[Bug fortran/30887] New: %VAL construct fails on 64 bit

[Bug fortran/30887] New: %VAL construct fails on 64 bit

[p dot w dot draper at durham dot ac dot uk]

The %VAL construct doesn't accept INTEGER types with a size
greater than the default kind. This is essential for supporting
64 bit architectures where an address cannot be stored in 
an integer with the default kind. Consider the simple module:

      SUBROUTINE VALTEST2()
      INTEGER*8 P
      P = 0
      CALL DOIT( %VAL( P ) )
      END

That fails with error report:

> gfortran -c valtest2.f 
valtest2.f:6.22:

      CALL DOIT( %VAL( P ) )                                            
                     1
Error: Kind of by-value argument at (1) is larger than default kind

Increasing the size of the default integer kind would resolve this
problem, but that would have secondary issues (which are not
acceptable in my code, the default integer maps to a defined-size
storage type).


-- 
           Summary: %VAL construct fails on 64 bit
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: critical
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: p dot w dot draper at durham dot ac dot uk
  GCC host triplet: x86_64-unknown-linux-gnu


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

[Bug fortran/30887] %VAL construct fails on 64 bit

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|critical                    |normal


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

[Bug fortran/30887] %VAL only accepts default-kind integer/real/complex

[burnus at gcc dot gnu dot org]

------- Comment #1 from burnus at gcc dot gnu dot org  2007-02-20 17:32 -------
Paul, do you remember why you have added the following restriction?

(The example is accepted by ifort, nagf95 and g95.)

resolve.c:
              if (((e->ts.type == BT_REAL || e->ts.type == BT_COMPLEX)
                   && e->ts.kind > gfc_default_real_kind)
                  || (e->ts.kind > gfc_default_integer_kind))
                {
                  gfc_error ("Kind of by-value argument at %L is larger "
                             "than default kind", &e->where);
                  return FAILURE;


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pault at gcc dot gnu dot
                   |                            |org, burnus at gcc dot gnu
                   |                            |dot org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   GCC host triplet|x86_64-unknown-linux-gnu    |
           Keywords|                            |rejects-valid
   Last reconfirmed|0000-00-00 00:00:00         |2007-02-20 17:32:54
               date|                            |
            Summary|%VAL construct fails on 64  |%VAL only accepts default-
                   |bit                         |kind integer/real/complex


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

[Bug fortran/30887] %VAL only accepts default-kind integer/real/complex

[paulthomas2 at wanadoo dot fr]

------- Comment #2 from paulthomas2 at wanadoo dot fr  2007-02-21 05:16 -------
Subject: Re:  %VAL only accepts default-kind integer/real/complex

Tobias,
> ------- Comment #1 from burnus at gcc dot gnu dot org  2007-02-20 17:32 -------
> Paul, do you remember why you have added the following restriction?
>
> (The example is accepted by ifort, nagf95 and g95.)
>
> resolve.c:
>               if (((e->ts.type == BT_REAL || e->ts.type == BT_COMPLEX)
>                    && e->ts.kind > gfc_default_real_kind)
>                   || (e->ts.kind > gfc_default_integer_kind))
>                 {
>                   gfc_error ("Kind of by-value argument at %L is larger "
>                              "than default kind", &e->where);
>                   return FAILURE;
>   
One of the compilers, whose implementation of %VAL I checked, had this 
restriction.  I now cannot find which one.

There is absolutely no reason why the restriction should not be removed.

Best regards

Paul


-- 


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

[Bug fortran/30887] %VAL only accepts default-kind integer/real/complex

[sdirkse at gams dot com]

------- Comment #3 from sdirkse at gams dot com  2007-02-22 18:52 -------
I took out the restriction in resolve.c that leads to the error message, and it
does give me a clean compile, but the code does not do what I expect.  For
example, passing a real(kind=8) by-value to C doesn't get me a good double,
ditto for a integer(kind=8).  The examples work when using ifort/icc.  I can
send them if you'd like, but they are vanilla one-liners, almost.

Enough facts, now for some ignorant speculation: I suppose there is some logic
missing to pass a value from the caller when the size of the value is not the
default size (i.e. 4 for my platform, Linux 32-bit).  


-- 

sdirkse at gams dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sdirkse at gams dot com


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

[Bug fortran/30887] %VAL only accepts default-kind integer/real/complex

[kargl at gcc dot gnu dot org]

------- Comment #4 from kargl at gcc dot gnu dot org  2007-02-22 19:24 -------
(In reply to comment #3)
>
> Enough facts, now for some ignorant speculation: I suppose there is some logic
> missing to pass a value from the caller when the size of the value is not the
> default size (i.e. 4 for my platform, Linux 32-bit).  
> 

See conv_arglist_function in trans-expr.c.


-- 


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

[Bug fortran/30887] %VAL only accepts default-kind integer/real/complex

[burnus at gcc dot gnu dot org]

-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |burnus at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2007-02-20 17:32:54         |2007-02-22 19:50:51
               date|                            |


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

[Bug fortran/30887] %VAL only accepts default-kind integer/real/complex

[patchapp at dberlin dot org]

------- Comment #5 from patchapp at dberlin dot org  2007-02-22 21:10 -------
Subject: Bug number PR30887

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01839.html


-- 


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

[Bug fortran/30887] %VAL only accepts default-kind integer/real/complex

[sdirkse at gams dot com]

------- Comment #6 from sdirkse at gams dot com  2007-02-22 21:35 -------
(In reply to comment #4)
> (In reply to comment #3)
> >
> > Enough facts, now for some ignorant speculation: I suppose there is some logic
> > missing to pass a value from the caller when the size of the value is not the
> > default size (i.e. 4 for my platform, Linux 32-bit).  
> > 
> 
> See conv_arglist_function in trans-expr.c.
> 

Brilliant!  I changed the code in there to use a size of
MAX(default_kind,expression_kind) instead of just default_kind, and it seems to
work now, i.e. the one-liner example is OK.  The code was easier to read and
modify than I was expecting, a pleasant surprise.


-- 


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

[Bug fortran/30887] %VAL only accepts default-kind integer/real/complex

[p dot w dot draper at durham dot ac dot uk]

------- Comment #7 from p dot w dot draper at durham dot ac dot uk  2007-02-23 15:44 -------
Tried out the patch and it works for me under 64bit with
default sized integers. Seems to have fixed PR 30888 too.

Thanks.


-- 


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

[Bug fortran/30887] %VAL only accepts default-kind integer/real/complex

[burnus at gcc dot gnu dot org]

------- Comment #8 from burnus at gcc dot gnu dot org  2007-02-28 18:17 -------
Subject: Bug 30887

Author: burnus
Date: Wed Feb 28 18:17:34 2007
New Revision: 122409

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122409
Log:
2007-02-28  Tobias Burnus  <burnus@net-b.de>
            Paul Thomas  <pault@gcc.gnu.org>

        PR fortran/30888
        PR fortran/30887
        * resolve.c (resolve_actual_arglist): Allow by-value
        arguments and non-default-kind for %VAL().
        * trans-expr.c (conv_arglist_function): Allow
        non-default-kind for %VAL().

testsuite/
2007-02-28  Tobias Burnus  <burnus@net-b.de>
            Paul Thomas  <pault@gcc.gnu.org>

        PR fortran/30888
        PR fortran/30887
        * c_by_val_1.f: Test %VAL() with non-default kind.
        * c_by_val.c: Ditto.
        * c_by_val_4.f: New test.


Added:
    trunk/gcc/testsuite/gfortran.dg/c_by_val_4.f
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/resolve.c
    trunk/gcc/fortran/trans-expr.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/c_by_val.c
    trunk/gcc/testsuite/gfortran.dg/c_by_val_1.f


-- 


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

[Bug fortran/30887] %VAL only accepts default-kind integer/real/complex

[burnus at gcc dot gnu dot org]

------- Comment #9 from burnus at gcc dot gnu dot org  2007-02-28 18:26 -------
Fixed in GCC 4.3, not part of 4.2 => close PR.

Thanks for having reported this bug.


-- 

burnus at gcc dot gnu dot org changed:

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


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