[Bug target/114358] ICE in change_address_1, at emit-rtl.cc:2287 on m68k-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114358 --- Comment #6 from Thorsten Glaser --- Oh okay. I have no easy way to check the trunk; gcc-snapshot_1:20240117-1 failed to build (due to an ICE in libgo). In about two days, gcc-14_14-20240315-1 should be built, which I can check then, if

[Bug target/114358] ICE in change_address_1, at emit-rtl.cc:2287 on m68k-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114358 Thorsten Glaser changed: What|Removed |Added CC||tg at mirbsd dot org --- Comment #2

[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896 Thorsten Glaser changed: What|Removed |Added CC||tg at mirbsd dot org --- Comment #47

[Bug c/111398] GCC should warn if a struct with flexible array member is declared static or onstack

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111398 --- Comment #2 from Thorsten Glaser --- Right, which is why I suggested a -Wextra level option to warn about these. Thanks!

[Bug c/111398] New: GCC should warn if a struct with flexible array member is declared static or onstack

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111398 Bug ID: 111398 Summary: GCC should warn if a struct with flexible array member is declared static or onstack Product: gcc Version: unknown Status: UNCONFIRMED

[Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65 --- Comment #18 from Thorsten Glaser --- I cannot, unfortunately. But I have found _another_ “mitigation”: varsub() is static and has only one caller:

[Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65 --- Comment #17 from Thorsten Glaser --- Hm, okay, I’ll try to find if I can trigger it in glibc/x32 then…

[Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65 --- Comment #16 from Thorsten Glaser --- If I add -maddress-mode=long to the build of the expr.c file, then link it with the rest, it still fails. I’m not sure about reducing, and not sure about the cross-anything, but I *did* get it to fail

[Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65 --- Comment #13 from Thorsten Glaser --- The interesting part is around the occurrence of… # eval.c:399: sp = cstrchr(sp, '\0') + 1; … in the .s files (it occurs thrice, the first is the beginning of the setup part,

[Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65 --- Comment #12 from Thorsten Glaser --- Created attachment 55808 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55808=edit tarball (.xz) with preprocessed and assembly output I’ve verified (back to unmodified source) that it is indeed

[Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65 --- Comment #11 from Thorsten Glaser --- OK, to summarise: When using the original code but providing a wrapper function (in a separate CU) for strchr, it works. When replacing the strchr with strlen (which GCC also does), it fails even

[Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65 --- Comment #10 from Thorsten Glaser --- oh no, wait, that was for strchr… the strlen one… but, yeah, that too: extern size_t xstrlen(const char *s); and changing the line again to… sp += xstrlen(sp) + 1; …

[Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65 --- Comment #9 from Thorsten Glaser --- > Does providing your own (trivially correct) strlen implementation in a > separate CU also fix the issue? Even providing one that just calls dietlibc’s (in a separate CU) fixes the issue, so I’m very

[Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65 --- Comment #7 from Thorsten Glaser --- (but with this, I think it’s neither the GCC builtins, nor a change thereof, nor anything about dietlibc that is at fault; feel free to adjust the title accordingly) Surrounding code:

[Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65 --- Comment #6 from Thorsten Glaser --- dietlibc’s strlen is a horrid SSE nightmare that doesn’t call (f)emms, but it has a switch global variable __valgrind, if setting that to 1 it uses a very traditional loop instead, and the registers

[Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65 --- Comment #5 from Thorsten Glaser --- I managed to isolate one specific strchr call changing which causes the breakage to go away: asm volatile("nop"); //401 sp = cstrchr(sp, '\0') + 1; asm

[Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65 --- Comment #4 from Thorsten Glaser --- Its {,sig}{set,long}jmp for x32 look good.

[Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65 --- Comment #3 from Thorsten Glaser --- Not yet, given it’s been relatively clearly tracked down to a change in GCC. I’ll have at its setjmp/longjmp myself now, will report back.

[Bug target/111165] New: [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65 Bug ID: 65 Summary: [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: