https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121652
--- Comment #22 from Aurelien Jarno ---
I have posted a patch to the gcc-patches mailing-list:
https://gcc.gnu.org/pipermail/gcc-patches/2025-September/696217.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121652
--- Comment #18 from Aurelien Jarno ---
Created attachment 62345
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=62345&action=edit
Patch / Proof of concept
In case we want to keep the condition unchanged, here is a patch to correctly
handl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121652
--- Comment #17 from Aurelien Jarno ---
(In reply to Jeffrey A. Law from comment #16)
> WRT c#13, yes, it's worth it, the performance gains were huge. Of course if
> we look out Zfa should become ubiquitious and that other path won't matter.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121652
--- Comment #15 from Aurelien Jarno ---
(In reply to Xi Ruoyao from comment #14)
> (In reply to Aurelien Jarno from comment #13)
> > I am starting to wonder if it is really worth inlining so much code compared
> > to a call to round(), and if it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121652
--- Comment #13 from Aurelien Jarno ---
I am starting to wonder if it is really worth inlining so much code compared to
a call to round(), and if it is not better to not try to handle NaN and fflags,
requiring both !flag_trapping_math and flag_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121652
--- Comment #11 from Aurelien Jarno ---
(In reply to Vineet Gupta from comment #4)
> Also I'm thinking to model this based on existing libc implementation which
> has been around for a while and should hopefully be correct.
>
> What glibc does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121652
--- Comment #12 from Aurelien Jarno ---
(In reply to Aurelien Jarno from comment #11)
> At the end it seems the GLIBC round code is correct and widely tested, so we
> just want to mimic it in the builtin.
The same way the comments in the GCC co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121534
Aurelien Jarno changed:
What|Removed |Added
CC||aurelien at aurel32 dot net
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117460
Bug ID: 117460
Summary: riscv64 backend emits large relocations due to loop
strength reduction
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066
--- Comment #25 from Aurelien Jarno ---
(In reply to Andrew Pinski from comment #23)
> Fixed on the trunk will backport to GCC 13 after 13.2.0 is released (since
> the branch is frozen except for RM approvals).
Now that GCC 13.2.0 has been rele
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110755
--- Comment #10 from Aurelien Jarno ---
(In reply to Jakub Jelinek from comment #9)
> Created attachment 55616 [details]
> gcc14-pr110755.patch
>
> Updated patch.
Thanks. I have just tested it, and I confirm it fixes the reported issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110755
--- Comment #7 from Aurelien Jarno ---
(In reply to Jakub Jelinek from comment #6)
> Created attachment 55594 [details]
> gcc14-pr110755.patch
>
> Untested patch.
Thanks for the patch, I confirm it works as expected, now the result is a
positi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066
--- Comment #18 from Aurelien Jarno ---
(In reply to Andreas Schwab from comment #17)
> I don't think you need -fno-omit-frame-pointer.
I confirm that CRTSTUFF_T_CFLAGS += -fno-asynchronous-unwind-tables
-fno-unwind-tables is enough to fix the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066
--- Comment #15 from Aurelien Jarno ---
(In reply to Andrew Pinski from comment #14)
> Created attachment 55614 [details]
> patch for someone to test out
>
> The problem is the similar across many targets so I basically copied what
> was done f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066
--- Comment #12 from Aurelien Jarno ---
Backtrace with debug symbols in libgcc_eh.a:
Program received signal SIGSEGV, Segmentation fault.
classify_object_over_fdes (ob=0xe2da0 , this_fde=0x1000530e6,
range=0x3ff310) at ../../../gcc/libgcc/u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066
--- Comment #11 from Aurelien Jarno ---
I have bisected the issue, and I found it has been introduced by the following
commit:
commit 3cd08f7168c196d7a481b9ed9f4289fd1f14eea8
Author: Andreas Schwab
Date: Wed Jan 25 12:00:09 2023 +0100
r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066
--- Comment #10 from Aurelien Jarno ---
(In reply to Aurelien Jarno from comment #9)
> (In reply to Andrew Pinski from comment #5)
> > Can you try reverting r13-923-g2d546ff69455f7deadab and try GCC 13 again?
>
> Yep, I'll do that, but it will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066
--- Comment #9 from Aurelien Jarno ---
(In reply to Andrew Pinski from comment #5)
> Can you try reverting r13-923-g2d546ff69455f7deadab and try GCC 13 again?
Yep, I'll do that, but it will probably take some time to get the results.
(In reply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066
--- Comment #8 from Aurelien Jarno ---
Created attachment 55610
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55610&action=edit
crtbeginT.o GCC 12 version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066
--- Comment #7 from Aurelien Jarno ---
Created attachment 55609
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55609&action=edit
crtbeginT.o GCC 12 version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066
Aurelien Jarno changed:
What|Removed |Added
CC||aurelien at aurel32 dot net
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110755
--- Comment #2 from Aurelien Jarno ---
(In reply to Andrew Pinski from comment #1)
> Hmm, this might be the case where you need -frounding-math since we don't
> expectly implement the pragma.
Indeed the original glibc code is compiled with -fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110755
Bug ID: 110755
Summary: Wrong optimization of fabs on ppc64el at -O1
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104338
--- Comment #18 from Aurelien Jarno ---
Thanks Patrick for working on that and for the backport to the gcc-13 branch. I
wonder if the following patch should also be backported, as it doesn't make
sense to link with -latomic anymore with inline s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104338
Aurelien Jarno changed:
What|Removed |Added
CC||aurelien at aurel32 dot net
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103874
--- Comment #11 from Aurelien Jarno ---
Thanks for the patch! I confirm the issue is fixed on the trunk. I also tried
to apply it on the GCC 11 branch (which is basically renaming dwarf2out.cc into
dwarf2out.c in the patch) and this also works f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103874
Aurelien Jarno changed:
What|Removed |Added
CC||jakub at redhat dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103874
--- Comment #4 from Aurelien Jarno ---
This is a better backtrace after building a riscv64 cross compiler from the
releases/gcc-11 branch:
/tmp/onnxifi_loader.c.i:6:1: internal compiler error: Segmentation fault
6 | }
| ^
0xadad0f cra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103874
--- Comment #3 from Aurelien Jarno ---
I have been able to reduce the reproducer code to almost nothing, so I guess
the issue is mostly related to the options and not to the source code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103874
Aurelien Jarno changed:
What|Removed |Added
Attachment #52099|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103874
--- Comment #1 from Aurelien Jarno ---
Sorry I submitted the bug by mistake without filling a comment.
pytorch failed to build in Debian on riscv64 following the switch to GCC 11 by
default:
https://buildd.debian.org/status/fetch.php?pkg=pytorc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103874
Bug ID: 103874
Summary: [11/12 Regression] ICE in internal_error on riscv64
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
32 matches
Mail list logo
