https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111165
Uroš Bizjak <ubizjak at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hjl.tools at gmail dot com
--- Comment #14 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Thorsten Glaser from comment #13)
> 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, the second and third surround the strlen call, so they’re all within a
> bunch of lines).
Unfortunately, the runtime bug requires test that fails at runtime; the
attached dumps are not that usable. The fact that the compiler fails for not so
common target makes things even harder.
I think that the best way forward is to create a minimized standalone testcase
(From Comment #11 it looks that the issue is independent of dietlibc) that can
be compiled with -mx32 in a kind of cross-compiler fashion. You can use
-maddress-mode=long with -mx32 to create a .s assembly file that is compatible
with x86_64, as far as stack handling is concerned.
The resulting .s assembly can then be compiled and linked with a C wrapper, so
a testcase that eventually fails on x86_64 can be produced.
IOW, does the testcase fail when -maddress-mode=long is used?
