[Bug fortran/48426] New: [patch] Quad precision promotion

[Bug fortran/48426] New: [patch] Quad precision promotion

[inform at tiker dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48426

           Summary: [patch] Quad precision promotion
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: inform@tiker.net


The attached patch implements the options

-finteger4-integer-8
-freal-4-real-8
-freal-4-real-10
-freal-4-real-16
-freal-8-real-4
-freal-8-real-10
-freal-8-real-16

to implement a variety of automatic type promotions. (This is particularly
helpful if one wants to quickly check whether a certain code has a bug limiting
its precision away from full machine accuracy.)

A similar promotion feature is available in Fujitsu compilers, see here:

http://www.lahey.com/docs/fujitsu%20compiler%20option%20list.pdf

(e.g. -CcR8R16)

I submitted this patch before, but it seems to have gotten lost in Bugzilla.
The implementation work on this was done by Zydrunas Gimbutas, not by me.
Zydrunas has authorized me to submit this for inclusion in gcc.

[Bug fortran/48426] [patch] Quad precision promotion

[inform at tiker dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48426

--- Comment #1 from Andreas Kloeckner <inform at tiker dot net> 2011-04-03 18:05:10 UTC ---
Created attachment 23859
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23859
patch v1

[Bug fortran/48426] [patch] Quad precision promotion

[kargl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48426

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org 2011-04-03 19:25:39 UTC ---
There is already -fdefault-real-8, -fdefault-integer-8, and
-fdefault-double-8.  This is already 3 too many hacks.  Adding
an additional 7 options is 7 too many.

[Bug fortran/48426] [patch] Quad precision promotion

[inform at tiker dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48426

--- Comment #3 from Andreas Kloeckner <inform at tiker dot net> 2011-04-03 19:49:51 UTC ---
(In reply to comment #2)
> There is already -fdefault-real-8, -fdefault-integer-8, and
> -fdefault-double-8.  This is already 3 too many hacks.  Adding
> an additional 7 options is 7 too many.

>From a purist perspective, I absolutely gree with you. Practically however, 
in dealing with legacy codes (*), the value of being able to do this should not
be underestimated. If this was a useless thing to do, why would Lahey/Fujitsu
have included these flags?

(*) Let's face it, a big part of Fortran's relevance stems from legacy codes.

(As an anecdote, I once worked at an unnamed US national lab, and one of my
group's main reasons *against* adoption of g77 was the absence of
-fdefault-real-8.)

Re: [Bug fortran/48426] [patch] Quad precision promotion

[Jerry DeLisle]

On 04/03/2011 12:49 PM, inform at tiker dot net wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48426
>
> --- Comment #3 from Andreas Kloeckner<inform at tiker dot net>  2011-04-03 19:49:51 UTC ---
> (In reply to comment #2)
>> There is already -fdefault-real-8, -fdefault-integer-8, and
>> -fdefault-double-8.  This is already 3 too many hacks.  Adding
>> an additional 7 options is 7 too many.
>
>> From a purist perspective, I absolutely gree with you. Practically however,
> in dealing with legacy codes (*), the value of being able to do this should not
> be underestimated. If this was a useless thing to do, why would Lahey/Fujitsu
> have included these flags?
>

Lets take another perspective, different than Steve's comments. Lets assume 
no-one is blindly using the legacy codes with changes in default kinds without 
at least some understanding of the code and knowing what it is doing.  With 
modern editors or scripts, one could modify declarations to use a 
kind=parameter.  This could be done to change REAL to REAL(kind=wp). wp meaning 
working precision.  One could also update real constants to append _wp to them. 
  Then add a use statement at the beginning of each file that sets wp. Several 
different precision parameters could be set up and used in varying places 
depending on the application.  One gets a finer degree of control.

Now I have presented a simplistic example and I am sure the real code may offer 
some additional challenges. But, the net result would be more flexible code that 
is more portable and the original issue becomes moot.

If ones knowledge of the code is greater then mine it is likely one could see 
more opportunities for improving it with simple changes like this, especially in 
the code that is critical to the issue.  Once the changes are made, perhaps even 
incrementally over time in small parts, they never have to be changed back, 
because the code is standard conforming to do so.

Now, we can make arguments to go in either direction; put the burden of 
resolving the issue on the compiler team or put the burden on the 
user/developers.  I think Steve is saying that we have an obligation on the 
compiler side to protect users who may not be as knowledgeable/experienced from 
doing stupid things, whereas someone such as yourself would probably know what 
to be careful of and could avoid it. Providing the adjustable precision on the 
user/developer side assures that it is done carefully and correctly, specific to 
the application.

Now the flip side is that the less than 100 lines of code patch on the compiler 
side is a lot less effort then perhaps updating the 100,000 lines of legacy 
code. However, the compiler changes affect thousands of users and thousands of 
applications.  That means there is, lets say, 1000 times more risk to the change 
on the compiler side.  (With no warranty of course).

I am leaning toward we need to err on the conservative side, and let others 
comment from here. We have had these discussions on this topic many times 
before. I don't think there is an easy answer.  My personal preference would be 
to update the user code. (aka software maintenance).

Regards

[Bug fortran/48426] [patch] Quad precision promotion

[sgk at troutmask dot apl.washington.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48426

--- Comment #4 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2011-04-03 20:33:12 UTC ---
On Sun, Apr 03, 2011 at 07:49:53PM +0000, inform at tiker dot net wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48426
> 
> --- Comment #3 from Andreas Kloeckner <inform at tiker dot net> 2011-04-03 19:49:51 UTC ---
> (In reply to comment #2)
> > There is already -fdefault-real-8, -fdefault-integer-8, and
> > -fdefault-double-8.  This is already 3 too many hacks.  Adding
> > an additional 7 options is 7 too many.
> 
> From a purist perspective, I absolutely gree with you. Practically
> however, in dealing with legacy codes (*), the value of being able
> to do this should not be underestimated.  If this was a useless thing
> to do, why would Lahey/Fujitsu have included these flags?
> 
> (*) Let's face it, a big part of Fortran's relevance stems from legacy codes.

This is the number one reason why these options (including the
current 3 [1]) should not be available in any compiler.  Few people
use these types of options for debugging.  Most have a single
precision algorithm, but want a double (or higher) precision
routine.  Instead of actually trying to understand and implement
a proper double (or higher) precision version, people simply use
these types of options without checking the robustness of the 
algorithm.

In glancing at the patch, there are at least two problems.  First,
this chunk 

+  else if (saw_i8 && gfc_option.flag_integer4_kind == 8 )
+    {
+      gfc_default_integer_kind = 8;
+
+      /* Even if the user specified that the default integer kind be 8,
+         the numeric storage size isn't 64.  In this case, a warning will
+     be issued when NUMERIC_STORAGE_SIZE is used.  */
+      gfc_numeric_storage_size = 4 * 8;
+    }

is simply a bad idea.  If one changes gfc_default_integer_kind to 8,
then the numeric storage size should be updated to 8 * 8.  I suspect
(but haven't checked) that the above breaks not only EQUIVALENCE
and COMMON but several assumptions within libgfortran.  Second, 
this chunk 

+  if (ts->type == BT_REAL || ts->type == BT_COMPLEX)
+    {
+      if( ts->kind == 4 && gfc_option.flag_real4_kind ==  8) ts->kind =  8;
+      if( ts->kind == 4 && gfc_option.flag_real4_kind == 10) ts->kind = 10;
+      if( ts->kind == 4 && gfc_option.flag_real4_kind == 16) ts->kind = 16;
+      if( ts->kind == 8 && gfc_option.flag_real8_kind ==  4) ts->kind =  4;
+      if( ts->kind == 8 && gfc_option.flag_real8_kind == 10) ts->kind = 10;
+      if( ts->kind == 8 && gfc_option.flag_real8_kind == 16) ts->kind = 16;

appears to assume that ts->kind=10 and ts->kind=16 are available. 
This may or may not be true depending on the target and the options
used during execution of configure.  One needs to check if 10 and 16
are available.  

> (As an anecdote, I once worked at an unnamed US national lab, and one of my
> group's main reasons *against* adoption of g77 was the absence of
> -fdefault-real-8.)

Hopefully, the unnamed national lab wasn't using options like these 
with critical software without actually checking the robustness of 
the code.

[1] I'm the person who did the initial clean-up of the poorly implemented
-r8, -i8, and -d8 options (See ChangLog-2005).  Others after me fixed my
fixes.  In rectrospect, I wish I had simply removed these options
because the options probably do not do what a user thinks.

[Bug fortran/48426] [patch] Quad precision promotion

[jvdelisle at frontier dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48426

--- Comment #5 from jvdelisle at frontier dot com 2011-04-03 21:14:41 UTC ---
On 04/03/2011 12:49 PM, inform at tiker dot net wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48426
>
> --- Comment #3 from Andreas Kloeckner<inform at tiker dot net>  2011-04-03 19:49:51 UTC ---
> (In reply to comment #2)
>> There is already -fdefault-real-8, -fdefault-integer-8, and
>> -fdefault-double-8.  This is already 3 too many hacks.  Adding
>> an additional 7 options is 7 too many.
>
>> From a purist perspective, I absolutely gree with you. Practically however,
> in dealing with legacy codes (*), the value of being able to do this should not
> be underestimated. If this was a useless thing to do, why would Lahey/Fujitsu
> have included these flags?
>

Lets take another perspective, different than Steve's comments. Lets assume 
no-one is blindly using the legacy codes with changes in default kinds without 
at least some understanding of the code and knowing what it is doing.  With 
modern editors or scripts, one could modify declarations to use a 
kind=parameter.  This could be done to change REAL to REAL(kind=wp). wp meaning 
working precision.  One could also update real constants to append _wp to them. 
  Then add a use statement at the beginning of each file that sets wp. Several 
different precision parameters could be set up and used in varying places 
depending on the application.  One gets a finer degree of control.

Now I have presented a simplistic example and I am sure the real code may offer 
some additional challenges. But, the net result would be more flexible code
that 
is more portable and the original issue becomes moot.

If ones knowledge of the code is greater then mine it is likely one could see 
more opportunities for improving it with simple changes like this, especially
in 
the code that is critical to the issue.  Once the changes are made, perhaps
even 
incrementally over time in small parts, they never have to be changed back, 
because the code is standard conforming to do so.

Now, we can make arguments to go in either direction; put the burden of 
resolving the issue on the compiler team or put the burden on the 
user/developers.  I think Steve is saying that we have an obligation on the 
compiler side to protect users who may not be as knowledgeable/experienced from 
doing stupid things, whereas someone such as yourself would probably know what 
to be careful of and could avoid it. Providing the adjustable precision on the 
user/developer side assures that it is done carefully and correctly, specific
to 
the application.

Now the flip side is that the less than 100 lines of code patch on the compiler 
side is a lot less effort then perhaps updating the 100,000 lines of legacy 
code. However, the compiler changes affect thousands of users and thousands of 
applications.  That means there is, lets say, 1000 times more risk to the
change 
on the compiler side.  (With no warranty of course).

I am leaning toward we need to err on the conservative side, and let others 
comment from here. We have had these discussions on this topic many times 
before. I don't think there is an easy answer.  My personal preference would be 
to update the user code. (aka software maintenance).

Regards

[Bug fortran/48426] [patch] Quad precision promotion

[inform at tiker dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48426

--- Comment #6 from Andreas Kloeckner <inform at tiker dot net> 2011-04-05 02:12:33 UTC ---
(In reply to comment #4)
> On Sun, Apr 03, 2011 at 07:49:53PM +0000, inform at tiker dot net wrote:
> This is the number one reason why these options (including the
> current 3 [1]) should not be available in any compiler. Few people
> use these types of options for debugging.  Most have a single
> precision algorithm, but want a double (or higher) precision
> routine.  Instead of actually trying to understand and implement
> a proper double (or higher) precision version, people simply use
> these types of options without checking the robustness of the 
> algorithm.

First, some use of type promotion is--at least to some extent--legitimate. If
you would like to use a certain piece of code in single and double precision
and maintain compatibility with pure F77, then having the compiler able to
rewrite your code is a useful thing to have available. Second, as I explained,
there are uses of this in debugging. Obviously, maintaining multiple versions
of the source code is not really an option in this case especially. To
reiterate, the practical use of these flags should not be underestimated.

Further, trying to convince users by not implementing this feature will simply
drive them away from free tools. The need exists.

> In glancing at the patch, there are at least two problems.  First,
> this chunk 
> 
> +  else if (saw_i8 && gfc_option.flag_integer4_kind == 8 )
> +    {
> +      gfc_default_integer_kind = 8;
> +
> +      /* Even if the user specified that the default integer kind be 8,
> +         the numeric storage size isn't 64.  In this case, a warning will
> +     be issued when NUMERIC_STORAGE_SIZE is used.  */
> +      gfc_numeric_storage_size = 4 * 8;
> +    }
> 
> is simply a bad idea.

This just imitates the behavior of -fdefault-integer-8, whose treatment is
right directly above this snippet. So if our code is broken, so is the code for
the existing flag.

> Second, this chunk 
> 
> +  if (ts->type == BT_REAL || ts->type == BT_COMPLEX)
> +    {
> +      if( ts->kind == 4 && gfc_option.flag_real4_kind ==  8) ts->kind =  8;
> +      if( ts->kind == 4 && gfc_option.flag_real4_kind == 10) ts->kind = 10;
> +      if( ts->kind == 4 && gfc_option.flag_real4_kind == 16) ts->kind = 16;
> +      if( ts->kind == 8 && gfc_option.flag_real8_kind ==  4) ts->kind =  4;
> +      if( ts->kind == 8 && gfc_option.flag_real8_kind == 10) ts->kind = 10;
> +      if( ts->kind == 8 && gfc_option.flag_real8_kind == 16) ts->kind = 16;
> 
> appears to assume that ts->kind=10 and ts->kind=16 are available. 
> This may or may not be true depending on the target and the options
> used during execution of configure.  One needs to check if 10 and 16
> are available.

Fixed in an updated version of the patch.

[Bug fortran/48426] [patch] Quad precision promotion

[inform at tiker dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48426

Andreas Kloeckner <inform at tiker dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #23859|0                           |1
        is obsolete|                            |

--- Comment #7 from Andreas Kloeckner <inform at tiker dot net> 2011-04-05 02:13:54 UTC ---
Created attachment 23876
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23876
patch v2

[Bug fortran/48426] [patch] Quad precision promotion

[inform at tiker dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48426

--- Comment #8 from Andreas Kloeckner <inform at tiker dot net> 2011-04-15 14:53:52 UTC ---
Ping?

[Bug fortran/48426] [patch] Quad precision promotion

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48426

Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2011.04.15 15:27:59
                 CC|                            |jvdelisle at gcc dot
                   |                            |gnu.org
         AssignedTo|unassigned at gcc dot       |jvdelisle at gcc dot
                   |gnu.org                     |gnu.org
     Ever Confirmed|0                           |1

--- Comment #9 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-04-15 15:27:59 UTC ---
I have looked over the patch.  I need to do some tests and I have about three
bugs in front of this one so please give me a few days.

[Bug fortran/48426] [patch] Quad precision promotion

[sgk at troutmask dot apl.washington.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48426

--- Comment #10 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2011-04-15 16:02:17 UTC ---
On Fri, Apr 15, 2011 at 03:29:36PM +0000, jvdelisle at gcc dot gnu.org wrote:
> 
> I have looked over the patch.  I need to do some tests and I have about three
> bugs in front of this one so please give me a few days.
> 

I skimmed the patch.  It is still wrong.

These parts should not be needed:

+    if (!saw_r8)
+      fatal_error ("real kind=8 not available for -freal-4-real-8 option");

+    if (!saw_r4)
+      fatal_error ("real kind=4 not available for -freal-8-real-4 option");

gfortran always has real(4) and real(8) on all important targets.

I also think that the description is the manual is lacking.  For example,

+freal-4-real-8
+Fortran RejectNegative
+Interpret any 4-byte real as an 8-byte real

I think the word 'any' is incorrect.

There also should be a warning here.  "Warning: This option is provided
for debugging purposes, and may give unexpected results for general
use."

[Bug fortran/48426] [patch] Quad precision promotion

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48426

--- Comment #11 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-04-15 16:40:58 UTC ---
Steve, I can clean this up but i am not clear on copyright assignment.  Any
issues on this?

[Bug fortran/48426] [patch] Quad precision promotion

[sgk at troutmask dot apl.washington.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48426

--- Comment #12 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2011-04-15 16:59:41 UTC ---
On Fri, Apr 15, 2011 at 04:41:06PM +0000, jvdelisle at gcc dot gnu.org wrote:
> Steve, I can clean this up but i am not clear on copyright assignment.  Any
> issues on this?

The patch touches several files and more than a few lines,
so I think it may exceed the threshold of a patch without
copyright assignment.  We should probably check with  
Andreas Kloeckner if he has an assignment on file. 

Note, the manual changes to add a warning is needed because
these options effective storage association, which has an impact
on EQUIVALENCE and COMMON and perhaps others.

[Bug fortran/48426] [patch] Quad precision promotion

[inform at tiker dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48426

--- Comment #13 from Andreas Kloeckner <inform at tiker dot net> 2011-04-15 19:46:45 UTC ---
Just requested the assignment forms. I'll let you know when we've returned
them.

[Bug fortran/48426] [patch] Quad precision promotion

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48426

--- Comment #14 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-04-15 20:30:44 UTC ---
Super! If you have not already figured it out.  We are really short on help.

[Bug fortran/48426] [patch] Quad precision promotion

[inform at tiker dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48426

--- Comment #15 from Andreas Kloeckner <inform at tiker dot net> 2011-11-07 19:25:32 UTC ---
Zydrunas and I have successfully completed the copyright assignment process,
and we're ready to move forward with this patch.

[Bug fortran/48426] [patch] Quad precision promotion

[sgk at troutmask dot apl.washington.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48426

--- Comment #16 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2011-11-07 19:49:39 UTC ---
On Mon, Nov 07, 2011 at 07:25:32PM +0000, inform at tiker dot net wrote:
> --- Comment #15 from Andreas Kloeckner <inform at tiker dot net> 2011-11-07 19:25:32 UTC ---
> Zydrunas and I have successfully completed the copyright assignment process,
> and we're ready to move forward with this patch.
> 

Andreas, that's good news.  If you are unaware of the 
submission policies, here's a short list:

1) Use 'svn diff > somefile.diff' to create the patch.
   The diff format should be unidiff (if possible).

2) Write ChangeLog entries.  The ones you may need to worry
   about are gcc/fortran/ChangeLog, gcc/libgfortran/ChangeLog,
   and gcc/testsuite/gfortran.dg/ChangeLog.  The ChangeLog
   entries should be separate from the diff.

3) Send the diff, ChangeLog entries, and a description of
   why and what you have done and how you tested the change
   to fortran@ and gcc-patches@gcc.gnu.org.

[Bug fortran/48426] [patch] Quad precision promotion

[inform at tiker dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48426

--- Comment #17 from Andreas Kloeckner <inform at tiker dot net> 2011-11-10 00:12:58 UTC ---
Done.

Andreas

[Bug fortran/48426] [patch] Quad precision promotion

[kargl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48426

--- Comment #18 from kargl at gcc dot gnu.org 2012-01-16 18:22:20 UTC ---
Author: kargl
Date: Mon Jan 16 18:22:16 2012
New Revision: 183217

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183217
Log:
2012-01-16  Zydrunas Gimbutas  <gimbutas@cims.nyu.edu>
        Andreas Kloeckner  <kloeckner@cims.nyu.edu>
        Steven G. Kargl  <kargl@gcc.gnu.org>

    PR fortran/48426
    * gfortran.h (gfc_option_t): Add members flag_*_kind to store kind.
    * lang.opt: Add options -freal-4-real-8, -freal-4-real-10,
    -freal-4-real-16, -freal-8-real-4, -freal-8-real-10, -freal-8-real-16
    and -finteger-4-integer-8. User-desired type conversion information.
    * decl.c (gfc_match_old_kind_spec,kind_expr): Type conversions
    in declaration parsing.
    * trans-types.c (gfc_init_kinds): User-specified type conversion
    checked for current backend.
    * primary.c (match_integer_constant,match_real_constant): Implement
    type conversion in constant parsing.
    * options.c (gfc_init_options,gfc_handle_option): Translate input
    options to flags in internal options data structure.
    * invoke.texi: Document new options.  Re-order options in Options
    summary section.

Modified:
    trunk/gcc/fortran/decl.c
    trunk/gcc/fortran/gfortran.h
    trunk/gcc/fortran/invoke.texi
    trunk/gcc/fortran/lang.opt
    trunk/gcc/fortran/options.c
    trunk/gcc/fortran/primary.c
    trunk/gcc/fortran/trans-types.c

[Bug fortran/48426] [patch] Quad precision promotion

[kargl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48426

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|jvdelisle at gcc dot        |kargl at gcc dot gnu.org
                   |gnu.org                     |

--- Comment #19 from kargl at gcc dot gnu.org 2012-01-16 18:25:16 UTC ---
Reset "Assigned To" from jerryd to me.

Patch committed to trunk.  I may backport in 
a few days or close the PR as FIXED.  I haven't
decided, yet.

[Bug fortran/48426] [patch] Quad precision promotion

[kargl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48426

--- Comment #20 from kargl at gcc dot gnu.org 2012-01-18 17:24:23 UTC ---
Author: kargl
Date: Wed Jan 18 17:24:14 2012
New Revision: 183277

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183277
Log:
Insert ChangeLog entry that should have been included
in svn revision 183217 for PR fortran/48426.

Modified:
    trunk/gcc/fortran/ChangeLog

[Bug fortran/48426] [patch] Quad precision promotion

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48426

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org

--- Comment #21 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-01-19 08:14:31 UTC ---
(In reply to comment #19)
> I may backport in a few days or close the PR as FIXED.

I would prefer to not backport it.

[Bug fortran/48426] [patch] Quad precision promotion

[kargl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48426

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #22 from kargl at gcc dot gnu.org 2012-01-19 16:53:36 UTC ---
(In reply to comment #21)
> (In reply to comment #19)
> > I may backport in a few days or close the PR as FIXED.
> 
> I would prefer to not backport it.

OK.  Closing as fixed on trunk.

Zydrunas and Andreas, thanks for the patch.