[Bug tree-optimization/112392] `a == nonnegative ? a : abs` -> abs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112392 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=111957 Last reconfirmed||2023-11-05 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- This is related to PR 111957. For positive values this would catch it too.
[Bug tree-optimization/112392] New: `a == nonnegative ? a : abs` -> abs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112392
Bug ID: 112392
Summary: `a == nonnegative ? a : abs` -> abs
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: pinskia at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
```
int f(int a, unsigned char b)
{
int absb = b;
if (a == absb) return absb;
return a > 0 ? a : -a;
}
```
This should just be turned into
`return ABS_EXPR;`
as we know that if a was a nonnegative value, then taking the ABS of that is
the same as a.
So something like:
```
(for cmp (eq gt ge)
(simplify
(cond (cmp:c @0 tree_expr_nonnegative_p@1) @0 (abs@3 @0))
(if (INTEGRAL_TYPE_P (type))
@3))
```
`a > nonnegative ? a : abs` is also just `abs` too.
There are some more improvements dealing with type changing between signed and
unsigned but this is the first step.
[Bug c/112391] inline-asm documentation wording for implicitly volatile can be cause confusion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112391 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-11-05 Status|UNCONFIRMED |ASSIGNED
[Bug c/112391] New: inline-asm documentation wording for implicitly volatile can be cause confusion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112391 Bug ID: 112391 Summary: inline-asm documentation wording for implicitly volatile can be cause confusion Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: c Assignee: pinskia at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- Reading: https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Extended-Asm.html https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html It current reads: ``` asm statements that have no output operands and asm goto statements, are implicitly volatile. ``` this can be slightly confusing is the requirement that the asm statement has no output operands and an asm goto or is it both are implicitly volatile. Knowing GCC and fixing PR 103979 (asm goto with output operands) myself, I know this is supposed to be it is both get added the volatile: * asm statements with no output operands * asm goto statements
[Bug tree-optimization/112390] New: `!(A & INT_MIN) & !!(A & INT_MAX)` is not optimized to `A > 0`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112390
Bug ID: 112390
Summary: `!(A & INT_MIN) & !!(A & INT_MAX)` is not optimized to
`A > 0`
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
```
void fn();
void test(unsigned *d) {
int is_negative = *d & 0x8000;
if (!is_negative & !!(*d & 0x7fff)) {
fn();
}
}
void test1(unsigned *d) {
int is_negative = *d & 0x8000;
if (!is_negative && !!(*d & 0x7fff)) {
fn();
}
}
```
We are able to optimize test1 but not test at -O2. In this case we would need
some pattern matching I think.
[Bug tree-optimization/112389] `(x | z) < (x >> y)` should be optimized to 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112389 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Keywords||missed-optimization
[Bug tree-optimization/112389] New: `(x | z) < (x >> y)` should be optimized to 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112389
Bug ID: 112389
Summary: `(x | z) < (x >> y)` should be optimized to 0
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
```
unsigned f(unsigned x, unsigned y, unsigned z)
{
return (x | z) < (x >> y);
}
unsigned g(unsigned x, unsigned y, unsigned z)
{
return (x) < (x >> y);
}
```
We can optimize g during EVRP (and dom) to 0. But we could in theory pattern
match f and g too.
[Bug target/112388] New: clear_cache vs cores with different cache line sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112388 Bug ID: 112388 Summary: clear_cache vs cores with different cache line sizes Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- This is the equivalent issue filed on LLVM side: https://github.com/llvm/llvm-project/issues/70791 To get thoughts on ways of fixing this. But basically sometimes different cores have different cache line sizes to invalide the cache. And the sizes might change between runs of the function. The only way I think we can fix this for Linux would to have a system call. for other OS, we just need to suffer unless they provide a new method if the different cache line sizes could appear.
[Bug c/112387] New: RISC-V: failed to SLP INT64 gather load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112387
Bug ID: 112387
Summary: RISC-V: failed to SLP INT64 gather load
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: juzhe.zhong at rivai dot ai
Target Milestone: ---
https://godbolt.org/z/beq8TcGKe
Consider this following case:
void
f (int *restrict y, int *restrict x,
int *restrict indices, int n)
{
for (int64_t i = 0; i < n; ++i)
{
y[i * 2] = x[indices[i * 2]] + 1;
y[i * 2 + 1] = x[indices[i * 2 + 1]] + 2;
}
}
Current RVV GCC can SLP:
vsetvli zero,a5,e32,m1,ta,ma
vle32.v v1,0(a2)
vsetvli t4,zero,e64,m2,ta,ma
vsext.vf2 v2,v1
vsll.vi v2,v2,2
vsetvli zero,a5,e32,m1,ta,ma
vluxei64.v v2,(a1),v2
vsetvli t1,zero,e32,m1,ta,ma
vadd.vv v2,v2,v4
vsetvli zero,a5,e32,m1,ta,ma
vse32.v v2,0(a0)
add a3,a3,t5
add a2,a2,a6
add a0,a0,a6
bgtua7,a4,.L4
However if we change int -> uint64_t, it failed:
void
f2 (uint64_t *restrict y, uint64_t *restrict x,
uint64_t *restrict indices, uint64_t n)
{
for (int64_t i = 0; i < n; ++i)
{
y[i * 2] = x[indices[i * 2]] + 1;
y[i * 2 + 1] = x[indices[i * 2 + 1]] + 2;
}
}
vsetvli a5,a3,e64,m1,ta,ma
vlseg2e64.v v2,(a2) -> unexpected
sllia4,a5,4
vsll.vi v4,v2,3
vsll.vi v1,v3,3
vluxei64.v v4,(a1),v4
vluxei64.v v1,(a1),v1
vadd.vi v2,v4,1
vadd.vi v3,v1,2
sub a3,a3,a5
vsseg2e64.v v2,(a0) -> unexpected
add a2,a2,a4
add a0,a0,a4
bne a3,zero,.L10
ARM SVE is able to SLP both of them.
I was thinking it was fixed by this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635084.html
But turns out we are still missing something. It can only succeed on int,
failed on int64_t
[Bug tree-optimization/112386] New: `CMP0 && CMP1 && CMP2` is better optimized than `CMP0 & CMP1 & CMP2`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112386
Bug ID: 112386
Summary: `CMP0 && CMP1 && CMP2` is better optimized than `CMP0
& CMP1 & CMP2`
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
```
_Bool foo(int x, int y, int z) {
return (z >= 0) & (x >= y + z) & (x >= y);
}
_Bool foo1(int x, int y, int z) {
return (z >= 0) && (x >= y + z) && (x >= y);
}
```
In foo1, we can optimize away the `x >= y` in VRP but foo is not optimized
away.
[Bug tree-optimization/112385] `(2 >> a) ^ (5 >> a)` is not optimized to `7 >> a` is 2 and 5 differ in signedness
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112385
--- Comment #2 from Andrew Pinski ---
We can even do it if we know the unsigned value does not have the last bit set.
That is:
```
int f(int a, unsigned b, int c)
{
b &= 0x;
return (c >> a) ^ (b >> a);
}
```
Note clang(LLVM) does not handle the above.
The way LLVM handles the others is it changes ashift to lshift if the value is
known to be non-negative. But since in the gimple level we are dealing with
types we can't do that in a nice way; RTL level on the other hand yes that can
be done (though nonzero bits is limited there).
[Bug libbacktrace/112263] [C++23] std::stacktrace does not identify symbols in shared library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112263 --- Comment #11 from Ian Lance Taylor --- vincenzo: the patch in the linked e-mail is the complete diff. There are no changes to generated Makefile.in files.
[Bug tree-optimization/112385] `(2 >> a) ^ (5 >> a)` is not optimized to `7 >> a` is 2 and 5 differ in signedness
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112385
--- Comment #1 from Andrew Pinski ---
Note a more complex case like:
```
int f(int a, unsigned b, int c)
{
c &= 0x;
return (c >> a) ^ (b >> a);
}
```
Should also be optimized to:
```
int f(int a, unsigned b, int c)
{
c &= 0x;
return (c^b) >> a;
}
```
That is if both are known to be non-negative we can do the combining.
[Bug tree-optimization/112385] New: `(2 >> a) ^ (5 >> a)` is not optimized to `7 >> a` is 2 and 5 differ in signedness
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112385
Bug ID: 112385
Summary: `(2 >> a) ^ (5 >> a)` is not optimized to `7 >> a` is
2 and 5 differ in signedness
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
```
int f(int a)
{
return (2 >> a) ^ (5u >> a);
}
```
This should be optimized to:
```
return (7 >> a);
```
But currently does not.
[Bug target/85592] __builtin_cpu_is and __builtin_cpu_supports should be supported for aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85592 --- Comment #2 from Andrew Pinski --- clang support: https://reviews.llvm.org/D153153
[Bug testsuite/77635] load/store pair testcases need to use -mcpu=generic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77635 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED Target Milestone|--- |7.0 --- Comment #2 from Andrew Pinski --- .
[Bug target/112384] a non-constant vec dup should be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112384
--- Comment #1 from Andrew Pinski ---
Oh f2 just goes to memory.
Produces:
```
and x0, x0, 3
str q0, [sp]
ldr s0, [sp, x0, lsl 2]
dup v0.4s, v0.s[0]
```
Now clang(LLVM) produces:
```
mov x8, sp
and w9, w0, #0x3
str q0, [sp]
orr x8, x8, x9, lsl #2
ld1r{ v0.4s }, [x8]
```
I don't know which is better but it might be the case where GCC's is better for
some micro-arch.
[Bug target/112384] New: a non-constant vec dup should be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112384
Bug ID: 112384
Summary: a non-constant vec dup should be improved
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Target: aarch64
Take:
```
#define vector __attribute__((vector_size(16)))
vector int f1(vector int t, int i)
{
i&=3;
vector int tt = {i, i, i, i};
vector int r = __builtin_shuffle(t, tt);
return r;
}
vector int f2(vector int t, int i)
{
i&=3;
i = t[i];
vector int tt = {i, i, i, i};
return tt;
}
```
Both of these give not so good code generation.
f1 has:
```
dup v31.4s, w0
...
shl v31.4s, v31.4s, 2
tbl v31.16b, {v31.16b}, v28.16b
add v31.16b, v31.16b, v29.16b
```
But we could do better by combing the dup and the shl into.
For RTL level:
Trying 11 -> 12:
11: r98:V4SI=vec_duplicate(r92:SI)
REG_DEAD r92:SI
12: r101:V4SI=r98:V4SI<
[Bug target/111907] ICE: in curr_insn_transform, at lra-constraints.cc:4294 unable to generate reloads for: {*andnottf3} with -mavx512f -mno-evex512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111907 Andrew Pinski changed: What|Removed |Added CC||haochen.jiang at intel dot com --- Comment #3 from Andrew Pinski --- Something is not being disabled correctly with -mno-evex512 or something is not being enabled correctly. TF mode is valid for SSE ...
[Bug target/111907] ICE: in curr_insn_transform, at lra-constraints.cc:4294 unable to generate reloads for: {*andnottf3} with -mavx512f -mno-evex512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111907 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2023-11-04 --- Comment #2 from Andrew Pinski --- .
[Bug target/111907] ICE: in curr_insn_transform, at lra-constraints.cc:4294 unable to generate reloads for: {*andnottf3} with -mavx512f -mno-evex512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111907
Andrew Pinski changed:
What|Removed |Added
Summary|ICE: in |ICE: in
|curr_insn_transform, at |curr_insn_transform, at
|lra-constraints.cc:4294 |lra-constraints.cc:4294
|unable to generate reloads |unable to generate reloads
|for: {*andnottf3} with |for: {*andnottf3} with
|-mavx512f -mno-evex512 |-mavx512f -mno-evex512
|-mbionic|
--- Comment #1 from Andrew Pinski ---
Simplified testcase:
```
_Float128
foo (_Float128 d, _Float128 e)
{
return __builtin_copysignf128 (d, e);
}
```
Just use `-mavx512f -mno-evex512` . No reason for the `-mbionic` here (which
changes `long double` into the IEEE128 bit long double rather than the 90bit
long double.
[Bug middle-end/112383] New: `a&=CST; (a) != a` and `((~b) & a) & CST != 0`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112383
Bug ID: 112383
Summary: `a&=CST; (a) != a` and `((~b) & a) & CST != 0`
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
```
int f1(unsigned a, unsigned b)
{
a &= 0x11;
return (a) != a;
}
int f2(unsigned a, unsigned b)
{
int d = 0x11;
int e = (~b) & a;
return (e) != 0;
}
```
These 2 should produce the same code.
Likewise for:
```
int fn1(unsigned a, unsigned b, unsigned c)
{
a &= c;
return (a) != a;
}
int fn2(unsigned a, unsigned b, unsigned c)
{
int d = c;
int e = (~b) & a;
return (e) != 0;
}
```
Note clang (LLVM) only produces the same code for f1/f2 pair, it misses the
Canonicalization for fn1/fn2 too.
Note for gimple f1/fn1 is simplier and most likely should be canonical.
[Bug tree-optimization/112093] (X & Y) < X (unsigned) and (X & Y) != X should produce the same code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112093 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-11-04 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org --- Comment #2 from Andrew Pinski --- (for cmp (lt ge le gt ) bop (bit_and bit_and bit_ior bit_ior) rcmp (ne eq eq ne ) (simplify (cmp (bop@2 @0 @1) @0) (if (tree_expr_nonnegative_p (@0) && (bop == BIT_AND || tree_expr_nonnegative_p (@1))) (rcmp @2 @0 I have not looked into what is needed for the IOR case for !tree_expr_nonnegative_p (@1) yet but I suspect it is similar to what I did for PR 101590. Anyways mine.
[Bug middle-end/112382] New: `(a) != a` where a is known to have one known bit set is not optimized to ((~b)>>shift) & 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112382
Bug ID: 112382
Summary: `(a) != a` where a is known to have one known bit
set is not optimized to ((~b)>>shift) & 1
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
```
int f(int a, int b)
{
a &= 0x10;
return (a) < a;
}
int f1(unsigned a, unsigned b)
{
a &= 0x10;
return (a) != a;
}
int f2(unsigned a, unsigned b)
{
a &= 0x10;
unsigned c = (a) ^ a;
return c>>4;
}
int f3(unsigned a, unsigned b)
{
unsigned c = (~b)
return (c>>4) & 1;
}
```
These all should produce the same code. Right now f2 and f3 produce the best
code on x86 (especially with BMI enabled) and aarch64
note f to f1 is really PR 112093 .
[Bug tree-optimization/110903] [12/13 Regression] Dead Code Elimination Regression since r12-4526-gd8edfadfc7a979
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110903 Andrew Pinski changed: What|Removed |Added Target Milestone|12.4|14.0 --- Comment #7 from Andrew Pinski --- Fixed. I doubt this missed optimization patch can be backported so closing as fixed. Maybe it would be good to have a testcase committed for both cases though.
[Bug tree-optimization/110903] [12/13 Regression] Dead Code Elimination Regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110903 --- Comment #6 from Thomas Koenig --- The original regression was caused by r12-4526-gd8edfadfc7a979 . d8edfadfc7a9795b65177a50ce44fd348858e844 is the first bad commit commit d8edfadfc7a9795b65177a50ce44fd348858e844 Author: Aldy Hernandez Date: Mon Oct 4 09:47:02 2021 +0200 Disallow loop rotation and loop header crossing in jump threaders. There is a lot of fall-out from this patch, as there were many threading tests that assumed the restrictions introduced by this patch were valid. Some tests have merely shifted the threading to after loop optimizations, but others ended up with no threading opportunities at all. Surprisingly some tests ended up with more total threads. It was a crapshoot all around. On a postive note, there are 6 tests that no longer XFAIL, and one guality test which now passes. I felt a bit queasy about such a fundamental change wrt threading, so I ran it through my callgrind test harness (.ii files from a bootstrap). There was no change in overall compilation, DOM, or the VRP threaders. However, there was a slight increase of 1.63% in the backward threader. I'm pretty sure we could reduce this if we incorporated the restrictions into their profitability code. This way we could stop the search when we ran into one of these restrictions. Not sure it's worth it at this point. Tested on x86-64 Linux. Co-authored-by: Richard Biener
[Bug modula2/111956] Many powerpc platforms do _not_ have support for IEEE754 long double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111956 --- Comment #5 from Maciej W. Rozycki --- Hmm, this seems awkward to me. It won't work AFAICT with the usual native bootstrap environment, where you just run: $ /path/to/configure && make bootstrap and it won't work where you have an old version of glibc installed and build with: $ /path/to/configure --with-cpu=power10 && make bootstrap either. Shouldn't this just use the same check that libstdc++ does? See the piece starting with: # Check for IEEE128 support in libm. in libstdc++-v3/configure.ac. Maybe you just need to check for the presence of `__frexpieee128' and ignore the rest, as you don't seem to be willing to provide support for the IBM long double format in libgm2, or do you?
[Bug target/112381] [14 regression] ICE when building Mesa (in reload, internal compiler error: in lra_split_hard_reg_for)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112381 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #7 from Andrew Pinski --- Fixed.
[Bug target/112381] [14 regression] ICE when building Mesa (in reload, internal compiler error: in lra_split_hard_reg_for)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112381 --- Comment #6 from Kostadin --- (In reply to Andrew Pinski from comment #5) > (In reply to Kostadin from comment #4) > > This is the first commit where it doesn't ICE. I reverted it from master, > > and it did start ICEing again. > > Does the ICE start at f08ca5903c7 ? If so this was the fix for that. It does indeed start there, just tested that commit (r14-4835-gf08ca5903c7a02), and it does ICE, and the one before it: r14-4834-gdbde384bd56f07, which doesn't ICE. So, I think we are all clear here.
[Bug rtl-optimization/112380] [14 regression] ICE when building Mesa (in combine, internal compiler error: in simplify_subreg) since r14-4612-g6decda1a35be57
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112380
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-11-04
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #8 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #7)
> That almost definitely just exposed the issue. Let me see if I can get a
> testcase that fails without depending on that.
New testcase which seems to have the same IR going into expand for GCC 13.2.0
and the trunk:
```
struct ureg_src {
unsigned File : 4;
unsigned : 2;
unsigned : 2;
unsigned : 2;
unsigned : 1;
unsigned IndirectFile : 4;
unsigned IndirectSwizzle : 2;
int : 16;
int : 6;
int : 16;
int : 16;
unsigned : 10;
} __trans_tmp_1;
int hh, nn;
void ureg_scalar(struct ureg_src);
void ntt_emit_texture_instr() {
struct ureg_src sampler;
unsigned char *t = ((char*));
unsigned char t1;
unsigned t2, t3;
if (nn) {
sampler = __trans_tmp_1;
t1 = *t;
t2 = sampler.IndirectFile;
t3 = sampler.IndirectSwizzle;
}
struct ureg_src reg = sampler;
*t = t1;
ureg_scalar(reg);
}
```
[Bug rtl-optimization/112380] [14 regression] ICE when building Mesa (in combine, internal compiler error: in simplify_subreg) since r14-4612-g6decda1a35be57
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112380 --- Comment #7 from Andrew Pinski --- (In reply to Sam James from comment #6) > bisect says: > > commit r14-4612-g6decda1a35be57 > Author: Richard Biener > Date: Thu Oct 12 11:34:57 2023 +0200 > > tree-optimization/111779 - Handle some BIT_FIELD_REFs in SRA That almost definitely just exposed the issue. Let me see if I can get a testcase that fails without depending on that.
[Bug target/112381] [14 regression] ICE when building Mesa (in reload, internal compiler error: in lra_split_hard_reg_for)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112381 --- Comment #5 from Andrew Pinski --- (In reply to Kostadin from comment #4) > This is the first commit where it doesn't ICE. I reverted it from master, > and it did start ICEing again. Does the ICE start at f08ca5903c7 ? If so this was the fix for that. > > commit r14-5001-g8111b5c23bd14f > Author: Haochen Gui > Date: Mon Oct 30 10:59:51 2023 +0800 > > Expand: Checking available optabs for scalar modes in by pieces > operations > > The former patch (f08ca5903c7) examines the scalar modes by target > hook scalar_mode_supported_p. It causes some i386 regression cases > as XImode and OImode are not enabled in i386 target function. This > patch examines the scalar mode by checking if the corresponding optabs > are available for the mode. > > gcc/ > PR target/111449 > * expr.cc (qi_vector_mode_supported_p): Rename to... > (by_pieces_mode_supported_p): ...this, and extends it to do > the checking for both scalar and vector mode. > (widest_fixed_size_mode_for_size): Call > by_pieces_mode_supported_p to examine the mode. > (op_by_pieces_d::smallest_fixed_size_mode_for_size): Likewise. > > gcc/expr.cc | 23 +-- > 1 file changed, 13 insertions(+), 10 deletions(-)
[Bug c/111810] rtlFE: nested inline RTL function cause ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111810
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-11-04
Status|UNCONFIRMED |NEW
Summary|GCC-14 segfault: error: |rtlFE: nested inline RTL
|expected declaration or |function cause ICE
|statement at end of input |
Ever confirmed|0 |1
--- Comment #1 from Andrew Pinski ---
Just like the gimple front-end, the RTL level front-end is for internal
testing.
Reduced testcase:
```
void j() {inline void __RTL test(void) {}}
```
[Bug rtl-optimization/112380] [14 regression] ICE when building Mesa (in combine, internal compiler error: in simplify_subreg) since r14-4612-g6decda1a35be57
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112380 Sam James changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Summary|[14 regression] ICE when|[14 regression] ICE when |building Mesa (in combine, |building Mesa (in combine, |internal compiler error: in |internal compiler error: in |simplify_subreg)|simplify_subreg) since ||r14-4612-g6decda1a35be57 --- Comment #6 from Sam James --- bisect says: commit r14-4612-g6decda1a35be57 Author: Richard Biener Date: Thu Oct 12 11:34:57 2023 +0200 tree-optimization/111779 - Handle some BIT_FIELD_REFs in SRA
[Bug target/112381] [14 regression] ICE when building Mesa (in reload, internal compiler error: in lra_split_hard_reg_for)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112381 --- Comment #4 from Kostadin --- This is the first commit where it doesn't ICE. I reverted it from master, and it did start ICEing again. commit r14-5001-g8111b5c23bd14f Author: Haochen Gui Date: Mon Oct 30 10:59:51 2023 +0800 Expand: Checking available optabs for scalar modes in by pieces operations The former patch (f08ca5903c7) examines the scalar modes by target hook scalar_mode_supported_p. It causes some i386 regression cases as XImode and OImode are not enabled in i386 target function. This patch examines the scalar mode by checking if the corresponding optabs are available for the mode. gcc/ PR target/111449 * expr.cc (qi_vector_mode_supported_p): Rename to... (by_pieces_mode_supported_p): ...this, and extends it to do the checking for both scalar and vector mode. (widest_fixed_size_mode_for_size): Call by_pieces_mode_supported_p to examine the mode. (op_by_pieces_d::smallest_fixed_size_mode_for_size): Likewise. gcc/expr.cc | 23 +-- 1 file changed, 13 insertions(+), 10 deletions(-)
[Bug c/111816] [gimple FE] ICE with _GIMPLE(ssa) and 2 returns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111816
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2023-11-04
Ever confirmed|0 |1
--- Comment #3 from Andrew Pinski ---
Confirmed.
/* We have a CFG. Build the edges. */
for (unsigned i = 0; i < parser.edges.length (); ++i)
{
edge e = make_edge (BASIC_BLOCK_FOR_FN (cfun, parser.edges[i].src),
BASIC_BLOCK_FOR_FN (cfun, parser.edges[i].dest),
parser.edges[i].flags);
e->probability = parser.edges[i].probability;
}
make_edge is returning NULL.
[Bug c/111809] gimpleFE: unreferenced inline function with _GIMPLE(ssa) definition causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111809
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-11-04
Keywords|error-recovery, |
|ice-on-invalid-code |
Status|UNCONFIRMED |NEW
Summary|GIMPLEFE: ICE after `SSA|gimpleFE: unreferenced
|name '' with |inline function with
|version 3 has no|_GIMPLE(ssa) definition
|definition` |causes ICE
Ever confirmed|0 |1
--- Comment #2 from Andrew Pinski ---
Reduced testcase:
```
inline
__GIMPLE (ssa) void
bar (void)
{
__BB(2):
return;
}
```
So basically it is due to the function be declared as inline (or static and
unused with -O1).
Confirmed.
[Bug modula2/111956] Many powerpc platforms do _not_ have support for IEEE754 long double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111956 Gaius Mulley changed: What|Removed |Added CC||gaius at gcc dot gnu.org --- Comment #4 from Gaius Mulley --- Created attachment 56508 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56508=edit Proposed fix Here is a proposed patch which detects whether the target_cpu is power10 and target is ppc64le. I've seen it build successfully on gcc135 (without bootstrap) and bootstrap on gcc120 (I'm currently running a bootstrap on gcc135). I'm unsure whether these libgm2/configure.ac and gcc/m2/configure.ac tests are sufficient - and suspect more combinations should be checked (ie the shell case statements might need expanding).
[Bug c++/112269] [14 Regression] x86_64 GNU/Linux '-m32' multilib 'libstdc++-v3/include/complex:1493: internal compiler error: in tsubst_expr, at cp/pt.cc:21534' since r14-4796-g3e3d73ed5e85e7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112269
Andrew Pinski changed:
What|Removed |Added
Keywords|needs-reduction |
--- Comment #10 from Andrew Pinski ---
Reduced testcase (`-m32 -std=c++20` or `-m32 -fexcess-precision=standard`):
```
template
constexpr void fg(__complex__ float ) {
const __complex__ float __t;
n /= __t;
}
```
[Bug c++/112288] [11/12/13/14 Regression] ICE - internal compiler error: in instantiate_decl, at cp/pt.cc:26861 since r6-6830-g20a0c6f9bdbd78
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112288 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org --- Comment #10 from Patrick Palka --- (In reply to Fabio Alemagna from comment #9) > (In reply to Patrick Palka from comment #8) > > The issue was probably latent before r6-6830. The testcase is kind of > > strange, > > It's the "friend injection" technique. In this case, it's used to create a > compile-time counter. The specific test case uses templates in such a way as > to try and circumvent a diagnostic-related bug (bug #112267), which however > triggered this other bug. Ah thanks, I see. I have a fix for the failing assert.
[Bug bootstrap/112379] [14 Regression] bootstrap failure on --enable-checking=release: gcc/gcc-urlifier.cc:100:1: error: get_url_suffix_for_quoted_text() defined but not used [-Werror=unused-function]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112379 Sergei Trofimovich changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Sergei Trofimovich --- Should be fixed now.
[Bug bootstrap/112379] [14 Regression] bootstrap failure on --enable-checking=release: gcc/gcc-urlifier.cc:100:1: error: get_url_suffix_for_quoted_text() defined but not used [-Werror=unused-function]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112379 --- Comment #2 from CVS Commits --- The master branch has been updated by Sergei Trofimovich : https://gcc.gnu.org/g:9eef85a0276a0a118b76ce2da00861b75e9a3012 commit r14-5125-g9eef85a0276a0a118b76ce2da00861b75e9a3012 Author: Sergei Trofimovich Date: Sat Nov 4 16:18:02 2023 + diagnostics: fix gcc-urlifier.cc bootstrap failure [PR112379] Without the change `./configure --enable-checking=release` bootstrap fails as: gcc/gcc-urlifier.cc:100:1: error: 'get_url_suffix_for_quoted_text()' defined but not used [-Werror=unused-function] This happens because the helper is used only in `ASSERT` macros which don't always get expanded to executable code. The fix marks helper function with `ATTRIBUTE_UNUSED`. gcc/ PR bootstrap/112379 * gcc-urlifier.cc (get_url_suffix_for_quoted_text): Mark as ATTRIBUTE_UNUSED.
[Bug target/112381] [14 regression] ICE when building Mesa (in reload, internal compiler error: in lra_split_hard_reg_for)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112381 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0 Target|x86_64-linux-gnu|x86_64-linux-gnu ||i?86-linux-gnu
[Bug rtl-optimization/112380] [14 regression] ICE when building Mesa (in combine, internal compiler error: in simplify_subreg)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112380
--- Comment #5 from Andrew Pinski ---
```
Trying 25, 31, 32 -> 34:
25: strict_low_part(r114:TI#0)=r102:QI
REG_DEAD r102:QI
31: {r131:SI=r130:SI&0x1f800;clobber flags:CC;}
REG_DEAD r130:SI
REG_UNUSED flags:CC
32: {r132:SI=r114:TI#0&0xfffe07ff;clobber flags:CC;}
REG_UNUSED flags:CC
34: {r134:DI=zero_extend(r131:SI|r132:SI);clobber flags:CC;}
REG_UNUSED flags:CC
REG_DEAD r131:SI
REG_DEAD r132:SI
```
Then crash.
[Bug rtl-optimization/112380] [14 regression] ICE when building Mesa (in combine, internal compiler error: in simplify_subreg)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112380 --- Comment #4 from Sam James --- (In reply to Sam James from comment #3) > might not be a 14 regression, I need to build older gccs with more checking ok, it is a 14 regression
[Bug c++/112377] Implement -Walloc-size in c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112377 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #2 from Eric Gallager --- (In reply to David Binderman from comment #0) > Following on from discussion in bug report 112347, > in file gcc/c-family/c.opt, is the new text > > Walloc-size > C ObjC Var(warn_alloc_size) Warning LangEnabledBy(C ObjC, Wextra) > Warn when allocating insufficient storage for the target type of the > assigned pointer. > > IMHO, it should say: > > Walloc-size > C ObjC Var(warn_alloc_size) Warning LangEnabledBy(C ObjC C++, Wextra) > Warn when allocating insufficient storage for the target type of the > assigned pointer. > > I think that should be enough to implement the new warning for C++. If adding it to C++, then IMO it ought to be enabled for ObjC++, too, since the current implementation is for both C and ObjC.
[Bug rtl-optimization/112381] [14 regression] ICE when building Mesa (in reload, internal compiler error: in lra_split_hard_reg_for)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112381 --- Comment #3 from Sam James --- (In reply to Sam James from comment #0) > Interestingly, it is the same source file as > in PR112380 (which still occurs on trunk). sorry, I lied here, just similar names and I skimmed
[Bug rtl-optimization/112381] [14 regression] ICE when building Mesa (internal compiler error: in lra_split_hard_reg_for)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112381
--- Comment #2 from Sam James ---
```
[...]
In file included from ../mesa-23.2.1/src/util/u_debug.h:49,
from ../mesa-23.2.1/src/util/format/u_format.h:35,
from ../mesa-23.2.1/src/compiler/nir/nir.h:43,
from ../mesa-23.2.1/src/compiler/nir/nir_opt_idiv_const.c:24:
../mesa-23.2.1/src/util/u_atomic.h:348:1: note: the alignment of ‘_Atomic long
long int’ fields changed in GCC 11.1
348 | typedef int64_t __attribute__((aligned(_Alignof(_Atomic(int64_t)
p_atomic_int64_t;
| ^~~
../mesa-23.2.1/src/compiler/nir/nir_opt_idiv_const.c: In function
‘nir_opt_idiv_const_instr’:
../mesa-23.2.1/src/compiler/nir/nir_opt_idiv_const.c:223:1: error: unable to
find a register to spill
223 | }
| ^
../mesa-23.2.1/src/compiler/nir/nir_opt_idiv_const.c:223:1: error: this is the
insn:
(insn 1701 2092 2188 122 (parallel [
(set (reg:DI 911 [479])
(and:DI (not:DI (reg/v:DI 671 [orig:119 d ] [119]))
(reg:DI 821 [389])))
(clobber (reg:CC 17 flags))
]) "../mesa-23.2.1/src/compiler/nir/nir_opt_idiv_const.c":135:21
discrim 1 623 {*andndi3_doubleword_bmi}
(expr_list:REG_DEAD (reg:DI 821 [389])
(expr_list:REG_DEAD (reg/v:DI 671 [orig:119 d ] [119])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)
during RTL pass: reload
../mesa-23.2.1/src/compiler/nir/nir_opt_idiv_const.c:223:1: internal compiler
error: in lra_split_hard_reg_for, at lra-assigns.cc:1861
0x5638c60933fe internal_error(char const*, ...)
???:0
0x5638c60934ee fancy_abort(char const*, int, char const*)
???:0
0x5638c52ace1e _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
???:0
0x5638c51a48f1 lra_split_hard_reg_for()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug rtl-optimization/112381] [14 regression] ICE when building Mesa (internal compiler error: in lra_split_hard_reg_for)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112381 --- Comment #1 from Sam James --- Created attachment 56507 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56507=edit reduced.i Attached reduced version. Not bothered cleaning it up b/c of that issue with it working on trunk. Needs gcc -O2 -m32 -mstackrealign -march=raptorlake -c nir_opt_idiv_const.c.i to reproduce.
[Bug rtl-optimization/112381] New: [14 regression] ICE when building Mesa (internal compiler error: in lra_split_hard_reg_for)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112381 Bug ID: 112381 Summary: [14 regression] ICE when building Mesa (internal compiler error: in lra_split_hard_reg_for) Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: sjames at gcc dot gnu.org Target Milestone: --- Created attachment 56506 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56506=edit nir_opt_idiv_const.c.i.orig.xz This appears fixed on trunk but not in the last 14 snapshot (20231029). Not sure if it got really fixed or is now latent, so reporting just in case so can bisect for the fix later if it's not an obvious dupe. Originally reported downstream by Kostadin Shishmanov in https://bugs.gentoo.org/916860. Interestingly, it is the same source file as in PR112380 (which still occurs on trunk).
[Bug rtl-optimization/112380] [14 regression] ICE when building mesa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112380 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code Target Milestone|--- |14.0
[Bug tree-optimization/110903] [12/13 Regression] Dead Code Elimination Regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110903 Thomas Koenig changed: What|Removed |Added Summary|[12/13/14 Regression] Dead |[12/13 Regression] Dead |Code Elimination Regression |Code Elimination Regression --- Comment #5 from Thomas Koenig --- (In reply to Andrew Pinski from comment #4) > (In reply to Thomas Koenig from comment #3) > > The code from comment#2 and from comment#3 no longer calls foo > > with current trunk, r14-5108-g751fc7bcdcdf25 . > > > > Now, to see which commit fixed it... > > My bet is on r14-4089-gd45ddc2c04e471 . Weird thing is that I do see this on POWER (I often use gcc120 for compiling because it is the beefiest machine I can lay my hands on). However, this was actually fixed by r14-4141-gbf6b107e2a3423: bf6b107e2a342319b3787ec960fc8014ef3aff91 is the first new commit commit bf6b107e2a342319b3787ec960fc8014ef3aff91 Author: Andrew MacLeod Date: Wed Sep 13 11:52:15 2023 -0400 New early __builtin_unreachable processing. in VRP passes before __builtin_unreachable MUST be removed, only remove it if all exports affected by the unreachable can have global values updated, and do not involve loads from memory. PR tree-optimization/110080 PR tree-optimization/110249 gcc/ * tree-vrp.cc (remove_unreachable::final_p): New. (remove_unreachable::maybe_register): Rename from maybe_register_block and call early or final routine. (fully_replaceable): New. (remove_unreachable::handle_early): New. (remove_unreachable::remove_and_update_globals): Remove non-final processing. (rvrp_folder::rvrp_folder): Add final flag to constructor. (rvrp_folder::post_fold_bb): Remove unreachable registration. (rvrp_folder::pre_fold_stmt): Move unreachable processing to here. (execute_ranger_vrp): Adjust some call parameters. gcc/testsuite/ * g++.dg/pr110249.C: New. * gcc.dg/pr110080.c: New. * gcc.dg/pr93917.c: Adjust.
[Bug bootstrap/112379] [14 Regression] bootstrap failure on --enable-checking=release: gcc/gcc-urlifier.cc:100:1: error: get_url_suffix_for_quoted_text() defined but not used [-Werror=unused-function]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112379 --- Comment #1 from Sergei Trofimovich --- Proposed trivial fix by marking helper as `ATTRIBUTE_UNUSED`: https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635194.html
[Bug rtl-optimization/112380] [14 regression] ICE when building mesa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112380 --- Comment #3 from Sam James --- might not be a 14 regression, I need to build older gccs with more checking
[Bug rtl-optimization/112380] [14 regression] ICE when building mesa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112380
--- Comment #2 from Sam James ---
reduced:
```
enum { TGSI_FILE_NULL };
struct ureg_src {
unsigned File : 4;
unsigned : 2;
unsigned : 2;
unsigned : 2;
unsigned : 1;
unsigned IndirectFile : 4;
unsigned IndirectSwizzle : 2;
int : 16;
int : 6;
int : 16;
int : 16;
unsigned : 10;
} __trans_tmp_1;
int ureg_src_indirect_addr_1, ntt_emit_texture_instr_sampler_handle_src;
void ureg_scalar(struct ureg_src);
void ntt_emit_texture_instr() {
struct ureg_src sampler;
if (ntt_emit_texture_instr_sampler_handle_src)
sampler = __trans_tmp_1;
struct ureg_src reg = sampler;
reg.File != TGSI_FILE_NULL;
reg.IndirectFile = reg.IndirectSwizzle = ureg_src_indirect_addr_1;
sampler = reg;
ureg_scalar(reg);
}
```
[Bug c/60846] Add 128-bit integer types for general use on 32-bit/64-bit CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60846 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #10 from Jakub Jelinek --- If a particular 32-bit arch agrees on ABI issues, one could use _BitInt(128) or unsigned _BitInt(128) for it in GCC 14+, though currently only x86-64 64-bit enables it.
[Bug fortran/97245] ASSOCIATED intrinsic does not recognize a pointer variable the second time it is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97245 anlauf at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |13.3 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-14, and backported to 13-branch. Closing. Thanks for the report!
[Bug fortran/97245] ASSOCIATED intrinsic does not recognize a pointer variable the second time it is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97245 --- Comment #6 from CVS Commits --- The releases/gcc-13 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:e6ea74b68c5904446da6050751fde97d02549d1f commit r13-8002-ge6ea74b68c5904446da6050751fde97d02549d1f Author: Harald Anlauf Date: Fri Nov 3 19:41:54 2023 +0100 Fortran: fix issue with multiple references of a procedure pointer [PR97245] gcc/fortran/ChangeLog: PR fortran/97245 * match.cc (gfc_match_call): If a procedure pointer has already been resolved, do not create a new symbol in a procedure reference of the same name shadowing the first one if it is host-associated. gcc/testsuite/ChangeLog: PR fortran/97245 * gfortran.dg/proc_ptr_53.f90: New test. (cherry picked from commit 5340f48b7639fcc874f64aac214f9ef9ae43d43e)
[Bug rtl-optimization/112380] [14 regression] ICE when building mesa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112380 --- Comment #1 from Sam James --- I'll try reduce it now.
[Bug rtl-optimization/112380] New: [14 regression] ICE when building mesa
cc-14.0.0./gcc-14.0.0./gcc/simplify-rtx.cc:7554 0x563ef8ef091d simplify_context::simplify_subreg(machine_mode, rtx_def*, machine_mode, poly_int<1u, unsigned long>) /usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/simplify-rtx.cc:7804 0x563ef8ef097d simplify_context::simplify_subreg(machine_mode, rtx_def*, machine_mode, poly_int<1u, unsigned long>) /usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/simplify-rtx.cc:7805 0x563ef8ef091d simplify_context::simplify_subreg(machine_mode, rtx_def*, machine_mode, poly_int<1u, unsigned long>) /usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/simplify-rtx.cc:7804 0x563ef9091703 make_compound_operation_int /usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/rtl.h:3516 0x563ef9091703 make_compound_operation(rtx_def*, rtx_code) /usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/combine.cc:8439 0x563ef9091f14 make_compound_operation_int /usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/combine.cc:8198 0x563ef9091f14 make_compound_operation(rtx_def*, rtx_code) /usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/combine.cc:8439 0x563ef908e22c simplify_set /usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/combine.cc:6954 0x563ef8fb86d7 subst /usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/combine.cc:5609 0x563ef8fb8bb9 subst /usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/combine.cc:5470 0x563ef8faedc3 try_combine /usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/combine.cc:3369 0x563ef8f3494c combine_instructions /usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/combine.cc:1357 0x563ef8f318d9 rest_of_handle_combine /usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/combine.cc:15080 0x563ef8f318d9 execute /usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/combine.cc:15124 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://bugs.gentoo.org/> for instructions. ``` ``` Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/14/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-14.0.0./work/gcc-14.0.0./configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/14 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/14/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/14 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/14/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/14/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14 --disable-silent-rules --disable-dependency-tracking --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/14/python --enable-languages=c,c++,fortran,rust --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --disable-libunwind-exceptions --enable-checking=yes,extra,rtl --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo Hardened 14.0.0 p, commit 2b02f083e67e97f8187d3ec023c3d281f49232c0' --with-gcc-major-version-only --enable-libstdcxx-time --enable-lto --disable-libstdcxx-pch --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-fixed-point --enable-targets=all --enable-libgomp --disable-libssp --disable-libada --enable-cet --disable-systemtap --enable-valgrind-annotations --disable-vtable-verify --disable-libvtv --with-zstd --with-isl --disable-isl-version-check --enable-default-pie --enable-host-pie --enable-host-bind-now --enable-default-ssp --with-build-config='bootstrap-O3 bootstrap-lto bootstrap-cet' Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.0 20231104 (experimental) 8d22ac6a18cf542cd541c06b2a7df8fdd293946d (Gentoo Hardened 14.0.0 p, commit 2b02f083e67e97f8187d3ec023c3d281f49232c0) ```
[Bug target/112368] Darwin failures for avx256_move_by_pieces and avx256_store_by_pieces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112368 Francois-Xavier Coudert changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Francois-Xavier Coudert --- OK, it's gone.
[Bug bootstrap/112379] New: [14 Regression] bootstrap failure on --enable-checking=release: gcc/gcc-urlifier.cc:100:1: error: get_url_suffix_for_quoted_text() defined but not used [-Werror=unused-func
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112379
Bug ID: 112379
Summary: [14 Regression] bootstrap failure on
--enable-checking=release: gcc/gcc-urlifier.cc:100:1:
error: get_url_suffix_for_quoted_text() defined but
not used [-Werror=unused-function]
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
Noticed build failure on today's `gcc-master` checkout at
r14-5124-gada871cfadd3f4.
Reproducer:
$ ../gcc/configure --disable-multilib --enable-languages=c,c++
--enable-checking=release
$ make STAGE1_CFLAGS='-O1 -g0'
/tmp/gb/./prev-gcc/xg++ -B/tmp/gb/./prev-gcc/
-B/usr/local/x86_64-pc-linux-gnu/bin/ -nostdinc++
-B/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-B/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-I/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
-I/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/include
-I/home/slyfox/dev/git/gcc/libstdc++-v3/libsupc++
-L/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -fno-PIE -c
-g -O2 -fno-checking -gtoggle -DIN_GCC-fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Wconditionally-supported
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Werror -DHAVE_CONFIG_H -fno-PIE -I. -I.
-I/home/slyfox/dev/git/gcc/gcc -I/home/slyfox/dev/git/gcc/gcc/.
-I/home/slyfox/dev/git/gcc/gcc/../include
-I/home/slyfox/dev/git/gcc/gcc/../libcpp/include
-I/home/slyfox/dev/git/gcc/gcc/../libcody
-I/home/slyfox/dev/git/gcc/gcc/../libdecnumber
-I/home/slyfox/dev/git/gcc/gcc/../libdecnumber/bid -I../libdecnumber
-I/home/slyfox/dev/git/gcc/gcc/../libbacktrace -o gcc-urlifier.o -MT
gcc-urlifier.o -MMD -MP -MF ./.deps/gcc-urlifier.TPo
/home/slyfox/dev/git/gcc/gcc/gcc-urlifier.cc
/home/slyfox/dev/git/gcc/gcc/gcc-urlifier.cc:100:1: error: 'const char*
{anonymous}::gcc_urlifier::get_url_suffix_for_quoted_text(const char*) const'
defined but not used [-Werror=unused-function]
100 | gcc_urlifier::get_url_suffix_for_quoted_text (const char *p) const
| ^~~~
cc1plus: all warnings being treated as errors
make[3]: *** [Makefile:1195: gcc-urlifier.o] Error 1
make[3]: Leaving directory '/tmp/gb/gcc'
make[2]: *** [Makefile:5054: all-stage2-gcc] Error 2
make[2]: Leaving directory '/tmp/gb'
make[1]: *** [Makefile:26048: stage2-bubble] Error 2
make[1]: Leaving directory '/tmp/gb'
make: *** [Makefile:1094: all] Error 2
I suspect it's the effect of r14-5118-gc5db4d8ba5f3de "diagnostics: add
automatic URL-ification within messages".
$ prev-gcc/xg++ -Bprev-gcc -v
Reading specs from prev-gcc/specs
COLLECT_GCC=prev-gcc/xg++
COLLECT_LTO_WRAPPER=prev-gcc/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/slyfox/dev/git/gcc/configure --disable-multilib
--enable-languages=c,c++ --enable-checking=release
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20231104 (experimental) (GCC)
[Bug analyzer/112378] Missing -fanalizer diagnostics with glibc under _GNU_SOURCE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112378
--- Comment #1 from Rimvydas (RJ) ---
The -fanalyzer does not seem to handle glibc __CONST_SOCKADDR_ARG definitions
with transparent_unions that are used under -D_GNU_SOURCE (__USE_GNU).
Minimal reduced testcase:
$ cat test_sockaddr.c
struct sockaddr; struct sockaddr_x25;
#if defined __cplusplus || !defined _GNU_SOURCE
# define __CONST_SOCKADDR_ARG const struct sockaddr *
#else
typedef union {
const struct sockaddr * __sockaddr__; /* ... */
const struct sockaddr_x25 * __sockaddr_x25__;
} __CONST_SOCKADDR_ARG __attribute__ ((__transparent_union__));
#endif
extern int connect (int __fd, __CONST_SOCKADDR_ARG __addr, unsigned int __len);
extern void __analyzer_eval (int);
void test_null_connect (int fd)
{ __analyzer_eval (connect (fd, 0, 0) == -1); } /* { dg-warning "TRUE" } */
$ ./gcc/xgcc -Bgcc/ -fdiagnostics-plain-output -fanalyzer -c test_sockaddr.c
test_sockaddr.c: In function 'test_null_connect':
test_sockaddr.c:16:3: warning: TRUE
$ ./gcc/xgcc -Bgcc/ -fdiagnostics-plain-output -fanalyzer -c test_sockaddr.c
-D_GNU_SOURCE
test_sockaddr.c: In function 'test_null_connect':
test_sockaddr.c:16:3: warning: UNKNOWN
[Bug analyzer/112378] New: Missing -fanalizer diagnostics with glibc under _GNU_SOURCE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112378 Bug ID: 112378 Summary: Missing -fanalizer diagnostics with glibc under _GNU_SOURCE Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: rimvydas.jas at gmail dot com Target Milestone: --- Same vanishing diagnostics can be reproduced by running testsuite with: $ make check-gcc-c -k RUNTESTFLAGS="--target_board=unix/-D_GNU_SOURCE analyzer.exp" Running target unix/-D_GNU_SOURCE FAIL: gcc.dg/analyzer/fd-accept.c (test for warnings, line 17) FAIL: gcc.dg/analyzer/fd-accept.c (test for warnings, line 22) FAIL: gcc.dg/analyzer/fd-accept.c (test for warnings, line 23) FAIL: gcc.dg/analyzer/fd-accept.c (test for warnings, line 34) FAIL: gcc.dg/analyzer/fd-accept.c warning (test for warnings, line 57) FAIL: gcc.dg/analyzer/fd-accept.c final event at line 58 (test for warnings, line 57) FAIL: gcc.dg/analyzer/fd-accept.c warning (test for warnings, line 68) FAIL: gcc.dg/analyzer/fd-accept.c final event at line 69 (test for warnings, line 68) FAIL: gcc.dg/analyzer/fd-bind.c (test for warnings, line 27) FAIL: gcc.dg/analyzer/fd-bind.c (test for warnings, line 28) FAIL: gcc.dg/analyzer/fd-bind.c warning (test for warnings, line 38) FAIL: gcc.dg/analyzer/fd-bind.c final event at line 39 (test for warnings, line 38) FAIL: gcc.dg/analyzer/fd-bind.c warning (test for warnings, line 74) FAIL: gcc.dg/analyzer/fd-bind.c final event at line 75 (test for warnings, line 74) FAIL: gcc.dg/analyzer/fd-bind.c (test for excess errors) FAIL: gcc.dg/analyzer/fd-connect.c (test for warnings, line 20) FAIL: gcc.dg/analyzer/fd-connect.c (test for warnings, line 21) FAIL: gcc.dg/analyzer/fd-connect.c (test for warnings, line 35) FAIL: gcc.dg/analyzer/fd-connect.c warning (test for warnings, line 45) FAIL: gcc.dg/analyzer/fd-connect.c final event at line 46 (test for warnings, line 45) FAIL: gcc.dg/analyzer/fd-connect.c (test for excess errors) FAIL: gcc.dg/analyzer/fd-datagram-socket.c (test for warnings, line 61) FAIL: gcc.dg/analyzer/fd-datagram-socket.c (test for warnings, line 65) FAIL: gcc.dg/analyzer/fd-datagram-socket.c (test for warnings, line 72) FAIL: gcc.dg/analyzer/fd-datagram-socket.c (test for warnings, line 78) FAIL: gcc.dg/analyzer/fd-datagram-socket.c (test for warnings, line 94) FAIL: gcc.dg/analyzer/fd-datagram-socket.c warning (test for warnings, line 109) FAIL: gcc.dg/analyzer/fd-datagram-socket.c final event at line 110 (test for warnings, line 109) FAIL: gcc.dg/analyzer/fd-listen.c (test for warnings, line 26) FAIL: gcc.dg/analyzer/fd-listen.c warning (test for warnings, line 33) FAIL: gcc.dg/analyzer/fd-listen.c final event at line 34 (test for warnings, line 33) FAIL: gcc.dg/analyzer/fd-listen.c (test for warnings, line 43) FAIL: gcc.dg/analyzer/fd-listen.c warning (test for warnings, line 44) FAIL: gcc.dg/analyzer/fd-listen.c final event at line 45 (test for warnings, line 44) FAIL: gcc.dg/analyzer/fd-listen.c warning (test for warnings, line 64) FAIL: gcc.dg/analyzer/fd-listen.c final event at line 65 (test for warnings, line 64) FAIL: gcc.dg/analyzer/fd-socket-misuse.c warning (test for warnings, line 56) FAIL: gcc.dg/analyzer/fd-socket-misuse.c final event at line 57 (test for warnings, line 56) FAIL: gcc.dg/analyzer/fd-socket-misuse.c (test for warnings, line 58) FAIL: gcc.dg/analyzer/fd-socket-misuse.c warning (test for warnings, line 66) FAIL: gcc.dg/analyzer/fd-socket-misuse.c final event at line 67 (test for warnings, line 66) FAIL: gcc.dg/analyzer/fd-socket-misuse.c warning (test for warnings, line 86) FAIL: gcc.dg/analyzer/fd-socket-misuse.c final event at line 87 (test for warnings, line 86) FAIL: gcc.dg/analyzer/fd-socket-misuse.c (test for warnings, line 93) FAIL: gcc.dg/analyzer/fd-socket-misuse.c warning (test for warnings, line 100) FAIL: gcc.dg/analyzer/fd-socket-misuse.c final event at line 101 (test for warnings, line 100) FAIL: gcc.dg/analyzer/fd-socket-misuse.c (test for excess errors) FAIL: gcc.dg/analyzer/fd-stream-socket-active-open.c (test for warnings, line 32) FAIL: gcc.dg/analyzer/fd-stream-socket-active-open.c (test for warnings, line 33) FAIL: gcc.dg/analyzer/fd-stream-socket-active-open.c (test for warnings, line 39) FAIL: gcc.dg/analyzer/fd-stream-socket-active-open.c (test for warnings, line 40) FAIL: gcc.dg/analyzer/fd-stream-socket-active-open.c (test for warnings, line 62) FAIL: gcc.dg/analyzer/fd-stream-socket-active-open.c (test for warnings, line 63) FAIL: gcc.dg/analyzer/fd-stream-socket-active-open.c (test for warnings, line 69) FAIL: gcc.dg/analyzer/fd-stream-socket-active-open.c (test for warnings, line 70) FAIL: gcc.dg/analyzer/fd-stream-socket-active-open.c (test for warnings, line 71) FAIL: gcc.dg/analyzer/fd-stream-socket-active-open.c (test for warnings, line 77)
[Bug libstdc++/112349] ranges::max makes unnecessary copies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112349
康桓瑋 changed:
What|Removed |Added
CC||hewillk at gmail dot com
--- Comment #2 from 康桓瑋 ---
(In reply to Jonathan Wakely from comment #1)
>
> I think that would be OK too.
>
> auto __result = *__first;
> while (++__first != __last)
> {
> if (std::__invoke(__comp,
> std::__invoke(__proj, __result),
> std::__invoke(__proj, *__first)))
> __result = *__first;
> }
> return __result;
`auto __result = *__first;` may not be OK, `range_value_t<_Range>
__result(*__first);` is OK.
[Bug target/111930] aarch64: SME should be supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111930 --- Comment #4 from Richard Sandiford --- (In reply to Xi Ruoyao from comment #3) > Note that now we have only 2 weeks before GCC 14 stage 1 ends. Yeah, I'm aware. :)
[Bug target/111930] aarch64: SME should be supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111930 --- Comment #3 from Xi Ruoyao --- (In reply to Richard Sandiford from comment #1) > We're aiming to add SME and SME2 support in GCC 14, hopefully by the end of > the year. Note that now we have only 2 weeks before GCC 14 stage 1 ends.
[Bug c/98541] warning with -Wnonnull for array parameter with bound > 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98541 uecker at gcc dot gnu.org changed: What|Removed |Added Known to fail||11.0 Resolution|--- |FIXED Status|NEW |RESOLVED Target Milestone|--- |14.0 CC||uecker at gcc dot gnu.org --- Comment #5 from uecker at gcc dot gnu.org --- Fixed on trunk.
[Bug c++/112377] Implement -Walloc-size in c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112377 uecker at gcc dot gnu.org changed: What|Removed |Added Severity|normal |enhancement
[Bug c++/112377] Implement -Walloc-size in c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112377 uecker at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2023-11-04 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from uecker at gcc dot gnu.org --- Confirmed. But this change would not be enough. The warning is implemented in the C front-end which which is separate from the C++ FE. Possibly, the code for the warning could be shared, but I do not know.
[Bug libstdc++/110133] System error message should ideally use strerror_r over strerror
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110133 --- Comment #3 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:51f94778b45514992a716b0b2d7a87244e6f0018 commit r14-5123-g51f94778b45514992a716b0b2d7a87244e6f0018 Author: Jonathan Wakely Date: Fri Nov 3 13:59:48 2023 + libstdc++: Use strerror_r in std::generic_category()::message(int) [PR110133] Use strerror_r instead of strerror when available, due to the latter not being thread-safe. This is complicated by Glibc providing a GNU-specific strerror_r which is not compatible with POSIX strerror_r, so we need to dispatch on the return type. We can use the recently-added std::string::__resize_and_overwrite to write directly into the string buffer when possible. Because we estimate the initial buffer size we might end up with excess capacity in the returned std::string. We can slightly tweak the std::system_error constructors to make use of that excess capacity, so that in some cases we require fewer allocations to construct the std::system_error::what() string. libstdc++-v3/ChangeLog: PR libstdc++/110133 * include/std/system_error (system_error::system_error): Group arguments so that concatenation can reuse rvalue's capacity. * src/c++11/system_error.cc (strerror_string): New function. [_GLIBCXX_HAVE_STRERROR_R] (use_strerror_result): New functions. (generic_error_category::message): Use strerror_string. (system_error_category::message): Likewise.
[Bug c++/112269] [14 Regression] x86_64 GNU/Linux '-m32' multilib 'libstdc++-v3/include/complex:1493: internal compiler error: in tsubst_expr, at cp/pt.cc:21534' since r14-4796-g3e3d73ed5e85e7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112269 --- Comment #9 from Jonathan Wakely --- (In reply to Patrick Palka from comment #5) > I can't reproduce any of these testsuite failures on trunk with x86_64 > -m32... could you provide a preprocessed source file perhaps? The libstdc++ testsuite shows lots of failures with -m32 -std=c++20 e.g. FAIL: 23_containers/vector/48101-2_neg.cc -std=c++20 (test for errors, line ) FAIL: 23_containers/vector/48101-2_neg.cc -std=c++20 (test for excess errors) Excess errors: /tmp/build/x86_64-pc-linux-gnu/32/libstdc++-v3/include/complex:1493: internal compiler error: in tsubst_expr, at cp/pt.cc:21534 0x78b9fb tsubst_expr(tree_node*, tree_node*, int, tree_node*) /home/test/src/gcc/gcc/cp/pt.cc:21534
[Bug c/112347] [14 regression] ICE on jemalloc-5.3.0: Segmentation fault around convert_for_assignment()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112347 --- Comment #21 from David Binderman --- (In reply to Martin Uecker from comment #16) > I agree that the C++ should have this warning as well, although it seems > less important there. This would be an enhancement request for the C++ FE. See 112377.
[Bug c++/112377] New: Implement -Walloc-size in c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112377 Bug ID: 112377 Summary: Implement -Walloc-size in c++ Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Following on from discussion in bug report 112347, in file gcc/c-family/c.opt, is the new text Walloc-size C ObjC Var(warn_alloc_size) Warning LangEnabledBy(C ObjC, Wextra) Warn when allocating insufficient storage for the target type of the assigned pointer. IMHO, it should say: Walloc-size C ObjC Var(warn_alloc_size) Warning LangEnabledBy(C ObjC C++, Wextra) Warn when allocating insufficient storage for the target type of the assigned pointer. I think that should be enough to implement the new warning for C++.
[Bug testsuite/112376] [14 Regression] gcc.dg/tree-ssa/ssa-dom-thread-7.c was not adjusted for aarch64 case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112376 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0
[Bug testsuite/112376] New: [14 Regression] gcc.dg/tree-ssa/ssa-dom-thread-7.c was not adjusted for aarch64 case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112376
Bug ID: 112376
Summary: [14 Regression] gcc.dg/tree-ssa/ssa-dom-thread-7.c was
not adjusted for aarch64 case
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: testsuite-fail
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Target: aarch64
So after r13-1998-g409978d58dafa689c5b3f85013, the !aarch64 case was updated
but the aarch64 was not. I suspect the testcase just needs to be updated.
The testcase has:
```
/* aarch64 has the highest CASE_VALUES_THRESHOLD in GCC. It's high enough
to change decisions in switch expansion which in turn can expose new
jump threading opportunities. Skip the later tests on aarch64. */
/* { dg-final { scan-tree-dump-not "Jumps threaded" "dom3" { target { !
aarch64*-*-* } } } } */
/* { dg-final { scan-tree-dump "Jumps threaded: 9" "thread2" { target { !
aarch64*-*-* } } } } */
/* { dg-final { scan-tree-dump "Jumps threaded: 18" "thread2" { target {
aarch64*-*-* } } } } */
```
[Bug target/112375] [14 Regression] vget_set_lane_1.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112375 --- Comment #2 from Andrew Pinski --- This simple patch fixes the issue but I have not tested it yet, basically it moves the ins case before the zip: ``` diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc index 5fd7063663c..8a9b89807e3 100644 --- a/gcc/config/aarch64/aarch64.cc +++ b/gcc/config/aarch64/aarch64.cc @@ -24890,6 +24890,8 @@ aarch64_expand_vec_perm_const_1 (struct expand_vec_perm_d *d) return true; else if (aarch64_evpc_dup (d)) return true; + else if (aarch64_evpc_ins (d)) + return true; else if (aarch64_evpc_zip (d)) return true; else if (aarch64_evpc_uzp (d)) @@ -24898,8 +24900,6 @@ aarch64_expand_vec_perm_const_1 (struct expand_vec_perm_d *d) return true; else if (aarch64_evpc_sel (d)) return true; - else if (aarch64_evpc_ins (d)) - return true; else if (aarch64_evpc_reencode (d)) return true; ``` But maybe this needs some better cost mechanism because right now even though we might be able to do ins because of reencoding zip might be detected first.
[Bug target/112375] [14 Regression] vget_set_lane_1.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112375 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0 Summary|vget_set_lane_1.c fails |[14 Regression] ||vget_set_lane_1.c fails Keywords||missed-optimization --- Comment #1 from Andrew Pinski --- I almost positive it was caused by r14-3381-g27de9aa15214 Where the the back-end decides to use zip1 instead of ins here for the vec_perm.
[Bug target/112375] New: vget_set_lane_1.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112375 Bug ID: 112375 Summary: vget_set_lane_1.c fails Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: testsuite-fail Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- Target: aarch64-linux-gnu FAIL: gcc.target/aarch64/vget_set_lane_1.c scan-assembler-times instv0.s[1], v1.s[0] 3 We expected ins here but currently get: zip1v0.2s, v0.2s, v1.2s 3 times.
[Bug tree-optimization/112272] suboptimal zero-initialization of struct of mixed pointer and integer types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112272 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-11-04 Blocks||53947 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed. I don't know why the SLP vectorizer rejects it. Though I wonder why store merging also rejects it for a cost reason ... Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
