https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91102
--- Comment #6 from Stefan Kneifel ---
It seems to fix the bug - at least the original problem (ICE during compiling
Linux kernel for aarch64 with -Os) is solved by this patch.
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: stefan.kneifel at bluewin dot ch
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Host: x86_64
Target: x86_64, aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106696
Stefan Kneifel changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #2 from Stefan Kneif
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: stefan.kneifel at bluewin dot ch
Target Milestone: ---
__builtin_cpu_supports is supposed to return a positive integer if the run-time
CPU supports the requested feature and zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103661
--- Comment #3 from Stefan Kneifel ---
Created attachment 51975
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51975&action=edit
First try of a patch, making it unsigned (and correcting the resolver
generator)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103661
--- Comment #4 from Stefan Kneifel ---
Created attachment 51978
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51978&action=edit
Testcase
Without the proposed patch, it compiles to:
:
0: 50
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: stefan.kneifel at bluewin dot ch
Target Milestone: ---
Created attachment 51243
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51243&action=edit
Testcase: compile with -Os -fPI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101726
--- Comment #2 from Stefan Kneifel ---
OK, so declaring the default function as local might make gcc assume that the
function body is available in the same translation unit, thus rendering the
relocation locally resolvable.
Thus said, I tried
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101726
--- Comment #4 from Stefan Kneifel ---
Yes, but a programmer might choose to implement target clones for a shared
library using another language, e.g. hand-optimized assembler code (this was
the actual problem I had).
Forbidding target_clone de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101726
--- Comment #7 from Stefan Kneifel ---
OK works for me, thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120011
--- Comment #13 from Stefan Kneifel ---
Correct, -R'ing this patch against 15.1.1 sources reverses the regression.
: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: stefan.kneifel at bluewin dot ch
Target Milestone: ---
Regression 15.1.1 against 15.0:
When compiling gcc itself using -march=x86-64-v4, it stops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120011
--- Comment #2 from Stefan Kneifel ---
Created attachment 61243
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61243&action=edit
creduced addtf3.c from libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120011
--- Comment #8 from Stefan Kneifel ---
It was the version shipped with Fedora 42 Release:
https://dl.fedoraproject.org/pub/fedora/linux/releases/42/Everything/source/tree/Packages/g/gcc-15.0.1-0.11.fc42.src.rpm
Regards, Stefan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120011
--- Comment #4 from Stefan Kneifel ---
Oh I see that the error occurs only if one of the size optimization options
(-Os,-Oz) is active:
[64 bit environment]
gcc -Os -pipe -c addtf3.c works
gcc -Os -pipe -c addtf3.c -mar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120011
--- Comment #9 from Stefan Kneifel ---
Hongtao Liu's patch mentioned in Comment 1 does NOT retract the regression.
16 matches
Mail list logo
