--- Comment #3 from pault at gcc dot gnu dot org 2009-09-06 07:04 ---
(In reply to comment #2)
Why there is a dependence on the preceding statement, I have no idea. However,
expr_type is not being set to EXPR_PPC, as the following shows (causes lots of
failures by the way :-()
Index:
--- Comment #2 from ktietz at gcc dot gnu dot org 2009-09-06 08:52 ---
I tested a i686 mingw bootstrap for 4.4.x and it works for me.
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
$ gfortran --version
GNU Fortran (Ubuntu 4.3.3-5ubuntu4) 4.3.3
...
$ cat crash.f90
program crash_random_number
implicit none
integer, parameter :: dp = kind(1.0d0)
integer, parameter :: size = 1
real(kind=dp), dimension(size) :: x, y
! call random_seed() ! doesn't
--- Comment #6 from rwild at gcc dot gnu dot org 2009-09-06 09:28 ---
Thanks for the report, analysis, and patch. I'll look into this later today
(would like to know where I failed when testing my earlier patch, and whether
your patch doesn't do more than desired). For reference, was
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-06 09:40 ---
You use too much memory and your operating system kills your program for that.
Read on ulimit(8).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from paolo dot carlini at oracle dot com 2009-09-06 09:43
---
I reproduced it yesterday with a native, fresh, build, and make -j8 on a quad
core (I bet it happens also with -j1, I'll try it later today and I'll report
back in case of surprises).
--
--- Comment #25 from dominiq at lps dot ens dot fr 2009-09-06 09:56 ---
Dominique,
Also if you are bothering to run the test suite on i686-apple-darwin9
periodically, you might as well shoot the results over to the gcc-testresults
mailing list (since Apple has never set up a
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-09-06 10:13
---
Created an attachment (id=18516)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18516action=view)
patch
here it is
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41254
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-09-06 10:17 ---
Most of the eon regression was due to the SRA patch. Other changes weren't
affected by the SRA patch and so have to be attributed to VTA.
See http://gcc.opensuse.org/SPEC/CFP/sb-terbium-head-64/recent.html
and
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-09-06 12:38
---
We again have ANTIC_IN/OUT oscillation
ANTIC_OUT[] := { x_2 (0001), y_3 (0002), {pointer_plus_expr,x_2,4} (0011) }
ANTIC_IN[] := { x_2 (0001), y_3 (0002), {pointer_plus_expr,x_2,4} (0011) }
ANTIC_OUT[] := { x_2
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-09-06 12:41
---
This is what I am thinking of:
Index: gcc/tree-ssa-pre.c
===
--- gcc/tree-ssa-pre.c (revision 151458)
+++ gcc/tree-ssa-pre.c (working copy)
@@
--- Comment #13 from rguenth at gcc dot gnu dot org 2009-09-06 12:50
---
Equivalent to that would be to clean ANTIC_IN using the maximal set - that is,
do not allow expressions in ANTIC_IN that are not in the maximal set.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41101
--- Comment #13 from t7 at gmail dot com 2009-09-06 12:55 ---
(In reply to comment #12)
Created an attachment (id=18516)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18516action=view) [edit]
patch
here it is
Confirm fixed.
--
--- Comment #2 from sschwarzer at sschwarzer dot net 2009-09-06 13:22
---
Richard, thanks for the quick answer. :-)
I hadn't gotten the idea of the limits because I can, from the same shell,
allocate three lists with Python which have the same size (1e8) and contain
floating point
--- Comment #50 from vmakarov at redhat dot com 2009-09-06 13:46 ---
I tried several times to reproduce it without success. It is suspicious that
only gnat generated files are different. May be the bug is in gnat specific
files.
I found that gnat1 generated by a system compiler
gcc fails to inline a simple function if it is first declared non-inline.
There is no warning with -Winline.
$ gcc -S -O2 -Winline -fpic inline.c
$ grep fxstatat64 inline.s
$ gcc -S -O2 -Winline -fpic inline.c -DNO_DECL
$ grep fxstatat64 inline.s
bl __gi___fxstata...@local
--
--- Comment #14 from dberlin at gcc dot gnu dot org 2009-09-06 14:15
---
Subject: Re: [4.4/4.5 Regression] ICE in
compute_antic, at tree-ssa-pre.c:2419
On Sun, Sep 6, 2009 at 8:41 AM, rguenth at gcc dot gnu dot
orggcc-bugzi...@gcc.gnu.org wrote:
--- Comment #12 from
--- Comment #1 from schwab at linux-m68k dot org 2009-09-06 14:15 ---
Created an attachment (id=18517)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18517action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41284
--- Comment #15 from rguenther at suse dot de 2009-09-06 14:17 ---
Subject: Re: [4.4/4.5 Regression] ICE in
compute_antic, at tree-ssa-pre.c:2419
On Sun, 6 Sep 2009, dberlin at dberlin dot org wrote:
--- Comment #14 from dberlin at gcc dot gnu dot org 2009-09-06 14:15
--- Comment #16 from dberlin at gcc dot gnu dot org 2009-09-06 14:19
---
Subject: Re: [4.4/4.5 Regression] ICE in
compute_antic, at tree-ssa-pre.c:2419
On Sun, Sep 6, 2009 at 8:50 AM, rguenth at gcc dot gnu dot
orggcc-bugzi...@gcc.gnu.org wrote:
--- Comment #13 from
--- Comment #17 from rguenther at suse dot de 2009-09-06 14:20 ---
Subject: Re: [4.4/4.5 Regression] ICE in
compute_antic, at tree-ssa-pre.c:2419
On Sun, 6 Sep 2009, dberlin at dberlin dot org wrote:
--- Comment #16 from dberlin at gcc dot gnu dot org 2009-09-06 14:19
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-09-06 14:04 ---
The future canonical type with structual equality set is built from
#0 0x089afcf4 in build_array_type (elt_type=0xb7d75620, index_type=0xb7d734d0)
at /home/richard/src/trunk/gcc/tree.c:6906
#1 0x082ecaa7 in
--- Comment #6 from jb at gcc dot gnu dot org 2009-09-06 13:55 ---
(In reply to comment #2)
Janne, I think the warning about unix.c:750:15: warning: statbuf.st_mode
may
be used uninitialized is spurious, but can you have a look?
Yes, it's spurious, and I submitted a patch
--- Comment #14 from t7 at gmail dot com 2009-09-06 13:57 ---
(In reply to comment #12)
Created an attachment (id=18516)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18516action=view) [edit]
patch
here it is
For some reason this leads to :
Problem signature:
Problem
--- Comment #16 from rguenth at gcc dot gnu dot org 2009-09-06 14:07
---
Try building without the patch but with unlimited stack (ulimit -s unlimited)
and see if the same error appears.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41254
--- Comment #15 from t7 at gmail dot com 2009-09-06 13:59 ---
(gdb) print $pc
$1 = (void (*)()) 0x80e132 QString::at(int) const+26
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41254
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-09-06 14:46 ---
Well you are allocating an 1.5gb bss segment. There is no room for this
amount of contiguous memory on i?86.
You might want to use allocatable arrays instead.
Anyway, this is not a gcc bug.
--
rguenth at gcc
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-09-06 14:49 ---
Works for me on i?86. Maybe m86k is somehow oddly confused about the extra
restrict qualification in the prototype?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41284
--- Comment #3 from schwab at linux-m68k dot org 2009-09-06 14:55 ---
I don't know what m86k is, but this is obviously ppc assembler.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41284
--- Comment #27 from hjl dot tools at gmail dot com 2009-09-06 15:37
---
EH has been problematic on Darwin/x86, see PR 37012.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41260
--- Comment #2 from paolo at gcc dot gnu dot org 2009-09-06 15:41 ---
Subject: Bug 41267
Author: paolo
Date: Sun Sep 6 15:41:38 2009
New Revision: 151459
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151459
Log:
2009-09-06 Paolo Carlini paolo.carl...@oracle.com
PR
--- Comment #3 from paolo dot carlini at oracle dot com 2009-09-06 15:43
---
Fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #28 from howarth at nitro dot med dot uc dot edu 2009-09-06
16:01 ---
Hopefully we can still use Apple's gdb to debug these EH issues on darwin10. If
I am reading...
http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00074.html
correctly, the VTA merge may break the ability to
--- Comment #11 from schwab at linux-m68k dot org 2009-09-06 16:08 ---
*** Bug 41284 has been marked as a duplicate of this bug. ***
--
schwab at linux-m68k dot org changed:
What|Removed |Added
--- Comment #4 from schwab at linux-m68k dot org 2009-09-06 16:08 ---
*** This bug has been marked as a duplicate of 41271 ***
--
schwab at linux-m68k dot org changed:
What|Removed |Added
--- Comment #7 from domob at gcc dot gnu dot org 2009-09-06 16:16 ---
Thanks for fixing this, I guess this was my fault (without looking further)...
I was away over the weekend, but should be able to do some hacking again now ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41258
--- Comment #4 from kargl at gcc dot gnu dot org 2009-09-06 16:25 ---
! call random_seed() ! doesn't seem to change anything
It changes the seeds to the default settings. Please see
the manual that came with gfortran.
As to the other problem, follow Richard's advice and
use
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-09-06 16:49 ---
Subject: Bug 41261
Author: rguenth
Date: Sun Sep 6 16:48:41 2009
New Revision: 151460
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151460
Log:
2009-09-06 Richard Guenther rguent...@suse.de
PR
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-09-06 16:50 ---
Subject: Bug 41144
Author: rguenth
Date: Sun Sep 6 16:49:48 2009
New Revision: 151461
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151461
Log:
2009-09-06 Richard Guenther rguent...@suse.de
PR
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-09-06 16:50 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-09-06 16:50 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #17 from rguenth at gcc dot gnu dot org 2009-09-06 16:51
---
The patch bootstrapped and tested ok but I'm holding off until you confirm it's
not the reason for the issue you see.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41254
--- Comment #2 from tkoenig at gcc dot gnu dot org 2009-09-06 17:38 ---
I have a patch.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from rguenth at gcc dot gnu dot org 2009-09-06 17:41
---
Do you mean sth like the following? Simply assuming that the maximal-set is
all ones and obviously translating all ones also results in all ones.
Index: gcc/tree-ssa-pre.c
--- Comment #19 from rguenth at gcc dot gnu dot org 2009-09-06 17:48
---
Err... I wonder how this works at all ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41101
--- Comment #20 from rguenth at gcc dot gnu dot org 2009-09-06 17:53
---
Ah, we start from the exit block with ANTIC_IN {} and go to its predecessors
getting just EXP_GEN - TMP_GEN there. Not unsound.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41101
lto on powerpc does not work at all.
(system is openSUSE 11.1 / PowerPC 32bit. glibc 2.9)
$ cat xx.c
int main(int argc,char **argv) { return 1; }
$ /abuild/meissner/lto/BIN/bin/gcc -flto -O2 xx.c -o xx
lto1: fatal error: internal error: builtin function to __builtin_bswap16
already processed.
--- Comment #8 from rwild at gcc dot gnu dot org 2009-09-06 16:56 ---
Darn. An intermediate version of the r151352 patch was correct and I failed
to do the installation test properly on the final version of the patch.
Awfully sorry about the breakage.
Updated patch at
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-09-06 17:02 ---
*** Bug 41285 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-06 17:02 ---
*** This bug has been marked as a duplicate of 41173 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from ktietz at gcc dot gnu dot org 2009-09-06 18:07 ---
I think I found the issue within gfortran for mingw. The issue is that off_t is
for mingw defined as 'long' (like _off_t). There is a 64-bit off64_t, which
holds in fact 64-bits and can be used with the ftello64, and
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2009-09-06 18:17
---
Let me fix this.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #51 from ebotcazou at gcc dot gnu dot org 2009-09-06 18:20
---
I tried several times to reproduce it without success. It is suspicious
that
only gnat generated files are different. May be the bug is in gnat specific
files.
No, it's again CSA, I'm testing a patch
--- Comment #52 from jakub at gcc dot gnu dot org 2009-09-06 18:38 ---
Created an attachment (id=18518)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18518action=view)
gcc45-pr41241.patch
FYI, here is the updated patch that I've already bootstrapped on x86_64-linux
and i686-linux
--- Comment #7 from kargl at gcc dot gnu dot org 2009-09-06 18:45 ---
(In reply to comment #6)
I think I found the issue within gfortran for mingw.
I think you have this backwards. the issue within mingw
for gfortran would be a better description of the issue.
It is afterall mingw
--- Comment #8 from ktietz at gcc dot gnu dot org 2009-09-06 18:52 ---
(In reply to comment #7)
(In reply to comment #6)
I think I found the issue within gfortran for mingw.
I think you have this backwards. the issue within mingw
for gfortran would be a better description of the
--- Comment #53 from ebotcazou at gcc dot gnu dot org 2009-09-06 19:08
---
FYI, here is the updated patch that I've already bootstrapped on x86_64-linux
and i686-linux and am regtesting ATM.
This is fine, thanks (missing records after This structure).
--
--- Comment #9 from kargl at gcc dot gnu dot org 2009-09-06 19:09 ---
(In reply to comment #8)
(In reply to comment #7)
(In reply to comment #6)
I think I found the issue within gfortran for mingw.
I think you have this backwards. the issue within mingw
for gfortran would
--- Comment #4 from oliver dot kellogg at eads dot com 2009-09-06 19:21
---
I don't know what fixed it but it doesn't happen with trunk 20090819 and newer.
--
oliver dot kellogg at eads dot com changed:
What|Removed |Added
--- Comment #54 from jakub at gcc dot gnu dot org 2009-09-06 19:32 ---
Subject: Bug 41241
Author: jakub
Date: Sun Sep 6 19:31:55 2009
New Revision: 151462
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151462
Log:
PR bootstrap/41241
* combine-stack-adj.c (struct
--- Comment #10 from ktietz at gcc dot gnu dot org 2009-09-06 20:05 ---
(In reply to comment #9)
(In reply to comment #8)
(In reply to comment #7)
(In reply to comment #6)
I think I found the issue within gfortran for mingw.
I think you have this backwards. the issue
--- Comment #55 from ebotcazou at gcc dot gnu dot org 2009-09-06 21:16
---
Subject: Bug 41241
Author: ebotcazou
Date: Sun Sep 6 21:15:45 2009
New Revision: 151463
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151463
Log:
PR bootstrap/41241
* combine-stack-adj.c
--- Comment #56 from ebotcazou at gcc dot gnu dot org 2009-09-06 21:17
---
This should be fixed everywhere.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2009-09-06 21:21
---
The following patch gets rid of the two warnings in list_read.c. The two
enumerators have equivalent value. Regression tests fine.
@@ -2377,7 +2377,7 @@
/* GFC_TYPE_UNKNOWN through for nulls and is
--- Comment #18 from t7 at gmail dot com 2009-09-06 21:59 ---
(In reply to comment #17)
The patch bootstrapped and tested ok but I'm holding off until you confirm
it's
not the reason for the issue you see.
I can confirm, that indeed patch fixed this bug.
Yes patch bootstrapped
--- Comment #19 from rguenther at suse dot de 2009-09-06 22:02 ---
Subject: Re: [4.5 Regression] crashed compile Qt4 gui
library
On Sun, 6 Sep 2009, t7 at gmail dot com wrote:
--- Comment #18 from t7 at gmail dot com 2009-09-06 21:59 ---
(In reply to comment #17)
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41245
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41224
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41214
--- Comment #20 from t7 at gmail dot com 2009-09-06 22:14 ---
(In reply to comment #16)
Try building without the patch but with unlimited stack (ulimit -s unlimited)
and see if the same error appears.
Actually can't try this because I'm using the native compiler to build
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41204
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40977
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40106
--- Comment #21 from rguenth at gcc dot gnu dot org 2009-09-06 22:19
---
Yes, that could be the reason. Can you test the same revision without the
patch again?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41254
--- Comment #22 from t7 at gmail dot com 2009-09-06 22:20 ---
(In reply to comment #16)
Try building without the patch but with unlimited stack (ulimit -s unlimited)
and see if the same error appears.
You mean cross compile the native compiler from linux by setting the shell
--- Comment #23 from t7 at gmail dot com 2009-09-06 22:21 ---
(In reply to comment #16)
Try building without the patch but with unlimited stack (ulimit -s unlimited)
and see if the same error appears.
This is under MSys/Mingw shell
$ ulimit -s unlimited
sh: ulimit: stack size:
--- Comment #24 from rguenther at suse dot de 2009-09-06 22:22 ---
Subject: Re: [4.5 Regression] crashed compile Qt4 gui
library
On Sun, 6 Sep 2009, t7 at gmail dot com wrote:
--- Comment #22 from t7 at gmail dot com 2009-09-06 22:20 ---
(In reply to comment
--- Comment #25 from t7 at gmail dot com 2009-09-06 22:27 ---
(In reply to comment #21)
Yes, that could be the reason. Can you test the same revision without the
patch again?
Ok there maybe a reason for qmake.exe crash, during the process, I changed the
O flag for building the
--- Comment #26 from t7 at gmail dot com 2009-09-06 22:30 ---
(In reply to comment #24)
Just the same way as you reported the bug (I understand that this
was a native compiler issue?). There surely must be a way to increase
the maximum stack size with windows?
Yes this was
--- Comment #27 from t7 at gmail dot com 2009-09-06 22:41 ---
Ok I just found out that it is the -O and up causing the problem, I just
changed script back to -O0 and it compiles and runs fine, right now up to
corelib.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41254
--- Comment #28 from t7 at gmail dot com 2009-09-06 22:43 ---
Thank you for the help, this bug can be close.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41254
--- Comment #29 from t7 at gmail dot com 2009-09-06 22:55 ---
Confirmed that qt4 library build was complete with -O0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41254
--- Comment #29 from rguenth at gcc dot gnu dot org 2009-09-06 22:59
---
Fixed as of comment #25.
For the remaining see PR41237.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-09-06 22:59 ---
Fixed. Please re-open if not.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-09-06 23:00 ---
Please check again.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
In the attached standalone test case (depends only on ::memcpy in string.h),
the test fails when compiled with -O1 but succeeds with all other optimisations
(-O0, -O2, -O3).
Files attached:
testOpt.cpp - standalone test with compilation information included in the
file.
testOpt.ii
Below is the
--- Comment #1 from mhenson at clarityvi dot com 2009-09-07 00:56 ---
Created an attachment (id=18519)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18519action=view)
standalone test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41287
--- Comment #2 from mhenson at clarityvi dot com 2009-09-07 00:56 ---
Created an attachment (id=18520)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18520action=view)
intermediate files
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41287
--- Comment #10 from ghazi at gcc dot gnu dot org 2009-09-07 00:59 ---
(In reply to comment #9)
See this note for some details on the semantics of this warning,
with respect to keywords:
http://gcc.gnu.org/ml/gcc-patches/2008-07/msg00808.html
What's the status of this PR? Are there
--- Comment #27 from ghazi at gcc dot gnu dot org 2009-09-07 01:04 ---
(In reply to comment #25)
Subject: Bug 34999
Author: jakub
Date: Fri Jul 24 23:30:39 2009
New Revision: 150069
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150069
Log:
PR rtl-optimization/34999
On both x86_64-apple-darwin* and i686-apple-darwin* using -m64, the
gcc.target/x86_64/abi/test_struct_returning.c test cases...
FAIL: gcc.target/x86_64/abi/test_struct_returning.c execution, -O3
-fomit-frame-pointer
FAIL: gcc.target/x86_64/abi/test_struct_returning.c execution, -O3
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2009-09-07
01:24 ---
The output from 20090425 shows...
Executing on host:
/sw/src/fink.build/gcc45-4.4.999-20090425/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc45-4.4.999-20090425/darwin_objdir/gcc/
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2009-09-07
01:33 ---
Ignore the comments on the warnings. This was a glitch from running...
make -k check-gcc
RUNTESTFLAGS=abi-x86_64.exp=gcc.target/x86_64/abi/test_struct_returning.c
in darwin_objdir which seems to cause
libavformat/oggparseogm.c: In function 'ogm_header':
libavformat/oggparseogm.c:34:1: error: expected an SSA_NAME object
libavformat/oggparseogm.c:34:1: error: in statement
# DEBUG default_len = ((const struct unaligned_32 *) p + -4)-l
libavformat/oggparseogm.c:34:1: internal compiler error:
--- Comment #1 from t7 at gmail dot com 2009-09-07 02:39 ---
Created an attachment (id=18521)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18521action=view)
tmp .saves
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41289
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2009-09-07 02:57
---
Regarding comment #6.
In write_a_char4, one has:
const char crlf[] = \r\n;
write_default_char4 (dtp, crlf, 2, 0);
but the second argument should be gfc_char4_t*
Right. So what is \r\n
--- Comment #2 from t7 at gmail dot com 2009-09-07 03:04 ---
Created an attachment (id=18522)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18522action=view)
saves
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41289
Hi,
I found problematic file in libdirac package which don't want to compile with
GCC 4.5.0 (20090827), but compiles fine with GCC 4.4.2 (20090825).
The problematic file is libdirac_common/common.cpp. I include preprocessed
file.
$ make_68k_v45
Making all in libdirac_byteio
make[1]: Entering
--- Comment #1 from ami_stuff at o2 dot pl 2009-09-07 04:01 ---
Created an attachment (id=18523)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18523action=view)
preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41290
1 - 100 of 103 matches
Mail list logo
