[patch, committed] PR48602 Fix optimization issue

[patch, committed] PR48602 Fix optimization issue

[Jerry DeLisle]

Committed the following after regression testing. i will update the test case 
when I get the chance.

Jerry

Author: jvdelisle
Date: Wed Apr 20 04:18:25 2011
New Revision: 172753

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172753
Log:
2011-04-19  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

     PR libgfortran/48602
     * io/write_float.def (output_float_FMT_G): Fix reversal in conditional.
     Use asm volatile to mark temp variable, avoiding optimization errors.

Modified:
     trunk/libgfortran/ChangeLog
     trunk/libgfortran/io/write_float.def

The patch:

Index: write_float.def
===================================================================
--- write_float.def	(revision 172634)
+++ write_float.def	(working copy)
@@ -805,7 +805,8 @@

     notes: for Gw.d ,  n' ' means 4 blanks
  	  for Gw.dEe, n' ' means e+2 blanks
-	  for rounding modes adjustment, r, See Fortran F2008 10.7.5.2.2  */
+	  for rounding modes adjustment, r, See Fortran F2008 10.7.5.2.2
+	  the asm volatile is required for 32-bit x86 platforms.  */

  #define OUTPUT_FLOAT_FMT_G(x) \
  static void \
@@ -830,7 +831,7 @@
    switch (dtp->u.p.current_unit->round_status)\
      {\
        case ROUND_ZERO:\
-	r = sign_bit ? 0.0 : 1.0;\
+	r = sign_bit ? 1.0 : 0.0;\
  	break;\
        case ROUND_UP:\
  	r = 1.0;\
@@ -867,6 +868,7 @@
        mid = (low + high) / 2;\
  \
        temp = (calculate_exp_ ## x (mid - 1) * (1 - r * rexp_d));\
+      asm volatile ("" : "+m" (temp));\
  \
        if (m < temp)\
          { \

Re: [patch, committed] PR48602 Fix optimization issue

[Janne Blomqvist]

On Wed, Apr 20, 2011 at 07:31, Jerry DeLisle <jvdelisle@frontier.com> wrote:
>    Use asm volatile to mark temp variable, avoiding optimization errors.

I wonder, would it make sense to compile the entire IO library with
-fexcess-precision=standard in order to avoid further similar issues?
This would keep the code free from tricks like this patch, and not
reduce performance on targets with sane floating point (e.g. x86_64).
That being said, we do so little floating point calculations in the IO
library that I don't think the performance hit either from forcing
this var to memory or from -fexcess-precision=standard would be
noticeable.

I say IO library because for other things like some intrinsic
functions (matmul, ...) we probably don't want to reduce performance
in the name of avoiding excess precision.


-- 
Janne Blomqvist