With revisions 128349 and 128362 a clean bootstrap fails now at stage two with:
...
mkdir powerpc-apple-darwin8/libgcc
Checking multilib configuration for libgcc...
Configuring stage 2 in powerpc-apple-darwin8/libgcc
configure: creating cache ./config.cache
checking for --enable-version-specific-r
--- Comment #6 from dominiq at lps dot ens dot fr 2007-09-11 08:47 ---
> If this is case 2 ...
Yes
> then the answers are ...
> Yes.
Why? more precisely what are the rules behind this yes?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33296
--- Comment #3 from rask at gcc dot gnu dot org 2007-09-11 08:52 ---
This was a newlib bug.
--
rask at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #3 from aldot at gcc dot gnu dot org 2007-09-11 09:37 ---
Created an attachment (id=14186)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14186&action=view)
slightly reduced testcase
ICEs with -O1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33382
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2007-09-11 09:38
---
(In reply to comment #9)
> It is the same, I just wanted to summarize in patch form. If we have an
> approval then I can commit asap.
Sorry for being so slow on that one, I only have limited net access. I have
s
Hi,
In my application a wrong CASE is occationally selected in a SELECT statement.
I've not been able to reduce the code to do the wrong jump. However, the
following simple code run through valgrind gives uninitialized variable
warnings, which i think might be the source of the problem:
PROGRAM t
Some Fortran intrinsics, like NEAREST or EXPONENT, are translated into calls to
libgfortran functions, which in turn call C99 functions. We could easily
generate C99 calls directly from the front-end, which would enable further
optimization by the middle-end.
The list of intrinsics I think of for
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-09-11 09:55
---
(In reply to comment #6)
> Why? more precisely what are the rules behind this yes?
Short answer: the statements are treated independently in the front-end.
When the front-end sees: "nearest(huge(1.0),1.0)", it p
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-09-11 10:15
---
(In reply to comment #4)
> Do I need to file an update to the bug or can you just close it out?
Closing.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33381
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-09-11 10:27
---
I'll work on that, I've re-written CHARACTER SELECT recently. However, I can't
reproduce this on x86_64-linux. Could you run "gfortran -fdump-tree-original
a.f90" and post the a.f90.003t.original file produced?
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-09-11 10:29
---
Another question: what is the output of the command lines if you add the "-v"
flag?
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-09-11 10:38 ---
int
select_string (select_struct *table, int table_len, const char *selector,
int selector_len)
{
select_struct *t;
int i, low, high, mid;
int default_jump;
The issue is default_jump is used un
--- Comment #3 from jpr at csc dot fi 2007-09-11 10:42 ---
(In reply to comment #1)
> I'll work on that, I've re-written CHARACTER SELECT recently. However, I can't
> reproduce this on x86_64-linux. Could you run "gfortran -fdump-tree-original
> a.f90" and post the a.f90.003t.original fi
--- Comment #19 from dominiq at lps dot ens dot fr 2007-09-11 10:44 ---
In order to avoid a too long post, I am splitting my answer in pieces.
> PS: I should note that the bug in question is a relatively minor one:
> lround(), on ppc-glibc and AIX, returns a wrong answer for the
> float
--- Comment #8 from dominiq at lps dot ens dot fr 2007-09-11 10:48 ---
Subject: Re: nearest(huge(1.0),1.0) gives an error
> (Doing so is a missed optimization, now filed as PR33387.)
When fixed, will the second test throw an error or not?
While looking for jokes about Intel, I cannot
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-09-11 10:48
---
> Adding a default case gets rid of the problems, also for my real application
> code.
If you're in a position to build the compiler yourself, could you try the
following patch? I think it should fix the problem
--- Comment #44 from giovannibajo at libero dot it 2007-09-11 10:59 ---
Daniel, are you then going to fix the "slow" part of this bug?
As for the memhog, CC'ing Honza which is expert on memory allocations and leaks
:)
--
giovannibajo at libero dot it changed:
What|Re
--- Comment #20 from fxcoudert at gcc dot gnu dot org 2007-09-11 11:06
---
(In reply to comment #19)
> More seriously, the test fails for the above values, but this does not mean
> that it does not fail for other values.
Sorry, I was posting in a haste and was to affirmative. What I me
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-09-11 11:10
---
This patch looks OK and obvious, although I can't test it myself. Could any of
the Ada maintainer test and commit?
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed
--- Comment #21 from dje at gcc dot gnu dot org 2007-09-11 11:29 ---
AIX defect number 628397 opened against the math library.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33271
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-09-11 11:31 ---
A bug in VRP respective its friend SCEV.
iin_5 = i_1 - 1;
lin_6 = iin_5;
pin_7 = (void *) iin_5;
iout_8 = iin_5;
printf (&" %d - In: %d, %ld (%p), Out: %ld\n"[0], i_1, iin_5, iin_5, pin_7,
iin_5);
i_9 =
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-09-11 11:33 ---
I think this is related (but not exactly dup) of PR33099.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from freeboy1212 at hotmail dot com 2007-09-11 11:35 ---
(In reply to comment #3)
> Another question: what is the output of the command lines if you add the "-v"
> flag?
>
F:\>gcj -v
Using built-in specs.
Reading specs from libgcj.spec
gcj: libgcj.spec: No such file or d
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-09-11 11:37 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #5 from freeboy1212 at hotmail dot com 2007-09-11 11:41 ---
(In reply to comment #2)
> Where did you get GCJ/GCC? Was it a binary package or did you compile it
> yourself?
I'dont know. It was already installed by other colleague. Is that very
important?
> Is this on vista?
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32590
There is a failure building libgcc with revision 128358:
Configure flags:
--target fr30-unknown-elf --enable-checking=yes,rtl --with-newlib --enable-sim
--disable-gdb --disable-nls
Using the preprocessed source:
$ gcc/xgcc -Bgcc/ -Os ~/negdi2.c -S -o /dev/null
/n/12/rask/src/all/libgcc/../gcc/lib
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32653
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32656
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32921
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33088
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33100
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33368
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33369
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33383
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Summary|4.3 performance regression |[4.3 Regression] performance
|on uint64_t operations
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Summary|Revision 121302 causes 30% |[4.3 Regression] Revision
|performance regression
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Summary|10% to 20% Performance |[4.3 Regression] 10% to 20%
|Regression Between 4.1.3
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-09-11 12:08 ---
Created an attachment (id=14187)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14187&action=view)
untested patch
testing appreciated (I'm at a conference right now)
--
rguenth at gcc dot gnu dot org change
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-09-11 12:08 ---
Note mailine is fixed by doing PTA "correct" now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33382
--- Comment #3 from sylvain dot pion at sophia dot inria dot fr 2007-09-11
12:16 ---
Hi Doug,
I tried your patch, and it seems to have a good effect, since I do not see
this error anymore. That said, I now get another one, which looks pretty
similar:
In file included from /usr/includ
--- Comment #7 from hjl at lucon dot org 2007-09-11 12:24 ---
Binutils 2.15 is very old. Can you try binutils 2.18?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33100
--- Comment #1 from rask at gcc dot gnu dot org 2007-09-11 12:29 ---
More problems:
/n/12/rask/src/all/libgcc/../gcc/libgcc2.c: In function '__popcountdi2':
/n/12/rask/src/all/libgcc/../gcc/libgcc2.c:813: internal compiler error: RTL
check: expected code 'reg', have 'mem' in rhs_regno,
--- Comment #8 from ro at gcc dot gnu dot org 2007-09-11 12:46 ---
Created an attachment (id=14188)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14188&action=view)
crtend.s without -fno-asynchronous-unwind-tables
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33100
--- Comment #9 from ro at gcc dot gnu dot org 2007-09-11 12:47 ---
Created an attachment (id=14189)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14189&action=view)
crtend.s with -fno-asynchronous-unwind-tables
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33100
--- Comment #10 from ro at techfak dot uni-bielefeld dot de 2007-09-11
12:48 ---
Subject: Re: [4.3 regression] on bootstrap getting section .eh_frame: bad cie
version 0: offset 0x0
hjl at lucon dot org writes:
> Binutils 2.15 is very old. Can you try binutils 2.18?
It doesn't make a
--- Comment #5 from jpr at csc dot fi 2007-09-11 12:49 ---
Subject: Re: Fortran SELECT statement miscompiles
Yes, this seems to do the trick.
Thanx, Juha
>
>
> --- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-09-11 10:48
> ---
>> Adding a default case gets rid of
--- Comment #3 from simon dot marshall at misys dot com 2007-09-11 12:51
---
This seems to apply to 4.2.2-RC-20070909 too.
--
simon dot marshall at misys dot com changed:
What|Removed |Added
--- Comment #45 from dberlin at gcc dot gnu dot org 2007-09-11 12:58
---
Subject: Re: [4.2/4.3 Regression] points-to analysis slow and memory hungry
Uh, it's not slow anymore since I committed the patch last month.
On 11 Sep 2007 10:59:31 -, giovannibajo at libero dot it
<[EMAIL
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |minor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33387
Revision 128239 causes some random libgomp failures on Linux/ia64:
FAIL: libgomp.c/loop-1.c execution test
FAIL: libgomp.c/nestedfn-4.c execution test
FAIL: libgomp.c/omp-loop01.c execution test
FAIL: libgomp.c/ordered-2.c execution test
FAIL: libgomp.c/pr26943-4.c execution test
FAIL: libgomp.c/p
--- Comment #11 from hjl at lucon dot org 2007-09-11 13:43 ---
.eh_frame section in the new crtend.S only has 4 byte:
[ 7] .eh_frame X86_64_UNWIND 00b8
0004 A 0 0 4
which is the zero terminator:
ba
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2007-09-11 13:59
---
Probably everywhere.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
I configured with -
../gcc/configure --prefix=/usr/local/java --enable-languages=c,c++,java
--with-ecj-jar=/Users/dir/gfortran/gcc/ecj.jar --enable-java-awt=gtk
--enable-gtk-cairo --disable-multilib --x-includes=/usr/X11R6/include
--x-libraries=/usr/X11R6/lib
The build set for 10 hours at -
rm -
--- Comment #1 from hubicka at gcc dot gnu dot org 2007-09-11 14:10 ---
This seems to be latent problem unconvered by -finline-small-functions patch.
Perlbmk was failing at -O3 on older SVN snapshots too.
-finline-small-functions should work as an workaround until the issue is
identifi
--- Comment #1 from dir at lanl dot gov 2007-09-11 14:15 ---
A top shows "cc1" running and eating time, but never finishing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33390
--- Comment #2 from hjl at lucon dot org 2007-09-11 14:16 ---
It is very likely that it is perl which is miscompiled. It looks quite
serious to me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33383
--- Comment #3 from hubicka at gcc dot gnu dot org 2007-09-11 14:22 ---
Sure, it will be neccessary to do some binary to figure out what inlining
breaks the benchmark. Not having the CPU2006 sources, I will be able to do so
until Monday. But if I remember right, it reproduced down to 3
gfortran.dg/do_3.F90 started FAILing somewhere between rev. 128091 and rev.
128123 (see testresults for that period) on i386-linux, i686-linux and
x86_64-linux. Reduced testcase is:
program test
integer(kind=1) :: i
do i = -128, 127
end do
if (i /= -128) call abort
end progra
--- Comment #2 from ubizjak at gmail dot com 2007-09-11 14:45 ---
Could be fixed by http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00976.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33390
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-09-11 14:47
---
It's also failing on s390x-ibm-linux-gnu and powerpc-ibm-aix.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-09-11 14:53
---
Subject: Bug 33386
Author: fxcoudert
Date: Tue Sep 11 14:53:02 2007
New Revision: 128379
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128379
Log:
PR libfortran/33386
* runtime/select.c (
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-09-11 14:54
---
Fixed. Thanks for the bug report.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from burnus at gcc dot gnu dot org 2007-09-11 14:59 ---
Isn't this what http://gcc.gnu.org/ml/gcc/2007-09/msg00087.html (plus/minus a
few emails in the thread) is about?
Using -fno-strict-overflow they pass. I think we can simply add this option to
the test case; or do yo
--- Comment #5 from bonzini at gnu dot org 2007-09-11 15:13 ---
changed 32283 from "blocks" to "depends on"; this might be fixed in 4.3
--
bonzini at gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-09-11 15:23
---
(In reply to comment #2)
> Isn't this what http://gcc.gnu.org/ml/gcc/2007-09/msg00087.html (plus/minus a
> few emails in the thread) is about?
Yes, you're right.
> -fstrict-overflow
> Allow the compiler to assum
--- Comment #4 from burnus at gcc dot gnu dot org 2007-09-11 15:34 ---
> > -fstrict-overflow
> > Allow the compiler to assume strict signed overflow rules, depending on the
> > language being compiled.
> Well, I think the "depending on the language being compiled" is important. I
> think
--- Comment #9 from jason at gcc dot gnu dot org 2007-09-11 15:35 ---
Fixed for 4.2.2.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASS
--- Comment #5 from dominiq at lps dot ens dot fr 2007-09-11 15:40 ---
> Well, I think the "depending on the language being compiled" is important. I
> think the testcase is valid Fortran, and shouldn't fail whatever the
> optimization level you use.
FX, may I recall what you wrote in P
--- Comment #3 from dominiq at lps dot ens dot fr 2007-09-11 15:46 ---
Is this a duplicate of PR33384?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33390
make: Entering directory `/home/voax/linux/build-4.3.x/gcc'
test -d testsuite/ada/acats || mkdir -p testsuite/ada/acats
testdir=`cd ../../gcc-4.3-20070907/gcc/testsuite/ada/acats; ${PWDCMD-pwd}`; \
export testdir; cd testsuite/ada/acats; /bin/sh ${testdir}/run_acats
=== acats config
--- Comment #4 from burnus at gcc dot gnu dot org 2007-09-11 15:53 ---
Subject: Bug 33040
Author: burnus
Date: Tue Sep 11 15:53:22 2007
New Revision: 128385
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128385
Log:
2007-09-11 Christopher D. Rickett <[EMAIL PROTECTED]>
--- Comment #7 from dominiq at lps dot ens dot fr 2007-09-11 15:54 ---
> this behaviour was prohibited
which behavior: folding huge(0)+1 as -huge(0)-1? or considering huge(0)+1 as
invalid (out of range) and doing an optimization based on the fact that any
valid integer is smaller and ne
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-09-11 15:48
---
(In reply to comment #5)
> Although there is no intrinsic involved in the test case, I don't see the
> logic
> to consider (abuse of) overflows valid for arithmetic operations and invalid
> for intrinsics.
I'd b
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-09-11 15:58
---
(In reply to comment #7)
>> this behaviour was prohibited
>
> considering huge(0)+1 as invalid (out of range)
The second one, in the context of a loop index. But the more I think about it,
the more dubious it see
--- Comment #1 from charlet at gcc dot gnu dot org 2007-09-11 16:09 ---
cxa* tests have already been handled by Eric in latest sources.
controlled2.adb was a missing commit, also fixed yesterday.
So the solution is simply to update your tree.
Arno
--
charlet at gcc dot gnu dot org
--- Comment #13 from eweddington at cso dot atmel dot com 2007-09-11 16:10
---
(In reply to comment #12)
> Andy Hutchinson wrote (comment #6) that addition a 'movdi' instruction
> improves
> the result. I have try to add a very simple 'movdi' (which split into 2 SImode
> instuctions).
With X86_TUNE_USE_VECTOR_CONVERTS enabled, I got
/export/build/gnu/gcc/build-i686-linux/./prev-gcc/xgcc
-B/export/build/gnu/gcc/build-i686-linux/./prev-gcc/
-B/usr/gcc-4.3/i686-pc-linux-gnu/bin/ -c -g -O2 -fomit-frame-pointer -DIN_GCC
-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prot
--- Comment #1 from hjl at lucon dot org 2007-09-11 16:35 ---
Apply this patch:
--- gcc/opts.c.small2007-09-09 12:56:26.0 -0700
+++ gcc/opts.c 2007-09-11 07:13:15.0 -0700
@@ -822,7 +822,9 @@ decode_options (unsigned int argc, const
if (optimize >= 2)
{
+#if
This is dependant on bug 32261.
g++ -g -O3 gccbug.cpp -pthread -o gccbug -s
#include
#include
void* thread_function(void*) {
for (int k = 0; k < 5; k++) {
std::string my_str;
my_str += "foo";
}
return 0;
}
int main()
{
pthread_t thread1, thread2;
pthre
Fetch FGSL (0.7) from
http://www.lrz-muenchen.de/services/software/mathematik/gsl/fortran/
Run ./configure --f90 gfortran && make
This should compile the library successfully.
Run now the following test case; result:
test.f90:39: internal compiler error: Segmentation fault
==2416== Invalid read
--- Comment #5 from burnus at gcc dot gnu dot org 2007-09-11 16:46 ---
Fixed by Chris (thanks!).
gfortran still does not fully work with FGSL :-(
See PR 33395.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
-
Add --enable-intermodule for the compilation of various parts of gcc.
--
Summary: add --enable-intermodule
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo:
--- Comment #1 from aldot at gcc dot gnu dot org 2007-09-11 16:47 ---
Created an attachment (id=14190)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14190&action=view)
libgcc patch#1
libgcc/ChangeLog:
2007-09-11 Bernhard Fischer <>
* configure.ac: Add option --enable-in
+++ This bug was initially created as a clone of Bug #33388 +++
There is a failure building libgcc with revision 128358 (with the first two
parts of bug 33388 fixed):
Configure flags:
--target fr30-unknown-elf --enable-checking=yes,rtl --with-newlib --enable-sim
--disable-gdb --disable-nls
/home
--- Comment #2 from aldot at gcc dot gnu dot org 2007-09-11 16:54 ---
With trunk r127829, this currently gives:
/scratch/obj.i686/gcc-4.3/./prev-gcc/libgcc.a(libgcc_onestep.o): In function
`isinfd128':
../../../../src/gcc-4.3/libgcc/config/libbid/_isinfd128.c:38: undefined
reference to
--- Comment #2 from debian-gcc at lists dot debian dot org 2007-09-11
17:11 ---
seen on arm-linux & m68k-linux as well
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32653
--- Comment #27 from jakub at gcc dot gnu dot org 2007-09-11 17:21 ---
Created an attachment (id=14191)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14191&action=view)
gcc43-pr33136.patch
Updated patch which tries to handle SFTs as well.
Unfortunately it causes a regression with
--- Comment #4 from andreast at gcc dot gnu dot org 2007-09-11 17:30
---
*** This bug has been marked as a duplicate of 33384 ***
--
andreast at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from andreast at gcc dot gnu dot org 2007-09-11 17:30
---
*** Bug 33390 has been marked as a duplicate of this bug. ***
--
andreast at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from andreast at gcc dot gnu dot org 2007-09-11 17:31
---
Fixed with this checkin.
http://gcc.gnu.org/ml/gcc-cvs/2007-09/msg00369.html
--
andreast at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from aldot at gcc dot gnu dot org 2007-09-11 17:58 ---
(In reply to comment #2)
> With trunk r127829, this currently gives:
>
> /scratch/obj.i686/gcc-4.3/./prev-gcc/libgcc.a(libgcc_onestep.o): In function
> `isinfd128':
> ../../../../src/gcc-4.3/libgcc/config/libbid/_isin
--- Comment #3 from pault at gcc dot gnu dot org 2007-09-11 18:37 ---
(In reply to comment #2)
> I want to add that you can find gfortran 4.3.0 binaries at
>http://gcc.gnu.org/wiki/GFortranBinaries
>
> I'm actually unsure which patch fixed it. It might be Paul's PR32298 even
> thoug
--- Comment #1 from burnus at gcc dot gnu dot org 2007-09-11 18:43 ---
Created an attachment (id=14192)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14192&action=view)
Test case
Reduced test case.
==3237== Invalid read of size 8
==3237==at 0x49F45A: gfc_conv_initializer (tra
--- Comment #2 from burnus at gcc dot gnu dot org 2007-09-11 18:45 ---
If I remove the default initializer in
type(c_ptr) :: gsl_vector = c_null_ptr
the crash is gone.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #27 from aldot at gcc dot gnu dot org 2007-09-11 18:58 ---
This also happens on SuSE-10.2, x86-64
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30915
1 - 100 of 142 matches
Mail list logo