[Bug target/107581] ICE on sparc-leon-uclibc during go build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107581 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.0
[Bug target/107581] ICE on sparc-leon-uclibc during go build
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107581 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #9 from Ian Lance Taylor --- Should be fixed on mainline. Thanks.
[Bug target/107581] ICE on sparc-leon-uclibc during go build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107581
--- Comment #8 from CVS Commits ---
The master branch has been updated by Ian Lance Taylor :
https://gcc.gnu.org/g:219f82070903625d6bd8865b5ecb5f944bcee871
commit r13-3868-g219f82070903625d6bd8865b5ecb5f944bcee871
Author: Ian Lance Taylor
Date: Wed Nov 9 16:05:08 2022 -0800
go: don't crash if __atomic_fetch_add functions are used
The Go frontend only generates __atomic_add_fetch, but in some cases
thost calls become __atomic_fetch_add.
Patch originally by Marc Poulhiès.
PR target/107581
* go-gcc.cc (Gcc_backend::Gcc_backend): Define
__atomic_fetch_add_{4,8}.
[Bug target/107581] ICE on sparc-leon-uclibc during go build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107581 --- Comment #7 from Ian Lance Taylor --- Interesting, thanks. The Go frontend will never emit a call to __atomic_fetch_add_4. I didn't realize that the middle end could convert __atomic_add_fetch_4 into that. Your patch looks right. I'll commit after testing.
[Bug target/107581] ICE on sparc-leon-uclibc during go build
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
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
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
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 target/107581] ICE on sparc-leon-uclibc during go build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107581
Richard Biener changed:
What|Removed |Added
Version|unknown |12.2.0
--- Comment #2 from Richard Biener ---
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
BUILT_IN_ATOMIC_FETCH_* and expand_builtin_atomic_fetch_op does
/* Change the call to the specified function. */
fndecl = get_callee_fndecl (exp);
addr = CALL_EXPR_FN (exp);
STRIP_NOPS (addr);
gcc_assert (TREE_OPERAND (addr, 0) == fndecl);
TREE_OPERAND (addr, 0) = builtin_decl_explicit (ext_call);
and this builtin_decl_explicit ends up NULL so we later crash. Adding an
assert that this isn't so after the above would confirm this. We compute
ext_call (lib) as
case BUILT_IN_ATOMIC_ADD_FETCH_1:
case BUILT_IN_ATOMIC_ADD_FETCH_2:
case BUILT_IN_ATOMIC_ADD_FETCH_4:
case BUILT_IN_ATOMIC_ADD_FETCH_8:
case BUILT_IN_ATOMIC_ADD_FETCH_16:
{
enum built_in_function lib;
mode = get_builtin_sync_mode (fcode - BUILT_IN_ATOMIC_ADD_FETCH_1);
lib = (enum built_in_function)((int)BUILT_IN_ATOMIC_FETCH_ADD_1 +
(fcode - BUILT_IN_ATOMIC_ADD_FETCH_1));
target = expand_builtin_atomic_fetch_op (mode, exp, target, PLUS, true,
ignore, lib);
as said, tracing exactly what fcode and lib is here would be useful.
Eventually this is a frontend issue, not properly initializing the builtins.
[Bug target/107581] ICE on sparc-leon-uclibc during go build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107581 Ian Lance Taylor changed: What|Removed |Added CC||ian at airs dot com --- Comment #1 from Ian Lance Taylor --- 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.
