https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846
--- Comment #11 from Salvatore Filippone sfilippone at uniroma2 dot it ---
Created attachment 35995
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35995action=edit
test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846
--- Comment #12 from Salvatore Filippone sfilippone at uniroma2 dot it ---
(In reply to Salvatore Filippone from comment #11)
Created attachment 35995 [details]
test case
Enjoy :)
[sfilippo@jacobi tlink]$ gfortran -v
Using built-in specs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846
--- Comment #13 from Salvatore Filippone sfilippone at uniroma2 dot it ---
Created attachment 35996
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35996action=edit
test case
Cleaned up a bit of noise due to the process of reducing the test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846
--- Comment #9 from Salvatore Filippone sfilippone at uniroma2 dot it ---
(In reply to Salvatore Filippone from comment #8)
(In reply to Paul Thomas from comment #7)
Salvatore
Spoke too quickly: I get this linker error
ppde3d.f90:(.text+0x9d0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846
--- Comment #8 from Salvatore Filippone sfilippone at uniroma2 dot it ---
(In reply to Paul Thomas from comment #7)
Created attachment 35926 [details]
A partially cooked patch to complete the implentation of submodules
The attached
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66280
--- Comment #12 from Salvatore Filippone sfilippone at uniroma2 dot it ---
Created attachment 35763
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35763action=edit
test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66280
Salvatore Filippone sfilippone at uniroma2 dot it changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
--- Comment #66 from Salvatore Filippone sfilippone at uniroma2 dot it ---
As far as I remember(In reply to rguent...@suse.de from comment #65)
On Wed, 10 Dec 2014, burnus at gcc dot gnu.org wrote:
Fortran 66 compilers did. For instance, DO
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: sfilippone at uniroma2 dot it
Created attachment 33881
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33881action=edit
test case
Hi,
The attached test case, slightly modified from an original by Alberto F.
Martin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61819
Salvatore Filippone sfilippone at uniroma2 dot it changed:
What|Removed |Added
Attachment #33127|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61819
--- Comment #5 from Salvatore Filippone sfilippone at uniroma2 dot it ---
Code works with 4.8.3, so this is a regression.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61819
--- Comment #7 from Salvatore Filippone sfilippone at uniroma2 dot it ---
The original code leaks memory like a sieve, and looks suspiciously similar to
PR55603. It is just possible that the whole area of function results needs to
be reviewed (I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60922
--- Comment #4 from Salvatore Filippone sfilippone at uniroma2 dot it ---
Looking at the original code of PR 61819, it is quite possible that the real
culprit are CLASS() ALLOCATABLE components, not necessarily the result itself
(being
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: sfilippone at uniroma2 dot it
Created attachment 33132
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33132action=edit
test case
Hi,
The attached code shows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61830
--- Comment #1 from Salvatore Filippone sfilippone at uniroma2 dot it ---
Created attachment 33133
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33133action=edit
workaround
Assignee: unassigned at gcc dot gnu.org
Reporter: sfilippone at uniroma2 dot it
The attached code produces the ICE in both trunk and 4.9.0.
The code is from a test case I was trying to reduce while investigating a
memory leak, so something fishy is going
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61819
--- Comment #1 from Salvatore Filippone sfilippone at uniroma2 dot it ---
Created attachment 33127
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33127action=edit
test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61819
--- Comment #2 from Salvatore Filippone sfilippone at uniroma2 dot it ---
Same ICE with a fresh trunk as of today.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60922
Salvatore Filippone sfilippone at uniroma2 dot it changed:
What|Removed |Added
Summary|[4.10 regression] Memory |[4.9
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: sfilippone at uniroma2 dot it
Created attachment 32653
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32653action=edit
test case
Attached code runs
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: sfilippone at uniroma2 dot it
Created attachment 31565
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31565action=edit
testcase
The attached code fails with current trunk with what
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: sfilippone at uniroma2 dot it
Created attachment 30274
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30274action=edit
Test case
The attached code generates the ICE when compiled
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: sfilippone at uniroma2 dot it
Created attachment 30267
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30267action=edit
Test case
The attached code triggers an ICE with debug options -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56969
Bug #: 56969
Summary: ISO_C_BINDING regression with current trunk
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54618
Salvatore Filippone sfilippone at uniroma2 dot it changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54618
--- Comment #19 from Salvatore Filippone sfilippone at uniroma2 dot it
2013-04-05 09:33:18 UTC ---
(In reply to comment #17)
Hi,
I am seeing intermittent issues with CLASS,ALLOCATABLE,INTENT(OUT) variables
that have a CLASS,ALLOCATABLE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54618
--- Comment #21 from Salvatore Filippone sfilippone at uniroma2 dot it
2013-04-05 12:29:11 UTC ---
(In reply to comment #20)
(In reply to comment #18)
I am seeing intermittent issues with CLASS,ALLOCATABLE,INTENT(OUT) variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55593
Bug #: 55593
Summary: Bogus error on passing DO LOOP variable
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54874
--- Comment #14 from Salvatore Filippone sfilippone at uniroma2 dot it
2012-10-10 11:36:45 UTC ---
(In reply to comment #13)
Salvatore, I would say we can close this PR (as a duplicate of PR54784),
unless
the runtime error with 4.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54874
Bug #: 54874
Summary: OOP: polymorphic allocation with SOURCE
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54784
--- Comment #9 from Salvatore Filippone sfilippone at uniroma2 dot it
2012-10-09 09:59:28 UTC ---
Just opened 54874. May or may not be a duplicate of this one.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54874
--- Comment #1 from Salvatore Filippone sfilippone at uniroma2 dot it
2012-10-09 10:02:41 UTC ---
Interestingly, taking out the outer container p% makes the code work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54874
--- Comment #2 from Salvatore Filippone sfilippone at uniroma2 dot it
2012-10-09 10:37:13 UTC ---
And it is also a regression, as it works on 4.6.3:
---
[sfilippo@jacobi bug34]$ gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54874
--- Comment #4 from Salvatore Filippone sfilippone at uniroma2 dot it
2012-10-09 11:03:10 UTC ---
(In reply to comment #3)
And it is also a regression, as it works on 4.6.3: ...
Well, this may be more complicated. On x86_64-apple
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54874
--- Comment #6 from Salvatore Filippone sfilippone at uniroma2 dot it
2012-10-09 14:46:15 UTC ---
(In reply to comment #5)
(In reply to comment #0)
I am getting the following output from the test case. It seems wrong, I do
not
see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54874
--- Comment #8 from Salvatore Filippone sfilippone at uniroma2 dot it
2012-10-09 16:02:35 UTC ---
(In reply to comment #6)
(In reply to comment #5)
(In reply to comment #0)
I am getting the following output from the test case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54784
Salvatore Filippone sfilippone at uniroma2 dot it changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46321
--- Comment #5 from Salvatore Filippone sfilippone at uniroma2 dot it
2012-05-07 09:32:30 UTC ---
(In reply to comment #1)
Note: There are four cases where a polymorphic deallocate is needed - though
some might end up in the same code path
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38813
Salvatore Filippone sfilippone at uniroma2 dot it changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38813
--- Comment #7 from Salvatore Filippone sfilippone at uniroma2 dot it
2012-01-13 12:48:13 UTC ---
(In reply to comment #6)
And the example that still fails:
--
module foo_mod
type foo_type
integer, allocatable :: idx(:)
end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48699
--- Comment #23 from Salvatore Filippone sfilippone at uniroma2 dot it
2011-12-03 12:00:43 UTC ---
Yes, TYPE FROM and polymorphic TO is exactly the typical usage I have (indeed,
it also was the original test case)
Thanks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47978
--- Comment #9 from Salvatore Filippone sfilippone at uniroma2 dot it
2011-09-14 13:46:00 UTC ---
(In reply to comment #8)
The test case in my original post is wrong in this respect
I mean: in the original post for pr41656.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47978
--- Comment #8 from Salvatore Filippone sfilippone at uniroma2 dot it
2011-09-14 13:45:13 UTC ---
Duh!
My bad: all versions of scal are supposed to update the A dummy argument, which
should be INTENT(INOUT).
The test case in my original post
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47978
--- Comment #12 from Salvatore Filippone sfilippone at uniroma2 dot it
2011-09-14 15:02:46 UTC ---
(In reply to comment #11)
relieved if Salvatore could tell us that his
latest code still compiles with gfortran ...
Cheers,
Janus
Yes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48699
--- Comment #15 from Salvatore Filippone sfilippone at uniroma2 dot it
2011-05-30 09:11:08 UTC ---
(In reply to comment #13)
Moreover, I think that this test case is in fact invalid, cf. PR 48887.
Hm.
I see; I wonder, is this something
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48699
Summary: [OOP] MOVE_ALLOC of polymorphic variables
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48699
--- Comment #1 from Salvatore Filippone sfilippone at uniroma2 dot it
2011-04-20 12:07:04 UTC ---
Created attachment 24057
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24057
test-case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48700
Summary: [OOP] memory leak with MOVE_ALLOC of polymorphic
variables
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48699
--- Comment #3 from Salvatore Filippone sfilippone at uniroma2 dot it
2011-04-20 13:20:48 UTC ---
(In reply to comment #2)
See also PR 48700 (memleak with polymorphic vars in MOVE_ALLOC), which might
be
a duplicate.
They are related
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47978
Summary: [OOP] Invalid INTENT in overriding TBP not detected
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47978
--- Comment #1 from Salvatore Filippone sfilippone at uniroma2 dot it
2011-03-03 16:47:24 UTC ---
Created attachment 23534
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23534
test-case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46448
--- Comment #3 from Salvatore Filippone sfilippone at uniroma2 dot it
2010-12-31 22:52:03 UTC ---
(In reply to comment #2)
I think you should check whether the symbol is already there using the gsym
(assuming that -fwhole-file is used - but I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46838
--- Comment #6 from Salvatore Filippone sfilippone at uniroma2 dot it
2010-12-28 13:40:52 UTC ---
(In reply to comment #5)
(In reply to comment #4)
Here's a patch:
The patch in comment #4 had a few regressions (e.g. on alloc_comp_basics_1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47082
Summary: [OOP] ICE in gfc_conv_component_ref
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47085
Summary: [OOP] Problem in allocate( SOURCE=) for polymorphic
component
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46838
--- Comment #3 from Salvatore Filippone sfilippone at uniroma2 dot it
2010-12-15 13:08:12 UTC ---
(In reply to comment #2)
The default initializer is obtained via expr.c's gfc_default_initializer.
The original code gives
Overall matrix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46838
Summary: [OOP] Wrong allocation status for polymorphic
component INTENT(OUT) dummy
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46809
Summary: [OOP] ICE with -fcheck=all
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46809
--- Comment #1 from Salvatore Filippone sfilippone at uniroma2 dot it
2010-12-05 13:29:12 UTC ---
With trunk at r167453 I get
[sfili...@localhost bug27]$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46809
--- Comment #2 from Salvatore Filippone sfilippone at uniroma2 dot it
2010-12-05 13:30:41 UTC ---
Created attachment 22642
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22642
test case
As usual, quite reduced from the original
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46448
Salvatore Filippone sfilippone at uniroma2 dot it changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46345
Summary: ICE
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46344
--- Comment #7 from Salvatore Filippone sfilippone at uniroma2 dot it
2010-11-07 14:58:40 UTC ---
(In reply to comment #6)
Revision 162456 compiles the tests, but not revision 166102. When compiled,
the
executable for pr46345 gives
Check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46174
Salvatore Filippone sfilippone at uniroma2 dot it changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45451
--- Comment #11 from Salvatore Filippone sfilippone at uniroma2 dot it
2010-10-05 19:39:44 UTC ---
(In reply to comment #4)
Ok, I could reduce this quite a bit:
1 3 4 5
1 3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45795
--- Comment #3 from Salvatore Filippone sfilippone at uniroma2 dot it
2010-09-26 07:33:13 UTC ---
(In reply to comment #2)
It is very likely a duplicate of pr45783.
The code compiles at r164549
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45795
--- Comment #4 from Salvatore Filippone sfilippone at uniroma2 dot it
2010-09-26 07:43:51 UTC ---
(In reply to comment #3)
(In reply to comment #2)
It is very likely a duplicate of pr45783.
The code compiles at r164549
and fails at r164550
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45795
--- Comment #6 from Salvatore Filippone sfilippone at uniroma2 dot it
2010-09-26 10:27:41 UTC ---
(In reply to comment #5)
Confirmed. I do not yet see how this is related to my commit, but will look
into it of course. Thanks for the report
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45795
Summary: [OOP] ICE in in gfc_add_component_ref plus bogus error
message
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
--- Comment #10 from sfilippone at uniroma2 dot it 2010-09-08 15:35 ---
(In reply to comment #9)
I have found a cure.
The original configuration had GMP, MPFR and MPC built and installed under the
user home directory (there were neither mpfr nor mpc system-wide, and gmp was a
bit
--- Comment #12 from sfilippone at uniroma2 dot it 2010-09-08 16:11 ---
(In reply to comment #11)
(In reply to comment #10)
How did you configure those prebuilt gmp/mpfr/mpc libraries installed under
your home directory? In particular, did you configure them all with
--disable
--- Comment #9 from sfilippone at uniroma2 dot it 2010-09-07 07:20 ---
(In reply to comment #8)
Created an attachment (id=21673)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21673action=view) [edit]
Modifying the conftest source gives the following:
[snfi...@josquin libiberty
: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sfilippone at uniroma2 dot it
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla
--- Comment #1 from sfilippone at uniroma2 dot it 2010-09-02 10:16 ---
Created an attachment (id=21653)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21653action=view)
test-case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45494
ReportedBy: sfilippone at uniroma2 dot it
GCC build triplet: powerpc64-unknown-linux-gnu
GCC host triplet: powerpc64-unknown-linux-gnu
GCC target triplet: powerpc64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45482
--- Comment #1 from sfilippone at uniroma2 dot it 2010-09-01 13:44 ---
Created an attachment (id=21642)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21642action=view)
Main config.log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45482
--- Comment #2 from sfilippone at uniroma2 dot it 2010-09-01 13:44 ---
Created an attachment (id=21643)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21643action=view)
stage 1 libiberty/config.log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45482
--- Comment #3 from sfilippone at uniroma2 dot it 2010-09-01 13:44 ---
Created an attachment (id=21644)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21644action=view)
stage 1 libiberty/config.h
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45482
--- Comment #4 from sfilippone at uniroma2 dot it 2010-09-01 13:45 ---
Created an attachment (id=21645)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21645action=view)
stage 2 libiberty/config.log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45482
--- Comment #5 from sfilippone at uniroma2 dot it 2010-09-01 13:45 ---
Created an attachment (id=21646)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21646action=view)
stage 2 libiberty/config.h
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45482
--- Comment #5 from sfilippone at uniroma2 dot it 2010-08-31 14:04 ---
(In reply to comment #4)
Ok, I could reduce this quite a bit:
Good :)
In the meantime, I tried with MOLD= in place of SOURCE=, and in the full
application it still gives a segfault; I think that variant should
--- Comment #7 from sfilippone at uniroma2 dot it 2010-08-31 14:18 ---
(In reply to comment #6)
Note that for MOLD there is PR 44541 left (which I am about to fix). Up to now
MOLD works only with non-polymorphic expressions. Once the PR is fixed,
polymorphics should work too. Until
--- Comment #8 from sfilippone at uniroma2 dot it 2010-08-31 19:20 ---
(In reply to comment #7)
(In reply to comment #6)
Fine. Waiting for it
Consider the following variation: upon exit from DOIT, the ACSR variable should
be deallocated (since it was MOVE_ALLOCed to atx
--- Comment #9 from sfilippone at uniroma2 dot it 2010-08-31 19:21 ---
Created an attachment (id=21613)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21613action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45451
at gcc dot gnu dot org
ReportedBy: sfilippone at uniroma2 dot it
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45451
--- Comment #1 from sfilippone at uniroma2 dot it 2010-08-30 12:09 ---
Created an attachment (id=21592)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21592action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45451
--- Comment #2 from sfilippone at uniroma2 dot it 2010-08-30 12:12 ---
(In reply to comment #0)
Hello,
After a lot (a LOT) of work, I've come up with this test case. The test case
*appears* to run fine, but valgrind shows something is amiss, and in the full
application (much more
--- Comment #3 from sfilippone at uniroma2 dot it 2010-08-30 12:13 ---
And here is the (expected) output with XLF.
[snfi...@josquin ~]$ xlf2003_r -o bug23 bug23.f03
** psb_const_mod === End of Compilation 1 ===
** psb_base_mat_mod === End of Compilation 2 ===
** psb_d_base_mat_mod
at uniroma2 dot it
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45438
--- Comment #1 from sfilippone at uniroma2 dot it 2010-08-28 09:04 ---
Created an attachment (id=21581)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21581action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45438
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sfilippone at uniroma2 dot it
GCC build triplet: x86_64-unknown-linux-gnu
GCC host
--- Comment #1 from sfilippone at uniroma2 dot it 2010-08-28 11:15 ---
Created an attachment (id=21583)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21583action=view)
test case
The code compiles cleanly with XLF.
If I switch the commented lines in the CLASS DEFAULT clause
--- Comment #3 from sfilippone at uniroma2 dot it 2010-08-27 07:37 ---
(In reply to comment #2)
It turns out this bug is rather easy to fix. The problem was the we used the
temporary needed for the TYPE IS clause also in the CLASS DEFAULT clause
(where
we need none). The following
--- Comment #5 from sfilippone at uniroma2 dot it 2010-08-27 11:38 ---
(In reply to comment #4)
(In reply to comment #3)
I tried to reproduce this by modifying your original test case, but did not
succeed so far. Can you provide a standalone test case for this problem? My
feeling
--- Comment #6 from sfilippone at uniroma2 dot it 2010-08-27 14:40 ---
(In reply to comment #3)
end if
class default
call aa%mv_to_coo(actmp,info)
if (info == psb_success_) then
if (present(b)) then
call psb_rwextd(nr,actmp,info,b
--- Comment #4 from sfilippone at uniroma2 dot it 2010-08-24 10:24 ---
(In reply to comment #3)
With dump-tree-original I see this code snippet:
finally
{
if (aa.$data != 0B)
{
__builtin_free ((void *) aa.$data
--- Comment #5 from sfilippone at uniroma2 dot it 2010-08-24 12:50 ---
(In reply to comment #3)
Reduced test case:
program bug20
type :: d_base_sparse_mat
integer :: v(10) = 0.
end type d_base_sparse_mat
class(d_base_sparse_mat),allocatable :: a
allocate
--- Comment #7 from sfilippone at uniroma2 dot it 2010-08-24 13:05 ---
(In reply to comment #6)
Cf. PR 44047 (which is similar to this, except that the polymorphic selector
itself is allocatable).
Yes, there indeed is a family air to this problem.it's probably one
)
--
Summary: [OOP] double free with SELECT TYPE
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sfilippone at uniroma2
--- Comment #1 from sfilippone at uniroma2 dot it 2010-08-23 14:44 ---
Created an attachment (id=21548)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21548action=view)
test-case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45384
1 - 100 of 253 matches
Mail list logo
