[Bug rtl-optimization/101169] [10 regression] test case gcc.target/powerpc/fold-vec-extract-char.p7.c fails after r10-9880
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101169 --- Comment #6 from Kewen Lin --- PR111850 reminded me this bug, the sub-optimal issue described in #comment 4 has been fixed on latest trunk, I think it's r14-4664-g04c9cf5c786b94.
[Bug target/111753] [14 Regression] ICE: in extract_constrain_insn, at recog.cc:2692 insn does not satisfy its constraints: {*movsf_internal} with -O2 -mavx512bw -fno-tree-ter starting with r14-4499
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111753 --- Comment #3 from Haochen Jiang --- It seems like caused by I changed the behavior when trying to use x/ymm16+ w/o avx512vl specified. Working on a solution for that.
[Bug c++/111872] New: GCC rejects out of class definition of inner private class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111872
Bug ID: 111872
Summary: GCC rejects out of class definition of inner private
class template
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jlame646 at gmail dot com
Target Milestone: ---
The following valid(afaik) code is rejected by gcc but accepted by clang and
msvc.
https://godbolt.org/z/x5xMvETPh
```
class A {
struct N;
template struct S;
};
// works now
class A::N{};
template class A::S{};//gcc rejects this but clang and msbc
accepts this
```
GCC says:
:10:19: error: 'class A::N' is private within this context
10 | template class A::S{};//gcc rejects this but clang and
msbc accepts this
| ^
:9:10: note: declared private here
9 | class A::N{};
| ^
[Bug c/100532] ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in useless_type_conversion_p, at gimple-expr.c:259
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100532
--- Comment #8 from Andrew Pinski ---
Maybe the simple fix:
diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc
index 6e044b4afbc..8f8562936dc 100644
--- a/gcc/c/c-typeck.cc
+++ b/gcc/c/c-typeck.cc
@@ -3367,7 +3367,7 @@ convert_argument (location_t ploc, tree function, tree
fundecl,
{
error_at (ploc, "type of formal parameter %d is incomplete",
parmnum + 1);
- return val;
+ return error_mark_node;
}
/* Optionally warn about conversions that differ from the default
[Bug middle-end/110986] [14 Regression] aarch64 has support for conditional not (and vectorized conditional not ) after r14-3110-g7fb65f10285
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110986 --- Comment #23 from Andrew Pinski --- Final patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2023-October/633517.html The Canonicalization between the 2 forms or doing it in isel will wait until next I think.
[Bug tree-optimization/111860] [14 Regression] incorrect vUSE after guard block loop skip block during vectorization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111860 --- Comment #10 from Andrew Pinski --- Just an FYI, I do get a similar ICE on: libgomp/testsuite/libgomp.fortran/simd3.f90 Testcase on aarch64-linux-gnu now too. Maybe since it was in the libgomp testsuite you missed it when you tested your patch. /home/ubuntu/src/upstream-gcc-aarch64/gcc/libgomp/testsuite/libgomp.fortran/simd3.f90:56:18: Error: stmt with wrong VUSE^M # VUSE <.MEM_68>^M _21 = D.3326[_50];^M expected .MEM_95^M /home/ubuntu/src/upstream-gcc-aarch64/gcc/libgomp/testsuite/libgomp.fortran/simd3.f90:56:18: Error: PHI node with wrong VUSE on edge from BB 32^M .MEM_131 = PHI <.MEM_68(32), .MEM_68(29)>^M expected .MEM_95^M /home/ubuntu/src/upstream-gcc-aarch64/gcc/libgomp/testsuite/libgomp.fortran/simd3.f90:56:18: Error: PHI node with wrong VUSE on edge from BB 29^M .MEM_131 = PHI <.MEM_68(32), .MEM_68(29)>^M expected .MEM_95^M during GIMPLE pass: vect^M /home/ubuntu/src/upstream-gcc-aarch64/gcc/libgomp/testsuite/libgomp.fortran/simd3.f90:56:18: internal compiler error: verify_ssa failed^M 0x12312eb verify_ssa(bool, bool)^M
[Bug c/104822] -Wscalar-storage-order warning for initialization from NULL seems useless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104822 --- Comment #4 from Andrew Pinski --- Created attachment 56147 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56147=edit Patch which I am testing
[Bug tree-optimization/111791] RISC-V: Strange loop vectorizaion on popcount function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111791 --- Comment #7 from JuzheZhong --- I don't think this is popcount vectorization issue. This code should not be vectorized. It's true this code won' be vectorized if we use default COST model. So this is not an issue.
[Bug modula2/111871] New: invoking gm2 with -pipe and -v does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111871
Bug ID: 111871
Summary: invoking gm2 with -pipe and -v does not work
Product: gcc
Version: 14.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: ---
Forwarding from the gm2 mailing list.
$ gm2 -v -O2 -pipe -o hello hello.mod -Wl,-rpath=/usr/local/gnu/lib`
$ cat hello.mod
MODULE hello;
FROM StrIO IMPORT WriteString, WriteLn;
BEGIN
WriteString('Hello world from M2!');
WriteLn
END hello.
Compiling yields this error:
--8<--
Driving: gm2 -v -O2 -pipe -o hello hello.mod -Wl,-rpath=/usr/local/gnu/lib
-fm2-pathname=- -fm2-pathnameI. -fgen-module-list=- -fscaffold-dynamic -fscaff
old-main -flibs=m2cor,m2log,m2pim,m2iso -fplugin=m2rte -l m2cor -l m2log -l
m2pim -l m2iso -l stdc++ -l m -l pthread
new argc = 21, added_libraries = 7
Using built-in specs.
COLLECT_GCC=gm2
COLLECT_LTO_WRAPPER=/usr/local/gnu/libexec/gcc/x86_64-unknown-openbsd7.3/14.0.0/lto-wrapper
Target: x86_64-unknown-openbsd7.3
Configured with: ../gcc/configure --verbose
--enable-languages=c,c++,d,fortran,lto,m2,objc,obj-c++,rust --enable-libssp
--enable-threads=posix --enable-wchar_t --disable-libstdcxx-pch
--enable-default-ssp --enable-default-pie --enable-cpp
--with-as=/usr/local/gnu/bin/as --with-ld=/usr/bin/ld --enable-link
er-build-id --prefix=/usr/local/gnu --with-local-prefix=/usr/local/gnu
--disable-tls --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230604 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-O2' '-pipe' '-o' 'hello' '-fm2-pathname=-'
'-fm2-pathnameI.' '-fgen-module-list=-' '-fscaffold-dynamic' '-fscaffold-main'
'-flibs=m2cor,m2log,m2pim,m2iso' '-fplugin=m2rte' '-mtune=generic'
'-march=x86-64'
/usr/local/gnu/libexec/gcc/x86_64-unknown-openbsd7.3/14.0.0/cc1gm2 -v
-iplugindir=/usr/local/gnu/lib/gcc/x86_64-unknown-openbsd7.3/14.0.0/plugin
-quiet -dumpbase hello.mod -dumpbase-ext .mod -mtune=generic -march=x86-64
-O2 -version -fm2-pathname=- -fm2-pathnameI. -fgen-module-list=-
-fscaffold-dynamic -fscaffold-main -flibs=m2cor,m2log,m2pim,m2iso
-fplugin=m2rte -fm2-pathname=- -fm2-pathnameI. hello.mod -o - |
/usr/local/gnu/bin/as -v -o /tmp//cceXRr5c.o -
GNU Modula-2 (GCC) version 14.0.0 20230604 (experimental)
(x86_64-unknown-openbsd7.3)
compiled by GNU C version 14.0.0 20230604 (experimental), GMP version
6.2.1, MPFR version 4.2.0, MPC version 1.3.1, isl version isl-0.25-GMP
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Versions of loaded plugins:
m2rte: Unknown version.
GNU assembler version 2.40.50 (x86_64-unknown-openbsd7.3) using BFD version
(GNU Binutils) 2.40.50.20230604
{standard input}: Assembler messages:
{standard input}:1: Error: no such instruction: `hello.mod'
-->8--
[Bug target/111720] RISC-V: Ugly codegen in RVV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
--- Comment #15 from JuzheZhong ---
After investigation:
I found it seems to be an issue to variable-length vector:
https://godbolt.org/z/6Wrjz9ofE
void fn (char * restrict out, int x)
{
[local count: 1073741824]:
MEM[(int8x16_t *)out_2(D)] = { 1, 2, 7, 1, 3, 4, 5, 3, 1, 0, 1, 2, 4, 4, 9, 9
};
return;
}
void fn2 (char * restrict out, int x)
{
svint8_t varr;
char arr[32];
[local count: 1073741824]:
arr =
"\x01\x02\x07\x01\x03\x04\x05\x03\x01\x00\x01\x02\x04\x04\t\t\x01\x02\x07\x01\x03\x04\x05\x03\x01\x00\x01\x02\x04\x04\t\t";
varr_3 = MEM[(svint8_t *)];
MEM[(svint8_t *)out_4(D)] = varr_3;
arr ={v} {CLOBBER(eol)};
return;
}
If we use ARM NEON type, the gimple IR won't have CLOBBER. Then no stack
transferring.
fn:
adrpx1, .LC0
ldr q31, [x1, #:lo12:.LC0]
str q31, [x0]
ret
fn2:
adrpx1, .LANCHOR0
add x1, x1, :lo12:.LANCHOR0
sub sp, sp, #32
ptrue p7.b, all
ldp q31, q30, [x1]
stp q31, q30, [sp]
ld1bz31.b, p7/z, [sp]
st1bz31.b, p7, [x0]
add sp, sp, 32
ret
ARM SVE type will have CLOBBER in gimple IR then cause redundant stack
transferring in ASM.
[Bug tree-optimization/111739] incorrect code with PGO enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111739
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |INVALID
--- Comment #3 from Andrew Pinski ---
The code is undefined for alias reasons:
union {
int f;
short g
} h;
*j =
...
a = n(h.f++);
*j = 0;
...
for (; i < 2; i++)
d = k(h.g || 0, 59376);
short *b =
*b ^= e;
printf("%d\n", h);
```
In the case of profiling, we are able to optimize away the short load from h
in:
*b ^= e;
and point it back to the store from `h.f++` and miss the store via *j.
Once you add -fno-strict-aliasing the testcase starts to work.
[Bug tree-optimization/111738] incorrect code when PGO is enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111738 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #4 from Andrew Pinski --- = ==1==ERROR: AddressSanitizer: global-buffer-overflow on address 0x004043e0 at pc 0x004012a3 bp 0x7ffd3315e4b0 sp 0x7ffd3315e4a8 WRITE of size 8 at 0x004043e0 thread T0 #0 0x4012a2 in i (/app/output.s+0x4012a2) (BuildId: 4eb338bebafc71b3519003fd1b76487cfb8fb27b) #1 0x4011c3 in h (/app/output.s+0x4011c3) (BuildId: 4eb338bebafc71b3519003fd1b76487cfb8fb27b) #2 0x40146f in main (/app/output.s+0x40146f) (BuildId: 4eb338bebafc71b3519003fd1b76487cfb8fb27b) #3 0x7f28b75e2082 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId: 1878e6b475720c7c51969e69ab2d276fae6d1dee) #4 0x4010fd in _start (/app/output.s+0x4010fd) (BuildId: 4eb338bebafc71b3519003fd1b76487cfb8fb27b) 0x004043e4 is located 0 bytes after global variable 'b' defined in '/app/example.cpp:1:8' (0x4043e0) of size 4 SUMMARY: AddressSanitizer: global-buffer-overflow (/app/output.s+0x4012a2) (BuildId: 4eb338bebafc71b3519003fd1b76487cfb8fb27b) in i Shadow bytes around the buggy address: 0x00404100: 00 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00 0x00404180: 00 00 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9 f9 f9 0x00404200: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 0x00404280: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 0x00404300: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 =>0x00404380: f9 f9 f9 f9 f9 f9 f9 f9 00 00 00 00[04]f9 f9 f9 0x00404400: f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9 0x00404480: f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 0x00404500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x00404580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x00404600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Container overflow: fc Array cookie:ac Intra object redzone:bb ASan internal: fe Left alloca redzone: ca Right alloca redzone:cb ==1==ABORTING In this case: ``` **c = ``` ... int **k = *k = *g |= **c; ``` Basically once I fixed the size issue (or use -m32) there is profile difference.
[Bug target/110733] [14 Regression] ICE: in curr_insn_transform, at lra-constraints.cc:4259 (unable to generate reloads for: {*one_cmplv16qi2}) with -O -fno-omit-frame-pointer -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110733 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #3 from Andrew Pinski --- .
[Bug middle-end/111799] [14 Regression] Missed Dead Code Elimination since r14-2365-g2e406f0753e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111799
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|tree-optimization |middle-end
Ever confirmed|0 |1
Keywords||TREE
Last reconfirmed||2023-10-18
--- Comment #5 from Andrew Pinski ---
(In reply to Theodoros Theodoridis from comment #4)
> Oops, there was a bug in my reduction, here's the fixed code:
>
> https://godbolt.org/z/shxffzs8E
>
> void foo(void);
> typedef unsigned short uint16_t;
> static int b;
> static int c;
> static int *f =
> static int *ad;
> static char(a)(char g, char h) { return g + h; }
> static char(d)(char g, char h) { return g * h; }
> static void(e)(uint16_t g) {
> if (!(((g) >= 1) && ((g) <= 65459))) {
> __builtin_unreachable();
> }
> }
> int main() {
> b = 0;
> for (;; b = 1) {
> char i = d(126 | 1, 205);
> e(i);
> short j;
> int k = *f;
> j = -21;
> for (; j; j = a(j, 7)) e((j ^ k && *f) <= *f);
> if (b) break;
> ad =
> }
> if (ad)
> ;
> else
> foo();
> ;
> }
Confirmed with this testcase but what is interesting is that the optimization
of calling foo away does NOT happen at the gimple level but at the RTL level
and just happens on x86_64 but NOT on aarch64.
on aarch64 for GCC 13, we even have:
mov w0, 1
str wzr, [x1, #:lo12:.LANCHOR0]
cbz w0, .L13
Which is obvious should have been removed ...
Anyways this is a missed jump threading that should have happened at the gimple
level. I have not looked into why it is not done.
[Bug middle-end/110986] [14 Regression] aarch64 has support for conditional not (and vectorized conditional not ) after r14-3110-g7fb65f10285
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110986 Andrew Pinski changed: What|Removed |Added Attachment #56134|0 |1 is obsolete|| --- Comment #22 from Andrew Pinski --- Created attachment 56146 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56146=edit patch under test
[Bug tree-optimization/111791] RISC-V: Strange loop vectorizaion on popcount function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111791 --- Comment #6 from Andrew Pinski --- (In reply to Vineet Gupta from comment #5) > (In reply to Robin Dapp from comment #4) > > > Analyzing loop at pr111791.c:8 > > pr111791.c:8:25: note: === analyze_loop_nest === > > pr111791.c:8:25: note: === vect_analyze_loop_form === > > pr111791.c:8:25: note:=== get_loop_niters === > > Matching expression match.pd:1919, generic-match-8.cc:27 > > Applying pattern match.pd:1975, generic-match-2.cc:4670 > > Matching expression match.pd:2707, generic-match-4.cc:36 > > Matching expression match.pd:2710, generic-match-3.cc:53 > > Matching expression match.pd:2717, generic-match-2.cc:23 > > Matching expression match.pd:2707, generic-match-4.cc:36 > > Matching expression match.pd:2710, generic-match-3.cc:53 > > Matching expression match.pd:2717, generic-match-2.cc:23 > > Matching expression match.pd:2707, generic-match-4.cc:36 > > Matching expression match.pd:2710, generic-match-3.cc:53 > > Matching expression match.pd:2717, generic-match-2.cc:23 > > Matching expression match.pd:148, generic-match-10.cc:27 > > Matching expression match.pd:148, generic-match-10.cc:27 > > Applying pattern match.pd:4519, generic-match-4.cc:2923 > > Applying pattern match.pd:201, generic-match-4.cc:3103 > > Applying pattern match.pd:3393, generic-match-2.cc:182 > > pr111791.c:8:25: note: Symbolic number of iterations is (unsigned intD.4) > > __builtin_popcountlD.1952 (value_4(D)) > > Curious, how did you get this debug output - is this just one of > -fdump-tree-? The `applying pattern`/`matching expression` comes from `-folding` option of `-fdump-tree-`. It is enabled with `-all` at the end too. So in this case it looks like it was: `-fdump-tree-vect-all` since both __builtin_popcount and the type `unsigned int` has the decl ID at the end (that is what `D.4` and `D.1952` are).
[Bug tree-optimization/111791] RISC-V: Strange loop vectorizaion on popcount function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111791 --- Comment #5 from Vineet Gupta --- (In reply to Robin Dapp from comment #4) > Analyzing loop at pr111791.c:8 > pr111791.c:8:25: note: === analyze_loop_nest === > pr111791.c:8:25: note: === vect_analyze_loop_form === > pr111791.c:8:25: note:=== get_loop_niters === > Matching expression match.pd:1919, generic-match-8.cc:27 > Applying pattern match.pd:1975, generic-match-2.cc:4670 > Matching expression match.pd:2707, generic-match-4.cc:36 > Matching expression match.pd:2710, generic-match-3.cc:53 > Matching expression match.pd:2717, generic-match-2.cc:23 > Matching expression match.pd:2707, generic-match-4.cc:36 > Matching expression match.pd:2710, generic-match-3.cc:53 > Matching expression match.pd:2717, generic-match-2.cc:23 > Matching expression match.pd:2707, generic-match-4.cc:36 > Matching expression match.pd:2710, generic-match-3.cc:53 > Matching expression match.pd:2717, generic-match-2.cc:23 > Matching expression match.pd:148, generic-match-10.cc:27 > Matching expression match.pd:148, generic-match-10.cc:27 > Applying pattern match.pd:4519, generic-match-4.cc:2923 > Applying pattern match.pd:201, generic-match-4.cc:3103 > Applying pattern match.pd:3393, generic-match-2.cc:182 > pr111791.c:8:25: note: Symbolic number of iterations is (unsigned intD.4) > __builtin_popcountlD.1952 (value_4(D)) Curious, how did you get this debug output - is this just one of -fdump-tree-?
[Bug target/111870] Miscompile of atomic rmw or on x86 (not aarch, though)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111870 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|WAITING |RESOLVED --- Comment #10 from Andrew Pinski --- There is no atomicity issue here. If we need the old (or new) value, we use a compare-and-exchange loop to get the old value. If we don't need it, we use an atomic or.
[Bug c/101364] ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in c_type_promotes_to, at c/c-typeck.c:278
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101364 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |14.0 Resolution|--- |FIXED --- Comment #6 from Andrew Pinski --- Fixed.
[Bug middle-end/111863] [14 Regression] Wrong code with "-O3 -fno-tree-ccp -fno-tree-dominator-opts -fno-tree-vrp" since r14-1600
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111863 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Andrew Pinski --- Fixed.
[Bug c/101285] [11/12/13/14 Regression] ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in c_safe_arg_type_equiv_p, at c/c-typeck.c:5830
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101285 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Andrew Pinski --- .
[Bug c/101285] [11/12/13/14 Regression] ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in c_safe_arg_type_equiv_p, at c/c-typeck.c:5830
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101285 Andrew Pinski changed: What|Removed |Added Target Milestone|11.5|14.0 --- Comment #8 from Andrew Pinski --- Fixed on the trunk, this is an error recovery issue so not backporting.
[Bug middle-end/111863] [14 Regression] Wrong code with "-O3 -fno-tree-ccp -fno-tree-dominator-opts -fno-tree-vrp" since r14-1600
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111863 --- Comment #11 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:b20dbddcc41120144e700c4e3ef1ec396b1c56ab commit r14-4729-gb20dbddcc41120144e700c4e3ef1ec396b1c56ab Author: Andrew Pinski Date: Wed Oct 18 10:26:07 2023 -0700 Fix expansion of `(a & 2) != 1` I had a thinko in r14-1600-ge60593f3881c72a96a3fa4844d73e8a2cd14f670 where we would remove the `& CST` part if we ended up not calling expand_single_bit_test. This fixes the problem by introducing a new variable that will be used for calling expand_single_bit_test. As afar as I know this can only show up when disabling optimization passes as this above form would have been optimized away. Committed as obvious after a bootstrap/test on x86_64-linux-gnu. PR middle-end/111863 gcc/ChangeLog: * expr.cc (do_store_flag): Don't over write arg0 when stripping off `& POW2`. gcc/testsuite/ChangeLog: * gcc.c-torture/execute/pr111863-1.c: New test.
[Bug c/101364] ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in c_type_promotes_to, at c/c-typeck.c:278
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101364 --- Comment #5 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:879c91fcccf93681bd7e13290bfbb384cadcd268 commit r14-4728-g879c91fcccf93681bd7e13290bfbb384cadcd268 Author: Andrew Pinski Date: Sat Oct 14 13:40:05 2023 -0700 [c] Fix PR 101364: ICE after error due to diagnose_arglist_conflict not checking for error When checking to see if we have a function declaration has a conflict due to promotations, there is no test to see if the type was an error mark and then calls c_type_promotes_to. c_type_promotes_to is not ready for error_mark and causes an ICE. This adds a check for error before the call of c_type_promotes_to. OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions. PR c/101364 gcc/c/ChangeLog: * c-decl.cc (diagnose_arglist_conflict): Test for error mark before calling of c_type_promotes_to. gcc/testsuite/ChangeLog: * gcc.dg/pr101364-1.c: New test.
[Bug c/101285] [11/12/13/14 Regression] ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in c_safe_arg_type_equiv_p, at c/c-typeck.c:5830
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101285 --- Comment #7 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:11e6bcedb41359c69ee790f38b04033d236336a8 commit r14-4727-g11e6bcedb41359c69ee790f38b04033d236336a8 Author: Andrew Pinski Date: Sat Oct 14 13:18:00 2023 -0700 Fix ICE due to c_safe_arg_type_equiv_p not checking for error_mark node This is a simple error recovery issue when c_safe_arg_type_equiv_p was added in r8-5312-gc65e18d3331aa999. The issue is that after an error, an argument type (of a function type) might turn into an error mark node and c_safe_arg_type_equiv_p was not ready for that. So this just adds a check for error operand for its arguments before getting the main variant. OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions. PR c/101285 gcc/c/ChangeLog: * c-typeck.cc (c_safe_arg_type_equiv_p): Return true for error operands early. gcc/testsuite/ChangeLog: * gcc.dg/pr101285-1.c: New test.
[Bug bootstrap/111601] [14 Regression] bootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601 --- Comment #6 from Peter Bergner --- (In reply to Andrew Pinski from comment #5) > (In reply to Peter Bergner from comment #4) > > CCing richi and jakub to see if they've seen anything like this before? > > I suspect we are miscompiling the final compiler somehow. I linked 2 other > reports which reported that PGO is causing wrong code; I have not looked > into confirming them yet though. Thanks and yes, I agree. Luckily those test cases are MUCH smaller than gcc itself. Hopefully the bug is the same!
[Bug driver/103398] configure: Enable --enable-default-pie by default for Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103398 Mark Esler changed: What|Removed |Added CC||mark.esler at canonical dot com --- Comment #4 from Mark Esler --- (In reply to Andrew Pinski from comment #1) > No. The whole reason why there is an option is because it is optional. Could this issue be re-considered? Or should -fhardened and related endeavors all re-suggest the specific flags that --enable-default-pie provides?
[Bug bootstrap/111601] [14 Regression] bootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601 --- Comment #5 from Andrew Pinski --- (In reply to Peter Bergner from comment #4) > CCing richi and jakub to see if they've seen anything like this before? I suspect we are miscompiling the final compiler somehow. I linked 2 other reports which reported that PGO is causing wrong code; I have not looked into confirming them yet though.
[Bug target/111870] Miscompile of atomic rmw or on x86 (not aarch, though)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111870
--- Comment #9 from Andrew Pinski ---
If I change your testcase to be:
uint64_t huh2 (_Atomic(uint64_t)* map, int t) {
return atomic_fetch_or_explicit(map, t, memory_order_relaxed);
}
You will see that it does the `lock cmpxchg` loop too.
[Bug target/111870] Miscompile of atomic rmw or on x86 (not aarch, though)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111870 --- Comment #8 from Andrew Pinski --- On aarch64, ldset does both a load and ior. that is unlike the `lock or` on x86.
[Bug target/111870] Miscompile of atomic rmw or on x86 (not aarch, though)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111870 --- Comment #7 from Andrew Pinski --- That is not using the fetch part is optimized to just `lock or`.
[Bug target/111870] Miscompile of atomic rmw or on x86 (not aarch, though)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111870 --- Comment #6 from Andrew Pinski --- If you don't use the return value of atomic_fetch_or_explicit, there is no need for a compare-and-exchange (swap) loop. If you need the fetch part, the compare-and-exchange loop needs to be used as `lock or` does not provide that. I still don't understand what exactly you are saying is wrong except you want to use `lock or` in both cases but you can't since that will not get the right atomic fetch part of the atomic_fetch_or.
[Bug bootstrap/111601] [14 Regression] bootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
Peter Bergner changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
--- Comment #4 from Peter Bergner ---
(In reply to Peter Bergner from comment #3)
> I'll try and see if I can reduce the test case.
cvise reduced this down to:
bergner@ltcden2-lp1:$ cat pr111601.ii
struct param_type {
param_type() : param_type(0.5) { }
param_type(double);
};
bergner@ltcden2-lp1:$
/home/bergner/gcc/build/gcc-fsf-mainline-pr111601-regtest/./gcc/xgcc
-B/home/bergner/gcc/build/gcc-fsf-mainline-pr111601-regtest/./gcc
-shared-libgcc -fno-checking -x c++-header -nostdinc++ -O2 -S pr111601.ii
pr111601.ii: In constructor ‘param_type::param_type()’:
pr111601.ii:2:32: internal compiler error: tree check: expected tree that
contains ‘decl common’ structure, have ‘’ in
build_new_method_call, at cp/call.cc:11630
2 | param_type() : param_type(0.5) { }
|^
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See
[Bug target/111870] Miscompile of atomic rmw or on x86 (not aarch, though)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111870 --- Comment #5 from isoosqa --- Please, forgive me. I typed stuff wrong in original link
[Bug target/111870] Miscompile of atomic rmw or on x86 (not aarch, though)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111870 --- Comment #4 from isoosqa --- Oops, I sent wrong code. This is the one https://godbolt.org/z/GxdvMdP76
[Bug target/111870] Miscompile of atomic rmw or on x86 (not aarch, though)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111870
--- Comment #3 from Andrew Pinski ---
Or maybe the issue is you don't understand the cmpxchg instruction and how it
gives back the original value too.
The RTL form for the "lock;cmpxchg " is:
(insn:TI 14 10 17 5 (parallel [
(set (reg:DI 0 ax [108])
(unspec_volatile:DI [
(mem/v:DI (reg/v/f:DI 5 di [orig:105 map ] [105]) [-1
S8 A64])
(reg:DI 0 ax [108])
(reg:DI 4 si [107])
(const_int 32773 [0x8005])
] UNSPECV_CMPXCHG))
(set (mem/v:DI (reg/v/f:DI 5 di [orig:105 map ] [105]) [-1 S8
A64])
(unspec_volatile:DI [
(const_int 0 [0])
] UNSPECV_CMPXCHG))
(set (reg:CCZ 17 flags)
(unspec_volatile:CCZ [
(const_int 0 [0])
] UNSPECV_CMPXCHG))
]) "/app/example.c":15:22 9336 {atomic_compare_and_swapdi_1}
(expr_list:REG_DEAD (reg:DI 4 si [107])
(nil)))
[Bug target/111870] Miscompile of atomic rmw or on x86 (not aarch, though)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111870 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-10-18 Status|UNCONFIRMED |WAITING --- Comment #2 from Andrew Pinski --- >atomicity of load gets elided. No IT DOES NOT. mov rax, QWORD PTR [rdi] .L3: mov rsi, rax mov rdx, rax or rsi, 1 lock cmpxchgQWORD PTR [rdi], rsi jne .L3 That is correct as far as I know. an atomic load from [rdi] and then do the or and then do a compare-and-exchange with the new value (old value was in rdx for the comparison and the new value is stored into rax). That is very much atomically doing the IOR.
[Bug target/111870] Miscompile of atomic rmw or on x86 (not aarch, though)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111870 --- Comment #1 from Andrew Pinski --- Created attachment 56145 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56145=edit testcase Next time please enter attach or place inline the testcase rather than just a link.
[Bug c/111870] New: Miscompile of atomic rmw or on x86 (not aarch, though)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111870 Bug ID: 111870 Summary: Miscompile of atomic rmw or on x86 (not aarch, though) Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: fallenleafs at icloud dot com Target Milestone: --- Recently I wrote one little piece of code that gave me too much headache. After investigation, I discovered that on x86 the sequence of instructions that GCC (strangely, llvm as well) produces is invalid because after applying optimisations, atomicity of load gets elided. You can witness that gcc makes up nonsense here[https://godbolt.org/z/Thfeq1KGW]. There you can find c code and if you compile it with gcc13.2 to aarch, atomic_fetch_or_explicit gets translated to a loop of a pair of special load-store instructions which is correct lowering, but if you do it for x86, you can, in fact, witness that generated code does not contain `lock or ...` instruction, which would be correct code, but instead `lock cmpxchg ...` which is invalid.
[Bug target/111857] RISC-V: Failed to vectorize small GNU vector if zvl4096b with fixed-vlmax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111857 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug tree-optimization/111869] ICE: verify_ssa failed since r14-4710-g60c231cb658
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111869 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 111860 ***
[Bug tree-optimization/111860] [14 Regression] incorrect vUSE after guard block loop skip block during vectorization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111860 Andrew Pinski changed: What|Removed |Added CC||shaohua.li at inf dot ethz.ch --- Comment #9 from Andrew Pinski --- *** Bug 111869 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/111860] [14 Regression] incorrect vUSE after guard block loop skip block during vectorization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111860 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #8 from Andrew Pinski --- .
[Bug tree-optimization/111791] RISC-V: Strange loop vectorizaion on popcount function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111791
--- Comment #4 from Robin Dapp ---
This is a scalar popcount and as Kito already noted we will just emit
cpop a0, a0
once the zbb extension is present.
As to the question what is actually being vectorized here, I'm not so sure :D
It looks like we're generating a vectorized scalar popcount by something like a
reduction? But we already did the call to __popcountdi2?
Analyzing loop at pr111791.c:8
pr111791.c:8:25: note: === analyze_loop_nest ===
pr111791.c:8:25: note: === vect_analyze_loop_form ===
pr111791.c:8:25: note:=== get_loop_niters ===
Matching expression match.pd:1919, generic-match-8.cc:27
Applying pattern match.pd:1975, generic-match-2.cc:4670
Matching expression match.pd:2707, generic-match-4.cc:36
Matching expression match.pd:2710, generic-match-3.cc:53
Matching expression match.pd:2717, generic-match-2.cc:23
Matching expression match.pd:2707, generic-match-4.cc:36
Matching expression match.pd:2710, generic-match-3.cc:53
Matching expression match.pd:2717, generic-match-2.cc:23
Matching expression match.pd:2707, generic-match-4.cc:36
Matching expression match.pd:2710, generic-match-3.cc:53
Matching expression match.pd:2717, generic-match-2.cc:23
Matching expression match.pd:148, generic-match-10.cc:27
Matching expression match.pd:148, generic-match-10.cc:27
Applying pattern match.pd:4519, generic-match-4.cc:2923
Applying pattern match.pd:201, generic-match-4.cc:3103
Applying pattern match.pd:3393, generic-match-2.cc:182
pr111791.c:8:25: note: Symbolic number of iterations is (unsigned intD.4)
__builtin_popcountlD.1952 (value_4(D))
Ah, interesting: ranger(?) recognizes that the loop runs "popcount" iterations.
Shouldn't that still be 64? Well, it probably knows better :)
Regardless, we use this symbolic value as number of iterations:
_5 = __builtin_popcountlD.1952 (value_4(D));
niters.4_9 = (unsigned intD.4) _5;
_2 = __builtin_popcountlD.1952 (value_4(D));
bnd.5_3 = (unsigned intD.4) _2;
_23 = (unsigned long) bnd.5_3;
Then, it gets funnier:
# nbits_11 = PHI
# vect_vec_iv_.6_15 = PHI <_16(6), { 0, 1, 2, ... }(5)>
# ivtmp_24 = PHI
_26 = .SELECT_VL (ivtmp_24, POLY_INT_CST [4, 4]);
_16 = vect_vec_iv_.6_15 + { POLY_INT_CST [4, 4], ... };
vect_nbits_7.7_18 = vect_vec_iv_.6_15 + { 1, ... };
# RANGE [irange] int [1, 65]
nbits_7 = nbits_11 + 1;
# RANGE [irange] long unsigned int [0, 18446744073709551614]
_1 = value_10 + 18446744073709551615;
# RANGE [irange] long unsigned int [0, 18446744073709551614]
value_8 = _1 & value_10;
ivtmp_25 = ivtmp_24 - _26;
i.e. we have a vector IV that we add to the vectorized nbits. Finally we
extract the niter-th (=popcount) element from that vector only to get -
popcount :)
Still not sure why that happens but a vector-mode popcount expander doesn't
help here as everything is scalar. Maybe the explanation is simple in that we
would vectorize such a loop anyway and here it just looks particularly bad
because we already know the result via ranger?
[Bug tree-optimization/111869] New: ICE: verify_ssa failed since r14-4710-g60c231cb658
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111869
Bug ID: 111869
Summary: ICE: verify_ssa failed since r14-4710-g60c231cb658
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: shaohua.li at inf dot ethz.ch
CC: tamar.christina at arm dot com
Target Milestone: ---
gcc at -O3 crashed.
Bisected to r14-4710-g60c231cb658
$ cat a.c
int a;
unsigned b() {
long c;
unsigned d = 1;
char *e = "";
c = 0;
for (; c < a; c++)
e[0]++;
c = 0;
for (; c < a; c++)
if (c)
d = 0;
return d;
}
int main() {}
$
$ gcc -O3 a.c
a.c: In function ‘b’:
a.c:2:10: error: PHI node with wrong VUSE on edge from BB 14
2 | unsigned b() {
| ^
.MEM_39 = PHI <.MEM_1(14), .MEM_1(13)>
expected .MEM_29
a.c:2:10: error: PHI node with wrong VUSE on edge from BB 13
.MEM_39 = PHI <.MEM_1(14), .MEM_1(13)>
expected .MEM_29
during GIMPLE pass: vect
a.c:2:10: internal compiler error: verify_ssa failed
0x7f10859fa082 __libc_start_main
../csu/libc-start.c:308
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug bootstrap/111601] [14 Regression] bootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601 Peter Bergner changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2023-10-18 --- Comment #3 from Peter Bergner --- (In reply to Matthias Klose from comment #2) > this seems to be fixed on x86_64-linux-gnu with trunk 20231017. > powerpc64le-linux now fails in a different way, trying to build the > libstdc++ pch headers. > > Full build log at > https://buildd.debian.org/status/fetch.php?pkg=gcc- > snapshot=ppc64el=1%3A20231017-1=1697561774=1 Ok, that is the same error I'm seeing, so Confirmed. I'll try and see if I can reduce the test case.
[Bug fortran/111851] f951: Segmentation fault at gfc_delete_symtree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111851 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org --- Oddly, I'm seeing an ICE due to the assert() at line 3131 in symbol.cc(gfc_release_symbol). I don't see the memory hog issue. If I comment out that assert() and let gfortran proceed, I see % gfcx -c a.f90 a.f90:1:28: 1 | SELECT TYPE (rvec2ASSOCIATE( |1 Error: Syntax error in argument list at (1) On FreeBSD I use the following for configure ../gccx/configure --prefix=$HOME/work/x --enable-languages=c,c++,fortran,lto \ --enable-bootstrap --disable-nls --disable-multilib --enable-libsanitizer
[Bug target/110551] [11/12/13/14 Regression] an extra mov when doing 128bit multiply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110551 Roger Sayle changed: What|Removed |Added CC||roger at nextmovesoftware dot com --- Comment #4 from Roger Sayle --- Patch proposed: https://gcc.gnu.org/pipermail/gcc-patches/2023-October/67.html
[Bug tree-optimization/111648] [14 Regression] Wrong code at -O2/3 on x86_64-linux-gnu since r14-3243-ga7dba4a1c05
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111648 prathamesh3492 at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from prathamesh3492 at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/111648] [14 Regression] Wrong code at -O2/3 on x86_64-linux-gnu since r14-3243-ga7dba4a1c05
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111648 --- Comment #5 from CVS Commits --- The master branch has been updated by Prathamesh Kulkarni : https://gcc.gnu.org/g:3ec8ecb8e92faec889bc6f7aeac9ff59e82b4f7f commit r14-4726-g3ec8ecb8e92faec889bc6f7aeac9ff59e82b4f7f Author: Prathamesh Kulkarni Date: Thu Oct 19 00:29:38 2023 +0530 PR111648: Fix wrong code-gen due to incorrect VEC_PERM_EXPR folding. gcc/ChangeLog: PR tree-optimization/111648 * fold-const.cc (valid_mask_for_fold_vec_perm_cst_p): If a1 chooses base element from arg, ensure that it's a natural stepped sequence. (build_vec_cst_rand): New param natural_stepped and use it to construct a naturally stepped sequence. (test_nunits_min_2): Add new unit tests Case 6 and Case 7.
[Bug c/110500] gcc: internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in c_parser_omp_clause_allocate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110500 --- Comment #3 from Andrew Pinski --- *** Bug 111862 has been marked as a duplicate of this bug. ***
[Bug c/111862] GCC: internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in c_parser_omp_clause_reduction, at c/c-parser.cc:16234
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111862 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup of bug 110500 (which was not fixed yet; just a patch was posted to the bug report for someone to finish up). *** This bug has been marked as a duplicate of bug 110500 ***
[Bug target/96347] note: non-delegitimized UNSPEC UNSPEC_TP (19) found in variable location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96347 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #6 from Iain Buclaw --- (releases/gcc-9) $ ./gcc/xg++ -B ./gcc/ pr.cc -O2 -g -fchecking pr.cc: In function ‘int main()’: pr.cc:45:5: note: non-delegitimized UNSPEC UNSPEC_TP (19) found in variable location 45 | int main (void) | ^~~~ pr.cc:45:5: note: non-delegitimized UNSPEC UNSPEC_TP (19) found in variable location (releases/gcc-10) $ ./gcc/xg++ -B ./gcc/ pr.cc -O2 -g -fchecking pr.cc: In function ‘int main()’: pr.cc:45:5: note: non-delegitimized UNSPEC UNSPEC_TP (19) found in variable location 45 | int main (void) | ^~~~ pr.cc:45:5: note: non-delegitimized UNSPEC UNSPEC_TP (19) found in variable location pr.cc:45:5: note: non-delegitimized UNSPEC UNSPEC_TP (19) found in variable location (releases/gcc-11) $ ./gcc/xg++ -B ./gcc/ pr.cc -O2 -g -fchecking (releases/gcc-12) $ ./gcc/xg++ -B ./gcc/ pr.cc -O2 -g -fchecking (releases/gcc-13) $ ./gcc/xg++ -B ./gcc/ pr.cc -O2 -g -fchecking (trunk) $ ./gcc/xg++ -B ./gcc/ pr.cc -O2 -g -fchecking Minimal test is only reproducible on the 9.x and 10.x compilers, and I've not seen it crop up again in any D testsuite runs. I'll just close this then.
[Bug tree-optimization/111866] [14 regression] ICE when compiling gcc.target/powerpc/p9-vec-length-full-7.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111866 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-10-18 Keywords||ice-on-valid-code Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #2 from Andrew Pinski --- .
[Bug middle-end/61192] Conflict between global register and function name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61192 --- Comment #7 from Andrew Pinski --- Created attachment 56144 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56144=edit Another testcase
[Bug middle-end/61192] Conflict between global register and function name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61192 Andrew Pinski changed: What|Removed |Added CC||141242068 at smail dot nju.edu.cn --- Comment #6 from Andrew Pinski --- *** Bug 111865 has been marked as a duplicate of this bug. ***
[Bug middle-end/111865] [11/12/13/14 Regression] ICE with register decl and extern decl with the same asm name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111865 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #4 from Andrew Pinski --- Basically a dup of bug 61192. *** This bug has been marked as a duplicate of bug 61192 ***
[Bug middle-end/111865] [11/12/13/14 Regression] ICE with register decl and extern decl with the same asm name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111865 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2023-10-18 Ever confirmed|0 |1 --- Comment #3 from Andrew Pinski --- Confirmed.
[Bug middle-end/111865] [11/12/13/14 Regression] ICE with register decl and extern decl with the same asm name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111865
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> Created attachment 56143 [details]
> testcase that could go into the testsuite with more targets supported
Add:
```
#elif defined __aarch64__
# define ASM __asm__("sp")
```
To it too.
[Bug middle-end/111865] [11/12/13/14 Regression] ICE with register decl and extern decl with the same asm name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111865 --- Comment #1 from Andrew Pinski --- Created attachment 56143 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56143=edit testcase that could go into the testsuite with more targets supported
[Bug middle-end/111865] [11/12/13/14 Regression] ICE with register decl and extern decl with the same asm name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111865 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.5 Summary|GCC: 14: internal compiler |[11/12/13/14 Regression] |error: symtab_node::verify |ICE with register decl and |failed |extern decl with the same ||asm name Known to fail||9.1.0
[Bug target/111867] aarch64: Wrong code for bf16 literal load when the arch support +fp16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111867 --- Comment #4 from Iain Sandoe --- (In reply to Andrew Pinski from comment #3) > (In reply to Andrew Pinski from comment #2) > > Maybe something like: > > diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc > > index 62b1ae0652f..db2dde84329 100644 > > --- a/gcc/config/aarch64/aarch64.cc > > +++ b/gcc/config/aarch64/aarch64.cc > > @@ -23788,7 +23788,8 @@ aarch64_float_const_representable_p (rtx x) > > return false; > > > >if (GET_MODE (x) == VOIDmode > > - || (GET_MODE (x) == HFmode && !TARGET_FP_F16INST)) > > + || (GET_MODE (x) == HFmode && !TARGET_FP_F16INST) > > + || (GET_MODE (x) == BFmode)) > > return false; > > > >r = *CONST_DOUBLE_REAL_VALUE (x); Yeah that fixes this case; re-running the testsuite to see if that clears any other bf16 fails. > That is there are no fmov instructions for bfmode constants ... Although I notice there's a spare bit pattern in the "ftype" field [0b10) in the fmov insn... but I guess that's being kept for something more useful than bf16.
[Bug middle-end/111868] [14 regression] many ICEs after r14-4710
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111868 Tamar Christina changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Tamar Christina --- Duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111860 patch going through regression testing. *** This bug has been marked as a duplicate of bug 111860 ***
[Bug tree-optimization/111860] [14 Regression] incorrect vUSE after guard block loop skip block during vectorization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111860 Tamar Christina changed: What|Removed |Added CC||seurer at gcc dot gnu.org --- Comment #7 from Tamar Christina --- *** Bug 111868 has been marked as a duplicate of this bug. ***
[Bug target/111867] aarch64: Wrong code for bf16 literal load when the arch support +fp16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111867 --- Comment #3 from Andrew Pinski --- (In reply to Andrew Pinski from comment #2) > Maybe something like: > diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc > index 62b1ae0652f..db2dde84329 100644 > --- a/gcc/config/aarch64/aarch64.cc > +++ b/gcc/config/aarch64/aarch64.cc > @@ -23788,7 +23788,8 @@ aarch64_float_const_representable_p (rtx x) > return false; > >if (GET_MODE (x) == VOIDmode > - || (GET_MODE (x) == HFmode && !TARGET_FP_F16INST)) > + || (GET_MODE (x) == HFmode && !TARGET_FP_F16INST) > + || (GET_MODE (x) == BFmode)) > return false; > >r = *CONST_DOUBLE_REAL_VALUE (x); That is there are no fmov instructions for bfmode constants ...
[Bug middle-end/111868] New: [14 regression] many ICEs after r14-4710
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111868 Bug ID: 111868 Summary: [14 regression] many ICEs after r14-4710 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:60c231cb65807fb963624acc4f82d2935e305f93, r14-4710-g60c231cb65807f FAIL: libgomp.fortran/pr100981-2.f90 -O1 (internal compiler error: verify_ssa failed) FAIL: libgomp.fortran/pr100981-2.f90 -O1 (test for excess errors) FAIL: libgomp.fortran/pr100981-2.f90 -O2 (internal compiler error: verify_ssa failed) FAIL: libgomp.fortran/pr100981-2.f90 -O2 (test for excess errors) FAIL: libgomp.fortran/pr100981-2.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (internal compiler error: verify_ssa failed) FAIL: libgomp.fortran/pr100981-2.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) FAIL: libgomp.fortran/pr100981-2.f90 -O3 -g (internal compiler error: verify_ssa failed) FAIL: libgomp.fortran/pr100981-2.f90 -O3 -g (test for excess errors) FAIL: libgomp.fortran/pr100981-2.f90 -Os (internal compiler error: verify_ssa failed) FAIL: libgomp.fortran/pr100981-2.f90 -Os (test for excess errors) FAIL: libgomp.fortran/simd3.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (internal compiler error: verify_ssa failed) FAIL: libgomp.fortran/simd3.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) FAIL: libgomp.fortran/simd3.f90 -O3 -g (internal compiler error: verify_ssa failed) FAIL: libgomp.fortran/simd3.f90 -O3 -g (test for excess errors) spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/../../gfortran -B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/../../ -B/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgfortran/ /home/seurer/gcc/git/gcc-test/gcc/testsuite/gfortran.dg/vect/pr100981-1.f90 -fdiagnostics-plain-output -fdiagnostics-plain-output -O -O2 -ftree-vectorize -fvect-cost-model=unlimited -fdump-tree-vect-details -maltivec -mpower9-vector -O3 -ftree-parallelize-loops=2 -fno-signed-zeros -fno-trapping-math -S -o pr100981-1.s /home/seurer/gcc/git/gcc-test/gcc/testsuite/gfortran.dg/vect/pr100981-1.f90:5:23: Error: stmt with wrong VUSE # VUSE <.MEM_17(D)> _82 = REALPART_EXPR <(*cx_22(D))[_83]>; expected .MEM_39 /home/seurer/gcc/git/gcc-test/gcc/testsuite/gfortran.dg/vect/pr100981-1.f90:5:23: Error: stmt with wrong VUSE # VUSE <.MEM_17(D)> _80 = IMAGPART_EXPR <(*cx_22(D))[_83]>; expected .MEM_39 /home/seurer/gcc/git/gcc-test/gcc/testsuite/gfortran.dg/vect/pr100981-1.f90:5:23: Error: PHI node with wrong VUSE on edge from BB 34 .MEM_23 = PHI <.MEM_17(D)(34), .MEM_17(D)(33)> expected .MEM_39 /home/seurer/gcc/git/gcc-test/gcc/testsuite/gfortran.dg/vect/pr100981-1.f90:5:23: Error: PHI node with wrong VUSE on edge from BB 33 .MEM_23 = PHI <.MEM_17(D)(34), .MEM_17(D)(33)> expected .MEM_39 during GIMPLE pass: vect dump file: pr100981-1.f90.175t.vect /home/seurer/gcc/git/gcc-test/gcc/testsuite/gfortran.dg/vect/pr100981-1.f90:5:23: internal compiler error: verify_ssa failed 0x110e9d2f verify_ssa(bool, bool) /home/seurer/gcc/git/gcc-test/gcc/tree-ssa.cc:1203 0x10bd279f execute_function_todo /home/seurer/gcc/git/gcc-test/gcc/passes.cc:2095 0x10bd35ab do_per_function /home/seurer/gcc/git/gcc-test/gcc/passes.cc:1687 0x10bd37cb execute_todo /home/seurer/gcc/git/gcc-test/gcc/passes.cc:2142 commit 60c231cb65807fb963624acc4f82d2935e305f93 (HEAD) Author: Tamar Christina Date: Wed Oct 18 09:03:06 2023 +0100 middle-end: maintain LCSSA throughout loop peeling
[Bug target/111867] aarch64: Wrong code for bf16 literal load when the arch support +fp16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111867 --- Comment #2 from Andrew Pinski --- Maybe something like: diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc index 62b1ae0652f..db2dde84329 100644 --- a/gcc/config/aarch64/aarch64.cc +++ b/gcc/config/aarch64/aarch64.cc @@ -23788,7 +23788,8 @@ aarch64_float_const_representable_p (rtx x) return false; if (GET_MODE (x) == VOIDmode - || (GET_MODE (x) == HFmode && !TARGET_FP_F16INST)) + || (GET_MODE (x) == HFmode && !TARGET_FP_F16INST) + || (GET_MODE (x) == BFmode)) return false; r = *CONST_DOUBLE_REAL_VALUE (x);
[Bug target/111867] aarch64: Wrong code for bf16 literal load when the arch support +fp16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111867
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Target|aarch64-linux-gnu, |aarch64
|aarch64-apple-darwin|
Last reconfirmed||2023-10-18
Ever confirmed|0 |1
--- Comment #1 from Andrew Pinski ---
This is definitely wrong:
(insn 5 2 6 (set (reg:BF 63 v31 [95])
(const_double:BF 1.0e+0 [0x0.8p+1])) "/app/example.cpp":4:10 72
{*movbf_aarch64}
(nil))
Confirmed.
[Bug target/111867] New: aarch64: Wrong code for bf16 literal load when the arch support +fp16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111867
Bug ID: 111867
Summary: aarch64: Wrong code for bf16 literal load when the
arch support +fp16
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: iains at gcc dot gnu.org
Target Milestone: ---
Analysing some target fails for aarch64-darwin.
The base arch for Apple M1 is (as far as I can determine)
armv8.4-a+fp16+sb+ssbs
So it has fp16 and fp15fml 0 but not bf16.
(M2 does have bf16).
===
int main ()
{
__bf16 a = 1.0bf16;
return (int) (a + a);
}
=== with the arch flags above produces:
_main:
fmovh31, 1.0e+0
str h31, [x29, 46]
ldr h15, [x29, 46]
mov v0.h[0], v15.h[0]
bl ___extendbfsf2
fmovs14, s0
Which seems to be loading an __fp16 value into h31 (not a __bf16 value)
not surprisingly this fails.
I checked the instruction bit pattern with objdump, and it is 0x1eee101f, which
is clearly a fp16 load.
with pruned arch flags armv8.4-a
_main:
adrpx0, lC0@PAGE
ldr h31, [x0, #lC0@PAGEOFF]
str h31, [x29, 30]
ldr h0, [x29, 30]
bl ___extendbfsf2
lC0:
.hword 16256
which looks correct (and produces the expected answer).
So support for fp16 seems to be breaking soft __bf16.
[Bug target/111528] aarch64: Test gfortran.dg/pr80494.f90 fails with -fstack-protector-strong with gcc-13 since r13-7813-gb96e66fd4ef3e3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111528 --- Comment #5 from CVS Commits --- The releases/gcc-13 branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:f5e56c5857cc6b704446c3666213468d25f6dcb2 commit r13-7961-gf5e56c5857cc6b704446c3666213468d25f6dcb2 Author: Richard Sandiford Date: Wed Oct 18 18:44:57 2023 +0100 lra: Avoid unfolded plus-0 While backporting another patch to an earlier release, I hit a situation in which lra_eliminate_regs_1 would eliminate an address to: (plus (reg:P R) (const_int 0)) This address compared not-equal to plain: (reg:P R) which caused an ICE in a later peephole2. (The ICE showed up in gfortran.fortran-torture/compile/pr80464.f90 on the branch but seems to be latent on trunk.) These unfolded PLUSes shouldn't occur in the insn stream, and later code in the same function tried to avoid them. gcc/ PR target/111528 * lra-eliminations.cc (lra_eliminate_regs_1): Use simplify_gen_binary rather than gen_rtx_PLUS. (cherry picked from commit 10d59b802a7db9ae908291fb20627c1493cfa26c)
[Bug middle-end/111863] [14 Regression] Wrong code with "-O3 -fno-tree-ccp -fno-tree-dominator-opts -fno-tree-vrp" since r14-1600
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111863 --- Comment #10 from Andrew Pinski --- Created attachment 56142 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56142=edit Reduced self-contained testcase
[Bug fortran/110644] Error in gfc_format_decoder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644
--- Comment #5 from Steve Kargl ---
On Wed, Oct 18, 2023 at 03:56:32PM +, aluaces at udc dot es wrote:
> --- Comment #4 from Alberto Luaces ---
> I got the same error in almost the same circumstances (crash in
> error.cc:1078).
>
> I have a large codebase and I could not prepare a minimal testcase, but I have
> built gfortran 13 from source with the aim to debug the crash.
>
> Hoewever, even I set "set follow-fork-mode children", f951 crashes and I
> cannot
> navigate through the backtrace nor see the arguments of the functions.
>
> Is there any reference for debugging gcc in order to send some useful
> information to this bug?
>
If you've built 13 and still have the source files and build
directory, then locate the installed l f951. For me, I have
${HOME}/work/x/libexec/gcc/x86_64-unknown-freebsd14.0/14.0.0/f951
In following, I'm going to use ${PATH} for the above path.
Go to the directory where your project dies. Suppose it is
compiling foo.f90 when it crashes. Do the following.
gdb ${PATH}/f951
(gdb) b error.cc:1078
(gdb) run foo.f90
Line 1078 is
gcc_assert (loc->nextc - loc->lb->line >= 0);
so the source file information looks corrupt. You may need to
continue the process a few to generate the crash, i.e.,
(gdb) c
(gdb) bt
This will generate a backtrace. Post that.
[Bug c++/89038] #pragma GCC diagnostic ignored "-Wunknown-pragmas" does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89038 Lewis Hyatt changed: What|Removed |Added CC||lhyatt at gcc dot gnu.org Status|RESOLVED|NEW Resolution|DUPLICATE |--- --- Comment #6 from Lewis Hyatt --- -Wunknown-pragmas is a special case because it is emitted during preprocessing, but not directly by the preprocessor (rather from a callback in C frontend), so in the options file, it is not tagged as a preprocessor warning, and hence wasn't fixed by the mechanism introduced for PR53431. I'll submit a patch shortly: diff --git a/gcc/c-family/c-pragma.cc b/gcc/c-family/c-pragma.cc index 293311dd4ce..98dfb0f108b 100644 --- a/gcc/c-family/c-pragma.cc +++ b/gcc/c-family/c-pragma.cc @@ -963,7 +963,8 @@ handle_pragma_diagnostic_impl () /* option_string + 1 to skip the initial '-' */ unsigned int option_index = find_opt (data.option_str + 1, lang_mask); - if (early && !c_option_is_from_cpp_diagnostics (option_index)) + if (early && !(c_option_is_from_cpp_diagnostics (option_index) +|| option_index == OPT_Wunknown_pragmas)) return; if (option_index == OPT_SPECIAL_unknown)
[Bug bootstrap/111852] [14 regression] r14-4339-geaa41a6dc127d8 breaks building with gcc 4.8.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111852 --- Comment #6 from Jakub Jelinek --- In several gcc ml (or gcc-patches, don't remember) threads it was discussed whether we should switch to C++14 as the implementation language, that would bump to the bootstrap compiler requirement to GCC 5 (core language features, maybe GCC 6 if we need full library side, certainly GCC 6 switched to -std=gnu++14 by default). Today on IRC this was discussed again, and I think Richi proposed switching just for GCC 15, not 14.
[Bug bootstrap/111852] [14 regression] r14-4339-geaa41a6dc127d8 breaks building with gcc 4.8.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111852 --- Comment #5 from seurer at gcc dot gnu.org --- Yup, thanks! In another 4.8.5 breakage PR someone mentioned removing that as the minimum required compiler level. Has there been any more discussion of that?
[Bug middle-end/111863] [14 Regression] Wrong code with "-O3 -fno-tree-ccp -fno-tree-dominator-opts -fno-tree-vrp" since r14-1600
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111863 --- Comment #9 from Andrew Pinski --- Created attachment 56141 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56141=edit untested fix This fixes the reuse of arg0 so we don't change it for the later on code.
[Bug middle-end/111863] [14 Regression] Wrong code with "-O3 -fno-tree-ccp -fno-tree-dominator-opts -fno-tree-vrp" since r14-1600
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111863 --- Comment #8 from Andrew Pinski --- Oh I see the issue now, I am changing arg0 even if we don't do the thing ...
[Bug tree-optimization/111864] [12/13/14 Regression] Dead Code Elimination Regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111864 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-10-18 Keywords||needs-bisection Status|UNCONFIRMED |NEW Target Milestone|14.0|12.4 Summary|[14 Regression] Dead Code |[12/13/14 Regression] Dead |Elimination Regression |Code Elimination Regression |since r14-4038-gb975c0dc3be | --- Comment #1 from Andrew Pinski --- Confirmed but this is just happened to be a side effect. In forwprop1 we can change: ``` # iftmp.5_11 = PHI <1(3), 0(4)> _4 = iftmp.5_11 <= 0; _5 = (short int) _4; _25 = (int) _4; _26 = _25 << 5; _29 = (short int) _4; _27 = _29 << 5; _6 = (int) _27; if (_27 != 0) ``` Into just: ``` # iftmp.5_11 = PHI <1(3), 0(4)> if (iftmp.5_11 <= 0) ``` And then ethread is able to thread through that bb. You get the same missed optimization with removing the call to a. that is changing: ``` short v = a((g && p(t)) <= 0, 5); ``` to ``` short v = ((g && p(t)) <= 0); ``` Which then becomes a regression between GCC 11 and GCC 12.
[Bug ada/81114] GNAT mishandles filenames with UTF8 chars on case-insensitive filesystems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81114 Eric Botcazou changed: What|Removed |Added Last reconfirmed|2017-07-04 00:00:00 |2023-10-18 Status|UNCONFIRMED |SUSPENDED Ever confirmed|0 |1
[Bug ada/81114] GNAT mishandles filenames with UTF8 chars on case-insensitive filesystems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81114 --- Comment #9 from simon at pushface dot org --- Created attachment 56140 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56140=edit C demonstrator As noted in comment 8, the C compiler doesn’t have a problem with finding a file with a combining filename when the #include directice uses a composed filename.
[Bug tree-optimization/111866] [14 regression] ICE when compiling gcc.target/powerpc/p9-vec-length-full-7.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111866 Tamar Christina changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot gnu.org Priority|P3 |P1 Target Milestone|--- |14.0 Component|middle-end |tree-optimization
[Bug middle-end/111866] [14 regression] ICE when compiling gcc.target/powerpc/p9-vec-length-full-7.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111866 --- Comment #1 from Tamar Christina --- Thanks for reporting! I'll debug. I suspect another case where the vectorized and scalar loop were sneakily swapped.
[Bug ada/81114] GNAT mishandles filenames with UTF8 chars on case-insensitive filesystems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81114 --- Comment #8 from simon at pushface dot org --- I think I’d forgotten that compiling páck3.ads on its own, rather than as part of the closure, was the way to demonstrate this problem. It was NOT fixed in darwin19 (it’s still present in darwin23). For interest, I made a C file which #includes a header with an a-acute in its name; the C file uses the composed a-acute, but the header’s file name (as shown by ls) uses the combining a-acute. Compiles without complaint. Attachment c-demo.zip. On third thoughts, this should probably go back to SUSPENDED. When I looked into it, it seemed to involve quite deep parts of the compiler, which probably means that the Ada maintainers would be resistant (especially since AdaCore don’t support macOS).
[Bug middle-end/111863] [14 Regression] Wrong code with "-O3 -fno-tree-ccp -fno-tree-dominator-opts -fno-tree-vrp" since r14-1600
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111863 --- Comment #7 from Andrew Pinski --- (In reply to Andrew Pinski from comment #6) > Oh I see the issue: > ``` > _8 = _7 & 2; > _10 = _8 != 1; > > ``` > > There needs to be a check that 1 here is the same as 2 or 0 ... Wait I have that check: if (wi::popcount (nz) == 1 && (integer_zerop (arg1) || wi::to_wide (arg1) == nz)) Why is that not working ...
[Bug fortran/110644] Error in gfc_format_decoder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644 Alberto Luaces changed: What|Removed |Added CC||aluaces at udc dot es --- Comment #4 from Alberto Luaces --- I got the same error in almost the same circumstances (crash in error.cc:1078). I have a large codebase and I could not prepare a minimal testcase, but I have built gfortran 13 from source with the aim to debug the crash. Hoewever, even I set "set follow-fork-mode children", f951 crashes and I cannot navigate through the backtrace nor see the arguments of the functions. Is there any reference for debugging gcc in order to send some useful information to this bug?
[Bug middle-end/111863] [14 Regression] Wrong code with "-O3 -fno-tree-ccp -fno-tree-dominator-opts -fno-tree-vrp" since r14-1600
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111863 --- Comment #6 from Andrew Pinski --- Oh I see the issue: ``` _8 = _7 & 2; _10 = _8 != 1; ``` There needs to be a check that 1 here is the same as 2 or 0 ...
[Bug middle-end/111866] New: [14 regression] ICE when compiling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111866 Bug ID: 111866 Summary: [14 regression] ICE when compiling Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:d65e38e616e7ac8157ef04b55beb6670f2c0f142, r14-4708-gd65e38e616e7ac FAIL: gcc.target/powerpc/p9-vec-length-full-7.c (internal compiler error: in vect_set_loop_condition_partial_vectors, at tree-vect-loop-manip.cc:911) FAIL: gcc.target/powerpc/p9-vec-length-full-7.c (test for excess errors) FAIL: gcc.target/powerpc/p9-vec-length-full-run-7.c (internal compiler error: in vect_set_loop_condition_partial_vectors, at tree-vect-loop-manip.cc:911) FAIL: gcc.target/powerpc/p9-vec-length-full-run-7.c (test for excess errors) spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test/gcc/ /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-7.c -fdiagnostics-plain-output -mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model -fno-unroll-loops -ffast-math -fdisable-tree-cunroll --param=vect-partial-vector-usage=2 -ffat-lto-objects -fno-ident -S -o p9-vec-length-full-7.s cc1: note: disable pass tree-cunroll for functions in the range of [0, 4294967295] during GIMPLE pass: vect In file included from /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-7.c:11: /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/p9-vec-length-7.h: In function 'test_npeel_int8_t': /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/p9-vec-length-7.h:12:43: internal compiler error: in vect_set_loop_condition_partial_vectors, at tree-vect-loop-manip.cc:911 /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/p9-vec-length.h:4:3: note: in expansion of macro 'test' /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/p9-vec-length-7.h:20:1: note: in expansion of macro 'TEST_ALL' 0x110c9c9b vect_set_loop_condition_partial_vectors /home/seurer/gcc/git/gcc-test/gcc/tree-vect-loop-manip.cc:911 0x110c9c9b vect_set_loop_condition(loop*, edge_def*, _loop_vec_info*, tree_node*, tree_node*, tree_node*, bool) /home/seurer/gcc/git/gcc-test/gcc/tree-vect-loop-manip.cc:1366 0x110cc37b vect_do_peeling(_loop_vec_info*, tree_node*, tree_node*, tree_node**, tree_node**, tree_node**, int, bool, bool, tree_node**) /home/seurer/gcc/git/gcc-test/gcc/tree-vect-loop-manip.cc:3250 0x110ba213 vect_transform_loop(_loop_vec_info*, gimple*) /home/seurer/gcc/git/gcc-test/gcc/tree-vect-loop.cc:11416 0x1110fa43 vect_transform_loops /home/seurer/gcc/git/gcc-test/gcc/tree-vectorizer.cc:1006 0x042f try_vectorize_loop_1 /home/seurer/gcc/git/gcc-test/gcc/tree-vectorizer.cc:1152 0x042f try_vectorize_loop /home/seurer/gcc/git/gcc-test/gcc/tree-vectorizer.cc:1182 0x08d3 execute /home/seurer/gcc/git/gcc-test/gcc/tree-vectorizer.cc:1298 commit d65e38e616e7ac8157ef04b55beb6670f2c0f142 (HEAD) Author: Tamar Christina Date: Wed Oct 18 09:02:12 2023 +0100 middle-end: Refactor vectorizer loop conditionals and separate out IV to new variables
[Bug middle-end/111863] [14 Regression] Wrong code with "-O3 -fno-tree-ccp -fno-tree-dominator-opts -fno-tree-vrp" since r14-1600
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111863 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #5 from Andrew Pinski --- Let me see where I made the mistake. ``` ;; _11 = (int) _10; (insn 10 9 11 (set (reg:CCZ 17 flags) (compare:CCZ (reg:SI 102 [ _7 ]) (const_int 1 [0x1]))) "/app/example.cpp":10:24 -1 (nil)) (insn 11 10 12 (set (reg:QI 109) (ne:QI (reg:CCZ 17 flags) (const_int 0 [0]))) "/app/example.cpp":10:24 -1 (nil)) ``` is definitely wrong. It was in GCC 13: ``` (insn 10 9 11 (parallel [ (set (reg:SI 92) (and:SI (reg:SI 86 [ _7 ]) (const_int 2 [0x2]))) (clobber (reg:CC 17 flags)) ]) "/app/example.cpp":10:24 -1 (nil)) (insn 11 10 12 (set (reg:CCZ 17 flags) (compare:CCZ (reg:SI 92) (const_int 1 [0x1]))) "/app/example.cpp":10:24 -1 (nil)) (insn 12 11 13 (set (reg:QI 94) (ne:QI (reg:CCZ 17 flags) (const_int 0 [0]))) "/app/example.cpp":10:24 -1 (nil)) ```
[Bug c/111808] [C23] constexpr with excess precision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111808 --- Comment #9 from joseph at codesourcery dot com --- A portability issue producing a compile failure is often better than one where there is no error but the code misbehaves at runtime on some platforms (a lot of code does not have good testsuites).
[Bug bootstrap/111852] [14 regression] r14-4339-geaa41a6dc127d8 breaks building with gcc 4.8.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111852 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #4 from Jakub Jelinek --- Should be worked around now.
[Bug tree-optimization/111864] [14 Regression] Dead Code Elimination Regression since r14-4038-gb975c0dc3be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111864 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Target Milestone|--- |14.0
[Bug bootstrap/111852] [14 regression] r14-4339-geaa41a6dc127d8 breaks building with gcc 4.8.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111852 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:bc4bd69faf986326f6b0fd0400cdd6871577afd1 commit r14-4722-gbc4bd69faf986326f6b0fd0400cdd6871577afd1 Author: Jakub Jelinek Date: Wed Oct 18 17:01:26 2023 +0200 cse: Workaround GCC < 5 bug in cse_insn [PR111852] Before the r5-3834 commit for PR63362, GCC 4.8-4.9 refuses to compile cse.cc which contains a variable with rtx_def type, because rtx_def contains a union with poly_uint16 element. poly_int template has defaulted default constructor and a variadic template constructor which could have empty parameter pack. GCC < 5 treated it as non-trivially constructible class and deleted rtunion and rtx_def default constructors. For the cse_insn purposes, all we need is a variable with size and alignment of rtx_def, not necessarily rtx_def itself, which we then memset to 0 and fill in like rtx is normally allocated from heap, so this patch for GCC_VERSION < 5000 uses an unsigned char array of the right size/alignment. 2023-10-18 Jakub Jelinek PR bootstrap/111852 * cse.cc (cse_insn): Add workaround for GCC 4.8-4.9, instead of using rtx_def type for memory_extend_buf, use unsigned char arrayy with size of rtx_def and its alignment.
[Bug middle-end/111849] GCC replaces volatile struct assignments with memcpy calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111849 --- Comment #2 from Rich Felker --- I agree that volatile isn't the best way to handle memcpy suppression for other purposes - it was just one of the methods I experimented with that led to me discovering this issue, which I found surprising and reported. With regards to impact of this bug, in discussion within the musl libc community where it was found, I did encounter one potentially affected user who is using volatile struct stores to write entire bitfields at once on mmio registers instead of (possibly invalid, at least inefficient) read-modify-write cycles on each bitfield member. I believe their use was unaffected, probably because the whole struct is small enouth that it gets emitted as direct load/store rather than a memcpy call.
[Bug c/111865] New: GCC: 14: internal compiler error: symtab_node::verify failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111865
Bug ID: 111865
Summary: GCC: 14: internal compiler error: symtab_node::verify
failed
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: 141242068 at smail dot nju.edu.cn
Target Milestone: ---
When compile this program, gcc crashes:
```
register unsigned long x asm("rsp");
struct {
int a;
} * p asm("rsp");
```
Compiler Explorer: https://godbolt.org/z/xYq8KP8M3
The stack dump:
```
:5:1: error: assembler name hash list corrupted
5 | } * p asm("rsp");
| ^
*rsp/0 (x)
Type: variable definition analyzed
Visibility: force_output semantic_interposition no_reorder public
References:
Referring:
Availability: not-ready
Varpool flags:
:5:1: internal compiler error: symtab_node::verify failed
0x231210e internal_error(char const*, ...)
???:0
0xbd03a9 symtab_node::verify()
???:0
0xbd168f symtab_node::verify_symtab_nodes()
???:0
0xbebdab symbol_table::finalize_compilation_unit()
???: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 target/111753] [14 Regression] ICE: in extract_constrain_insn, at recog.cc:2692 insn does not satisfy its constraints: {*movsf_internal} with -O2 -mavx512bw -fno-tree-ter starting with r14-4499
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111753
Jakub Jelinek changed:
What|Removed |Added
Summary|[14 Regression] ICE: in |[14 Regression] ICE: in
|extract_constrain_insn, at |extract_constrain_insn, at
|recog.cc:2692 insn does not |recog.cc:2692 insn does not
|satisfy its constraints:|satisfy its constraints:
|{*movsf_internal} with -O2 |{*movsf_internal} with -O2
|-mavx512bw -fno-tree-ter|-mavx512bw -fno-tree-ter
||starting with r14-4499
CC||haochen.jiang at intel dot com,
||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
Started with r14-4499-gc1eef66baa8dde706d7ea6921648e6016dc7c93d
[Bug tree-optimization/111864] New: [14 Regression] Dead Code Elimination Regression since r14-4038-gb975c0dc3be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111864
Bug ID: 111864
Summary: [14 Regression] Dead Code Elimination Regression since
r14-4038-gb975c0dc3be
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: theodort at inf dot ethz.ch
Target Milestone: ---
https://godbolt.org/z/PoYvWMG7T
Given the following code:
void foo(void);
static int d, g = 4, k;
static int *h, *j, *s;
static int **i = , **t =
static int ***l =
static unsigned short *m, *n;
static unsigned short **o = , **u =
void __assert_fail() __attribute__((__noreturn__));
static short(a)(short b, int c) { return b << c; }
static int(e)(int f) {
if (!(((f) >= 0) && ((f) <= 0))) {
__builtin_unreachable();
}
return d;
}
static int ***p(int **q) {
j = *q;
return
}
static int *r() {
short v = a((g && p(t)) <= 0, 5);
e(v);
if (s) o = u;
if (o == || o == )
;
else
__assert_fail();
return
}
int main() {
**l = r();
if (h)
;
else
__assert_fail();
if (j == == 0)
;
else
__assert_fail();
if (o == || o == )
;
else
foo();
;
}
gcc-trunk -O2 does not eliminate the call to foo:
main:
subq$8, %rsp
movqs(%rip), %rax
movqi(%rip), %rdx
movq%rax, j(%rip)
testq %rax, %rax
je .L17
movq$k, (%rdx)
cmpq$0, h(%rip)
movq$m, o(%rip)
je .L5
cmpq$g, %rax
je .L5
movl$m, %eax
.L10:
cmpq$n, %rax
je .L12
cmpq$m, %rax
je .L12
callfoo
.L12:
xorl%eax, %eax
addq$8, %rsp
ret
.L17:
movqo(%rip), %rax
cmpq$m, %rax
je .L18
cmpq$n, %rax
jne .L5
movq$k, (%rdx)
cmpq$0, h(%rip)
jne .L10
.L5:
xorl%eax, %eax
call__assert_fail
.L18:
movq$k, (%rdx)
cmpq$0, h(%rip)
jne .L12
jmp .L5
gcc-13.2.0 -O2 eliminates the call to foo:
main:
movqs(%rip), %rax
movqi(%rip), %rdx
movq%rax, j(%rip)
testq %rax, %rax
je .L2
movq$k, (%rdx)
cmpq$0, h(%rip)
movq$m, o(%rip)
je .L4
cmpq$g, %rax
je .L4
.L8:
xorl%eax, %eax
ret
.L2:
movqo(%rip), %rax
cmpq$m, %rax
je .L5
cmpq$n, %rax
jne .L4
.L5:
movq$k, (%rdx)
cmpq$0, h(%rip)
jne .L8
.L4:
pushq %rax
xorl%eax, %eax
call__assert_fail
Bisects to r14-4038-gb975c0dc3be
[Bug ipa/111773] Inconsistent optimization of replaced operator new()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111773 --- Comment #6 from Vlad Yaglamunov --- I agree with Richard's explanation. Seems like my first example is an undefined behavior. In section [basic.stc.dynamic.allocation] par 2, in C++17, was added the following: "Furthermore, for the library allocation functions in [new.delete.single] and [new.delete.array], p0 shall represent the address of a block of storage disjoint from the storage for any other object accessible to the caller."
[Bug c/111863] [14 Regression] Wrong code with "-O3 -fno-tree-ccp -fno-tree-dominator-opts -fno-tree-vrp" since r14-1600
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111863 Jakub Jelinek changed: What|Removed |Added Summary|[14 Regression] Wrong code |[14 Regression] Wrong code |with "-O3 -fno-tree-ccp |with "-O3 -fno-tree-ccp |-fno-tree-dominator-opts|-fno-tree-dominator-opts |-fno-tree-vrp" |-fno-tree-vrp" since ||r14-1600 CC||jakub at gcc dot gnu.org, ||pinskia at gcc dot gnu.org Keywords|needs-bisection | --- Comment #4 from Jakub Jelinek --- Started with r14-1600-ge60593f3881c72a96a3fa4844d73e8a2cd14f670
[Bug testsuite/111850] [14 regression] gcc.target/powerpc/fold-vec-extract-char.p7.c fails after r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111850 --- Comment #2 from seurer at gcc dot gnu.org --- Yes, it does look like an improvement ad I doubt the number of addis really matters. That's why I said the test probably just needs to be updated.
[Bug bootstrap/111601] [14 Regression] bootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601 Matthias Klose changed: What|Removed |Added Target|powerpc64le-linux |powerpc64le-linux |x86_64-linux| --- Comment #2 from Matthias Klose --- this seems to be fixed on x86_64-linux-gnu with trunk 20231017. powerpc64le-linux now fails in a different way, trying to build the libstdc++ pch headers. Full build log at https://buildd.debian.org/status/fetch.php?pkg=gcc-snapshot=ppc64el=1%3A20231017-1=1697561774=1 Configured with: -v --with-pkgversion='Debian 20231017-1' --with-bugurl='file:///usr/share/doc/gcc-snapshot/README.Bugs' --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr/lib/gcc-snapshot --with-gcc-major-version-only --program-prefix= --enable-shared --enable-linker-build-id --disable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --enable-plugin --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --with-libphobos-druntime-only=yes --enable-objc-gc=auto --enable-secureplt --enable-targets=powerpcle-linux --disable-multilib --enable-multiarch --disable-werror --with-long-double-128 --enable-offload-targets=nvptx-none=/<>/debian/tmp-nvptx/usr/lib/gcc-snapshot --enable-offload-defaulted --without-cuda-driver --enable-checking=yes,extra,rtl --build=powerpc64le-linux-gnu --host=powerpc64le-linux-gnu --target=powerpc64le-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-serialization=4 Build target is profiledbootstrap-lean
