[Bug tree-optimization/109005] [13 Regression] ICE during GIMPLE pass: ifcvt

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109005

--- Comment #16 from Marc Poulhiès  ---
(In reply to avieira from comment #15)
> @richi: Yeah and as I mentioned on IRC I can confirm it fixes the issue, I
> also bootstrapped and regression tested the change on
> aarch64-unknown-linux-gnu.
> 
> Simon, I can't compile your minimal reproducer, first it complains about
> missing the body keyword, so I added that, but then it complains about
> missing a ifcvt_demo.ads, tried adding an empty one but that didn't work.

Try by using the small reproducer as the ads file instead:

gcc -c -O3 ifcvt_demo.ads  

during GIMPLE pass: ifcvt

raised STORAGE_ERROR : stack overflow or erroneous memory access

[Bug tree-optimization/109005] [13 Regression] ICE during GIMPLE pass: ifcvt

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109005

--- Comment #17 from Marc Poulhiès  ---
FWIW, can confirm the above fix works for the small reproducer (x86_64-linux)

   /* Bail out if the representative is BLKmode as we will not be able to
  vectorize this.  */
-  if (TYPE_MODE (TREE_TYPE (rep_decl)) == E_BLKmode)
+  if (!is_gimple_reg_type (TREE_TYPE (rep_decl)))
 return NULL_TREE;

[Bug go/107581] New: ICE on sparc-leon-uclibc during go build

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107581

Bug ID: 107581
   Summary: ICE on sparc-leon-uclibc during go build
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: dkm at gcc dot gnu.org
  Target Milestone: ---

While building a cross compiler for sparc-leon with Go enabled, I get the
following ICE:

/path/git/crosstool-ng/.build/sparc-leon-linux-uclibc/build/build-cc-gcc-final/./gcc/gccgo
-B/path/git/crosstool-ng/.build/sparc-leon-linux-uclibc/build/build-cc-gcc-final/./gcc/
-B/path/crosstool-scratch/sparc-leon-linux-uclibc/sparc-leon-linux-uclibc/bin/
-B/path/crosstool-scratch/sparc-leon-linux-uclibc/sparc-leon-linux-uclibc/lib/
-isystem
/path/crosstool-scratch/sparc-leon-linux-uclibc/sparc-leon-linux-uclibc/include
-isystem
/path/crosstool-scratch/sparc-leon-linux-uclibc/sparc-leon-linux-uclibc/sys-include
-O2 -g -I . -c -fgo-pkgpath=runtime/internal/atomic -fgo-compiling-runtime
/path/git/crosstool-ng/.build/sparc-leon-linux-uclibc/src/gcc/libgo/go/runtime/internal/atomic/doc.go
/path/git/crosstool-ng/.build/sparc-leon-linux-uclibc/src/gcc/libgo/go/runtime/internal/atomic/gccgo.go
/path/git/crosstool-ng/.build/sparc-leon-linux-uclibc/src/gcc/libgo/go/runtime/internal/atomic/stubs.go
/path/git/crosstool-ng/.build/sparc-leon-linux-uclibc/src/gcc/libgo/go/runtime/internal/atomic/types.go
/path/git/crosstool-ng/.build/sparc-leon-linux-uclibc/src/gcc/libgo/go/runtime/internal/atomic/unaligned.go
 -fPIC -o runtime/internal/.libs/atomic.o -freport-bug -save-temps

during RTL pass: expand
/path/git/crosstool-ng/.build/sparc-leon-linux-uclibc/src/gcc/libgo/go/runtime/internal/atomic/types.go:
In function 'runtime/internal/atomic.Int32.Add':
/path/git/crosstool-ng/.build/sparc-leon-linux-uclibc/src/gcc/libgo/go/runtime/internal/atomic/types.go:47:16:
internal compiler error: Segmentation fault
   47 | return Xaddint32(&i.value, delta)
  |^
0xc01d6f crash_signal
   
/path/git/crosstool-ng/.build/sparc-leon-linux-uclibc/src/gcc/gcc/toplev.cc:314
0x7f7eff3daf8f ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0xeea114 get_callee_fndecl(tree_node const*)
   
/path/git/crosstool-ng/.build/sparc-leon-linux-uclibc/src/gcc/gcc/tree.cc:8459
0x72f8f0 expand_call(tree_node*, rtx_def*, int)
   
/path/git/crosstool-ng/.build/sparc-leon-linux-uclibc/src/gcc/gcc/calls.cc:2740
0x717412 expand_builtin_atomic_fetch_op
   
/path/git/crosstool-ng/.build/sparc-leon-linux-uclibc/src/gcc/gcc/builtins.cc:6497
0x7234c2 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
   
/path/git/crosstool-ng/.build/sparc-leon-linux-uclibc/src/gcc/gcc/builtins.cc:8343
0x864639 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
   
/path/git/crosstool-ng/.build/sparc-leon-linux-uclibc/src/gcc/gcc/expr.cc:11865
0x86e065 store_expr(tree_node*, rtx_def*, int, bool, bool)
   
/path/git/crosstool-ng/.build/sparc-leon-linux-uclibc/src/gcc/gcc/expr.cc:6330
0x870720 expand_assignment(tree_node*, tree_node*, bool)
   
/path/git/crosstool-ng/.build/sparc-leon-linux-uclibc/src/gcc/gcc/expr.cc:6051
0x74301c expand_call_stmt
   
/path/git/crosstool-ng/.build/sparc-leon-linux-uclibc/src/gcc/gcc/cfgexpand.cc:2829
0x74301c expand_gimple_stmt_1
   
/path/git/crosstool-ng/.build/sparc-leon-linux-uclibc/src/gcc/gcc/cfgexpand.cc:3880
0x74301c expand_gimple_stmt
   
/path/git/crosstool-ng/.build/sparc-leon-linux-uclibc/src/gcc/gcc/cfgexpand.cc:4044
0x7489ae expand_gimple_basic_block
   
/path/git/crosstool-ng/.build/sparc-leon-linux-uclibc/src/gcc/gcc/cfgexpand.cc:6096
0x74a55e execute
   
/path/git/crosstool-ng/.build/sparc-leon-linux-uclibc/src/gcc/gcc/cfgexpand.cc:6822
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.

I can provide more info if needed, or rebuild with a debug build.

The ICE has been first observed on 12.2.0 tgz and reproduced on today's master
(bbcb84bb)

The build has been configured with: 
 CC_FOR_BUILD='x86_64-build_pc-linux-gnu-gcc' CFLAGS='-O2 -g -pipe
-I/path/git/crosstool-ng/.build/sparc-leon-linux-uclibc/buildtools/include  '
CFLAGS_FOR_BUILD='-O2 -g -pipe
-I/path/git/crosstool-ng/.build/sparc-leon-linux-uclibc/buildtools/include  '
CXXFLAGS='-O2 -g -pipe
-I/path/git/crosstool-ng/.build/sparc-leon-linux-uclibc/buildtools/include   '
CXXFLAGS_FOR_BUILD='-O2 -g -pipe
-I/path/git/crosstool-ng/.build/sparc-leon-linux-uclibc/buildtools/include   '
LDFLAGS='-L/path/git/crosstool-ng/.build/sparc-leon-linux-uclibc/buildtools/lib
 ' CFLAGS_FOR_TARGET='-g -O2 ' CXXFLAGS_FOR_TARGET='-g -O2 '
LDFLAGS_FOR_TARGET='' '/usr/bin/bash'
'/path/git/crosstool-ng/.build/sparc-leon-linux-uclibc/src/gcc/c

[Bug target/107581] ICE on sparc-leon-uclibc during go build

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107581

--- Comment #3 from Marc Poulhiès  ---
(In reply to Ian Lance Taylor from comment #1)
> This crash appears to be fairly deep in the middle-end.  Nothing has changed
> recently in the Go frontend.  Has this crash just started appearing, or is
> this the first time you are trying this?  If it is a relatively new crash
> then I think it must be related to some middle-end change.  Thanks.

This is a first try. I was trying 12.2.0 (ICE) then checked with trunk to see
if it was still crashing.


(In reply to Richard Biener from comment #2)
> I assume that reproducing with trunk is with checking enabled?  It would be
> nice if you can do a debugging session on the crashing go1 invocation and
> inspect the GIMPLE that's being expanded.  From the backtrace it looks like
> it's some

I don't think the build has any checking enabled but I have to check (that's
from a crosstool-ng build, so I doubt they are enabling checks).

I'll do a debug build and add the more detailed log here.

Thanks

[Bug target/107581] ICE on sparc-leon-uclibc during go build

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107581

--- Comment #4 from Marc Poulhiès  ---
You're correct, builtin_decl_explicit returns NULL.

As for the lib and fcode:

8186  {
8187enum built_in_function lib;
8188mode = get_builtin_sync_mode (fcode -
BUILT_IN_ATOMIC_ADD_FETCH_1);
8189lib = (enum built_in_function)((int)BUILT_IN_ATOMIC_FETCH_ADD_1
+ 
8190   (fcode -
BUILT_IN_ATOMIC_ADD_FETCH_1));
> 8191  target = expand_builtin_atomic_fetch_op (mode, exp, target, 
> PLUS, true,
8192 ignore, lib);
8193if (target)
8194  return target;
8195break;
(rr) p lib
$8 = BUILT_IN_ATOMIC_FETCH_ADD_4
(rr) p fcode
$9 = BUILT_IN_ATOMIC_ADD_FETCH_4

Let me know if I can do anything else to help.

[Bug target/107581] ICE on sparc-leon-uclibc during go build

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107581

--- Comment #5 from Marc Poulhiès  ---
Created attachment 53862
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53862&action=edit
naive patch

[Bug target/107581] ICE on sparc-leon-uclibc during go build

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107581

--- Comment #6 from Marc Poulhiès  ---
IIUC, the builtin for ADD_FETCH_4 is correctly defined (there's an entry with a
corresponding decl), but there's no builtin for FETCH_ADD_4.

When looking in go-gcc.cc, I see that only the ADD_FETCH is defined, and not
the FETCH_ADD. I'm testing a simple patch. It fixes the segfault but the libgo
still won't build because of missing symbols (probably an issue in uclibc? Not
sure it's worth the effort...).

I'm now regtesting the patch on x86_64.

[Bug target/107581] ICE on sparc-leon-uclibc during go build

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107581

--- Comment #10 from Marc Poulhiès  ---
Thanks for applying the fix Ian!

[Bug rust/107633] [13 regression] Bootstrap failure due to -Werror=unused-parameter and -Werror=dangling-reference

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107633

--- Comment #7 from Marc Poulhiès  ---
Hello,

(I'm merely proxying some info here)

We do have regular bootstrap builds (see
https://builder.sourceware.org/buildbot/#/builders/107 ) and were aware of the
breakage (but I'm not sure you can observe it in this builder, I'll investigate
why)

Arthur already has a pending change that should fix this, see: 

 https://github.com/Rust-GCC/gccrs/pull/1635

Not really sure how it interacts with Marek's fix. I've pinged Arthur so this
will be handled at some point :)

Thanks!

[Bug ada/107475] [10/11/12/13 Regression] libgnat fails to link libgnat.so on systems with older glibc on x86_64-linux-gnux32

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107475

Marc Poulhiès  changed:

   What|Removed |Added

 CC||dkm at gcc dot gnu.org

--- Comment #2 from Marc Poulhiès  ---
Thank Matthias for your report and patch.

The patch looks correct (although have nothing to test it), you can install it
in all affected branches.

[Bug rust/108113] Rust and --enable-link-serialization=1

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108113

Marc Poulhiès  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |dkm at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2022-12-14
 Ever confirmed|0   |1

--- Comment #1 from Marc Poulhiès  ---
Thanks Jakub! I'll fix that, thanks for the detailed report

[Bug rust/108111] Rust meets clang

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108111

--- Comment #1 from Marc Poulhiès  ---
Hello David,

Looking at the errors, most of them are trivial to fix.

1-6: missing 'override'.
9: not present in most recent dev branch on github, can be ignored as it will
disappear when we update the gcc master branch with latest code.
13-14: class is missing a virtual dtor
7,10-12: unused variables

I'll need to read a bit more about the 8 (default move assignment op being
deleted).

I've a first patch that addresses most of the warnings, but I'm missing the
last one. If Arthur (or someone else) doesn't beat me to it, I'll have a fix
shortly

[Bug rust/108111] Rust meets clang

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108111

--- Comment #3 from Marc Poulhiès  ---
Thanks Jonathan for the suggestion.

The lexer code still need some refactor because the Source type (2nd template
argument to buffered_queue) is expected to have a next() method and is used
with both a InputSource& and a TokenSource. I have a local patch but still need
to use clang to check the fix first :)

[Bug rust/108113] Rust and --enable-link-serialization=1

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108113

--- Comment #3 from Marc Poulhiès  ---
I can yes, but wasn't really sure and didn't want to interfere with Arthur
ongoing work at updating the gcc's master branch with all the pending changes
from github.

Should I submit the patch for formal approval on gcc-patches@ or can I go ahead
and apply it directly ?

[Bug rust/108113] Rust and --enable-link-serialization=1

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108113

Marc Poulhiès  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #7 from Marc Poulhiès  ---
Fixed in master.

[Bug target/108293] New: Incorrect assembly emitted for float for BPF target

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108293

Bug ID: 108293
   Summary: Incorrect assembly emitted for float for BPF target
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dkm at gcc dot gnu.org
  Target Milestone: ---

https://godbolt.org/z/z9WEs3Ksn

The generated code has identical function for b() and d(), which is obviously
wrong.

float f;
float a() { f = 1.0; return 1.0; }
float b() { f = 2.0; return 2.0; }
float c() { f = 2.0; return 3.0; }
float d() { f = 3.0; return 3.0; }

_Z1av:
lddw%r0,65
lddw%r1,f
stxw[%r1+0],%r0
exit
_Z1bv:
lddw%r0,129
lddw%r1,f
stxw[%r1+0],%r0
exit
_Z1cv:
lddw%r0,f
lddw%r1,129
stxw[%r0+0],%r1
lddw%r0,129
exit
_Z1dv:
lddw%r0,129
lddw%r1,f
stxw[%r1+0],%r0
exit

[Bug rust/105913] gccrs doesn't compile on 32-bit targets

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105913

--- Comment #3 from Marc Poulhiès  ---
Fixed in github, but not yet in gcc's repository AFAIK.

[Bug rust/105913] gccrs doesn't compile on 32-bit targets

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105913

--- Comment #5 from Marc Poulhiès  ---
Oh, nice, should have checked before commenting then ! Thanks !

[Bug ada/110898] compilation of adacl-assert-integer.ads failed

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110898

--- Comment #1 from Marc Poulhiès  ---
I get the following error when compiling the adacl-assert-integer.ads file:

```
src/adacl-assert-integer.ads:21:10: warning: unit "GNAT.Source_Info" is not
referenced [-gnatwu]
src/adacl-assert-integer.ads:25:34: (style) trailing spaces not permitted
[-gnatyb]
src/adacl-assert-integer.ads:31:01: error: child of a generic package must be a
generic unit
```

I've checked and I also get the same errors with gcc 11.x, so that's not
something new. I think your code should be fixed here.

[Bug ada/110898] compilation of adacl-assert-integer.ads failed

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110898

--- Comment #3 from Marc Poulhiès  ---
Yes, I was confused also, as I've never seen this issue when using alire.
Maybe check that your alr install is up to date, and if it's the case, report
an issue in the corresponding project:
https://github.com/alire-project/alire/issues

[Bug target/116339] New: arm-unknown-elf fails to build

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116339

Bug ID: 116339
   Summary: arm-unknown-elf fails to build
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dkm at gcc dot gnu.org
  Target Milestone: ---

The nightly build of arm-unknown-elf has been failing the last 3 days in
compiler-explorer:

Configured with: ../gcc-14.1.0/configure
--prefix=/opt/compiler-explorer/gcc-build/staging
--enable-libstdcxx-backtrace=yes -
   │ -build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu --disable-bootstrap --enable-multiarch --with-abi=m64
--with-multilib-list=m32,m64,mx32 --e
   │ nable-multilib --enable-clocale=gnu
--enable-languages=c,c++,fortran,ada,objc,obj-c++,go,d,rust,m2 --enable-ld=yes
--enable-gold=yes --enable-libstdcxx-debug --enabl
   │ e-libstdcxx-time=yes --enable-linker-build-id --enable-lto
--enable-plugins --enable-threads=posix
--with-pkgversion=Compiler-Explorer-Build-gcc--binutils-2.42


327511   │ 2024-08-12T00:22:22.0398812Z [ALL  ]   
/opt/.build/arm-unknown-linux-gnueabihf/src/gcc/libgcc/config/arm/lib1funcs.S:
Assembler messages:
327512   │ 2024-08-12T00:22:22.0400251Z [ERROR]   
/opt/.build/arm-unknown-linux-gnueabihf/src/gcc/libgcc/config/arm/lib1funcs.S:1490:
Error: too many positional arguments
327513   │ 2024-08-12T00:22:22.0401288Z [ALL  ]echo '#include
"soft-fp/divdf3.c"' >> divdf3.c
327514   │ 2024-08-12T00:22:22.0401820Z [ERROR]make[3]: *** [Makefile:498:
_dvmd_lnx_s.o] Error 1
327515   │ 2024-08-12T00:22:22.0402344Z [ERROR]make[3]: *** Waiting for
unfinished jobs

[Bug target/116339] arm-unknown-linux-gnueabihf fails to build

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116339

Marc Poulhiès  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
Summary|arm-unknown-elf fails to|arm-unknown-linux-gnueabihf
   |build   |fails to build
 Target||arm-unknown-linux-gnueabihf
 Resolution|MOVED   |---

--- Comment #3 from Marc Poulhiès  ---
Got the wrong configure line sorry.

The actual command for configure is: 

CC_FOR_BUILD='x86_64-build_pc-linux-gnu-gcc' CFLAGS='-O2 -g
-I/opt/.build/arm-unknown-linux-gnueabihf/buildtools/include  '
CFLAGS_FOR_BUILD='-O2 -g
-I/opt/.build/arm-unknown-linux-gnueabihf/buildtools/include  ' CXXFLAGS='-O2
-g -I/opt/.build/arm-unknown-linux-gnueabihf/buildtools/include   '
CXXFLAGS_FOR_BUILD='-O2 -g
-I/opt/.build/arm-unknown-linux-gnueabihf/buildtools/include   '
LDFLAGS='-L/opt/.build/arm-unknown-linux-gnueabihf/buildtools/lib  '
CFLAGS_FOR_TARGET='-g -O2 ' CXXFLAGS_FOR_TARGET='-g -O2 ' LDFLAGS_FOR_TARGET=''
'/usr/bin/bash' '/opt/.build/arm-unknown-linux-gnueabihf/src/gcc/configure'
'--build=x86_64-build_pc-linux-gnu' '--host=x86_64-build_pc-linux-gnu'
'--target=arm-unknown-linux-gnueabihf'
'--prefix=/opt/.build/arm-unknown-linux-gnueabihf/buildtools'
'--exec_prefix=/opt/.build/arm-unknown-linux-gnueabihf/buildtools'
'--with-local-prefix=/opt/compiler-explorer/arm/gcc-trunk-20240812/arm-unknown-linux-gnueabihf/arm-unknown-linux-gnueabihf/sysroot'
'--with-sysroot=/opt/compiler-explorer/arm/gcc-trunk-20240812/arm-unknown-linux-gnueabihf/arm-unknown-linux-gnueabihf/sysroot'
'--with-newlib' '--enable-threads=no' '--disable-shared' '--with-arch=armv7-a'
'--with-fpu=neon' '--with-float=hard' '--enable-__cxa_atexit'
'--disable-libgomp' '--disable-libmudflap' '--disable-libmpx' '--enable-libssp'
'--enable-libquadmath' '--enable-libquadmath-support' '--disable-libstdcxx'
'--with-gmp=/opt/.build/arm-unknown-linux-gnueabihf/buildtools'
'--with-mpfr=/opt/.build/arm-unknown-linux-gnueabihf/buildtools'
'--with-mpc=/opt/.build/arm-unknown-linux-gnueabihf/buildtools'
'--with-isl=/opt/.build/arm-unknown-linux-gnueabihf/buildtools' '--enable-lto'
'--enable-target-optspace' '--with-glibc-version=2.32' '--disable-nls'
'--disable-multilib' '--enable-languages=c' '--with-mode=thumb'
'--enable-checking=release'

[Bug target/116339] arm-unknown-linux-gnueabihf fails to build

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116339

--- Comment #6 from Marc Poulhiès  ---
Thanks Andrew, I'll switch our builds master binutils, sorry for the noise.

[Bug target/116339] arm-unknown-linux-gnueabihf fails to build

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116339

--- Comment #8 from Marc Poulhiès  ---
Ha, correct, we're already using master. But it's also where the revert has
been applied, so everything should be ok now. I should have waited one more day
and this would have saved you some time...

[Bug ada/109212] Ada "for" expression generates gcc error

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109212

--- Comment #1 from Marc Poulhiès  ---
Yes, but this has been fixed in later 11.x and above versions of the compiler,
see for example:

https://ada.godbolt.org/z/6KraGY965

I don't think we'll try to backport the Ada 202x features/bugfixes in old
compilers.

[Bug target/109328] [13 Regression] Build fail in RISC-V port

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109328

--- Comment #5 from Marc Poulhiès  ---
Thanks for the very quick fix (I'm the one who hit this issue)!

[Bug ada/109472] [13 regression] False unread/unassigned warning for variable in local package

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109472

--- Comment #2 from Marc Poulhiès  ---
Regression starts from:

a8d17a88a52d2f773423adb55399d23ed5ea03c8 is the first bad commit
commit a8d17a88a52d2f773423adb55399d23ed5ea03c8
Author: Piotr Trojanek 
Date:   Tue Jun 21 10:17:57 2022 +0200

[Ada] Warn on unset objects in packages with no bodies

Fix an inconsistency, where GNAT was warning about references to unset
objects inside generic packages with no bodies but not inside ordinary
packages with no bodies.

But the issue is probably not this particular change, that simply asks gnat to
warn on unreferenced entities. The error is most probably caused by the
Referenced(N) that returns False for 'X' entity.

[Bug ada/109798] Gnat Bug Detected

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109798

--- Comment #2 from Marc Poulhiès  ---
Can't reproduce on x86_64-linux trunk, 13.1, 12.3, 12.2, 11.3, see
https://ada.godbolt.org/z/Gbv9Wc93E

Can you get the exact compiler invocation?

[Bug ada/109798] Gnat Bug Detected

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109798

--- Comment #6 from Marc Poulhiès  ---
`alr -v build -- --keep-temp-files` should provide the expected commands.

You should have all the gcc invocations + be able to see the TMP files used
with `-gnatem` and `-gnatec`.

[Bug target/109874] [SH] GCC 13's -Os code is 50% bigger than GCC 4's

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109874

--- Comment #1 from Marc Poulhiès  ---
Forcing GCC 13 to emit non-PIC (as gcc4) code shaves a few insns, down to 28.

```
_SetupCartCHRMapping:
mov r4,r1
mov.l   .L3,r2
shlr8   r1
shlr2   r1
add #-1,r1
mov.l   r1,@r2
mov r4,r1
shlr8   r1
mov.l   .L4,r2
shlrr1
shlr2   r1
add #-1,r1
mov.l   r1,@r2
mov r4,r1
shlr8   r1
mov.l   .L5,r2
shlr2   r1
shlr2   r1
shlr8   r4
add #-1,r1
shlr2   r4
mov.l   r1,@r2
shlrr4
mov.l   .L6,r1
shlr2   r4
add #-1,r4
rts 
mov.l   r4,@r1
.L3:
.long   _CHRmask1
.L4:
.long   _CHRmask2
.L5:
.long   _CHRmask4
.L6:
.long   _CHRmask8
_CHRmask8:
.zero   4
_CHRmask4:
.zero   4
_CHRmask2:
.zero   4
_CHRmask1:
.zero   4
```

[Bug rust/114629] rust-ast-resolve-expr contains bloated code for funny_error

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114629

--- Comment #7 from Marc Poulhiès  ---
There's no language spec yet, it's WIP:
https://github.com/rust-lang/rust/issues/113527

Currently, the reference is rustc and the goal is to match its current
behavior.

I think the frontend is not listed because it's currently not
enabled/working-enough.

[Bug target/114910] New: can't build a c6x cross compiler

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114910

Bug ID: 114910
   Summary: can't build a c6x cross compiler
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dkm at gcc dot gnu.org
  Target Milestone: ---

Hello,

I'm building a c6x cross compiler using crosstool-ng (with newlib).

Configured with:

configure --build=x86_64-build_pc-linux-gnu --host=x86_64-build_pc-linux-gnu
--target=tic6x-elf --prefix=/root/crosstool-scratch/tic6x-elf
--exec_prefix=/root/crosstool-scratch/tic6x-elf
--with-local-prefix=/root/crosstool-scratch/tic6x-elf/tic6x-elf
--with-headers=/root/crosstool-scratch/tic6x-elf/tic6x-elf/include
--with-newlib --enable-threads=no --disable-shared
--with-pkgversion=crosstool-NG 1.26.0.72_810021d --enable-__cxa_atexit
--disable-libgomp --disable-libmudflap --disable-libmpx --disable-libssp
--disable-libquadmath --disable-libquadmath-support
--with-gmp=/mnt/dkm/git/crosstool-ng/.build/tic6x-elf/buildtools
--with-mpfr=/mnt/dkm/git/crosstool-ng/.build/tic6x-elf/buildtools
--with-mpc=/mnt/dkm/git/crosstool-ng/.build/tic6x-elf/buildtools
--with-isl=/mnt/dkm/git/crosstool-ng/.build/tic6x-elf/buildtools --enable-lto
--enable-target-optspace --disable-nls --enable-multiarch
--enable-languages=c,c++


The failing command:
/mnt/dkm/git/crosstool-ng/.build/tic6x-elf/build/build-cc-gcc-final/./gcc/xgcc
-B/mnt/dkm/git/crosstool-ng/.build/tic6x-elf/build/build-cc-gcc-final/./gcc/
-B/root/crosstool-scratch/tic6x-elf/tic6x-elf/bin/
-B/root/crosstool-scratch/tic6x-elf/tic6x-elf/lib/ -isystem
/root/crosstool-scratch/tic6x-elf/tic6x-elf/include -isystem
/root/crosstool-scratch/tic6x-elf/tic6x-elf/sys-include-g -O2 -idirafter
/root/crosstool-scratch/tic6x-elf/tic6x-elf/include -g -Os -mbig-endian -O2  -g
-O2  -idirafter /root/crosstool-scratch/tic6x-elf/tic6x-elf/include -g -Os
-DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition 
-isystem ./include  -msdata=none -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector  -msdata=none -I. -I. -I../../.././gcc
-I/mnt/dkm/git/crosstool-ng/.build/tic6x-elf/src/gcc/libgcc
-I/mnt/dkm/git/crosstool-ng/.build/tic6x-elf/src/gcc/libgcc/.
-I/mnt/dkm/git/crosstool-ng/.build/tic6x-elf/src/gcc/libgcc/../gcc
-I/mnt/dkm/git/crosstool-ng/.build/tic6x-elf/src/gcc/libgcc/../include 
-DHAVE_CC_TLS -DUSE_EMUTLS  -o hardcfr.o -MT hardcfr.o -MD -MP -MF hardcfr.dep 
-c /mnt/dkm/git/crosstool-ng/.build/tic6x-elf/src/gcc/libgcc/hardcfr.c
-fvisibility=hidden -DHIDE_EXPORTS -save-temps --verbose-asm
hardcfr.s: Assembler messages:  
hardcfr.s:164: Error: label not at start of execute packet  
hardcfr.s:335: Error: label not at start of execute packet  
hardcfr.s:340: Error: label not at start of execute packet  
hardcfr.s:357: Error: label not at start of execute packet  
hardcfr.s:381: Error: label not at start of execute packet  

with corresponding assembly:

 161   │ .loc 1 165 3 is_stmt 0
 162   │ callp   .s2 (consume_seq), B3   ;#
 163   │ .LVL9:
 164   │ ||  stw .d1t1   A7, *A4 ;# cfg_it__lsm.31, *cfg_it_8(D)
 165   │ ;#
/mnt/dkm/git/crosstool-ng/.build/tic6x-elf/src/gcc/libgcc/hardcfr.c:167:  
return true;
 166   │ .loc 1 167 9

 335   │ ||  add .l1x12, B15, A4 ;#,,
 336   │ ;#
/mnt/dkm/git/crosstool-ng/.build/tic6x-elf/src/gcc/libgcc/hardcfr.c:287:   
consume_seq (&cfg_it);
 337   │ .loc 1 287 4
 338   │ callp   .s2 (consume_seq), B3   ;#
 339   │ .LVL15:
 340   │ ||  add .l1x12, B15, A4 ;#,,
 341   │ .L14:
 342   │ .LBE66:
 343   │ .loc 1 274 35 is_stmt 1 discriminator 2
 344   │ .LVL16:
 345   │ b   .s1 .L12;#
 346   │ ||  add .d1 A10, 1, A10 ;# i,, i
 347   │ nop 5   ;#
 348   │ ;; jump to .L12 occurs  ;#
 349   │ .LVL17:
 350   │ .L13:
 351   │ .LBB67:
 352   │ .loc 1 292 4
 353   │ ;#
/mnt/dkm/git/crosstool-ng/.build/tic6x-elf/src/gcc/libgcc/hardcfr.c:292:if
(!check_seq (visited, &cfg_it))
 354   │ .loc 1 292 9 is_stmt 0
 355   │ callp   .s2 (check_seq), B3 ;#
 356   │ .LVL18:
 357   │ ||  add .l2 12, B15, B4 ;#,,
 358   │ ||  mv  .d1 A15, A4 ;# visited,
 359   │ ;#
/mnt/dkm/git/crosstool-ng/.build/tic6x-elf/src/gcc/libgcc/hardcfr.c:292:if
(!check_seq (visited, &cfg_it))
 360   │ .loc 1 292 7 discriminator 1
 361   │ extu.s1 A4, 24, 24, A0  ;# tmp129, _1
 362   │ [A0]b   .s1 .L15;#
 363   │ nop 5   ;#
 364   │ ;; condjump to .L15 occurs  ;#
 365   │ .LVL19:
 366   │ .L16:
 367   │ .loc 1 293 6 is_stmt 1
 368   │ .LBB64:
 369   │ .LBB65:
 370   │ .loc 1 262 3
 371   │ callp   .s2 (abort), 

[Bug target/114910] can't build a c6x cross compiler

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114910

--- Comment #4 from Marc Poulhiès  ---
Oh, so maybe I could use `-fno-var-tracking` to workaround the failure... I'll
try that, thanks.

[Bug target/114910] can't build a c6x cross compiler

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114910

--- Comment #6 from Marc Poulhiès  ---
It fails with -Os.
It works with -O0, -O1, -O2, -O3 and -Os -fno-var-tracking.

Mikael, is it possible that you're not using -Os for target libs?

[Bug target/114910] can't build a c6x cross compiler

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114910

--- Comment #9 from Marc Poulhiès  ---
Yes, sorry I should have added that in my original message (I did mention the
commit on IRC). This is the commit that introduces the hardcfr.c file that is
miscompiled. The error may be latent and bisecting should probably run the
above command with a copy of a preprocessed hardcfr.c ?

[Bug target/114993] New: ICE when using bpf-unknown-g++

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114993

Bug ID: 114993
   Summary: ICE when using bpf-unknown-g++
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dkm at gcc dot gnu.org
  Target Milestone: ---

bpf-unknown-none-g++ always ICE when using -g:

https://c.godbolt.org/z/EabsM3xjq

Using -g0 builds fine.

```
int square(int num) {
return num * num;
}
```

Using built-in specs.
COLLECT_GCC=/opt/compiler-explorer/bpf/gcc-trunk/bpf-unknown-none/bin/bpf-unknown-none-g++
Target: bpf-unknown-none
Configured with: /opt/.build/bpf-unknown-none/src/gcc/configure
--build=x86_64-build_pc-linux-gnu --host=x86_64-build_pc-linux-gnu
--target=bpf-unknown-none
--prefix=/opt/compiler-explorer/bpf/gcc-trunk-20240508/bpf-unknown-none
--exec_prefix=/opt/compiler-explorer/bpf/gcc-trunk-20240508/bpf-unknown-none
--with-local-prefix=/opt/compiler-explorer/bpf/gcc-trunk-20240508/bpf-unknown-none/bpf-unknown-none
--with-headers=/opt/compiler-explorer/bpf/gcc-trunk-20240508/bpf-unknown-none/bpf-unknown-none/include
--with-newlib --enable-threads=no --disable-shared
--with-pkgversion='crosstool-NG UNKNOWN' --disable-__cxa_atexit
--disable-libgomp --disable-libmudflap --disable-libmpx --disable-libssp
--disable-libquadmath --disable-libquadmath-support --disable-libstdcxx-verbose
--disable-libstdcxx --with-gmp=/opt/.build/bpf-unknown-none/buildtools
--with-mpfr=/opt/.build/bpf-unknown-none/buildtools
--with-mpc=/opt/.build/bpf-unknown-none/buildtools
--with-isl=/opt/.build/bpf-unknown-none/buildtools --enable-lto
--enable-target-optspace --disable-nls --disable-multilib
--enable-languages=c,c++
Thread model: single
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20240507 (experimental) (crosstool-NG UNKNOWN) 
COLLECT_GCC_OPTIONS='-fdiagnostics-color=always' '-g' '-o' '/app/output.s' '-S'
'-v' '-dumpdir' '/app/'

/opt/compiler-explorer/bpf/gcc-trunk-20240508/bpf-unknown-none/libexec/gcc/bpf-unknown-none/15.0.0/cc1plus
-quiet -v  -quiet -dumpdir /app/ -dumpbase output.cpp -dumpbase-ext
.cpp -g -version -fdiagnostics-color=always -o /app/output.s
GNU C++17 (crosstool-NG UNKNOWN) version 15.0.0 20240507 (experimental)
(bpf-unknown-none)
compiled by GNU C version 14.1.0, GMP version 6.2.1, MPFR version
4.2.1, MPC version 1.3.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory
"/opt/compiler-explorer/bpf/gcc-trunk-20240508/bpf-unknown-none/lib/gcc/bpf-unknown-none/15.0.0/../../../../bpf-unknown-none/include/c++/15.0.0"
ignoring nonexistent directory
"/opt/compiler-explorer/bpf/gcc-trunk-20240508/bpf-unknown-none/lib/gcc/bpf-unknown-none/15.0.0/../../../../bpf-unknown-none/include/c++/15.0.0/bpf-unknown-none"
ignoring nonexistent directory
"/opt/compiler-explorer/bpf/gcc-trunk-20240508/bpf-unknown-none/lib/gcc/bpf-unknown-none/15.0.0/../../../../bpf-unknown-none/include/c++/15.0.0/backward"
#include "..." search starts here:
#include <...> search starts here:

/opt/compiler-explorer/bpf/gcc-trunk-20240508/bpf-unknown-none/lib/gcc/bpf-unknown-none/15.0.0/include

/opt/compiler-explorer/bpf/gcc-trunk-20240508/bpf-unknown-none/lib/gcc/bpf-unknown-none/15.0.0/include-fixed

/opt/compiler-explorer/bpf/gcc-trunk-20240508/bpf-unknown-none/lib/gcc/bpf-unknown-none/15.0.0/../../../../bpf-unknown-none/sys-include

/opt/compiler-explorer/bpf/gcc-trunk-20240508/bpf-unknown-none/lib/gcc/bpf-unknown-none/15.0.0/../../../../bpf-unknown-none/include
End of search list.
Compiler executable checksum: ed25500f957a8d770dd6c33cfdac0a0b
during RTL pass: final
: In function 'int square(int)':
:4:1: internal compiler error: Segmentation fault
4 | }
  | ^
0x1e609e8 internal_error(char const*, ...)
???:0
0x16d7834 btf_ext_add_string
???:0
0x16d7b19 btf_add_func_info_for
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
Compiler returned: 1

[Bug target/114993] ICE when using bpf-unknown-g++

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114993

--- Comment #1 from Marc Poulhiès  ---
After discussing on IRC, C++ (or anything != C) is not supported by BPF.
The fix is probably to display an error when using anything else than the C FE.

The Rust FE gives another error:
https://c.godbolt.org/z/TeWa3cshd

bpf-unknown-gcc: warning: : linker input file unused because linking
not done

Not sure why it does not even use crab1 in this case.

[Bug target/114993] ICE when using bpf-unknown-g++

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114993

Marc Poulhiès  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jemarch at gcc dot 
gnu.org

--- Comment #2 from Marc Poulhiès  ---
After discussing on IRC, C++ (or anything != C) is not supported by BPF.
The fix is probably to display an error when using anything else than the C FE.

The Rust FE gives another error:
https://c.godbolt.org/z/TeWa3cshd

bpf-unknown-gcc: warning: : linker input file unused because linking
not done

Not sure why it does not even use crab1 in this case.

[Bug target/114993] ICE when using bpf-unknown-g++

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114993

--- Comment #3 from Marc Poulhiès  ---
The gccrs cross compiler is not working because of the missing cargo/rustc dep,
disabling the frontend, so not a real issue.

[Bug ipa/113359] [13 Regression] LTO miscompilation of ceph on aarch64 and x86_64

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359

Marc Poulhiès  changed:

   What|Removed |Added

 CC||dkm at gcc dot gnu.org

--- Comment #31 from Marc Poulhiès  ---
Hello Martin,

Any chance the fix that fixes the new test for 32bits can be also backported?

4923ed49b93352bcf9e43cafac38345e4a54c3f8
https://gcc.gnu.org/g:4923ed49b93352bcf9e43cafac38345e4a54c3f8

Not sure why it's not tagged so that it would appear here.

[Bug ipa/113359] [13 Regression] LTO miscompilation of ceph on aarch64 and x86_64

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359

--- Comment #33 from Marc Poulhiès  ---
No worries, we've applied it locally.
Thanks!

[Bug ada/115305] [15 Regression] many (162) acats regressions on i686-darwin9

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115305

--- Comment #9 from Marc Poulhiès  ---
cxa4001 should be fixed since
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=e0ab5ee9bed5cbad9ae344a23ff0d302b8279d32

[Bug tree-optimization/115387] [15 regression] RISC-V: ICE in iovsprintf.c since r15-1081-ge14afbe2d1c

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115387

Marc Poulhiès  changed:

   What|Removed |Added

 CC||dkm at gcc dot gnu.org

--- Comment #3 from Marc Poulhiès  ---
Created attachment 58392
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58392&action=edit
preprocessed file

Preprocessed file triggering the error

[Bug tree-optimization/115387] [15 regression] RISC-V: ICE in iovsprintf.c since r15-1081-ge14afbe2d1c

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115387

--- Comment #4 from Marc Poulhiès  ---
This is command line that triggers the same error in all the nightly builds for
riscv32/64 compiler explorer.

```
$ riscv32-unknown-linux-gnu-gcc  -g -O2   -march=rv32gc -mabi=ilp32d   input.c
-c -std=gnu11 -fgnu89-inline  -g -O2 -Wall -Wwrite-strings -Wundef
-fmerge-all-constants -frounding-math -fno-stack-protector -fno-common
-Wstrict-prototypes -Wold-style-definition -fmath-errno-fPIE  
-ftls-model=initial-exec -nostdinc  -o iovsprintf.o
iovsprintf.c: In function '__vsprintf_internal':
iovsprintf.c:34:1: error: definition in block 5 follows the use
   34 | __vsprintf_internal (char *string, size_t maxlen,
  | ^~~
for SSA_NAME: _9 in statement:
prephitmp_36 = (char *) _9;
during GIMPLE pass: widening_mul
iovsprintf.c:34:1: internal compiler error: verify_ssa failed
0x162fd0f verify_ssa(bool, bool)
   
/mnt/barryallen/dkm/git/crosstool-ng/.build/riscv32-unknown-linux-gnu/src/gcc/gcc/tree-ssa.cc:1203
0x1292a65 execute_function_todo
   
/mnt/barryallen/dkm/git/crosstool-ng/.build/riscv32-unknown-linux-gnu/src/gcc/gcc/passes.cc:2096
0x1292ece execute_todo
   
/mnt/barryallen/dkm/git/crosstool-ng/.build/riscv32-unknown-linux-gnu/src/gcc/gcc/passes.cc:2143
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
```

[Bug testsuite/70150] Additonal test failures with --enable-default-pie

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70150

Marc Poulhiès  changed:

   What|Removed |Added

 CC||dkm at gcc dot gnu.org

--- Comment #30 from Marc Poulhiès  ---
Hello  Xi Ruoyao,

Your 3 patches are also fixing the regressions in the gcc-12 branch. Do you
plan on back-porting them on this release branch?

[Bug ada/110314] Gnat failed assertion and Allocators with discriminant

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110314

Marc Poulhiès  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-06-20
 Ever confirmed|0   |1

[Bug ada/110314] Gnat failed assertion and Allocators with discriminant

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110314

--- Comment #1 from Marc Poulhiès  ---
This is new in 14, was OK when forking 13.

https://ada.godbolt.org/z/TvbPxYfnP

Currently bisecting.

[Bug d/113772] [14 Regression] atomic.d compile error since recent upstream imports.

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772

Marc Poulhiès  changed:

   What|Removed |Added

 CC||dkm at gcc dot gnu.org

--- Comment #12 from Marc Poulhiès  ---
FWIW, I think we are having the same issue when building our nightly riscv32
cross on compiler explorer:
https://github.com/compiler-explorer/compiler-explorer/issues/6102

[Bug tree-optimization/115387] [15 regression] ICE in iovsprintf.c since r15-1081-ge14afbe2d1c

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115387

--- Comment #12 from Marc Poulhiès  ---
I can confirm both our riscv32/64 builds are back to normal, thanks!

[Bug modula2/118761] New: gm2 driver doesn't behave as gcc for --help=BLA

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118761

Bug ID: 118761
   Summary: gm2 driver doesn't behave as gcc for --help=BLA
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: dkm at gcc dot gnu.org
  Target Milestone: ---

$ gm2 -fsyntax-only --help=optimizers
gm2: fatal error: no input files
compilation terminated.

But gcc gives:

$ gcc -fsyntax-only --help=optimizers
The following options control optimizations:
  -O  Set optimization level to .
  -Ofast  Optimize for speed disregarding exact standards
compliance.

...

Other frontends (gccrs, gfortran, g++, gdc, gccgo) behaves all like gcc.

(ga68, the to-be-merged algol68 has the same issue).

[Bug modula2/118761] gm2 driver doesn't behave as gcc for --help=BLA

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118761

--- Comment #1 from Marc Poulhiès  ---
(same inconsistent behavior with "--help --verbose")

[Bug modula2/118761] gm2 driver doesn't behave as gcc for --help=BLA

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118761

--- Comment #6 from Marc Poulhiès  ---
Thanks for the quick fix!

[Bug ada/114065] gnat build with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 fails on 32bit archs

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065

--- Comment #33 from Marc Poulhiès  ---
Hello Nicolas,

Sorry this is taking so long, thank you for your patience.

Thank you also for having rebased your changes, I've been able to apply it
internally and run some tests. I only have partial tests coverage as some
applications need to be adjusted after the revert, but results are OK for the
ones that can be executed.

We are currently having a look at how to reconcile both conflicting changes and
will come back to you early next year, before stage 4 ends.

[Bug c++/119516] SIGKILL when -O2

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119516

Marc Poulhiès  changed:

   What|Removed |Added

 CC||dkm at gcc dot gnu.org

--- Comment #4 from Marc Poulhiès  ---
Beware that compiler-explorer builds are cached: that's why you can see the
SIGKILL immediately. You can click "clear cache and recompile" (bottom left of
the assembly pane). You'll see it takes a very long time to build, so not
surprising it gets killed.

I've just tried it now, and the exec was very long, but succeeded:
https://godbolt.org/z/88jneM6Ej

[Bug rust/119333] [15 regression] Rust bootstrap fails with cargo trying to download polonius crates

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119333

--- Comment #3 from Marc Poulhiès  ---
Correct. Not sure about having a .cargo at toplevel currently, so I'll simply
--offline for bck, and we'll be able to revisit.
https://github.com/Rust-GCC/gccrs/pull/3505

[Bug rust/120018] internal compiler error: in redirect_to_unreachable, at ipa-fnsummary.cc:258 for 32-bits

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120018

--- Comment #3 from Marc Poulhiès  ---
Ok, thanks Andrew, we'll take care of fixing this.

[Bug ipa/120018] New: internal compiler error: in redirect_to_unreachable, at ipa-fnsummary.cc:258 for 32-bits

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120018

Bug ID: 120018
   Summary: internal compiler error: in redirect_to_unreachable,
at ipa-fnsummary.cc:258 for 32-bits
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dkm at gcc dot gnu.org
  Target Milestone: ---

Running the rust testsuite with -m32 on x86_64 triggers 2 ICE:

 /.../git/gcc-master/build/gcc/testsuite/rust10/../../gccrs
-B.../git/gcc-master/build/gcc/testsuite/rust10/../../
/.../git/gcc-master/gcc/testsuite/rust/execute/torture/derive_clone_enum1.rs
-m32 -fdiagnostics-plain-output
-frust-incomplete-and-experimental-compiler-do-not-use -O1 -lm -o
./derive_clone_enum1.exe
during IPA pass: inline
crab1: internal compiler error: in redirect_to_unreachable, at
ipa-fnsummary.cc:258
0x38f10b1 internal_error(char const*, ...)
../../gcc/diagnostic-global-context.cc:517
0x38d9cff fancy_abort(char const*, int, char const*)
../../gcc/diagnostic.cc:1748
0x2c61577 redirect_to_unreachable
../../gcc/ipa-fnsummary.cc:258
0x2c61577 edge_set_predicate
../../gcc/ipa-fnsummary.cc:290
0x2c52390 remap_edge_summaries
../../gcc/ipa-fnsummary.cc:4355
0x2c55bdf ipa_merge_fn_summary_after_inlining(cgraph_edge*)
../../gcc/ipa-fnsummary.cc:4519
0x2c9942f inline_call(cgraph_edge*, bool, vec*,
int*, bool, bool*)
../../gcc/ipa-inline-transform.cc:522
0x2c80250 inline_to_all_callers_1
../../gcc/ipa-inline.cc:2612
0x2c80250 inline_to_all_callers
../../gcc/ipa-inline.cc:2637
0x2c81e1a cgraph_node::call_for_symbol_and_aliases(bool (*)(cgraph_node*,
void*), void*, bool)
../../gcc/cgraph.h:3434
0x2c81e1a ipa_inline
../../gcc/ipa-inline.cc:2962
0x2c81e1a execute
../../gcc/ipa-inline.cc:3291

Failing assert is:
 258   │   gcc_checking_assert (lookup_attribute ("cold",
 259   │  DECL_ATTRIBUTES (target->decl)));

(gdb) call debug_tree(target->decl)
 >
QI
size 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7722a0a8
arg-types >
pointer_to_this >
public external built-in QI :0:0
align:8 warn_if_not_align:0 built-in: BUILT_IN_NORMAL:BUILT_IN_UNREACHABLE>

Or maybe the rust frontend is doing something incorrect with
__builtin_unreachable?

[Bug ada/114065] gnat build with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 fails on 32bit archs

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065

--- Comment #35 from Marc Poulhiès  ---
Hello Matthias,

As planned, we had another look at Nicolas' changes, and sent some feedback on
January 3rd, see the messages on gcc-patches@
(https://inbox.sourceware.org/gcc-patches/878qrrgbbz@adacore.com/).

Mainly, the changes are OK but need adjustment to not break existing API +
minor comment on glibc dependency.

We haven't heard back since then.

[Bug c++/119516] SIGKILL when -O2

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119516

--- Comment #5 from Marc Poulhiès  ---
Here's the -ftime-report from a successful run at -O2
(https://godbolt.org/z/KEvs93bcx)


Time variable  wall   GGC
 phase setup:   0.02 (  0%)  1822k (  1%)
 phase parsing  :   4.70 ( 27%)   139M ( 46%)
 phase lang. deferred   :   1.43 (  8%)38M ( 13%)
 phase opt and generate :  11.45 ( 65%)   120M ( 40%)
 phase last asm :   0.11 (  1%)  1873k (  1%)
 |name lookup   :   0.82 (  5%)  4465k (  1%)
 |overload resolution   :   1.41 (  8%)37M ( 12%)
 garbage collection :   0.93 (  5%) 0  (  0%)
 dump files :   0.05 (  0%) 0  (  0%)
 callgraph construction :   0.10 (  1%)  2441k (  1%)
 callgraph optimization :   0.10 (  1%)15k (  0%)
 callgraph functions expansion  :   9.24 ( 52%)80M ( 27%)
 callgraph ipa passes   :   1.87 ( 11%)24M (  8%)
 ipa function summary   :   0.02 (  0%)   514k (  0%)
 ipa dead code removal  :   0.01 (  0%) 0  (  0%)
 ipa cp :   0.02 (  0%)   361k (  0%)
 ipa inlining heuristics:   0.07 (  0%)  2097k (  1%)
 ipa function splitting :   0.02 (  0%)   422k (  0%)
 ipa pure const :   0.02 (  0%)32k (  0%)
 ipa icf:   0.01 (  0%) 0  (  0%)
 ipa SRA:   0.01 (  0%)   266k (  0%)
 ipa modref :   0.01 (  0%)   199k (  0%)
 cfg cleanup:   0.08 (  0%)   514k (  0%)
 CFG verifier   :   0.53 (  3%) 0  (  0%)
 trivially dead code:   0.03 (  0%)  2648  (  0%)
 df scan insns  :   0.02 (  0%)  2400  (  0%)
 df reaching defs   :   0.06 (  0%) 0  (  0%)
 df live regs   :   0.18 (  1%)38k (  0%)
 df live&initialized regs   :   0.07 (  0%) 0  (  0%)
 df use-def / def-use chains:   0.03 (  0%) 0  (  0%)
 df reg dead/unused notes   :   0.07 (  0%)   599k (  0%)
 register information   :   0.02 (  0%) 0  (  0%)
 alias analysis :   0.04 (  0%)  1322k (  0%)
 alias stmt walking :   0.10 (  1%)   287k (  0%)
 register scan  :   0.01 (  0%)10k (  0%)
 rebuild jump labels:   0.01 (  0%)   144  (  0%)
 preprocessing  :   0.88 (  5%)  3989k (  1%)
 parser (global):   0.79 (  4%)48M ( 16%)
 parser struct body :   0.49 (  3%)20M (  7%)
 parser enumerator list :   0.01 (  0%)   198k (  0%)
 parser function body   :   0.11 (  1%)  6110k (  2%)
 parser inl. func. body :   0.27 (  2%)  5861k (  2%)
 parser inl. meth. body :   0.59 (  3%)16M (  6%)
 template instantiation :   1.77 ( 10%)53M ( 18%)
 constant expression evaluation :   0.15 (  1%)  2031k (  1%)
 constraint normalization   :   0.08 (  0%)  2000k (  1%)
 constraint satisfaction:   0.38 (  2%)  8306k (  3%)
 early inlining heuristics  :   0.02 (  0%)   478k (  0%)
 inline parameters  :   0.05 (  0%)  1344k (  0%)
 integration:   0.28 (  2%)24M (  8%)
 tree gimplify  :   0.06 (  0%)  3790k (  1%)
 tree eh:   0.01 (  0%)   442k (  0%)
 tree CFG construction  :   0.02 (  0%)  1533k (  0%)
 tree CFG cleanup   :   0.22 (  1%)   210k (  0%)
 tree tail merge:   0.01 (  0%)   350k (  0%)
 tree VRP   :   0.24 (  1%)   697k (  0%)
 tree Early VRP :   0.07 (  0%)   900k (  0%)
 tree copy propagation  :   0.03 (  0%)28k (  0%)
 tree PTA   :   0.10 (  1%)   386k (  0%)
 tree SSA rewrite   :   0.02 (  0%)  1078k (  0%)
 tree SSA incremental   :   0.10 (  1%)  1400k (  0%)
 tree operand scan  :   0.17 (  1%)  3964k (  1%)
 dominator optimization :   0.31 (  2%)  2378k (  1%)
 backwards jump threading   :   0.36 (  2%)  2423k (  1%)
 tree SRA   :   0.03 (  0%)   734k (  0%)
 tree CCP   :   0.14 (  1%)   389k (  0%)
 tree split crit edges  :   0.01 (  0%)   395k (  0%)
 tree reassociation :   0.01 (  0%)11k (  0%)
 tree PRE   :   0.11 (  1%)  1005k (  0%)
 tree FRE   :   0.15 (  1%)   830k (  0%)
 tree code sinking  :   0.01 (  0%)   760k (  0%)
 tree linearize phis:   0.02 (  0%)   111k (  0%)