[Bug fortran/18566] New: Can vary constants

[Bug fortran/18566] New: Can vary constants

[Thomas dot Koenig at online dot de]

Should the value of pi change...

The following is very probably illegal code.
Still, it would be nice if this could segfault
instead of silently doing the Wrong Thing.

$ cat variation-constants.f90
module a1
contains
  subroutine foo(b)
    real :: b
    b = 42.
  end subroutine foo
end module a1

program main
  use a1
  real, parameter :: pi = 3.1415926535
  call foo(pi)
  print *,'pi equals ', pi
end program main
$ gfortran variation-constants.f90 && ./a.out
 pi equals    42.00000
$ gfortran -v
Reading specs from /home/zfkts/lib/gcc/ia64-unknown-linux-gnu/4.0.0/specs
Configured with: ../gcc-4.0-20041107/configure --prefix=/home/zfkts
--enable-languages=c,c++,f95
Thread model: posix
gcc version 4.0.0 20041107 (experimental)

-- 
           Summary: Can vary constants
           Product: gcc
           Version: 4.0.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P2
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: Thomas dot Koenig at online dot de
                CC: gcc-bugs at gcc dot gnu dot org


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

[Bug fortran/18566] Can vary constants

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-19 15:13 -------
No it is just undefined on most targets we do seg fault.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


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

[Bug fortran/18566] Can vary constants

[Thomas dot Koenig at online dot de]

------- Additional Comments From Thomas dot Koenig at online dot de  2004-11-25 20:29 -------
(In reply to comment #1)
> No it is just undefined on most targets we do seg fault.

I realize that this is undefined, but it would still be nice
to get consistent behavior (i.e. a consistent segfault)
across all platforms.  Is there any reason why
the parameter isn't being put into a read-only section
on IA-64?

This is why this is a request for an enhancement.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
           Priority|P2                          |P1
         Resolution|INVALID                     |


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

[Bug target/18566] Can vary constants (undefined fortran)

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-29 14:13 -------
This is a target problem, most likely what is happening is that the memory where the variable is being 
stored is not being marked as read only for the processor.  So is this is either an OS problem or just a 
defientcy  in the IA64.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|fortran                     |target
           Priority|P1                          |P3
            Summary|Can vary constants          |Can vary constants
                   |                            |(undefined fortran)


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

[Bug target/18566] Can vary constants (undefined fortran)

[Thomas dot Koenig at online dot de]

------- Additional Comments From Thomas dot Koenig at online dot de  2004-11-30 08:29 -------
(In reply to comment #3)
> This is a target problem, most likely what is happening is that the memory
where the variable is being 
> stored is not being marked as read only for the processor.

This appears to be the case for C, as well. "const" variables are not
put into read-only memory.

Here's a C equivalent.  It is invalid as well, but it would be
nice if this could segfault, as well.

$ cat const.c
const int answer=42;
$ cat const2.c
#include <stdio.h>

extern int answer;

int main()
{
  answer = 3;
  printf("%d\n", answer);
  return 0;
}
$ ia64-unknown-linux-gnu-gcc-4.0.0 const.c const2.c
$ ./a.out
3


-- 


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

[Bug target/18566] Can vary constants (undefined fortran)

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2004-12-07 18:48:17
               date|                            |


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

[Bug target/18566] Can vary constants (undefined fortran)

[wilson at gcc dot gnu dot org]

------- Additional Comments From wilson at gcc dot gnu dot org  2005-01-05 03:44 -------
This question was asked and mostly answered on the gcc mailing list.
    http://gcc.gnu.org/ml/gcc/2004-12/msg00231.html
    http://gcc.gnu.org/ml/gcc/2004-12/msg00234.html

As per the ABI, small local data ("own" data) is placed in the small data
section in the GOT, where it can be accessed with a single memory reference.  If
we put it in the read-only data section, it would require two memory references
to access it, resulting in slower code.

Since the C testcase is invalid, this is not a good enough reason to disable an
optimization by default.

However, as Richard Henderson mentioned, we could optionally put the variable in
a read-only data section if the user requested it via an option, or if the
Fortran standard requires it.  I don't know if the Fortran standard requires
this, I doubt that it does.

Incidentally, this issue is not unique to the IA-64 port.  There are other
targets that behave the same way, mips-elf for instance.  So you may still have
this problem when porting code to other systems even if the IA-64 port was fixed.

There is an option that will make your testcase work as you expect, the
-mno-sdata option.  This is overkill for your purposes though, as this prevents
any variable from going in sdata, whereas you only want to prevent putting const
variables in sdata.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wilson at gcc dot gnu dot
                   |                            |org


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