[Bug c++/104708] New: RV64: gcc does not pass all library directories to linker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104708 Bug ID: 104708 Summary: RV64: gcc does not pass all library directories to linker Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: rui314 at gmail dot com Target Milestone: --- I'm the author of the mold linker (https://github.com/rui314/mold). As far as I know, gcc always passes all library paths to the linker by -L, but I got a bug report that that's not the case on RV64. It is reported that gcc does not pass some obvious paths such as `-L/usr` or `-L/usr/lib`. Can gcc pass all library paths to the linker on RV64?
[Bug target/104707] gcc on riscv64 isn't passing entire library path to the linker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104707 Andrew Pinski changed: What|Removed |Added Target||riscv64-unknown-linux-gnu --- Comment #1 from Andrew Pinski --- I think this is a multilib issue with riscv and there might be another bug already for this.
[Bug target/104707] New: gcc on riscv64 isn't passing entire library path to the linker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104707
Bug ID: 104707
Summary: gcc on riscv64 isn't passing entire library path to
the linker
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sterprim at outlook dot com
Target Milestone: ---
I tried to build mold linker (v1.1) for Arch Linux RISC-V, but gcc (11.2.0,
riscv64) filters out essential library paths (/lib and /usr/lib) and mold does
not have the notion of "default search paths" by design. Therefore, mold would
complain something like "mold: library not found: gcc_s" if extra
"-Wl,-L/lib,-L/usr/lib" is not added. Similarly lld fails to work with gcc,
complaining "library not found". But I found that bfd works well with gcc.
Output from gcc when compiling c source files:
$ echo 'int main() { return 0; }' > b.c
$ mold -run gcc -o exe b.c --verbose
..
GNU C17 (GCC) version 11.2.0 (riscv64-unknown-linux-gnu)
compiled by GNU C version 11.2.0, GMP version 6.2.1, MPFR version
4.1.0-p13, MPC version 1.2.1, isl version isl-0.24-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 30030405e2f045a69ffd93f3ffd2fa18
COLLECT_GCC_OPTIONS='-o' 'exe' '-v' '-march=rv64imafdc' '-mabi=lp64d'
'-march=rv64imafdc' '-dumpdir' 'exe-'
as -v --traditional-format -fpic -march=rv64imafdc -march=rv64imafdc
-mabi=lp64d -o /tmp/ccB31rEk.o /tmp/ccTd7vTJ.s
GNU assembler version 2.38 (riscv64-unknown-linux-gnu) using BFD version (GNU
Binutils) 2.38
COMPILER_PATH=/usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/:/usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/:/usr/lib/gcc/riscv64-unknown-linux-gnu/:/usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/:/usr/lib/gcc/riscv64-unknown-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-o' 'exe' '-v' '-march=rv64imafdc' '-mabi=lp64d'
'-march=rv64imafdc' '-dumpdir' 'exe.'
/usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/collect2 -plugin
/usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/liblto_plugin.so
-plugin-opt=/usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccD5XkR9.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id
--eh-frame-hdr --hash-style=gnu -melf64lriscv -dynamic-linker
/lib/ld-linux-riscv64-lp64d.so.1 -pie -o exe /lib/Scrt1.o
/usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/crti.o
/usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/crtbeginS.o
-L/usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0 /tmp/ccB31rEk.o -lgcc
--push-state --as-needed -lgcc_s --pop-state -lc -lgcc --push-state --as-needed
-lgcc_s --pop-state /usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/crtendS.o
/usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/crtn.o
mold: library not found: gcc_s
Another test, but with -L/lib and -L/usr/lib added:
$ mold -run gcc -o exe b.c --verbose -Wl,-L/lib,-L/usr/lib
..
GNU C17 (GCC) version 11.2.0 (riscv64-unknown-linux-gnu)
compiled by GNU C version 11.2.0, GMP version 6.2.1, MPFR version
4.1.0-p13, MPC version 1.2.1, isl version isl-0.24-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 30030405e2f045a69ffd93f3ffd2fa18
COLLECT_GCC_OPTIONS='-o' 'exe' '-v' '-march=rv64imafdc' '-mabi=lp64d'
'-march=rv64imafdc' '-dumpdir' 'exe-'
as -v --traditional-format -fpic -march=rv64imafdc -march=rv64imafdc
-mabi=lp64d -o /tmp/ccwQuF3N.o /tmp/cc4kmqtA.s
GNU assembler version 2.38 (riscv64-unknown-linux-gnu) using BFD version (GNU
Binutils) 2.38
COMPILER_PATH=/usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/:/usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/:/usr/lib/gcc/riscv64-unknown-linux-gnu/:/usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/:/usr/lib/gcc/riscv64-unknown-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-o' 'exe' '-v' '-march=rv64imafdc' '-mabi=lp64d'
'-march=rv64imafdc' '-dumpdir' 'exe.'
/usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/collect2 -plugin
/usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/liblto_plugin.so
-plugin-opt=/usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccyg2R0b.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id
--eh-frame-hdr --hash-style=gnu -melf64lriscv -dynamic-linker
/lib/ld-linux-riscv64-lp64d.so.1 -pie -o exe /lib/Scrt1.o
/usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/crti.o
/usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/crtbeginS.o
-L/usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0 /tmp/ccwQuF3N.o -L/lib
-L/usr/lib -lgcc --push-state --
[Bug target/104704] [12 Regression] ix86_gen_scratch_sse_rtx doesn't work with explicit XMM7/XMM15/XMM31 usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104704 H.J. Lu changed: What|Removed |Added Last reconfirmed||2022-02-27 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from H.J. Lu --- ix86_expand_vector_move shouldn't use ix86_gen_scratch_sse_rtx.
[Bug c++/39751] [9/10/11/12 Regression] ICE in cp_lexer_new_from_tokens, at cp/parser.c:342
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39751 Roger Sayle changed: What|Removed |Added CC||roger at nextmovesoftware dot com Assignee|unassigned at gcc dot gnu.org |roger at nextmovesoftware dot com Status|NEW |ASSIGNED --- Comment #14 from Roger Sayle --- Patch proposed. https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590951.html
[Bug c++/104706] New: make_unique cannot create struct of size of 0 due to default_delete's static_assert failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104706
Bug ID: 104706
Summary: make_unique cannot create struct of size of 0 due to
default_delete's static_assert failure
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nickhuang99 at hotmail dot com
Target Milestone: ---
See code in compiler explorer: https://www.godbolt.org/z/cb8973Ys1
struct of size of 0 does have its usage and it is supported by GNU C
(https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html). However, make_unique
makes it impossible to create such an unique_ptr because its default_delete
requires "A" must have non-zero size.
struct A{
alignas(int[0]) int ptr[0];
};
void test(){
unique_ptr ptr=make_unique();
}
error: static assertion failed: can't delete pointer to incomplete type
83 | static_assert(sizeof(_Tp)>0,
| ~~~^~
I am not arguing that static_assert is reasonable. My point is that
"make_shared" can actually deal this properly. i.e.
shared_ptr ptr=make_shared();
gives no error at all.
[Bug middle-end/95126] [9/10/11/12 Regression] Missed opportunity to turn static variables into immediates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95126 Roger Sayle changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |roger at nextmovesoftware dot com CC||roger at nextmovesoftware dot com Status|NEW |ASSIGNED --- Comment #6 from Roger Sayle --- Patch proposed. https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590949.html
[Bug c++/104699] zero-length-array is not considered as an array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104699
qingzhe huang changed:
What|Removed |Added
CC||nickhuang99 at hotmail dot com
--- Comment #2 from qingzhe huang ---
(In reply to Jonathan Wakely from comment #1)
> It says GNU C, not C++. But in any case, that example works fine for me, as
> does the simpler:
>
> template struct S { };
> S s;
>
> Please provide the info you were asked to provide by https://gcc.gnu.org/bugs
https://www.godbolt.org/z/8xa1dTzdM
#include
static_assert( ! std::is_array::value);
And as a directly result, it causes "make_shared" fails with "int[0]"
https://www.godbolt.org/z/8nE6qojaE
shared_ptr ptr=make_shared();
...
error: request for member '~int [0]' in '* __location', which is of non-class
type 'int [0]'
88 | __location->~_Tp();
| ~^~~
This is the direct result of template specialization "is_array" is
ill-format code or something.
[Bug middle-end/104705] [12 regression] ICE ‘global_options’ are modified in local context in cl_optimization_compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104705 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2022-02-26 Keywords||needs-bisection Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Interesting it does not ICE with -g.
[Bug middle-end/104705] [12 regression] ICE ‘global_options’ are modified in local context in cl_optimization_compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104705 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code Component|c |middle-end Target Milestone|--- |12.0
[Bug c/104705] New: [12 regression] ICE ‘global_options’ are modified in local context in cl_optimization_compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104705 Bug ID: 104705 Summary: [12 regression] ICE ‘global_options’ are modified in local context in cl_optimization_compare Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: slyfox at gcc dot gnu.org CC: mliska at suse dot cz Target Milestone: --- Tried to build ghc-HEAD with gcc-master today, got an ICE on pragmas in intrisics. Here is a small reproducer (I think I lost real "optimize" value during shrinking, does it matter much for this ICE?): //$ cat a.c #pragma GCC optimize "foo" #pragma GCC push_options #pragma GCC pop_options $ /tmp/bg/gcc/xgcc -B/tmp/bg/gcc -c a.c -O2 -Wall a.c:1:9: warning: bad option ‘-ffoo’ to pragma ‘optimize’ [-Wpragmas] 1 | #pragma GCC optimize "foo" | ^~~ a.c:3:9: internal compiler error: ‘global_options’ are modified in local context 3 | #pragma GCC pop_options | ^~~ 0xccf111 cl_optimization_compare(gcc_options*, gcc_options*) /tmp/bg/gcc/options-save.cc:15919 0x7ca26f handle_pragma_pop_options /home/slyfox/dev/git/gcc/gcc/c-family/c-pragma.cc:1141 0x7cd42e c_invoke_pragma_handler(unsigned int) /home/slyfox/dev/git/gcc/gcc/c-family/c-pragma.cc:1569 0x72a4ca c_parser_pragma /home/slyfox/dev/git/gcc/gcc/c/c-parser.cc:12621 0x7555e7 c_parser_external_declaration /home/slyfox/dev/git/gcc/gcc/c/c-parser.cc:1760 0x75596a c_parser_translation_unit /home/slyfox/dev/git/gcc/gcc/c/c-parser.cc:1652 0x75596a c_parse_file() /home/slyfox/dev/git/gcc/gcc/c/c-parser.cc:23357 0x7c7e81 c_common_parse_file() /home/slyfox/dev/git/gcc/gcc/c-family/c-opts.cc:1238 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ /tmp/bg/gcc/xgcc -B/tmp/bg/gcc -v Reading specs from /tmp/bg/gcc/specs COLLECT_GCC=/tmp/bg/gcc/xgcc COLLECT_LTO_WRAPPER=/tmp/bg/gcc/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /home/slyfox/dev/git/gcc/configure --disable-multilib --disable-bootstrap --with-native-system-header-dir=/<>/glibc-2.33-108-dev/include --prefix=/tmp/bg/__td__ CFLAGS='-O1 -ggdb3' CXXFLAGS='-O1 -ggdb3' LDFLAGS='-O1 -ggdb3' Thread model: posix Supported LTO compression algorithms: zlib gcc version 12.0.1 20220226 (experimental) (GCC)
[Bug target/104610] memcmp () == 0 can be optimized better for avx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104610 H.J. Lu changed: What|Removed |Added Depends on||104704 --- Comment #12 from H.J. Lu --- (In reply to Hongtao.liu from comment #8) > Created attachment 52495 [details] > untested patch. > > With the patch, it exposes one potential issue related to dse(or > ix86_gen_scratch_sse_rtx usage). in dse1, it try to replace load insn with > equivalent value, but the inserted new insns(insn 45, insn 44, insn 46) will > set xmm31, but dse is not aware of that, and xmm31 is alive and will be used > by insn 10 which is exactly after new added insns, and it breaks data flow. > I opened PR 104704. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104704 [Bug 104704] [12 Regression] ix86_gen_scratch_sse_rtx doesn't work with explicit XMM7/XMM15/XMM31 usage
[Bug c++/104702] [12 Regression] False positive -Wunused-value warning with -fno-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104702 Jonathan Wakely changed: What|Removed |Added CC||jason at gcc dot gnu.org Last reconfirmed||2022-02-26 Known to fail||12.0 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Known to work||11.2.1 --- Comment #1 from Jonathan Wakely --- Started with r12-6328: c++: temporary lifetime with array aggr init [PR94041]
[Bug target/104704] New: [12 Regression] ix86_gen_scratch_sse_rtx doesn't work explicit XMM7/XMM15/XMM31 usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104704
Bug ID: 104704
Summary: [12 Regression] ix86_gen_scratch_sse_rtx doesn't work
explicit XMM7/XMM15/XMM31 usage
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: crazylht at gmail dot com, ubizjak at gmail dot com
Target Milestone: ---
ix86_gen_scratch_sse_rtx returns XMM7/XMM15/XMM31 as a scratch register to
prevent RTL optimizer from removing scratch vector register. But it introduces
a conflict with explicit XMM7/XMM15/XMM31 usage:
[hjl@gnu-tgl-2 scratch-2]$ cat x-2.c
/* { dg-do compile { target { ! ia32 } } } */
/* { dg-options "-O2 -march=x86-64 -mavx2" } */
#include
__m256d y, z;
int i;
__attribute__((noipa))
int
do_test (void)
{
register int xmm15 __asm ("xmm15") = i;
asm volatile ("" : "+v" (xmm15));
z = y;
register int xmm2 __asm ("xmm2") = xmm15;
asm volatile ("" : "+v" (xmm2));
return xmm2;
}
__attribute__((target("arch=x86-64")))
int
main (void)
{
if (__builtin_cpu_supports ("avx2"))
{
i = 4;
if (do_test () != 4)
__builtin_abort ();
}
return 0;
}
[hjl@gnu-tgl-2 scratch-2]$ make x-2
/export/build/gnu/tools-build/gcc-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-debug/build-x86_64-linux/gcc/ -O2
-march=x86-64 -mavx2 -S x-2.c
/export/build/gnu/tools-build/gcc-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-debug/build-x86_64-linux/gcc/ -O2
-march=x86-64 -o x-2 x-2.s
[hjl@gnu-tgl-2 scratch-2]$ ./x-2
Aborted (core dumped)
[hjl@gnu-tgl-2 scratch-2]$
[Bug c++/104699] zero-length-array is not considered as an array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104699
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed||2022-02-26
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
It says GNU C, not C++. But in any case, that example works fine for me, as
does the simpler:
template struct S { };
S s;
Please provide the info you were asked to provide by https://gcc.gnu.org/bugs
[Bug tree-optimization/104700] [12 Regression] ICE on valid code at -O2 and -O3 with -fno-tree-ccp -fno-tree-dce -fno-tree-vrp on x86_64-linux-gnu: in find_or_generate_expression, at tree-ssa-pre.cc:2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104700
--- Comment #3 from Zhendong Su ---
Another test without using "-fno-tree-ccp -fno-tree-dce -fno-tree-vrp":
[700] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.1 20220226 (experimental) [master r12-7395-gafeaaf4b352] (GCC)
[701] %
[701] % gcctk -O2 small.c
during GIMPLE pass: pre
small.c: In function ‘o’:
small.c:3:6: internal compiler error: in find_or_generate_expression, at
tree-ssa-pre.cc:2795
3 | void o() {
| ^
0x1005c10 find_or_generate_expression
../../gcc-trunk/gcc/tree-ssa-pre.cc:2795
0x1005132 create_expression_by_pieces
../../gcc-trunk/gcc/tree-ssa-pre.cc:2951
0x10095b1 insert_into_preds_of_block
../../gcc-trunk/gcc/tree-ssa-pre.cc:3159
0x100b134 do_pre_regular_insertion
../../gcc-trunk/gcc/tree-ssa-pre.cc:3416
0x100b134 insert
../../gcc-trunk/gcc/tree-ssa-pre.cc:3809
0x100b134 execute
../../gcc-trunk/gcc/tree-ssa-pre.cc:4433
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[702] %
[702] % cat small.c
int printf(const char *, ...);
int a, b, c = 2, d, e, *f, g;
void o() {
unsigned h = 1;
int j = -1, k, l = 1, m = 2, i;
while (c < 2)
;
L1:
k = h;
h = -1;
if (k < 2 && !c) {
printf("%d", k);
goto L1;
}
if (!j)
l = printf("0");
if (g)
k = 0;
if (a && k)
goto L2;
while (f) {
m = a;
d = i;
i = e;
f = &j;
L2:
if (d == l && !m)
l = b;
}
unsigned *n[1] = {&h};
}
int main() {
o();
return 0;
}
--
>From Compiler Explorer: https://godbolt.org/z/b9z9e71oh
[Bug c++/104702] [12 Regression] False positive -Wunused-value warning with -fno-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104702 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic Target Milestone|--- |12.0
[Bug ada/104703] New: GNAT 11.2 exception traceback output is mostly garbled on Intel x64 (MSYS2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104703 Bug ID: 104703 Summary: GNAT 11.2 exception traceback output is mostly garbled on Intel x64 (MSYS2) Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: cthowie at netzero dot net Target Milestone: --- PLATFORM: GCC 11.2 Revision 8 toolchain for MSYS2 on Windows 10 Intel x64 CPU. Note GNAT FSF 8.2 Revision 1 compiler does NOT have the problem as shown below. ISSUE: I upgraded from GNAT FSF 8.2 to GNAT FSF 11.2 and noticed the "traceback" output is now garbled as demonstrated below with a trivial Ada program: EXAMPLE PROGRAM DEMONSTRATING THE ISSUE: procedure Main is procedure Inner with No_Inline is begin raise Program_Error; end Inner; begin Inner; end Main; BUILD INSTRUCTIONS: Save the above example program to e.g., "main.adb" then run: gnatmake -g main.adb -bargs -Es so we get symbolic traceback for the raised exception. Then run the 'main.exe' from the command line. I get this broken trace (only the bottom 4 lines for KERNEL32.DLL and ntdll.dll are correct): $ ./main raised PROGRAM_ERROR : main.adb:8 explicit raise [C:\temp\GNAT bug\main.exe] 0x7ff6ecbe1a1e ??? at ??? [C:\temp\GNAT bug\main.exe] 0x7ff6ecbe1a41 ??? at ??? [C:\temp\GNAT bug\main.exe] 0x7ff6ecbe1992 ??? at ??? [C:\temp\GNAT bug\main.exe] 0x7ff6ecbe13af ??? at ??? [C:\temp\GNAT bug\main.exe] 0x7ff6ecbe14e4 ??? at ??? [C:\windows\System32\KERNEL32.DLL] 0x7ffb5c5f81f2 [C:\windows\SYSTEM32\ntdll.dll] 0x7ffb5f05a24f The trace is broken even: 1) if I bind with the "-Ea" binder flag 2) if I use the GNAT system package and Text_IO e.g., with GNAT.Traceback.Symbolic; use GNAT.Traceback.Symbolic; and add this to the bottom of the main subprogram: exception when e : others => Put_Line (Symbolic_Traceback (e)); Note that the traceback is correct if I compile exactly as above but with GNAT FSF 8.2 Revision 1 compiler for MSYS2: raised PROGRAM_ERROR : main.adb:8 explicit raise [C:\temp\GNAT bug\main.exe] Main.Inner at main.adb:8 Main at main.adb:12 Main at b~main.adb:188 __tmainCRTStartup at crtexe.c:333 mainCRTStartup at crtexe.c:217 [C:\windows\System32\KERNEL32.DLL] 0x7ffb5c5f81f2 [C:\windows\SYSTEM32\ntdll.dll] 0x7ffb5f05a24f
[Bug c++/103328] [11/12 Regression] ICE in remap_gimple_stmt, at tree-inline.c:1921 since r11-7419-g0f161cc8494cf728
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103328
Piotr Grabowski changed:
What|Removed |Added
CC||piotr.grabowski at scylladb
dot co
||m
--- Comment #18 from Piotr Grabowski ---
Created attachment 52520
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52520&action=edit
smaller reproducer (-g flag required)
Uploading a smaller 30-line reproducer, reduced independently from Avi, but
started from the same origin file. The error messages are the same as previous
reproducers. It fails to compile with all optimization levels I checked.
Compiled with (-g required):
g++ -g -std=c++20 attached.cpp
For g++ (GCC) 11.2.1 20220127 (Red Hat 11.2.1-9) and "-g -std=c++20 -fchecking"
it fails with:
...
pr103328_smaller.cpp:30:13: error: location references block not in block tree
... (repeated multiple times)
pr103328_smaller.cpp:30: confused by earlier errors, bailing out
Preprocessed source stored into /tmp/ccdJXVFM.out file, please attach this to
your bugreport.
For "g++ (GCC) 11.2.1 20220127 (Red Hat 11.2.1-9)" and "-g -std=c++20
-fno-checking" it fails with:
during RTL pass: final
pr103328_smaller.cpp: In function ‘void
foo::f()operator()(foo::f()_ZZN3foo1fEvENKUlvE_clEv.Frame*)’:
pr103328_smaller.cpp:24:17: internal compiler error: Segmentation fault
24 | auto lambda = [this]() noexcept -> task {
| ^
Please submit a full bug report,
For "g++
(Compiler-Explorer-Build-gcc-cb3afcd2a380f2fb6c490f2c1318f76402eab43a-binutils-2.36.1)
12.0.1 20220217 (experimental)" and "-g -std=c++20 -fno-checking" it fails
with:
during RTL pass: final
: In function 'void
foo::f()operator()(foo::f()_ZZN3foo1fEvENKUlvE_clEv.Frame*)':
:24:17: internal compiler error: tree check: expected block, have
function_decl in change_scope, at final.cc:1467
24 | auto lambda = [this]() noexcept -> task {
| ^
0x217c1f9 internal_error(char const*, ...)
???:0
0x6f3eaf tree_check_failed(tree_node const*, char const*, int, char const*,
...)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
For "g++
(Compiler-Explorer-Build-gcc-cb3afcd2a380f2fb6c490f2c1318f76402eab43a-binutils-2.36.1)
12.0.1 20220217 (experimental)" and "-g -std=c++20 -fchecking" it fails with:
...
:30:13: error: location references block not in block tree
... (repeated multiple times)
during IPA pass: *free_lang_data
:30:13: internal compiler error: verify_gimple failed
0x217c1f9 internal_error(char const*, ...)
???:0
0x1188a85 verify_gimple_in_cfg(function*, bool)
???:0
[Bug c++/104702] New: [12 Regression] False positive -Wunused-value warning with -fno-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104702
Bug ID: 104702
Summary: [12 Regression] False positive -Wunused-value warning
with -fno-exceptions
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dani at danielbertalan dot dev
Target Milestone: ---
I'm getting a false positive "value computed is not used" warning on trunk iff
I specify -fno-exceptions.
Godbolt link: https://godbolt.org/z/h7ssrza8Y
$ cat unused.cpp
struct FlyString {
FlyString(char const*);
~FlyString();
};
struct Array { FlyString __data[1]; };
void frobnicate(Array&);
int main() {
Array s_reserved_words { "" };
frobnicate(s_reserved_words);
}
$ g++ -fno-exceptions -Wunused-value unused.cpp
unused.cpp: In function 'int main()':
unused.cpp:11:33: warning: value computed is not used [-Wunused-value]
11 | Array s_reserved_words { "" };
| ^
[Bug target/100085] Bad code for union transfer from __float128 to vector types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100085 --- Comment #23 from Steven Munroe --- Ok, but I strongly recommend a compiler test that verify that the compiler is generating the expected code (for this and other cases). We have a history of common code changes (accidental or deliberate) causing regressions for POWER targets. Best to find these early, before they impact customer performance.
[Bug target/104701] New: MIPS: Nested interrupts won't work with 2 or more shadow register sets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104701
Bug ID: 104701
Summary: MIPS: Nested interrupts won't work with 2 or more
shadow register sets
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: reimu at sudomaker dot com
Target Milestone: ---
GCC version: 12.0
System type: MIPS32 M5150, little endian
Hardware: Microchip PIC32MZ
The PIC32MZ device has EIC and 7 shadow register sets. If 2 different
interrupts with different assigned shadow register sets are coming nested
(second over first), the normal non-interrupt code will end up using first
interrupt's shadow set when all of them are finished.
Example code:
// ISR #1: Timer1
void __attribute__ ((interrupt, use_shadow_register_set,
__section__(".vectors"))) ISR_Timer1() {
// do something
IFS0CLR = _IFS0_T1IF_MASK;
}
// ISR #2: External 0
void __attribute__ ((interrupt, use_shadow_register_set,
__section__(".vectors"))) ISR_EXT0() {
// do something
IFS0CLR = _IFS0_INT0IF_MASK;
}
void setup_interrupts() {
uint32_t val;
// Set the CP0 cause IV bit high
asm volatile("mfc0 %0,$13" : "=r"(val));
val |= 0x0080;
asm volatile("mtc0 %0,$13" : "+r"(val));
// Enable multi-vectored mode
INTCONSET = _INTCON_MVEC_MASK;
// Assign a different SR set for each priority
PRISS = 0x76543210;
asm("ei");
// Enable Timer1 interrupt with priority 3
IPC1bits.T1IP = 3;
IPC1bits.T1IS = 0;
IFS0CLR = _IFS0_T1IF_MASK;
IEC0SET = _IEC0_T1IE_MASK;
// Enable Timer1 interrupt with priority 4
IPC0bits.INT0IP = 4;
IPC0bits.INT0IS = 0;
IFS0CLR = _IFS0_INT0IF_MASK;
IEC0SET = _IEC0_INT0IE_MASK;
}
int main() {
// some bootstrap code...
setup_interrupts();
while (1) {
// doing some work, CP0.SRSCtl.CSS is 0, CP0.SRSCtl.PSS is 0
// Timer1 interrupt comes, CP0.SRSCtl.CSS is 3, CP0.SRSCtl.PSS
is 0
// External0 interrupt comes, CP0.SRSCtl.CSS is 4,
CP0.SRSCtl.PSS is 3
// External0 interrupt ends, CP0.SRSCtl.CSS is 3,
CP0.SRSCtl.PSS is 3
// Timer1 interrupt ends, CP0.SRSCtl.CSS is 3, CP0.SRSCtl.PSS
is 3
// The program is screwed, since CP0.SRSCtl.CSS is NO LONGER 0
}
}
[Bug target/64785] [9/10/11/12 Regression][SH] and|or|xor #imm not used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64785 Roger Sayle changed: What|Removed |Added Status|NEW |RESOLVED CC||roger at nextmovesoftware dot com Resolution|--- |FIXED Target Milestone|9.5 |12.0 --- Comment #17 from Roger Sayle --- This appears to have been fixed on trunk; a cross-compiler to sh-elf produces: _test000: mov r5,r0 and #128,r0 rts mov.l r0,@r4 _test001: mov r5,r0 or #128,r0 rts mov.l r0,@r4 _test002: mov r5,r0 xor #128,r0 rts mov.l r0,@r4
[Bug tree-optimization/104700] [12 Regression] ICE on valid code at -O2 and -O3 with -fno-tree-ccp -fno-tree-dce -fno-tree-vrp on x86_64-linux-gnu: in find_or_generate_expression, at tree-ssa-pre.cc:2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104700 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Summary|ICE on valid code at -O2|[12 Regression] ICE on |and -O3 with -fno-tree-ccp |valid code at -O2 and -O3 |-fno-tree-dce -fno-tree-vrp |with -fno-tree-ccp |on x86_64-linux-gnu: in |-fno-tree-dce -fno-tree-vrp |find_or_generate_expression |on x86_64-linux-gnu: in |, at tree-ssa-pre.cc:2795 |find_or_generate_expression ||, at tree-ssa-pre.cc:2795 Last reconfirmed||2022-02-26 Ever confirmed|0 |1 Version|unknown |12.0 Target Milestone|--- |12.0 CC||jakub at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Priority|P3 |P1 --- Comment #2 from Jakub Jelinek --- Started with r12-7389-ge25dce501334053239dcc433e4c46ecbddbcb13e
[Bug tree-optimization/104700] ICE on valid code at -O2 and -O3 with -fno-tree-ccp -fno-tree-dce -fno-tree-vrp on x86_64-linux-gnu: in find_or_generate_expression, at tree-ssa-pre.cc:2795
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104700 --- Comment #1 from Zhendong Su --- >From Compiler Explorer: https://godbolt.org/z/PKfrMK489
[Bug tree-optimization/104700] New: ICE on valid code at -O2 and -O3 with -fno-tree-ccp -fno-tree-dce -fno-tree-vrp on x86_64-linux-gnu: in find_or_generate_expression, at tree-ssa-pre.cc:2795
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104700
Bug ID: 104700
Summary: ICE on valid code at -O2 and -O3 with -fno-tree-ccp
-fno-tree-dce -fno-tree-vrp on x86_64-linux-gnu: in
find_or_generate_expression, at tree-ssa-pre.cc:2795
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
It appears to be a recent regression.
[627] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.1 20220226 (experimental) [master r12-7395-gafeaaf4b352] (GCC)
[628] %
[628] % gcctk -O2 -fno-tree-ccp -fno-tree-dce -fno-tree-vrp small.c
during GIMPLE pass: pre
small.c: In function ‘main’:
small.c:2:5: internal compiler error: in find_or_generate_expression, at
tree-ssa-pre.cc:2795
2 | int main() {
| ^~~~
0x1005c10 find_or_generate_expression
../../gcc-trunk/gcc/tree-ssa-pre.cc:2795
0x1005132 create_expression_by_pieces
../../gcc-trunk/gcc/tree-ssa-pre.cc:2951
0x10095b1 insert_into_preds_of_block
../../gcc-trunk/gcc/tree-ssa-pre.cc:3159
0x100b134 do_pre_regular_insertion
../../gcc-trunk/gcc/tree-ssa-pre.cc:3416
0x100b134 insert
../../gcc-trunk/gcc/tree-ssa-pre.cc:3809
0x100b134 execute
../../gcc-trunk/gcc/tree-ssa-pre.cc:4433
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[629] %
[629] % cat small.c
int a, b;
int main() {
int c = 2, d, e = 0;
if (a)
e = 2;
int f, g = -(1L | (e && f && f & e));
if (g)
L:
g = c;
c = 0;
d = e * g;
if (d)
goto L;
while (e) {
int i = (a && b) * i;
}
return 0;
}
[Bug c++/104699] New: zero-length-array is not considered as an array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104699 Bug ID: 104699 Summary: zero-length-array is not considered as an array Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: nickhuang99 at hotmail dot com Target Milestone: --- GCC clearly states that "declaring zero-length arrays is allowed in GNU C as an extension". https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html However, parser rejects to recognize int[0] as an array. i.e. static_assert(! std::is_array::value); This is not an issue of library function "is_array". Instead it is the specialization of "is_array" which is not considered valid.
[Bug target/104698] Inefficient code for DI to TI sign extend on power10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104698 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2022-02-26 Ever confirmed|0 |1 --- Comment #2 from Segher Boessenkool --- Trying 6 -> 12: 6: r120:TI=unspec[r121:DI] 190 REG_DEAD r121:DI 12: %3:TI=unspec[r120:TI] 189 REG_DEAD r120:TI Failed to match this instruction: (set (reg/i:TI 3 3) (unspec:TI [ (unspec:TI [ (reg:DI 121) ] UNSPEC_MTVSRD_DITI_W1) ] UNSPEC_EXTENDDITI2)) If this was expressed as RTL, it would just work.
[Bug target/104698] Inefficient code for DI to TI sign extend on power10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104698 --- Comment #1 from Segher Boessenkool --- GCC should not use unspecs for any basic operations like this. *That* is the problem.
[Bug gcov-profile/104685] multiple common of `__gcov_var'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104685 --- Comment #3 from Gejoe --- Thank you Richard for your valuable inputs. That helps !!
[Bug c/104693] Can't disable "comparison between pointer and integer"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104693 Andrew Pinski changed: What|Removed |Added Severity|normal |minor Last reconfirmed||2022-02-26 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Confirmed, the C++ front-end can turn off this warning with -Wno-pointer-arith so I don't see why the C front-end could be made to do the same.
