https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103646
Siddhesh Poyarekar <siddhesh at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
--- Comment #2 from Siddhesh Poyarekar <siddhesh at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #1)
> The driver does what it has been configured to.
> The default for x86_64-linux compiler is x86-64 arch even for 32-bit code,
> Fedora GCC is configured with --with-arch_32=i686 and therefore it defaults
> to -march=i686.
> I don't really see a bug here.
Right, sorry, I think I went off-track. I saw it in the Fedora build failure
but lost track when I tried to reduce the reproducer in a local build.
> With -O0 the testcase is rejected with either -march=i686 or -march=x86-64,
> similarly with -O0 -mstackrealign, with -O2 it is accepted for both, with
> -O2 -mstackrealign only for i686; all this depends on whether frame pointer
> is used or not. The reason why x86-64 rejects it and i686 doesn't in the
> last case is
> SLP vectorization of the
> t->tv_sec = 0;
> t->tv_usec = 1;
> stores, due to that we actually want to realign in the prologue and that
> results in %ebp being used as frame pointer and so can't be used in the
> local register variable.
> -mno-sse or -fno-tree-vectorize will make it compile.
The ebp use in glibc is to inline 6 argument syscalls. It looks like the
assumption in configure is that only -fno-omit-frame-pointer (or other compile
flags that fail a trivial program with asm("ebp")) will cause similar failures
in the build. With the vectorizer in play and the above semantics, it doesn't
seem like a reliable thing to do in gcc 12; the choice would be to either
sacrifice vectorization or 6 argument syscall inlining.
Either way it's a question for glibc, I'll take it there. Thanks for helping
me see this clearer.
