Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: townsend at astro dot wisc.edu
Target Milestone: ---
I'm attempting to build 10.2 from within a Docker container based on Centos
5.11, which ships with glibc 2.5 and gcc 4.1.2. (The reaso
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96492
--- Comment #2 from Rich Townsend ---
(In reply to Richard Biener from comment #1)
> Did GCC 10.1 work or any older version you tried to build this way in the
> past?
It's worked in 9.2, 9.3, and earlier releases; but not in 10.1.
If I try the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96492
--- Comment #4 from Rich Townsend ---
(In reply to Jakub Jelinek from comment #3)
> Can you run
> gdb --args ./cc1 -quiet -fself-test=../../gcc/gcc/testsuite/selftests
> /dev/null -o /dev/null
> and do
> run
> bt
> ?
[user@6d6cb5609b91 gcc]$ gdb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96492
--- Comment #5 from Rich Townsend ---
So, given that gcc 4.1.2 is really ancient, I've tried building 10.2 using gcc
9.3.0 instead (but still inside the Docker container). This builds fine, and in
fact I'm happy to go with this workaround.
Howev
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: townsend at astro dot wisc.edu
Target Milestone: ---
I get an ICE when compiling this example code (involving a PDT inside a PDT):
module pdt_test_m
type :: matrix (k,n)
integer, kind :: k
integer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56218
Bug #: 56218
Summary: Segfault with allocatable intent(out) derived type
argument having allocatable component
Classification: Unclassified
Product: gcc
Version: 4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56655
Bug #: 56655
Summary: Associate construct with OpenMP triggers ICE
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Prio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56656
Bug #: 56656
Summary: Suffix or operands invalid for 'movq'
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56656
--- Comment #2 from Rich Townsend 2013-03-20
02:11:30 UTC ---
(In reply to comment #1)
> Can you try to compile it out of the src directory in another directory? I
> think that is what is causing it.
Could you clarify what you mean --
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56656
--- Comment #4 from Rich Townsend 2013-03-20
04:20:56 UTC ---
(In reply to comment #3)
> svn co svn://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch gcc-src
> mkdir gcc-objdir
> cd gcc-objdir
> ../gcc-src/configure
> make
No change
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56656
--- Comment #12 from Rich Townsend 2013-03-20
12:56:53 UTC ---
(In reply to comment #9)
> So I guess an important question is if the "svn-fetched 4.8.0" wasn't actually
> "svn-fetched trunk" instead, Uros' changes have been committed only
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56655
--- Comment #2 from Rich Townsend 2013-03-20
13:25:15 UTC ---
(In reply to comment #1)
> (In reply to comment #0)
> > Created attachment 29692 [details]
> > Test source file to reproduce the error
> >
> > Attempting to compile the atta
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56670
Bug #: 56670
Summary: Allocatable-length character var causes bogus warning
with -Wall
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56748
Bug #: 56748
Summary: STOP statement + array optional variable causes bogus
uninitialized warning
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50269
Rich Townsend changed:
What|Removed |Added
CC||townsend at astro dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50269
--- Comment #6 from Rich Townsend 2013-04-01
22:24:35 UTC ---
(In reply to comment #4)
> FIXED on the 4.9 trunk.
Are we sure? When running the code example given in comment #1, I get a
segfault.
Moreover, the following subroutine won
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56872
Bug #: 56872
Summary: Incorrect SUM evaluation, involving implied-do loop,
with -ffrontend-optimize
Classification: Unclassified
Product: gcc
Version: 4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56872
--- Comment #1 from Rich Townsend 2013-04-08
06:02:42 UTC ---
Created attachment 29821
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29821
Test program to reproduce the error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55199
Bug #: 55199
Summary: Equivalenced variable has wrong type when used with
generic member function
Classification: Unclassified
Product: gcc
Version: 4.7.3
S
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55199
--- Comment #9 from Rich Townsend 2012-11-04
18:01:53 UTC ---
(In reply to comment #8)
> Fixed with r193136. Closing.
>
> Thanks for reporting this!
Hey, thanks for fixing it so quickly -- you never cease to amaze me!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47463
Summary: ICE in gfc_add_component_ref
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: fortran
AssignedTo: unassig...@gcc.gn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47463
--- Comment #3 from Rich Townsend 2011-01-27
04:06:10 UTC ---
(In reply to comment #2)
> (In reply to comment #1)
> > 4.5 fails with:
> > use hydro_recon
> > 1
> > Internal Error at (1):
> > mio_component_ref(): Component not f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47546
Summary: Internal error - free_pi_tree(): Unresolved fixup
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47546
--- Comment #4 from Rich Townsend 2011-02-02
16:52:49 UTC ---
On Feb 2, 2011, at 8:49 AM, janus at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47546
>
> --- Comment #3 from janus at gcc dot gnu.org 2011-02-02 14:49:16 U
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47546
--- Comment #9 from Rich Townsend 2011-02-02
19:56:25 UTC ---
(In reply to comment #8)
> On the other hand, the failure is very elusive: Even removing the 'implicit
> none' line in the module 'hydro_types' (which btw is never used) will make it
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47546
--- Comment #15 from Rich Townsend 2011-02-03
00:09:57 UTC ---
(In reply to comment #10)
> (In reply to comment #9)
> > Sounds like a Heisenbug -- it goes away when you look for it. Would it be
> > worth
> > bringing valgrind into the picture?
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47601
Summary: Internal Error (mio_component_ref(): Component not
found) with strange behavior
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47601
--- Comment #1 from Rich Townsend 2011-02-03
18:45:47 UTC ---
(In reply to comment #0)
> This is similar to problems I've been encountering with another code (see
> pr47456). But in cutting down the attached code to find the simplest possible
> t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47601
--- Comment #3 from Rich Townsend 2011-02-03
19:20:12 UTC ---
Created attachment 23239
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23239
Fixed Makefile
Removed some broken dependencies from the original Makefile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47601
--- Comment #5 from Rich Townsend 2011-02-03
21:17:29 UTC ---
Created attachment 23241
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23241
Revised tar archive w/ source & Makefile
Seems some stuff got left out of the tar file. Here's a new
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47546
--- Comment #17 from Rich Townsend 2011-02-03
22:54:34 UTC ---
(In reply to comment #16)
> Rich, in case this is a blocker on a real world application, you can probably
> circumvent the error by not use-importing hydro_state when you use-import
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47546
--- Comment #18 from Rich Townsend 2011-02-03
23:04:22 UTC ---
(In reply to comment #8)
> This is a *very* strange bug, to say the least. Here is a reduced test case:
>
>
> module hydro_types
> implicit none
> end module hydro_types
>
> modu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47637
Summary: Memory leak involving derived types w/ allocatable
components
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
Assignee: unassigned at gcc dot gnu.org
Reporter: townsend at astro dot wisc.edu
Created attachment 30520
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30520&action=edit
Example program
I'm experiencing a problem with:
Using built-in specs.
COLLECT_GCC=/
mponent: c
Assignee: unassigned at gcc dot gnu.org
Reporter: townsend at astro dot wisc.edu
When compiling trunk on x86_64 Fedora Core 6, I encounter the following after
configuring and running make:
make[3]: Entering directory
`/home/townsend/mesasdk-src/gcc/host-x86_64-pc-lin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57956
--- Comment #1 from Rich Townsend ---
Temporary workaround: add --disable-nls to ./configure args.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53309
--- Comment #3 from Rich Townsend ---
Thanks for the explanation about -Warray-temporaries vs.
-fcheck-array-temporaries -- got it!
Might be worth changing the output text from the former to something like
"Warning: Array temporary might be creat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58007
Rich Townsend changed:
What|Removed |Added
CC||townsend at astro dot wisc.edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53309
Bug #: 53309
Summary: Unnecessary temporary array creation in subroutine
call
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
S
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53544
Bug #: 53544
Summary: Derived-type components in namelist group declaration
produces error
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRME
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53945
Bug #: 53945
Summary: Scalar element of assumed-shape dummy array not
recognized as C interoperable
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: U
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52153
Bug #: 52153
Summary: REAL128 gives extended precision, not quad precision
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Assignee: unassigned at gcc dot gnu.org
Reporter: townsend at astro dot wisc.edu
Created attachment 31507
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31507&action=edit
Test code demonstrating leak
The attached code leaks memory, as indicated by the 'ps' call.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58007
--- Comment #11 from Rich Townsend ---
#6 fails with 4.9.0 (svn rev. 206179), on both OS X and Linux.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59589
--- Comment #1 from Rich Townsend ---
Oops, missed out details. This is with rev. 206179, on both OS X and Linux.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59589
--- Comment #3 from Rich Townsend ---
(In reply to Dominique d'Humieres from comment #2)
> Works for me on OS X for 4.8.2 or trunk. What command are you using?
townsend@talos ~ $ gfortran -v
Using built-in specs.
COLLECT_GCC=/Applications/madsdk/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59589
--- Comment #10 from Rich Townsend ---
(In reply to Dominique d'Humieres from comment #9)
> > So it's actually a regression.
>
> Marking as a regression, even if I am not fully convinced.
Further support from valgrind on x86_64-pc-linux-gnu:
==
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: townsend at astro dot wisc.edu
Target Milestone: ---
Created attachment 46748
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46748&action=edit
Leak demonstration program
The attached test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91537
--- Comment #3 from Rich Townsend ---
(In reply to Thomas Koenig from comment #1)
> Comment on attachment 46748 [details]
> Leak demonstration program
>
> Here's the output on current trunk:
>
> 862548
> 8725
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: townsend at astro dot wisc.edu
Target Milestone: ---
The following test program produces bogus -Warray-bounds warnings at compile
time:
program test_bounds
character(256) :: foo
foo
: unassigned at gcc dot gnu.org
Reporter: townsend at astro dot wisc.edu
Target Milestone: ---
Created attachment 46844
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46844&action=edit
Demo program
The intrinsics provided by the IEEE_ARITHMETIC module appear to be
signif
Assignee: unassigned at gcc dot gnu.org
Reporter: townsend at astro dot wisc.edu
Target Milestone: ---
I'm encountering a bogus subscript-in-loop warning triggered by -Wdo-subscript
Example:
--
program do_subscript_bug
implicit none
real:: a(10)
integer :: i
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: townsend at astro dot wisc.edu
Target Milestone: ---
The zero-length character literal following example program triggers a bogus
array-bounds warning:
--
program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90238
--- Comment #1 from Rich Townsend ---
An even-simpler demo:
--
program test_str_2
write(*,*) ''
end program test_str_2
--
Compile with -O2 -Warray-bounds gives
test_str_2.f90:3:0:
write(*,*) ''
Warning: array subscript 1 is above arra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90238
--- Comment #3 from Rich Townsend ---
(In reply to kargl from comment #2)
> -Warray-bounds is a generic GCC option, and is used in the
> middle end for reporting warnings. When you use this option
> it does not recognize that a Fortran string is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90238
--- Comment #5 from Rich Townsend ---
(In reply to Steve Kargl from comment #4)
> It's certainly confusing. gfortran.info includes
> -Warray-bounds as a warning option, but there is no
> description for the option. Grepping the gfortran
> sour
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86148
Rich Townsend changed:
What|Removed |Added
CC||townsend at astro dot wisc.edu
Assignee: unassigned at gcc dot gnu.org
Reporter: townsend at astro dot wisc.edu
Target Milestone: ---
The test program below causes an internal compiler error, that appears to be
linked to the polymorphic assignment:
--
program test
implicit none
type f_t
end type f_t
NCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: townsend at astro dot wisc.edu
Target Milestone: ---
I'm running into a bug building on OSX Mojave, which seems to be tied into th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90558
--- Comment #2 from Rich Townsend ---
(In reply to Andrew Pinski from comment #1)
> Dup.
>
> *** This bug has been marked as a duplicate of bug 89864 ***
Are you sure? The discussion in 89864 indicates that the patch to fix this bug
should be i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90558
--- Comment #6 from Rich Townsend ---
(In reply to Rich Townsend from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > Dup.
> >
> > *** This bug has been marked as a duplicate of bug 89864 ***
>
> Are you sure? The discussion in 89
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90558
--- Comment #7 from Rich Townsend ---
(In reply to Rich Townsend from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > Dup.
> >
> > *** This bug has been marked as a duplicate of bug 89864 ***
>
> Are you sure? The discussion in 89
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: townsend at astro dot wisc.edu
Target Milestone: ---
Created attachment 44380
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44380&action=edit
Example program showing the leak
I've come across a memo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86481
--- Comment #1 from Rich Townsend ---
As addenda:
*) I also see the problem on gfortran 8.1
*) It doesn't seem to matter whether bar_t is a subclass of foo_t. This choice
was based on the code I developed the test case for, but removing the
ext
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: townsend at astro dot wisc.edu
Target Milestone: ---
I'm getting an undefined symbol at link time when compiling the following test
program, which involves intrinsic polymo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55387
Bug #: 55387
Summary: Build problem: malloc error in genautomata
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69268
--- Comment #3 from Rich Townsend ---
Proposed patch appears to work in the real-world case I'm focused on. Thanks!
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: townsend at astro dot wisc.edu
Target Milestone: ---
Created attachment 38298
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38298&action=edit
Example program
In the example program attached, comp
: unassigned at gcc dot gnu.org
Reporter: townsend at astro dot wisc.edu
Target Milestone: ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81241
--- Comment #1 from Rich Townsend ---
(Apologies for the initial blank description, my web-browser submitted before I
was ready).
I've recently upgraded to gfortran 7.1 from 5.3, and am seeing a large number
of breakages in a significant piece o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81241
--- Comment #2 from Rich Townsend ---
Aha, given that MESA is multithreaded, this may well be linked to this issue:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78387
Certainly, running with just 1 thread seems to make things behave.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81241
--- Comment #6 from Rich Townsend ---
Jim's patch for pr81195 fixes all the issues we've been experiencing -- so yes,
this counts as a duplicate. Thanks to all for the quick response.
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: townsend at astro dot wisc.edu
Target Milestone: ---
Created attachment 40709
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40709&action=edit
Example program
A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79446
--- Comment #2 from Rich Townsend ---
(In reply to Dominique d'Humieres from comment #1)
> > Also, I don't experience the segfault on other Linux distros
> > (e.g., Gentoo/3.16.5) or Mac OS.
>
> Confirmed on x86_64-apple-darwin16, even using an
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: townsend at astro dot wisc.edu
The following code:
program foo
real, allocatable :: a(:,:)
real, allocatable :: b(:,:)
allocate(a(10,5))
a = 0.
b = TRANSPOSE(a)
end
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: townsend at astro dot wisc.edu
Created attachment 34184
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34184&action=edit
Code to reproduce the crash
I'm encountering an ICE when compiling the attached cod
: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: townsend at astro dot wisc.edu
I'm trying to build the latest trunk (rev. 218759) on Linux. Configuring with:
./configure CC=gcc --build=x86_64-pc-linux-gnu --prefix=/root/madsdk
--with-gmp=/root/madsdk --with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64320
--- Comment #1 from Rich Townsend ---
OK, it seems that this bug comes from building with srcdir == objdir. If I
build in a separate directory, then the problem goes away.
As an aside, I hadn't realized that using srcdir == objdir is generally
d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56218
--- Comment #4 from Rich Townsend ---
Seems to work fine on 4.10 (20140710).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60324
Rich Townsend changed:
What|Removed |Added
CC||townsend at astro dot wisc.edu
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: townsend at astro dot wisc.edu
Target Milestone: ---
Created attachment 37255
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37255&action=edit
Source code of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69185
--- Comment #2 from Rich Townsend ---
(In reply to Dominique d'Humieres from comment #1)
> It looks like a duplicate of pr52162. Unless you object I'll mark this PRas
> a duplicate in the coming days.
Agreed!
Assignee: unassigned at gcc dot gnu.org
Reporter: townsend at astro dot wisc.edu
Target Milestone: ---
Created attachment 37338
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37338&action=edit
Source code of program reproducing the problem
The attached
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47546
--- Comment #19 from Rich Townsend 2011-03-16
02:29:35 UTC ---
(In reply to comment #18)
> (In reply to comment #8)
> > This is a *very* strange bug, to say the least. Here is a reduced test case:
> >
> >
> > module hydro_types
> > implicit n
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48145
Summary: Generic interfaces & derived types cannot share names
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48939
Summary: ICE in code involving procedure pointers
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassig
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47601
--- Comment #12 from Rich Townsend 2011-05-26
18:05:35 UTC ---
Do we have any progress in fixing this one? It's become a showstopper for me,
alas!
(Serves me right for starting a number of new, large projects in F2003).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47601
--- Comment #14 from Rich Townsend 2011-05-26
21:43:27 UTC ---
> Fails for me on x86_64-unknown-linux-gnu with 4.5, 4.6 and 4.7. Apparently
> related to type extension.
I think the bug can be summarized thus:
*) The error is triggered by USEing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47601
--- Comment #28 from Rich Townsend 2011-05-29
21:10:08 UTC ---
(In reply to comment #27)
> r174416 fixes all the test cases in this PR (except comment #11, which is
> invalid). I'm glad we finally nailed this one.
>
> Closing as fixed. Thanks fo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49466
Summary: Memory leak with assignment of extended derived types
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49466
--- Comment #2 from Rich Townsend 2011-06-19
15:39:28 UTC ---
(In reply to comment #1)
> (In reply to comment #0)
> > In the attached sample code, which is a reduced test case from the full
> > code,
> > the assignment "as_b = as_a" leaks memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49466
--- Comment #6 from Rich Townsend 2011-06-19
18:57:40 UTC ---
(In reply to comment #5)
> > In the first assignment b.U is allocated, in the second assignment it is not
> > freed, before being allocated again.
>
> I don't think it should be freed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47601
--- Comment #34 from Rich Townsend 2011-06-19
21:18:47 UTC ---
Thanks, Janus -- you rock!
On Jun 19, 2011, at 4:16 PM, janus at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47601
>
> --- Comment #33 from janus at gcc do
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48351
Rich Townsend changed:
What|Removed |Added
CC||townsend at astro dot
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: townsend at astro dot wisc.edu
Target Milestone: ---
Created attachment 39054
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39054&action=edit
Test case demonstrating problem
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72798
--- Comment #2 from Rich Townsend ---
Hmm, I can understand why having an internal pure attribute makes sense from an
optimiser point of view. But it results in having lots of compilation cascades
during debugging, which sucks.
Is there a way to
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: townsend at astro dot wisc.edu
Target Milestone: ---
Created attachment 50335
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50335&action=edit
Example program
I thi
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: townsend at astro dot wisc.edu
Target Milestone: ---
Created attachment 49844
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49844&action=edit
Minimal working example
I'm running into what I bel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98445
--- Comment #2 from Rich Townsend ---
I know it's acceptable to overload a type name with one or more functions --
from 12.4.3.4.1 of the F2008 standard,
"A generic name may be the same as a derived-type name, in which case all of
the procedures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98445
--- Comment #3 from Rich Townsend ---
OK, my code isn't valid -- it's not permitted to pass a generic procedure name
as an actual argument. As such, gfortran is correct in its behavior.
Happy for this one to be closed -- sorry for the false alar
1 - 100 of 120 matches
Mail list logo
