https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112828
--- Comment #5 from Rich Townsend ---
One more data point: I tried with gfortran 13.2.0 on Linux/Intel and get the
same result as for 13.1.0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112828
--- Comment #4 from Rich Townsend ---
Another data point for MacOS/Intel (10.13.6, High Sierra) -- with the character
vars set to length 64, the crash is as follows:
test(3287,0x7fff8fc11380) malloc: *** error for object 0x7fe44cc03b58:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112828
--- Comment #3 from Rich Townsend ---
I can get the MWE to barf on MacOS/Arm (Sonoma 14.1.1), gfortran 13.1.0, by
changing the length of the character vars in the main program from 64 to 16.
The error is now:
In file 'test.f90', around line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112828
--- Comment #2 from Rich Townsend ---
The problem manifests with gfortran 13.1.0 on Linux/x86_64. I've run into
similar looking problems on MacOS/Arm, but the MWE I provided seems to work OK
on Arm.
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: townsend at astro dot wisc.edu
Target Milestone: ---
Created attachment 56768
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56768=edit
MWE demonstrating problem
When I compile the attached MWE with
gfortran -o t
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: townsend at astro dot wisc.edu
Target Milestone: ---
I've run into a problem that's demonstrated by the following code:
--
module avs_m
type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110659
--- Comment #9 from Rich Townsend ---
OK, I managed to get things working by setting
export LDFLAGS='-Wl,--no-eh-frame-hdr'
prior to configuring. I'm hoping this won't affect the functionality of the
built compiler.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110659
--- Comment #7 from Rich Townsend ---
(In reply to Andrew Pinski from comment #6)
> GCC 13 won't build with anything older than GCC 4.8.x as documented at
> https://gcc.gnu.org/install/prerequisites.html (which is right now for the
> trunk but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110659
--- Comment #5 from Rich Townsend ---
(In reply to Andrew Pinski from comment #2)
> What compiler did you start with?
> That is what is the output of `x86_64-pc-linux-gnu-g++ -v` ?
[user@60947d0cbd04 ~]$ x86_64-pc-linux-gnu-g++ -v
bash:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110659
--- Comment #4 from Rich Townsend ---
Someone else seems to have the same problem:
https://stackoverflow.com/questions/76375244/how-can-i-resolve-a-ld-eh-frame-hdr-refers-to-overlapping-fdes-error-during
...although there is no fix suggested.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110659
--- Comment #1 from Rich Townsend ---
I should add that this is on CentOS 5.11, running inside a Docker container.
This ships with a very old binutils, so before trying to compile gcc I
installed binutils 2.40 (built from source with
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: townsend at astro dot wisc.edu
Target Milestone: ---
I'm running into the following problem during a build of the 13.1.0 release:
x86_64-pc-linux-gnu-g++ -std=c++11 -g -DIN_GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110650
--- Comment #3 from Rich Townsend ---
Sure thing:
GNU ld version 2.17.50.0.6-26.el5 20061020
I'm deliberately working with an old toolchain, inside a Docker container, to
make sure that when I distribute the gcc executables they will work OK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110650
--- Comment #1 from Rich Townsend ---
Oops, posted without any bug description!
I'm trying to build gcc 13.1.0 on Linux x86_64, and I get the following
segfault:
libtool: compile: /home/user/sdk2-tmp/build/gcc-build/./gcc/xgcc
-shared-libgcc
: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: townsend at astro dot wisc.edu
Target Milestone: ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110629
--- Comment #3 from Rich Townsend ---
Thanks for the quick responses, folks. The problem persists in 12.3.0 release,
but is fixed in 13.1.0 release.
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: townsend at astro dot wisc.edu
Target Milestone: ---
I've run into a problem with intrinsic assignment of derived types with
allocatable character components. This seems
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: townsend at astro dot wisc.edu
Target Milestone: ---
I've run into problems with assignment of derived types containing an
allocatable array of deferred
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992
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 50335
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50335=edit
Example program
I think I
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: townsend at astro dot wisc.edu
Target Milestone: ---
Created attachment 50222
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50222=edit
Minimal working example
I
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
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
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=edit
Minimal working example
I'm running into what I believe to be a bo
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.
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]$
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
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 reason I'm
: 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
: 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=edit
Demo program
The intrinsics provided by the IEEE_ARITHMETIC module appear to be
significantly slo
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
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
> 87
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=edit
Leak demonstration program
The attached test program demonstra
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
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
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
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 the
problems
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86148
Rich Townsend changed:
What|Removed |Added
CC||townsend at astro dot wisc.edu
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
>
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
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
: 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
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
a = 0
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 polymorphic
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
: 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=edit
Example program showing the leak
I've come across a memory leak with gfort
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.
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 #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
: unassigned at gcc dot gnu.org
Reporter: townsend at astro dot wisc.edu
Target Milestone: ---
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
Target Milestone: ---
Created attachment 40709
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40709=edit
Example program
Attached prog
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
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=edit
Test case demonstrating problem
In a big proj
: 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=edit
Example program
In the example program attached, compilation (gfortran
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!
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=edit
Source code of program reproducing the problem
The attached program demonstra
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!
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=edit
Source code of program reproduc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64320
--- Comment #1 from Rich Townsend townsend at astro dot wisc.edu ---
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
: 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-mpfr
: 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=34184action=edit
Code to reproduce the crash
I'm encountering an ICE when compiling the attached code with 4.9.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56218
--- Comment #4 from Rich Townsend townsend at astro dot wisc.edu ---
Seems to work fine on 4.10 (20140710).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60324
Rich Townsend townsend at astro dot wisc.edu changed:
What|Removed |Added
CC||townsend
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59589
--- Comment #10 from Rich Townsend townsend at astro dot wisc.edu ---
(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
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=31507action=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 townsend at astro dot wisc.edu ---
#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 townsend at astro dot wisc.edu ---
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 townsend at astro dot wisc.edu ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58007
Rich Townsend townsend at astro dot wisc.edu changed:
What|Removed |Added
CC||townsend
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53309
--- Comment #3 from Rich Townsend townsend at astro dot wisc.edu ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57956
--- Comment #1 from Rich Townsend townsend at astro dot wisc.edu ---
Temporary workaround: add --disable-nls to ./configure args.
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-linux-gnu/gcc
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=30520action=edit
Example program
I'm experiencing a problem with:
Using built-in specs.
COLLECT_GCC=/Applications
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 townsend at astro dot wisc.edu 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=50269
Rich Townsend townsend at astro dot wisc.edu changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50269
--- Comment #6 from Rich Townsend townsend at astro dot wisc.edu 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
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:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56656
--- Comment #12 from Rich Townsend townsend at astro dot wisc.edu 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56655
--- Comment #2 from Rich Townsend townsend at astro dot wisc.edu 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
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=56655
Bug #: 56655
Summary: Associate construct with OpenMP triggers ICE
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56656
--- Comment #2 from Rich Townsend townsend at astro dot wisc.edu 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56656
--- Comment #4 from Rich Townsend townsend at astro dot wisc.edu 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
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=55387
Bug #: 55387
Summary: Build problem: malloc error in genautomata
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55199
--- Comment #9 from Rich Townsend townsend at astro dot wisc.edu 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
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
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:
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:
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
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48351
Rich Townsend townsend at astro dot wisc.edu changed:
What|Removed |Added
CC||townsend
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49466
--- Comment #2 from Rich Townsend townsend at astro dot wisc.edu 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49466
--- Comment #6 from Rich Townsend townsend at astro dot wisc.edu 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47601
--- Comment #34 from Rich Townsend townsend at astro dot wisc.edu 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
1 - 100 of 120 matches
Mail list logo
