https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68524
Thorsten Glaser changed:
What|Removed |Added
CC||tg at mirbsd dot org
--- Comment #5 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65
--- Comment #25 from Thorsten Glaser ---
Good as I can tell, __valgrind is always 1, at least when looking at it in gdb…
I even had to add -ffreestanding because it otherwise triggered an optimisation
to transform the loop into a call to strlen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65
--- Comment #21 from Thorsten Glaser ---
… reverting that precise workaround FIXES the bug with GCC 14 🤯
Something deep inside must be buggy, and the triggering with this only an
accident.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65
--- Comment #20 from Thorsten Glaser ---
I would like some assistance in debugging this further. I had been able to work
around this by…
-static int varsub(Expand *, const char *, const char *, unsigned int *, int
*);
+static int varsub(Expand
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 that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114358
Thorsten Glaser changed:
What|Removed |Added
CC||tg at mirbsd dot org
--- Comment #2 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
Thorsten Glaser changed:
What|Removed |Added
CC||tg at mirbsd dot org
--- Comment #47
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!
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
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:
https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=alioth/mksh.git;a=blob;f=eval.c;h=cb9
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…
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 on
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, t
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&action=edit
tarball (.xz) with preprocessed and assembly output
I’ve verified (back to unmodified source) that it is in
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
withou
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;
… an
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 su
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:
https://evolvis.org/
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 before
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 volatile("no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65
--- Comment #4 from Thorsten Glaser ---
Its {,sig}{set,long}jmp for x32 look good.
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.
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: norma
23 matches
Mail list logo
