https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103276
Salvatore Filippone changed:
What|Removed |Added
CC||sfilippone at uniroma2 dot it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846
--- Comment #13 from Salvatore Filippone ---
Created attachment 35996
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35996&action=edit
test case
Cleaned up a bit of noise due to the process of reducing the test case: it was
spitting out a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846
--- Comment #12 from Salvatore Filippone ---
(In reply to Salvatore Filippone from comment #11)
> Created attachment 35995 [details]
> test case
Enjoy :)
[sfilippo@jacobi tlink]$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846
--- Comment #11 from Salvatore Filippone ---
Created attachment 35995
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35995&action=edit
test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846
--- Comment #9 from Salvatore Filippone ---
(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): undefined reference to
`_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846
--- Comment #8 from Salvatore Filippone ---
(In reply to Paul Thomas from comment #7)
> Created attachment 35926 [details]
> A partially cooked patch to complete the implentation of submodules
>
> The attached is a first attempt to complete the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66280
--- Comment #12 from Salvatore Filippone ---
Created attachment 35763
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35763&action=edit
test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66280
Salvatore Filippone changed:
What|Removed |Added
CC||sfilippone at uniroma2 dot it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
--- Comment #66 from Salvatore Filippone ---
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 i = 2, 1" would then be e
: 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=33881&action=edit
test case
Hi,
The attached test case, slightly modified from an original by Alberto F.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61830
--- Comment #1 from Salvatore Filippone ---
Created attachment 33133
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33133&action=edit
workaround
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=33132&action=edit
test case
Hi,
The attached cod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60922
--- Comment #4 from Salvatore Filippone ---
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 allocatable).
Salvatore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61819
--- Comment #7 from Salvatore Filippone ---
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 guess that would be no small t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61819
--- Comment #5 from Salvatore Filippone ---
Code works with 4.8.3, so this is a regression.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61819
Salvatore Filippone changed:
What|Removed |Added
Attachment #33127|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61819
--- Comment #2 from Salvatore Filippone ---
Same ICE with a fresh trunk as of today.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61819
--- Comment #1 from Salvatore Filippone ---
Created attachment 33127
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33127&action=edit
test case
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 on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60922
Salvatore Filippone changed:
What|Removed |Added
Summary|[4.10 regression] Memory |[4.9/4.10 regression]
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=32653&action=edit
test case
Attached co
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=31565&action=edit
testcase
The attached code fails with current trunk wi
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=30274&action=edit
Test case
The attached code generates the ICE when c
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=30267&action=edit
Test case
The attached code triggers an ICE with debug optio
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
--- Comment #21 from Salvatore Filippone
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
> > that have a CLASS,ALLOCATABLE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54618
--- Comment #19 from Salvatore Filippone
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 component; however when I tried
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54618
Salvatore Filippone changed:
What|Removed |Added
CC||sfilippone at uniroma2 dot
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
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 on darwin is a regression (whi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54874
--- Comment #8 from Salvatore Filippone
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. It seems wrong, I
> > > do n
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54874
--- Comment #6 from Salvatore Filippone
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 why allocating the pol
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54874
--- Comment #4 from Salvatore Filippone
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-darwin10, compiling the
> at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54874
--- Comment #2 from Salvatore Filippone
2012-10-09 10:37:13 UTC ---
And it is also a regression, as it works on 4.6.3:
---
[sfilippo@jacobi bug34]$ gfortran -v
Using built-in specs.
COL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54874
--- Comment #1 from Salvatore Filippone
2012-10-09 10:02:41 UTC ---
Interestingly, taking out the outer container p% makes the code work...
---
[sfilippo@jacobi bug34]$ gfo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54784
--- Comment #9 from Salvatore Filippone
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
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
Salvatore Filippone changed:
What|Removed |Added
CC||sfilippone at uniroma2 dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46321
--- Comment #5 from Salvatore Filippone
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:
>
> - explicit DEALLOCATE (cf.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38813
--- Comment #7 from Salvatore Filippone
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 type foo_type
end module foo_mod
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38813
Salvatore Filippone changed:
What|Removed |Added
CC||sfilippone at uniroma2 dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48699
--- Comment #23 from Salvatore Filippone
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 #12 from Salvatore Filippone
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 it does.
No (new) worries here
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47978
--- Comment #8 from Salvatore Filippone
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 is wrong in this respect
:(
Sa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47978
--- Comment #9 from Salvatore Filippone
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=48699
--- Comment #15 from Salvatore Filippone
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 that was added in F2008 or was it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48699
--- Comment #3 from Salvatore Filippone
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 in the sense that the test cases fo
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
Compon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48699
--- Comment #1 from Salvatore Filippone
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=48699
Summary: [OOP] MOVE_ALLOC of polymorphic variables
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47978
--- Comment #1 from Salvatore Filippone
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=47978
Summary: [OOP] Invalid INTENT in overriding TBP not detected
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assigned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46448
--- Comment #3 from Salvatore Filippone
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 think that can be assumed ;
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
Comp
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: unassig...@
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46838
--- Comment #6 from Salvatore Filippone
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.f90
> etc), but the follow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46838
--- Comment #3 from Salvatore Filippone
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 creation time : 1.69176E-01
[local
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
--- Comment #2 from Salvatore Filippone
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, but not necessarily minimal.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46809
--- Comment #1 from Salvatore Filippone
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/gnu46/libexec/gcc/x86_64-unknown-
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: unassig...@gcc.gnu.or
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46448
Salvatore Filippone changed:
What|Removed |Added
CC||sfilippone at uniroma2 dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46344
--- Comment #7 from Salvatore Filippone
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 0: T
> a.out(84352) mall
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: s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46174
Salvatore Filippone changed:
What|Removed |Added
CC||sfilippone at uniroma2 dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45451
--- Comment #11 from Salvatore Filippone
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 4 5
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45795
--- Comment #6 from Salvatore Filippone
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!
Well, considering how many ti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45795
--- Comment #4 from Salvatore Filippone
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 #3 from Salvatore Filippone
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
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
Comp
--- 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 t
--- 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
--- 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=21673&action=view) [edit]
>
Modifying the conftest source gives the following:
[sn
--- 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=21653&action=view)
test-case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45494
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 triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://g
--- 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=21646&action=view)
stage 2 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=21645&action=view)
stage 2 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=21644&action=view)
stage 1 libiberty/config.h
--
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=21643&action=view)
stage 1 libiberty/config.log
--
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=21642&action=view)
Main config.log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45482
ootstrap fails on PPC error: conflicting types for
'malloc'
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
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 #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=21613&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45451
--- 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_ALLO
--- 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 sho
--- 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
--- 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
--- 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
>
--- 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=21592&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45451
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/show_bug.cgi?id=45451
--- 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=21583&action=view)
test case
The code compiles cleanly with XLF.
If I switch the commented lines in the CLASS DEFAULT cla
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 dot it
GCC build triplet: x86_64-unknown-
--- 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=21581&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45438
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=45438
--- 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
--- 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 pr
--- 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 nee
--- 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 pro
--- 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_s
--- 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 #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=21548&action=view)
test-case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45384
1 - 100 of 254 matches
Mail list logo
