Bug 50619 - Surprising interaction between -finit-real=NAN and the associate construct
Summary: Surprising interaction between -finit-real=NAN and the associate construct
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.6.1
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: wrong-code
Depends on:
Blocks:
 
Reported: 2011-10-04 22:00 UTC by Fred Krogh
Modified: 2012-06-14 13:06 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Fred Krogh 2011-10-04 22:00:17 UTC
With a real variable defined in a derived type and referenced in an associate construct the value is redefined as a NaN when using the compilier flag -finit-real=NAN.  The following two short routines illustrate the problem.


program testa1
  use testa2
  type(test_ty) :: e
  call test(e)
  stop
end program testa1

module testa2
type, public ::  test_ty ! Values that can be set or looked at by the user.
  real :: rmult = 1.0e0 ! Multiplies reals using default format.
end type test_ty

contains
  subroutine test(e)
    type(test_ty) :: e
    print '("No associate: e%rmult =", es15.6)', e%rmult
    associate (rmult=>e%rmult)
      print '("Associate: %rmult =", es15.6)', e%rmult
    end associate
  end subroutine test
end module testa2

compile with

gfortran  -ggdb -finit-real=NAN  -o testa1 testa2.f90 testa1.f90

and get

No associate: e%rmult =   1.000000E+00
Associate: %rmult =            NaN
Comment 1 Tobias Burnus 2011-10-05 08:25:21 UTC
This seems to be an ordering problem - from -fdump-tree-original:

test (struct test_ty & restrict e)
{
  {
    real(kind=4) * rmult;
    {
       I/O before ASSOCIATE ...
    }
    rmult = &e->rmult;
    *rmult =  Nan;
    {
       I/O in ASSOCIATE ...
    }

The "*rmult = NaN" line should be before "rmult = &e->rmult". I don't quite see whether that's a problem of inserting the NAN or of the ASSOCIATE assignment.
Comment 2 Bud Davis 2011-11-30 21:30:30 UTC
Reduced a bit more, for those that like it simple....


  real :: rmult = 1.0e0 
  real :: e
  print*,'No Associate',rmult
  associate (rmult=>e)
  print*,'   Associate',e
  end associate
  end
Comment 3 Stephan Weller 2012-06-04 09:44:06 UTC
I can confirm this behaviour in gcc-4.6.2, 4.7.0, and 4.8.0 (20120530) development version. Since this renders -finit-real=NAN unusable for me, I would consider this a serious bug.
Comment 4 Tobias Burnus 2012-06-04 12:32:20 UTC
(In reply to comment #3)
> I can confirm this behaviour in gcc-4.6.2, 4.7.0, and 4.8.0 (20120530)
> development version. Since this renders -finit-real=NAN unusable for me, I
> would consider this a serious bug.

I concur that it is a bad wrong-code bug, but it only occurs with the nondefault flag -finit-real=* - and it is not a regression -, thus, I think it is bad but not serious.

Unfortunately, the number of active gfortran developers is not that high, which in turn means that bugs aren't fixed and features not implemented as quickly as everyone would like. (Note: 99% of the Fortran-frontend development is done in the spare time!) Thus, if you are interested in contributing to gfortran - or if you know someone who is ...

 * * *

Regarding this bugreport: I think the following patch should fix it. I will test it and submit it.

--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -10105,3 +10105,4 @@ build_default_init_expr (gfc_symbol *sym)
       || sym->attr.cray_pointee
-      || sym->attr.cray_pointer)
+      || sym->attr.cray_pointer
+      || sym->assoc)
     return NULL;
Comment 5 Tobias Burnus 2012-06-04 21:01:05 UTC
Author: burnus
Date: Mon Jun  4 21:01:02 2012
New Revision: 188208

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188208
Log:
2012-06-04  Tobias Burnus  <burnus@net-b.de>

        PR fortran/50619
        * resolve.c (build_default_init_expr): Don't initialize
        ASSOCIATE names.

2012-06-04  Tobias Burnus  <burnus@net-b.de>

        PR fortran/50619
        * gfortran.dg/init_flag_10.f90: New.


Added:
    trunk/gcc/testsuite/gfortran.dg/init_flag_10.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/resolve.c
    trunk/gcc/testsuite/ChangeLog
Comment 6 Stephan Weller 2012-06-05 11:56:59 UTC
Great, this fixes the problem for me. In current svn revision, -finit-real=NAN works as expected. Thanks for keeping up the good work!
Comment 7 Tobias Burnus 2012-06-05 13:05:38 UTC
Author: burnus
Date: Tue Jun  5 13:05:31 2012
New Revision: 188237

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188237
Log:
2012-06-05  Tobias Burnus  <burnus@net-b.de>

        PR fortran/50619
        * resolve.c (build_default_init_expr): Don't initialize
        ASSOCIATE names.

2012-06-05  Tobias Burnus  <burnus@net-b.de>

        PR fortran/50619
        * gfortran.dg/init_flag_10.f90: New.


Added:
    branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/init_flag_10.f90
Modified:
    branches/gcc-4_6-branch/gcc/fortran/ChangeLog
    branches/gcc-4_6-branch/gcc/fortran/resolve.c
    branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
Comment 8 Tobias Burnus 2012-06-14 13:04:57 UTC
Author: burnus
Date: Thu Jun 14 13:04:43 2012
New Revision: 188617

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188617
Log:
2012-06-14  Tobias Burnus  <burnus@net-b.de>

        Backport from mainline
        2012-06-04  Tobias Burnus  <burnus@net-b.de>

        PR fortran/50619
        * resolve.c (build_default_init_expr): Don't initialize
        ASSOCIATE names.

2012-06-14  Tobias Burnus  <burnus@net-b.de>

        Backport from mainline
        2012-06-04  Tobias Burnus  <burnus@net-b.de>

        PR fortran/50619
        * gfortran.dg/init_flag_10.f90: New.


Added:
    branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/init_flag_10.f90
Modified:
    branches/gcc-4_7-branch/gcc/fortran/ChangeLog
    branches/gcc-4_7-branch/gcc/fortran/resolve.c
    branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
Comment 9 Tobias Burnus 2012-06-14 13:06:54 UTC
FIXED on all affected branches: On the (4.8) trunk and the 4.6 and the 4.7 branches. (Note that the patch came too late for the 4.7.1 release.)