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

2024-06-11 Thread 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 tree-optimization/115387] [15 regression] RISC-V: ICE in iovsprintf.c since r15-1081-ge14afbe2d1c

2024-06-09 Thread 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 tree-optimization/115387] [15 regression] RISC-V: ICE in iovsprintf.c since r15-1081-ge14afbe2d1c

2024-06-09 Thread 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=edit
preprocessed file

Preprocessed file triggering the error

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

2024-06-04 Thread 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 ipa/113359] [13 Regression] LTO miscompilation of ceph on aarch64 and x86_64

2024-05-20 Thread 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 ipa/113359] [13 Regression] LTO miscompilation of ceph on aarch64 and x86_64

2024-05-17 Thread 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 target/114993] ICE when using bpf-unknown-g++

2024-05-12 Thread 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 target/114993] ICE when using bpf-unknown-g++

2024-05-08 Thread 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++

2024-05-08 Thread 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] New: ICE when using bpf-unknown-g++

2024-05-08 Thread 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/114910] can't build a c6x cross compiler

2024-05-03 Thread 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/114910] can't build a c6x cross compiler

2024-05-02 Thread 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

2024-05-02 Thread 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] New: can't build a c6x cross compiler

2024-05-01 Thread 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 (_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, _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, _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), B3 ;#
 372  

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

2024-04-09 Thread 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 d/113772] [14 Regression] atomic.d compile error since recent upstream imports.

2024-02-05 Thread 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 ada/110898] compilation of adacl-assert-integer.ads failed

2023-08-07 Thread 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 ada/110898] compilation of adacl-assert-integer.ads failed

2023-08-04 Thread 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/110314] Gnat failed assertion and Allocators with discriminant

2023-06-20 Thread 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 ada/110314] Gnat failed assertion and Allocators with discriminant

2023-06-20 Thread 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 testsuite/70150] Additonal test failures with --enable-default-pie

2023-06-12 Thread 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 target/109874] [SH] GCC 13's -Os code is 50% bigger than GCC 4's

2023-05-16 Thread 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 ada/109798] Gnat Bug Detected

2023-05-11 Thread 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 ada/109798] Gnat Bug Detected

2023-05-11 Thread 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/109472] [13 regression] False unread/unassigned warning for variable in local package

2023-04-12 Thread 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 target/109328] [13 Regression] Build fail in RISC-V port

2023-03-30 Thread 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/109212] Ada "for" expression generates gcc error

2023-03-20 Thread 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 tree-optimization/109005] [13 Regression] ICE during GIMPLE pass: ifcvt

2023-03-07 Thread 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 tree-optimization/109005] [13 Regression] ICE during GIMPLE pass: ifcvt

2023-03-07 Thread 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 target/108293] New: Incorrect assembly emitted for float for BPF target

2023-01-04 Thread 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/108113] Rust and --enable-link-serialization=1

2022-12-20 Thread 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 rust/108113] Rust and --enable-link-serialization=1

2022-12-19 Thread 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/108111] Rust meets clang

2022-12-15 Thread 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/108111] Rust meets clang

2022-12-14 Thread 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/108113] Rust and --enable-link-serialization=1

2022-12-14 Thread 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 ada/107475] [10/11/12/13 Regression] libgnat fails to link libgnat.so on systems with older glibc on x86_64-linux-gnux32

2022-11-21 Thread 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/107633] [13 regression] Bootstrap failure due to -Werror=unused-parameter and -Werror=dangling-reference

2022-11-14 Thread 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 target/107581] ICE on sparc-leon-uclibc during go build

2022-11-10 Thread 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 target/107581] ICE on sparc-leon-uclibc during go build

2022-11-09 Thread 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

2022-11-09 Thread 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=edit
naive patch

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

2022-11-09 Thread 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

2022-11-08 Thread 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 go/107581] New: ICE on sparc-leon-uclibc during go build

2022-11-08 Thread 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(, 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'

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

2022-06-21 Thread 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 rust/105913] gccrs doesn't compile on 32-bit targets

2022-06-21 Thread 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.