[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  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #23 from Thomas Koenig  ---
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] 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  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #22 from Thomas Koenig  ---
I think this should be fixed now, because we now generate
argument lists from actual arcuments if none are present.

Can somebody confirm that this is the case? I don't speak
TREE too well.

[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  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||tkoenig at gcc dot gnu.org
 Blocks||87689, 40976

--- Comment #21 from Thomas Koenig  ---
Please don't close.

This is one of the longstanding issues with gfortran, which
causes, or is closely related, to other PRs. Some might even
be duplicates.

For one thing, this kind of thing causes problems for LTO,
and also wrong-code issues such as PR 87689.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40976
[Bug 40976] Merge DECL of procedure call with DECL of gfc_get_function_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87689
[Bug 87689] Memory corruption on Power 8

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

[juergen.reuter at desy dot de]

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

Jürgen Reuter  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #20 from Jürgen Reuter  ---
Dominique, you announced almost 10 months ago that you would close this one in
case of no feedback. Closing?

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

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #19 from Dominique d'Humieres  ---
> This was due to the following TODO in gfc_get_symbol_for_expr():
> /* TODO: proper argument lists for external intrinsics.  */

This has disappeared from the sources since at least gcc5.

In addition I see:

gcc/fortran/ChangeLog-2011: * trans.h (gfc_chainon_list): Delete.
gcc/fortran/ChangeLog-2011: * trans.c (gfc_chainon_list): Delete.

So the patch in comment 10 is now irrelevant.

Without feedback I'll close this PR as INVALID.

[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

[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 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

[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

[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

[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

[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=14365action=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

[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|-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