[Bug ipa/115533] New: [12/13/14/15 regression] flac miscompiled with -O3 -march=znver2 -fipa-pta -fno-vect-cost-model
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115533 Bug ID: 115533 Summary: [12/13/14/15 regression] flac miscompiled with -O3 -march=znver2 -fipa-pta -fno-vect-cost-model Product: gcc Version: unknown Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: sjames at gcc dot gnu.org Blocks: 68331 Target Milestone: --- Created attachment 58458 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58458&action=edit replaygain_analysis.i Hit this when building flac with -O3 -march=znver2 -fipa-pta -fno-vect-cost-model. I don't yet have a reduced runtime testcase, working on it though. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68331 [Bug 68331] [meta-bug] fipa-pta issues
[Bug ipa/115533] [12/13/14/15 regression] flac miscompiled with -O3 -march=znver2 -fipa-pta -fno-vect-cost-model
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115533
--- Comment #1 from Sam James ---
* Adding optimize("O2") or O0 to ReallocateWindowBuffer fixes it (it's a
realloc wrapper)
* We go wrong in analyzeResult and return a bogus result
[Bug ipa/115533] [12/13/14/15 regression] flac miscompiled with -O3 -march=znver2 -fipa-pta -fno-vect-cost-model
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115533 --- Comment #2 from Sam James --- Created attachment 58459 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58459&action=edit replaygain_analysis-bad.c.o.xz
[Bug ipa/115533] [12/13/14/15 regression] flac miscompiled with -O3 -march=znver2 -fipa-pta -fno-vect-cost-model
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115533 Sam James changed: What|Removed |Added Attachment #58459|0 |1 is obsolete|| --- Comment #3 from Sam James --- Created attachment 58460 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58460&action=edit replaygain_analysis-bad.c.o.xz
[Bug ipa/115533] [12/13/14/15 regression] flac miscompiled with -O3 -march=znver2 -fipa-pta -fno-vect-cost-model
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115533 --- Comment #4 from Sam James --- Created attachment 58461 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58461&action=edit replaygain_analysis-good.c.o.xz
[Bug tree-optimization/115534] New: intermediate stack use not eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115534
Bug ID: 115534
Summary: intermediate stack use not eliminated
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tnfchris at gcc dot gnu.org
Target Milestone: ---
Consider the following example:
#include
typedef struct _pixel_t
{
double red, green, blue, opacity;
} pixel_t;
typedef struct _PixelPacket
{
unsigned short blue, green, red, opacity;
} PixelPacket;
pixel_t f (unsigned height, unsigned width, unsigned virt_width,
uint8_t *restrict k, const PixelPacket *restrict k_pixels)
{
pixel_t result = {};
for (unsigned u=0; u < (width & -4); u++, k--) {
result.red += (*k)*k_pixels[u].red;
result.green += (*k)*k_pixels[u].green;
result.blue+= (*k)*k_pixels[u].blue;
result.opacity += (*k)*k_pixels[u].opacity;
k_pixels += virt_width;
}
return result;
}
---
compiled with -O3 vectorizes as good, but the epilogue code is very
inefficient:
faddv29.2d, v29.2d, v30.2d
faddv28.2d, v28.2d, v31.2d
cmp w5, w1
bhi .L3
mov v31.16b, v28.16b
ins v31.d[1], v29.d[1]
ins v29.d[1], v28.d[1]
stp q31, q29, [sp, 32]
ldp d0, d1, [sp, 32]
ldp d2, d3, [sp, 48]
add sp, sp, 64
ret
.L4:
moviv29.2d, 0
mov v31.16b, v29.16b
stp q31, q29, [sp, 32]
ldp d0, d1, [sp, 32]
ldp d2, d3, [sp, 48]
add sp, sp, 64
ret
as in it goes through the stack to create the return registers. This looks
like at gimple we still have the store:
[local count: 105119324]:
_33 = VEC_PERM_EXPR ;
_31 = VEC_PERM_EXPR ;
[local count: 118111600]:
# vect_result_red_64.18_28 = PHI <_33(5), { 0.0, 0.0 }(2)>
# vect_result_red_64.18_105 = PHI <_31(5), { 0.0, 0.0 }(2)>
MEM [(double *)&D.4535] = vect_result_red_64.18_28;
MEM [(double *)&D.4535 + 16B] = vect_result_red_64.18_105;
return D.4535;
clang is able to generate much better code here:
faddv0.2d, v0.2d, v1.2d
faddv2.2d, v2.2d, v3.2d
b.ne.LBB0_2
.LBB0_3:
mov d1, v2.d[1]
mov d3, v0.d[1]
ret
The vectorized code gets reg-alloc'ed so that d0 an d2 are already in the right
registers at the end of the vector loop, and the epilogue only has to split the
registers up to get d1 and d3.
I think we would generate the same if we were to elide the intermediate stack
store.
See https://godbolt.org/z/ocqchWWs5
[Bug target/111376] missed optimization of one bit test on MIPS32r1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111376 --- Comment #17 from YunQiang Su --- I send the patch here. So we may need some more test.
[Bug ada/115535] New: Image attribute on arrays incorrectly prints a signed representation under certain conditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115535 Bug ID: 115535 Summary: Image attribute on arrays incorrectly prints a signed representation under certain conditions Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: liam at liampwll dot com CC: dkm at gcc dot gnu.org Target Milestone: --- When calling 'Image on arrays containing range 0 .. 2**32 - 1 the output does not match the output of 'Image for each element and instead outputs the value interpreted as a signed 32 bit number. GCC version: x64 13.2.0 from Alire on Linux and trunk on godbolt.org Example built with gcc -c -I/app/ -g -fdiagnostics-color=always -S -fverbose-asm -masm=intel -gnat2022 -o /app/example.s -I-: with Ada.Text_IO; use Ada.Text_IO; with System; procedure Example is type Client_ID_Part is range 0 .. 2**32 - 1 with Size => 32; type Client_ID is array (1 .. 2) of Client_ID_Part; A : Client_ID := (1479222903, 3163714999); begin Put_Line (A'Image); Put_Line (A (1)'Image); Put_Line (A (2)'Image); end Example; Actual output: [ 1479222903, -1131252297] 1479222903 3163714999 Expected output: [ 1479222903, 3163714999] 1479222903 3163714999
[Bug target/115517] Fix x86 regressions after dropping uses of vcond{,u,eq}_optab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115517 --- Comment #2 from Hongtao Liu --- (In reply to Richard Biener from comment #1) > Btw, I had opened PR115490 with my results for this already. Some mitigation > should be from optimizing ISEL expansion to vcond_mask and I'd start with > looking at some of the fallout from that side (note that might require > the backend reject not natively implemented vec_cmp via its operand 1 > predicate) w/o AVX512, vector integer comparison only supports EQ/GT, others comparison rtx_cost is transformed to that. (.i.e GTU is emulated with us_minus + eq + negative the vector mask) If we restrict the predicate of operand 1, would middle-end reject vectorization (or lower it to scalar version)?
[Bug libstdc++/115514] Nonconforming reverse_iterator::operator->
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115514 --- Comment #1 from Jonathan Wakely --- (In reply to frankhb1989 from comment #0) > (Another difference is it only applies the resolution for C++17 onward.) C++20 onward, I think.
[Bug libstdc++/115514] Nonconforming reverse_iterator::operator->
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115514 --- Comment #2 from Jonathan Wakely --- The constraint on reverse_iterator::operator->() checks it for an lvalue, which suggests nobody considered (or cared) about annoying iterators that do something different for lvalues and rvalues. I'm inclined to consider the difference here to be an unintended consequence of using of std::prev, and so a defect in the spec. I think this is not something we should care about.
[Bug rtl-optimization/114996] [15 Regression] [RISC-V] 2->2 combination no longer occurring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114996 Richard Sandiford changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #6 from Richard Sandiford --- FWIW, late-combine also fixes this. I'm in the process of getting the submission ready (still going through multi-target testing).
[Bug modula2/115536] New: Expression is evaluated incorrectly when encountering relops and indirection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115536
Bug ID: 115536
Summary: Expression is evaluated incorrectly when encountering
relops and indirection
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: modula2
Assignee: gaius at gcc dot gnu.org
Reporter: gaius at gcc dot gnu.org
Target Milestone: ---
The following code fails with:
$ gm2 -g testcond2.mod
$ ./a.out
failed
MODULE condtest2 ;
FROM libc IMPORT printf, exit ;
PROCEDURE test (VAR a, b, c, d: CARDINAL) ;
BEGIN
IF (a = b) # (c = d)
THEN
printf ("passed\n")
ELSE
printf ("failed\n") ;
exit (1)
END
END test ;
VAR
e, f, g, h: CARDINAL ;
BEGIN
e := 1 ;
f := 2 ;
g := 3 ;
h := 3 ;
test (e, f, g, h)
END condtest2.
[Bug ipa/115533] [12/13/14/15 regression] flac miscompiled with -O3 -march=znver2 -fipa-pta -fno-vect-cost-model
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115533 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Version|unknown |15.0 Target Milestone|--- |12.4 --- Comment #5 from Richard Biener --- I wonder if it's the badly tested interaction between IPA opts and IPA PTA, I assume -O2 -ftree-vectorize instead of -O3 isn't enough to reproduce? I don't think that GCC 11 working means anything - IPA PTA doesn't get much changes, so it's likely just now actually doing sth meaningful (bad) with IPA PTA info.
[Bug modula2/115536] Expression is evaluated incorrectly when encountering relops and indirection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115536 Gaius Mulley changed: What|Removed |Added Last reconfirmed||2024-06-18 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #1 from Gaius Mulley --- Confirmed - it appears that the gcc/m2/gm2-compiler/M2Quads.mod:BuildRelOp procedure is generating incorrect quadruples. During processing of the inequality it detects the two boolean sub expressions and manipulates them to deduce the result. However the manipulation has ignored the operands c and d require de-referencing.
[Bug middle-end/115528] [15 regression] segmentation fault in legacy F77 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115528 --- Comment #4 from Jürgen Reuter --- Created attachment 58462 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58462&action=edit Input file that triggers the test case with segmentation fault This test case needs Whizard 3.1.4 to be downloaded here, http://whizard.hepforge.org/whizard-3.1.4.tar.gz I avoided the need for OCaml being present, just do ./configure, make, make install. This will create a binary whizard, and then execute whizard tauola_1.sin as attached.
[Bug target/115517] Fix x86 regressions after dropping uses of vcond{,u,eq}_optab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115517 --- Comment #3 from rguenther at suse dot de --- On Tue, 18 Jun 2024, liuhongt at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115517 > > --- Comment #2 from Hongtao Liu --- > (In reply to Richard Biener from comment #1) > > Btw, I had opened PR115490 with my results for this already. Some > > mitigation > > should be from optimizing ISEL expansion to vcond_mask and I'd start with > > looking at some of the fallout from that side (note that might require > > the backend reject not natively implemented vec_cmp via its operand 1 > > predicate) > > w/o AVX512, vector integer comparison only supports EQ/GT, others comparison > rtx_cost is transformed to that. (.i.e GTU is emulated with us_minus + eq + > negative the vector mask) > If we restrict the predicate of operand 1, would middle-end reject > vectorization (or lower it to scalar version)? Richard suggests that we implement the "obvious" transforms like inversion in the middle-end but if for example unsigned compares are not supported the us_minus + eq + negative trick isn't on that list. The main reason to restrict vec_cmp would be to avoid a <= b ? c : d going with an unsupported vec_cmp but instead do a > b ? d : c - the alternative is trying to fix this on the RTL side via combine. I understand the non-native compares are already expanded to supported form and we don't use a split after combine to make combinations to a supported form easier? I don't have a good feeling which approach is going to be better maintainable here. But for example even for the unsigned compare "lowering" the middle-end would have range info while RTL does not (to some extent it's available at RTL expansion time).
[Bug c/115109] Incorrect type of enumeration constant in redeclaration of enumeration constant (C23)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115109 --- Comment #8 from GCC Commits --- The master branch has been updated by Martin Uecker : https://gcc.gnu.org/g:c9b96a68860bfdee49d40b4a844af7c5ef69cd12 commit r15-1394-gc9b96a68860bfdee49d40b4a844af7c5ef69cd12 Author: Martin Uecker Date: Sat May 18 22:00:04 2024 +0200 c23: Fix for redeclared enumerator initialized with different type [PR115109] c23 specifies that the type of a redeclared enumerator is the one of the previous declaration. Convert initializers with different type accordingly and emit an error when the value does not fit. 2024-06-01 Martin Uecker PR c/115109 gcc/c/ * c-decl.cc (build_enumerator): When redeclaring an enumerator convert value to previous type. For redeclared enumerators use underlying type for computing the next value. gcc/testsuite/ * gcc.dg/pr115109.c: New test. * gcc.dg/c23-tag-enum-6.c: New test. * gcc.dg/c23-tag-enum-7.c: New test.
[Bug target/115517] Fix x86 regressions after dropping uses of vcond{,u,eq}_optab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115517
--- Comment #4 from Hongtao Liu ---
(In reply to rguent...@suse.de from comment #3)
> On Tue, 18 Jun 2024, liuhongt at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115517
> >
> > --- Comment #2 from Hongtao Liu ---
> > (In reply to Richard Biener from comment #1)
> > > Btw, I had opened PR115490 with my results for this already. Some
> > > mitigation
> > > should be from optimizing ISEL expansion to vcond_mask and I'd start with
> > > looking at some of the fallout from that side (note that might require
> > > the backend reject not natively implemented vec_cmp via its operand 1
> > > predicate)
> >
> > w/o AVX512, vector integer comparison only supports EQ/GT, others comparison
> > rtx_cost is transformed to that. (.i.e GTU is emulated with us_minus + eq +
> > negative the vector mask)
> > If we restrict the predicate of operand 1, would middle-end reject
> > vectorization (or lower it to scalar version)?
>
> Richard suggests that we implement the "obvious" transforms like
> inversion in the middle-end but if for example unsigned compares
> are not supported the us_minus + eq + negative trick isn't on
> that list.
>
> The main reason to restrict vec_cmp would be to avoid
> a <= b ? c : d going with an unsupported vec_cmp but instead
> do a > b ? d : c - the alternative is trying to fix this
> on the RTL side via combine. I understand the non-native
Yes, I have a patch which can fix most regressions via pattern match in
combine.
Still there is a situation that is difficult to deal with, mainly the
optimization w/o sse4.1 . Because pblendvb/blendvps/blendvpd only exists under
sse4.1, w/o sse4.1, it takes 3 instructions (pand,pandn,por) to simulate the
vcond_mask, and the combine matches up to 4 instructions, which makes it
currently impossible to use the combine to recover those optimizations in the
vcond{,u,eq}.i.e min/max.
In the case of sse 4.1 and above, there is basically no regression anymore.
the regression testcases w/o sse4.1
FAIL: g++.target/i386/pr100637-1b.C -std=gnu++14 scan-assembler-times pcmpeqb
2
FAIL: g++.target/i386/pr100637-1b.C -std=gnu++17 scan-assembler-times pcmpeqb
2
FAIL: g++.target/i386/pr100637-1b.C -std=gnu++20 scan-assembler-times pcmpeqb
2
FAIL: g++.target/i386/pr100637-1b.C -std=gnu++98 scan-assembler-times pcmpeqb
2
FAIL: g++.target/i386/pr100637-1w.C -std=gnu++14 scan-assembler-times pcmpeqw
2
FAIL: g++.target/i386/pr100637-1w.C -std=gnu++17 scan-assembler-times pcmpeqw
2
FAIL: g++.target/i386/pr100637-1w.C -std=gnu++20 scan-assembler-times pcmpeqw
2
FAIL: g++.target/i386/pr100637-1w.C -std=gnu++98 scan-assembler-times pcmpeqw
2
FAIL: g++.target/i386/pr103861-1.C -std=gnu++14 scan-assembler-times pcmpeqb
2
FAIL: g++.target/i386/pr103861-1.C -std=gnu++17 scan-assembler-times pcmpeqb
2
FAIL: g++.target/i386/pr103861-1.C -std=gnu++20 scan-assembler-times pcmpeqb
2
FAIL: g++.target/i386/pr103861-1.C -std=gnu++98 scan-assembler-times pcmpeqb
2
FAIL: gcc.target/i386/pr88540.c scan-assembler minpd
[Bug tree-optimization/115537] New: [15 Regression] vectorizable_reduction ICEs after g:d66b820f392aa9a7c34d3cddaf3d7c73bf23f82d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115537
Bug ID: 115537
Summary: [15 Regression] vectorizable_reduction ICEs after
g:d66b820f392aa9a7c34d3cddaf3d7c73bf23f82d
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tnfchris at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Target Milestone: ---
testcase:
---
char *a;
int b;
void c() {
int d = 0, e = 0, f;
for (; f; ++f)
if (a[f] == 5)
;
else if (a[f])
e = 1;
else
d = 1;
if (d)
if (e)
b = 0;
}
---
compiled with -mcpu=neoverse-v1 -O3 produces the following ICE:
during GIMPLE pass: vect
pngrtran.i: In function 'c':
pngrtran.i:3:6: internal compiler error: in vectorizable_reduction, at
tree-vect-loop.cc:8335
3 | void c() {
| ^
0xff74ff vectorizable_reduction(_loop_vec_info*, _stmt_vec_info*, _slp_tree*,
_slp_instance*, vec*)
/opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-vect-loop.cc:8335
0x1b598f7 vect_analyze_stmt(vec_info*, _stmt_vec_info*, bool*, _slp_tree*,
_slp_instance*, vec*)
/opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-vect-stmts.cc:13353
0x10225df vect_slp_analyze_node_operations_1
/opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-vect-slp.cc:6457
0x10225df vect_slp_analyze_node_operations
/opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-vect-slp.cc:6656
0x102253f vect_slp_analyze_node_operations
/opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-vect-slp.cc:6635
0x1023ec3 vect_slp_analyze_operations(vec_info*)
/opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-vect-slp.cc:7053
0xff816f vect_analyze_loop_2
/opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-vect-loop.cc:2953
0xff9fb7 vect_analyze_loop_1
/opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-vect-loop.cc:3484
0xffa6f7 vect_analyze_loop(loop*, vec_info_shared*)
/opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-vect-loop.cc:3642
0x1035547 try_vectorize_loop_1
/opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-vectorizer.cc:1067
0x1035547 try_vectorize_loop
/opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-vectorizer.cc:1183
0x1035a5b execute
/opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-vectorizer.cc:1299
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug libstdc++/115514] Nonconforming reverse_iterator::operator->
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115514 Jiang An changed: What|Removed |Added CC||de34 at live dot cn --- Comment #3 from Jiang An --- See - https://cplusplus.github.io/LWG/issue3725 - https://cplusplus.github.io/LWG/issue3727 If "implicit expression variations" (https://eel.is/c++draft/concepts.equality#6) apply here, then despite std::prev returning a non-const prvalue, the behavior of operator-> on such a prvalue should be required to be same as that on a const lvalue. But the current standard wording just says > These implicit expression variations are required to meet the semantic > requirements of the declared expression. It seems that we haven't forbidden the cases where an implicit expression variation behaves differently while still meeting the semantic requirements.
[Bug target/115517] Fix x86 regressions after dropping uses of vcond{,u,eq}_optab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115517
--- Comment #5 from rguenther at suse dot de ---
On Tue, 18 Jun 2024, liuhongt at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115517
>
> --- Comment #4 from Hongtao Liu ---
> (In reply to rguent...@suse.de from comment #3)
> > On Tue, 18 Jun 2024, liuhongt at gcc dot gnu.org wrote:
> >
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115517
> > >
> > > --- Comment #2 from Hongtao Liu ---
> > > (In reply to Richard Biener from comment #1)
> > > > Btw, I had opened PR115490 with my results for this already. Some
> > > > mitigation
> > > > should be from optimizing ISEL expansion to vcond_mask and I'd start
> > > > with
> > > > looking at some of the fallout from that side (note that might require
> > > > the backend reject not natively implemented vec_cmp via its operand 1
> > > > predicate)
> > >
> > > w/o AVX512, vector integer comparison only supports EQ/GT, others
> > > comparison
> > > rtx_cost is transformed to that. (.i.e GTU is emulated with us_minus + eq
> > > +
> > > negative the vector mask)
> > > If we restrict the predicate of operand 1, would middle-end reject
> > > vectorization (or lower it to scalar version)?
> >
> > Richard suggests that we implement the "obvious" transforms like
> > inversion in the middle-end but if for example unsigned compares
> > are not supported the us_minus + eq + negative trick isn't on
> > that list.
> >
> > The main reason to restrict vec_cmp would be to avoid
> > a <= b ? c : d going with an unsupported vec_cmp but instead
> > do a > b ? d : c - the alternative is trying to fix this
> > on the RTL side via combine. I understand the non-native
>
> Yes, I have a patch which can fix most regressions via pattern match in
> combine.
> Still there is a situation that is difficult to deal with, mainly the
> optimization w/o sse4.1 . Because pblendvb/blendvps/blendvpd only exists under
> sse4.1, w/o sse4.1, it takes 3 instructions (pand,pandn,por) to simulate the
> vcond_mask, and the combine matches up to 4 instructions, which makes it
> currently impossible to use the combine to recover those optimizations in the
> vcond{,u,eq}.i.e min/max.
> In the case of sse 4.1 and above, there is basically no regression anymore.
Maybe it's possible to use a define_insn_and_split for blends w/o SSE 4.1?
That would allow combine matching the high-level blend operation and
we'd only lower it afterwards? The question is what we lose in
combinations of/into the loweredn pand/pandn/por of course.
Maybe it's possible to catch the higher-level optimization (min/max)
on the GIMPLE level instead?
[Bug target/115464] [14 Backport] ICE when building libaom on arm64 (neon sve bridge usage with tbl/perm)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115464 --- Comment #12 from GCC Commits --- The trunk branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:6bd4fbae45d11795a9a6f54b866308d4d7134def commit r15-1399-g6bd4fbae45d11795a9a6f54b866308d4d7134def Author: Richard Sandiford Date: Tue Jun 18 12:22:31 2024 +0100 aarch64: Add some uses of force_lowpart_subreg This patch makes more use of force_lowpart_subreg, similarly to the recent patch for force_subreg. The criteria were: (1) The code is obviously specific to expand (where new pseudos can be created). (2) The value is obviously an rvalue rather than an lvalue. gcc/ PR target/115464 * config/aarch64/aarch64-builtins.cc (aarch64_expand_fcmla_builtin) (aarch64_expand_rwsr_builtin): Use force_lowpart_subreg instead of simplify_gen_subreg and lowpart_subreg. * config/aarch64/aarch64-sve-builtins-base.cc (svset_neonq_impl::expand): Likewise. * config/aarch64/aarch64-sve-builtins-sme.cc (add_load_store_slice_operand): Likewise. * config/aarch64/aarch64.cc (aarch64_sve_reinterpret): Likewise. (aarch64_addti_scratch_regs, aarch64_subvti_scratch_regs): Likewise. gcc/testsuite/ PR target/115464 * gcc.target/aarch64/sve/acle/general/pr115464_2.c: New test.
[Bug target/115517] Fix x86 regressions after dropping uses of vcond{,u,eq}_optab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115517
--- Comment #6 from Hongtao Liu ---
(In reply to rguent...@suse.de from comment #5)
> On Tue, 18 Jun 2024, liuhongt at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115517
> >
> > --- Comment #4 from Hongtao Liu ---
> > (In reply to rguent...@suse.de from comment #3)
> > > On Tue, 18 Jun 2024, liuhongt at gcc dot gnu.org wrote:
> > >
> > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115517
> > > >
> > > > --- Comment #2 from Hongtao Liu ---
> > > > (In reply to Richard Biener from comment #1)
> > > > > Btw, I had opened PR115490 with my results for this already. Some
> > > > > mitigation
> > > > > should be from optimizing ISEL expansion to vcond_mask and I'd start
> > > > > with
> > > > > looking at some of the fallout from that side (note that might require
> > > > > the backend reject not natively implemented vec_cmp via its operand 1
> > > > > predicate)
> > > >
> > > > w/o AVX512, vector integer comparison only supports EQ/GT, others
> > > > comparison
> > > > rtx_cost is transformed to that. (.i.e GTU is emulated with us_minus +
> > > > eq +
> > > > negative the vector mask)
> > > > If we restrict the predicate of operand 1, would middle-end reject
> > > > vectorization (or lower it to scalar version)?
> > >
> > > Richard suggests that we implement the "obvious" transforms like
> > > inversion in the middle-end but if for example unsigned compares
> > > are not supported the us_minus + eq + negative trick isn't on
> > > that list.
> > >
> > > The main reason to restrict vec_cmp would be to avoid
> > > a <= b ? c : d going with an unsupported vec_cmp but instead
> > > do a > b ? d : c - the alternative is trying to fix this
> > > on the RTL side via combine. I understand the non-native
> >
> > Yes, I have a patch which can fix most regressions via pattern match in
> > combine.
> > Still there is a situation that is difficult to deal with, mainly the
> > optimization w/o sse4.1 . Because pblendvb/blendvps/blendvpd only exists
> > under
> > sse4.1, w/o sse4.1, it takes 3 instructions (pand,pandn,por) to simulate the
> > vcond_mask, and the combine matches up to 4 instructions, which makes it
> > currently impossible to use the combine to recover those optimizations in
> > the
> > vcond{,u,eq}.i.e min/max.
> > In the case of sse 4.1 and above, there is basically no regression anymore.
>
> Maybe it's possible to use a define_insn_and_split for blends w/o SSE 4.1?
> That would allow combine matching the high-level blend operation and
> we'd only lower it afterwards? The question is what we lose in
> combinations of/into the loweredn pand/pandn/por of course.
I'd rather live with those regressions since they're only existed below sse4.1.
>
> Maybe it's possible to catch the higher-level optimization (min/max)
> on the GIMPLE level instead?
For integral part, I believe the optimization is already there at gimple level.
For floating point part, x86 {max,min}{ps,pd} is not ieee-conformant, it's a
exact match of cond_expr a < b ? a : b (w/ consideration of -0.0 and NAN.)
[Bug libstdc++/115514] Nonconforming reverse_iterator::operator->
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115514 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Jonathan Wakely --- (In reply to Jiang An from comment #3) > See > - https://cplusplus.github.io/LWG/issue3725 > - https://cplusplus.github.io/LWG/issue3727 > > If "implicit expression variations" > (https://eel.is/c++draft/concepts.equality#6) apply here, then despite > std::prev returning a non-const prvalue, the behavior of operator-> on such > a prvalue should be required to be same as that on a const lvalue. Yes, Hewill just pointed this out to me too. It does apply here, because the function's constraints have a requires-expression using a const lvalue operand. > But the current standard wording just says > > These implicit expression variations are required to meet the semantic > > requirements of the declared expression. > > It seems that we haven't forbidden the cases where an implicit expression > variation behaves differently while still meeting the semantic requirements. Meh. That will only affect people intentionally doing dumb things, and we already spend too much time tweaking the spec to forbid such things, when we could be doing something more useful. I think we can close this, the libstdc++ implementation is fine.
[Bug tree-optimization/115538] New: wrong-code with SLP vectorization of conversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115538
Bug ID: 115538
Summary: wrong-code with SLP vectorization of conversions
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
When using SLP vectorizable_conversion does
/* Supportable by target? */
switch (modifier)
{
case NONE:
...
/* Check if the intermediate type can hold OP0's range.
When converting from float to integer this is not necessary
because values that do not fit the (smaller) target type are
unspecified anyway. */
if (demotion && float_expr_p)
{
wide_int op_min_value, op_max_value;
if (!vect_get_range_info (op0, &op_min_value, &op_max_value))
break;
if (cvt_type == NULL_TREE
|| (wi::min_precision (op_max_value, SIGNED)
> TYPE_PRECISION (cvt_type))
|| (wi::min_precision (op_min_value, SIGNED)
> TYPE_PRECISION (cvt_type)))
continue;
but that uses op0 from the representative (or error_mark_node in case of
a VEC_PERM_EXPR SLP operand).
No testcase yet.
[Bug tree-optimization/115537] [15 Regression] vectorizable_reduction ICEs after g:d66b820f392aa9a7c34d3cddaf3d7c73bf23f82d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115537 Richard Biener changed: What|Removed |Added Target Milestone|--- |15.0 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2024-06-18 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- I will have a look.
[Bug c/115539] New: Misoptimization of application at -O2 -g on x86-64 causing segfaults on valid memory accesses where it works on both clang and gcc at -g (no -O2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115539 Bug ID: 115539 Summary: Misoptimization of application at -O2 -g on x86-64 causing segfaults on valid memory accesses where it works on both clang and gcc at -g (no -O2) Product: gcc Version: 14.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: melodygoad18 at gmail dot com Target Milestone: --- Hi. I maintain a program that gets misoptimized at -O2 -g on gcc 14.1.1. This wasn't happening on GCC 12 or 13 AFAIR, and it also doesn't happen on Windows. Only on Linux. This also doesn't happen on clang with the same flags or on gcc with simply -g. The problem is in the fastreadl_fetch function, where it crashes on a perfectly valid memory access, but only if it's compiled with gcc 14.1.1 with -O2 -g flags on Linux. gdb is able to access the memory when it crashes too, so it's most likely a compiler bug.
[Bug c/115539] Misoptimization of application at -O2 -g on x86-64 causing segfaults on valid memory accesses where it works on both clang and gcc at -g (no -O2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115539 --- Comment #1 from Andreas Schwab --- Please read https://gcc.gnu.org/bugs/ and follow the instructions.
[Bug tree-optimization/115537] [15 Regression] vectorizable_reduction ICEs after g:d66b820f392aa9a7c34d3cddaf3d7c73bf23f82d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115537
--- Comment #2 from Richard Biener ---
So w/o SLP we reject this with
if ((double_reduc || reduction_type != TREE_CODE_REDUCTION)
&& ncopies > 1)
{
if (dump_enabled_p ())
dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
"multiple types in double reduction or condition "
"reduction or fold-left reduction.\n");
return false;
reduction_type is EXTRACT_LAST_REDUCTION here. For SLP we only disallow
if ((reduction_type == COND_REDUCTION
|| reduction_type == INTEGER_INDUC_COND_REDUCTION
|| reduction_type == CONST_COND_REDUCTION)
&& slp_node
&& SLP_TREE_NUMBER_OF_VEC_STMTS (slp_node) > 1)
{
if (dump_enabled_p ())
dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
"multiple types in condition reduction reduction.\n");
return false;
}
I've recently fixed a fold-left reduction case with multiple types
which we handle just fine. I have a patch amending the above condition
(EXTRACT_LAST is an optimized COND_REDUCTION).
[Bug c/115539] Misoptimization of application at -O2 -g on x86-64 causing segfaults on valid memory accesses where it works on both clang and gcc at -g (no -O2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115539 fuel changed: What|Removed |Added CC||melodygoad18 at gmail dot com --- Comment #2 from fuel --- gcc -v outputs Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/14.1.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /build/gcc/src/gcc/configure --enable-languages=ada,c,c++,d,fortran,go,lto,m2,objc,obj-c++,rust --enable-bootstrap --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://gitlab.archlinux.org/archlinux/packaging/packages/gcc/-/issues --with-build-config=bootstrap-lto --with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit --enable-cet=auto --enable-checking=release --enable-clocale=gnu --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object --enable-libstdcxx-backtrace --enable-link-serialization=1 --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch --disable-werror Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.1.1 20240522 (GCC)
[Bug c/115539] Misoptimization of application at -O2 -g on x86-64 causing segfaults on valid memory accesses where it works on both clang and gcc at -g (no -O2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115539 --- Comment #3 from fuel --- Created attachment 58463 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58463&action=edit Preprocessed source
[Bug libstdc++/115522] [13/14/15 Regression] std::to_array no longer works for struct which is trivial but not default constructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115522 Jonathan Wakely changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=85723 --- Comment #5 from Jonathan Wakely --- Ah, it looks like is_trivial is just wrong for types with a deleted default constructor, that's PR 85723 The std::to_array code _should_ work correctly for this case :-\
[Bug c++/85723] [C++17][DR 1496] __is_trivial intrinsic fails with no trivial non-deleted default c'tor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85723 --- Comment #3 from Jonathan Wakely --- And again, causing PR 115522
[Bug c/115539] Misoptimization of application at -O2 -g on x86-64 causing segfaults on valid memory accesses where it works on both clang and gcc at -g (no -O2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115539 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Your testcase isn't self-contained, there is no main, so there isn't much we can do about it, but from the 220 -Wstrict-aliasing warnings I'd say it is very likely the code violates TBAA just about everywhere. Try -O2 -fno-strict-aliasing? If that helps, most likely it is just bogus code being compiled.
[Bug tree-optimization/115534] intermediate stack use not eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115534 --- Comment #1 from Andrew Pinski --- I suspect there is a dup of this already. See the bug which I made this one blocking for a list of related bugs.
[Bug middle-end/115534] intermediate stack use not eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115534 Andrew Pinski changed: What|Removed |Added Component|tree-optimization |middle-end Severity|normal |enhancement
[Bug c/115539] Misoptimization of application at -O2 -g on x86-64 causing segfaults on valid memory accesses where it works on both clang and gcc at -g (no -O2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115539 --- Comment #5 from Sam James --- fastreadl_fetch in particular looks aliasing unsafe, let alone the rest.
[Bug libstdc++/115522] [13/14/15 Regression] std::to_array no longer works for struct which is trivial but not default constructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115522 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
[Bug c/115539] Misoptimization of application at -O2 -g on x86-64 causing segfaults on valid memory accesses where it works on both clang and gcc at -g (no -O2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115539 --- Comment #6 from Sam James --- (In reply to Sam James from comment #5) > fastreadl_fetch in particular looks aliasing unsafe, let alone the rest. The code looks derived from 86box or similar. They build with -fno-strict-aliasing: https://github.com/86Box/86Box/blob/15d2ee28c7d7f4590f1f69c542081cdb78313b91/cmake/flags-gcc.cmake#L18. You should be building with it too if using code derived from it.
[Bug c/115539] Misoptimization of application at -O2 -g on x86-64 causing segfaults on valid memory accesses where it works on both clang and gcc at -g (no -O2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115539 Sam James changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2024-06-18
[Bug middle-end/115534] intermediate stack use not eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115534 --- Comment #2 from Tamar Christina --- (In reply to Andrew Pinski from comment #1) > I suspect there is a dup of this already. See the bug which I made this one > blocking for a list of related bugs. Most of the other bugs relate to the argument expansions, however this one, regardless of the expansion itself shouldn't need the intermediate stack. I think there are various other ways the operation could have been kept in a gimple register.
[Bug modula2/115540] New: "gcc/m2/mc-boot-ch/Gtermios.cc:292:20: error: return-statement with a value, in function returning 'void' [-fpermissive]" when HAVE_CFMAKERAW is defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115540
Bug ID: 115540
Summary: "gcc/m2/mc-boot-ch/Gtermios.cc:292:20: error:
return-statement with a value, in function returning
'void' [-fpermissive]" when HAVE_CFMAKERAW is defined
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: modula2
Assignee: gaius at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
I got a bootstrap failure on cfarm119 with:
286 /* cfmakeraw - sets the terminal to raw mode. */
287
288 void
289 EXPORT (cfmakeraw) (struct termios *t)
290 {
291 #if defined(HAVE_CFMAKERAW)
292return cfmakeraw (t);
293 #endif
294 }
../../src/gcc/m2/mc-boot-ch/Gtermios.cc: In function 'void
termios_cfmakeraw(termios*)':
../../src/gcc/m2/mc-boot-ch/Gtermios.cc:292:20: error: return-statement with a
value, in function returning 'void' [-fpermissive]
292 | return cfmakeraw (t);
| ~~^~~
Seems to have been present since 1eee94d351774cdc2efc8ee508b82d065184c6ee.
[Bug tree-optimization/115537] [15 Regression] vectorizable_reduction ICEs after g:d66b820f392aa9a7c34d3cddaf3d7c73bf23f82d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115537 --- Comment #3 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:7f9be55a4630134a237219af9cc8143e02080380 commit r15-1407-g7f9be55a4630134a237219af9cc8143e02080380 Author: Richard Biener Date: Tue Jun 18 14:00:52 2024 +0200 tree-optimization/115537 - ICE with SLP condition reduction vectorization The condition rejecting "multiple-type" SLP condition reduction lacks handling EXTRACT_LAST reductions. PR tree-optimization/115537 * tree-vect-loop.cc (vectorizable_reduction): Also reject SLP condition reductions of EXTRACT_LAST kind when multiple statement copies are involved. * gcc.dg/vect/pr115537.c: New testcase.
[Bug tree-optimization/115537] [15 Regression] vectorizable_reduction ICEs after g:d66b820f392aa9a7c34d3cddaf3d7c73bf23f82d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115537 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Richard Biener --- Fixed.
[Bug c++/115501] [13/14/15 Regression] ICE: in build_call_a with dynamic_cast after invalid definition of __cxxabiv1::__dynamic_cast since r13-3299
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115501 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #8 from Marek Polacek --- Good point, I'll test that.
[Bug tree-optimization/115537] [15 Regression] vectorizable_reduction ICEs after g:d66b820f392aa9a7c34d3cddaf3d7c73bf23f82d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115537 --- Comment #5 from Tamar Christina --- Thanks for the fix! I think the testcase needs SVE enabled to ICE no? shouldn't that be -mcpu=neoverse-v1 and not -mcpu=neoverse-n1?
[Bug target/115458] [15 regression] [RISC-V] ICE in lra_split_hard_reg_for, at lra-assigns.cc:1868 unable to find a register to spill since r15-518-g99b1daae18c095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115458 --- Comment #5 from Li Pan --- (In reply to Richard Biener from comment #4) > The bisected rev only exposes this. Thanks Richard for hint, will take a look into it.
[Bug c++/115476] [13/14/15 Regression] __has_unique_object_representation ICE with array of uninstantiated type of unknown bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115476 --- Comment #8 from Marek Polacek --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2024-June/654985.html but I'm not changing __has_trivial_destructor in that patch. That and its kin are extensions: https://gcc.gnu.org/onlinedocs/gcc/Type-Traits.html and I'm not sure I should be changing them. (It appears some of the __has_* built-ins may be deprecated: bug 106085.)
[Bug middle-end/115527] -ftrivial-auto-var-init appears to clobber explicit initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115527 qinzhao at gcc dot gnu.org changed: What|Removed |Added CC||qinzhao at gcc dot gnu.org --- Comment #2 from qinzhao at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #1) > Confirmed. It looks like the option is emitting the code afterwards rather > than before the initializer ... Yes, this is the case, will take a look on why this is happening.
[Bug tree-optimization/115537] [15 Regression] vectorizable_reduction ICEs after g:d66b820f392aa9a7c34d3cddaf3d7c73bf23f82d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115537 --- Comment #6 from rguenther at suse dot de --- > Am 18.06.2024 um 16:11 schrieb tnfchris at gcc dot gnu.org > : > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115537 > > --- Comment #5 from Tamar Christina --- > Thanks for the fix! > > I think the testcase needs SVE enabled to ICE no? > shouldn't that be -mcpu=neoverse-v1 and not -mcpu=neoverse-n1? I intended to copy from the PR options, in case I mistyped feel free to correct > -- > You are receiving this mail because: > You are on the CC list for the bug. > You are the assignee for the bug.
[Bug middle-end/115539] Misoptimization of application at -O2 -g on x86-64 causing segfaults on valid memory accesses where it works on both clang and gcc at -g (no -O2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115539 Andrew Pinski changed: What|Removed |Added Component|c |middle-end Keywords||alias --- Comment #7 from Andrew Pinski --- The places which are just as likely cause strict aliasing issues: geteaw geteal geteaw_mem geteal_mem
[Bug middle-end/115541] New: gcc generates calls to memcpy that violate the memcpy specification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115541
Bug ID: 115541
Summary: gcc generates calls to memcpy that violate the memcpy
specification
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: mikulas at artax dot karlin.mff.cuni.cz
Target Milestone: ---
struct s {
int a[1];
};
void assign(struct s *s1, struct s *s2)
{
*s1 = *s2;
}
compiling it with -O2 results in this:
assign:
subq$8, %rsp
movl$4, %edx
callmemcpy@PLT
addq$8, %rsp
ret
The problem is that when we call the function "assign" with s1 equal to s2, gcc
generates a call to memcpy with overlapping arguments and that violates the C
standard.
Note that if the memcpy implementation uses an instruction such as "DC ZVA" to
zero cache line without reading it from memory, this becomes a practical
problem.
gcc should generate memmove instead of memcpy in this case.
[Bug middle-end/115541] gcc generates calls to memcpy that violate the memcpy specification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115541 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 32667 ***
[Bug middle-end/32667] block copy with exact overlap is expanded as memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667 Andrew Pinski changed: What|Removed |Added CC||mikulas at artax dot karlin.mff.cu ||ni.cz --- Comment #63 from Andrew Pinski --- *** Bug 115541 has been marked as a duplicate of this bug. ***
[Bug fortran/115542] New: Invalid finalization in derived type containing allocatable entities
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115542 Bug ID: 115542 Summary: Invalid finalization in derived type containing allocatable entities Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: federico.perini at gmail dot com Target Milestone: --- Created attachment 58464 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58464&action=edit Finalization test program - Affected versions: gfortran >= 13 - MWE at: https://godbolt.org/z/rvP5qcvEz (also attached) - Possibly related: 110626 When a derived type has at least 3 layers: type(r) - type(q) - type(p) all types finalizable, and at least one "complex" component i.e. allocatable or real(real128), type finalization on the intermediate variables is wrongly called: - twice instead of once - the second time, I believe with a wrong memory address (or at least, with object data containing garbage). It's not in the MWE, but I have user cases where a pointer may become associated due to the invalid values in the second call, which triggers further issues and crashes (i.e. because the finalizer tries to deallocate it). In the attached program, there is an intent(out) argument so finalization should only be called once, as the subroutine enters: enter in-n-out r final ! ok: finalize parent type - q final F ! ok: finalize intermediate type - p final -1 ! ok: finalize 3rd-level scalars - p final -1 ! ok: finalize 3rd-level scalars - p final0 ! WRONG: 2nd-time and wrong value ERROR! ! WRONG: should not be called - p final0 ! WRONG: 2nd-time and wrong value ERROR! ! WRONG: should not be called hello world exit in-n-out Thank you, Federico
[Bug c++/85723] [C++17][DR 1496] __is_trivial intrinsic fails with no trivial non-deleted default c'tor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85723 --- Comment #4 from Andrew Pinski --- (In reply to Jonathan Wakely from comment #3) > And again, causing PR 115522 oh and clang has not implemented this DR either which made me think that was more of a libstdc++ issue :).
[Bug middle-end/32667] block copy with exact overlap is expanded as memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667 --- Comment #64 from Patrick J. LoPresti --- The C (and POSIX) standards have had "restrict" on the arguments to memcpy() since C99. So calling it with overlapping arguments is undefined behavior and always has been. This bug should be trivial to fix by checking for self-assignment before calling memcpy(). Doesn't GCC inline the assignments for small objects anyway? I still have no idea why this is even controversial.
[Bug middle-end/32667] block copy with exact overlap is expanded as memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667 Andrew Pinski changed: What|Removed |Added See Also||https://github.com/llvm/llv ||m-project/issues/17135, ||https://github.com/llvm/llv ||m-project/issues/12135 --- Comment #65 from Andrew Pinski --- (In reply to Patrick J. LoPresti from comment #64) > This bug should be trivial to fix by checking for self-assignment before > calling memcpy(). Doesn't GCC inline the assignments for small objects > anyway?
[Bug c/115543] New: DWARF call_site_parameter entries are not generated for stack-passed parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115543 Bug ID: 115543 Summary: DWARF call_site_parameter entries are not generated for stack-passed parameters Product: gcc Version: 14.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: spevnev16 at gmail dot com Target Milestone: --- When compiling a C function with more than 6 parameters on x86_64, its call_site contains only the first 6 parameters, while the others (which are passed through stack rather than registers) only have formal_parameters in the subprogram DIE. I assume that the number 6 is related to the way parameters are passed on x86_64 (i.e. only 6 are passed through registers) and thus this number may differ based on the architecture. version: 14.1.0 target: x86_64-linux-gnu configured: /usr/src/gcc/configure --build=x86_64-linux-gnu --disable-multilib --enable-languages=c,c++,fortran,go compiled with: gcc -g3 -O1 -Wall -Wextra -pedantic main.c
[Bug c++/85723] [C++17][DR 1496] __is_trivial intrinsic fails with no trivial non-deleted default c'tor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85723 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug c++/115504] [14/15 Regression] Wrong decltype result for a captured reference inside lambda since r14-5330
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115504 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
[Bug middle-end/115534] intermediate stack use not eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115534 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-06-18 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #3 from Andrew Pinski --- Confirmed. Note even without vectorizer turned on we get really bad code from the return when expanding (just happens the RTL optimizers can remove the load/stores but not the stack location): ``` ;; return D.4535; (insn 60 59 61 (set (reg:DF 156) (mem/c:DF (plus:DI (reg/f:DI 95 virtual-stack-vars) (const_int -32 [0xffe0])) [4 D.4535+0 S8 A128])) "/app/example.cpp":24:12 -1 (nil)) (insn 61 60 62 (set (reg:DF 157) (mem/c:DF (plus:DI (reg/f:DI 95 virtual-stack-vars) (const_int -24 [0xffe8])) [4 D.4535+8 S8 A64])) "/app/example.cpp":24:12 -1 (nil)) (insn 62 61 63 (set (reg:DF 158) (mem/c:DF (plus:DI (reg/f:DI 95 virtual-stack-vars) (const_int -16 [0xfff0])) [4 D.4535+16 S8 A128])) "/app/example.cpp":24:12 -1 (nil)) (insn 63 62 64 (set (reg:DF 159) (mem/c:DF (plus:DI (reg/f:DI 95 virtual-stack-vars) (const_int -8 [0xfff8])) [4 D.4535+24 S8 A64])) "/app/example.cpp":24:12 -1 (nil)) (insn 64 63 65 (set (reg:DF 132 [ ]) (reg:DF 156)) "/app/example.cpp":24:12 -1 (nil)) (insn 65 64 66 (set (reg:DF 133 [ +8 ]) (reg:DF 157)) "/app/example.cpp":24:12 -1 (nil)) (insn 66 65 67 (set (reg:DF 134 [ +16 ]) (reg:DF 158)) "/app/example.cpp":24:12 -1 (nil)) (insn 67 66 68 (set (reg:DF 135 [ +24 ]) (reg:DF 159)) "/app/example.cpp":24:12 -1 (nil)) (jump_insn 68 67 69 (set (pc) (label_ref 0)) "/app/example.cpp":24:12 -1 (nil)) ``` On the stack location we get: ``` sub sp, sp, #64 ``` This is why I said there are a few duplicates there ...
[Bug middle-end/115534] intermediate stack use not eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115534 --- Comment #4 from Andrew Pinski --- This might be improved by https://gcc.gnu.org/pipermail/gcc-patches/2024-June/654819.html . Or it might be the case the vectorizer case needs to be improved afterwards. But I think that is the infrastructure for fixing this issue.
[Bug c++/115358] [13/14/15 Regression] template argument deduction/substitution failed in generic lambda function use of static constexpr array type whos initializer defines the size since r13-2540
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115358
Patrick Palka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
Status|NEW |ASSIGNED
--- Comment #7 from Patrick Palka ---
Non-constexpr testcase exhibiting an even older regression (since
r8-2720-gf44a8dd56f5bfb):
template
void f(int (&)[N]);
template
struct A {
static int STR[];
A() { [](auto){ f(STR); }; }
};
template
int A::STR[] = {1,2,3};
A a;
[Bug middle-end/115528] [15 regression] segmentation fault in legacy F77 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115528 kargls at comcast dot net changed: What|Removed |Added CC||kargls at comcast dot net --- Comment #5 from kargls at comcast dot net --- (In reply to Jürgen Reuter from comment #4) > Created attachment 58462 [details] > Input file that triggers the test case with segmentation fault > > This test case needs Whizard 3.1.4 to be downloaded here, > http://whizard.hepforge.org/whizard-3.1.4.tar.gz > I avoided the need for OCaml being present, just do ./configure, make, make > install. This will create a binary whizard, and then execute > whizard tauola_1.sin as attached. ./configure ... checking for OCaml version 408000... test: -ge: unexpected operator < 4.08.0 configure: error: * configure: error: found version , too old! configure: error: *
[Bug debug/115543] DWARF call_site_parameter entries are not generated for stack-passed parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115543 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- That is not a bug, DW_TAG_call_site_parameter is emitted only when it has something relevant to say (like, what value has been passed). If it isn't known how to reconstruct the value or if the compiler is unable to track the value passed to it, it can omit it.
[Bug middle-end/115534] intermediate stack use not eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115534 --- Comment #5 from Tamar Christina --- (In reply to Andrew Pinski from comment #4) > This might be improved by > https://gcc.gnu.org/pipermail/gcc-patches/2024-June/654819.html . Or it > might be the case the vectorizer case needs to be improved afterwards. But I > think that is the infrastructure for fixing this issue. Yeah Richard pointed me to this today as well. The vectorizer case is a bit unique because the vectorizer has packed scalar values in two vector registers. So yeah think it's likely some work will be needed afterwards but will see after the fsra patch lands :)
[Bug middle-end/115544] New: ICE: in lower_complexexpr_stmt, at gimple-lower-bitint.cc:4719 with -O -fno-tree-fre -fno-tree-ccp -fno-tree-forwprop and _BitInt() __builtin_mul_overflow()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115544 Bug ID: 115544 Summary: ICE: in lower_complexexpr_stmt, at gimple-lower-bitint.cc:4719 with -O -fno-tree-fre -fno-tree-ccp -fno-tree-forwprop and _BitInt() __builtin_mul_overflow() Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 58465 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58465&action=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -O -fno-tree-fre -fno-tree-ccp -fno-tree-forwprop testcase.c during GIMPLE pass: bitintlower testcase.c: In function 'foo': testcase.c:5:1: internal compiler error: in lower_complexexpr_stmt, at gimple-lower-bitint.cc:4719 5 | foo() | ^~~ 0xdad936 lower_complexexpr_stmt /repo/gcc-trunk/gcc/gimple-lower-bitint.cc:4719 0xdad936 lower_stmt /repo/gcc-trunk/gcc/gimple-lower-bitint.cc:5708 0x27cf3f1 gimple_lower_bitint /repo/gcc-trunk/gcc/gimple-lower-bitint.cc:6926 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r15-1418-20240618085924-gadadb5c7ba0-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --enable-libsanitizer --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r15-1418-20240618085924-gadadb5c7ba0-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 15.0.0 20240618 (experimental) (GCC)
[Bug c++/96288] [DR 1734] __is_trivial and __is_trivially_copyable fails for deleted members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96288 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2024-06-18
[Bug c++/108769] [C++20] __is_trivial returns true even if a default constructor's constraints are unsatisfied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108769 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org CC||mpolacek at gcc dot gnu.org
[Bug libstdc++/115497] [15 Regression] __is_pointer doesn't compile with clang since 014879ea4c86b3b8ab6b61a1226ee5b31e816c8b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115497 Richard Smith changed: What|Removed |Added CC||richard-gccbugzilla@metafoo ||.co.uk --- Comment #13 from Richard Smith --- (In reply to Jonathan Wakely from comment #10) > The only foolproof fix would be to rename the __is_pointer class template. Yes, given that Clang treats this identifier as a keyword, the best solution would be for libstdc++ to stop using it as a type name. We have an awful hack in Clang to support libstdc++ doing this, and it'd be great to remove that eventually. (I apologize, we should have made this request years ago when we added the hack.) As is evidenced in this bug, this hack was only made to be good enough to support libstdc++ as it existed at the time. I'm not really sure what behavior one would expect from `__is_pointer(_Tp)`, given that it can parse as a type (treating `__is_pointer` as a placeholder for CTAD, which is semantically invalid in this context only because we can't perform CTAD here). We could extend our hack to support this too, but doing so is really a losing proposition. In general, we seem to have organically adopted the convention that `std::blah<...>` type traits correspond to `__blah` keywords, so it'd be great if libstdc++ didn't use any of those identifiers as type names.
[Bug libstdc++/111250] __glibcxx_requires_subscript assertions are not checked during constant evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111250 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
[Bug fortran/115390] Bogus -Wuninitialized warning when using CHARACTER(*) argument in BIND(C) function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115390 anlauf at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #4 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2024-June/060591.html
[Bug libstdc++/103191] vector doesn't have any checks enabled by _GLIBCXX_ASSERTIONS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103191 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |15.0 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug libstdc++/115497] [15 Regression] __is_pointer doesn't compile with clang since 014879ea4c86b3b8ab6b61a1226ee5b31e816c8b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115497 --- Comment #14 from Jonathan Wakely --- I assume clang doesn't have __is_arithmetic, __is_scalar and __is_void built-ins yet, because also defines class templates with those names. At least __are_same, __is_integer and __is_floating don't clash.
[Bug c++/58074] [C++11][DR 1333] __is_trivial intrinsic fails for deleted members and for non-trivial copy-c'tors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58074
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #12 from Marek Polacek ---
I have a patch for the first assert (via bug 85723), and I think the second
assert should also be reversed; that is, I think we want to assert this:
```
struct Trivial
{
Trivial() = delete;
};
struct NonTrivial
{
NonTrivial() = default;
NonTrivial(NonTrivial&) = default;
NonTrivial& operator=(NonTrivial&) = default;
};
static_assert(!__is_trivial(Trivial), "Ouch"); // #1
static_assert(__is_trivial(NonTrivial), "Ouch"); // #2
```
The reason for #1 is https://cplusplus.github.io/CWG/issues/1496.html.
The reason for #2 is https://cplusplus.github.io/CWG/issues/2171.html (after
the https://cplusplus.github.io/CWG/issues/1593.html adjustment).
[Bug tree-optimization/115544] ICE: in lower_complexexpr_stmt, at gimple-lower-bitint.cc:4719 with -O -fno-tree-fre -fno-tree-ccp -fno-tree-forwprop and _BitInt() __builtin_mul_overflow()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115544 Andrew Pinski changed: What|Removed |Added Host|x86_64-pc-linux-gnu | Target|x86_64-pc-linux-gnu |x86_64-pc-linux-gnu ||aarch64-*-* Known to fail||14.1.0 Known to work|14.1.1 | Component|middle-end |tree-optimization --- Comment #1 from Andrew Pinski --- Confirmed. ICEs for me with released GCC 14.1.0 on both x86_64 and aarch64.
[Bug tree-optimization/115544] ICE: in lower_complexexpr_stmt, at gimple-lower-bitint.cc:4719 with -O -fno-tree-fre -fno-tree-ccp -fno-tree-forwprop and _BitInt() __builtin_mul_overflow()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115544 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-06-18 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- .
[Bug middle-end/115528] [15 regression] segmentation fault in legacy F77 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115528 --- Comment #6 from Jürgen Reuter --- (In reply to kargls from comment #5) > (In reply to Jürgen Reuter from comment #4) > > Created attachment 58462 [details] > > Input file that triggers the test case with segmentation fault > > > > This test case needs Whizard 3.1.4 to be downloaded here, > > http://whizard.hepforge.org/whizard-3.1.4.tar.gz > > I avoided the need for OCaml being present, just do ./configure, make, make > > install. This will create a binary whizard, and then execute > > whizard tauola_1.sin as attached. > > ./configure > ... > checking for OCaml version 408000... test: -ge: unexpected operator > < 4.08.0 > configure: error: * > configure: error: found version , too old! > configure: error: * Just do configure with --disable-ocaml.
[Bug middle-end/115528] [15 regression] segmentation fault in legacy F77 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115528 --- Comment #7 from Jürgen Reuter --- First data point: after the commit from Uros, https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=8bb6b2f4ae19c3aab7d7a5e5c8f5965f89d90e01 at Sun, 9 Jun 2024 10:09:13 all was still fine.
[Bug ada/115507] bogus Constraint_Error for Wide_Wide_Value with wide enumeration literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115507 Eric Botcazou changed: What|Removed |Added Summary|'Wide_Wide_Value failed for |bogus Constraint_Error for |unicode strings |Wide_Wide_Value with wide ||enumeration literal Last reconfirmed||2024-06-18 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Eric Botcazou --- System.Val_Util.Normalize_String incorrectly normalizes the input string.
[Bug tree-optimization/115544] ICE: in lower_complexexpr_stmt, at gimple-lower-bitint.cc:4719 with -O -fno-tree-fre -fno-tree-ccp -fno-tree-forwprop and _BitInt() __builtin_mul_overflow()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115544 --- Comment #3 from Andrew Pinski --- Note the gimple stmt/complex_expr in this case: _6 = COMPLEX_EXPR ; where _6 is fully unused. Complex lowering changes: _6 = COMPLEX_EXPR ; _2 = REALPART_EXPR <_6>; into: _6 = COMPLEX_EXPR ; _2 = a.0_1; Which is totally correct though it does not do any DCE. I am not sure if complex lowering should do some simple DCE or if it matters if it does not do it.
[Bug ada/115535] negative value returned by 'Image applied to array with nonnegative integer component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115535 Eric Botcazou changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2024-06-18 Summary|Image attribute on arrays |negative value returned by |of unsigned values |'Image applied to array |incorrectly prints a signed |with nonnegative integer |representation under|component |certain conditions | CC||ebotcazou at gcc dot gnu.org --- Comment #1 from Eric Botcazou --- Build_Elementary_Put_Image_Call uses the signedness of the base type but the size of the first subtype, hence the discrepancy.
[Bug other/115545] New: [15 regression] missing/excess errors after r15-1395-g01044471ea39f9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115545 Bug ID: 115545 Summary: [15 regression] missing/excess errors after r15-1395-g01044471ea39f9 Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:01044471ea39f9be4803c583ef2a946abc657f99, r15-1395-g01044471ea39f9 Seeing this on powerpc64 BE systems. FAIL: gcc.dg/c23-tag-enum-6.c (test for errors, line 10) FAIL: gcc.dg/c23-tag-enum-6.c (test for errors, line 13) FAIL: gcc.dg/c23-tag-enum-7.c (test for excess errors) FAIL: gcc.dg/pr115109.c (test for excess errors) commit 01044471ea39f9be4803c583ef2a946abc657f99 (HEAD) Author: Richard Sandiford Date: Tue Jun 18 12:22:30 2024 +0100 Make force_subreg emit nothing on failure Looks like it is missing some errors spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test2/gcc/ /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.dg/c23-tag-enum-6.c -m32 -fdiagnostics-plain-output -std=c23 -fno-short-enums -S -o c23-tag-enum-6.s /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.dg/c23-tag-enum-6.c:16:24: error: value of redeclared enumerator outside the range of 'enum F' /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.dg/c23-tag-enum-6.c:15:10: note: previous definition of 'A' with type 'enum F' /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.dg/c23-tag-enum-6.c:19:39: error: overflow in enumeration values compiler exited with status 1 FAIL: gcc.dg/c23-tag-enum-6.c (test for errors, line 10) FAIL: gcc.dg/c23-tag-enum-6.c (test for errors, line 13) PASS: gcc.dg/c23-tag-enum-6.c (test for errors, line 16) PASS: gcc.dg/c23-tag-enum-6.c (test for errors, line 19) And has excess errors spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test2/gcc/ exceptions_enabled727535.cc -m32 -fdiagnostics-plain-output -Wno-complain-wrong-lang -S -o exceptions_enabled727535.s FAIL: gcc.dg/c23-tag-enum-7.c (test for excess errors) Excess errors: /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.dg/c23-tag-enum-7.c:15:18: warning: left shift count >= width of type [-Wshift-count-overflow] /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.dg/c23-tag-enum-7.c:16:24: error: '_Generic' selector of type 'int' is not compatible with any association /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.dg/c23-tag-enum-7.c:16:15: error: expression in static assertion is not an integer /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.dg/c23-tag-enum-7.c:17:24: error: '_Generic' selector of type 'int' is not compatible with any association /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.dg/c23-tag-enum-7.c:17:15: error: expression in static assertion is not an integer /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.dg/c23-tag-enum-7.c:18:18: warning: left shift count >= width of type [-Wshift-count-overflow] /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.dg/c23-tag-enum-7.c:18:39: error: conflicting redeclaration of enumerator 'd' /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.dg/c23-tag-enum-7.c:18:39: error: conflicting redefinition of enum 'enum H' /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.dg/c23-tag-enum-7.c:19:24: error: '_Generic' selector of type 'int' is not compatible with any association /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.dg/c23-tag-enum-7.c:19:15: error: expression in static assertion is not an integer /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.dg/c23-tag-enum-7.c:20:24: error: '_Generic' selector of type 'int' is not compatible with any association /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.dg/c23-tag-enum-7.c:20:15: error: expression in static assertion is not an integer /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.dg/c23-tag-enum-7.c:23:71: error: '_Generic' selector of type 'long long unsigned int' is not compatible with any association /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.dg/c23-tag-enum-7.c:33:61: error: '_Generic' selector of type 'long long int' is not compatible with any association spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test2/gcc/ exceptions_enabled730621.cc -m32 -fdiagnostics-plain-output -Wno-complain-wrong-lang -S -o exceptions_enabled730621.s FAIL: gcc.dg/pr115109.c (test for excess errors) Excess errors: /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.dg/pr115109.c:7:54: error: '_Generic' selector of type 'int' is not compatible with any association /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.dg/pr115109.c:7:41: error: conflicting redeclaration of enumerator 'b' /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.dg/pr115109.c:7:62: error: conflicting redefinition of enum 'enum E'
[Bug libstdc++/115497] [15 Regression] __is_pointer doesn't compile with clang since 014879ea4c86b3b8ab6b61a1226ee5b31e816c8b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115497 --- Comment #15 from Richard Smith --- (In reply to Jonathan Wakely from comment #14) > I assume clang doesn't have __is_arithmetic, __is_scalar and __is_void > built-ins yet, because also defines class templates > with those names. Clang has all of those (https://github.com/llvm/llvm-project/blob/12cf0dc685a9c3adfefc3a58f0b8ed4360be8b14/clang/include/clang/Basic/TokenKinds.def#L552), but it looks like happens to not use them in a way that breaks. The specific problem with __is_pointer in is that it's being used in a template argument: : public __bool_constant<__is_pointer(_Tp)> ... where it would be valid to parse a type. Clang's hack to treat `__is_pointer(T)` as the builtin (after we've seen a declaration using the same name) only applies in contexts where we know we're parsing an expression. (We can fix this, but I think the healthier thing long-term is to treat these as keywords everywhere.)
[Bug other/115545] [15 regression] missing/excess errors after r15-1394
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115545 Andrew Pinski changed: What|Removed |Added Summary|[15 regression] |[15 regression] |missing/excess errors after |missing/excess errors after |r15-1395-g01044471ea39f9|r15-1394 CC|rsandifo at gcc dot gnu.org|muecker at gwdg dot de --- Comment #1 from Andrew Pinski --- FAIL: gcc.dg/c23-tag-enum-6.c (test for errors, line 10) FAIL: gcc.dg/c23-tag-enum-6.c (test for errors, line 13) FAIL: gcc.dg/c23-tag-enum-7.c (test for excess errors) FAIL: gcc.dg/pr115109.c (test for excess errors) Was definitely introduced by the patch before you mentioned: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=c9b96a68860bfdee49d40b4a844af7c5ef69cd12 They fail with -m32 just like x86_64 too: https://gcc.gnu.org/pipermail/gcc-patches/2024-June/654984.html
[Bug c++/115546] New: [14.1.0 Regression] Section Type Conflict Error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115546
Bug ID: 115546
Summary: [14.1.0 Regression] Section Type Conflict Error
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nikhilg1 at uci dot edu
Target Milestone: ---
Consider the following reduced test case:
$>cat test.cpp
template
int v2 __attribute__((section("A"))) = sizeof(T);
template <>
int v2 __attribute__((section("A"))) = 50;
void a(int*& x) {
x = &v2;
}
$>g++-13 -c test.cpp && echo OK
OK
$>g++-14 -c test.cpp && echo OK
test.cpp:2:5: error: 'v2' causes a section type conflict with 'v2'
2 | int v2 __attribute__((section("A"))) = sizeof(T);
| ^~
test.cpp:5:5: note: 'v2' was declared here
5 | int v2 __attribute__((section("A"))) = 50;
| ^~
$>clang++-17 -c test.cpp && echo OK
OK
I am looking through the docs on the section attribute
(https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gcc/Common-Variable-Attributes.html)
but am not able to see any reason why this case has started to fail. I also
don't see any other compiler failing for this case.
Issue is occurring since g++ 14.1.0 and seems to be reproducible on trunk as
well.
[Bug testsuite/115545] [15 regression] missing/excess errors after r15-1394
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115545 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |15.0
[Bug target/101324] powerpc64le: hashst appears before mflr at -O1 or higher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101324 --- Comment #27 from Peter Bergner --- FYI, as part of the work for PR114759, I have come to the conclusion that disabling shrink-wrapping in the presence of -mrop-protect is a big hammer and we shouldn't really need to do that. I plan on "fixing" that as part of my PR114759 work.
[Bug testsuite/115545] [15 regression] missing/excess errors after r15-1394
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115545
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-06-18
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #2 from Andrew Pinski ---
>enum H { x = 2UL + UINT_MAX }; /* { dg-error "outside the range" } */
UL should most likely be ULL here.
or require lp64 target.
and yes this is just a testsuite issue. Because on ILP32 targets, `unsigned
long` is the same as `unsigned int` so obvious they won't fail.
NOTE there are also LLP64 targets where long is still the same size as int.
[Bug target/114759] Power: multiple issues with -mrop-protect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114759 Peter Bergner changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-June/65 ||5028.html --- Comment #6 from Peter Bergner --- Updated patch for item 2. submitted.
[Bug c++/115546] [14.1.0 Regression] Section Type Conflict Error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115546 --- Comment #1 from Andrew Pinski --- the section attribute was ignored before GCC 14.
[Bug c++/115546] [14.1.0 Regression] Section Type Conflict Error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115546 --- Comment #2 from Andrew Pinski --- But starting with GCC 14, they are not ignored. In this case you have one variable that is in a comdat section named "A" and another one which is in a regular section named "A" which conflict.
[Bug c++/115546] [14.1.0 Regression] Section Type Conflict Error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115546 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=87178 --- Comment #3 from Andrew Pinski --- The reason why this is invalid is for the same reason why PR 87178 is invalid.
[Bug c++/41091] Using section attribute in c and c++ function causes section type conflict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41091 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #12 from Andrew Pinski --- See PR 87178. *** This bug has been marked as a duplicate of bug 87178 ***
[Bug c++/87178] Compilation failure when program contains multiple variables allocated in particular section, and at least one variable is C++17 "inline"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87178 Andrew Pinski changed: What|Removed |Added CC||mark at gcc dot gnu.org --- Comment #9 from Andrew Pinski --- *** Bug 41091 has been marked as a duplicate of this bug. ***
[Bug c++/115546] [14.1.0 Regression] Section Type Conflict Error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115546 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Andrew Pinski --- See PR 87178 on why this is invalid. *** This bug has been marked as a duplicate of bug 87178 ***
[Bug c++/87178] Compilation failure when program contains multiple variables allocated in particular section, and at least one variable is C++17 "inline"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87178 Andrew Pinski changed: What|Removed |Added CC||nikhilg1 at uci dot edu --- Comment #10 from Andrew Pinski --- *** Bug 115546 has been marked as a duplicate of this bug. ***
[Bug target/101017] ICE: Segmentation fault, convert_memory_address_addr_space_1 with vector_size(32) and target_clone arch=core-avx2/default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101017 --- Comment #8 from Haochen Jiang --- One potential solution is to let the resolver ISA level becomes the highest one in target_clones instead of the default one. Then it will not get the memory/register mismatch when passing/returning arguments.
