* [Bug fortran/33097] Invalid decl trees are created for external intrinsics
2007-08-17 12:39 [Bug fortran/33097] New: Invalid decl trees are created for external intrinsics asl at math dot spbu dot ru
@ 2007-08-17 12:42 ` asl at math dot spbu dot ru
2007-08-17 12:49 ` asl at math dot spbu dot ru
` (15 subsequent siblings)
16 siblings, 0 replies; 21+ messages in thread
From: asl at math dot spbu dot ru @ 2007-08-17 12:42 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from asl at math dot spbu dot ru 2007-08-17 12:42 -------
Created an attachment (id=14069)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14069&action=view)
Quick and dirty patch
Attached is quick and dirty patch to populate symbol with arguments. It seems
to be incomplete (at least for optional args, as it seems to me), and maybe
invalid in general (I touched gfortran FE yesterday for the first time).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33097
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug fortran/33097] Invalid decl trees are created for external intrinsics
2007-08-17 12:39 [Bug fortran/33097] New: Invalid decl trees are created for external intrinsics asl at math dot spbu dot ru
2007-08-17 12:42 ` [Bug fortran/33097] " asl at math dot spbu dot ru
@ 2007-08-17 12:49 ` asl at math dot spbu dot ru
2007-08-20 14:48 ` [Bug fortran/33097] Function decl trees without proper argument list fxcoudert at gcc dot gnu dot org
` (14 subsequent siblings)
16 siblings, 0 replies; 21+ messages in thread
From: asl at math dot spbu dot ru @ 2007-08-17 12:49 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from asl at math dot spbu dot ru 2007-08-17 12:49 -------
Quick example of the problem:
<function_decl 0x4bf6d00 _gfortran_matmul_r4
type <function_type 0x52495a0
type <void_type 0x4419840 void VOID
align 8 symtab 6 alias set -1
LLVM: void
pointer_to_this <pointer_type 0x44198a0>>
QI
size <integer_cst 0x441247c constant invariant 8>
unit size <integer_cst 0x4412498 constant invariant 1>
align 8 symtab 0 alias set -1
arg-types <tree_list 0x524d63c value <reference_type 0x5249540>
chain <tree_list 0x524d658 value <void_type 0x4419840 void>>>
pointer_to_this <pointer_type 0x5249600>>
addressable public external asm-frame-size 0 QI file rnflow.f90 line 2723
chain <function_decl 0x4bf6c00 dgetri>>
Note, we have only 1 arg for matmul_r4 and it's return value actually. And such
decl is attached to CALL_EXPR, which has 3 arguments to provide for callee :)
The gcf_show_symbol() returns (no formal args, as expected):
symbol _gfortran_matmul_r4 (REAL 4)(PROCEDURE UNKNOWN-INTENT
UNKNOWN-ACCESS INTRINSIC-PROC DIMENSION EXTERNAL FUNCTION)
Array spec:(2 AS_ASSUMED_SHAPE () () () () )
result: _gfortran_matmul_r4
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33097
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug fortran/33097] Function decl trees without proper argument list
2007-08-17 12:39 [Bug fortran/33097] New: Invalid decl trees are created for external intrinsics asl at math dot spbu dot ru
2007-08-17 12:42 ` [Bug fortran/33097] " asl at math dot spbu dot ru
2007-08-17 12:49 ` asl at math dot spbu dot ru
@ 2007-08-20 14:48 ` fxcoudert at gcc dot gnu dot org
2007-08-20 16:47 ` asl at math dot spbu dot ru
` (13 subsequent siblings)
16 siblings, 0 replies; 21+ messages in thread
From: fxcoudert at gcc dot gnu dot org @ 2007-08-20 14:48 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug fortran/33097] Function decl trees without proper argument list
2007-08-17 12:39 [Bug fortran/33097] New: Invalid decl trees are created for external intrinsics asl at math dot spbu dot ru
` (2 preceding siblings ...)
2007-08-20 14:48 ` [Bug fortran/33097] Function decl trees without proper argument list fxcoudert at gcc dot gnu dot org
@ 2007-08-20 16:47 ` asl at math dot spbu dot ru
2007-08-20 16:48 ` asl at math dot spbu dot ru
` (12 subsequent siblings)
16 siblings, 0 replies; 21+ messages in thread
From: asl at math dot spbu dot ru @ 2007-08-20 16:47 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug fortran/33097] Function decl trees without proper argument list
2007-08-17 12:39 [Bug fortran/33097] New: Invalid decl trees are created for external intrinsics asl at math dot spbu dot ru
` (3 preceding siblings ...)
2007-08-20 16:47 ` asl at math dot spbu dot ru
@ 2007-08-20 16:48 ` asl at math dot spbu dot ru
2007-08-20 16:51 ` fxcoudert at gcc dot gnu dot org
` (11 subsequent siblings)
16 siblings, 0 replies; 21+ messages in thread
From: asl at math dot spbu dot ru @ 2007-08-20 16:48 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug fortran/33097] Function decl trees without proper argument list
2007-08-17 12:39 [Bug fortran/33097] New: Invalid decl trees are created for external intrinsics asl at math dot spbu dot ru
` (4 preceding siblings ...)
2007-08-20 16:48 ` asl at math dot spbu dot ru
@ 2007-08-20 16:51 ` fxcoudert at gcc dot gnu dot org
2007-08-20 17:00 ` asl at math dot spbu dot ru
` (10 subsequent siblings)
16 siblings, 0 replies; 21+ messages in thread
From: fxcoudert at gcc dot gnu dot org @ 2007-08-20 16:51 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug fortran/33097] Function decl trees without proper argument list
2007-08-17 12:39 [Bug fortran/33097] New: Invalid decl trees are created for external intrinsics asl at math dot spbu dot ru
` (5 preceding siblings ...)
2007-08-20 16:51 ` fxcoudert at gcc dot gnu dot org
@ 2007-08-20 17:00 ` asl at math dot spbu dot ru
2007-10-17 10:17 ` asl at math dot spbu dot ru
` (9 subsequent siblings)
16 siblings, 0 replies; 21+ messages in thread
From: asl at math dot spbu dot ru @ 2007-08-20 17:00 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug fortran/33097] Function decl trees without proper argument list
2007-08-17 12:39 [Bug fortran/33097] New: Invalid decl trees are created for external intrinsics asl at math dot spbu dot ru
` (6 preceding siblings ...)
2007-08-20 17:00 ` asl at math dot spbu dot ru
@ 2007-10-17 10:17 ` asl at math dot spbu dot ru
2007-10-17 16:45 ` asl at math dot spbu dot ru
` (8 subsequent siblings)
16 siblings, 0 replies; 21+ messages in thread
From: asl at math dot spbu dot ru @ 2007-10-17 10:17 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug fortran/33097] Function decl trees without proper argument list
2007-08-17 12:39 [Bug fortran/33097] New: Invalid decl trees are created for external intrinsics asl at math dot spbu dot ru
` (7 preceding siblings ...)
2007-10-17 10:17 ` asl at math dot spbu dot ru
@ 2007-10-17 16:45 ` asl at math dot spbu dot ru
2007-10-17 16:46 ` asl at math dot spbu dot ru
` (7 subsequent siblings)
16 siblings, 0 replies; 21+ messages in thread
From: asl at math dot spbu dot ru @ 2007-10-17 16:45 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug fortran/33097] Function decl trees without proper argument list
2007-08-17 12:39 [Bug fortran/33097] New: Invalid decl trees are created for external intrinsics asl at math dot spbu dot ru
` (8 preceding siblings ...)
2007-10-17 16:45 ` asl at math dot spbu dot ru
@ 2007-10-17 16:46 ` asl at math dot spbu dot ru
2007-10-17 17:00 ` asl at math dot spbu dot ru
` (6 subsequent siblings)
16 siblings, 0 replies; 21+ messages in thread
From: asl at math dot spbu dot ru @ 2007-10-17 16:46 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug fortran/33097] Function decl trees without proper argument list
2007-08-17 12:39 [Bug fortran/33097] New: Invalid decl trees are created for external intrinsics asl at math dot spbu dot ru
` (9 preceding siblings ...)
2007-10-17 16:46 ` asl at math dot spbu dot ru
@ 2007-10-17 17:00 ` asl at math dot spbu dot ru
2007-10-17 17:14 ` fxcoudert at gcc dot gnu dot org
` (5 subsequent siblings)
16 siblings, 0 replies; 21+ messages in thread
From: asl at math dot spbu dot ru @ 2007-10-17 17:00 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug fortran/33097] Function decl trees without proper argument list
2007-08-17 12:39 [Bug fortran/33097] New: Invalid decl trees are created for external intrinsics asl at math dot spbu dot ru
` (10 preceding siblings ...)
2007-10-17 17:00 ` asl at math dot spbu dot ru
@ 2007-10-17 17:14 ` fxcoudert at gcc dot gnu dot org
2007-10-17 17:28 ` asl at math dot spbu dot ru
` (4 subsequent siblings)
16 siblings, 0 replies; 21+ messages in thread
From: fxcoudert at gcc dot gnu dot org @ 2007-10-17 17:14 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug fortran/33097] Function decl trees without proper argument list
2007-08-17 12:39 [Bug fortran/33097] New: Invalid decl trees are created for external intrinsics asl at math dot spbu dot ru
` (11 preceding siblings ...)
2007-10-17 17:14 ` fxcoudert at gcc dot gnu dot org
@ 2007-10-17 17:28 ` asl at math dot spbu dot ru
2009-01-03 21:31 ` dfranke at gcc dot gnu dot org
` (3 subsequent siblings)
16 siblings, 0 replies; 21+ messages in thread
From: asl at math dot spbu dot ru @ 2007-10-17 17:28 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug fortran/33097] Function decl trees without proper argument list
2007-08-17 12:39 [Bug fortran/33097] New: Invalid decl trees are created for external intrinsics asl at math dot spbu dot ru
` (12 preceding siblings ...)
2007-10-17 17:28 ` asl at math dot spbu dot ru
@ 2009-01-03 21:31 ` dfranke at gcc dot gnu dot org
2010-05-01 20:20 ` dfranke at gcc dot gnu dot org
` (2 subsequent siblings)
16 siblings, 0 replies; 21+ messages in thread
From: dfranke at gcc dot gnu dot org @ 2009-01-03 21:31 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug fortran/33097] Function decl trees without proper argument list
2007-08-17 12:39 [Bug fortran/33097] New: Invalid decl trees are created for external intrinsics asl at math dot spbu dot ru
` (13 preceding siblings ...)
2009-01-03 21:31 ` dfranke at gcc dot gnu dot org
@ 2010-05-01 20:20 ` dfranke at gcc dot gnu dot org
2010-07-15 23:06 ` steven at gcc dot gnu dot org
2010-07-16 7:17 ` burnus at gcc dot gnu dot org
16 siblings, 0 replies; 21+ messages in thread
From: dfranke at gcc dot gnu dot org @ 2010-05-01 20:20 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug fortran/33097] Function decl trees without proper argument list
2007-08-17 12:39 [Bug fortran/33097] New: Invalid decl trees are created for external intrinsics asl at math dot spbu dot ru
` (14 preceding siblings ...)
2010-05-01 20:20 ` dfranke at gcc dot gnu dot org
@ 2010-07-15 23:06 ` steven at gcc dot gnu dot org
2010-07-16 7:17 ` burnus at gcc dot gnu dot org
16 siblings, 0 replies; 21+ messages in thread
From: steven at gcc dot gnu dot org @ 2010-07-15 23:06 UTC (permalink / raw)
To: gcc-bugs
--
steven at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33097
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug fortran/33097] Function decl trees without proper argument list
2007-08-17 12:39 [Bug fortran/33097] New: Invalid decl trees are created for external intrinsics asl at math dot spbu dot ru
` (15 preceding siblings ...)
2010-07-15 23:06 ` steven at gcc dot gnu dot org
@ 2010-07-16 7:17 ` burnus at gcc dot gnu dot org
16 siblings, 0 replies; 21+ messages in thread
From: burnus at gcc dot gnu dot org @ 2010-07-16 7:17 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 21+ messages in thread