Merge pull request #1 from gcc-mirror/master #2

ghost · 2015-07-03T10:26:56Z

just merge

wtf: just merge

We have two desires for interaction of __builtin_constant_p with constexpr: 1) it should be a constant-expression even if its operands are not, and 2) we shouldn't fold it to false prematurely when parsing a constexpr function (c++/54021). We were having trouble with both of these, and this patch fixes #1 without breaking gcc-mirror#2. gcc/cp/ Backport from mainline 2015-04-28 Jason Merrill <jason@redhat.com> PR c++/65656 * constexpr.c (cxx_eval_builtin_function_call): Fix __builtin_constant_p. gcc/testsuite/ Backport from mainline 2015-04-28 Jason Merrill <jason@redhat.com> PR c++/65656 * g++.dg/cpp0x/constexpr-builtin3.C: New test.

operand gcc-mirror#2 for COMPONENT_REF. * gcc-interface/utils2.c (gnat_save_expr): Likewise. (gnat_protect_expr): Likewise. (gnat_stabilize_reference_1): Likewise. (gnat_rewrite_reference): Do not bother about operand gcc-mirror#3 for ARRAY_REF. (get_inner_constant_reference): Likewise. (gnat_invariant_expr): Likewise. * gcc-interface/trans.c (fold_constant_decl_in_expr): Likewise. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@235701 138bc75d-0d04-0410-961f-82ee72b054a4

long series of fixes and updates -> bring back to master

* tree.c (ovl_copy): Adjust assert, copy OVL_LOOKUP. (ovl_used): New. (lookup_keep): Call it. PR c++/80891 (gcc-mirror#2) * g++.dg/lookup/pr80891-2.C: New. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@248570 138bc75d-0d04-0410-961f-82ee72b054a4

gcc/ChangeLog: 2017-07-13 Martin Liska <mliska@suse.cz> * dwarf2out.c (gen_pointer_type_die): Remove dead code. (gen_reference_type_die): Likewise. * stor-layout.c: Remove Pascal-related comment.

2017-07-13 Martin Liska <mliska@suse.cz> * dwarf2out.c (gen_pointer_type_die): Remove dead code. (gen_reference_type_die): Likewise. * stor-layout.c: Remove Pascal-related comment. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@250184 138bc75d-0d04-0410-961f-82ee72b054a4

Make ix86_frame available to i386 code generation. This is needed to backport the patch set of -mindirect-branch= to mitigate variant #2 of the speculative execution vulnerabilities on x86 processors identified by CVE-2017-5715, aka Spectre. Backport from mainline * config/i386/i386.c (ix86_frame): Moved to ... * config/i386/i386.h (ix86_frame): Here. (machine_function): Add frame. * config/i386/i386.c (ix86_compute_frame_layout): Repace the frame argument with &cfun->machine->frame. (ix86_can_use_return_insn_p): Don't pass &frame to ix86_compute_frame_layout. Copy frame from cfun->machine->frame. (ix86_can_eliminate): Likewise. (ix86_expand_prologue): Likewise. (ix86_expand_epilogue): Likewise. (ix86_expand_split_stack_prologue): Likewise.

Make ix86_frame available to i386 code generation. This is needed to backport the patch set of -mindirect-branch= to mitigate variant #2 of the speculative execution vulnerabilities on x86 processors identified by CVE-2017-5715, aka Spectre. Backport from mainline * config/i386/i386.c (ix86_frame): Moved to ... * config/i386/i386.h (ix86_frame): Here. (machine_function): Add frame. * config/i386/i386.c (ix86_compute_frame_layout): Repace the frame argument with &cfun->machine->frame. (ix86_can_use_return_insn_p): Don't pass &frame to ix86_compute_frame_layout. Copy frame from cfun->machine->frame. (ix86_can_eliminate): Likewise. (ix86_expand_prologue): Likewise. (ix86_expand_epilogue): Likewise. (ix86_expand_split_stack_prologue): Likewise. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-7-branch@256691 138bc75d-0d04-0410-961f-82ee72b054a4

Make ix86_frame available to i386 code generation. This is needed to backport the patch set of -mindirect-branch= to mitigate variant gcc-mirror#2 of the speculative execution vulnerabilities on x86 processors identified by CVE-2017-5715, aka Spectre. Backport from mainline * config/i386/i386.c (ix86_frame): Moved to ... * config/i386/i386.h (ix86_frame): Here. (machine_function): Add frame. * config/i386/i386.c (ix86_compute_frame_layout): Repace the frame argument with &cfun->machine->frame. (ix86_can_use_return_insn_p): Don't pass &frame to ix86_compute_frame_layout. Copy frame from cfun->machine->frame. (ix86_can_eliminate): Likewise. (ix86_expand_prologue): Likewise. (ix86_expand_epilogue): Likewise. (ix86_expand_split_stack_prologue): Likewise.

This patch implements GCC support for mitigating vulnerability CVE-2017-5715 known as Spectre #2 on IBM Z. In order to disable prediction of indirect branches the implementation makes use of an IBM Z specific feature - the execute instruction. Performing an indirect branch via execute prevents the branch from being subject to dynamic branch prediction. The implementation tries to stay close to the x86 solution regarding user interface. x86 style options supported (without thunk-inline): -mindirect-branch=(keep|thunk|thunk-extern) -mfunction-return=(keep|thunk|thunk-extern) IBM Z specific options: -mindirect-branch-jump=(keep|thunk|thunk-extern|thunk-inline) -mindirect-branch-call=(keep|thunk|thunk-extern) -mfunction-return-reg=(keep|thunk|thunk-extern) -mfunction-return-mem=(keep|thunk|thunk-extern) These options allow us to enable/disable the branch conversion at a finer granularity. -mindirect-branch sets the value of -mindirect-branch-jump and -mindirect-branch-call. -mfunction-return sets the value of -mfunction-return-reg and -mfunction-return-mem. All these options are supported on GCC command line as well as function attributes. 'thunk' triggers the generation of out of line thunks (expolines) and replaces the formerly indirect branch with a direct branch to the thunk. Depending on the -march= setting two different types of thunks are generated. With -march=z10 or higher exrl (execute relative long) is being used while targeting older machines makes use of larl/ex instead. From a security perspective the exrl variant is preferable. 'thunk-extern' does the branch replacement like 'thunk' but does not emit the thunks. 'thunk-inline' is only available for indirect jumps. It should be used in environments where correct CFI is important - known as user space. Additionally the patch introduces the -mindirect-branch-table option which generates tables pointing to the locations which have been modified. This is supposed to allow reverting the changes without re-compilation in situations where it isn't required. The sections are split up into one section per option. gcc/ChangeLog: 2018-02-08 Andreas Krebbel <krebbel@linux.vnet.ibm.com> * config/s390/s390-opts.h (enum indirect_branch): Define. * config/s390/s390-protos.h (s390_return_addr_from_memory) (s390_indirect_branch_via_thunk) (s390_indirect_branch_via_inline_thunk): Add function prototypes. (enum s390_indirect_branch_type): Define. * config/s390/s390.c (struct s390_frame_layout, struct machine_function): Remove. (indirect_branch_prez10thunk_mask, indirect_branch_z10thunk_mask) (indirect_branch_table_label_no, indirect_branch_table_name): Define variables. (INDIRECT_BRANCH_NUM_OPTIONS): Define macro. (enum s390_indirect_branch_option): Define. (s390_return_addr_from_memory): New function. (s390_handle_string_attribute): New function. (s390_attribute_table): Add new attribute handler. (s390_execute_label): Handle UNSPEC_EXECUTE_JUMP patterns. (s390_indirect_branch_via_thunk): New function. (s390_indirect_branch_via_inline_thunk): New function. (s390_function_ok_for_sibcall): When jumping via thunk disallow sibling call optimization for non z10 compiles. (s390_emit_call): Force indirect branch target to be a single register. Add r1 clobber for non-z10 compiles. (s390_emit_epilogue): Emit return jump via return_use expander. (s390_reorg): Handle JUMP_INSNs as execute targets. (s390_option_override_internal): Perform validity checks for the new command line options. (s390_indirect_branch_attrvalue): New function. (s390_indirect_branch_settings): New function. (s390_set_current_function): Invoke s390_indirect_branch_settings. (s390_output_indirect_thunk_function): New function. (s390_code_end): Implement target hook. (s390_case_values_threshold): Implement target hook. (TARGET_ASM_CODE_END, TARGET_CASE_VALUES_THRESHOLD): Define target macros. * config/s390/s390.h (struct s390_frame_layout) (struct machine_function): Move here from s390.c. (TARGET_INDIRECT_BRANCH_NOBP_RET) (TARGET_INDIRECT_BRANCH_NOBP_JUMP) (TARGET_INDIRECT_BRANCH_NOBP_JUMP_THUNK) (TARGET_INDIRECT_BRANCH_NOBP_JUMP_INLINE_THUNK) (TARGET_INDIRECT_BRANCH_NOBP_CALL) (TARGET_DEFAULT_INDIRECT_BRANCH_TABLE) (TARGET_INDIRECT_BRANCH_THUNK_NAME_EXRL) (TARGET_INDIRECT_BRANCH_THUNK_NAME_EX) (TARGET_INDIRECT_BRANCH_TABLE): Define macros. * config/s390/s390.md (UNSPEC_EXECUTE_JUMP) (INDIRECT_BRANCH_THUNK_REGNUM): Define constants. (mnemonic attribute): Add values which aren't recognized automatically. ("*cjump_long", "*icjump_long", "*basr", "*basr_r"): Disable pattern for branch conversion. Fix mnemonic attribute. ("*c<code>", "*sibcall_br", "*sibcall_value_br", "*return"): Emit indirect branch via thunk if requested. ("indirect_jump", "<code>"): Expand patterns for branch conversion. ("*indirect_jump"): Disable for branch conversion using out of line thunks. ("indirect_jump_via_thunk<mode>_z10") ("indirect_jump_via_thunk<mode>") ("indirect_jump_via_inlinethunk<mode>_z10") ("indirect_jump_via_inlinethunk<mode>", "*casesi_jump") ("casesi_jump_via_thunk<mode>_z10", "casesi_jump_via_thunk<mode>") ("casesi_jump_via_inlinethunk<mode>_z10") ("casesi_jump_via_inlinethunk<mode>", "*basr_via_thunk<mode>_z10") ("*basr_via_thunk<mode>", "*basr_r_via_thunk_z10") ("*basr_r_via_thunk", "return<mode>_prez10"): New pattern. ("*indirect2_jump"): Disable for branch conversion. ("casesi_jump"): Turn into expander and expand patterns for branch conversion. ("return_use"): New expander. ("*return"): Emit return via thunk and rename it to ... ("*return<mode>"): ... this one. * config/s390/s390.opt: Add new options and and enum for the option values. gcc/testsuite/ChangeLog: 2018-02-08 Andreas Krebbel <krebbel@linux.vnet.ibm.com> * gcc.target/s390/nobp-function-pointer-attr.c: New test. * gcc.target/s390/nobp-function-pointer-nothunk.c: New test. * gcc.target/s390/nobp-function-pointer-z10.c: New test. * gcc.target/s390/nobp-function-pointer-z900.c: New test. * gcc.target/s390/nobp-indirect-jump-attr.c: New test. * gcc.target/s390/nobp-indirect-jump-inline-attr.c: New test. * gcc.target/s390/nobp-indirect-jump-inline-z10.c: New test. * gcc.target/s390/nobp-indirect-jump-inline-z900.c: New test. * gcc.target/s390/nobp-indirect-jump-nothunk.c: New test. * gcc.target/s390/nobp-indirect-jump-z10.c: New test. * gcc.target/s390/nobp-indirect-jump-z900.c: New test. * gcc.target/s390/nobp-return-attr-all.c: New test. * gcc.target/s390/nobp-return-attr-neg.c: New test. * gcc.target/s390/nobp-return-mem-attr.c: New test. * gcc.target/s390/nobp-return-mem-nothunk.c: New test. * gcc.target/s390/nobp-return-mem-z10.c: New test. * gcc.target/s390/nobp-return-mem-z900.c: New test. * gcc.target/s390/nobp-return-reg-attr.c: New test. * gcc.target/s390/nobp-return-reg-mixed.c: New test. * gcc.target/s390/nobp-return-reg-nothunk.c: New test. * gcc.target/s390/nobp-return-reg-z10.c: New test. * gcc.target/s390/nobp-return-reg-z900.c: New test. * gcc.target/s390/nobp-table-jump-inline-z10.c: New test. * gcc.target/s390/nobp-table-jump-inline-z900.c: New test. * gcc.target/s390/nobp-table-jump-z10.c: New test. * gcc.target/s390/nobp-table-jump-z900.c: New test. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@257489 138bc75d-0d04-0410-961f-82ee72b054a4

Make ix86_frame available to i386 code generation. This is needed to backport the patch set of -mindirect-branch= to mitigate variant gcc-mirror#2 of the speculative execution vulnerabilities on x86 processors identified by CVE-2017-5715, aka Spectre. Backport from mainline * config/i386/i386.c (ix86_frame): Moved to ... * config/i386/i386.h (ix86_frame): Here. (machine_function): Add frame. * config/i386/i386.c (ix86_compute_frame_layout): Repace the frame argument with &cfun->machine->frame. (ix86_can_use_return_insn_p): Don't pass &frame to ix86_compute_frame_layout. Copy frame from cfun->machine->frame. (ix86_can_eliminate): Likewise. (ix86_expand_prologue): Likewise. (ix86_expand_epilogue): Likewise. (ix86_expand_split_stack_prologue): Likewise. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-7-branch@256691 138bc75d-0d04-0410-961f-82ee72b054a4

Make ix86_frame available to i386 code generation. This is needed to backport the patch set of -mindirect-branch= to mitigate variant #2 of the speculative execution vulnerabilities on x86 processors identified by CVE-2017-5715, aka Spectre. Backport from mainline 2017-10-13 H.J. Lu <hongjiu.lu@intel.com> PR target/82499 * config/i386/i386.h (ix86_red_zone_size): New. 2017-06-01 Bernd Edlinger <bernd.edlinger@hotmail.de> * config/i386/i386.c (ix86_frame): Moved to ... * config/i386/i386.h (ix86_frame): Here. (machine_function): Add frame. * config/i386/i386.c (ix86_compute_frame_layout): Repace the frame argument with &cfun->machine->frame. (ix86_can_use_return_insn_p): Don't pass &frame to ix86_compute_frame_layout. Copy frame from cfun->machine->frame. (ix86_can_eliminate): Likewise. (ix86_expand_prologue): Likewise. (ix86_expand_epilogue): Likewise. (ix86_expand_split_stack_prologue): Likewise. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-6-branch@259408 138bc75d-0d04-0410-961f-82ee72b054a4

When -fcf-protection -mcet is used, I got FAIL: g++.dg/eh/sighandle.C (gdb) bt #0 _Unwind_RaiseException (exc=exc@entry=0x416ed0) at /export/gnu/import/git/sources/gcc/libgcc/unwind.inc:140 #1 0x00007ffff7d9936b in __cxxabiv1::__cxa_throw (obj=<optimized out>, tinfo=0x403dd0 <typeinfo for int@@CXXABI_1.3>, dest=0x0) at /export/gnu/import/git/sources/gcc/libstdc++-v3/libsupc++/eh_throw.cc:90 #2 0x0000000000401255 in sighandler (signo=11, si=0x7fffffffd6f8, uc=0x7fffffffd5c0) at /export/gnu/import/git/sources/gcc/gcc/testsuite/g++.dg/eh/sighandle.C:9 #3 <signal handler called> <<<< Signal frame which isn't on shadow stack #4 dosegv () at /export/gnu/import/git/sources/gcc/gcc/testsuite/g++.dg/eh/sighandle.C:14 #5 0x00000000004012e3 in main () at /export/gnu/import/git/sources/gcc/gcc/testsuite/g++.dg/eh/sighandle.C:30 (gdb) p frames $6 = 5 (gdb) frame count should be 4, not 5. This patch skips signal frames when unwinding shadow stack. gcc/testsuite/ PR libgcc/85334 * g++.dg/torture/pr85334.C: New test. libgcc/ PR libgcc/85334 * unwind-generic.h (_Unwind_Frames_Increment): New. * config/i386/shadow-stack-unwind.h (_Unwind_Frames_Increment): Likewise. * unwind.inc (_Unwind_RaiseException_Phase2): Increment frame count with _Unwind_Frames_Increment. (_Unwind_ForcedUnwind_Phase2): Likewise. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@259502 138bc75d-0d04-0410-961f-82ee72b054a4

This patch fixes an LRA cycling problem on the attached testcase. The original insn was: (insn 74 72 76 8 (set (reg:V2DI 287 [ _166 ]) (subreg:V2DI (reg/v/f:DI 112 [ d ]) 0)) 1060 {*aarch64_simd_movv2di} (nil)) which IRA converted to: (insn 74 72 580 8 (set (reg:V2DI 287 [ _166 ]) (subreg:V2DI (reg/v/f:DI 517 [orig:112 d ] [112]) 0)) 1060 {*aarch64_simd_movv2di} (nil)) after creating loop allocnos. It happens that the ALLOCNO_WMODEs for both 112 and 517 were not set to V2DI due to another bug that I'll post a separate patch for, but we nevertheless got a valid allocation of register 1. LRA's first try at constraining the instruction gave: Choosing alt 5 in insn 74: (0) ?w (1) r {*aarch64_simd_movv2di} at which point all was good. But LRA later decided it needed to spill r517: Spill r517 after risky transformations so the next constraint attempt gave: Choosing alt 0 in insn 74: (0) =w (1) m {*aarch64_simd_movv2di} which was still good. Then during inheritance we had: Creating newreg=672 from oldreg=517, assigning class GENERAL_REGS to inheritance r672 Original reg change 517->672 (bb8): 74: r287:V2DI=r672:DI#0 Add inheritance<-original before: 939: r672:DI=r517:DI Inheritance reuse change 517->672 (bb8): 620: r572:DI=r672:DI REG_DEAD r672:DI Use smallest class of POINTER_REGS and GENERAL_REGS Creating newreg=673 from oldreg=517, assigning class POINTER_REGS to inheritance r673 Original reg change 517->673 (bb8): 936: r669:DI=r673:DI Add inheritance<-original before: 940: r673:DI=r517:DI ("Use smallest class of POINTER_REGS and GENERAL_REGS" ought to give GENERAL_REGS. That might be a missed optimisation, and probably due to both classes having the same number of allocatable registers. I'll look at that as a follow-on.) Thus LRA created two inheritance registers for r517, one (r673) that included the unallocatable x31 and another (r672) that didn't. The r672 references included the paradoxical subreg in insn 74 but the r673 ones didn't. LRA then allocated x30 to r673, which was a valid choice. Later LRA decided to "undo" the inheritance for insn 620, but because of the double inheritance, it got confused as to what the original situation was, and made insn 74 use the other inheritance register instead of r517: ********** Undoing inheritance #2: ********** Inherit 11 out of 12 (91.67%) Insn after restoring regs: 620: r572:DI=r517:DI REG_DEAD r517:DI Change reload insn: 74: r287:V2DI=r673:DI#0 <------------------- Insn after restoring regs: 939: r517:DI=r673:DI REG_DEAD r673:DI This might be a bug in itself: we should probably look through sets of other inheritance pseudos to find the "real" origin. Either way, at this point we had a situation in which r673 was used in an insn whose subreg was larger than the biggest_mode that r673 had when it was allocated. While x30 was valid for the original biggest_mode, it wasn't valid for this subreg use. The next attempt to constrain insn 74 was: Choosing alt 5 in insn 74: (0) ?w (1) r {*aarch64_simd_movv2di} Creating newreg=684, assigning class GENERAL_REGS to r684 74: r287:V2DI=r684:V2DI Inserting insn reload before: 951: r684:V2DI=r673:DI#0 where LRA reloaded the SUBREG rather than the SUBREG_REG. And it then cycled trying the same thing when reloading the reload (and the reload of the reload, etc.). What it should be doing here is reloading the SUBREG_REG instead. There's already code to cope with this case when the paradoxical subreg falls outside the class (which isn't true here, since r673 is POINTER_REGS and POINTER_REGS includes x31). But I think we should also test whether LRA is entitled to allocate the spanned registers. Not doing that seems like a bug regardless of the above missed optimisation and the mix-up undoing inheritance. 2018-05-30 Richard Sandiford <richard.sandiford@linaro.org> gcc/ * lra-constraints.c (simplify_operand_subreg): In the paradoxical case, check whether the outer register overlaps an unallocatable register, not just whether it fits the required class. gcc/testsuite/ * g++.dg/torture/aarch64-vect-init-1.C: New test. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@261531 138bc75d-0d04-0410-961f-82ee72b054a4

This patch fixes an LRA cycling problem on the attached testcase. The original insn was: (insn 74 72 76 8 (set (reg:V2DI 287 [ _166 ]) (subreg:V2DI (reg/v/f:DI 112 [ d ]) 0)) 1060 {*aarch64_simd_movv2di} (nil)) which IRA converted to: (insn 74 72 580 8 (set (reg:V2DI 287 [ _166 ]) (subreg:V2DI (reg/v/f:DI 517 [orig:112 d ] [112]) 0)) 1060 {*aarch64_simd_movv2di} (nil)) after creating loop allocnos. It happens that the ALLOCNO_WMODEs for both 112 and 517 were not set to V2DI due to another bug that I'll post a separate patch for, but we nevertheless got a valid allocation of register 1. LRA's first try at constraining the instruction gave: Choosing alt 5 in insn 74: (0) ?w (1) r {*aarch64_simd_movv2di} at which point all was good. But LRA later decided it needed to spill r517: Spill r517 after risky transformations so the next constraint attempt gave: Choosing alt 0 in insn 74: (0) =w (1) m {*aarch64_simd_movv2di} which was still good. Then during inheritance we had: Creating newreg=672 from oldreg=517, assigning class GENERAL_REGS to inheritance r672 Original reg change 517->672 (bb8): 74: r287:V2DI=r672:DI#0 Add inheritance<-original before: 939: r672:DI=r517:DI Inheritance reuse change 517->672 (bb8): 620: r572:DI=r672:DI REG_DEAD r672:DI Use smallest class of POINTER_REGS and GENERAL_REGS Creating newreg=673 from oldreg=517, assigning class POINTER_REGS to inheritance r673 Original reg change 517->673 (bb8): 936: r669:DI=r673:DI Add inheritance<-original before: 940: r673:DI=r517:DI ("Use smallest class of POINTER_REGS and GENERAL_REGS" ought to give GENERAL_REGS. That might be a missed optimisation, and probably due to both classes having the same number of allocatable registers. I'll look at that as a follow-on.) Thus LRA created two inheritance registers for r517, one (r673) that included the unallocatable x31 and another (r672) that didn't. The r672 references included the paradoxical subreg in insn 74 but the r673 ones didn't. LRA then allocated x30 to r673, which was a valid choice. Later LRA decided to "undo" the inheritance for insn 620, but because of the double inheritance, it got confused as to what the original situation was, and made insn 74 use the other inheritance register instead of r517: ********** Undoing inheritance gcc-mirror#2: ********** Inherit 11 out of 12 (91.67%) Insn after restoring regs: 620: r572:DI=r517:DI REG_DEAD r517:DI Change reload insn: 74: r287:V2DI=r673:DI#0 <------------------- Insn after restoring regs: 939: r517:DI=r673:DI REG_DEAD r673:DI This might be a bug in itself: we should probably look through sets of other inheritance pseudos to find the "real" origin. Either way, at this point we had a situation in which r673 was used in an insn whose subreg was larger than the biggest_mode that r673 had when it was allocated. While x30 was valid for the original biggest_mode, it wasn't valid for this subreg use. The next attempt to constrain insn 74 was: Choosing alt 5 in insn 74: (0) ?w (1) r {*aarch64_simd_movv2di} Creating newreg=684, assigning class GENERAL_REGS to r684 74: r287:V2DI=r684:V2DI Inserting insn reload before: 951: r684:V2DI=r673:DI#0 where LRA reloaded the SUBREG rather than the SUBREG_REG. And it then cycled trying the same thing when reloading the reload (and the reload of the reload, etc.). What it should be doing here is reloading the SUBREG_REG instead. There's already code to cope with this case when the paradoxical subreg falls outside the class (which isn't true here, since r673 is POINTER_REGS and POINTER_REGS includes x31). But I think we should also test whether LRA is entitled to allocate the spanned registers. Not doing that seems like a bug regardless of the above missed optimisation and the mix-up undoing inheritance. 2018-05-30 Richard Sandiford <richard.sandiford@linaro.org> gcc/ * lra-constraints.c (simplify_operand_subreg): In the paradoxical case, check whether the outer register overlaps an unallocatable register, not just whether it fits the required class. gcc/testsuite/ * g++.dg/torture/aarch64-vect-init-1.C: New test. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@261531 138bc75d-0d04-0410-961f-82ee72b054a4

This adds a 4th information level for the -gnatR output, where relevant compiler-generated types are listed in addition to the information already output by -gnatR3. For the following package P: package P is type Arr0 is array (Positive range <>) of Boolean; type Rec (D1 : Positive; D2 : Boolean) is record C1 : Integer; C2 : Arr0 (1 .. D1); case D2 is when False => C3 : Character; when True => C4 : String (1 .. 3); C5 : Float; end case; end record; type Arr1 is array (1 .. 8) of Rec (1, True); end P; the output generated by -gnatR4 must be: Representation information for unit P (spec) -------------------------------------------- for Arr0'Alignment use 1; for Arr0'Component_Size use 8; for Rec'Object_Size use 17179869344; for Rec'Value_Size use (if (gcc-mirror#2 != 0) then ((((#1 + 15) & -4) + 8) * 8) else ((((#1 + 15) & -4) + 1) * 8) end); for Rec'Alignment use 4; for Rec use record D1 at 0 range 0 .. 31; D2 at 4 range 0 .. 7; C1 at 8 range 0 .. 31; C2 at 12 range 0 .. ((#1 * 8)) - 1; C3 at ((#1 + 15) & -4) range 0 .. 7; C4 at ((#1 + 15) & -4) range 0 .. 23; C5 at (((#1 + 15) & -4) + 4) range 0 .. 31; end record; for Arr1'Size use 1536; for Arr1'Alignment use 4; for Arr1'Component_Size use 192; for Tarr1c'Size use 192; for Tarr1c'Alignment use 4; for Tarr1c use record D1 at 0 range 0 .. 31; D2 at 4 range 0 .. 7; C1 at 8 range 0 .. 31; C2 at 12 range 0 .. 7; C4 at 16 range 0 .. 23; C5 at 20 range 0 .. 31; end record; 2018-11-14 Eric Botcazou <ebotcazou@adacore.com> gcc/ada/ * doc/gnat_ugn/building_executable_programs_with_gnat.rst (-gnatR): Document new -gnatR4 level. * gnat_ugn.texi: Regenerate. * opt.ads (List_Representation_Info): Bump upper bound to 4. * repinfo.adb: Add with clause for GNAT.HTable. (Relevant_Entities_Size): New constant. (Entity_Header_Num): New type. (Entity_Hash): New function. (Relevant_Entities): New set implemented with GNAT.HTable. (List_Entities): Also list compiled-generated entities present in the Relevant_Entities set. Consider that the Component_Type of an array type is relevant. (List_Rep_Info): Reset Relevant_Entities for each unit. * switch-c.adb (Scan_Front_End_Switches): Add support for -gnatR4. * switch-m.adb (Normalize_Compiler_Switches): Likewise * usage.adb (Usage): Likewise. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@266131 138bc75d-0d04-0410-961f-82ee72b054a4

…. (PR target/88530) Commandline options on AArch64 don't get canonicalized into the smallest possible set before output to the assembler. This means that overlapping feature sets are emitted with superfluous parts. Normally this isn't an issue, but in the case of crypto we have retro-actively split it into aes and sha2. We need to emit only +crypto to the assembler so old assemblers continue to work. Because of how -mcpu=native and -march=native work they end up enabling all feature bits. Instead we need to get the smallest possible set, which would also fix the problem with older the assemblers and the retro-active split. The function that handles this is called quite often. It is called for any push/pop options or attribute that changes arch, cpu etc. In order to not make this search for the smallest set too expensive we sort the options based on the number of features (bits) they enable. This allows us to process the list linearly instead of quadratically (Once we have enabled a feature, we know that anything else that enables it can be ignored. By sorting we'll get the biggest groups first and thus the smallest combination of commandline flags). The Option handling structures have been extended to have a boolean to indicate whether the option is synthetic, with that I mean if the option flag itself enables a new feature. e.g. +crypto isn't an actual feature, it just enables other features, but others like +rdma enable multiple dependent features but is itself also a feature. There are two ways to solve this. 1) Either have the options that are feature bits also turn themselves on, e.g. change rdma to turn on FP, SIMD and RDMA as dependency bits. 2) Make a distinction between these two different type of features and have the framework handle it correctly. Even though it's more code I went for the second approach, as it's the one that'll be less fragile (people can't forget it) and gives the least surprises. Effectively this patch changes the following: The values before the => are the old compiler and after the => the new code. -march=armv8.2-a+crypto+sha2 => -march=armv8.2-a+crypto -march=armv8.2-a+sha2+aes => -march=armv8.2-a+crypto The remaining behaviors stay the same. gcc/ChangeLog: PR target/88530 * common/config/aarch64/aarch64-common.c (struct aarch64_option_extension): Add is_synthetic. (all_extensions): Use it. (TARGET_OPTION_INIT_STRUCT): Define hook. (struct gcc_targetm_common): Moved to end. (all_extensions_by_on): New. (opt_ext_cmp, typedef opt_ext): New. (aarch64_option_init_struct): New. (aarch64_contains_opt): New. (aarch64_get_extension_string_for_isa_flags): Output smallest set. * config/aarch64/aarch64-option-extensions.def (AARCH64_OPT_EXTENSION): Explicitly include AES and SHA2 in crypto. (fp, simd, crc, lse, fp16, rcpc, rdma, dotprod, aes, sha2, sha3, sm4, fp16fml, sve, profile, rng, memtag, sb, ssbs, predres): Set is_synthetic to false. (crypto): Set is_synthetic to true. * config/aarch64/driver-aarch64.c (AARCH64_OPT_EXTENSION): Add SYNTHETIC. gcc/testsuite/ChangeLog: PR target/88530 * gcc.target/aarch64/options_set_1.c: New test. * gcc.target/aarch64/options_set_2.c: New test. * gcc.target/aarch64/options_set_3.c: New test. * gcc.target/aarch64/options_set_4.c: New test. * gcc.target/aarch64/options_set_5.c: New test. * gcc.target/aarch64/options_set_6.c: New test. * gcc.target/aarch64/options_set_7.c: New test. * gcc.target/aarch64/options_set_8.c: New test. * gcc.target/aarch64/options_set_9.c: New test. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@269193 138bc75d-0d04-0410-961f-82ee72b054a4

Here during overload resolution we have two strictly viable ambiguous candidates #1 and #2, and two non-strictly viable candidates #3 and #4 which we hold on to ever since r14-6522. These latter candidates have an empty second arg conversion since the first arg conversion was deemed bad, and this trips up joust when called on #3 and #4 which assumes all arg conversions are there. We can fix this by making joust robust to empty arg conversions, but in this situation we shouldn't need to compare #3 and #4 at all given that we have a strictly viable candidate. To that end, this patch makes tourney shortcut considering non-strictly viable candidates upon encountering ambiguity between two strictly viable candidates (taking advantage of the fact that the candidates list is sorted according to viability via splice_viable). PR c++/115239 gcc/cp/ChangeLog: * call.cc (tourney): Don't consider a non-strictly viable candidate as the champ if there was ambiguity between two strictly viable candidates. gcc/testsuite/ChangeLog: * g++.dg/overload/error7.C: New test. Reviewed-by: Jason Merrill <jason@redhat.com>

Here during overload resolution we have two strictly viable ambiguous candidates #1 and #2, and two non-strictly viable candidates #3 and #4 which we hold on to ever since r14-6522. These latter candidates have an empty second arg conversion since the first arg conversion was deemed bad, and this trips up joust when called on #3 and #4 which assumes all arg conversions are there. We can fix this by making joust robust to empty arg conversions, but in this situation we shouldn't need to compare #3 and #4 at all given that we have a strictly viable candidate. To that end, this patch makes tourney shortcut considering non-strictly viable candidates upon encountering ambiguity between two strictly viable candidates (taking advantage of the fact that the candidates list is sorted according to viability via splice_viable). PR c++/115239 gcc/cp/ChangeLog: * call.cc (tourney): Don't consider a non-strictly viable candidate as the champ if there was ambiguity between two strictly viable candidates. gcc/testsuite/ChangeLog: * g++.dg/overload/error7.C: New test. Reviewed-by: Jason Merrill <jason@redhat.com> (cherry picked from commit 7fed7e9)

…o_debug_section [PR116614] cat abc.C #define A(n) struct T##n {} t##n; #define B(n) A(n##0) A(n##1) A(n##2) A(n##3) A(n##4) A(n##5) A(n##6) A(n##7) A(n##8) A(n##9) #define C(n) B(n##0) B(n##1) B(n##2) B(n##3) B(n##4) B(n##5) B(n##6) B(n##7) B(n##8) B(n##9) #define D(n) C(n##0) C(n##1) C(n##2) C(n##3) C(n##4) C(n##5) C(n##6) C(n##7) C(n##8) C(n##9) #define E(n) D(n##0) D(n##1) D(n##2) D(n##3) D(n##4) D(n##5) D(n##6) D(n##7) D(n##8) D(n##9) E(1) E(2) E(3) int main () { return 0; } ./xg++ -B ./ -o abc{.o,.C} -flto -flto-partition=1to1 -O2 -g -fdebug-types-section -c ./xgcc -B ./ -o abc{,.o} -flto -flto-partition=1to1 -O2 (not included in testsuite as it takes a while to compile) FAILs with lto-wrapper: fatal error: Too many copied sections: Operation not supported compilation terminated. /usr/bin/ld: error: lto-wrapper failed collect2: error: ld returned 1 exit status The following patch fixes that. Most of the 64K+ section support for reading and writing was already there years ago (and especially reading used quite often already) and a further bug fixed in it in the PR104617 fix. Yet, the fix isn't solely about removing the if (new_i - 1 >= SHN_LORESERVE) { *err = ENOTSUP; return "Too many copied sections"; } 5 lines, the missing part was that the function only handled reading of the .symtab_shndx section but not copying/updating of it. If the result has less than 64K-epsilon sections, that actually wasn't needed, but e.g. with -fdebug-types-section one can exceed that pretty easily (reported to us on WebKitGtk build on ppc64le). Updating the section is slightly more complicated, because it basically needs to be done in lock step with updating the .symtab section, if one doesn't need to use SHN_XINDEX in there, the section should (or should be updated to) contain SHN_UNDEF entry, otherwise needs to have whatever would be overwise stored but couldn't fit. But repeating due to that all the symtab decisions what to discard and how to rewrite it would be ugly. So, the patch instead emits the .symtab_shndx section (or sections) last and prepares the content during the .symtab processing and in a second pass when going just through .symtab_shndx sections just uses the saved content. 2024-09-07 Jakub Jelinek <jakub@redhat.com> PR lto/116614 * simple-object-elf.c (SHN_COMMON): Align comment with neighbouring comments. (SHN_HIRESERVE): Use uppercase hex digits instead of lowercase for consistency. (simple_object_elf_find_sections): Formatting fixes. (simple_object_elf_fetch_attributes): Likewise. (simple_object_elf_attributes_merge): Likewise. (simple_object_elf_start_write): Likewise. (simple_object_elf_write_ehdr): Likewise. (simple_object_elf_write_shdr): Likewise. (simple_object_elf_write_to_file): Likewise. (simple_object_elf_copy_lto_debug_section): Likewise. Don't fail for new_i - 1 >= SHN_LORESERVE, instead arrange in that case to copy over .symtab_shndx sections, though emit those last and compute their section content when processing associated .symtab sections. Handle simple_object_internal_read failure even in the .symtab_shndx reading case.

…o_debug_section [PR116614] cat abc.C #define A(n) struct T##n {} t##n; #define B(n) A(n##0) A(n##1) A(n##2) A(n##3) A(n##4) A(n##5) A(n##6) A(n##7) A(n##8) A(n##9) #define C(n) B(n##0) B(n##1) B(n##2) B(n##3) B(n##4) B(n##5) B(n##6) B(n##7) B(n##8) B(n##9) #define D(n) C(n##0) C(n##1) C(n##2) C(n##3) C(n##4) C(n##5) C(n##6) C(n##7) C(n##8) C(n##9) #define E(n) D(n##0) D(n##1) D(n##2) D(n##3) D(n##4) D(n##5) D(n##6) D(n##7) D(n##8) D(n##9) E(1) E(2) E(3) int main () { return 0; } ./xg++ -B ./ -o abc{.o,.C} -flto -flto-partition=1to1 -O2 -g -fdebug-types-section -c ./xgcc -B ./ -o abc{,.o} -flto -flto-partition=1to1 -O2 (not included in testsuite as it takes a while to compile) FAILs with lto-wrapper: fatal error: Too many copied sections: Operation not supported compilation terminated. /usr/bin/ld: error: lto-wrapper failed collect2: error: ld returned 1 exit status The following patch fixes that. Most of the 64K+ section support for reading and writing was already there years ago (and especially reading used quite often already) and a further bug fixed in it in the PR104617 fix. Yet, the fix isn't solely about removing the if (new_i - 1 >= SHN_LORESERVE) { *err = ENOTSUP; return "Too many copied sections"; } 5 lines, the missing part was that the function only handled reading of the .symtab_shndx section but not copying/updating of it. If the result has less than 64K-epsilon sections, that actually wasn't needed, but e.g. with -fdebug-types-section one can exceed that pretty easily (reported to us on WebKitGtk build on ppc64le). Updating the section is slightly more complicated, because it basically needs to be done in lock step with updating the .symtab section, if one doesn't need to use SHN_XINDEX in there, the section should (or should be updated to) contain SHN_UNDEF entry, otherwise needs to have whatever would be overwise stored but couldn't fit. But repeating due to that all the symtab decisions what to discard and how to rewrite it would be ugly. So, the patch instead emits the .symtab_shndx section (or sections) last and prepares the content during the .symtab processing and in a second pass when going just through .symtab_shndx sections just uses the saved content. 2024-09-07 Jakub Jelinek <jakub@redhat.com> PR lto/116614 * simple-object-elf.c (SHN_COMMON): Align comment with neighbouring comments. (SHN_HIRESERVE): Use uppercase hex digits instead of lowercase for consistency. (simple_object_elf_find_sections): Formatting fixes. (simple_object_elf_fetch_attributes): Likewise. (simple_object_elf_attributes_merge): Likewise. (simple_object_elf_start_write): Likewise. (simple_object_elf_write_ehdr): Likewise. (simple_object_elf_write_shdr): Likewise. (simple_object_elf_write_to_file): Likewise. (simple_object_elf_copy_lto_debug_section): Likewise. Don't fail for new_i - 1 >= SHN_LORESERVE, instead arrange in that case to copy over .symtab_shndx sections, though emit those last and compute their section content when processing associated .symtab sections. Handle simple_object_internal_read failure even in the .symtab_shndx reading case. (cherry picked from commit bb8dd09)

This is another case of load hoisting breaking UID order in the preheader, this time between two hoistings. The easiest way out is to do what we do for the main stmt - copy instead of move. PR tree-optimization/116902 PR tree-optimization/116842 * tree-vect-stmts.cc (sort_after_uid): Remove again. (hoist_defs_of_uses): Copy defs instead of hoisting them so we can zero their UID. (vectorizable_load): Separate analysis and transform call, do transform on the stmt copy. * g++.dg/torture/pr116902.C: New testcase.

Whenever C1 and C2 are integer constants, X is of a wrapping type, and cmp is a relational operator, the expression X +- C1 cmp C2 can be simplified in the following cases: (a) If cmp is <= and C2 -+ C1 == +INF(1), we can transform the initial comparison in the following way: X +- C1 <= C2 -INF <= X +- C1 <= C2 (add left hand side which holds for any X, C1) -INF -+ C1 <= X <= C2 -+ C1 (add -+C1 to all 3 expressions) -INF -+ C1 <= X <= +INF (due to (1)) -INF -+ C1 <= X (eliminate the right hand side since it holds for any X) (b) By analogy, if cmp if >= and C2 -+ C1 == -INF(1), use the following sequence of transformations: X +- C1 >= C2 +INF >= X +- C1 >= C2 (add left hand side which holds for any X, C1) +INF -+ C1 >= X >= C2 -+ C1 (add -+C1 to all 3 expressions) +INF -+ C1 >= X >= -INF (due to (1)) +INF -+ C1 >= X (eliminate the right hand side since it holds for any X) (c) The > and < cases are negations of (a) and (b), respectively. This transformation allows to occasionally save add / sub instructions, for instance the expression 3 + (uint32_t)f() < 2 compiles to cmn w0, #4 cset w0, ls instead of add w0, w0, 3 cmp w0, 2 cset w0, ls on aarch64. Testcases that go together with this patch have been split into two separate files, one containing testcases for unsigned variables and the other for wrapping signed ones (and thus compiled with -fwrapv). Additionally, one aarch64 test has been adjusted since the patch has caused the generated code to change from cmn w0, #2 csinc w0, w1, wzr, cc (x < -2) to cmn w0, #3 csinc w0, w1, wzr, cs (x <= -3) This patch has been bootstrapped and regtested on aarch64, x86_64, and i386, and additionally regtested on riscv32. gcc/ChangeLog: PR tree-optimization/116024 * match.pd: New transformation around integer comparison. gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/pr116024-2.c: New test. * gcc.dg/tree-ssa/pr116024-2-fwrapv.c: Ditto. * gcc.target/aarch64/gtu_to_ltu_cmp_1.c: Adjust.

PR jit/117275 reports various jit test failures seen on powerpc64le-unknown-linux-gnu due to hitting this assertion in varasm.cc on the 2nd compilation in a process: #2 0x00007ffff63e67d0 in assemble_external_libcall (fun=0x7ffff2a4b1d8) at ../../src/gcc/varasm.cc:2650 2650 gcc_assert (!pending_assemble_externals_processed); (gdb) p pending_assemble_externals_processed $1 = true We're not properly resetting state in varasm.cc after a compile for libgccjit. Fixed thusly. gcc/ChangeLog: PR jit/117275 * toplev.cc (toplev::finalize): Call varasm_cc_finalize. * varasm.cc (varasm_cc_finalize): New. * varasm.h (varasm_cc_finalize): New decl. Signed-off-by: David Malcolm <dmalcolm@redhat.com>

PR jit/117275 reports various jit test failures seen on powerpc64le-unknown-linux-gnu due to hitting this assertion in varasm.cc on the 2nd compilation in a process: #2 0x00007ffff63e67d0 in assemble_external_libcall (fun=0x7ffff2a4b1d8) at ../../src/gcc/varasm.cc:2650 2650 gcc_assert (!pending_assemble_externals_processed); (gdb) p pending_assemble_externals_processed $1 = true We're not properly resetting state in varasm.cc after a compile for libgccjit. Fixed thusly. gcc/ChangeLog: PR jit/117275 * toplev.cc (toplev::finalize): Call varasm_cc_finalize. * varasm.cc (varasm_cc_finalize): New. * varasm.h (varasm_cc_finalize): New decl. Signed-off-by: David Malcolm <dmalcolm@redhat.com> (cherry picked from commit 779c039) Signed-off-by: David Malcolm <dmalcolm@redhat.com>

We currently crash upon the following invalid code (notice the "void void**" parameter) === cut here === using size_t = decltype(sizeof(int)); void *operator new(size_t, void void **p) noexcept { return p; } int x; void f() { int y; new (&y) int(x); } === cut here === The problem is that in this case, we end up with a NULL_TREE parameter list for the new operator because of the error, and (1) coerce_new_type wrongly complains about the first parameter type not being size_t, (2) std_placement_new_fn_p blindly accesses the parameter list, hence a crash. This patch does NOT address #1 since we can't easily distinguish between a new operator declaration without parameters from one with erroneous parameters (and it's not worth the risk to refactor and break things for an error recovery issue) hence a dg-bogus in new52.C, but it does address #2 and the ICE by simply checking the first parameter against NULL_TREE. It also adds a new testcase checking that we complain about new operators with no or invalid first parameters, since we did not have any. PR c++/117101 gcc/cp/ChangeLog: * init.cc (std_placement_new_fn_p): Check first_arg against NULL_TREE. gcc/testsuite/ChangeLog: * g++.dg/init/new52.C: New test. * g++.dg/init/new53.C: New test.

The second source register of insn "*extzvsi-1bit_addsubx" cannot be the same as the destination register, because that register will be overwritten with an intermediate value after insn splitting. /* example gcc-mirror#1 */ int test1(int b, int a) { return ((a & 1024) ? 4 : 0) + b; } ;; result gcc-mirror#1 (incorrect) test1: extui a2, a3, 10, 1 ;; overwrites A2 before used addx4 a2, a2, a2 ret.n This patch fixes that. ;; result gcc-mirror#1 (correct) test1: extui a3, a3, 10, 1 ;; uses A3 and then overwrites addx4 a2, a3, a2 ret.n However, it should be noted that the first source register can be the same as the destination without any problems. /* example gcc-mirror#2 */ int test2(int a, int b) { return ((a & 1024) ? 4 : 0) + b; } ;; result (correct) test2: extui a2, a2, 10, 1 ;; uses A2 and then overwrites addx4 a2, a2, a3 ret.n gcc/ChangeLog: * config/xtensa/xtensa.md (*extzvsi-1bit_addsubx): Add '&' to the destination register constraint to indicate that it is 'earlyclobber', append '0' to the first source register constraint to indicate that it can be the same as the destination register, and change the split condition from 1 to reload_completed so that the insn will be split only after RA in order to obtain allocated registers that satisfy the above constraints.

…R117557] The testcase #include <stdint.h> #include <string.h> #define N 8 #define L 8 void f(const uint8_t * restrict seq1, const uint8_t *idx, uint8_t *seq_out) { for (int i = 0; i < L; ++i) { uint8_t h = idx[i]; memcpy((void *)&seq_out[i * N], (const void *)&seq1[h * N / 2], N / 2); } } compiled at -O3 -mcpu=neoverse-n1+sve miscompiles to: ld1w z31.s, p3/z, [x23, z29.s, sxtw] ld1w z29.s, p7/z, [x23, z30.s, sxtw] st1w z29.s, p7, [x24, z12.s, sxtw] st1w z31.s, p7, [x24, z12.s, sxtw] rather than ld1w z31.s, p3/z, [x23, z29.s, sxtw] ld1w z29.s, p7/z, [x23, z30.s, sxtw] st1w z29.s, p7, [x24, z12.s, sxtw] addvl x3, x24, #2 st1w z31.s, p3, [x3, z12.s, sxtw] Where two things go wrong, the wrong mask is used and the address pointers to the stores are wrong. This issue is happening because the codegen loop in vectorizable_store is a nested loop where in the outer loop we iterate over ncopies and in the inner loop we loop over vec_num. For SLP ncopies == 1 and vec_num == SLP_NUM_STMS, but the loop mask is determined by only the outerloop index and the pointer address is only updated in the outer loop. As such for SLP we always use the same predicate and the same memory location. This patch flattens the two loops and instead iterates over ncopies * vec_num and simplified the indexing. This does not fully fix the gcc_r miscompile error in SPECCPU 2017 as the error moves somewhere else. I will look at that next but fixes some other libraries that also started failing. gcc/ChangeLog: PR tree-optimization/117557 * tree-vect-stmts.cc (vectorizable_store): Flatten the ncopies and vec_num loops. gcc/testsuite/ChangeLog: PR tree-optimization/117557 * gcc.target/aarch64/pr117557.c: New test.

This PR reports a missed optimization. When we have: Str str{"Test"}; callback(str); as in the test, we're able to evaluate the Str::Str() call at compile time. But when we have: callback(Str{"Test"}); we are not. With this patch (in fact, it's Patrick's patch with a little tweak), we turn callback (TARGET_EXPR <D.2890, <<< Unknown tree: aggr_init_expr 5 __ct_comp D.2890 (struct Str *) <<< Unknown tree: void_cst >>> (const char *) "Test" >>>>) into callback (TARGET_EXPR <D.2890, {.str=(const char *) "Test", .length=4}>) I explored the idea of calling maybe_constant_value for the whole TARGET_EXPR in cp_fold. That has three problems: - we can't always elide a TARGET_EXPR, so we'd have to make sure the result is also a TARGET_EXPR; - the resulting TARGET_EXPR must have the same flags, otherwise Bad Things happen; - getting a new slot is also problematic. I've seen a test where we had "TARGET_EXPR<D.2680, ...>, D.2680", and folding the whole TARGET_EXPR would get us "TARGET_EXPR<D.2681, ...>", but since we don't see the outer D.2680, we can't replace it with D.2681, and things break. With this patch, two tree-ssa tests regressed: pr78687.C and pr90883.C. FAIL: g++.dg/tree-ssa/pr90883.C scan-tree-dump dse1 "Deleted redundant store: .*.a = {}" is easy. Previously, we would call C::C, so .gimple has: D.2590 = {}; C::C (&D.2590); D.2597 = D.2590; return D.2597; Then .einline inlines the C::C call: D.2590 = {}; D.2590.a = {}; // #1 D.2590.b = 0; // #2 D.2597 = D.2590; D.2590 ={v} {CLOBBER(eos)}; return D.2597; then #2 is removed in .fre1, and #1 is removed in .dse1. So the test passes. But with the patch, .gimple won't have that C::C call, so the IL is of course going to look different. The .optimized dump looks the same though so there's no problem. pr78687.C is XFAILed because the test passes with r15-5746 but not with r15-5747 as well. I opened <https://gcc.gnu.org/PR117971>. PR c++/116416 gcc/cp/ChangeLog: * cp-gimplify.cc (cp_fold_r) <case TARGET_EXPR>: Try to fold TARGET_EXPR_INITIAL and replace it with the folded result if it's TREE_CONSTANT. gcc/testsuite/ChangeLog: * g++.dg/analyzer/pr97116.C: Adjust dg-message. * g++.dg/tree-ssa/pr78687.C: Add XFAIL. * g++.dg/tree-ssa/pr90883.C: Adjust dg-final. * g++.dg/cpp0x/constexpr-prvalue1.C: New test. * g++.dg/cpp1y/constexpr-prvalue1.C: New test. Co-authored-by: Patrick Palka <ppalka@redhat.com> Reviewed-by: Jason Merrill <jason@redhat.com>

The ASRD instruction on SVE performs an arithmetic shift right by an immediate for divide. This patch enables the use of ASRD with Neon modes. For example: int in[N], out[N]; void foo (void) { for (int i = 0; i < N; i++) out[i] = in[i] / 4; } compiles to: ldr q31, [x1, x0] cmlt v30.16b, v31.16b, #0 and z30.b, z30.b, 3 add v30.16b, v30.16b, v31.16b sshr v30.16b, v30.16b, 2 str q30, [x0, x2] add x0, x0, 16 cmp x0, 1024 but can just be: ldp q30, q31, [x0], 32 asrd z31.b, p7/m, z31.b, #2 asrd z30.b, p7/m, z30.b, #2 stp q30, q31, [x1], 32 cmp x0, x2 This patch also adds the following overload: aarch64_ptrue_reg (machine_mode pred_mode, machine_mode data_mode) Depending on the data mode, the function returns a predicate with the appropriate bits set. The patch was bootstrapped and regtested on aarch64-linux-gnu, no regression. gcc/ChangeLog: * config/aarch64/aarch64.cc (aarch64_ptrue_reg): New overload. * config/aarch64/aarch64-protos.h (aarch64_ptrue_reg): Likewise. * config/aarch64/aarch64-sve.md: Extended sdiv_pow2<mode>3 and *sdiv_pow2<mode>3 to support Neon modes. gcc/testsuite/ChangeLog: * gcc.target/aarch64/sve/sve-asrd.c: New test. Co-authored-by: Richard Sandiford <richard.sandiford@arm.com> Signed-off-by: Soumya AR <soumyaa@nvidia.com>

This crash started with my r12-7803 but I believe the problem lies elsewhere. build_vec_init has cleanup_flags whose purpose is -- if I grok this correctly -- to avoid destructing an object multiple times. Let's say we are initializing an array of A. Then we might end up in a scenario similar to initlist-eh1.C: try { call A::A in a loop // #0 try { call a fn using the array } finally { // #1 call A::~A in a loop } } catch { // #2 call A::~A in a loop } cleanup_flags makes us emit a statement like D.3048 = 2; at #0 to disable performing the cleanup at #2, since #1 will take care of the destruction of the array. But if we are not emitting the loop because we can use a constant initializer (and use a single { a, b, ...}), we shouldn't generate the statement resetting the iterator to its initial value. Otherwise we crash in gimplify_var_or_parm_decl because it gets the stray decl D.3048. PR c++/117985 gcc/cp/ChangeLog: * init.cc (build_vec_init): Pop CLEANUP_FLAGS if we're not generating the loop. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/initlist-array23.C: New test. * g++.dg/cpp0x/initlist-array24.C: New test.

This patch removes the AARCH64_EXTRA_TUNE_USE_NEW_VECTOR_COSTS tunable and use_new_vector_costs entry in aarch64-tuning-flags.def and makes the AARCH64_EXTRA_TUNE_USE_NEW_VECTOR_COSTS paths in the backend the default. To that end, the function aarch64_use_new_vector_costs_p and its uses were removed. To prevent costing vec_to_scalar operations with 0, as described in https://gcc.gnu.org/pipermail/gcc-patches/2024-October/665481.html, we adjusted vectorizable_store such that the variable n_adjacent_stores also covers vec_to_scalar operations. This way vec_to_scalar operations are not costed individually, but as a group. As suggested by Richard Sandiford, the "known_ne" in the multilane-check was replaced by "maybe_ne" in order to treat nunits==1+1X as a vector rather than a scalar. Two tests were adjusted due to changes in codegen. In both cases, the old code performed loop unrolling once, but the new code does not: Example from gcc.target/aarch64/sve/strided_load_2.c (compiled with -O2 -ftree-vectorize -march=armv8.2-a+sve -mtune=generic -moverride=tune=none): f_int64_t_32: cbz w3, .L92 mov x4, 0 uxtw x3, w3 + cntd x5 + whilelo p7.d, xzr, x3 + mov z29.s, w5 mov z31.s, w2 - whilelo p6.d, xzr, x3 - mov x2, x3 - index z30.s, #0, #1 - uqdecd x2 - ptrue p5.b, all - whilelo p7.d, xzr, x2 + index z30.d, #0, #1 + ptrue p6.b, all .p2align 3,,7 .L94: - ld1d z27.d, p7/z, [x0, #1, mul vl] - ld1d z28.d, p6/z, [x0] - movprfx z29, z31 - mul z29.s, p5/m, z29.s, z30.s - incw x4 - uunpklo z0.d, z29.s - uunpkhi z29.d, z29.s - ld1d z25.d, p6/z, [x1, z0.d, lsl 3] - ld1d z26.d, p7/z, [x1, z29.d, lsl 3] - add z25.d, z28.d, z25.d + ld1d z27.d, p7/z, [x0, x4, lsl 3] + movprfx z28, z31 + mul z28.s, p6/m, z28.s, z30.s + ld1d z26.d, p7/z, [x1, z28.d, uxtw 3] add z26.d, z27.d, z26.d - st1d z26.d, p7, [x0, #1, mul vl] - whilelo p7.d, x4, x2 - st1d z25.d, p6, [x0] - incw z30.s - incb x0, all, mul #2 - whilelo p6.d, x4, x3 + st1d z26.d, p7, [x0, x4, lsl 3] + add z30.s, z30.s, z29.s + incd x4 + whilelo p7.d, x4, x3 b.any .L94 .L92: ret Example from gcc.target/aarch64/sve/strided_store_2.c (compiled with -O2 -ftree-vectorize -march=armv8.2-a+sve -mtune=generic -moverride=tune=none): f_int64_t_32: cbz w3, .L84 - addvl x5, x1, #1 mov x4, 0 uxtw x3, w3 - mov z31.s, w2 + cntd x5 whilelo p7.d, xzr, x3 - mov x2, x3 - index z30.s, #0, #1 - uqdecd x2 - ptrue p5.b, all - whilelo p6.d, xzr, x2 + mov z29.s, w5 + mov z31.s, w2 + index z30.d, #0, #1 + ptrue p6.b, all .p2align 3,,7 .L86: - ld1d z28.d, p7/z, [x1, x4, lsl 3] - ld1d z27.d, p6/z, [x5, x4, lsl 3] - movprfx z29, z30 - mul z29.s, p5/m, z29.s, z31.s - add z28.d, z28.d, #1 - uunpklo z26.d, z29.s - st1d z28.d, p7, [x0, z26.d, lsl 3] - incw x4 - uunpkhi z29.d, z29.s + ld1d z27.d, p7/z, [x1, x4, lsl 3] + movprfx z28, z30 + mul z28.s, p6/m, z28.s, z31.s add z27.d, z27.d, #1 - whilelo p6.d, x4, x2 - st1d z27.d, p7, [x0, z29.d, lsl 3] - incw z30.s + st1d z27.d, p7, [x0, z28.d, uxtw 3] + incd x4 + add z30.s, z30.s, z29.s whilelo p7.d, x4, x3 b.any .L86 .L84: ret The patch was bootstrapped and tested on aarch64-linux-gnu, no regression. OK for mainline? Signed-off-by: Jennifer Schmitz <jschmitz@nvidia.com> gcc/ * tree-vect-stmts.cc (vectorizable_store): Extend the use of n_adjacent_stores to also cover vec_to_scalar operations. * config/aarch64/aarch64-tuning-flags.def: Remove use_new_vector_costs as tuning option. * config/aarch64/aarch64.cc (aarch64_use_new_vector_costs_p): Remove. (aarch64_vector_costs::add_stmt_cost): Remove use of aarch64_use_new_vector_costs_p. (aarch64_vector_costs::finish_cost): Remove use of aarch64_use_new_vector_costs_p. * config/aarch64/tuning_models/cortexx925.h: Remove AARCH64_EXTRA_TUNE_USE_NEW_VECTOR_COSTS. * config/aarch64/tuning_models/fujitsu_monaka.h: Likewise. * config/aarch64/tuning_models/generic_armv8_a.h: Likewise. * config/aarch64/tuning_models/generic_armv9_a.h: Likewise. * config/aarch64/tuning_models/neoverse512tvb.h: Likewise. * config/aarch64/tuning_models/neoversen2.h: Likewise. * config/aarch64/tuning_models/neoversen3.h: Likewise. * config/aarch64/tuning_models/neoversev1.h: Likewise. * config/aarch64/tuning_models/neoversev2.h: Likewise. * config/aarch64/tuning_models/neoversev3.h: Likewise. * config/aarch64/tuning_models/neoversev3ae.h: Likewise. gcc/testsuite/ * gcc.target/aarch64/sve/strided_load_2.c: Adjust expected outcome. * gcc.target/aarch64/sve/strided_store_2.c: Likewise.

This crash started with my r12-7803 but I believe the problem lies elsewhere. build_vec_init has cleanup_flags whose purpose is -- if I grok this correctly -- to avoid destructing an object multiple times. Let's say we are initializing an array of A. Then we might end up in a scenario similar to initlist-eh1.C: try { call A::A in a loop // #0 try { call a fn using the array } finally { // #1 call A::~A in a loop } } catch { // #2 call A::~A in a loop } cleanup_flags makes us emit a statement like D.3048 = 2; at #0 to disable performing the cleanup at #2, since #1 will take care of the destruction of the array. But if we are not emitting the loop because we can use a constant initializer (and use a single { a, b, ...}), we shouldn't generate the statement resetting the iterator to its initial value. Otherwise we crash in gimplify_var_or_parm_decl because it gets the stray decl D.3048. PR c++/117985 gcc/cp/ChangeLog: * init.cc (build_vec_init): Pop CLEANUP_FLAGS if we're not generating the loop. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/initlist-array23.C: New test. * g++.dg/cpp0x/initlist-array24.C: New test. (cherry picked from commit 40e5636)

We evaluate constexpr functions on the original, pre-genericization bodies. That means that the function body we're evaluating will not have gone through cp_genericize_r's "Map block scope extern declarations to visible declarations with the same name and type in outer scopes if any". Here: constexpr bool bar() { return true; } // #1 constexpr bool foo() { constexpr bool bar(void); // #2 return bar(); } it means that we: 1) register_constexpr_fundef (#1) 2) cp_genericize (#1) nothing interesting happens 3) register_constexpr_fundef (foo) does copy_fn, so we have two copies of the BIND_EXPR 4) cp_genericize (foo) this remaps #2 to #1, but only on one copy of the BIND_EXPR 5) retrieve_constexpr_fundef (foo) we find it, no problem 6) retrieve_constexpr_fundef (#2) and here #2 isn't found in constexpr_fundef_table, because we're working on the BIND_EXPR copy where #2 wasn't mapped to #1 so we fail. We've only registered #1. It should work to use DECL_LOCAL_DECL_ALIAS (which used to be extern_decl_map). We evaluate constexpr functions on pre-cp_fold bodies to avoid diagnostic problems, but the remapping I'm proposing should not interfere with diagnostics. This is not a problem for a global scope redeclaration; there we go through duplicate_decls which keeps the DECL_UID: DECL_UID (olddecl) = olddecl_uid; and DECL_UID is what constexpr_fundef_hasher::hash uses. PR c++/111132 gcc/cp/ChangeLog: * constexpr.cc (get_function_named_in_call): Use cp_get_fndecl_from_callee. * cvt.cc (cp_get_fndecl_from_callee): If there's a DECL_LOCAL_DECL_ALIAS, use it. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/constexpr-redeclaration3.C: New test. * g++.dg/cpp0x/constexpr-redeclaration4.C: New test. (cherry picked from commit 8c90638)

This crash started with my r12-7803 but I believe the problem lies elsewhere. build_vec_init has cleanup_flags whose purpose is -- if I grok this correctly -- to avoid destructing an object multiple times. Let's say we are initializing an array of A. Then we might end up in a scenario similar to initlist-eh1.C: try { call A::A in a loop // #0 try { call a fn using the array } finally { // #1 call A::~A in a loop } } catch { // #2 call A::~A in a loop } cleanup_flags makes us emit a statement like D.3048 = 2; at #0 to disable performing the cleanup at #2, since #1 will take care of the destruction of the array. But if we are not emitting the loop because we can use a constant initializer (and use a single { a, b, ...}), we shouldn't generate the statement resetting the iterator to its initial value. Otherwise we crash in gimplify_var_or_parm_decl because it gets the stray decl D.3048. PR c++/117985 gcc/cp/ChangeLog: * init.cc (build_vec_init): Pop CLEANUP_FLAGS if we're not generating the loop. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/initlist-array23.C: New test. * g++.dg/cpp0x/initlist-array24.C: New test. (cherry picked from commit 40e5636)

…ns [PR114292] We currently ICE upon the following valid (under -Wno-vla) code === cut here === void f(int c) { constexpr int r = 4; [&](auto) { int t[r * c]; }(0); } === cut here === When parsing the lambda body, and more specifically the multiplication, we mark the lambda as LAMBDA_EXPR_CAPTURE_OPTIMIZED, which indicates to prune_lambda_captures that it might be possible to optimize out some captures. The problem is that prune_lambda_captures then misses the use of the r capture (because neither walk_tree_1 nor cp_walk_subtrees walks the dimensions of array types - here "r * c"), hence believes the capture can be pruned... and we trip on an assert when instantiating the lambda. This patch changes cp_walk_subtrees so that (1) when walking a DECL_EXPR, it also walks the DECL's type, and (2) when walking an INTEGER_TYPE, it also walks its TYPE_{MIN,MAX}_VALUE. Note that #2 makes a <case INTEGER_TYPE> redundant in for_each_template_parm_r, and removes it. PR c++/114292 gcc/cp/ChangeLog: * pt.cc (for_each_template_parm_r) <INTEGER_TYPE>: Remove case now handled by cp_walk_subtrees. * tree.cc (cp_walk_subtrees): Walk the type of DECL_EXPR declarations, as well as the TYPE_{MIN,MAX}_VALUE of INTEGER_TYPEs. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/lambda-ice4.C: New test.

We've been miscompiling the following since r0-51314-gd6b4ea8592e338 (I did not go compile something that old, and identified this change via git blame, so might be wrong) === cut here === struct Foo { int x; }; Foo& get (Foo &v) { return v; } void bar () { Foo v; v.x = 1; (true ? get (v) : get (v)).*(&Foo::x) = 2; // v.x still equals 1 here... } === cut here === The problem lies in build_m_component_ref, that computes the address of the COND_EXPR using build_address to build the representation of (true ? get (v) : get (v)).*(&Foo::x); and gets something like &(true ? get (v) : get (v)) // #1 instead of (true ? &get (v) : &get (v)) // #2 and the write does not go where want it to, hence the miscompile. This patch replaces the call to build_address by a call to cp_build_addr_expr, which gives #2, that is properly handled. PR c++/114525 gcc/cp/ChangeLog: * typeck2.cc (build_m_component_ref): Call cp_build_addr_expr instead of build_address. gcc/testsuite/ChangeLog: * g++.dg/expr/cond18.C: New test.

Here we instantiate the lambda three times in producing A<0>::f: 1) in tsubst_function_type, substituting the type of A<>::f 2) in tsubst_function_decl, substituting the parameters of A<>::f 3) in regenerate_decl_from_template when instantiating A<>::f The first one gets thrown away by maybe_rebuild_function_decl_type. Before r15-7202, we happily built all of them and mangled the result wrongly as lambda #3. After r15-7202, we try to mangle #3 as #1, which breaks because #1 is already mangled as #1. This patch avoids building #3 by suppressing regenerate_decl_from_template if the template signature includes a lambda, fixing the ICE. We now mangle the lambda as #2, which is still wrong. Addressing that should involve not calling tsubst_function_type from tsubst_function_decl, and building the type from the parms types in the first place rather than fixing it up in maybe_rebuild_function_decl_type. PR c++/119401 gcc/cp/ChangeLog: * pt.cc (regenerate_decl_from_template): Don't regenerate if the signature involves a lambda. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/lambda-targ11.C: New test.

We've been miscompiling the following since r0-51314-gd6b4ea8592e338 (I did not go compile something that old, and identified this change via git blame, so might be wrong) === cut here === struct Foo { int x; }; Foo& get (Foo &v) { return v; } void bar () { Foo v; v.x = 1; (true ? get (v) : get (v)).*(&Foo::x) = 2; // v.x still equals 1 here... } === cut here === The problem lies in build_m_component_ref, that computes the address of the COND_EXPR using build_address to build the representation of (true ? get (v) : get (v)).*(&Foo::x); and gets something like &(true ? get (v) : get (v)) // gcc-mirror#1 instead of (true ? &get (v) : &get (v)) // gcc-mirror#2 and the write does not go where want it to, hence the miscompile. This patch replaces the call to build_address by a call to cp_build_addr_expr, which gives gcc-mirror#2, that is properly handled. PR c++/114525 gcc/cp/ChangeLog: * typeck2.cc (build_m_component_ref): Call cp_build_addr_expr instead of build_address. gcc/testsuite/ChangeLog: * g++.dg/expr/cond18.C: New test.

Here we instantiate the lambda three times in producing A<0>::f: 1) in tsubst_function_type, substituting the type of A<>::f 2) in tsubst_function_decl, substituting the parameters of A<>::f 3) in regenerate_decl_from_template when instantiating A<>::f The first one gets thrown away by maybe_rebuild_function_decl_type. Before r15-7202, we happily built all of them and mangled the result wrongly as lambda gcc-mirror#3. After r15-7202, we try to mangle gcc-mirror#3 as gcc-mirror#1, which breaks because gcc-mirror#1 is already mangled as gcc-mirror#1. This patch avoids building gcc-mirror#3 by suppressing regenerate_decl_from_template if the template signature includes a lambda, fixing the ICE. We now mangle the lambda as gcc-mirror#2, which is still wrong. Addressing that should involve not calling tsubst_function_type from tsubst_function_decl, and building the type from the parms types in the first place rather than fixing it up in maybe_rebuild_function_decl_type. PR c++/119401 gcc/cp/ChangeLog: * pt.cc (regenerate_decl_from_template): Don't regenerate if the signature involves a lambda. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/lambda-targ11.C: New test.

We've been miscompiling the following since r0-51314-gd6b4ea8592e338 (I did not go compile something that old, and identified this change via git blame, so might be wrong) === cut here === struct Foo { int x; }; Foo& get (Foo &v) { return v; } void bar () { Foo v; v.x = 1; (true ? get (v) : get (v)).*(&Foo::x) = 2; // v.x still equals 1 here... } === cut here === The problem lies in build_m_component_ref, that computes the address of the COND_EXPR using build_address to build the representation of (true ? get (v) : get (v)).*(&Foo::x); and gets something like &(true ? get (v) : get (v)) // #1 instead of (true ? &get (v) : &get (v)) // #2 and the write does not go where want it to, hence the miscompile. This patch replaces the call to build_address by a call to cp_build_addr_expr, which gives #2, that is properly handled. PR c++/114525 gcc/cp/ChangeLog: * typeck2.cc (build_m_component_ref): Call cp_build_addr_expr instead of build_address. gcc/testsuite/ChangeLog: * g++.dg/expr/cond18.C: New test. (cherry picked from commit 35ce9af)

The second source register of insn "*extzvsi-1bit_addsubx" cannot be the same as the destination register, because that register will be overwritten with an intermediate value after insn splitting. /* example espressif#1 */ int test1(int b, int a) { return ((a & 1024) ? 4 : 0) + b; } ;; result espressif#1 (incorrect) test1: extui a2, a3, 10, 1 ;; overwrites A2 before used addx4 a2, a2, a2 ret.n This patch fixes that. ;; result espressif#1 (correct) test1: extui a3, a3, 10, 1 ;; uses A3 and then overwrites addx4 a2, a3, a2 ret.n However, it should be noted that the first source register can be the same as the destination without any problems. /* example gcc-mirror#2 */ int test2(int a, int b) { return ((a & 1024) ? 4 : 0) + b; } ;; result (correct) test2: extui a2, a2, 10, 1 ;; uses A2 and then overwrites addx4 a2, a2, a3 ret.n gcc/ChangeLog: * config/xtensa/xtensa.md (*extzvsi-1bit_addsubx): Add '&' to the destination register constraint to indicate that it is 'earlyclobber', append '0' to the first source register constraint to indicate that it can be the same as the destination register, and change the split condition from 1 to reload_completed so that the insn will be split only after RA in order to obtain allocated registers that satisfy the above constraints.

This patch adds a new param vect-scalar-cost-multiplier to scale the scalar costing during vectorization. If the cost is set high enough and when using the dynamic cost model it has the effect of effectively disabling the costing vs scalar and assumes all vectorization to be profitable. This is similar to using the unlimited cost model, but unlike unlimited it does not fully disable the vector cost model. That means that we still perform comparisons between vector modes. And it means it also still does costing for alias analysis. As an example, the following: void foo (char *restrict a, int *restrict b, int *restrict c, int *restrict d, int stride) { if (stride <= 1) return; for (int i = 0; i < 3; i++) { int res = c[i]; int t = b[i * stride]; if (a[i] != 0) res = t * d[i]; c[i] = res; } } compiled with -O3 -march=armv8-a+sve -fvect-cost-model=dynamic fails to vectorize as it assumes scalar would be faster, and with -fvect-cost-model=unlimited it picks a vector type that's so big that the large sequence generated is working on mostly inactive lanes: ... and p3.b, p3/z, p4.b, p4.b whilelo p0.s, wzr, w7 ld1w z23.s, p3/z, [x3, #3, mul vl] ld1w z28.s, p0/z, [x5, z31.s, sxtw 2] add x0, x5, x0 punpklo p6.h, p6.b ld1w z27.s, p4/z, [x0, z31.s, sxtw 2] and p6.b, p6/z, p0.b, p0.b punpklo p4.h, p7.b ld1w z24.s, p6/z, [x3, #2, mul vl] and p4.b, p4/z, p2.b, p2.b uqdecw w6 ld1w z26.s, p4/z, [x3] whilelo p1.s, wzr, w6 mul z27.s, p5/m, z27.s, z23.s ld1w z29.s, p1/z, [x4, z31.s, sxtw 2] punpkhi p7.h, p7.b mul z24.s, p5/m, z24.s, z28.s and p7.b, p7/z, p1.b, p1.b mul z26.s, p5/m, z26.s, z30.s ld1w z25.s, p7/z, [x3, #1, mul vl] st1w z27.s, p3, [x2, #3, mul vl] mul z25.s, p5/m, z25.s, z29.s st1w z24.s, p6, [x2, #2, mul vl] st1w z25.s, p7, [x2, #1, mul vl] st1w z26.s, p4, [x2] ... With -fvect-cost-model=dynamic --param vect-scalar-cost-multiplier=200 you get more reasonable code: foo: cmp w4, 1 ble .L1 ptrue p7.s, vl3 index z0.s, #0, w4 ld1b z29.s, p7/z, [x0] ld1w z30.s, p7/z, [x1, z0.s, sxtw 2] ptrue p6.b, all cmpne p7.b, p7/z, z29.b, #0 ld1w z31.s, p7/z, [x3] mul z31.s, p6/m, z31.s, z30.s st1w z31.s, p7, [x2] .L1: ret This model has been useful internally for performance exploration and cost-model validation. It allows us to force realistic vectorization overriding the cost model to be able to tell whether it's correct wrt to profitability. gcc/ChangeLog: * params.opt (vect-scalar-cost-multiplier): New. * tree-vect-loop.cc (vect_estimate_min_profitable_iters): Use it. * doc/invoke.texi (vect-scalar-cost-multiplier): Document it. gcc/testsuite/ChangeLog: * gcc.target/aarch64/sve/cost_model_16.c: New test.

…o_debug_section [PR116614] cat abc.C #define A(n) struct T##n {} t##n; #define B(n) A(n##0) A(n##1) A(n##2) A(n##3) A(n##4) A(n##5) A(n##6) A(n##7) A(n##8) A(n##9) #define C(n) B(n##0) B(n##1) B(n##2) B(n##3) B(n##4) B(n##5) B(n##6) B(n##7) B(n##8) B(n##9) #define D(n) C(n##0) C(n##1) C(n##2) C(n##3) C(n##4) C(n##5) C(n##6) C(n##7) C(n##8) C(n##9) #define E(n) D(n##0) D(n##1) D(n##2) D(n##3) D(n##4) D(n##5) D(n##6) D(n##7) D(n##8) D(n##9) E(1) E(2) E(3) int main () { return 0; } ./xg++ -B ./ -o abc{.o,.C} -flto -flto-partition=1to1 -O2 -g -fdebug-types-section -c ./xgcc -B ./ -o abc{,.o} -flto -flto-partition=1to1 -O2 (not included in testsuite as it takes a while to compile) FAILs with lto-wrapper: fatal error: Too many copied sections: Operation not supported compilation terminated. /usr/bin/ld: error: lto-wrapper failed collect2: error: ld returned 1 exit status The following patch fixes that. Most of the 64K+ section support for reading and writing was already there years ago (and especially reading used quite often already) and a further bug fixed in it in the PR104617 fix. Yet, the fix isn't solely about removing the if (new_i - 1 >= SHN_LORESERVE) { *err = ENOTSUP; return "Too many copied sections"; } 5 lines, the missing part was that the function only handled reading of the .symtab_shndx section but not copying/updating of it. If the result has less than 64K-epsilon sections, that actually wasn't needed, but e.g. with -fdebug-types-section one can exceed that pretty easily (reported to us on WebKitGtk build on ppc64le). Updating the section is slightly more complicated, because it basically needs to be done in lock step with updating the .symtab section, if one doesn't need to use SHN_XINDEX in there, the section should (or should be updated to) contain SHN_UNDEF entry, otherwise needs to have whatever would be overwise stored but couldn't fit. But repeating due to that all the symtab decisions what to discard and how to rewrite it would be ugly. So, the patch instead emits the .symtab_shndx section (or sections) last and prepares the content during the .symtab processing and in a second pass when going just through .symtab_shndx sections just uses the saved content. 2024-09-07 Jakub Jelinek <jakub@redhat.com> PR lto/116614 * simple-object-elf.c (SHN_COMMON): Align comment with neighbouring comments. (SHN_HIRESERVE): Use uppercase hex digits instead of lowercase for consistency. (simple_object_elf_find_sections): Formatting fixes. (simple_object_elf_fetch_attributes): Likewise. (simple_object_elf_attributes_merge): Likewise. (simple_object_elf_start_write): Likewise. (simple_object_elf_write_ehdr): Likewise. (simple_object_elf_write_shdr): Likewise. (simple_object_elf_write_to_file): Likewise. (simple_object_elf_copy_lto_debug_section): Likewise. Don't fail for new_i - 1 >= SHN_LORESERVE, instead arrange in that case to copy over .symtab_shndx sections, though emit those last and compute their section content when processing associated .symtab sections. Handle simple_object_internal_read failure even in the .symtab_shndx reading case. (cherry picked from commit bb8dd09)

Merge pull request #1 from gcc-mirror/master

3a2e318

wtf: just merge

ghost closed this Jul 3, 2015

ghost reopened this Jul 3, 2015

ghost closed this Jul 3, 2015

muffgaga pushed a commit to electronicvisions/gcc that referenced this pull request Mar 1, 2017

Merge pull request gcc-mirror#2 from TemnosHD/temp-branch-name

3abe67e

long series of fixes and updates -> bring back to master

marxin added a commit to marxin/gccold that referenced this pull request May 29, 2017

Fix gcc-mirror#2.

390b236

marxin added a commit to marxin/gccold that referenced this pull request Aug 14, 2017

Attempt gcc-mirror#2.

470f797

marxin added a commit to marxin/gccold that referenced this pull request Jan 23, 2018

Fix linux-unwind.h gcc-mirror#2.

29ff827

marxin added a commit to marxin/gccold that referenced this pull request Mar 8, 2018

Attempt gcc-mirror#2.

c17c7d6

marxin added a commit to marxin/gccold that referenced this pull request Jun 4, 2018

Fix up gcc-mirror#2.

5a53767

marxin added a commit to marxin/gccold that referenced this pull request Oct 24, 2018

Revert local patches gcc-mirror#2.

c1e524d

marxin added a commit to marxin/gccold that referenced this pull request Mar 4, 2019

Manual gcc-mirror#2.

d3f32b8

mikpe added a commit to mikpe/gcc that referenced this pull request Sep 8, 2024

CDP1802 libgcc support: __udivmodsi4 bug fix gcc-mirror#2

5909787

This pull request was closed.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Merge pull request #1 from gcc-mirror/master #2

Merge pull request #1 from gcc-mirror/master #2

Uh oh!

ghost commented Jul 3, 2015

Uh oh!

Uh oh!

Merge pull request #1 from gcc-mirror/master #2

Merge pull request #1 from gcc-mirror/master #2

Uh oh!

Conversation

ghost commented Jul 3, 2015

Uh oh!

Uh oh!