--- Comment #4 from jakub at gcc dot gnu dot org 2008-09-01 07:17 ---
Created an attachment (id=16177)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16177&action=view)
gcc43-pr37248.patch
Patch I've bootstrapped/regtested on 4 linux arches on 4.3 branch.
--
http://gcc.gnu.org
--- Comment #14 from sfilippone at uniroma2 dot it 2008-09-01 08:13 ---
(In reply to comment #11)
> My point is this:
> As you said in your first comment, there is no ambiguity in your code.
> vector is defined in only one module which is used when needed in other
> modules.
> Moreover
--- Comment #4 from jwakely dot gcc at gmail dot com 2008-09-01 08:39
---
Yes, I realise that, but it's still documented and it was apparently harmless
with 4.2.2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37277
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37307
--- Comment #5 from dominiq at lps dot ens dot fr 2008-09-01 09:37 ---
On i686-apple-darwin9, I have the following failures in both 32 and 64 bit
modes:
FAIL: gfortran.dg/debug/pr35154-dwarf2.f -gdwarf-2 scan-assembler DW_AT_name:
"__BLNK__"
FAIL: gfortran.dg/debug/pr35154-dwarf2.f -gdw
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-09-01 09:50 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-09-01 09:50 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #1 from paolo dot carlini at oracle dot com 2008-09-01 09:53
---
Do you mean *hangs* during bootstrap?? Sorry, but it's not at all clear what is
happening exactly on your side.
David, can you follow a bit this... ?
--
paolo dot carlini at oracle dot com changed:
--- Comment #2 from cnstar9988 at gmail dot com 2008-09-01 10:15 ---
(In reply to comment #1)
> Do you mean *hangs* during bootstrap?? Sorry, but it's not at all clear what
> is
> happening exactly on your side.
> David, can you follow a bit this... ?
the bootrap stop at ./conftest for
My system response to the gcc -v is
[EMAIL PROTECTED] ~]$ gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --ena
--- Comment #3 from cnstar9988 at gmail dot com 2008-09-01 10:23 ---
$ oslevel -r
5100-09
with all latest AIX 5.1 patch.
=
I can compile gcc 4.2.4, works ok, and used for bootstrap gcc.
gcc 4.2.4 can't support TLS "__thread", "test.c:1: error: thread-loca
--- Comment #4 from paolo dot carlini at oracle dot com 2008-09-01 10:25
---
Note that the TLS check code is used in libstdc++-v3, but it's actually part of
the general GCC config infrastructure: tls.m4. It's also used in libjava, for
example.
--
paolo dot carlini at oracle dot com
--- Comment #15 from pault at gcc dot gnu dot org 2008-09-01 10:27 ---
Since I am homing in on a solution, I might as well take it on.
Cheers
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from pault at gcc dot gnu dot org 2008-09-01 10:28 ---
(In reply to comment #2)
> Paul, do you have an idea? You are our module/interface specialist.
>
I have started to take a look at it.
Cheers
Paul
--
pault at gcc dot gnu dot org changed:
What|Re
All,
From the backtrace I very doubt this is a IRA issue.
I looks to be related to the recent IPA/CGRAPG changes
so it's one for Honza to look at
Cheers
Graham
--- Comment #10 from graham dot stott at btinternet dot com 2008-09-01
10:30 ---
Subject: Re: Bootstrap failure due to __muldi3
All,
>From the backtrace I very doubt this is a IRA issue.
I looks to be related to the recent IPA/CGRAPG changes
so it's one for Honza to look at
Cheers
--- Comment #5 from cnstar9988 at gmail dot com 2008-09-01 10:34 ---
gcc 4.2.4 doesn't support tls on AIX 5.1.
Does gcc 4.3.2 support tls on AIX 5.1? Maybe stage3 gcc can compile "__thread",
but can't run well?
why I configure with --disable-tls, gcc 4.3.2 always use and check tls?
IBM
Sent from my iPhone
On Sep 1, 2008, at 3:25, "paolo dot carlini at oracle dot com" <[EMAIL PROTECTED]
> wrote:
--- Comment #4 from paolo dot carlini at oracle dot com
2008-09-01 10:25 ---
Note that the TLS check code is used in libstdc++-v3, but it's
actually part of
the gene
--- Comment #6 from pinskia at gmail dot com 2008-09-01 10:43 ---
Subject: Re: bootstrap hangs in libstdc++
Sent from my iPhone
On Sep 1, 2008, at 3:25, "paolo dot carlini at oracle dot com"
<[EMAIL PROTECTED]
> wrote:
>
>
> --- Comment #4 from paolo dot carlini at oracle dot
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-09-01 11:02 ---
Grrr, this crap "overflow infinity" hits again... we try to set the
value-range
to [-INF, -INF(OVF)].
Which is because the overflow flag is set on -2147483647 in the assert
expression
ASSERT_EXPR .
Which is becaus
--- Comment #7 from paolo dot carlini at oracle dot com 2008-09-01 11:09
---
(In reply to comment #6)
> The other thing is that __thread is emulated on targets that don't
> support it.
That's interesting, I didn't notice we are actually doing that, right now (I
remember some discussi
$ cat x.c
struct { int a:1; } bf;
__typeof__(bf.a) clone;
$ g++ -x c x.c -c
x.c:2: error: 'typeof' applied to a bit-field
this testcase was extracted from gnupg-1.4.9 sources.
it works at least on gcc-3.2.3 (Red Hat Linux 3.2.3-53).
--
Summary: C frontend rejects __typeof__(bitfield
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-09-01 11:19 ---
FWIW the patch is ok for the 4.3 branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37248
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-09-01 11:21 ---
Sorry, but we need a complete compilable testcase to reproduce the issue.
Please also make sure you are not running into PR323 (you didn't report the
architecture you see the problem).
--
rguenth at gcc dot gnu d
[component might be wrong]
The appended test case is significantly faster with -Os -funroll-all-loops
(~5%) versus -O2 -funroll-all-loops in gcc 4.4 ( gcc version 4.4.0 20080829;
that
is shortly after the IRA merge) on a Core2 (Merom)
In earlier gcc versions they are about the same performance.
--- Comment #1 from andi-gcc at firstfloor dot org 2008-09-01 11:22 ---
Created an attachment (id=16178)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16178&action=view)
test case
checksum functions extracted from the Linux kernel.
Not preprocessed, but should compile on any x86
--- Comment #8 from cnstar9988 at gmail dot com 2008-09-01 11:24 ---
When I remove TLS check code in libstdc++-v3/configure, bootstrap OK!!!
Does there have anything harm when remove the TLS check code? affect only C++?
Thanks!
===
--- Comment #6 from jakub at gcc dot gnu dot org 2008-09-01 11:33 ---
Subject: Bug 37248
Author: jakub
Date: Mon Sep 1 11:32:18 2008
New Revision: 139858
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139858
Log:
PR middle-end/37248
PR middle-end/36449
*
--- Comment #5 from jakub at gcc dot gnu dot org 2008-09-01 11:33 ---
Subject: Bug 36449
Author: jakub
Date: Mon Sep 1 11:32:18 2008
New Revision: 139858
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139858
Log:
PR middle-end/37248
PR middle-end/36449
*
--- Comment #6 from jakub at gcc dot gnu dot org 2008-09-01 11:36 ---
Subject: Bug 36449
Author: jakub
Date: Mon Sep 1 11:34:47 2008
New Revision: 139859
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139859
Log:
PR middle-end/36449
* g++.dg/opt/pr36449.C: New t
--- Comment #1 from joseph at codesourcery dot com 2008-09-01 11:59 ---
Subject: Re: New: C frontend rejects __typeof__(bitfield).
On Mon, 1 Sep 2008, pluto at agmk dot net wrote:
> $ cat x.c
> struct { int a:1; } bf;
> __typeof__(bf.a) clone;
>
> $ g++ -x c x.c -c
> x.c:2: error: '
Build is broken on trunk, worked with revision 139848, for revision
139854 I see:
gcc -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes \
-Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-format-attribute
-fno-common -DHAVE_C
--- Comment #3 from jakub at gcc dot gnu dot org 2008-09-01 12:40 ---
This is a C++ FE bug. Shorter testcase:
enum E { E0 = 0, E1 = 'E' };
struct S
{
E s0 : 8;
enum E foo (bool, E);
};
E S::foo (bool a, E b)
{
return a ? s0 : b;
}
The bug is IMHO in build_conditional_expr. One
--- Comment #2 from pluto at agmk dot net 2008-09-01 12:58 ---
(In reply to comment #1)
> Subject: Re: New: C frontend rejects __typeof__(bitfield).
>
> On Mon, 1 Sep 2008, pluto at agmk dot net wrote:
>
> > $ cat x.c
> > struct { int a:1; } bf;
> > __typeof__(bf.a) clone;
> >
> > $
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2008-09-01 12:59
---
> It is not fixed on FreeBSD. I sometimes also see
>
> checking for i386-unknown-freebsd8.0-gcc... /usr/home/kargl/gcc/obj/./gcc/xgcc
> -B/usr/home/kargl/gcc/obj/./gcc/
> -B/usr/home/kargl/work/i386-unknown-fre
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2008-09-01 13:02
---
> From the backtrace I very doubt this is a IRA issue.
The backtrace is for another problem, the _muldi3 issue is a miscompilation of
gimple.c:gimple_build_asm_vec by the new regalloc/reload.
--
ebotcazou at
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Last reconfirmed|2008-09-01 13:02:39 |2008-09-01 13:0
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||wrong-code
Summary|Bootstrap failure due to|[4.4 Regre
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2008-09-01 13:18
---
> Yes, I realise that, but it's still documented and it was apparently harmless
> with 4.2.2
It's still documented because it's still useful on platforms that don't default
to DWARF-2, which is not the case of So
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-09-01 13:40 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2008-09-01 13:40
---
Reconfirmed with failure mode from comment #4 on i586-linux at r139863.
I'm going to investigate.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-09-01 13:41 ---
Subject: Bug 37305
Author: rguenth
Date: Mon Sep 1 13:39:42 2008
New Revision: 139864
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139864
Log:
2008-09-01 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-09-01 13:42 ---
Uh, well. The code ist mostly inline assembly which doesn't give GCC much
freedom to do something. I guess -O2 simply optimizes "too much" around the
asm. Try not using inline assembly instead.
--
http://gcc.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37296
--- Comment #1 from domob at gcc dot gnu dot org 2008-09-01 13:44 ---
Subject: Bug 37193
Author: domob
Date: Mon Sep 1 13:43:10 2008
New Revision: 139866
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139866
Log:
2008-09-01 Daniel Kraft <[EMAIL PROTECTED]>
PR fortran
--- Comment #3 from jakub at gcc dot gnu dot org 2008-09-01 13:50 ---
The problem is that cgraph_node_for_asm assumes that once it has been called
once, no new cgraph nodes will be created. But that's not true, at least C++
lang_hooks.callgraph.emit_associated_thunks (decl) adds new cgr
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P1 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36908
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-09-01 14:00
---
Try seeing if you need to install mpfr-devel and gmp-devel packages for your
distribution. This will install the headers needed for those libraries.
Also, make sure you are building in a separate directory away
--- Comment #4 from efernandez at physiomics-plc dot com 2008-09-01 14:09
---
Thanks David. Would that be worth it to make it appear in the regression list?
How can it be added to that bug list?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35397
--- Comment #3 from andi-gcc at firstfloor dot org 2008-09-01 14:20 ---
Thanks for the us^whelpful comment. If you can suggest a way to do carry
preserving addition without inline assembler that would be fine, otherwise not.
-Os seems to do something that improves it at least (and that
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-09-01 14:36 ---
Well, now -Os -funroll-all-loops doesn't do any unrolling anymore while it did
before. With -O2 you get what you ask for - unrolled loops.
-funroll-all-loops isn't really a flag to be used in general.
--
http:
--- Comment #3 from jakub at gcc dot gnu dot org 2008-09-01 15:38 ---
Created an attachment (id=16179)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16179&action=view)
gcc44-pr36904.patch
Updated patch, apparently all other problems can be fixed just by never
expanding the conditi
seg violation of compiler - previous versions compiled ok!
--
Summary: seg violation
Product: gcc
Version: 4.1.3
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot g
--- Comment #1 from w dot doeringer at fh-worms dot de 2008-09-01 15:41
---
Created an attachment (id=16180)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16180&action=view)
the ii file
the file you requested in your instructions on how to submit a bug report
--
http://gcc.g
--- Comment #4 from jakub at gcc dot gnu dot org 2008-09-01 15:46 ---
Works on the trunk for me.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-09-01 15:49 ---
Created an attachment (id=16181)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16181&action=view)
unincluded testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37314
--- Comment #3 from paolo dot carlini at oracle dot com 2008-09-01 15:50
---
Note, 4_1-branch is closed. I would suggest first trying a newer compiler on
your code, e.g., 4.3.2.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
-
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-09-01 15:53 ---
Confirmed.
Program received signal SIGSEGV, Segmentation fault.
0x00cd5495 in strip_array_types (type=0x0)
at /space/rguenther/src/svn/trunk/gcc/tree.c:5755
5755 while (TREE_CODE (type) == ARRAY_TYP
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-09-01 15:56 ---
Reducing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37314
--- Comment #6 from paolo dot carlini at oracle dot com 2008-09-01 16:01
---
Thanks Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37314
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-09-01 16:02 ---
Reduced testcase:
template
class Cdeque {
typedef T *pointer;
class iterator {
typedef typename Cdeque::pointer pointer;
pointer operator->();
};
};
template T* Cdeque::iterator::operat
--- Comment #1 from hp at gcc dot gnu dot org 2008-09-01 16:02 ---
Confirmed with 139863 that build works again.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-09-01 16:03 ---
Which I guess is invalid because the definition of Cdeque is not complete
at the time we bind iterator::pointer to Cdeque::pointer.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37314
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-09-01 16:05 ---
Though EDG accepts it (but of course nothing is instantiated here).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37314
--- Comment #10 from w dot doeringer at fh-worms dot de 2008-09-01 16:14
---
Subject: Re: [4.2/4.3/4.4 Regression] seg violation
Hi,
thanks for taking the time to look at my problem.
I did try with version 4.2 and fared no better.
Versions up to 4.0.x compile ok.
Let me know if I can
With revision 139521 this test passed.
>From revision 139525 and on, these tests have failed.
At revision 139842 the FAILs are as follows:
Running
/tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.c-torture/execute/execute.exp ...
FAIL: gcc.c-torture/execute/931018-1.c compilation, -O3 -fomit-frame-poin
--- Comment #11 from w dot doeringer at fh-worms dot de 2008-09-01 16:39
---
Subject: Re: [4.2/4.3/4.4 Regression] seg violation
Hi,
I have added some substance to the reduced testcase, so that now actual
code is generated. You find it in the attached file.
It compiles well under g++
--- Comment #14 from sgk at troutmask dot apl dot washington dot edu
2008-09-01 16:56 ---
Subject: Re: Bootstrap failure due to __muldi3
On Mon, Sep 01, 2008 at 10:30:27AM -, graham dot stott at btinternet dot
com wrote:
>
> --- Comment #10 from graham dot stott at btinternet
--- Comment #12 from howarth at nitro dot med dot uc dot edu 2008-09-01
16:57 ---
Does the fact that linux seems to be immune to this problem suggest that the
Darwin linker is too restrictive with regard to weak symbols? Would it make
sense to create a testcase and submit a
radar bug re
--- Comment #28 from danglin at gcc dot gnu dot org 2008-09-01 17:40
---
On hppa64-hp-hpux11.11, the test still fails at certain optimizations:
FAIL: gcc.c-torture/execute/20040709-1.c execution, -O0
FAIL: gcc.c-torture/execute/20040709-1.c execution, -O1
# ./xgcc -B./ -v
Reading
--- Comment #29 from dave at hiauly1 dot hia dot nrc dot ca 2008-09-01
18:17 ---
Subject: Re: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c
execution at -O2 and above
> On hppa64-hp-hpux11.11, the test still fails at certain optimizations:
>
> FAIL: gcc.c-torture/execute/
--- Comment #2 from jdemeyer at cage dot ugent dot be 2008-09-01 18:18
---
Created an attachment (id=16183)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16183&action=view)
Better and simpler test case
The second test case, asmtest2.i exhibits the bug on even more versions of gcc
--
jdemeyer at cage dot ugent dot be changed:
What|Removed |Added
Severity|normal |major
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37195
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/te
st/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/931004-1.c -w -O0 -lm
-
o /test/gnu/gcc/objdir/gcc/testsuite/gcc/931004-1.x0(timeout = 300)
PASS: gcc.c-torture/execute/931004-1.c compilation, -O0
Setting
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #1 from danglin at gcc dot gnu dot org 2008-09-01 18:28 ---
gcc.c-torture/execute/931004-3.c, gcc.c-torture/execute/931004-7.c and
gcc.c-torture/execute/931005-1.c also fail. These fails appear related.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37316
The following self-contained code should print the same for the bounds of xxx
and yyy (0:12). Instead it prints
bounds of yyy= 0 12
bounds of xxx= 1 13
% gfortran --version
GNU Fortran (GCC) 4.2.3 (Ubuntu 4.2.3-2ubuntu7)
This causes the current version of
--- Comment #1 from kargl at gcc dot gnu dot org 2008-09-01 19:02 ---
The correct result is given by both 4.3.2 and 4.4.0. You
may want to upgrade to a newer version of the compiler
because few if any patches will make it back to the 4.2 branch.
troutmask:sgk[204] ./z
bounds of yyy=
--- Comment #4 from jakub at gcc dot gnu dot org 2008-09-01 19:03 ---
Created an attachment (id=16184)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16184&action=view)
gcc44-pr37095.patch
Patch I'm going to bootstrap now.
--
jakub at gcc dot gnu dot org changed:
Wh
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
-
DSKIP_DECIMAL_FLOAT -c -o c_compat_x_tst.o
/test/gnu/gcc/gcc/gcc/testsuite/gcc.
dg/compat//scalar-by-value-4_x.c(timeout = 300)
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/compat//scalar-by-value-4_x.c: In
functio
n 'c
--- Comment #1 from danglin at gcc dot gnu dot org 2008-09-01 19:08 ---
Also,
(gdb) p debug_rtx (orig_dst)
(concat:CQI (reg:QI 95)
(reg:QI 96))
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37318
Between revisions 139588 (working) and 139622 (broken), the test
gfortran.dg/function_kinds_5.f90 started to fail: the expected error is no
longer emitted:
[ibook-dhum] f90/bug% gfc -c
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/function_kinds_5.f90
[ibook-dhum] f90/bug% gfortran -c
/opt/gcc/_gc
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #3 from jason at gcc dot gnu dot org 2008-09-01 19:35 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from jason at gcc dot gnu dot org 2008-09-01 19:35 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from rosinskijm at ornl dot gov 2008-09-01 19:36 ---
Thank you for the quick response. Glad the bug is fixed in newer releases. Feel
free to close the bug, or is the reporter supposed to do that?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37317
FAIL: gcc.dg/compat/struct-by-value-1 c_compat_x_tst.o-c_compat_y_tst.o execute
FAIL: gcc.dg/compat/struct-by-value-2 c_compat_x_tst.o-c_compat_y_tst.o execute
FAIL: gcc.dg/compat/struct-by-value-3 c_compat_x_tst.o-c_compat_y_tst.o execute
FAIL: gcc.dg/compat/struct-by-value-4 c_compat_x_tst.o-c
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/te
st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/debug/dwarf2/dwarf-die3.c -O0 -gdwarf-2
-d
A -S -o dwarf-die3.s(timeout = 300)
PASS: gcc.dg/debug/dwarf2/dwarf-die3.c (test for excess errors)
FAIL: gcc.dg/debug/dwarf2/dwarf-
On 686-apple-darwin9 between revisions 139622 (working or not implemented) and
139843 (broken) I have the following failures:
FAIL: gfortran.dg/debug/pr35154-dwarf2.f -gdwarf-2 scan-assembler DW_AT_name:
"__BLNK__"
FAIL: gfortran.dg/debug/pr35154-dwarf2.f -gdwarf-2 scan-assembler DW_AT_name:
"labe
FAIL: gcc.dg/builtin-apply2.c execution test
FAIL: gcc.dg/builtin-apply3.c execution test
FAIL: gcc.dg/builtin-apply4.c execution test
--
Summary: [4.4 Regression] __builtin_apply failures
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Seve
--- Comment #1 from danglin at gcc dot gnu dot org 2008-09-01 19:52 ---
Also,
FAIL: gcc.dg/builtin-return-1.c execution test
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37323
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/te
st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/utf-array.c -std=gnu99 -S -o utf-array.s
(timeout = 300)
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/utf-array.c:12: error: char-array
initial
ized from wide string
/test/gnu/gcc/g
FAIL: gcc.dg/visibility-14.c scan-hidden hidden[ \t_]*foo
FAIL: gcc.dg/visibility-15.c scan-hidden hidden[ \t_]*foo
FAIL: gcc.dg/visibility-16.c scan-hidden hidden[ \t_]*foo
FAIL: gcc.dg/visibility-17.c scan-hidden hidden[ \t_]*foo
FAIL: gcc.dg/visibility-18.c scan-hidden hidden[ \t_]*foo
FAIL: gcc
--- Comment #2 from hp at gcc dot gnu dot org 2008-09-01 20:15 ---
Actually ... failing: 139762. So, rguenth is no longer a suspect.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from danglin at gcc dot gnu dot org 2008-09-01 20:19 ---
Also, these seem related:
FAIL: gcc.dg/torture/pr30665-2.c -O0 execution test
FAIL: gcc.dg/torture/pr30665-2.c -O1 execution test
FAIL: gcc.dg/torture/pr30665-2.c -O2 execution test
FAIL: gcc.dg/torture/pr3066
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/te
st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/tree-ssa/ssa-store-ccp-3.c -O2
-fno-common
-fdump-tree-optimized -S -o ssa-store-ccp-3.s(timeout = 300)
PASS: gcc.dg/tree-ssa/ssa-store-ccp-3.c (test for excess errors)
FAIL:
--- Comment #7 from etienne_lorrain at yahoo dot fr 2008-09-01 20:29
---
Patch works for me, thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37248
This is mostly because of extra register moves that IRA some times
introduces. There is another bug about Inline-asm and the return
register.
Sent from my iPhone
On Sep 1, 2008, at 7:36, "rguenth at gcc dot gnu dot org" <[EMAIL PROTECTED]
> wrote:
--- Comment #4 from rguenth at gcc
--- Comment #2 from joseph at codesourcery dot com 2008-09-01 20:40 ---
Subject: Re: [4.4 Regression] gcc.dg/compat//scalar-by-value-4_x.c:72:
ICE: in emit_group_store, at expr.c:2084
Someone needs to review HJ's patch
http://gcc.gnu.org/ml/gcc-patches/2008-08/msg01078.html
that fix
--- Comment #5 from pinskia at gmail dot com 2008-09-01 20:41 ---
Subject: Re: -Os significantly faster than -O2 on test case
This is mostly because of extra register moves that IRA some times
introduces. There is another bug about Inline-asm and the return
register.
Sent from my
1 - 100 of 121 matches
Mail list logo
