https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
--- Comment #17 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Paul Eggert from comment #16)
> (In reply to Richard Biener from comment #13)
> > Paul - can you test if this patch resolves the emacs issue?
>
> Unfortunately not. Although the generated code differs, it's still the same
> bad pattern. GDB's command 'disas decode_lisp_time' reports this:
>
> ...
> 0x082a924c <+876>: call 0x82a8140 <decode_ticks_hz>
>
> => 0x082a9251 <+881>: fldl 0x8c(%esp)
>
> 0x082a9258 <+888>: add $0x10,%esp
>
> 0x082a925b <+891>: fstpl 0x7c(%esp)
> ...
>
> where the 8-byte quantity being copied comes from the leading bytes of this
> union:
>
> union c_time
> {
> struct ticks_hz { long long ticks; long long hz; } th;
> struct timespec ts;
> double d;
> };
>
> and this union happens to contain th (of type struct ticks_hz) not d (of
> type double).
I suppose this happens even when building without LTO, so can you please
attach preprocessed source of the TU containing decode_lisp_time
(preprocessed with all the flags used when the issue appears)? Maybe
it's really a duplicate of one of the related bugs (my patch didn't fix
all of them).
