--- Comment #4 from jakub at gcc dot gnu dot org 2009-05-05 06:47 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from jakub at gcc dot gnu dot org 2009-05-05 06:41 ---
Subject: Bug 40013
Author: jakub
Date: Tue May 5 06:41:33 2009
New Revision: 147120
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147120
Log:
PR c++/40013
* pt.c (tsubst): If magic NOP_EXPR w
--- Comment #1 from happyarch at gmail dot com 2009-05-05 06:40 ---
Created an attachment (id=17801)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17801&action=view)
.i file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40023
fix=/usr --libexecdir=/usr/lib
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --enable-languages=c,c++ --disable-bootstrap
--disable-multilib
Thread model: posix
gcc version 4.5.0 20090504 (experimental) (GCC)
--
Summary: type mismatch in address expre
--- Comment #2 from jakub at gcc dot gnu dot org 2009-05-05 06:37 ---
Subject: Bug 40013
Author: jakub
Date: Tue May 5 06:37:05 2009
New Revision: 147119
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147119
Log:
PR c++/40013
* pt.c (tsubst): If magic NOP_EXPR w
--- Comment #8 from jv244 at cam dot ac dot uk 2009-05-05 04:18 ---
(In reply to comment #6)
> opt/gcc/gcc-4.5-work/gcc/testsuite/gfortran.dg/import6.f90:42.13:
>
> call func1(x)
> 1
> Error: Type mismatch in argument 'param' at (1); passed TYPE(my_type) to
> TYPE(my_typ
--- Comment #5 from hjl dot tools at gmail dot com 2009-05-05 00:45 ---
Created an attachment (id=17800)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17800&action=view)
A testcase
[...@gnu-33 pr40021]$ make
/export/gnu/import/rrs/146817/usr/bin/gfortran -m32 -c -O2 -ftree-vectori
--- Comment #5 from joshuadfranklin at yahoo dot com 2009-05-05 00:01
---
(In reply to comment #3)
> That is the assembler that is produced not the preprocessed source, use
> -save-temps and attach the .ii file.
Sorry. Does this one look right? It's actually .c I typo'd the .cc.
--
--- Comment #4 from joshuadfranklin at yahoo dot com 2009-05-05 00:00
---
Created an attachment (id=17799)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17799&action=view)
alpine pith/reply.c compiled with save-temps
'
My compile line:
gcc -c -save-temps -std=gnu99 -DHAVE_CONFI
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-05-04 23:55 ---
That is the assembler that is produced not the preprocessed source, use
-save-temps and attach the .ii file.
Thanks,
Andrew Pinski
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--
joshuadfranklin at yahoo dot com changed:
What|Removed |Added
CC||joshuadfranklin at yahoo dot
|
--- Comment #2 from joshuadfranklin at yahoo dot com 2009-05-04 23:36
---
Created an attachment (id=17798)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17798&action=view)
alpine pith/reply.c compiled with O0 and save-temps
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40022
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-04 23:16 ---
Hmm, so -fwrapv and -fno-strict-aliasing fixes the problem which case it might
be a bug in the source.
Can you provide the preprocessed source of pith/reply.cc?
--
pinskia at gcc dot gnu dot org changed:
--- Comment #4 from hjl dot tools at gmail dot com 2009-05-04 23:09 ---
The vectorizer seems broken:
/export/gnu/import/rrs/146817/usr/bin/gfortran -m32 -c -O2 -ftree-vectorize
-msse2 -mfpmath=sse -ffast-math -ffixed-form test.f
/export/gnu/import/rrs/146817/usr/bin/gfortran -m32 -c -O
Hello, I have to admit I'm clueless about how to debug this.
On Fedora 11 preview release with gcc-4.4.0 alpine "reply to all"
does not include the list of cc'd addresses. Linus found that if
you compile the pith/reply.cc without optimizations it works
properly (see Fedora bug report at
http://b
--- Comment #3 from hjl dot tools at gmail dot com 2009-05-04 23:07 ---
Created an attachment (id=17797)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17797&action=view)
A testcase
[...@gnu-33 pr40021]$ make
/export/gnu/import/rrs/146817/usr/bin/gfortran -m32 -c -O3 -msse2 -mfpmat
--- Comment #7 from dominiq at lps dot ens dot fr 2009-05-04 22:44 ---
Also gfortran.dg/contained_3.f90 is miscompiled with -fwhole-file.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
--- Comment #3 from bkoz at gcc dot gnu dot org 2009-05-04 22:33 ---
No feedback.
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #6 from dominiq at lps dot ens dot fr 2009-05-04 22:20 ---
Regtest gives:
=== gfortran Summary ===
# of expected passes117714
# of unexpected failures576
# of expected failures 78
# of unsupported tests 906
for RUNTESTF
--- Comment #1 from kargl at gcc dot gnu dot org 2009-05-04 22:17 ---
(In reply to comment #0)
> I tried to migrate well running program from g77 to gfortran.
> I found a problem with new gfortan:
> >>Fortran runtime error: Bad value during floating point read<<
> to read REAL from file.
--- Comment #2 from hjl dot tools at gmail dot com 2009-05-04 21:53 ---
*** Bug 39973 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40021
--- Comment #4 from hjl dot tools at gmail dot com 2009-05-04 21:53 ---
*** This bug has been marked as a duplicate of 40021 ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
--- Comment #5 from hjl dot tools at gmail dot com 2009-05-04 21:52 ---
*** This bug has been marked as a duplicate of 40021 ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
--- Comment #1 from hjl dot tools at gmail dot com 2009-05-04 21:52 ---
*** Bug 39972 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40021
--- Comment #5 from dominiq at lps dot ens dot fr 2009-05-04 21:52 ---
With the patch in http://gcc.gnu.org/ml/fortran/2009-05/msg00056.html
gas_dyn.f90 fails as in commet #0, except for -O1:
[ibook-dhum] lin/test% gfc -O1 -fwhole-file gas_dyn.f90
gas_dyn.f90: In function 'chozdt':
gas_
On Linux/ia32, revision 146817 miscompiled DAXPY in BLAS with
-m32 O3 -msse2 -mfpmath=sse -ffast-math -fno-inline-functions -funroll-loops
-ffixed-form
--
Summary: [4.5 Regression] Revision 146817 miscompiled DAXPY in
BLAS
Product: gcc
Versi
I tried to migrate well running program from g77 to gfortran.
I found a problem with new gfortan:
>>Fortran runtime error: Bad value during floating point read<<
to read REAL from file.
>> read(nin,'(6e11.0)') a
and numbers were:
>> 7.73118- 3 4.26617+ 0 8.17285- 3 ...
It helps to add number '0' to
--- Comment #3 from janis at gcc dot gnu dot org 2009-05-04 21:24 ---
On x86_64 with a 64-bit compiler, positive decimal float constants are OK,
negative decimal float constants are wrong for both -m64 (the default) and
-m32.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39986
--- Comment #4 from hjl dot tools at gmail dot com 2009-05-04 20:52 ---
blas.f90 was miscompiled by
-m32 -O3 -msse2 -mfpmath=sse -ffast-math -fno-inline-functions -funroll-loops
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39972
--- Comment #3 from hjl dot tools at gmail dot com 2009-05-04 20:44 ---
blas.fppized.f was miscompiled by
-m32 -c -O3 -msse2 -mfpmath=sse -ffast-math -fno-inline-functions
-funroll-loops -ffixed-form
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39973
--- Comment #13 from mikael at gcc dot gnu dot org 2009-05-04 20:27 ---
(In reply to comment #12)
> don't know how to use it to compile gcc being a normal user (no root
> privileges) without scrambling everything else. Any help on this direction?
> Thanks
>
export LD_LIBRARY_PATH=/your/
--- Comment #10 from mikael at gcc dot gnu dot org 2009-05-04 20:24 ---
cf PR36462
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39772
--- Comment #5 from janis at gcc dot gnu dot org 2009-05-04 19:55 ---
This was fixed in trunk, expected to become GCC 4.5.0, on 2009-04-01 as
revision 145422. The ChangeLog entries have the correct PR number but the svn
log messages use 29027, which is why the checkins were not recorded
--- Comment #10 from janis at gcc dot gnu dot org 2009-05-04 19:50 ---
Fixed for trunk, expected to become GCC 4.5.0.
--
janis at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2009-05-04 19:37
---
About POPCNT and POPPAR, beware! Implementations are much harder than simply
using the GCC __builtin_popcount{,l,ll}: see PR40019 for similar issue with
LEADZ and TRAILZ.
--
http://gcc.gnu.org/bugzilla/show_b
LEADZ and TRAILZ can give wrong results for kinds other than 4 and 8. For
example, the following code:
integer(kind=1) :: i1
integer(kind=2) :: i2
integer(kind=4) :: i4
integer(kind=8) :: i8
integer(kind=16) :: i16
i1 = -1
i2 = -1
i4 = -1
i8 = -1
i16 = -1
print *, leadz(i1),
--- Comment #1 from dominiq at lps dot ens dot fr 2009-05-04 19:19 ---
Confirmed on trunk and 4.4.0. Works with 4.3.3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40018
$ cat a.f90
integer(kind=8) :: i
write(*,*) [(i, i = 1, 10)]
end
$ gfortran a.f90
a.f90:2: internal compiler error: in output_constructor, at varasm.c:4712
The GDB backtrace is:
#0 fancy_abort (file=0xd7999a "../../trunk/gcc/varasm.c", line=4716,
function=0xd792d0 "output_constructo
--- Comment #8 from dfranke at gcc dot gnu dot org 2009-05-04 18:08 ---
Paul, your patch fixes all issues I came across when compiling my largish set
of fortran sources with -fwhole-file. So, now I "just" need to sort out all the
warnings that came up *cough* ;)
Many thanks!
--
dfra
--- Comment #4 from dominiq at lps dot ens dot fr 2009-05-04 17:54 ---
With thee patch in http://gcc.gnu.org/ml/fortran/2009-05/msg00056.html without
type cheating, all the ICEs in my tests are gone. It even fixes pr37744!-(it
may give a clue on how to fix it without -fwhole-file).
For
--- Comment #10 from matz at gcc dot gnu dot org 2009-05-04 16:10 ---
Yes, I can now, thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976
--- Comment #9 from luisgpm at linux dot vnet dot ibm dot com 2009-05-04
15:50 ---
Follows the configure options, although i think you'll be able to reproduce it
with the flags i've mentioned.
/gcc/HEAD/configure --target=powerpc64-linux --host=powerpc64-linux
--build=powerpc64-linux -
--- Comment #8 from luisgpm at linux dot vnet dot ibm dot com 2009-05-04
15:41 ---
Oops... forgot about that bit, sorry.
Compile flags: -m32 -O3 -mcpu=power[4|5|6] -ffast-math -ftree-loop-linear
-funroll-loops -fpeel-loops
This reproduces on both 32-bit and 64-bit.
Luis
--
http:
--- Comment #7 from danglin at gcc dot gnu dot org 2009-05-04 15:35 ---
The patch from comment #4 was installed here:
http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00018.html
>From my perspective, this fixes the 4.5 regression reported here.
Possibly the change should be back ported to fix P
--- Comment #3 from guerby at gcc dot gnu dot org 2009-05-04 15:32 ---
Subject: Bug 38874
Author: guerby
Date: Mon May 4 15:32:00 2009
New Revision: 147102
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147102
Log:
2009-05-04 Laurent GUERBY
PR ada/38874
* m
--- Comment #14 from pinskia at gcc dot gnu dot org 2009-05-04 15:00
---
Yes slightly, it is trying to warn about something which is unitialized. This
works for me on i686-linux-gnu. Can you provide the preprocessed source?
--
pinskia at gcc dot gnu dot org changed:
Wh
--- Comment #3 from jakub at gcc dot gnu dot org 2009-05-04 14:52 ---
Not surprisingly when the error is during preprocessing.
regex.h parted ships (why?) is broken by the #elif changes, there is:
#if some_condition_that_is_true_on_sane_targets
...
#elif BITSET_WORD_MAX == (0x +
--- Comment #15 from dennis dot wassel at googlemail dot com 2009-05-04
15:09 ---
Created an attachment (id=17796)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17796&action=view)
Preprocessed source
Sure!
Attaching preprocessed source of gcc-4.4.0/gcc/config/soft-fp/divtf3.c
-
--- Comment #21 from laurent at guerby dot net 2009-05-04 14:50 ---
No objection in one week, so closing as WORKSFORME with binutils from CVS >=
20090423
--
laurent at guerby dot net changed:
What|Removed |Added
--- Comment #1 from happyarch at gmail dot com 2009-05-04 13:59 ---
Created an attachment (id=17795)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17795&action=view)
.i file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40016
--- Comment #12 from dennis dot wassel at googlemail dot com 2009-05-04
14:43 ---
(In reply to comment #10)
> It obviously works for me, you system seems to be messed up / special.
Seems so, although it is a Debian 4 with an unknown amount of modifications by
our admin.
One symptom of
--- Comment #13 from dennis dot wassel at googlemail dot com 2009-05-04
14:55 ---
I just noticed/remembered that [x]gcc only drives the compilers, so I plugged
cc1 into gdb and here is the (somewhat messy, slightly edited) result:
gdb /localdata/install/gcc/gcc-4.4.0-build/./gcc/cc1
--- Comment #6 from luisgpm at linux dot vnet dot ibm dot com 2009-05-04
13:50 ---
Just for the sake of information, -fselective-scheduling doesn't help.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #3 from jakub at gcc dot gnu dot org 2009-05-04 14:39 ---
_Bool would need to be a conditional macro too though, I wonder if some ISO C99
pedantry can't test that _Bool isn't defined or something like that.
But then for C++ it is similar with defined(bool) also being true wit
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-05-04 14:32 ---
Yes that seems like the right idea; the altivec specs was written before C99
was out.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from jakub at gcc dot gnu dot org 2009-05-04 14:30 ---
I'd say handling _Bool the same way as bool after vector would be a good idea.
It has a disadvantage that in addition to the (I'd say desirable):
#include
#include
...
vector bool int i;
also
vector _Bool int i;
woul
--- Comment #7 from matz at gcc dot gnu dot org 2009-05-04 14:37 ---
Compile options please. I can't reproduce it with a powerpc64 compiler
with -O2, neither with -m32 nor -m64, -ffast-math or no -ffast-math.
Also 'gcc -v' can't hurt to make sure our compilers are configured the same.
--- Comment #11 from dennis dot wassel at googlemail dot com 2009-05-04
14:35 ---
(In reply to comment #9)
> Do not set CFLAGS in
>
> make CFLAGS='-O2' LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2
> -fno-implicit-templates' profiledbootstrap
This ^ was only in my first iteration, and I've o
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-05-04 14:29
---
It obviously works for me, you system seems to be messed up / special.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-05-04 14:28 ---
Do not set CFLAGS in
make CFLAGS='-O2' LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2
-fno-implicit-templates' profiledbootstrap
or specify your host compiler version.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39
#include
#include
vector bool int b;
int
main (void)
{
return 0;
}
used to compile up to 4.3, doesn't any longer. I wonder what can be done here
though, for C++ with the conditional macros bool keywords can coexist well with
the context sensitive keywords, but unfortunately #define bool _Bo
--- Comment #8 from dennis dot wassel at googlemail dot com 2009-05-04
14:18 ---
Marked as 4.3/4.4 regression.
What should I try next? Need I provide any additional info? Any help is much
appreciated!
--
dennis dot wassel at googlemail dot com changed:
What|Removed
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-04 14:23 ---
Works for me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40016
Hi, when i compiling gnu parted 1.8.8 with gcc 4.5.0, got error
include regex.i
TIA
=
/bin/sh ../libtool --tag=CC --mode=compile gcc -std=gnu99 -I. -Os
-Werror -MT regex.lo -MD -MP -MF .deps/regex.Tpo -c -o regex.lo re
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2009-05-04
13:48 ---
Subject: Re: [4.5 Regression] SEGV compiling libiberty/regex.c in stage2
> Which pass? p *pass in frame 20 should tell you.
(gdb) p *pass
$1 = {type = GIMPLE_PASS, name = 0x27bb734 "forwprop",
gate = 0x
--- Comment #10 from manu at gcc dot gnu dot org 2009-05-04 12:49 ---
FIXED in GCC 4.5
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #9 from manu at gcc dot gnu dot org 2009-05-04 12:48 ---
Subject: Bug 28152
Author: manu
Date: Mon May 4 12:47:53 2009
New Revision: 147097
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147097
Log:
2009-05-04 Manuel Lopez-Ibanez
PR c++/28152
cp/
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-05-04 12:43 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #15 from dominiq at lps dot ens dot fr 2009-05-04 11:45 ---
This pr is fixed as long as *-apple-darwin9 is concerned. Due to comments #11
to
#13, I don't close it as fixed. If someone wants to keep this PR open, (s)he
should change subject, platform, and priority.
--
htt
--- Comment #6 from dominiq at lps dot ens dot fr 2009-05-04 11:42 ---
This pr is fixed as long as *-apple-darwin9 is concerned. Due to comments #3 to
#5, I don't close it as fixed. If someone wants to keep this PR open, (s)he
should change subject and priority.
--
http://gcc.gnu.or
--- Comment #1 from jakub at gcc dot gnu dot org 2009-05-04 11:26 ---
http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00116.html
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-05-04 11:02 ---
Subject: Bug 40015
Author: rguenth
Date: Mon May 4 11:01:59 2009
New Revision: 147094
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147094
Log:
2009-05-04 Richard Guenther
PR middle-end/40015
--- Comment #7 from pault at gcc dot gnu dot org 2009-05-04 10:32 ---
I guess that I should take it :-)
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pault at gcc dot gnu dot org 2009-05-04 10:31 ---
> For some reason that I do not see right now, cs_base in resolve.c is not being
> pushed or popped correctly.
Ah yes! resolve_codes nulls out cs_base. The problem is fixed by storing
cs_base before calling gfc_res
--- Comment #5 from pault at gcc dot gnu dot org 2009-05-04 10:19 ---
(In reply to comment #2)
> It may be worth noting that there are no warnings in the application about
> labels not being in the same block as the corresponding GOTO if compiled
> without -fwhole-file, but if compiled w
--- Comment #8 from carrot at google dot com 2009-05-04 10:08 ---
Sorry for my ignorance to gcc. What types of instructions reload will add?
Spilling and loading registers? and more?
By reading the the implementation of thumb_far_jump_used_p() I can get the
conclusion that if reload thi
--- Comment #7 from rearnsha at gcc dot gnu dot org 2009-05-04 09:41
---
(In reply to comment #6)
> We can compute the maximum possible function length first. If the length is
> not
> large enough far jump is not necessary, and we can do this optimization
> safely.
>
No, it's not th
--- Comment #3 from pault at gcc dot gnu dot org 2009-05-04 09:31 ---
...and PR39896 : "ICE with -fwhole-file"
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pault at gcc dot gnu dot org 2009-05-04 09:29 ---
see PR40006: allow type cheating for procedures with an implicit interface""
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-05-04 09:25 ---
I have a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|
--- Comment #1 from pault at gcc dot gnu dot org 2009-05-04 09:10 ---
Dominique,
Thanks for setting this up. I'll poll everybody involved for contributions and
have assigned myself the bug(s).
Cheers
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to work||4.3.3
Summary|[4.4 regression] ICE when |[4.4 Regression
--- Comment #4 from dominiq at lps dot ens dot fr 2009-05-04 09:06 ---
Also ICE on trunk r147065 powerpc-apple-darwin9 or r147085 i686-apple-darwin9.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37744
--- Comment #5 from rguenther at suse dot de 2009-05-04 09:01 ---
Subject: Re: [4.5.0 Regression] Revision 147083 failed
gfortran.dg/array_memcpy_4.f90
On Mon, 4 May 2009, dominiq at lps dot ens dot fr wrote:
> --- Comment #4 from dominiq at lps dot ens dot fr 2009-05-04 08:59
--- Comment #4 from dominiq at lps dot ens dot fr 2009-05-04 08:59 ---
This test has been introduced by the patch in
http://gcc.gnu.org/ml/fortran/2007-01/msg00425.html.
The tests gfortran.dg/array_memcpy_[1-3].f90 use
! { dg-final { scan-tree-dump-times "memcpy" * "original" } }
So a
--- Comment #3 from dennis dot wassel at googlemail dot com 2009-05-04
08:55 ---
Also fails with 4.3.3:
gfortran -v pr37744.f90
Driving: gfortran -v pr37744.f90 -lgfortranbegin -lgfortran -lm -shared-libgcc
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.3.3/c
--- Comment #10 from dennis dot wassel at googlemail dot com 2009-05-04
08:50 ---
Edited the "Known to fail" instead of "Reported against".
--
dennis dot wassel at googlemail dot com changed:
What|Removed |Added
---
--- Comment #9 from dennis dot wassel at googlemail dot com 2009-05-04
08:45 ---
Also fails with 4.3.3 (precisely the same error message as 4.3.2)
gfortran -O2 -ftree-parallelize-loops=2 -c ma57.f -o ma57.o
ma57.f: In function 'ma57od':
ma57.f:2724: error: edge from 676 to 686 should b
--- Comment #11 from jv244 at cam dot ac dot uk 2009-05-04 07:49 ---
I have a gdb session open, but I'm rather clueless. I have this:
(gdb) print (*x).generic.type
$5 = {common = {base = {code = RECORD_TYPE, side_effects_flag = 0,
constant_flag = 0, addressable_flag = 0, volatile_flag =
--- Comment #10 from jv244 at cam dot ac dot uk 2009-05-04 07:12 ---
This is the outermost stack trace to the segfault (with default 8M stack),
shows the depth of the recursion, and the location:
#174699 0x00528487 in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:33
--- Comment #1 from burnus at gcc dot gnu dot org 2009-05-04 07:11 ---
Wrong comp.lang.fortran link; the correct one is:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/b3a7e94ddf6b8ff3
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39997
92 matches
Mail list logo
