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 test
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...
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116339
Marc Poulhiès changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Summary|arm-unkn
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
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!
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
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 f
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359
--- Comment #33 from Marc Poulhiès ---
No worries, we've applied it locally.
Thanks!
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
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.
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
---
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.or
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
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
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?
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.
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
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 b
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
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.c
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:
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110314
Marc Poulhiès changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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 f
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
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`.
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?
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
[
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)!
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
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
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.
>
>
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
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108113
Marc Poulhiès changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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 app
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 Inpu
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
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
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 f
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 observ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107581
--- Comment #10 from Marc Poulhiès ---
Thanks for applying the fix Ian!
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 defin
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
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_ATOM
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
> th
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
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 !
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.
50 matches
Mail list logo
