public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/15809] New: ICE Using Pointer Functions
@ 2004-06-03 20:12 giese025 at tc dot umn dot edu
2004-06-03 20:13 ` [Bug fortran/15809] " giese025 at tc dot umn dot edu
` (15 more replies)
0 siblings, 16 replies; 28+ messages in thread
From: giese025 at tc dot umn dot edu @ 2004-06-03 20:12 UTC (permalink / raw)
To: gcc-bugs
The file foo.f95 compiles without error nor warning with the NAG f95 compiler
but produces an internal compiler error with g95 (x86 Linux Binary (06/02/04)
from http://www.g95.org).
The error messege produced is:
foo.f95: In function `reallocate_hnv__':
foo.f95:1: internal compiler error: in find_function_data, at function.c:311
This was performed on a Redhat 9 machine.
The program simply contains a function and a subroutine. The function produces
a pointer of a specified vector length and fills in the array from an input
pointer. The input pointer is then deallocated.
The function itself will compile fine, but produces the ICE when used in another
subroutine.
foo.f95 will be submitted as an attachment in the next comment.
--
Summary: ICE Using Pointer Functions
Product: gcc
Version: tree-ssa
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: giese025 at tc dot umn dot edu
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15809
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug fortran/15809] ICE Using Pointer Functions
2004-06-03 20:12 [Bug fortran/15809] New: ICE Using Pointer Functions giese025 at tc dot umn dot edu
@ 2004-06-03 20:13 ` giese025 at tc dot umn dot edu
2004-06-03 20:21 ` pinskia at gcc dot gnu dot org
` (14 subsequent siblings)
15 siblings, 0 replies; 28+ messages in thread
From: giese025 at tc dot umn dot edu @ 2004-06-03 20:13 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From giese025 at tc dot umn dot edu 2004-06-03 20:13 -------
Created an attachment (id=6460)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=6460&action=view)
Test program to reproduce ICE
Attached file that reproduces the internal compiler error.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15809
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug fortran/15809] ICE Using Pointer Functions
2004-06-03 20:12 [Bug fortran/15809] New: ICE Using Pointer Functions giese025 at tc dot umn dot edu
2004-06-03 20:13 ` [Bug fortran/15809] " giese025 at tc dot umn dot edu
@ 2004-06-03 20:21 ` pinskia at gcc dot gnu dot org
2004-07-11 17:10 ` tobi at gcc dot gnu dot org
` (13 subsequent siblings)
15 siblings, 0 replies; 28+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-06-03 20:21 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pinskia at gcc dot gnu dot org 2004-06-03 20:21 -------
There is a different bug in gfortran with this code:
f951: /home/gates/pinskia/src/gnu/gcc/src/gcc/fortran/trans-array.c:184: gfc_conv_descriptor_data:
Assertion `(__extension__ ({ const tree __t = (type); if (tree_code_type[(int) (((enum tree_code) (__t)-
>common.code))] != ('t')) tree_class_check_failed (__t, ('t'), "/home/gates/pinskia/src/gnu/gcc/src/gcc/
fortran/trans-array.c", 184, __FUNCTION__); __t; })->type.lang_flag_1)' failed.
Note gfortran and g95 are two different projects, gfortran forked off of g95 to so that the source would
be more available and intergrated with the GCC project, gfortran is now included in snapshots of 3.5.0.
--
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever Confirmed| |1
Keywords| |ice-on-valid-code
Last reconfirmed|0000-00-00 00:00:00 |2004-06-03 20:21:06
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15809
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug fortran/15809] ICE Using Pointer Functions
2004-06-03 20:12 [Bug fortran/15809] New: ICE Using Pointer Functions giese025 at tc dot umn dot edu
2004-06-03 20:13 ` [Bug fortran/15809] " giese025 at tc dot umn dot edu
2004-06-03 20:21 ` pinskia at gcc dot gnu dot org
@ 2004-07-11 17:10 ` tobi at gcc dot gnu dot org
2004-08-25 22:10 ` tobi at gcc dot gnu dot org
` (12 subsequent siblings)
15 siblings, 0 replies; 28+ messages in thread
From: tobi at gcc dot gnu dot org @ 2004-07-11 17:10 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From tobi at gcc dot gnu dot org 2004-07-11 17:10 -------
Reduced testcase:
SUBROUTINE A(p,LEN)
CHARACTER(LEN=LEN), DIMENSION(:), POINTER :: p
IF ( .NOT. ASSOCIATED(p) ) THEN
END IF
END SUBROUTINE A
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15809
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug fortran/15809] ICE Using Pointer Functions
2004-06-03 20:12 [Bug fortran/15809] New: ICE Using Pointer Functions giese025 at tc dot umn dot edu
` (2 preceding siblings ...)
2004-07-11 17:10 ` tobi at gcc dot gnu dot org
@ 2004-08-25 22:10 ` tobi at gcc dot gnu dot org
2004-09-22 7:48 ` c dot lemmen at fz-juelich dot de
` (11 subsequent siblings)
15 siblings, 0 replies; 28+ messages in thread
From: tobi at gcc dot gnu dot org @ 2004-08-25 22:10 UTC (permalink / raw)
To: gcc-bugs
--
What |Removed |Added
----------------------------------------------------------------------------
BugsThisDependsOn| |17193
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15809
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug fortran/15809] ICE Using Pointer Functions
2004-06-03 20:12 [Bug fortran/15809] New: ICE Using Pointer Functions giese025 at tc dot umn dot edu
` (3 preceding siblings ...)
2004-08-25 22:10 ` tobi at gcc dot gnu dot org
@ 2004-09-22 7:48 ` c dot lemmen at fz-juelich dot de
2004-12-14 17:53 ` pinskia at gcc dot gnu dot org
` (10 subsequent siblings)
15 siblings, 0 replies; 28+ messages in thread
From: c dot lemmen at fz-juelich dot de @ 2004-09-22 7:48 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From c dot lemmen at fz-juelich dot de 2004-09-22 07:48 -------
Confirmed with GNU F95 version 4.0.0 20040921 on Sep-22, 2004
Problem only occurs when the pointer is an <strong>argument</strong> to the
function and not with logical,real,integer types
Note that this error occurs on line 183 now:
internal compiler error: in gfc_conv_descriptor_data, at fortran/trans-array.c:183
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15809
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug fortran/15809] ICE Using Pointer Functions
2004-06-03 20:12 [Bug fortran/15809] New: ICE Using Pointer Functions giese025 at tc dot umn dot edu
` (4 preceding siblings ...)
2004-09-22 7:48 ` c dot lemmen at fz-juelich dot de
@ 2004-12-14 17:53 ` pinskia at gcc dot gnu dot org
2005-04-03 2:25 ` szalai at mit dot edu
` (9 subsequent siblings)
15 siblings, 0 replies; 28+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-12-14 17:53 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-14 17:53 -------
*** Bug 18991 has been marked as a duplicate of this bug. ***
--
What |Removed |Added
----------------------------------------------------------------------------
CC| |tow21 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15809
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug fortran/15809] ICE Using Pointer Functions
2004-06-03 20:12 [Bug fortran/15809] New: ICE Using Pointer Functions giese025 at tc dot umn dot edu
` (5 preceding siblings ...)
2004-12-14 17:53 ` pinskia at gcc dot gnu dot org
@ 2005-04-03 2:25 ` szalai at mit dot edu
2005-06-05 22:44 ` pault at gcc dot gnu dot org
` (8 subsequent siblings)
15 siblings, 0 replies; 28+ messages in thread
From: szalai at mit dot edu @ 2005-04-03 2:25 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From szalai at mit dot edu 2005-04-03 02:25 -------
This also occurs with the MUMPS parallel solver library.
The testcase testcase in this report now occurs as follows:
test5.f: In function ‘a’:
test5.f:1: internal compiler error: in gfc_conv_descriptor_data, at
fortran/trans-array.c:144
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
The compiler version
gcc version 4.0.0 20050326 (prerelease)
(this is a snapshot)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15809
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug fortran/15809] ICE Using Pointer Functions
2004-06-03 20:12 [Bug fortran/15809] New: ICE Using Pointer Functions giese025 at tc dot umn dot edu
` (6 preceding siblings ...)
2005-04-03 2:25 ` szalai at mit dot edu
@ 2005-06-05 22:44 ` pault at gcc dot gnu dot org
2005-08-30 20:44 ` erik dot edelmann at iki dot fi
` (7 subsequent siblings)
15 siblings, 0 replies; 28+ messages in thread
From: pault at gcc dot gnu dot org @ 2005-06-05 22:44 UTC (permalink / raw)
To: gcc-bugs
--
Bug 15809 depends on bug 17193, which changed state.
Bug 17193 Summary: [meta-bug] Pointer arguments not working correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17193
What |Old Value |New Value
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15809
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug fortran/15809] ICE Using Pointer Functions
2004-06-03 20:12 [Bug fortran/15809] New: ICE Using Pointer Functions giese025 at tc dot umn dot edu
` (7 preceding siblings ...)
2005-06-05 22:44 ` pault at gcc dot gnu dot org
@ 2005-08-30 20:44 ` erik dot edelmann at iki dot fi
2005-08-31 19:39 ` tobi at gcc dot gnu dot org
` (6 subsequent siblings)
15 siblings, 0 replies; 28+ messages in thread
From: erik dot edelmann at iki dot fi @ 2005-08-30 20:44 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From erik dot edelmann at iki dot fi 2005-08-30 20:28 -------
Hmm ... With current version of gfortran (4.1.0 20050830), the reduced testcase
by Tobias gives the error message
bug.f90: In function 'a':
bug.f90:3: internal compiler error: in gfc_trans_deferred_array, at
fortran/trans-array.c:4005
while the original testcase by Tim gives
bug2.f90: In function 'allocateifneeded_hnv':
bug2.f90:38: internal compiler error: in gfc_conv_function_call, at
fortran/trans-expr.c:1107
I think we are dealing with (at least) two different non-related bugs here.
--
What |Removed |Added
----------------------------------------------------------------------------
CC| |erik dot edelmann at iki dot
| |fi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15809
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug fortran/15809] ICE Using Pointer Functions
2004-06-03 20:12 [Bug fortran/15809] New: ICE Using Pointer Functions giese025 at tc dot umn dot edu
` (8 preceding siblings ...)
2005-08-30 20:44 ` erik dot edelmann at iki dot fi
@ 2005-08-31 19:39 ` tobi at gcc dot gnu dot org
2005-09-02 11:34 ` tobi at gcc dot gnu dot org
` (5 subsequent siblings)
15 siblings, 0 replies; 28+ messages in thread
From: tobi at gcc dot gnu dot org @ 2005-08-31 19:39 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From tobi at gcc dot gnu dot org 2005-08-31 19:35 -------
Probably Paul Thomas' character fixes play a role in making those two different
bugs.
--
What |Removed |Added
----------------------------------------------------------------------------
CC| |tobi at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15809
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug fortran/15809] ICE Using Pointer Functions
2004-06-03 20:12 [Bug fortran/15809] New: ICE Using Pointer Functions giese025 at tc dot umn dot edu
` (9 preceding siblings ...)
2005-08-31 19:39 ` tobi at gcc dot gnu dot org
@ 2005-09-02 11:34 ` tobi at gcc dot gnu dot org
2005-09-02 11:58 ` erik dot edelmann at iki dot fi
` (4 subsequent siblings)
15 siblings, 0 replies; 28+ messages in thread
From: tobi at gcc dot gnu dot org @ 2005-09-02 11:34 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From tobi at gcc dot gnu dot org 2005-09-02 11:34 -------
According to Erik Richard's patch for PR15326 fixes one of those two bugs (I
assume the latter?), adding the dependency so that we will keep track of this.
--
What |Removed |Added
----------------------------------------------------------------------------
BugsThisDependsOn| |15326
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15809
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug fortran/15809] ICE Using Pointer Functions
2004-06-03 20:12 [Bug fortran/15809] New: ICE Using Pointer Functions giese025 at tc dot umn dot edu
` (10 preceding siblings ...)
2005-09-02 11:34 ` tobi at gcc dot gnu dot org
@ 2005-09-02 11:58 ` erik dot edelmann at iki dot fi
2005-09-02 15:39 ` Tobias dot Schlueter at physik dot uni-muenchen dot de
` (3 subsequent siblings)
15 siblings, 0 replies; 28+ messages in thread
From: erik dot edelmann at iki dot fi @ 2005-09-02 11:58 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From erik dot edelmann at iki dot fi 2005-09-02 11:56 -------
(In reply to comment #9)
> According to Erik Richard's patch for PR15326 fixes one of those two bugs (I
> assume the latter?), adding the dependency so that we will keep track of this.
Yes, it's the latter bug that Richard's patch fixes.
I could add that I posted a patch to fix the other bug here:
http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01861.html
I'm not yet sure if this is the best way to deal with the problem, though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15809
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug fortran/15809] ICE Using Pointer Functions
2004-06-03 20:12 [Bug fortran/15809] New: ICE Using Pointer Functions giese025 at tc dot umn dot edu
` (11 preceding siblings ...)
2005-09-02 11:58 ` erik dot edelmann at iki dot fi
@ 2005-09-02 15:39 ` Tobias dot Schlueter at physik dot uni-muenchen dot de
2005-09-06 21:10 ` erik dot edelmann at iki dot fi
` (2 subsequent siblings)
15 siblings, 0 replies; 28+ messages in thread
From: Tobias dot Schlueter at physik dot uni-muenchen dot de @ 2005-09-02 15:39 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From Tobias dot Schlueter at physik dot uni-muenchen dot de 2005-09-02 15:38 -------
Subject: Re: ICE Using Pointer Functions
erik dot edelmann at iki dot fi wrote:
> Yes, it's the latter bug that Richard's patch fixes.
>
> I could add that I posted a patch to fix the other bug here:
> http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01861.html
> I'm not yet sure if this is the best way to deal with the problem, though.
I vaguely remember seeing a case where allowing a PARM_DECL fixed a bug, but
wasn't still not quite right. I'll try to find out what this was (hopefully
I'll have somethign written somewhere on it)
- Tobi
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15809
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug fortran/15809] ICE Using Pointer Functions
2004-06-03 20:12 [Bug fortran/15809] New: ICE Using Pointer Functions giese025 at tc dot umn dot edu
` (12 preceding siblings ...)
2005-09-02 15:39 ` Tobias dot Schlueter at physik dot uni-muenchen dot de
@ 2005-09-06 21:10 ` erik dot edelmann at iki dot fi
2005-09-08 18:51 ` rsandifo at gcc dot gnu dot org
2005-09-18 19:53 ` tkoenig at gcc dot gnu dot org
15 siblings, 0 replies; 28+ messages in thread
From: erik dot edelmann at iki dot fi @ 2005-09-06 21:10 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From erik dot edelmann at iki dot fi 2005-09-06 21:10 -------
With my patch, the reduced testcase by Tobi compiles, but this slightly longer
testcase doesn't:
$ cat bug7.f90
SUBROUTINE A(p,LEN)
CHARACTER(LEN=LEN), DIMENSION(:), POINTER :: p
IF ( .NOT. ASSOCIATED(p) ) THEN
allocate(p(1))
END IF
END SUBROUTINE A
$ gfortran bug7.f90
bug7.f90: In function 'a':
bug7.f90:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
I'm not yet sure if it is because my patch doesn't solve the bug after all, or
if this is yet another unrelated bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15809
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug fortran/15809] ICE Using Pointer Functions
2004-06-03 20:12 [Bug fortran/15809] New: ICE Using Pointer Functions giese025 at tc dot umn dot edu
` (13 preceding siblings ...)
2005-09-06 21:10 ` erik dot edelmann at iki dot fi
@ 2005-09-08 18:51 ` rsandifo at gcc dot gnu dot org
2005-09-18 19:53 ` tkoenig at gcc dot gnu dot org
15 siblings, 0 replies; 28+ messages in thread
From: rsandifo at gcc dot gnu dot org @ 2005-09-08 18:51 UTC (permalink / raw)
To: gcc-bugs
--
Bug 15809 depends on bug 15326, which changed state.
Bug 15326 Summary: ICE with assumed length character strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15326
What |Old Value |New Value
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15809
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug fortran/15809] ICE Using Pointer Functions
2004-06-03 20:12 [Bug fortran/15809] New: ICE Using Pointer Functions giese025 at tc dot umn dot edu
` (14 preceding siblings ...)
2005-09-08 18:51 ` rsandifo at gcc dot gnu dot org
@ 2005-09-18 19:53 ` tkoenig at gcc dot gnu dot org
15 siblings, 0 replies; 28+ messages in thread
From: tkoenig at gcc dot gnu dot org @ 2005-09-18 19:53 UTC (permalink / raw)
To: gcc-bugs
--
Bug 15809 depends on bug 15326, which changed state.
Bug 15326 Summary: [4.0 only] ICE with assumed length character strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15326
What |Old Value |New Value
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15809
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug fortran/15809] ICE Using Pointer Functions
[not found] <bug-15809-7776@http.gcc.gnu.org/bugzilla/>
` (9 preceding siblings ...)
2005-12-07 6:20 ` pault at gcc dot gnu dot org
@ 2005-12-12 20:10 ` pinskia at gcc dot gnu dot org
10 siblings, 0 replies; 28+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-12-12 20:10 UTC (permalink / raw)
To: gcc-bugs
--
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15809
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug fortran/15809] ICE Using Pointer Functions
[not found] <bug-15809-7776@http.gcc.gnu.org/bugzilla/>
` (8 preceding siblings ...)
2005-12-05 11:14 ` jakub at gcc dot gnu dot org
@ 2005-12-07 6:20 ` pault at gcc dot gnu dot org
2005-12-12 20:10 ` pinskia at gcc dot gnu dot org
10 siblings, 0 replies; 28+ messages in thread
From: pault at gcc dot gnu dot org @ 2005-12-07 6:20 UTC (permalink / raw)
To: gcc-bugs
------- Comment #22 from pault at gcc dot gnu dot org 2005-12-07 06:20 -------
Subject: Bug 15809
Author: pault
Date: Wed Dec 7 06:20:21 2005
New Revision: 108150
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108150
Log:
2005-12-07 Paul Thomas <pault@gcc.gnu.org>
PR fortran/15809
* trans-decl.c (gfc_get_symbol_decl): In the case of automatic
character length, dummy pointer arrays, build an expression for
unit size of the array elements, to be picked up and used in the
descriptor dtype.
* trans-io.c (gfc_trans_transfer): Modify the detection of
components of derived type arrays to use the gfc_expr references
instead of the array descriptor dtype. This allows the latter
to contain expressions.
2005-12-07 Paul Thomas <pault@gcc.gnu.org>
PR fortran/15809
* gfortran.dg/auto_char_dummy_array.f90: New test.
Added:
branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/auto_char_dummy_array_1.f90
Modified:
branches/gcc-4_1-branch/gcc/fortran/ChangeLog
branches/gcc-4_1-branch/gcc/fortran/trans-array.c
branches/gcc-4_1-branch/gcc/fortran/trans-decl.c
branches/gcc-4_1-branch/gcc/fortran/trans-io.c
branches/gcc-4_1-branch/gcc/testsuite/ChangeLog
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15809
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug fortran/15809] ICE Using Pointer Functions
[not found] <bug-15809-7776@http.gcc.gnu.org/bugzilla/>
` (7 preceding siblings ...)
2005-11-30 19:26 ` pault at gcc dot gnu dot org
@ 2005-12-05 11:14 ` jakub at gcc dot gnu dot org
2005-12-07 6:20 ` pault at gcc dot gnu dot org
2005-12-12 20:10 ` pinskia at gcc dot gnu dot org
10 siblings, 0 replies; 28+ messages in thread
From: jakub at gcc dot gnu dot org @ 2005-12-05 11:14 UTC (permalink / raw)
To: gcc-bugs
------- Comment #21 from jakub at gcc dot gnu dot org 2005-12-05 11:14 -------
Subject: Bug 15809
Author: jakub
Date: Mon Dec 5 11:14:10 2005
New Revision: 108052
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108052
Log:
PR fortran/15809
* trans-decl.c (gfc_get_symbol_decl): Revert 2005-11-30 and
2005-12-01 changes.
(gfc_trans_vla_type_sizes): Also "gimplify"
GFC_TYPE_ARRAY_DATAPTR_TYPE for GFC_DESCRIPTOR_TYPE_P types.
* trans-array.c (gfc_trans_deferred_array): Call
gfc_trans_vla_type_sizes.
Modified:
branches/gomp-20050608-branch/gcc/fortran/ChangeLog.gomp
branches/gomp-20050608-branch/gcc/fortran/trans-array.c
branches/gomp-20050608-branch/gcc/fortran/trans-decl.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15809
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug fortran/15809] ICE Using Pointer Functions
[not found] <bug-15809-7776@http.gcc.gnu.org/bugzilla/>
` (6 preceding siblings ...)
2005-11-30 17:26 ` pault at gcc dot gnu dot org
@ 2005-11-30 19:26 ` pault at gcc dot gnu dot org
2005-12-05 11:14 ` jakub at gcc dot gnu dot org
` (2 subsequent siblings)
10 siblings, 0 replies; 28+ messages in thread
From: pault at gcc dot gnu dot org @ 2005-11-30 19:26 UTC (permalink / raw)
To: gcc-bugs
------- Comment #20 from pault at gcc dot gnu dot org 2005-11-30 19:26 -------
Fixed on trunk, just waiting 24 hours before fixing in 4.0 and 4.1
--
pault at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15809
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug fortran/15809] ICE Using Pointer Functions
[not found] <bug-15809-7776@http.gcc.gnu.org/bugzilla/>
` (5 preceding siblings ...)
2005-11-23 14:26 ` paul dot richard dot thomas at cea dot fr
@ 2005-11-30 17:26 ` pault at gcc dot gnu dot org
2005-11-30 19:26 ` pault at gcc dot gnu dot org
` (3 subsequent siblings)
10 siblings, 0 replies; 28+ messages in thread
From: pault at gcc dot gnu dot org @ 2005-11-30 17:26 UTC (permalink / raw)
To: gcc-bugs
------- Comment #19 from pault at gcc dot gnu dot org 2005-11-30 17:26 -------
Subject: Bug 15809
Author: pault
Date: Wed Nov 30 17:26:40 2005
New Revision: 107727
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107727
Log:
2005-11-30 Paul Thomas <pault@gcc.gnu.org>
PR fortran/15809
* trans-decl.c (gfc_get_symbol_decl): In the case of automatic
character length, dummy pointer arrays, build an expression for
unit size of the array elements, to be picked up and used in the
descriptor dtype.
* trans-io.c (gfc_trans_transfer): Modify the detection of
components of derived type arrays to use the gfc_expr references
instead of the array descriptor dtype. This allows the latter
to contain expressions.
2005-11-30 Erik Edelmann <erik.edelmann@iki.fi>
PR fortran/15809
* trans-array.c (gfc_trans_deferred_array): Allow PARM_DECLs past
in addition to VAR_DECLs.
2005-11-30 Paul Thomas <pault@gcc.gnu.org>
PR fortran/15809
* gfortran.dg/auto_char_dummy_array.f90: New test.
Added:
trunk/gcc/testsuite/gfortran.dg/auto_char_dummy_array_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c
trunk/gcc/fortran/trans-decl.c
trunk/gcc/fortran/trans-io.c
trunk/gcc/testsuite/ChangeLog
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15809
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug fortran/15809] ICE Using Pointer Functions
[not found] <bug-15809-7776@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2005-11-22 20:16 ` pault at gcc dot gnu dot org
@ 2005-11-23 14:26 ` paul dot richard dot thomas at cea dot fr
2005-11-30 17:26 ` pault at gcc dot gnu dot org
` (4 subsequent siblings)
10 siblings, 0 replies; 28+ messages in thread
From: paul dot richard dot thomas at cea dot fr @ 2005-11-23 14:26 UTC (permalink / raw)
To: gcc-bugs
------- Comment #18 from paul dot richard dot thomas at cea dot fr 2005-11-23 14:26 -------
(In reply to comment #15)
> I cannot tell why, but it seems to me that Paul Thomas' test case is no valid
Hej Sven!
You quite correctly picked up that it does not have an explicit interface and
so will give nonsense. Making it contained or writing an interface converts my
rubbish into legal code.
I have made progress in converting pointer arrays into references to pointer
arrays:
The patch below works for pointer assignments with integers and characters and
returns pointer dummy arguments correctly.
There is still a problem (seg fault) with assignments of characters. This comes
about because dtype does not contain the size, as is apparent from the code at
the end of the message. (see the dtypes in the subroutine).
There are also some issues with alignment during pointer assignments.
This damn thing is going to work, legal fortran or not!!!!
Both the examples below work.
Paul Thomas 23rd Nov 2005
Danger: Cygwin source => whitespace issues.
*** trunk/gcc/fortran/trans-array.c Wed Nov 23 14:44:18 2005
--- trunk/gcc/fortran/trans-array.c.orig Wed Nov 23 14:45:15 2005
*************** gfc_trans_deferred_array (gfc_symbol * s
*** 4173,4179 ****
gfc_init_block (&fnblock);
! gcc_assert (TREE_CODE (sym->backend_decl) == VAR_DECL);
if (sym->ts.type == BT_CHARACTER
&& !INTEGER_CST_P (sym->ts.cl->backend_decl))
gfc_trans_init_string_length (sym->ts.cl, &fnblock);
--- 4173,4181 ----
gfc_init_block (&fnblock);
! gcc_assert (TREE_CODE (sym->backend_decl) == VAR_DECL
! || TREE_CODE (sym->backend_decl) == PARM_DECL);
!
if (sym->ts.type == BT_CHARACTER
&& !INTEGER_CST_P (sym->ts.cl->backend_decl))
gfc_trans_init_string_length (sym->ts.cl, &fnblock);
*** trunk/gcc/fortran/trans-expr.c Wed Nov 23 14:55:20 2005
--- trunk/gcc/fortran/trans-expr.c.orig Wed Nov 23 14:56:37 2005
*************** gfc_conv_variable (gfc_se * se, gfc_expr
*** 396,401 ****
--- 396,404 ----
|| !sym->attr.dimension))
se->expr = gfc_build_indirect_ref (se->expr);
}
+
+ if (sym->attr.pointer && sym->attr.dummy && sym->attr.dimension)
+ se->expr = gfc_build_indirect_ref (se->expr);
ref = expr->ref;
}
*************** gfc_conv_function_call (gfc_se * se, gfc
*** 1608,1614 ****
&& !formal->sym->attr.pointer
&& formal->sym->as->type != AS_ASSUMED_SHAPE;
f = f || !sym->attr.always_explicit;
! gfc_conv_array_parameter (&parmse, arg->expr, argss, f);
}
}
--- 1611,1619 ----
&& !formal->sym->attr.pointer
&& formal->sym->as->type != AS_ASSUMED_SHAPE;
f = f || !sym->attr.always_explicit;
! gfc_conv_array_parameter (&parmse, arg->expr, argss, f);
! if (formal != NULL && formal->sym->attr.pointer &&
formal->sym->attr.dimension)
! parmse.expr = gfc_build_addr_expr (NULL, parmse.expr);
}
}
*** trunk/gcc/fortran/trans-types.c Wed Nov 23 13:48:37 2005
--- trunk/gcc/fortran/trans-types.c.orig Wed Nov 23 13:49:06 2005
*************** gfc_sym_type (gfc_symbol * sym)
*** 1333,1338 ****
--- 1333,1342 ----
}
else
type = gfc_build_array_type (type, sym->as);
+
+ if (sym->attr.pointer && sym->attr.dummy)
+ type = build_reference_type (type);
+
}
else
{
!=============================================================================
module global
CHARACTER(14), DIMENSION(2), target :: t
end module global
program oh_no_not_pr15908_again
CHARACTER(12), DIMENSION(:), POINTER :: ptr
allocate (ptr(2))
ptr = "xyz"
call a (ptr, 12)
IF ( .NOT. ASSOCIATED(ptr) ) THEN
print *, "not associated in MAIN"
else
print *, "associated in MAIN ", size(ptr,1), len (ptr), ptr
END IF
contains
SUBROUTINE A(p, l)
use global
CHARACTER(l), DIMENSION(:), POINTER :: p
t = "abc"
IF ( .NOT. ASSOCIATED(p) ) THEN
p => t
print *, "not associated in A ", size(p,1), len (p), p
else
print *, "associated in A ", size(p,1), len (p), p
t = "lmn"
p => t
END IF
END SUBROUTINE A
end program oh_no_not_pr15908_again
!=========================integer version=========================
module global
integer, DIMENSION(2), target :: t
end module global
integer, DIMENSION(:), POINTER :: ptr
allocate (ptr(2))
ptr = 123
IF ( .NOT. ASSOCIATED(ptr) ) THEN
print *, "not associated in MAIN"
else
print *, "associated in MAIN ", size(ptr,1), ptr
END IF
call a (ptr, 12)
IF ( .NOT. ASSOCIATED(ptr) ) THEN
print *, "not associated in MAIN"
else
print *, "associated in MAIN ", size(ptr,1), ptr
END IF
contains
SUBROUTINE A(p, l)
use global
integer, DIMENSION(:), POINTER :: p
t = 456
IF ( .NOT. ASSOCIATED(p) ) THEN
p => t
print *, "not associated in A ", size(p,1), p
else
print *, "associated in A ", size(p,1), p
t = 789
p => t
print *, "associated in A ", size(p,1), p
END IF
END SUBROUTINE A
end
=========================code for character version====================
a (p, l, _p)
{
extern char t[2][1:14];
int4 .p;
.p = *l;
{
int4 S.0;
S.0 = 1;
while (1)
{
if (S.0 > 2) goto L.1; else (void) 0;
_gfortran_copy_string (14, &t[NON_LVALUE_EXPR <S.0> + -1], 3, "abc");
S.0 = S.0 + 1;
}
L.1:;
}
if ((char[0:][1:] *) (*p)->data != 0B == 0)
{
(*p)->dtype = 49;
(*p)->dim[0].lbound = 1;
(*p)->dim[0].ubound = 2;
(*p)->dim[0].stride = 1;
(*p)->data = (void *) (char[0:][1:14] *) &t[0];
(*p)->offset = -1;
_gfortran_filename = "pr15809.f90";
_gfortran_line = 24;
_gfortran_ioparm.unit = 6;
_gfortran_ioparm.list_format = 1;
_gfortran_st_write ();
_gfortran_transfer_character ("not associated in A ", 22);
{
int4 D.577;
D.577 = _gfortran_size1 ((struct array1_unknown *) *p, 1);
_gfortran_transfer_integer (&D.577, 4);
}
{
int4 D.578;
D.578 = .p;
_gfortran_transfer_integer (&D.578, 4);
}
_gfortran_transfer_array ((struct array1_unknown *) *p, 1, .p);
_gfortran_st_write_done ();
}
else
{
_gfortran_filename = "pr15809.f90";
_gfortran_line = 26;
_gfortran_ioparm.unit = 6;
_gfortran_ioparm.list_format = 1;
_gfortran_st_write ();
_gfortran_transfer_character ("associated in A ", 22);
{
int4 D.579;
D.579 = _gfortran_size1 ((struct array1_unknown *) *p, 1);
_gfortran_transfer_integer (&D.579, 4);
}
{
int4 D.580;
D.580 = .p;
_gfortran_transfer_integer (&D.580, 4);
}
_gfortran_transfer_array ((struct array1_unknown *) *p, 1, .p);
_gfortran_st_write_done ();
{
int4 S.1;
S.1 = 1;
while (1)
{
if (S.1 > 2) goto L.2; else (void) 0;
_gfortran_copy_string (14, &t[NON_LVALUE_EXPR <S.1> + -1], 3,
"lmn";
S.1 = S.1 + 1;
}
L.2:;
}
(*p)->dtype = 49;
(*p)->dim[0].lbound = 1;
(*p)->dim[0].ubound = 2;
(*p)->dim[0].stride = 1;
(*p)->data = (void *) (char[0:][1:14] *) &t[0];
(*p)->offset = -1;
}
}
MAIN__ ()
{
struct array1_unknown ptr;
static void a (struct array1_unknown & &, int4 &, int4);
ptr.data = 0B;
{
void * * D.584;
ptr.dtype = 1585;
ptr.dim[0].lbound = 1;
ptr.dim[0].ubound = 2;
ptr.dim[0].stride = 1;
D.584 = &ptr.data;
_gfortran_allocate (D.584, 48, 0);
ptr.offset = -1;
}
{
int4 D.587;
int4 D.586;
char[0:][1:24] * D.585;
D.585 = (char[0:][1:24] *) ptr.data;
D.586 = ptr.offset;
D.587 = ptr.dim[0].lbound;
{
int4 D.589;
int4 S.2;
D.589 = ptr.dim[0].stride;
S.2 = D.587;
while (1)
{
if (S.2 > ptr.dim[0].ubound) goto L.3; else (void) 0;
_gfortran_copy_string (24, &(*D.585)[NON_LVALUE_EXPR <S.2> * D.589 +
.586], 3, "xyz");
S.2 = S.2 + 1;
}
L.3:;
}
}
{
int4 C.591 = 12;
a (&&ptr, &C.591, 24);
}
if ((char[0:][1:24] *) ptr.data != 0B == 0)
{
_gfortran_filename = "pr15809.f90";
_gfortran_line = 11;
_gfortran_ioparm.unit = 6;
_gfortran_ioparm.list_format = 1;
_gfortran_st_write ();
_gfortran_transfer_character ("not associated in MAIN", 22);
_gfortran_st_write_done ();
}
else
{
_gfortran_filename = "pr15809.f90";
_gfortran_line = 13;
_gfortran_ioparm.unit = 6;
_gfortran_ioparm.list_format = 1;
_gfortran_st_write ();
_gfortran_transfer_character ("associated in MAIN ", 22);
{
int4 D.592;
D.592 = _gfortran_size1 (&ptr, 1);
_gfortran_transfer_integer (&D.592, 4);
}
{
int4 C.593 = 24;
_gfortran_transfer_integer (&C.593, 4);
}
_gfortran_transfer_array (&ptr, 1, 24);
_gfortran_st_write_done ();
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15809
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug fortran/15809] ICE Using Pointer Functions
[not found] <bug-15809-7776@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2005-11-21 18:08 ` Tobias dot Schlueter at physik dot uni-muenchen dot de
@ 2005-11-22 20:16 ` pault at gcc dot gnu dot org
2005-11-23 14:26 ` paul dot richard dot thomas at cea dot fr
` (5 subsequent siblings)
10 siblings, 0 replies; 28+ messages in thread
From: pault at gcc dot gnu dot org @ 2005-11-22 20:16 UTC (permalink / raw)
To: gcc-bugs
------- Comment #17 from pault at gcc dot gnu dot org 2005-11-22 20:16 -------
I have started to see a light at the end of the tunnel. Going back to easier
but related things, I have found that this is broken, as is its character
cousin:
integer, DIMENSION(:), POINTER :: ptr
allocate (ptr(2))
ptr = 123
call a (ptr, 12)
IF ( .NOT. ASSOCIATED(ptr) ) THEN
print *, "not associated in MAIN"
else
print *, "associated in MAIN ", size(ptr,1), ptr
END IF
contains
SUBROUTINE A(p, l)
integer, DIMENSION(:), POINTER :: p
integer, DIMENSION(2), target :: t
t = 456
IF ( .NOT. ASSOCIATED(p) ) THEN
p => t
print *, "not associated in A ", size(p,1), p
else
print *, "associated in A ", size(p,1), p
t = 789
p => t
END IF
END SUBROUTINE A
end
The subroutine works but the wrong result is returned. The reason for this is
now abundantly clear, although why it was not so before is not....*sigh*
A pointer array is passed as an array descriptor; this means that the value is
not returned if the association is changed!
I have most of the way cured this, up to backend complaints about violating the
sanctity of pointers (I need to get the PARM_DECL to be of the right type but
have all the indirect referencing sorted out.).
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15809
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug fortran/15809] ICE Using Pointer Functions
[not found] <bug-15809-7776@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2005-11-21 18:06 ` sven dot buijssen at math dot uni-dortmund dot de
@ 2005-11-21 18:08 ` Tobias dot Schlueter at physik dot uni-muenchen dot de
2005-11-22 20:16 ` pault at gcc dot gnu dot org
` (6 subsequent siblings)
10 siblings, 0 replies; 28+ messages in thread
From: Tobias dot Schlueter at physik dot uni-muenchen dot de @ 2005-11-21 18:08 UTC (permalink / raw)
To: gcc-bugs
------- Comment #16 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2005-11-21 18:08 -------
Subject: Re: ICE Using Pointer Functions
pgf90 compiles Paul Thomas' example, giving an empty string as output from the
subroutine.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15809
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug fortran/15809] ICE Using Pointer Functions
[not found] <bug-15809-7776@http.gcc.gnu.org/bugzilla/>
2005-10-23 13:34 ` sven dot buijssen at math dot uni-dortmund dot de
2005-11-21 15:53 ` pault at gcc dot gnu dot org
@ 2005-11-21 18:06 ` sven dot buijssen at math dot uni-dortmund dot de
2005-11-21 18:08 ` Tobias dot Schlueter at physik dot uni-muenchen dot de
` (7 subsequent siblings)
10 siblings, 0 replies; 28+ messages in thread
From: sven dot buijssen at math dot uni-dortmund dot de @ 2005-11-21 18:06 UTC (permalink / raw)
To: gcc-bugs
------- Comment #15 from sven dot buijssen at math dot uni-dortmund dot de 2005-11-21 18:06 -------
I cannot tell why, but it seems to me that Paul Thomas' test case is no valid
code:
* Compaq Fortran Compiler X5.4A-1684-46B5P gives:
f90: Warning: line 14: An explicit-shaped array is being passed to a routine
that expects a pointer or assumed-shape array
call a (ptr)
----------^
Ok, that's because of the spare dummy argument l in the subroutine definition.
Omitting it, Compaq compiles, decides that p is associated, but prints an empty
string.
* Same behaviour with g95 (Nov 12 2005): empty string
* Next compiler: Sun Fortran 95 8.1 Patch 117834-03 2005/06/15
The Sun Compiler totally refuses to compile Paul Thomas' test case (but
omitting the spare dummy argument l):
call a (ptr)
^
Line = 14, Column = 3: ERROR: Procedure "A" is defined at line 1. It must have
an explicit interface specified.
f90comp: 16 SOURCE LINES
f90comp: 1 ERRORS, 0 WARNINGS, 0 OTHER MESSAGES, 0 ANSI
* Rewriting the code to something equivalent
program demo
character(8), dimension (:), pointer :: ptr
character(8), dimension (2), target :: tar
tar = "def"
ptr => tar
call a (ptr)
if (associated (ptr)) print *, "in MAIN, ptr = ", ptr
contains
subroutine a(p)
character(8), dimension(:), pointer :: p
if (associated (p)) then
print *, p
else
print *, "not associated"
end if
end subroutine a
end program demo
solves all problems. g95, gfortran (20051113), ifort 9.0, Sun + Compaq Compiler
smoothly compile and print to screen the desired:
def def
in MAIN, ptr = def def
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15809
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug fortran/15809] ICE Using Pointer Functions
[not found] <bug-15809-7776@http.gcc.gnu.org/bugzilla/>
2005-10-23 13:34 ` sven dot buijssen at math dot uni-dortmund dot de
@ 2005-11-21 15:53 ` pault at gcc dot gnu dot org
2005-11-21 18:06 ` sven dot buijssen at math dot uni-dortmund dot de
` (8 subsequent siblings)
10 siblings, 0 replies; 28+ messages in thread
From: pault at gcc dot gnu dot org @ 2005-11-21 15:53 UTC (permalink / raw)
To: gcc-bugs
------- Comment #14 from pault at gcc dot gnu dot org 2005-11-21 15:53 -------
I have become more than a little bit concerned that this PR is a wild goose
chase.
Applying a similar patch to Erik's, I can persuade some bits of code to do
something. Furthermore, they are even the same things that ifort9.0 does;
right down to segfaulting in the same places... mostly! However, getting
anything useful out of such subroutines, even with ifort, is defeating me.
>From 12.4.1.1....
"If the dummy argument is a pointer, the actual argument shall be a pointer and
the types, type parameters and ranks shall agree."
Does this not make an automatic, character-length, pointer dummy incorrect
code?
"At the invocation of the procedure, the dummy argument pointer receives the
pointer association status of the actual argument. If the actual argument is
currently associated, the the dummy argument becomes associated with the same
target... "
Thus encouraged, I wrote this:
SUBROUTINE A(p,l)
CHARACTER(8), DIMENSION(:), pointer :: p
if (associated (p)) then
print *, p
else
print *, "not associated"
end if
END SUBROUTINE A
character(8), dimension (:), pointer :: ptr
character(8), dimension (2), target :: tar
tar = "def"
ptr => tar
call a (ptr)
if (associated (ptr)) print *, "in MAIN, ptr = ", ptr
end
ifort decides that p is not associated, whilst gfortran finds p to be
associated but fails to recognise that p is a character and produces a "bad
real" message at the print statement.
It seems to me that, in gfortran, the dummy needs to be declared in the
procedure and its data pointer set to that of the actual argument. Whether an
automatic character length should work or not seems to be moot to me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15809
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug fortran/15809] ICE Using Pointer Functions
[not found] <bug-15809-7776@http.gcc.gnu.org/bugzilla/>
@ 2005-10-23 13:34 ` sven dot buijssen at math dot uni-dortmund dot de
2005-11-21 15:53 ` pault at gcc dot gnu dot org
` (9 subsequent siblings)
10 siblings, 0 replies; 28+ messages in thread
From: sven dot buijssen at math dot uni-dortmund dot de @ 2005-10-23 13:34 UTC (permalink / raw)
To: gcc-bugs
------- Comment #13 from sven dot buijssen at math dot uni-dortmund dot de 2005-10-23 13:34 -------
In the meantime with gfortran 4.0.2 and the latest CVS version of gfortran (GNU
F95 version 4.1.0 20051023 (experimental)) again both Tobi's and Erik's
testcases give ICEs, both different ones:
# Tobi's testcase
$ cat bug7.f90
SUBROUTINE A(p,LEN)
CHARACTER(LEN=LEN), DIMENSION(:), POINTER :: p
IF ( .NOT. ASSOCIATED(p) ) THEN
END IF
END SUBROUTINE A
$ gfortran bug7.f90
bug7.f90: In function 'a':
bug7.f90:3: internal compiler error: in gfc_trans_deferred_array, at
fortran/trans-array.c:4163
# Erik's testcase
$ cat bug7a.f90
SUBROUTINE A(p,LEN)
CHARACTER(LEN=LEN), DIMENSION(:), POINTER :: p
IF ( .NOT. ASSOCIATED(p) ) THEN
allocate(p(1))
END IF
END SUBROUTINE A
$ gfortran bug7a.f90
bug7a.f90: In function 'a':
bug7a.f90:1: internal compiler error: Segmentation fault
Both testcases, however, compile smoothly when replacing CHARACTER(LEN=LEN) by
something fixed, e.g. CHARACTER(LEN=5). So, assigning a fixed length is a
possible workaround for those that are affected by this bug, like I am.
Investigating this bug further one finds:
1) Tobi's testcase with assumed-length character, CHARACTER(LEN=*), compiles
smoothly as well, while Erik's testcase with CHARACTER(LEN=*) gives again
bug7a.f90: In function 'a':
bug7a.f90:1: internal compiler error: Segmentation fault
2) The problem seems to be that accessing a member of the array p, e.g. via
print *, p(1)
or via 'allocate' as in Erik's test case, causes an ICE if and if only an
assumed-length character is used. CHARACTER(LEN=<some number>) works.
3) Fixing this bug will probably also fix the ICE for the following invalid (!)
code
$ cat bug7c.f90
function foo()
character(len=*),dimension(:),pointer :: foo
allocate(foo(1))
end function
$ gfortran -c bug7c.f90
bug3.f90: In function 'foo':
bug3.f90:1: internal compiler error: Segmentation fault
while it simply gives errors with ifort 9.0 20050809
> fortcom: Error: bug3.f90, line 1: A CHARACTER function name must not be declared with an asterisk type-param-value (i.e., (LEN=*)) if the function is array-valued.
and g95 (G95 (GCC 4.0.1 (g95!) Oct 16 2005))
> Error: POINTER valued function 'foo' at (1) cannot return an assumed-length character (*)
As previously, this problem only occurs if assumed-length character is used
instead of a fixed length.
I hope this information will help tracing the error.
For sake of completeness:
$ gfortran -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcccvs/configure --enable-shared
--prefix=/usr/local/gcc-4.0.x-cvs --enable-languages=c,c++,fortran
--enable-threads --enable-__cxa_atexit
Thread model: posix
gcc version 4.1.0 20051023 (experimental)
$ gfortran-4.0.2 -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.0.2/configure --enable-shared
--prefix=/usr/local/gcc-4.0.2 --enable-languages=c,c++,f95 --enable-threads
--enable-__cxa_atexit
Thread model: posix
gcc version 4.0.2
Environment:
System: Linux stingray 2.6.8-24.18-default #1 Fri Aug 19 11:56:28 UTC 2005 i686
unknown unknown GNU/Linux
Architecture: i686
glibc 2.3.4
SuSE 9.2
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
--
sven dot buijssen at math dot uni-dortmund dot de changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |sven dot buijssen at math
| |dot uni-dortmund dot de
Bug 15809 depends on bug 15326, which changed state.
Bug 15326 Summary: [4.0 only] ICE with assumed length character strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15326
What |Old Value |New Value
----------------------------------------------------------------------------
Status|REOPENED |NEW
Status|NEW |RESOLVED
Resolution| |FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15809
^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2005-12-12 20:10 UTC | newest]
Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-06-03 20:12 [Bug fortran/15809] New: ICE Using Pointer Functions giese025 at tc dot umn dot edu
2004-06-03 20:13 ` [Bug fortran/15809] " giese025 at tc dot umn dot edu
2004-06-03 20:21 ` pinskia at gcc dot gnu dot org
2004-07-11 17:10 ` tobi at gcc dot gnu dot org
2004-08-25 22:10 ` tobi at gcc dot gnu dot org
2004-09-22 7:48 ` c dot lemmen at fz-juelich dot de
2004-12-14 17:53 ` pinskia at gcc dot gnu dot org
2005-04-03 2:25 ` szalai at mit dot edu
2005-06-05 22:44 ` pault at gcc dot gnu dot org
2005-08-30 20:44 ` erik dot edelmann at iki dot fi
2005-08-31 19:39 ` tobi at gcc dot gnu dot org
2005-09-02 11:34 ` tobi at gcc dot gnu dot org
2005-09-02 11:58 ` erik dot edelmann at iki dot fi
2005-09-02 15:39 ` Tobias dot Schlueter at physik dot uni-muenchen dot de
2005-09-06 21:10 ` erik dot edelmann at iki dot fi
2005-09-08 18:51 ` rsandifo at gcc dot gnu dot org
2005-09-18 19:53 ` tkoenig at gcc dot gnu dot org
[not found] <bug-15809-7776@http.gcc.gnu.org/bugzilla/>
2005-10-23 13:34 ` sven dot buijssen at math dot uni-dortmund dot de
2005-11-21 15:53 ` pault at gcc dot gnu dot org
2005-11-21 18:06 ` sven dot buijssen at math dot uni-dortmund dot de
2005-11-21 18:08 ` Tobias dot Schlueter at physik dot uni-muenchen dot de
2005-11-22 20:16 ` pault at gcc dot gnu dot org
2005-11-23 14:26 ` paul dot richard dot thomas at cea dot fr
2005-11-30 17:26 ` pault at gcc dot gnu dot org
2005-11-30 19:26 ` pault at gcc dot gnu dot org
2005-12-05 11:14 ` jakub at gcc dot gnu dot org
2005-12-07 6:20 ` pault at gcc dot gnu dot org
2005-12-12 20:10 ` pinskia at gcc dot gnu dot org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).