[Bug fortran/30432] New: gfortran.dg/c_by_val_1.f fails on ia64-*-*, problem with %VAL

[Bug fortran/30432] New: gfortran.dg/c_by_val_1.f fails on ia64-*-*, problem with %VAL

[sje at cup dot hp dot com]

The test tails for both HP-UX and Linux on IA64.  It looks like the problem is
with the %VAL function on the f_to_f subroutine call.  I believe that the
Fortran front-end is doing something wrong so that the %VAL(a) gets passed in
an integer register instead of a floating point register.  Since a is a
floating point variable and it is being passed by value, the IA64 ABI says it
should be passed in a floating point register and that is where the C code is
expecting it.


-- 
           Summary: gfortran.dg/c_by_val_1.f fails on ia64-*-*, problem with
                    %VAL
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: sje at cup dot hp dot com
GCC target triplet: ia64-*-*


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

[Bug fortran/30432] gfortran.dg/c_by_val_1.f fails on ia64-*-*, problem with %VAL

[pault at gcc dot gnu dot org]

------- Comment #1 from pault at gcc dot gnu dot org  2007-01-12 20:59 -------
Steve,

I am a bit surprised by what you say:
On an ia64/FC5, the pair of programs work fine.  The code around the call to
f_to_f is:
.....
  real4 a;
.....
  a = 4.2e+1;
  b = 0.0;
  c = a;
  c.1 = &c;
  f_to_f (&b, a, &c, &c.1);
  D.1355 = a * 2.0e+0;
  b.2 = b;
  if (D.1355 != b.2)
    {
      _gfortran_abort ();
    }
so that a appears to be passed as a float, aka real4

and for the function itself:
f_to_f__ (retval, a1, a2, a3)
{
  float D.1993;
  float * D.1994;
  float D.1995;
  float D.1996;
  float D.1997;

  D.1993 = *a2;
  if (D.1993 != a1)
    {
      abort ();
    }
  else
    {

    }
  D.1994 = *a3;
  D.1995 = *D.1994;
  if (D.1995 != a1)
    {
      abort ();
    }
  else
    {

    }
  a1 = 0.0;
  D.1996 = *a2;
  D.1997 = D.1996 * 2.0e+0;
  *retval = D.1997;
  return;
}
and, similarly, f_to_f treats it as a float.

Unflummox me!

Paul 


-- 


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

[Bug fortran/30432] gfortran.dg/c_by_val_1.f fails on ia64-*-*, problem with %VAL

[sje at cup dot hp dot com]

------- Comment #2 from sje at cup dot hp dot com  2007-01-12 21:52 -------
I am not sure if I can unflummox you or not.  It still fails for me on IA64
HP-UX and on IA64 Debian 3.1 Linux.  It also shows up in the testresults mail
from H.J and Andreas on their IA64 Linux testing.  Here are two short programs
to reproduce the error.  The interesting thing is that a1 is correctly printed
out if I remove the initial integer argument.  With the integer argument I get
the value zero printed.  Looking at the assembly code again, it still looks
like the float argument is being passed in an integer register by the Fortran
main program and read from a floating point register by the C code.  With out
the integer argument the float argument is written to and read from a floating
point register, which is what I would expect.

C code:

void f_to_f__(int i, float a1)
{
  printf("a1 = %f\n", (double) a1);
  return;
}
      program c_by_val_1
      external   f_to_f
      real       a
      integer    i

      a = 42.0
      call  f_to_f (i, %VAL (a))
      stop
      end
Fortran code:


-- 


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

[Bug fortran/30432] gfortran.dg/c_by_val_1.f fails on ia64-*-*, problem with %VAL

[sje at cup dot hp dot com]

------- Comment #3 from sje at cup dot hp dot com  2007-01-12 21:54 -------
My example code got a little messed up in the last comment, here it is again:

C code:

  void f_to_f__(int i, float a1)
  {
    printf("a1 = %f\n", (double) a1);
    return;
  }


Fortran code:


      program c_by_val_1
      external   f_to_f
      real       a
      integer    i

      a = 42.0
      call  f_to_f (i, %VAL (a))
      stop
      end


-- 


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

[Bug fortran/30432] gfortran.dg/c_by_val_1.f fails on ia64-*-*, problem with %VAL

[sje at cup dot hp dot com]

------- Comment #4 from sje at cup dot hp dot com  2007-01-12 22:37 -------
Here is a little more information:  In the broken case (my small test case with
the initial integer argument), when I call ia64_function_arg (via the
FUNCTION_ARG macro) the named argument has a value of zero.  This results in
the floating point argument being put in an integer register.  In the working
case (no initial integer argument), named is one and the floating point
argument gets put in a floating point register.  I am not sure what triggers
the different value for the  named parameter though.


-- 


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

[Bug fortran/30432] gfortran.dg/c_by_val_1.f fails on ia64-*-*, problem with %VAL

[pinskia at gcc dot gnu dot org]

------- Comment #5 from pinskia at gcc dot gnu dot org  2007-01-14 05:28 -------
Hmmm, I wonder if ia64 is broken for the following C case:
TU1.c:
int f();
int g(int a, double c, int d)
{
  return f(a, d);
}

TU2.c:
int f(int a, double b)
{
  return b;
}


the named agrument is defined by:
  current_function_stdarg
    = (fntype
       && TYPE_ARG_TYPES (fntype) != 0
       && (TREE_VALUE (tree_last (TYPE_ARG_TYPES (fntype)))
           != void_type_node));

But I wonder if we get it even more incorrect someother cases too.


-- 


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

[Bug fortran/30432] gfortran.dg/c_by_val_1.f fails on ia64-*-*, problem with %VAL

[sje at cup dot hp dot com]

------- Comment #6 from sje at cup dot hp dot com  2007-01-17 16:58 -------
The code in comment #5 works fine.  In pure C cases, if a prototype has been
seen when you get to the call, the floating point value goes into a FP reg.  If
you haven't seen a prototype then the value goes into both an FP reg -and- a
general register. In the Fortran case the floating point value is only going
into a general register.  I think the only way to reproduce this in C is to
have a protype for the f_to_f function that looks like f_to_f (int, ...).


-- 


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

[Bug fortran/30432] gfortran.dg/c_by_val_1.f fails on ia64-*-*, problem with %VAL

[sje at cup dot hp dot com]

------- Comment #7 from sje at cup dot hp dot com  2007-01-22 22:45 -------
So I can see things going wrong in expand_call but I still don't know why. 
With the FORTRAN example (comment #3) expand_call sets num_actuals to 2 and
n_named_args to 1.  If I write the calling code in C, num_actuals is 2 and
n_named_args is 3.  Because (in FORTRAN) num_actuals > n_named_args, I pass the
floating point value in a general register (like varags) instead of in a
floating point register like when I have a regular named argument.

n_named_args seems to be set based on list_length(type_arg_types) and for some
reason this is 3 for C and 1 for Fortran.  I think the fortran type_arg_types
list is wrong but I don't know why it is wrong.


-- 


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

[Bug fortran/30432] gfortran.dg/c_by_val_1.f fails on ia64-*-*, problem with %VAL

[sje at gcc dot gnu dot org]

------- Comment #8 from sje at gcc dot gnu dot org  2007-01-30 17:49 -------
Subject: Bug 30432

Author: sje
Date: Tue Jan 30 17:49:24 2007
New Revision: 121347

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121347
Log:
        PR fortran/30432
        * trans-types.c (gfc_get_function_type):  Do not add void_type_node
        to empty arg list.
        * trans-decl.c (create_function_arglist): Change assert.

Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-decl.c
    trunk/gcc/fortran/trans-types.c


-- 


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

[Bug fortran/30432] [4.2/4.1 only] gfortran.dg/c_by_val_1.f fails on ia64-*-*, problem with %VAL

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
           Keywords|                            |patch, wrong-code
      Known to fail|                            |4.2.0 4.1.2
      Known to work|                            |4.3.0
   Last reconfirmed|0000-00-00 00:00:00         |2007-02-01 12:27:47
               date|                            |
            Summary|gfortran.dg/c_by_val_1.f    |[4.2/4.1 only]
                   |fails on ia64-*-*, problem  |gfortran.dg/c_by_val_1.f
                   |with %VAL                   |fails on ia64-*-*, problem
                   |                            |with %VAL
   Target Milestone|---                         |4.2.0


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

[Bug fortran/30432] [4.2/4.1 only] gfortran.dg/c_by_val_1.f fails on ia64-*-*, problem with %VAL

[sje at gcc dot gnu dot org]

------- Comment #9 from sje at gcc dot gnu dot org  2007-02-05 21:28 -------
Subject: Bug 30432

Author: sje
Date: Mon Feb  5 21:28:46 2007
New Revision: 121615

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121615
Log:
        Backport from trunk
        PR fortran/30432
        * trans-types.c (gfc_get_function_type):  Do not add void_type_node
        to empty arg list.
        * trans-decl.c (create_function_arglist): Change assert.

Modified:
    branches/gcc-4_2-branch/gcc/fortran/ChangeLog
    branches/gcc-4_2-branch/gcc/fortran/trans-decl.c
    branches/gcc-4_2-branch/gcc/fortran/trans-types.c


-- 


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

[Bug fortran/30432] [4.1 only] gfortran.dg/c_by_val_1.f fails on ia64-*-*, problem with %VAL

[sje at cup dot hp dot com]

------- Comment #10 from sje at cup dot hp dot com  2007-02-06 18:01 -------
This is fixed on mainline and the 4.2 branch now.  Should it be closed?  I
don't think %VAL is in GCC 4.1 and the failing test is certainly not in the 4.1
branch.  The underlying bug is in 4.1 but it may not be possible to trigger it
without %VAL.


-- 

sje at cup dot hp dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|4.2.0 4.1.2                 |4.1.2
      Known to work|4.3.0                       |4.3.0 4.2.0
            Summary|[4.2/4.1 only]              |[4.1 only]
                   |gfortran.dg/c_by_val_1.f    |gfortran.dg/c_by_val_1.f
                   |fails on ia64-*-*, problem  |fails on ia64-*-*, problem
                   |with %VAL                   |with %VAL


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

[Bug fortran/30432] [4.1 only] gfortran.dg/c_by_val_1.f fails on ia64-*-*, problem with %VAL

[fxcoudert at gcc dot gnu dot org]

------- Comment #11 from fxcoudert at gcc dot gnu dot org  2007-02-06 23:17 -------
(In reply to comment #10)
> This is fixed on mainline and the 4.2 branch now.  Should it be closed?  I
> don't think %VAL is in GCC 4.1 and the failing test is certainly not in the 4.1
> branch.  The underlying bug is in 4.1 but it may not be possible to trigger it
> without %VAL.

OK, that's reason enough to close it. Thanks for your work!


-- 

fxcoudert at gcc dot gnu dot org changed:

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


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