This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Add volatiles for x86-64 bits/mathinline.h

> As mentioned previously today, lrintf fails for me with gcc 4.7. The
> resolution in bugzilla suggests to add volatiles, here's a patch to do
> so. I will in a separate patch add checks for specific gcc versions so
> that we use the gcc builtins.

I had to read the GCC bugzilla to figure out what this was about.
Since those asms do have output parameters, volatile doesn't seem
like it would be required.  In fact, I'm still not convinced that
is the best fix.  If it is, it certainly requires comments explaining
why those volatiles are there.

AIUI the issue is that these asms depend on the state of the fpsr, but the
compiler doesn't know that and so eliminates a second instance after an
fpsr change as redundant with the first.  So what would be really right is
to tell the compiler that the fpsr is an input to these asms and an output
of the mode-changing code.  

There may be no direct way to do that if the compiler doesn't know about
fpsr as a register name (since it's not really a register).  But perhaps
it could be done by some fakery.  Declare a global variable __fpsr or
somesuch, and then make that an input/output parameter of the asms that
are affected by or change the fpsr.  Then the compiler is free to
eliminate the asms if their outputs are dead, or reorder them relative
to unrelated 'asm volatile's, etc.

If that is a lot of trouble and all the affected code is going away
entirely for new-enough GCC versions, then it might not be worth the
effort.  But no matter what, thorough comments are required.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]