https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114910
Andrew Pinski changed:
What|Removed |Added
CC||joel at gcc dot gnu.org
--- Comment #12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114910
--- Comment #11 from Chris Packham ---
After working around things by not passing --enable-target-optspace I end up
getting an ICE later in the toolchain build.
[ALL ]during RTL pass: mach
[ALL ]
/home/ctng/crosstool-ng/.build/tic6x-el
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114910
Andrew Pinski changed:
What|Removed |Added
CC||judge.packham at gmail dot com
--- Comm
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 #8 from Mikael Pettersson ---
According to my git bisect, the assembler error started with
551935d11817dd5b139d66c36f62c0f0eba0db06 is the first new commit
commit 551935d11817dd5b139d66c36f62c0f0eba0db06
Author: Alexandre Oliva
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114910
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
--- Com
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 #5 from Mikael Pettersson ---
I don't use crosstool-ng, but I have no problems building a cross to
c6x-unknown-elf with binutils-2.42, gcc-14.1.0-RC-20240430, and
newlib-4.4.0.20231231. (A cross to c6x-unknown-uclibc with uclibc-ng-1
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
--- Comment #3 from Andrew Pinski ---
LVL labels comes from the debugging info when it comes to variable tracking.
This looks like it has always been broken ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114910
--- Comment #2 from Andrew Pinski ---
C6x Linux support was removed in 2021:
https://lore.kernel.org/linux-arm-kernel/20210120124812.2800027-1-a...@kernel.org/T/
So maybe it is time to remove it from GCC too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114910
--- Comment #1 from Andrew Pinski ---
The only thing hardcfr.c uses special is __builtin_return_address and
__builtin_trap otherwise it is just normal C code ...
12 matches
Mail list logo
