Gcc 4 8 branch #1
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
why do you want to merge gcc4.8 into master? |
|
I believe this is a read-only repo. |
Backport from mainline 2014-11-19 Richard Biener <rguenther@suse.de> PR tree-optimization/63844 * omp-low.c (fixup_child_record_type): Use a restrict qualified referece type for the receiver parameter. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch@220941 138bc75d-0d04-0410-961f-82ee72b054a4
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch@220954 138bc75d-0d04-0410-961f-82ee72b054a4
Backport from mainline 2015-02-16 Richard Biener <rguenther@suse.de> PR tree-optimization/63593 * tree-predcom.c (execute_pred_commoning_chain): Delay removing stmts and releasing SSA names until... (execute_pred_commoning): ... after processing all chains. * gcc.dg/pr63593.c: New testcase. 2015-02-18 Richard Biener <rguenther@suse.de> PR tree-optimization/65063 * tree-predcom.c (determine_unroll_factor): Return 1 if we have replaced looparound PHIs. * gcc.dg/pr65063.c: New testcase. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch@220960 138bc75d-0d04-0410-961f-82ee72b054a4
* config/avr/avr.c (avr_adjust_insn_length): Call recog_memoized only with NONDEBUG_INSN_P. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch@220965 138bc75d-0d04-0410-961f-82ee72b054a4
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch@220993 138bc75d-0d04-0410-961f-82ee72b054a4
Backport from mainline 2014-11-27 Richard Biener <rguenther@suse.de> PR tree-optimization/61634 * tree-vect-slp.c: (vect_detect_hybrid_slp_stmts): Rewrite to propagate hybrid down the SLP tree for one scalar statement. (vect_detect_hybrid_slp_1): New walker function. (vect_detect_hybrid_slp_2): Likewise. (vect_detect_hybrid_slp): Properly handle pattern statements in a pre-scan over all loop stmts. * gcc.dg/vect/pr61634.c: New testcase. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch@221006 138bc75d-0d04-0410-961f-82ee72b054a4
Backport from mainline 2015-02-25 Adhemerval Zanella <azanella@linux.vnet.ibm.com> * config/rs6000/htm.md (tcheck): Fix assembly encoding. gcc/testsuite/ Backport from mainline 2015-02-25 Peter Bergner <bergner@vnet.ibm.com> * gcc.target/powerpc/htm-builtin-1.c (dg-do) Change to assemble. (dg-options): Add -save-temps. (dg-final): Add cleanup-saved-temps. 2015-02-25 Adhemerval Zanella <azanella@linux.vnet.ibm.com> * gcc.target/powerpc/htm-builtin-1.c: Fix tcheck expect value. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch@221019 138bc75d-0d04-0410-961f-82ee72b054a4
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch@221036 138bc75d-0d04-0410-961f-82ee72b054a4
PR lto/65193 Backport from mainline 2014-07-24 Jan Hubicka <hubicka@ucw.cz> * lto-streamer-out.c (tree_is_indexable): Consider IMPORTED_DECL as non-indexable. * g++.dg/lto/pr65193_0.C: New testcase. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch@221054 138bc75d-0d04-0410-961f-82ee72b054a4
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch@221072 138bc75d-0d04-0410-961f-82ee72b054a4
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch@221081 138bc75d-0d04-0410-961f-82ee72b054a4
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch@221093 138bc75d-0d04-0410-961f-82ee72b054a4
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch@221129 138bc75d-0d04-0410-961f-82ee72b054a4
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch@221167 138bc75d-0d04-0410-961f-82ee72b054a4
Backport from mainline
2015-01-14 Thomas Preud'homme <thomas.preudhomme@arm.com>
gcc/
PR target/64453
* config/arm/arm.c (callee_saved_reg_p): Define.
(arm_compute_save_reg0_reg12_mask): Use callee_saved_reg_p to check if
register is callee saved instead of !call_used_regs[reg].
(thumb1_compute_save_reg_mask): Likewise.
gcc/testsuite/
PR target/64453
* gcc.target/arm/pr64453.c: New.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch@221170 138bc75d-0d04-0410-961f-82ee72b054a4
Backport from mainline
2014-11-27 Thomas Preud'homme <thomas.preudhomme@arm.com>
gcc/
PR target/59593
* config/arm/arm.c (dump_minipool): dispatch to consttable pattern
based on mode size.
* config/arm/arm.md (consttable_1): Make it TARGET_EITHER.
(consttable_2): Make it TARGET_EITHER and move HFmode handling from
consttable_4 to it.
(consttable_4): Move HFmode handling to consttable_2 pattern.
gcc/testsuite/
PR target/59593
* gcc.target/arm/constant-pool.c: New test.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch@221173 138bc75d-0d04-0410-961f-82ee72b054a4
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch@221200 138bc75d-0d04-0410-961f-82ee72b054a4
Backport from trunk 2015-03-03 Michael Meissner <meissner@linux.vnet.ibm.com> PR 65138/target * config/rs6000/rs6000-cpus.def (powerpc64le): Add new generic processor type for 64-bit little endian PowerPC. * config/rs6000/rs6000.c (rs6000_option_override_internal): If -mdebug=reg, print TARGET_DEFAULT. Fix logic to use TARGET_DEFAULT if there is no default cpu. Fix -mdebug=reg printing built-in mask so it does not pass NULL pointers. * config/rs6000/rs6000-tables.opt: Regenerate. * doc/invoke.texi (IBM RS/6000 and PowerPC options): Document -mcpu=powerpc64le. Backport from trunk 2015-01-19 David Edelsohn <dje.gcc@gmail.com> * config/rs6000/default64.h: Include rs6000-cpus.def. (TARGET_DEFAULT) [LITTLE_ENDIAN]: Use ISA 2.7 (POWER8). (TARGET_DEFAULT) [BIG_ENDIAN]: Use POWER4. * config/rs6000/driver-rs6000.c (detect_processor_aix): Add POWER7 and POWER8. * config/rs6000/linux64.h (PROCESSOR_DEFAULT64): Always default to POWER8. * config/rs6000/rs6000.c (rs6000_file_start): Emit .machine pseudo-op to specify assembler dialect. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch@221225 138bc75d-0d04-0410-961f-82ee72b054a4
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch@221227 138bc75d-0d04-0410-961f-82ee72b054a4
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch@221251 138bc75d-0d04-0410-961f-82ee72b054a4
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch@221259 138bc75d-0d04-0410-961f-82ee72b054a4
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch@221272 138bc75d-0d04-0410-961f-82ee72b054a4
* config.gcc (powerpc*-*-linux*): Arrange for powerpc64le-linux to be single-arch by default. Set cpu_is_64bit for powerpc64 given --with-cpu=native. * config/rs6000/t-fprules: Do not set default MULTILIB vars. * config/rs6000/t-linux (MULTIARCH_DIRNAME): Support powerpc64 and powerpc64le. * config/rs6000/linux64.h (SUBSUBTARGET_OVERRIDE_OPTIONS): Test rs6000_isa_flags rather than TARGET_64BIT. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch@221290 138bc75d-0d04-0410-961f-82ee72b054a4
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch@221294 138bc75d-0d04-0410-961f-82ee72b054a4
* config/rs6000/t-linux: For powerpc64* target set MULTILIB_OSDIRNAMES instead of MULTIARCH_DIRNAME. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch@221324 138bc75d-0d04-0410-961f-82ee72b054a4
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch@221340 138bc75d-0d04-0410-961f-82ee72b054a4
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch@221367 138bc75d-0d04-0410-961f-82ee72b054a4
hubot
pushed a commit
that referenced
this pull request
Nov 5, 2024
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.
hubot
pushed a commit
that referenced
this pull request
Nov 8, 2024
Update test case for armv8.1-m.main that supports conditional
arithmetic.
armv7-m:
push {r4, lr}
ldr r4, .L6
ldr r4, [r4]
lsls r4, r4, #29
it mi
addmi r2, r2, #1
bl bar
movs r0, #0
pop {r4, pc}
armv8.1-m.main:
push {r3, r4, r5, lr}
ldr r4, .L5
ldr r5, [r4]
tst r5, #4
csinc r2, r2, r2, eq
bl bar
movs r0, #0
pop {r3, r4, r5, pc}
gcc/testsuite/ChangeLog:
* gcc.target/arm/epilog-1.c: Use check-function-bodies.
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
hubot
pushed a commit
that referenced
this pull request
Nov 8, 2024
Update test case for armv8.1-m.main that supports conditional
arithmetic.
armv7-m:
push {r4, lr}
ldr r4, .L6
ldr r4, [r4]
lsls r4, r4, #29
it mi
addmi r2, r2, #1
bl bar
movs r0, #0
pop {r4, pc}
armv8.1-m.main:
push {r3, r4, r5, lr}
ldr r4, .L5
ldr r5, [r4]
tst r5, #4
csinc r2, r2, r2, eq
bl bar
movs r0, #0
pop {r3, r4, r5, pc}
gcc/testsuite/ChangeLog:
* gcc.target/arm/epilog-1.c: Use check-function-bodies.
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
(cherry picked from commit ec86e87)
vathpela
pushed a commit
to vathpela/gcc
that referenced
this pull request
Nov 11, 2024
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.
hubot
pushed a commit
that referenced
this pull request
Nov 26, 2024
vec.h has this method: template<typename T, typename A> inline T * vec_safe_push (vec<T, A, vl_embed> *&v, const T &obj CXX_MEM_STAT_INFO) where v is a reference to a pointer to vec. This matches the regex for VecPrinter, so gdbhooks.py attempts to print it but chokes on the reference. I see the following: #1 0x0000000002b84b7b in vec_safe_push<edge_def*, va_gc> (v=Traceback (most recent call last): File "$SRC/gcc/gcc/gdbhooks.py", line 486, in to_string return '0x%x' % intptr(self.gdbval) File "$SRC/gcc/gcc/gdbhooks.py", line 168, in intptr return long(gdbval) if sys.version_info.major == 2 else int(gdbval) gdb.error: Cannot convert value to long. This patch makes VecPrinter handle such references by stripping them (dereferencing) at the top of the relevant functions. gcc/ChangeLog: * gdbhooks.py (strip_ref): New. Use it ... (VecPrinter.to_string): ... here, (VecPrinter.children): ... and here.
hubot
pushed a commit
that referenced
this pull request
Nov 26, 2024
In r14.2.0-376-g724446556e5, I accidentally introduced a regression in
the expected assembler as the csinc instruction was not used for
armv8.1-m.main.
The generated assembler for armv8.1-m.main is:
push {r3, r4, r5, lr}
ldr r4, .L5
ldr r5, [r4]
adds r4, r2, #1
tst r5, #4
it ne
movne r2, r4
bl bar
movs r0, #0
pop {r3, r4, r5, pc}
gcc/testsuite/ChangeLog:
* gcc.target/arm/epilog-1.c: Corrected armv8.1.m-main asm.
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
hubot
pushed a commit
that referenced
this pull request
Dec 7, 2024
Brief:
The bug appears in LRA after rematerialization pass while creating live ranges.
File lra.cc:
*************************************************************
/* Now we know what pseudos should be spilled. Try to
rematerialize them first. */
if (lra_remat ())
{
/* We need full live info -- see the comment above. */
lra_create_live_ranges (lra_reg_spill_p, true);
*************************************************************
Wrong call `lra_create_live_ranges (lra_reg_spill_p, true)'
It have to be `lra_create_live_ranges (true, true)'.
The explanation:
**********************************
int main (void)
{
if (a.u33 * a.u33 != 0)
------^^^^^^^^^^^^^
goto abrt;
if (a.u33 * a.u40 * a.u33 != 0)
**********************************
The bug appears here.
Part of the expression `a.u33 * a.u33'
Before LRA:
*************************************************************
(insn 13 11 15 2 (set (reg:QI 184 [ _1+3 ])
(mem/c:QI (const:HI (plus:HI (symbol_ref:HI ("a") [flags 0x2] <var_decl 0x7c866435d000 a>)
(const_int 3 [0x3]))) [1 a+3 S1 A8])) "bf.c":11:8 86 {movqi_insn_split}
(nil))
(insn 15 13 16 2 (set (reg:QI 64 [ a+4 ])
(mem/c:QI (const:HI (plus:HI (symbol_ref:HI ("a") [flags 0x2] <var_decl 0x7c866435d000 a>)
(const_int 4 [0x4]))) [1 a+4 S1 A8])) "bf.c":11:8 86 {movqi_insn_split}
(nil))
(insn 16 15 20 2 (set (reg:QI 185 [ _1+4 ])
(zero_extract:QI (reg:QI 64 [ a+4 ])
(const_int 1 [0x1])
(const_int 0 [0]))) "bf.c":11:8 985 {*extzvqi_split}
(nil))
*************************************************************
After LRA:
*************************************************************
(insn 587 11 13 2 (set (reg:QI 24 r24 [368])
(mem/c:QI (const:HI (plus:HI (symbol_ref:HI ("a") [flags 0x2] <var_decl 0x7c866435d000 a>)
(const_int 3 [0x3]))) [1 a+3 S1 A8])) "bf.c":11:8 86 {movqi_insn_split}
(nil))
(insn 13 587 15 2 (set (mem/c:QI (plus:HI (reg/f:HI 28 r28)
(const_int 1 [0x1])) [4 %sfp+1 S1 A8])
(reg:QI 24 r24 [368])) "bf.c":11:8 86 {movqi_insn_split}
(nil))
(insn 15 13 16 2 (set (reg:QI 6 r6 [orig:64 a+4 ] [64])
(mem/c:QI (const:HI (plus:HI (symbol_ref:HI ("a") [flags 0x2] <var_decl 0x7c866435d000 a>)
(const_int 4 [0x4]))) [1 a+4 S1 A8])) "bf.c":11:8 86 {movqi_insn_split}
(nil))
(insn 16 15 572 2 (set (reg:QI 24 r24 [orig:185 _1+4 ] [185])
(zero_extract:QI (reg:QI 6 r6 [orig:64 a+4 ] [64])
(const_int 1 [0x1])
(const_int 0 [0]))) "bf.c":11:8 985 {*extzvqi_split}
(nil))
(insn 572 16 20 2 (set (mem/c:QI (plus:HI (reg/f:HI 28 r28)
(const_int 1 [0x1])) [4 %sfp+1 S1 A8])
(reg:QI 24 r24 [orig:185 _1+4 ] [185])) "bf.c":11:8 86 {movqi_insn_split}
(nil))
*************************************************************
Insn 13 and insn 572 use sfp+1 as a spill slot, but in IRA pass it was a two
different pseudos r184 and r185.
Insns 13 use sfp+1 as a spill slot for r184
Insns 572 use the same slot for r185. It's wrong.
Here we have a rematerialization.
Fragment from bf.c.317r.reload:
**************************************************************************************
******** Rematerialization #1: ********
df_worklist_dataflow_doublequeue: n_basic_blocks 14 n_edges 18 count 14 ( 1)
df_worklist_dataflow_doublequeue: n_basic_blocks 14 n_edges 18 count 14 ( 1)
Cands:
0 (nop=0, remat_regno=185, reload_regno=359):
(insn 16 15 572 2 (set (reg:QI 359 [orig:185 _1+4 ] [185])
(zero_extract:QI (reg:QI 64 [ a+4 ])
(const_int 1 [0x1])
(const_int 0 [0]))) "bf.c":11:8 985 {*extzvqi_split}
(nil))
**************************************************************************************
[...]
**************************************************************************************
Ranges after the compression:
r185: [0..1]
Frame pointer can not be eliminated anymore
Spilling non-eliminable hard regs: 28 29
Spilling r113(28)
Spilling r184(29)
Spilling r208(29)
Spilling r209(28)
Slot 0 regnos (width = 0): 185 209 208 184 113
**************************************************************************************
The bug is here: `r185: [0..1]' wrong live range after compression.
r185 and r184 can't have the same spill slot !
Rematerialization in bf.c.317r.reload looks like:
*************************************************************
24: r14:QI=r185:QI
Inserting rematerialization insn before:
581: r14:QI=zero_extract(r64:QI,0x1,0)
deleting insn with uid = 24.
Considering alt=0 of insn 16: (0) =r (1) rYil (2) n
overall=0,losers=0,rld_nregs=0
32: r22:QI=r185:QI
Inserting rematerialization insn before:
582: r22:QI=zero_extract(r64:QI,0x1,0)
deleting insn with uid = 32.
*************************************************************
It's happened because:
Fragment from lra.c (lra):
*************************************************************************
if (! live_p)
{
/* We need full live info for spilling pseudos into
registers instead of memory. */
lra_create_live_ranges (lra_reg_spill_p, true);
live_p = true;
}
/* We should check necessity for spilling here as the above live
range pass can remove spilled pseudos. */
if (! lra_need_for_spills_p ())
break;
/* Now we know what pseudos should be spilled. Try to
rematerialize them first. */
if (lra_remat ())
{
/* We need full live info -- see the comment above. */
lra_create_live_ranges (lra_reg_spill_p, true);
----------------------------------^^^^^^^^^^^^^^^
live_p = true;
*************************************************************************
The bug is here.
Rematerialization sometimes can be like spilling pseudos into registers.
582: r22:QI=zero_extract(r64:QI,0x1,0)
So, here we need a live ranges for all pseudos.
PS: the patch will not affect any target with usable definition of
TARGET_SPILL_CLASS hook.
PR target/116778
gcc/
* lra-lives.cc (complete_info_p): Clarification of the comment.
* lra.cc (lra): Create a full live info after rematerialization.
hubot
pushed a commit
that referenced
this pull request
Dec 9, 2024
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>
hubot
pushed a commit
that referenced
this pull request
Dec 12, 2024
With the changes in r15-1579-g792f97b44ff, the code used as "padding" in
the test case is optimized way. Prevent this optimization by forcing a
read of the volatile memory.
Also, validate that there is a far jump in the generated assembler.
Without this patch, the generated assembler is reduced to:
f3:
cmp r0, #0
beq .L1
ldr r4, .L6
.L1:
bx lr
.L7:
.align 2
.L6:
.word g_0_1
With the patch, the generated assembler is:
f3:
movs r2, #1
ldr r3, .L6
push {lr}
str r2, [r3]
cmp r0, #0
bne .LCB10
bl .L1 @far jump
.LCB10:
b .L7
.L8:
.align 2
.L6:
.word .LANCHOR0
.L7:
str r2, [r3]
...
str r2, [r3]
.L1:
pop {pc}
gcc/testsuite/ChangeLog:
* gcc.target/arm/thumb1-far-jump-2.c: Write to volatile memmory
in macro to avoid optimization.
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
hubot
pushed a commit
that referenced
this pull request
Dec 12, 2024
On Cortex-M4, the code generated is:
cmp r0, r1
itte ne
lslne r0, r0, r1
asrne r0, r0, #1
moveq r0, r1
add r0, r0, r1
bx lr
On Cortex-M7, the code generated is:
cmp r0, r1
beq .L3
lsls r0, r0, r1
asrs r0, r0, #1
add r0, r0, r1
bx lr
.L3:
mov r0, r1
add r0, r0, r1
bx lr
As Cortex-M7 only allow maximum one conditional instruction, force
Cortex-M4 to have a stable test case.
gcc/testsuite/ChangeLog:
* gcc.target/arm/thumb-ifcvt.c: Use -mtune=cortex-m4.
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
hubot
pushed a commit
that referenced
this pull request
Dec 12, 2024
On Cortex-M4, the code generated is:
cmp r0, r1
itte ne
lslne r0, r0, r1
asrne r0, r0, #1
moveq r0, r1
add r0, r0, r1
bx lr
On Cortex-M7, the code generated is:
cmp r0, r1
beq .L3
lsls r0, r0, r1
asrs r0, r0, #1
add r0, r0, r1
bx lr
.L3:
mov r0, r1
add r0, r0, r1
bx lr
As Cortex-M7 only allow maximum one conditional instruction, force
Cortex-M4 to have a stable test case.
gcc/testsuite/ChangeLog:
* gcc.target/arm/thumb-ifcvt.c: Use -mtune=cortex-m4.
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
(cherry picked from commit e7615f6)
hubot
pushed a commit
that referenced
this pull request
Dec 17, 2024
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.
hubot
pushed a commit
that referenced
this pull request
Jan 7, 2025
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.
hubot
pushed a commit
that referenced
this pull request
Jan 9, 2025
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)
hubot
pushed a commit
that referenced
this pull request
Jan 10, 2025
This code in cxx_eval_array_reference has been hard to get right.
In r12-2304 I added some code; in r13-5693 I removed some of it.
Here the problematic line is "S s = arr[0];" which causes a crash
on the assert in verify_ctor_sanity:
gcc_assert (!ctx->object || !DECL_P (ctx->object)
|| ctx->global->get_value (ctx->object) == ctx->ctor);
ctx->object is the VAR_DECL 's', which is correct here. The second
line points to the problem: we replaced ctx->ctor in
cxx_eval_array_reference:
new_ctx.ctor = build_constructor (elem_type, NULL); // #1
which I think we shouldn't have; the CONSTRUCTOR we created in
cxx_eval_constant_expression/DECL_EXPR
new_ctx.ctor = build_constructor (TREE_TYPE (r), NULL);
had the right type.
We still need #1 though. E.g., in constexpr-96241.C, we never
set ctx.ctor/object before calling cxx_eval_array_reference, so
we have to build a CONSTRUCTOR there. And in constexpr-101371-2.C
we have a ctx.ctor, but it has the wrong type, so we need a new one.
We can fix the problem by always clearing the object, and, as an
optimization, only create/free a new ctor when actually needed.
PR c++/110382
gcc/cp/ChangeLog:
* constexpr.cc (cxx_eval_array_reference): Create a new constructor
only when we don't already have a matching one. Clear the object
when the type is non-scalar.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1y/constexpr-110382.C: New test.
(cherry picked from commit 6e424fe)
hubot
pushed a commit
that referenced
this pull request
Jan 10, 2025
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)
hubot
pushed a commit
that referenced
this pull request
Jan 10, 2025
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)
hubot
pushed a commit
that referenced
this pull request
Feb 7, 2025
In a member-specification of a class, a noexcept-specifier is
a complete-class context. Thus we delay parsing until the end of
the class via our DEFERRED_PARSE mechanism; see cp_parser_save_noexcept
and cp_parser_late_noexcept_specifier.
We also attempt to defer instantiation of noexcept-specifiers in order
to reduce the number of instantiations; this is done via DEFERRED_NOEXCEPT.
We can even have both, as in noexcept65.C: a DEFERRED_PARSE wrapped in
DEFERRED_NOEXCEPT, which uses the DEFPARSE_INSTANTIATIONS mechanism.
noexcept65.C works, because when we really need the noexcept, which is
when parsing the body of S::A::A(), the noexcept will have been parsed
already; noexcepts are parsed before bodies of member function.
But in this test we have:
struct A {
int x;
template<class>
void foo() noexcept(noexcept(x)) {}
auto bar() -> decltype(foo<int>()) {} // #1
};
and I think the decltype in #1 needs the unparsed noexcept before it
could have been parsed. clang++ rejects the test and I suppose we
should reject it as well, rather than crashing on a DEFERRED_PARSE
in tsubst_expr.
PR c++/117106
PR c++/118190
gcc/cp/ChangeLog:
* pt.cc (maybe_instantiate_noexcept): Give an error if the noexcept
hasn't been parsed yet.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/noexcept89.C: New test.
* g++.dg/cpp0x/noexcept90.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
hubot
pushed a commit
that referenced
this pull request
Mar 25, 2025
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.
hubot
pushed a commit
that referenced
this pull request
Mar 31, 2025
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.
Peter0x44
pushed a commit
to Peter0x44/gcc
that referenced
this pull request
Apr 6, 2025
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.
Peter0x44
pushed a commit
to Peter0x44/gcc
that referenced
this pull request
Apr 6, 2025
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.
|
heart goes out to the guy who made this PR and was never told that this isn't the official repo |
hubot
pushed a commit
that referenced
this pull request
Apr 14, 2025
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)
hubot
pushed a commit
that referenced
this pull request
Apr 14, 2025
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)
hubot
pushed a commit
that referenced
this pull request
May 10, 2025
this patch fixes some of problems with cosint in scalar to vector pass.
In particular
1) the pass uses optimize_insn_for_size which is intended to be used by
expanders and splitters and requires the optimization pass to use
set_rtl_profile (bb) for currently processed bb.
This is not done, so we get random stale info about hotness of insn.
2) register allocator move costs are all realtive to integer reg-reg move
which has cost of 2, so it is (except for size tables and i386)
a latency of instruction multiplied by 2.
These costs has been duplicated and are now used in combination with
rtx costs which are all based to COSTS_N_INSNS that multiplies latency
by 4.
Some of vectorizer costing contains COSTS_N_INSNS (move_cost) / 2
to compensate, but some new code does not. This patch adds compensatoin.
Perhaps we should update the cost tables to use COSTS_N_INSNS everywher
but I think we want to first fix inconsistencies. Also the tables will
get optically much longer, since we have many move costs and COSTS_N_INSNS
is a lot of characters.
3) variable m which decides how much to multiply integer variant (to account
that with -m32 all 64bit computations needs 2 instructions) is declared
unsigned which makes the signed computation of instruction gain to be
done in unsigned type and breaks i.e. for division.
4) I added integer_to_sse costs which are currently all duplicationof
sse_to_integer. AMD chips are asymetric and moving one direction is faster
than another. I will chance costs incremnetally once vectorizer part
is fixed up, too.
There are two failures gcc.target/i386/minmax-6.c and gcc.target/i386/minmax-7.c.
Both test stv on hasswell which no longer happens since SSE->INT and INT->SSE moves
are now more expensive.
There is only one instruction to convert:
Computing gain for chain #1...
Instruction gain 8 for 11: {r110:SI=smax(r116:SI,0);clobber flags:CC;}
Instruction conversion gain: 8
Registers conversion cost: 8 <- this is integer_to_sse and sse_to_integer
Total gain: 0
total gain used to be 4 since the patch doubles the conversion costs.
According to agner fog's tables the costs should be 1 cycle which is correct
here.
Final code gnerated is:
vmovd %esi, %xmm0 * latency 1
cmpl %edx, %esi
je .L2
vpxor %xmm1, %xmm1, %xmm1 * latency 1
vpmaxsd %xmm1, %xmm0, %xmm0 * latency 1
vmovd %xmm0, %eax * latency 1
imull %edx, %eax
cltq
movzwl (%rdi,%rax,2), %eax
ret
cmpl %edx, %esi
je .L2
xorl %eax, %eax * latency 1
testl %esi, %esi * latency 1
cmovs %eax, %esi * latency 2
imull %edx, %esi
movslq %esi, %rsi
movzwl (%rdi,%rsi,2), %eax
ret
Instructions with latency info are those really different.
So the uncoverted code has sum of latencies 4 and real latency 3.
Converted code has sum of latencies 4 and real latency 3 (vmod+vpmaxsd+vmov).
So I do not quite see it should be a win.
There is also a bug in costing MIN/MAX
case ABS:
case SMAX:
case SMIN:
case UMAX:
case UMIN:
/* We do not have any conditional move cost, estimate it as a
reg-reg move. Comparisons are costed as adds. */
igain += m * (COSTS_N_INSNS (2) + ix86_cost->add);
/* Integer SSE ops are all costed the same. */
igain -= ix86_cost->sse_op;
break;
Now COSTS_N_INSNS (2) is not quite right since reg-reg move should be 1 or perhaps 0.
For Haswell cmov really is 2 cycles, but I guess we want to have that in cost vectors
like all other instructions.
I am not sure if this is really a win in this case (other minmax testcases seems to make
sense). I have xfailed it for now and will check if that affects specs on LNT testers.
I will proceed with similar fixes on vectorizer cost side. Sadly those introduces
quite some differences in the testuiste (partly triggered by other costing problems,
such as one of scatter/gather)
gcc/ChangeLog:
* config/i386/i386-features.cc
(general_scalar_chain::vector_const_cost): Add BB parameter; handle
size costs; use COSTS_N_INSNS to compute move costs.
(general_scalar_chain::compute_convert_gain): Use optimize_bb_for_size
instead of optimize_insn_for size; use COSTS_N_INSNS to compute move costs;
update calls of general_scalar_chain::vector_const_cost; use
ix86_cost->integer_to_sse.
(timode_immed_const_gain): Add bb parameter; use
optimize_bb_for_size_p.
(timode_scalar_chain::compute_convert_gain): Use optimize_bb_for_size_p.
* config/i386/i386-features.h (class general_scalar_chain): Update
prototype of vector_const_cost.
* config/i386/i386.h (struct processor_costs): Add integer_to_sse.
* config/i386/x86-tune-costs.h (struct processor_costs): Copy
sse_to_integer to integer_to_sse everywhere.
gcc/testsuite/ChangeLog:
* gcc.target/i386/minmax-6.c: xfail test that pmax is used.
* gcc.target/i386/minmax-7.c: xfall test that pmin is used.
keith-packard
pushed a commit
to keith-packard/gcc
that referenced
this pull request
May 11, 2025
hubot
pushed a commit
that referenced
this pull request
May 12, 2025
The test was designed to pass with thumb2, but code generation changed
with the introduction of Low Overhead Loops, so the test can fail if
one overrides the flags when running the testsuite.
In addition, useless subtract / extension instructions require -O2 to
remove them (-O is not sufficient), so replace -O with -O2 in
dg-options.
arm_thumb2_ok_no_arm_v8_1m_lob does not do what the test needs (it can
fail because some flags conflict, rather than because lob are
supported, and we do not need to check runtime support in this test
anyway), so the patch reverts back to arm_thumb2_ok.
Finally, replace the scan-assembler directives with
check-function-bodies, checking both types of code generation (with
and without LOL). Depending on architecture version, the two insns
and r0, r1, r0, lsr #1
ands r3, r3, #255
can be swapped, so accept both orders.
gcc/testsuite/ChangeLog:
PR target/116445
* gcc.target/arm/unsigned-extend-2.c: Fix dg directives.
hubot
pushed a commit
that referenced
this pull request
Jun 9, 2025
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.
hubot
pushed a commit
that referenced
this pull request
Jun 13, 2025
…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)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.