[Bug fortran/33097] Function decl trees without proper argument list

[Bug fortran/33097] Function decl trees without proper argument list

[howarth at nitro dot med.uc.edu]

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

Jack Howarth <howarth at nitro dot med.uc.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |howarth at nitro dot
                   |                            |med.uc.edu

--- Comment #17 from Jack Howarth <howarth at nitro dot med.uc.edu> 2010-10-06 19:37:20 UTC ---
FYI, this PR apparently causes all of the remaining Polyhedron 2005 benchmark
compile failures when building with gcc 4.5.2 using the current dragonegg 2.8
plugin...

http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-October/035255.html
http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-October/035256.html

While fixing this PR might not be particularly helpful in stock gcc trunk, it
would greatly enhance dragonegg's usefulness under the same.

[Bug fortran/33097] Function decl trees without proper argument list

[burnus at gcc dot gnu.org]

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

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

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

--- Comment #18 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-03-25 18:18:59 UTC ---
See also PR 44471.

[Bug fortran/33097] Function decl trees without proper argument list

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33097

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

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

--- Comment #23 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
If we see the procedure in the global namespace, we add
its declaration; and if we don't see it, we generate
the declaration on the fly, from the actual arglist.

So, I'd say this is fixed.

[Bug fortran/33097] New: Invalid decl trees are created for external intrinsics

[asl at math dot spbu dot ru]

Recently I discovered, that gfortran FE creates invalid decl trees for exteranl
intrinsics: only return value is added to arg chain, and none of the actual
arguments. This can potentially break much stuff, because of inconsistency of
CALL_EXPR and corresponding fndecl.

This was due to the following TODO in gfc_get_symbol_for_expr():
/* TODO: proper argument lists for external intrinsics.  */


-- 
           Summary: Invalid decl trees are created for external intrinsics
           Product: gcc
           Version: 4.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: asl at math dot spbu dot ru


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

[Bug fortran/33097] Function decl trees without proper argument list

[fxcoudert at gcc dot gnu dot org]

------- Comment #3 from fxcoudert at gcc dot gnu dot org  2007-08-20 14:47 -------
Confirmed.  The same thing is true for external procedures, like:

program test
  real x
  external x
  print *, x(2)
end program test

real function x(i)
  integer i
  x = i + 1
end function x

Two decls are generated for function x, the first one (inside MAIN__) doesn't
have a proper argument list while the second one is OK. When I try to make
gfortran emit only one decl per externally-visible function, it's currently
choking on this.


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fxcoudert at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
      Known to fail|                            |4.1.2 4.2.0 4.3.0
   Last reconfirmed|0000-00-00 00:00:00         |2007-08-20 14:47:58
               date|                            |
            Summary|Invalid decl trees are      |Function decl trees without
                   |created for external        |proper argument list
                   |intrinsics                  |


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

[Bug fortran/33097] Function decl trees without proper argument list

[asl at math dot spbu dot ru]

------- Comment #4 from asl at math dot spbu dot ru  2007-08-20 16:46 -------
Ooops, attached patch is not complete. I also need:

diff --git a/gcc/fortran/trans-types.c b/gcc/fortran/trans-types.c
--- a/gcc/fortran/trans-types.c
+++ b/gcc/fortran/trans-types.c
@@ -1027,7 +1027,7 @@ gfc_get_nodesc_array_type (tree etype, gfc_array_spec *
as, int packed)
       GFC_TYPE_ARRAY_STRIDE (type, n) = tmp;

       expr = as->lower[n];
-      if (expr->expr_type == EXPR_CONSTANT)
+      if (expr && expr->expr_type == EXPR_CONSTANT)
         {
           tmp = gfc_conv_mpz_to_tree (expr->value.integer,
                                   gfc_index_integer_kind);


-- 


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

[Bug fortran/33097] Function decl trees without proper argument list

[asl at math dot spbu dot ru]

------- Comment #5 from asl at math dot spbu dot ru  2007-08-20 16:47 -------
(In reply to comment #3)
> Two decls are generated for function x, the first one (inside MAIN__) doesn't
> have a proper argument list while the second one is OK. When I try to make
> gfortran emit only one decl per externally-visible function, it's currently
> choking on this.
How is it choking? Maybe I already seen this during preparation of quick patch.


-- 


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

[Bug fortran/33097] Function decl trees without proper argument list

[fxcoudert at gcc dot gnu dot org]

------- Comment #6 from fxcoudert at gcc dot gnu dot org  2007-08-20 16:51 -------
(In reply to comment #5)
> How is it choking? Maybe I already seen this during preparation of quick patch.

Well, it's trying to reuse a decl without arglist for a function call with
arguments, and it leads to some segfault down the way...

Program received signal SIGSEGV, Segmentation fault.
create_function_arglist (sym=<value optimized out>)
    at ../../../trunk3/gcc/fortran/trans-decl.c:1430

I'm sorry that I can't yet attach my patch (the one that triggers the ICE), but
I'll try to do it later this week.


-- 


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

[Bug fortran/33097] Function decl trees without proper argument list

[asl at math dot spbu dot ru]

------- Comment #7 from asl at math dot spbu dot ru  2007-08-20 17:00 -------
Well, I haven't seen this. The only segfault I've seen was in trans-types.c
(patch mentioned)


-- 


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

[Bug fortran/33097] Function decl trees without proper argument list

[asl at math dot spbu dot ru]

------- Comment #8 from asl at math dot spbu dot ru  2007-10-17 10:17 -------
(In reply to comment #3)
> Confirmed.  The same thing is true for external procedures, like:
> 
> program test
>   real x
>   external x
>   print *, x(2)
> end program test
> 
> real function x(i)
>   integer i
>   x = i + 1
> end function x
> 
This isn't so bad, because decl for x is emitted as vararg function and thus
tree is not bogus


-- 


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

[Bug fortran/33097] Function decl trees without proper argument list

[asl at math dot spbu dot ru]

------- Comment #9 from asl at math dot spbu dot ru  2007-10-17 16:45 -------
(In reply to comment #3)
> Two decls are generated for function x, the first one (inside MAIN__) doesn't
> have a proper argument list while the second one is OK. When I try to make
> gfortran emit only one decl per externally-visible function, it's currently
> choking on this.
After some thinking on this example, it seems, I found some solution. My
previous approach cannot be completed because of the presence of optional
arguments. And even having some valid call, we cannot construct valid decl from
this (or we will need some additional logic, which will "complete" such decls).

The idea itself is pretty simple: why don't turn external functions/intrinsics
into varargs function (in C/C++ sense). In this case trees won't became bogus
anymore, however, having call to varargs function can (in theory) disable some
optimization performed on it. Attached patch works fine for me. Any comments?


-- 


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

[Bug fortran/33097] Function decl trees without proper argument list

[asl at math dot spbu dot ru]

------- Comment #10 from asl at math dot spbu dot ru  2007-10-17 16:46 -------
Created an attachment (id=14365)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14365&action=view)
Patch to mark external decls to be varargs


-- 

asl at math dot spbu dot ru changed:

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


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

[Bug fortran/33097] Function decl trees without proper argument list

[asl at math dot spbu dot ru]

------- Comment #11 from asl at math dot spbu dot ru  2007-10-17 17:00 -------
Also, some chunk of code in function type creation (gfc_get_function_type() is
in question) looks suspicious to me. Let me explain on terms of C (I don't know
Fortran at all :) )

Consider we have two function decls:

int foo1();
struct some_fat_struct foo2();

Both are varargs functions, but return type for the second will be lowered to
void, so, after some lowering they in general should look like:

int foo(...);
void foo2(struct some_fat_struct *retval, ...);

The problem with gfortran is that function, which result is passed by reference
(determined with help of gfc_return_by_reference() call inside
gfc_get_function_type()) won't be varargs, so inside gfortran FE we'll end with
 something like:

void foo2(some_fat_struct *ptr); but:
int foo(...);

This looks pretty unlogical to me. Was it intentional?


-- 


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

[Bug fortran/33097] Function decl trees without proper argument list

[fxcoudert at gcc dot gnu dot org]

------- Comment #12 from fxcoudert at gcc dot gnu dot org  2007-10-17 17:14 -------
(In reply to comment #11)
> void foo2(some_fat_struct *ptr); but:
> int foo(...);
> 
> This looks pretty unlogical to me. Was it intentional?

Yes, I think that's intentional. Why is it unlogical?

Also, have you looked at how character variables are handled? (appending string
length in the arg list) That's a surprising calling convention for people
coming from C...


-- 


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

[Bug fortran/33097] Function decl trees without proper argument list

[asl at math dot spbu dot ru]

------- Comment #13 from asl at math dot spbu dot ru  2007-10-17 17:27 -------
(In reply to comment #12)
> (In reply to comment #11)
> > void foo2(some_fat_struct *ptr); but:
> > int foo(...);
> > 
> > This looks pretty unlogical to me. Was it intentional?
> 
> Yes, I think that's intentional. Why is it unlogical?
Because return type dictates, whether there is ellipsis or not. I think, that
both functions should be varargs, no?

> Also, have you looked at how character variables are handled? (appending string
> length in the arg list) That's a surprising calling convention for people
> coming from C...
Yes, I saw this. It's pretty clear, not surprising :) 


-- 


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

[Bug fortran/33097] Function decl trees without proper argument list

[dfranke at gcc dot gnu dot org]

------- Comment #14 from dfranke at gcc dot gnu dot org  2009-01-03 21:26 -------
For the interested reader, see another approach here:
        http://gcc.gnu.org/ml/fortran/2008-12/msg00306.html

Instead of "guessing" the arguments, I fused existing decls with later
interfaces. It generally workes, but the patch is a horrible hack (see thread
for comments and a different approach).


-- 

dfranke at gcc dot gnu dot org changed:

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


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

[Bug fortran/33097] Function decl trees without proper argument list

[dfranke at gcc dot gnu dot org]

------- Comment #15 from dfranke at gcc dot gnu dot org  2010-05-01 20:20 -------
By now we have proper whole-file checking. Is this PR still relevant?


-- 

dfranke at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
OtherBugsDependingO|                            |40011
              nThis|                            |


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

[Bug fortran/33097] Function decl trees without proper argument list

[steven at gcc dot gnu dot org]

-- 

steven at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING


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

[Bug fortran/33097] Function decl trees without proper argument list

[burnus at gcc dot gnu dot org]

------- Comment #16 from burnus at gcc dot gnu dot org  2010-07-16 07:17 -------
(In reply to comment #15)
> By now we have proper whole-file checking. Is this PR still relevant?

I think it is - though there should be some PR about it. The correct way is to
construct the dummy argument list from the actual argument list. For
procedures, where the explicit interface is known, this is not an issue, but
those with implicit interface ("EXTERNAL") it is. Additionally, one can improve
the diagnostic as conflicting use of such procedures can be diagnosed.

Cf. PR 40976. I thought there was another PR, but I cannot find it at the
moment.


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
   Last reconfirmed|2007-08-20 14:47:58         |2010-07-16 07:17:03
               date|                            |


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