aboutsummaryrefslogtreecommitdiff
path: root/gcc
AgeCommit message (Collapse)AuthorFilesLines
2021-03-09RTEMS: Fix -Werror buildsSebastian Huber1-5/+5
Fix build errors due to warnings such as: gcc/config/v850/rtems.h:43: error: "RTEMS_STARTFILE_SPEC" redefined [-Werror] 43 | #define RTEMS_STARTFILE_SPEC "" The problem was that "gcc/config/rtems.h" was included before the architecture-specific "gcc/config/*/rtems.h" header file on some architectures. gcc/ * config.gcc (aarch64-*-rtems*): Include general rtems.h after the architecture-specific rtems.h. (aarch64-*-rtems*): Likewise. (arm*-*-rtems*): Likewise. (epiphany-*-rtems*): Likewise. (riscv*-*-rtems*): Likewise.
2021-03-09phiopt: Fix up conditional_replacement [PR99305]Jakub Jelinek2-3/+29
Before my PR97690 changes, conditional_replacement would not set neg when the nonzero arg was boolean true. I've simplified the testing, so that it first finds the zero argument and then checks the other argument for all the handled cases (1, -1 and 1 << X, where the last case is what the patch added support for). But, unfortunately I've placed the integer_all_onesp test first. For unsigned precision 1 types such as bool integer_all_onesp, integer_onep and integer_pow2p can all be true and the code set neg to true in that case, which is undesirable. The following patch tests integer_pow2p first (which is trivially true for integer_onep too and tree_log2 in that case gives shift == 0) and only if that isn't the case, integer_all_onesp. 2021-03-09 Jakub Jelinek <jakub@redhat.com> PR tree-optimization/99305 * tree-ssa-phiopt.c (conditional_replacement): Test integer_pow2p before integer_all_onesp instead of vice versa. * g++.dg/opt/pr99305.C: New test.
2021-03-09rs6000: Fix check_effective_target_sqrt_insn (PR99352)Segher Boessenkool1-1/+16
The previous version returned true for all PowerPC. This is incorrect. We only support floating point square root instructions if a) we support floating point instructions at all, and b) we have _ARCH_PPCSQ defined. 2020-03-09 Segher Boessenkool <segher@kernel.crashing.org> gcc/testsuite/ * lib/target-supports.exp (check_effective_target_powerpc_sqrt): New. (check_effective_target_sqrt_insn): Use it.
2021-03-09arm: fix bootstrap failure following automatic mode selection patchRichard Earnshaw1-1/+1
Fix a signed vs unsigned comparison in last change. gcc: * common/config/arm/arm-common.c (arm_config_default): Change type of 'i' to unsigned.
2021-03-09[PR99454] LRA: Process separately 'g' and digital constraints > 9 in ↵Vladimir N. Makarov2-5/+51
process_address_1 gcc/ChangeLog: PR target/99454 * lra-constraints.c (process_address_1): Process constraint 'g' separately and digital constraints containing more one digit. gcc/testsuite/ChangeLog: PR target/99454 * gcc.target/i386/pr99454.c: New.
2021-03-09Re: [PATCH v2] fix Ada bootstrap on Cygwin64 (PR bootstrap/94918)Mikael Pettersson1-0/+6
gcc/ada/ * raise-gcc.c: On Cygwin include mingw32.h to prevent windows.h from including x86intrin.h or emmintrin.h.
2021-03-09c++: Fix coroutines on targetm.cxx.cdtor_return_this targets [PR99459]Jakub Jelinek1-16/+18
The r11-7528 build_co_await changes broke coroutines on arm*-linux-gnuabi, 2780 ^FAIL.*coroutines/ in total. The problem is that arm is targetm.cxx.cdtor_return_this target where both ctors and dtors in the ABI return this pointer rather than void, and build_new_method_call_1 does: else if (call != error_mark_node && DECL_DESTRUCTOR_P (cand->fn) && !VOID_TYPE_P (TREE_TYPE (call))) /* An explicit call of the form "x->~X()" has type "void". However, on platforms where destructors return "this" (i.e., those where targetm.cxx.cdtor_returns_this is true), such calls will appear to have a return value of pointer type to the low-level call machinery. We do not want to change the low-level machinery, since we want to be able to optimize "delete f()" on such platforms as "operator delete(~X(f()))" (rather than generating "t = f(), ~X(t), operator delete (t)"). */ call = build_nop (void_type_node, call); The new code in build_co_await relies on build_special_member_call returned expression being a CALL_EXPR, but due to the build_nop in there it is a NOP_EXPR around the CALL_EXPR. It can't be stripped with STRIP_NOPS because void has different mode from the pointer mode. 2021-03-09 Jakub Jelinek <jakub@redhat.com> PR c++/99459 * coroutines.cc (build_co_await): Look through NOP_EXPRs in build_special_member_call return value to find the CALL_EXPR. Simplify.
2021-03-09Fix building the RX port of gcc.Nick Clifton1-0/+3
* config/rx/rx.h (DBX_DEBUGGING_INFO): Define. (DWARF"_DEBUGGING_INFO): Define.
2021-03-09Assorted testsuite fixesEric Botcazou4-3/+5
First, gcc.dg/array-quals-1.c does not pass if the compiler is configured with --enable-default-pie because the sections change, so force -fno-pie. Second, replace *-*-solaris* with sparc*-*-* for gfortran.dg/pr95690.f90 because this depends on the architecture rather than the OS. Third force SRA to trigger on Aarch64 (like PowerPC) for gnat.dg/opt39.adb. gcc/testsuite/ * gcc.dg/array-quals-1.c: Pass -fno-pie if supported. * gcc.dg/loop-9.c: Likewise. * gfortran.dg/pr95690.f90: Replace *-*-solaris* with sparc*-*-*. * gnat.dg/opt39.adb: Pass --param option for Aarch64 too.
2021-03-09Fix internal error on lambda functionEric Botcazou1-13/+11
This boils down to the RTL expander trying to take the address of a DECL whose RTX is a register. gcc/ PR c++/90448 * calls.c (initialize_argument_information): When the argument is passed by reference, do not make a copy in a thunk only if the argument is already in memory. Remove redundant test for the case of callee copy.
2021-03-09[PR99454] LRA: Process 0..9 constraints in process_address_1Vladimir N. Makarov1-0/+4
We need to process 0..9 constraints to fetch the right op constraint in the function. Also 0..9 constraints gives unknown class constraint class which can result in skipping address normalization for memory in asm. gcc/ChangeLog: PR target/99454 * lra-constraints.c (process_address_1): Process 0..9 constraints in process_address_1.
2021-03-09IBM Z: arch14 fix option string used for BinutilsAndreas Krebbel1-1/+1
gcc/ChangeLog: * config/s390/s390.c (struct s390_processor processor_table): Binutils name string must not be empty.
2021-03-09testsuite: Fix up pr98920.c on non-glibc or old glibc targets [PR98920]Jakub Jelinek1-0/+4
Not all OSes have regex.h and not all OSes that do have REG_STARTEND macro support. Conditionalize the test on that. 2021-03-09 Jakub Jelinek <jakub@redhat.com> PR sanitizer/98920 * c-c++-common/asan/pr98920.c: Only include regex.h if the header exists. If REG_STARTEND macro isn't defined, just return 0 from main instead of the actual test.
2021-03-09c++: Clarify note about -fmodules-ts [PR 99472]Nathan Sidwell1-4/+8
This clarifies that c++2[03] intentionally does not enable c++20 modules. PR c++/99472 gcc/cp/ * parser.c (cp_parser_diagnose_invalid_type_name): Clarify that C++20 does not yet imply modules.
2021-03-09arc: Remove orphan function.Claudiu Zissulescu1-17/+0
Remove unused function. gcc/ 2021-03-09 Claudiu Zissulescu <claziss@synopsys.com> * config/arc/arc.c (arc_attr_type): Remove function. Signed-off-by: Claudiu Zissulescu <claziss@synopsys.com>
2021-03-09i386: Properly set ix86_isa_flagsMartin Liska2-4/+19
gcc/ChangeLog: PR target/99464 * config/i386/i386-options.c (ix86_option_override_internal): Set isa_flags for OPTS argument and not for the global global_options. gcc/testsuite/ChangeLog: PR target/99464 * gcc.target/i386/pr99464.c: New test.
2021-03-08Checked in non-final version of patch in commit ↵Aaron Sawdey1-8/+2
9433c844c8bcf0166567943b45576ceeeee0b131 Not sure what I did but this corrects it to the version that I tested and that Segher approved. gcc/ChangeLog * config/rs6000/predicates.md (ds_form_mem_operand): Check in correct code.
2021-03-08add powerpc_vsx_ok requirement to undef-bool testsJoel Brobecker2-0/+2
These tests use -mvsx in their dg-options lists, so they are only applicable if the -mvsx option is supported by the compiler. for gcc/testsuite/ChangeLog * gcc.target/powerpc/undef-bool-2.c: Add dg-require-effective-target powerpc_vsx_ok directive. * g++.dg/ext/undef-bool-1.C: Add dg-require-effective-target powerpc_vsx_ok directive.
2021-03-08Tighten predicates for p10 ld/cmpi fusionAaron Sawdey3-91/+113
PR99070 is caused by a fusion pattern matching that the individual instructions do not match when it is split later. In this case the ld+cmpi patterns were allowing a d-form load address, which the split condition would rightly split, however that left us with something that could not be matched by a ds-form ld instruction, hence the ICE. This only happened if the target cpu was not power10 -- if we were targeting power10 then a prefixed pld instruction would get generated because that can handle d-form. However this is not optimal code either. So the solution is a new predicate (ds_form_mem_operand) that only accepts what we can take as for a ds-form load. Then a small modification of the genfusion.pl script changes the relevant ld+cmpi patterns to use the new predicate. gcc/ChangeLog PR target/99070 * config/rs6000/predicates.md (ds_form_mem_operand) New predicate. * config/rs6000/genfusion.pl (gen_ld_cmpi_p10) Use ds_form_mem_operand in ld/lwa patterns. * config/rs6000/fusion.md: Regenerate file.
2021-03-08runtime: cast SIGSTKSZ to uintptrIan Lance Taylor1-1/+1
In newer versions of glibc it is long, which causes a signed comparison warning. Fixes PR go/99458
2021-03-09Daily bump.GCC Administrator6-1/+197
2021-03-08Update gcc de.po, sv.po.Joseph Myers2-450/+291
* de.po, sv.po: Update.
2021-03-08PR fortran/49278 - ICE when combining DATA with default initializationHarald Anlauf2-0/+20
A variable with the PARAMETER attribute may not appear in a DATA statement. gcc/fortran/ChangeLog: PR fortran/49278 * data.c (gfc_assign_data_value): Reject variable with PARAMETER attribute in DATA statement. gcc/testsuite/ChangeLog: PR fortran/49278 * gfortran.dg/parameter_data.f90: New test.
2021-03-08PR middle-end/98266 - bogus array subscript is partly outside array bounds ↵Martin Sebor6-1/+540
on virtual inheritance gcc/ChangeLog: PR middle-end/98266 * gimple-array-bounds.cc (inbounds_vbase_memaccess_p): New function. (array_bounds_checker::check_array_bounds): Call it. gcc/testsuite/ChangeLog: PR middle-end/98266 * g++.dg/warn/Warray-bounds-15.C: New test. * g++.dg/warn/Warray-bounds-18.C: New test. * g++.dg/warn/Warray-bounds-19.C: New test. * g++.dg/warn/Warray-bounds-20.C: New test. * g++.dg/warn/Warray-bounds-21.C: New test.
2021-03-08PR middle-end/97631 - bogus "writing one too many bytes" warning for memcpy ↵Martin Sebor6-47/+242
with strlen argument gcc/ChangeLog: PR middle-end/97631 * tree-ssa-strlen.c (maybe_warn_overflow): Test rawmem. (handle_builtin_stxncpy_strncat): Rename locals. Determine destination size from allocation calls. Issue a more appropriate kind of warning. (handle_builtin_memcpy): Pass true as rawmem to maybe_warn_overflow. (handle_builtin_memset): Same. gcc/testsuite/ChangeLog: PR middle-end/97631 * c-c++-common/Wstringop-overflow.c: Remove unexpected warnings. Add an xfail. * c-c++-common/Wstringop-truncation.c: Add expected warnings. * gcc.dg/Wstringop-overflow-10.c: Also enable -Wstringop-truncation. * gcc.dg/Wstringop-overflow-66.c: New test. * gcc.dg/tree-ssa/strncpy-2.c: Adjust expected warning.
2021-03-08c++: Add test for PR96268.Marek Polacek1-0/+13
This works since the recent r11-7102, but we didn't have a test for a template-argument context. gcc/testsuite/ChangeLog: PR c++/96268 * g++.dg/cpp2a/nontype-class41.C: New test.
2021-03-08C++: Enable c++2b module mode [PR 99436]Nathan Sidwell2-1/+3
This adds support for c++23 mode to modules, and enables such testing. PR c++/99436 gcc/cp/ * name-lookup.c (get_cxx_dialect_name): Add cxx23. gcc/testsuite/ * g++.dg/modules/modules.exp (MOD_STD_LIST): Add 2b.
2021-03-08c++: Poor diagnostic in header-unit [PR 99468]Nathan Sidwell3-2/+15
We didn't specifically check for a module-decl inside a header unit. That leads to a confusing diagostic. Fixed thusly. gcc/cp/ * lex.c (module_token_filter::resume): Ignore module-decls inside header-unit. * parser.c (cp_parser_module_declaration): Reject in header-unit. gcc/testsuite/ * g++.dg/modules/pr99468.H: New.
2021-03-08rs6000: Fix invalid splits when using Altivec style addresses [PR98959]Peter Bergner3-7/+34
The rs6000_emit_le_vsx_* functions assume they are not passed an Altivec style "& ~16" address. However, some of our expanders and splitters do not verify we do not have an Altivec style address before calling those functions, leading to an ICE. The solution here is to guard the expanders and splitters to ensure we do not call them if we're given an Altivec style address. 2021-03-08 Peter Bergner <bergner@linux.ibm.com> gcc/ PR target/98959 * config/rs6000/rs6000.c (rs6000_emit_le_vsx_permute): Add an assert to ensure we do not have an Altivec style address. * config/rs6000/vsx.md (*vsx_le_perm_load_<mode>): Disable if passed an Altivec style address. (*vsx_le_perm_store_<mode>): Likewise. (splitters after *vsx_le_perm_store_<mode>): Likewise. (vsx_load_<mode>): Disable special expander if passed an Altivec style address. (vsx_store_<mode>): Likewise. gcc/testsuite/ PR target/98959 * gcc.target/powerpc/pr98959.c: New test.
2021-03-08c++: Incorrect specialization hash table [PR 99285]Nathan Sidwell5-34/+71
Class template partial specializations need to be in the specialization hash, but not all of them. This defers adding streamed-in entities to the hash table, in the same way I deferred adding the instantiation and specialization lists for 99170. PR c++/99285 gcc/cp/ * cp-tree.h (match_mergeable_specialization) (add_mergeable_specialization): Adjust parms. * module.cc (trees_in::decl_value): Adjust add_mergeable_specialization calls. (trees_out::key_mergeable): Adjust match_mergeable_specialization calls. (specialization_add): Likewise. * pt.c (match_mergeable_specialization): Do not insert. (add_mergeable_specialization): Add to hash table here. gcc/testsuite/ * g++.dg/modules/pr99285_a.H: New. * g++.dg/modules/pr99285_b.H: New.
2021-03-08aarch64: Fix PR99437 - tighten shift predicates for narrowing shift patternsKyrylo Tkachov3-10/+46
In this bug combine forms the (R)SHRN(2) instructions with an invalid shift amount. The intrinsic expanders for these patterns validate the right shift amount but if the final patterns end up being matched by combine (or other RTL passes I suppose) they still let the wrong const_vector through. This patch tightens up the predicates for the instructions involved by using predicates for the right shift amount const_vectors. gcc/ChangeLog: PR target/99437 * config/aarch64/predicates.md (aarch64_simd_shift_imm_vec_qi): Define. (aarch64_simd_shift_imm_vec_hi): Likewise. (aarch64_simd_shift_imm_vec_si): Likewise. (aarch64_simd_shift_imm_vec_di): Likewise. * config/aarch64/aarch64-simd.md (aarch64_shrn<mode>_insn_le): Use predicate from above. (aarch64_shrn<mode>_insn_be): Likewise. (aarch64_rshrn<mode>_insn_le): Likewise. (aarch64_rshrn<mode>_insn_be): Likewise. (aarch64_shrn2<mode>_insn_le): Likewise. (aarch64_shrn2<mode>_insn_be): Likewise. (aarch64_rshrn2<mode>_insn_le): Likewise. (aarch64_rshrn2<mode>_insn_be): Likewise. gcc/testsuite/ChangeLog: PR target/99437 * gcc.target/aarch64/simd/pr99437.c: New test.
2021-03-08libsanitizer: cherry-pick ad294e572bc5c16f9dc420cc994322de6ca3fbfbMartin Liska1-0/+24
libsanitizer/ChangeLog: PR sanitizer/98920 * asan/asan_interceptors.cpp (COMMON_INTERCEPT_FUNCTION_VER): Cherry pick. (COMMON_INTERCEPT_FUNCTION_VER_UNVERSIONED_FALLBACK): Likewise. * asan/asan_interceptors.h (ASAN_INTERCEPT_FUNC_VER_UNVERSIONED_FALLBACK): Likewise. * sanitizer_common/sanitizer_common_interceptors.inc (COMMON_INTERCEPT_FUNCTION_GLIBC_VER_MIN): Likewise. (INIT_REGEX): Likewise. * tsan/tsan_interceptors_posix.cpp (COMMON_INTERCEPT_FUNCTION_VER_UNVERSIONED_FALLBACK): Likewise. gcc/testsuite/ChangeLog: PR sanitizer/98920 * c-c++-common/asan/pr98920.c: New test.
2021-03-08[PR99422] LRA: Skip modifiers when processing memory address.Vladimir N. Makarov1-2/+20
Function process_address_1 can wrongly look at constraint modifiers instead of the 1st constraint itself. The patch solves the problem. gcc/ChangeLog: PR target/99422 * lra-constraints.c (skip_contraint_modifiers): New function. (process_address_1): Use it before lookup_constraint call.
2021-03-08i386: Enable UINTR and HRESET for -march that supports itMartin Liska3-0/+17
gcc/ChangeLog: PR target/99463 * config/i386/i386-options.c (ix86_option_override_internal): Enable UINTR and HRESET for -march that supports it. gcc/testsuite/ChangeLog: PR target/99463 * gcc.target/i386/pr99463-2.c: New test. * gcc.target/i386/pr99463.c: New test.
2021-03-08IBM Z: Fix usage of "f" constraint with long doublesIlya Leoshkevich8-0/+190
After switching the s390 backend to store long doubles in vector registers, "f" constraint broke when used with the former: long doubles correspond to TFmode, which in combination with "f" corresponds to hard regs %v0-%v15, however, asm users expect a %f0-%f15 pair. Fix by using TARGET_MD_ASM_ADJUST hook to convert TFmode values to FPRX2mode and back. gcc/ChangeLog: 2020-12-14 Ilya Leoshkevich <iii@linux.ibm.com> * config/s390/s390.c (f_constraint_p): New function. (s390_md_asm_adjust): Implement TARGET_MD_ASM_ADJUST. (TARGET_MD_ASM_ADJUST): Likewise. gcc/testsuite/ChangeLog: 2020-12-14 Ilya Leoshkevich <iii@linux.ibm.com> * gcc.target/s390/vector/long-double-asm-commutative.c: New test. * gcc.target/s390/vector/long-double-asm-earlyclobber.c: New test. * gcc.target/s390/vector/long-double-asm-in-out.c: New test. * gcc.target/s390/vector/long-double-asm-inout.c: New test. * gcc.target/s390/vector/long-double-asm-matching.c: New test. * gcc.target/s390/vector/long-double-asm-regmem.c: New test. * gcc.target/s390/vector/long-double-volatile-from-i64.c: New test.
2021-03-08tree-nested: Update assert for Fortran module vars [PR97927]Tobias Burnus2-0/+38
gcc/ChangeLog: PR fortran/97927 * tree-nested.c (convert_local_reference_stmt): Avoid calling lookup_field_for_decl for Fortran module (= namespace context). gcc/testsuite/ChangeLog: PR fortran/97927 * gfortran.dg/module_variable_3.f90: New test.
2021-03-08IBM Z: Fix vcond-shift.c testcase.Andreas Krebbel2-6/+16
Due to a common code change the comparison in the testcase is emitted via vec_cmp instead of vcond. The testcase checks for an optimization currently only available via vcond. Fixed by implementing the same optimization also in s390_expand_vec_compare. gcc/ChangeLog: * config/s390/s390.c (s390_expand_vec_compare): Implement <0 comparison with arithmetic right shift. (s390_expand_vcond): No need for a force_reg anymore. s390_vec_compare will do it. * config/s390/vector.md ("vec_cmp<mode><tointvec>"): Accept also immediate operands.
2021-03-08Daily bump.GCC Administrator3-1/+22
2021-03-07i386: Fix some -mavx512vl -mno-avx512bw bugs [PR99321]Jakub Jelinek5-22/+79
As I wrote in the mail with the previous PR99321 fix, we have various bugs where we emit instructions that need avx512bw and avx512vl ISAs when compiling with -mavx512vl -mno-avx512bw. Without the following patch, the attached testcase fails with: /tmp/ccW4PsfG.s: Assembler messages: /tmp/ccW4PsfG.s:9: Error: unsupported instruction `vpaddb' /tmp/ccW4PsfG.s:20: Error: unsupported instruction `vpaddb' /tmp/ccW4PsfG.s:31: Error: unsupported instruction `vpaddw' /tmp/ccW4PsfG.s:42: Error: unsupported instruction `vpaddw' /tmp/ccW4PsfG.s:53: Error: unsupported instruction `vpsubb' /tmp/ccW4PsfG.s:64: Error: unsupported instruction `vpsubb' /tmp/ccW4PsfG.s:75: Error: unsupported instruction `vpsubw' /tmp/ccW4PsfG.s:86: Error: unsupported instruction `vpsubw' /tmp/ccW4PsfG.s:97: Error: unsupported instruction `vpmullw' /tmp/ccW4PsfG.s:108: Error: unsupported instruction `vpmullw' /tmp/ccW4PsfG.s:133: Error: unsupported instruction `vpminub' /tmp/ccW4PsfG.s:144: Error: unsupported instruction `vpminuw' /tmp/ccW4PsfG.s:155: Error: unsupported instruction `vpminuw' /tmp/ccW4PsfG.s:166: Error: unsupported instruction `vpminsb' /tmp/ccW4PsfG.s:177: Error: unsupported instruction `vpminsb' /tmp/ccW4PsfG.s:202: Error: unsupported instruction `vpminsw' /tmp/ccW4PsfG.s:227: Error: unsupported instruction `vpmaxub' /tmp/ccW4PsfG.s:238: Error: unsupported instruction `vpmaxuw' /tmp/ccW4PsfG.s:249: Error: unsupported instruction `vpmaxuw' /tmp/ccW4PsfG.s:260: Error: unsupported instruction `vpmaxsb' /tmp/ccW4PsfG.s:271: Error: unsupported instruction `vpmaxsb' /tmp/ccW4PsfG.s:296: Error: unsupported instruction `vpmaxsw' We already have Yw constraint which is equivalent to v for -mavx512bw -mavx512vl and to nothing otherwise, per discussions this patch changes it to stand for x otherwise. As it is an undocumented internal constraint, hopefully it won't affect any inline asm in the wild. For the instructions that need both we need to use Yw and v for modes that don't need that. 2021-03-07 Jakub Jelinek <jakub@redhat.com> PR target/99321 * config/i386/constraints.md (Yw): Use SSE_REGS if TARGET_SSE but TARGET_AVX512BW or TARGET_AVX512VL is not set. Adjust description and comment. * config/i386/sse.md (v_Yw): New define_mode_attr. (*<insn><mode>3, *mul<mode>3<mask_name>, *avx2_<code><mode>3, *sse4_1_<code><mode>3<mask_name>): Use <v_Yw> instead of v in constraints. * config/i386/mmx.md (mmx_pshufw_1, *vec_dupv4hi): Use Yw instead of xYw in constraints. * lib/target-supports.exp (check_effective_target_assembler_march_noavx512bw): New effective target. * gcc.target/i386/avx512vl-pr99321-1.c: New test.
2021-03-07Daily bump.GCC Administrator5-1/+71
2021-03-06c++: Fix constexpr evaluation of pre-increment when !lval [PR99287]Patrick Palka2-10/+68
Here, during cxx_eval_increment_expression (with lval=false) of ++__first where __first is &"mystr"[0], we correctly update __first to &"mystr"[1] but we end up returning &"mystr"[0] + 1 instead of &"mystr"[1]. This unreduced return value inhibits other pointer arithmetic folding during later constexpr evaluation, which ultimately causes the constexpr evaluation to fail. It turns out the simplification of &"mystr"[0] + 1 to &"mystr"[1] is performed by cxx_fold_pointer_plus_expression, not by fold_build2. So we perform this simplification during constexpr evaluation of the temporary MODIFY_EXPR (during which we assign to __first the simplified value), but then we return 'mod' which has only been folded via fold_build2 and hasn't gone through cxx_fold_pointer_plus_expression. This patch fixes this by updating 'mod' with the result of the MODIFY_EXPR evaluation appropriately, so that it captures any additional folding of the expression when !lval. We now need to be wary of this evaluation failing and returning e.g. the MODIFY_EXPR or NULL_TREE; it seems checking *non_constant_p should cover our bases here and is generally prudent. gcc/cp/ChangeLog: PR c++/99287 * constexpr.c (cxx_eval_increment_expression): Pass lval when evaluating the MODIFY_EXPR, and update 'mod' with the result of this evaluation. Check *non_constant_p afterwards. For prefix ops, just return 'mod'. gcc/testsuite/ChangeLog: PR c++/99287 * g++.dg/cpp2a/constexpr-99287.C: New test. Co-authored-by: Jakub Jelinek <jakub@redhat.com>
2021-03-06middle-end: Pretty-print address space of aggregatesJulian Brown1-0/+7
This patch adds printing of "<address-space-N>" markers for aggregates in non-default address spaces. gcc/ * tree-pretty-print.c (dump_generic_node): Emit non-generic address space info for aggregates.
2021-03-06d: Don't set default flag_complex_method.Iain Buclaw1-3/+0
D doesn't need C99-like requirements for complex multiply and divide, the default set by common.opt is sufficient enough. gcc/d/ChangeLog: * d-lang.cc (d_init_options_struct): Don't set default flag_complex_method.
2021-03-06c++: Fix tsubsting member variable template-id [PR96330]Patrick Palka3-3/+37
This makes tsubst_copy appropriately handle a variable template-id, which in turn fixes tsubsting a COMPONENT_REF whose member operand is known at parse time to be a variable template-id, as in the initialization of 'x' in the first testcase. Previously, we rejected this testcase with the error "foo_t::bar<T> is not a function template", issued from lookup_template_fuction. We were already properly handling the analagous case where the object operand of the COMPONENT_REF is dependent (and so the member operand is a dependent template name), but there doesn't seems to be existing test coverage for this, hence the second testcase below. gcc/cp/ChangeLog: PR c++/96330 * pt.c (tsubst_copy) <case TEMPLATE_ID_EXPR>: Rename local variable 'fn' to 'tmpl'. Handle a variable template-id by calling lookup_template_variable. gcc/testsuite/ChangeLog: PR c++/96330 * g++.dg/cpp1y/var-templ68.C: New test. * g++.dg/cpp1y/var-templ68a.C: New test. Co-authored-by: Jakub Jelinek <jakub@redhat.com>
2021-03-06c++: adc_unify deduction with constrained auto [PR99365]Patrick Palka3-44/+136
My recent r11-7454 changed the way do_auto_deduction handles constrained placeholders during template argument deduction (context == adc_unify) when processing_template_decl != 0. Before the patch, we would just ignore the constraints on the placeholder, and return the deduced type. After the patch, we now punt and return the original placeholder type While this change fixed instances where we'd prematurely resolve a constrained placeholder return or variable type with non-dependent initializer at template parse time (such as PR96444), it broke the adc_unify callers that rely on the previous behavior. This patch restores the previous behavior during adc_unify deduction while retaining the new behavior only during adc_variable_type or adc_return_type deduction. We additionally now need to pass the outer template arguments to do_auto_deduction during unify, for sake of constraint checking. But we want to avoid substituting these outer arguments into type when the caller has already done so, so this patch adds a TEMPLATE_TYPE_LEVEL check to do_auto_deduction to that effect. This above is enough to fix partial specialization of non-nested templates with constrained 'auto' template parameters, but it doesn't fix the nested template case, ultimately because most_specialized_partial_spec passes only the innermost template arguments to get_partial_spec_bindings, and so outer_targs during do_auto_deduction (called from unify) contains only the innermost template arguments, and this breaks satisfaction. Fixing this properly is perhaps too risky at this stage, so this patch adds a hack to do_auto_deduction to compensate for callers that don't supply all outer template arguments. The goal of this hack is to ensure placeholder type constraint checking continues to work whenever it worked before r11-7454, namely whenever the constraint is non-dependent. Finally, this patch allows do_auto_deduction to resolve a constrained placeholder type ahead of time (at template parse time), as long as the constraint is non-dependent. gcc/cp/ChangeLog: PR c++/99365 * pt.c (unify) <case TEMPLATE_TYPE_PARM>: Pass targs as outer_targs to do_auto_deduction. (placeholder_type_constraint_dependent_p): Define. (do_auto_deduction): When processing_template_decl != 0 and context is adc_unify and we have constraints, pretend the constraints are satisfied instead of punting. Otherwise don't punt unless placeholder_type_constraint_dependent_p holds. Add some clarifying sanity checks. Add a hack to add missing outermost template levels to outer_args before checking satisfaction. Don't substitute outer_targs into type if it's already been done. gcc/testsuite/ChangeLog: PR c++/99365 * g++.dg/cpp2a/concepts-partial-spec9.C: New test. * g++.dg/cpp2a/concepts-placeholder4.C: New test.
2021-03-06cris: don't define MAX_FIXED_MODE_SIZEHans-Peter Nilsson1-7/+0
It's been 32 ever since the CRIS port was committed. A TODO-item of mine has been to check whether the non-default setting of MAX_FIXED_MODE_SIZE makes sense wrt. performance and/or code-size with a modern gcc. It doesn't, so it goes. The setting is now the default, GET_MODE_BITSIZE (DImode) (defaults.h) i.e. 64. Measurements at r11-7500 (f3641ac70eb0) on coremark with "-O2 -march=v10 -mno-mul-bug-workaround" shows 0.04% performance improvement with this change, and by inspection the effect is that unused and/or unneeded stack-frames are eliminated more often in the floating-point library (not in the coremark main loop, thus the marginal improvement). The floating-point library is full of 64-bit unions used to pick apart floating point numbers, so this kind of makes sense. Inspection of a simulator trace shows that this is indeed the only effect in coremark. Other local micro-benchmarks agree as to the net effect (no traces were inspected though), and the most floating-point-heavy test shows an 8% improvement. These effects are of course subject to gcc core tweaks and may make sense to be adjusted again in a future release. While MAX_FIXED_MODE_SIZE is IMO supposed to be an optional macro for performance, setting it to anything smaller than twice the size of an address exposes bad decisions in gcc middle end, sometimes leading to internal compiler errors. (It being set to 32 should *not* affect use of DImode as an integer mode; it's for "integer machine modes of this size or smaller can be used for structures and unions with the appropriate sizes".) Thus, with the default 64 instead of 32, there are two tests that now pass for the first time: gcc.dg/attr-vector_size.c and gcc.dg/tree-ssa/pr93121-1.c. gcc: * config/cris/cris.h (MAX_FIXED_MODE_SIZE): Don't define.
2021-03-06gcc.target/cris/pr93372-1.c: Adjust expectations for eliminated stack-frameHans-Peter Nilsson1-1/+10
See comment. * gcc.target/cris/pr93372-1.c: Adjust expected assembler result to allow an eliminated stack-frame.
2021-03-06Daily bump.GCC Administrator8-1/+238
2021-03-05c++: Pointer-to-member fn conversion with noexcept [PR99374]Marek Polacek2-1/+17
The issue in this PR is that we wrongly reject converting pointers to member function of incomplete types, one of which has noexcept. Recall that pointers (including pointers to member functions) to non-throwing functions can be implicitly converted to potentially-throwing functions (but not vice versa). We reject the conversion when called from can_convert_arg_bad because standard_conversion can't create such a conversion. It comes down to the DERIVED_FROM_P check in the TYPE_PTRMEMFUNC_P block. It considers every class derived from itself, but not when the class is incomplete. But surely we want to reach fnptr_conv_p when tbase is fbase (one of them could be an alias to the other so use same_type_p instead of ==). Another approach would be to not perform DERIVED_FROM_P at all when either tbase or fbase are incomplete (so perhaps something like at the end of ptr_reasonably_similar). gcc/cp/ChangeLog: PR c++/99374 * call.c (standard_conversion): When converting pointers to member, don't return NULL when the bases are equivalent but incomplete. gcc/testsuite/ChangeLog: PR c++/99374 * g++.dg/cpp1z/noexcept-type23.C: New test.
2021-03-05c++: ICE with -Wshadow and enumerator in template [PR99120]Marek Polacek2-3/+15
We crash here, because in a template, an enumerator doesn't have a type until we've called finish_enum_value_list. But our -Wshadow implementation, check_local_shadow, is called when we pushdecl in build_enumerator, which takes place before finish_enum_value_list. gcc/cp/ChangeLog: PR c++/99120 * name-lookup.c (check_local_shadow): Check if the type of decl is non-null before checking TYPE_PTR*. gcc/testsuite/ChangeLog: PR c++/99120 * g++.dg/warn/Wshadow-17.C: New test.
generated by cgit v1.1 at 2025-09-04 08:29:37 +0000