--- Comment #5 from janus at gcc dot gnu dot org 2009-12-11 15:02 ---
Fixed with r155162. Thanks for the report.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from janus at gcc dot gnu dot org 2009-12-11 15:54 ---
Here is a patch which fixes the ICE:
Index: gcc/fortran/module.c
===
--- gcc/fortran/module.c(revision 155160)
+++ gcc/fortran/module.c
--- Comment #10 from janus at gcc dot gnu dot org 2009-12-11 16:09 ---
I think this one can be closed.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from janus at gcc dot gnu dot org 2009-12-11 23:05 ---
Subject: Bug 42257
Author: janus
Date: Fri Dec 11 23:05:02 2009
New Revision: 155183
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155183
Log:
gcc/fortran/
2009-12-11 Janus Weil
PR fortr
--- Comment #4 from janus at gcc dot gnu dot org 2009-12-11 23:06 ---
Fixed with r155183. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from janus at gcc dot gnu dot org 2009-12-11 23:13 ---
Confirmed. Thanks for reporting.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from janus at gcc dot gnu dot org 2009-12-13 21:09 ---
One can get rid of this by making the vtypes private:
Index: gcc/fortran/symbol.c
===
--- gcc/fortran/symbol.c(revision 155182)
+++ gcc/fortran
--- Comment #4 from janus at gcc dot gnu dot org 2009-12-13 21:41 ---
Btw, here is a reduced/modified test case which gives the same error:
module m0
type :: t
end type
end module
module m1a
use m0
class(t), pointer :: c1
end module
module m1b
use m0
class(t), pointer
--- Comment #18 from janus at gcc dot gnu dot org 2009-12-13 21:51 ---
r155024 contains the patch in comment #12, which fixes comment #9, but not the
double free issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41478
--- Comment #6 from janus at gcc dot gnu dot org 2009-12-15 22:30 ---
The test case in comment #5 has issues which go beyond the usage of 'deferred':
The variant below, which has no deferred procedures, compiles, but produces
wrong code (the operators are always resolved to t
Keywords: wrong-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42385
--- Comment #7 from janus at gcc dot gnu dot org 2009-12-15 23:02 ---
(In reply to comment #6)
> The test case in comment #5 has issues which go beyond the usage of
> 'deferred':
> The variant below, which has no deferred procedures, compiles, but produces
> wro
--- Comment #8 from janus at gcc dot gnu dot org 2009-12-17 09:28 ---
Subject: Bug 42144
Author: janus
Date: Thu Dec 17 09:28:25 2009
New Revision: 155305
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155305
Log:
gcc/fortran/
2009-12-17 Janus Weil
PR fortr
--- Comment #9 from janus at gcc dot gnu dot org 2009-12-17 09:46 ---
Fixed on trunk with r155305 (on fortran-dev it was working already). Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from janus at gcc dot gnu dot org 2009-12-19 20:27 ---
(In reply to comment #1)
> The following program is also rejected, unless the marked line is
> removed/comment out. At a glance, it looks OK - and ifort, NAG f95 and g95
> accept it. The error m
gfault with -fopenmp -static
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janu
at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42478
--- Comment #1 from janus at gcc dot gnu dot org 2009-12-23 13:29 ---
Btw, one also gets the segfault without actually calling 'omp_get_num_procs':
subroutine s
!$ use omp_lib
!$ print *, 'Number of processors:', omp_get_num_procs()
end subroutin
--- Comment #3 from janus at gcc dot gnu dot org 2009-12-23 13:41 ---
(In reply to comment #2)
> Dupe of PR30471?
Ah, yes, indeed. The segfault is cured by the workaround from comment #7 of
that PR (i.e. compiling with -fopenmp -static -Wl,--whole-archive -lpthread
-Wl,--no-wh
--- Comment #10 from janus at gcc dot gnu dot org 2009-12-23 13:41 ---
*** Bug 42477 has been marked as a duplicate of this bug. ***
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42484
--- Comment #1 from janus at gcc dot gnu dot org 2009-12-24 13:54 ---
I think the example is valid. ifort and sunf95 accept it.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from janus at gcc dot gnu dot org 2009-12-25 20:36 ---
Sorry. Of course the code is *not* valid. Section 1.2.2 of the OpenMP 3.0
specification says: "The point of exit cannot be a branch out of the structured
block."
Also, an analogous example in C is correctl
--- Comment #3 from janus at gcc dot gnu dot org 2009-12-26 20:11 ---
There is a pass 'diagnose_omp_blocks', which generates the error message for
the C code. Its execution function is 'diagnose_omp_structured_block_errors' in
omp-low.x, which is correctly called a
--- Comment #4 from janus at gcc dot gnu dot org 2009-12-26 21:44 ---
I'm curious why this problem only appears for Fortran code and not for C. If it
is a 'glibc feature', then both should be equally affected, or am I mistaken?
The following C program does not show the r
--- Comment #4 from janus at gcc dot gnu dot org 2009-12-26 22:31 ---
Here are test cases in Fortran and C, which both use GOTOs. Again, the Fortran
code ICEs, while the C code gives an error message:
subroutine sub
integer :: nRead
!$omp critical
if (nRead<3) goto
--- Comment #5 from janus at gcc dot gnu dot org 2009-12-26 22:46 ---
For the Fortran test case in comment #4, diagnose_sb_2 (omp-low.c) is called
six times, with the following statements:
* GIMPLE_BIND
* GIMPLE_OMP_CRITICAL
* GIMPLE_COND
* GIMPLE_LABEL
* GIMPLE_LABEL
* GIMPLE_ASSIGN
--- Comment #6 from janus at gcc dot gnu dot org 2009-12-27 11:38 ---
One more observation: The Fortran test case works, with return as well as goto,
giving the correct error message, if one removes the 'if' statement:
subroutine sub
!$omp critical
return
--- Comment #7 from janus at gcc dot gnu dot org 2009-12-27 12:53 ---
Interestingly, the test case also works when using an 'if ... then ... end if'
instead of a simple 'if':
subroutine sub
integer :: nRead
!$omp critical
if (nRead<3) then
--- Comment #8 from janus at gcc dot gnu dot org 2009-12-27 13:05 ---
The reason for the failure of comment #0 and #4 is that these cases run into
the following optimization in gimplify_cond_expr (gimplify.c):
if (TREE_OPERAND (expr, 1) != NULL
&& TREE_CODE (TREE_OPERA
--- Comment #9 from janus at gcc dot gnu dot org 2009-12-27 15:57 ---
Here is a patch which fixes the ICE, and gives the correct error messages:
Index: gcc/fortran/trans.c
===
--- gcc/fortran/trans.c (revision 155304
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42517
--- Comment #1 from janus at gcc dot gnu dot org 2009-12-27 18:39 ---
An easy way to fix this is to simply disable the recursion check if -fopenmp is
given:
Index: gcc/fortran/trans-decl.c
===
--- gcc/fortran/trans-decl.c
--- Comment #7 from janus at gcc dot gnu dot org 2009-12-28 14:15 ---
Here is a reduced version of the test case in comment #6:
module concrete_vector
type :: trivial_vector_type
end type
class(trivial_vector_type), pointer :: this
end module concrete_vector
module
--- Comment #8 from janus at gcc dot gnu dot org 2009-12-28 14:29 ---
Ok, here is a new patch, which fixes all problems reported here so far:
Index: gcc/fortran/symbol.c
===
--- gcc/fortran/symbol.c(revision 155486
--- Comment #9 from janus at gcc dot gnu dot org 2009-12-28 15:24 ---
(In reply to comment #8)
> In the meantime I will test it for regressions.
Regtest finished successfully.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42353
--- Comment #11 from janus at gcc dot gnu dot org 2009-12-28 19:13 ---
(In reply to comment #10)
> this patch appears OK so far.
Great, thanks for checking.
> (I get a probably unrelated ICE later in the compilation process
> of the Fortran project which I am investigating
--- Comment #10 from janus at gcc dot gnu dot org 2009-12-28 21:41 ---
*** This bug has been marked as a duplicate of 41344 ***
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from janus at gcc dot gnu dot org 2009-12-28 21:41 ---
*** Bug 42484 has been marked as a duplicate of this bug. ***
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from janus at gcc dot gnu dot org 2009-12-28 21:59 ---
(In reply to comment #12)
> I have attached a version that results in the following ICE after your patch
> was applied. The error message reads:
>
> gfcbug96c.f90:144:0: internal compiler error: Segmen
--- Comment #15 from janus at gcc dot gnu dot org 2009-12-28 23:13 ---
Subject: Bug 42353
Author: janus
Date: Mon Dec 28 23:13:03 2009
New Revision: 155494
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155494
Log:
gcc/fortran/
2009-12-28 Janus Weil
PR fortr
--- Comment #16 from janus at gcc dot gnu dot org 2009-12-28 23:16 ---
Fixed with r155494. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from janus at gcc dot gnu dot org 2009-12-29 19:30 ---
Subject: Bug 42517
Author: janus
Date: Tue Dec 29 19:29:54 2009
New Revision: 155506
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155506
Log:
gcc/fortran/
2009-12-29 Janus Weil
PR fortr
--- Comment #3 from janus at gcc dot gnu dot org 2009-12-29 20:19 ---
The commit in comment #2 contains the patch in comment #1 and disables
recursion checking if -fopenmp is given.
In the long run, the checking should be modified so that it can work with
multiple threads. It has been
--- Comment #17 from janus at gcc dot gnu dot org 2009-12-30 17:34 ---
Reopening. As reported in http://gcc.gnu.org/ml/fortran/2009-12/msg00215.html,
the patch in comment #15 introduced several regressions on the fortran-dev
branch.
--
janus at gcc dot gnu dot org changed
--- Comment #7 from janus at gcc dot gnu dot org 2010-01-14 21:35 ---
(In reply to comment #2)
> I would guess it is due to PR 36947.
Yes, I think this is correct. r148519, to be precise.
The following patch fixes it:
Index: interfac
--- Comment #8 from janus at gcc dot gnu dot org 2010-01-14 22:23 ---
The patch in comment #7 regresses on dummy_procedure_2.f90 and
proc_ptr_result_1.f90.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42677
--- Comment #9 from janus at gcc dot gnu dot org 2010-01-14 22:59 ---
Another way to get rid of the error is:
Index: fortran/module.c
===
--- fortran/module.c(revision 155865)
+++ fortran/module.c(working copy
--- Comment #8 from janus at gcc dot gnu dot org 2010-01-17 11:59 ---
Here is a reduced test case:
module mod1
type :: t1
contains
procedure, nopass :: get => my_get
end type
contains
logical function my_get()
end function
end module
module mod2
contains
logi
--- Comment #10 from janus at gcc dot gnu dot org 2010-01-17 13:16 ---
A regression-free patch was posted at:
http://gcc.gnu.org/ml/fortran/2010-01/msg00092.html
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from janus at gcc dot gnu dot org 2010-01-17 13:33 ---
Subject: Bug 42677
Author: janus
Date: Sun Jan 17 13:33:11 2010
New Revision: 155979
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155979
Log:
gcc/fortran/
2010-01-17 Janus Weil
PR fortr
--- Comment #12 from janus at gcc dot gnu dot org 2010-01-17 13:36 ---
Fixed with r155979. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from janus at gcc dot gnu dot org 2010-01-17 20:53 ---
(In reply to comment #5)
> It is very likely caused by revision :
> http://gcc.gnu.org/ml/gcc-cvs/2009-10/msg00175.html
Actually I don't see how this bug could be caused by r152526. That patch was
about
--- Comment #12 from janus at gcc dot gnu dot org 2010-01-17 21:29 ---
I'd argue this is not even a regression. Sure, the code in comment #1 fails to
compile with 4.4 since it contains lots of CLASS declarations. But on comment
#8, gfortran 4.4 fails with (almost) the same
--- Comment #14 from janus at gcc dot gnu dot org 2010-01-17 21:34 ---
(In reply to comment #10)
> mod1
> 1
> Error: Unclassifiable statement at (1)
Sorry, this is due to a wrapped comment in comment #8. Let's try it again:
module mod1
type :: t1
contains
pro
--- Comment #15 from janus at gcc dot gnu dot org 2010-01-17 21:58 ---
(In reply to comment #5)
> It is very likely caused by revision :
> http://gcc.gnu.org/ml/gcc-cvs/2009-10/msg00175.html
Just for completeness: With trunk r152525 you get the same ICE (with a
different line
--- Comment #1 from janus at gcc dot gnu dot org 2010-01-17 22:35 ---
This problem is not specific to TBPs. It also appears for data components of
the parent type, as the following example shows:
module mo
implicit none
type :: tt
integer :: i = 1
end type
type, extends(tt
--- Comment #2 from janus at gcc dot gnu dot org 2010-01-17 22:42 ---
Another related example. This one is being accepted, although it is invalid.
module mo
implicit none
type,private :: tt
integer :: i = 1
end type
type, extends(tt) :: ttt
real :: x = 2.0
end type
--- Comment #3 from janus at gcc dot gnu dot org 2010-01-17 23:34 ---
Here is a simple patch for setting the parent component accessibility:
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c (revision 155994)
+++ gcc
--- Comment #4 from janus at gcc dot gnu dot org 2010-01-17 23:46 ---
In addition to the parent component accessibility issue, there is also
something wrong with the error message being thrown in comment #0 and #1.
The check throwing this error resides in 'gfc_find_component'
--- Comment #5 from janus at gcc dot gnu dot org 2010-01-18 13:46 ---
(In reply to comment #3)
> Here is a simple patch for setting the parent component accessibility:
> [...]
> This is probably not enough, since the access. specification of the parent
> type
> may
--- Comment #8 from janus at gcc dot gnu dot org 2010-01-19 13:20 ---
Patch posted at:
http://gcc.gnu.org/ml/fortran/2010-01/msg00101.html
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from janus at gcc dot gnu dot org 2010-01-19 13:45 ---
Subject: Bug 42545
Author: janus
Date: Tue Jan 19 13:45:07 2010
New Revision: 156040
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156040
Log:
gcc/fortran/
2010-01-19 Janus Weil
PR fortr
--- Comment #10 from janus at gcc dot gnu dot org 2010-01-19 14:00 ---
Fixed with r156040. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from janus at gcc dot gnu dot org 2010-01-19 16:35 ---
If one replaces the TBP call by a direct call to the subroutine, like this:
call a_proc(arr(i),ierr)
then the ICE goes away (of course a_proc must be public for this to work). This
means it is not a problem of the
--- Comment #5 from janus at gcc dot gnu dot org 2010-01-19 16:39 ---
Another observation: If I remove the CLASS argument, give the procedure the
NOPASS attribute and call it like this, the ICE also goes away.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42804
--- Comment #6 from janus at gcc dot gnu dot org 2010-01-19 17:11 ---
(In reply to comment #3)
> The problem is that e(xpr)->where->lb == NULL.
Exactly. What's important is that the expression "e" here is the passed-object
argument.
Now the problem really i
--- Comment #7 from janus at gcc dot gnu dot org 2010-01-19 17:24 ---
We probably have the same trouble with procedure pointer components, which can
also have passed-object arguments.
However, when trying to construct an analogous PPC test case, I came across
another bug. Here is the
--- Comment #8 from janus at gcc dot gnu dot org 2010-01-19 17:46 ---
Here is the fix for PPCs, curing both the "must be scalar" error from the last
comment as well as the missing-locus ICE (which, as expected, did appear also
for PPCs after the other thing was fixed):
--- Comment #9 from janus at gcc dot gnu dot org 2010-01-19 22:21 ---
Subject: Bug 42804
Author: janus
Date: Tue Jan 19 22:21:35 2010
New Revision: 156049
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156049
Log:
gcc/fortran/
2010-01-19 Janus Weil
PR fortr
--- Comment #10 from janus at gcc dot gnu dot org 2010-01-19 22:23 ---
Fixed with r156049. Closing.
Thanks for the report!
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from janus at gcc dot gnu dot org 2010-01-23 17:25 ---
Another related quote from the F2003 standard:
C489 (R457) If derived-type-spec is a type name that is the same as a generic
name, the component-spec-list shall not be a valid actual-arg-spec-list for a
function
--- Comment #6 from janus at gcc dot gnu dot org 2010-01-28 10:29 ---
(In reply to comment #5)
> I think the relevant part is:
> http://gcc.gnu.org/viewcvs/trunk/gcc/fortran/trans-stmt.c?r1=152345&r2=152344&pathrev=152345
> -- especially around "Add default initial
--- Comment #7 from janus at gcc dot gnu dot org 2010-01-28 13:02 ---
(In reply to comment #6)
> #0 fold_convert_loc (loc=0, type=0x77e83498, arg=0x77f65060) at
> /home/jweil/gcc45/trunk/gcc/fold-const.c:2669
> #1 0x005a088a in gfc_trans_scalar_as
--- Comment #9 from janus at gcc dot gnu dot org 2010-01-28 13:32 ---
(In reply to comment #7)
> While for the old rev. 'type' and 'orig' are both
> INTEGER_TYPE, 'orig' is REAL_TYPE on current trunk. I'll try to find out how
> that comes ab
--- Comment #10 from janus at gcc dot gnu dot org 2010-01-28 14:51 ---
(In reply to comment #9)
> Index: gcc/fortran/trans-stmt.c
> ===
> --- gcc/fortran/trans-stmt.c(revision 156258)
> +++ gcc/fortran/
--- Comment #14 from janus at gcc dot gnu dot org 2010-01-29 19:01 ---
Ok, I think the best solution is to move the code setting up the initializer
back to resolve.c. Here is a patch which does so (without any testsuite
regressions):
Index: gcc/fortran/trans-stmt.c
--- Comment #15 from janus at gcc dot gnu dot org 2010-01-29 19:18 ---
(In reply to comment #14)
> Note: There is another call to 'gfc_default_initializer' in
> 'gfc_trans_allocate', which should be moved to resolve.c too, I guess.
Here is a small test case (
--- Comment #16 from janus at gcc dot gnu dot org 2010-01-29 22:41 ---
Created an attachment (id=19754)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19754&action=view)
patch
Here is an updated patch which fixes the test case in the last comment and the
original
--- Comment #19 from janus at gcc dot gnu dot org 2010-01-30 10:29 ---
(In reply to comment #17)
> There is another problem left with the patch. I am not sure whether the
> code is legal, but it gives an ICE for me:
>
> implicit none
> type t
> integer :: X
--- Comment #20 from janus at gcc dot gnu dot org 2010-01-30 10:31 ---
(In reply to comment #19)
> And the ICE is kind of expected right now, since CLASS arrays
> are not really supported yet (cf. PR42539, PR41600, PR41951; the second one
> contains a similar ALLOCATE statement
--- Comment #1 from janus at gcc dot gnu dot org 2010-01-30 10:37 ---
Related example (PR42888 comment #17):
implicit none
type t
integer :: X = -999.0
end type t
class(t), allocatable :: y(:)
allocate (t::y(1)) ! ICE
end
--
http://gcc.gnu.org/bugzilla
--- Comment #21 from janus at gcc dot gnu dot org 2010-01-31 21:56 ---
Subject: Bug 42888
Author: janus
Date: Sun Jan 31 21:56:02 2010
New Revision: 156418
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156418
Log:
gcc/fortran/
2010-01-31 Janus Weil
PR fortr
--- Comment #22 from janus at gcc dot gnu dot org 2010-01-31 22:01 ---
Fixed with r156418. Thanks for the report!
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from janus at gcc dot gnu dot org 2010-07-15 13:36 ---
Subject: Bug 44936
Author: janus
Date: Thu Jul 15 13:36:28 2010
New Revision: 162221
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162221
Log:
2010-07-15 Janus Weil
PR fortr
--- Comment #4 from janus at gcc dot gnu dot org 2010-07-15 13:42 ---
Fixed with r162221. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from janus at gcc dot gnu dot org 2010-07-17 08:49 ---
Another failing example was reported by Andrew Benson in
http://gcc.gnu.org/ml/fortran/2010-07/msg00222.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44065
--- Comment #2 from janus at gcc dot gnu dot org 2010-07-17 15:35 ---
At r162275, I'm neither seeing the ICE nor any valgrind errors. Can anyone
confirm this?
[My guess is that it has been fixed by the recent cleanup of generics, i.e.
r162125.]
--
janus at gcc dot gnu do
--- Comment #5 from janus at gcc dot gnu dot org 2010-07-18 09:23 ---
(In reply to comment #3)
> At revision 162276, I get
>
> pr44868.f90:245.24:
>
> tst_case => self%list(i)
> 1
> Error: Pointer assignment target is neith
olved more than once
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janus at gcc do
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org
|dot org
--- Comment #2 from janus at gcc dot gnu dot org 2010-07-22 21:21 ---
Reduced test case with the same output:
program bug18
type foo
integer :: i
end type foo
type bar
class(foo), allocatable :: bf
end type bar
class(foo), allocatable :: afab
type(bar) :: bb
--- Comment #3 from janus at gcc dot gnu dot org 2010-07-22 21:44 ---
Here is an even more elementary example which shows that there is a problem for
allocatable scalars, already without any polymorphic variables:
implicit none
integer, allocatable :: afab1,afab2
allocate(afab1
--- Comment #4 from janus at gcc dot gnu dot org 2010-07-23 16:19 ---
Here is a draft patch which deals with allocatable scalars:
Index: gcc/fortran/trans.c
===
--- gcc/fortran/trans.c (revision 162448)
+++ gcc/fortran
--- Comment #5 from janus at gcc dot gnu dot org 2010-07-29 18:14 ---
Subject: Bug 45004
Author: janus
Date: Thu Jul 29 18:14:16 2010
New Revision: 162688
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162688
Log:
2010-07-29 Janus Weil
PR fortr
--- Comment #6 from janus at gcc dot gnu dot org 2010-07-29 18:18 ---
Fixed with r162688. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from janus at gcc dot gnu dot org 2010-07-29 19:36 ---
Here is a reduced/modified version of the code in comment #0, which also
exhibits a runtime segfault, although the code seems to be valid:
module polynomial
implicit none
private
type, public :: polynom
complex
--- Comment #1 from janus at gcc dot gnu dot org 2010-07-29 20:59 ---
Subject: Bug 44962
Author: janus
Date: Thu Jul 29 20:58:57 2010
New Revision: 162695
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162695
Log:
2010-07-29 Janus Weil
PR fortr
--- Comment #2 from janus at gcc dot gnu dot org 2010-07-29 21:01 ---
Fixed with r162695. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
CC||janus at gcc dot gnu dot org
Status|UNCONFIRMED
601 - 700 of 1036 matches
Mail list logo
