Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: townsend at astro dot wisc.edu
Target Milestone: ---
Created attachment 60078
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60078&action=edit
Code that demonstrates the issue
When compiling the a
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:
incorre
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 49:
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&action=edit
MWE demonstrating problem
When I compile the attached MWE with
g
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_
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 t
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: x86_64-
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 --disable-g
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 -DI
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 o
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
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 def
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&action=edit
Example program
I thi
: 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&action=edit
Minimal working
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
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
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=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
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 #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 reaso
: 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&action=edit
Demo program
The intrinsics provided by the IEEE_ARITHMETIC module appear to be
signif
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
> 8725
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=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
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 #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
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
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
> sour
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 #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
: 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
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
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
: 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=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 o
: 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&action=edit
Example program
A
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 39054
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39054&action=edit
Test case demonstrating problem
I
: 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
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&action=edit
Source code of program reproducing the problem
The attached
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&action=edit
Source code of
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
: 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
: 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60324
Rich Townsend changed:
What|Removed |Added
CC||townsend at astro dot wisc.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56218
--- Comment #4 from Rich Townsend ---
Seems to work fine on 4.10 (20140710).
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 ---
(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:
==
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 #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=58007
--- Comment #11 from Rich Townsend ---
#6 fails with 4.9.0 (svn rev. 206179), on both OS X and Linux.
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
Rich Townsend changed:
What|Removed |Added
CC||townsend at astro dot wisc.edu
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=57956
--- Comment #1 from Rich Townsend ---
Temporary workaround: add --disable-nls to ./configure args.
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
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=/
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=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=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=50269
Rich Townsend changed:
What|Removed |Added
CC||townsend at astro dot
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=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
--- 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=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=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 #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
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=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=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 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=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=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=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=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=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 changed:
What|Removed |Added
CC||townsend at astro dot
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=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
1 - 100 of 121 matches
Mail list logo
