--- Comment #3 from burnus at gcc dot gnu dot org 2008-09-02 05:43 ---
(In reply to comment #2)
> 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?
Well, in principle it does not matter who
--- Comment #14 from pinskia at gcc dot gnu dot org 2008-09-02 03:53
---
Created an attachment (id=16186)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16186&action=view)
Patch which should fix it but needs full testing
ChangeLog:
* cgraphunit.c (update_call_expr): Remove eh regi
--- Comment #9 from kargl at gcc dot gnu dot org 2008-09-02 03:46 ---
(In reply to comment #8)
> gfortran -O3 -Wuninitialized -fno-f2c -ffast-math -fno-automatic
> -fno-backslash tssum.f ../gen_util/gen_util_lib.a
> ../../libraries/matrix/kinv_lib.a ../../libraries/comlib/com_lib.a -
=/home/regehr : (reconfigured) ../configure
--program-prefix=current- --prefix=/home/regehr --enable-languages=c,c++
--no-create --no-recursion
Thread model: posix
gcc version 4.4.0 20080901 (experimental) (GCC)
[EMAIL PROTECTED]:~/volatile/tmp21$ cat small.c
typedef signed char int8_t;
typedef
--- Comment #13 from pinskia at gcc dot gnu dot org 2008-09-02 03:13
---
Here is a reduced testcase for the next failure:
int& f(int&);
inline void _M_reset(int &_M_vbp) throw()
{
f(_M_vbp);
}
extern int _S_last_request;
void _M_allocate_single_object() throw()
{
_M_reset(_S_last_r
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-09-02 02:47
---
Works for me here with latest trunk. x86-64-linux
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37319
--- Comment #8 from petermorgan at grapevine dot net dot au 2008-09-02
02:36 ---
Subject: Re: gfortran errors in compilation and the making
for upgraded compilers
Dear Guys
Okay I have a 4.3.1 set of language compilers on board.
I have tested the gfortran compiler on the NGA progra
--- Comment #4 from hp at gcc dot gnu dot org 2008-09-02 01:49 ---
Not a target bug and my trivial attempt at a solution failed. Unassigning
myself.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from hp at gcc dot gnu dot org 2008-09-02 01:48 ---
Created an attachment (id=16185)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16185&action=view)
Non-working conceptual patch - just an illustration to my previous comment.
Unfortunately it doesn't work: the calle
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #2 from hp at gcc dot gnu dot org 2008-09-02 00:47 ---
Honza, why is tree-inline.c:initialize_cfun not calling
allocate_struct_function and *then* change whatever elements need changing?
There's no comment to reveal the reason. Now, you're just allocating a cleared
area and
--- Comment #7 from petermorgan at grapevine dot net dot au 2008-09-02
00:45 ---
Subject: Re: gfortran errors in compilation and the making
for upgraded compilers
Dear Kargl
Yes I added the additional bit of info and now I have built all the
languages. I will now test them and let
--- Comment #1 from hp at gcc dot gnu dot org 2008-09-02 00:10 ---
Looks like my first guess was right.
For gcc.c-torture/execute/931018-1.c I see a function and a cloned (but empty,
wtf?) function with the same cfun->machine.
I'm looking just a little bit more.
--
hp at gcc dot gnu
--- Comment #6 from kargl at gcc dot gnu dot org 2008-09-01 23:31 ---
(In reply to comment #5)
>
> Do you want a new bug report for this error.
No. This isn't a gcc bug.
Try adding --disable-multilib to your configure line.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37310
--- Comment #5 from petermorgan at grapevine dot net dot au 2008-09-01
23:22 ---
Subject: Re: gfortran errors in compilation and the making
for upgraded compilers
Hi Guys
Do you want a new bug report for this error.
I issued a " make bootstrap" after the configure in the normal w
--- Comment #4 from petermorgan at grapevine dot net dot au 2008-09-01
23:12 ---
Subject: Re: gfortran errors in compilation and the making
for upgraded compilers
Dear All
thanks for the reply
I have brought up the configure help pages of GNU.
While I had tried the inclusion of the
--- Comment #3 from kargl at gcc dot gnu dot org 2008-09-01 22:38 ---
(In reply to comment #2)
> checking for correct version of gmp.h... yes
> checking for correct version of mpfr.h... no
Clearly, configure can't find your installation of MPFR.
> configure: error: Building GCC requi
--- Comment #2 from petermorgan at grapevine dot net dot au 2008-09-01
22:22 ---
Subject: Re: gfortran errors in compilation and the making
for upgraded compilers
Thanks for the mail message below.
I have checked my system as suggested. The gmp-development is installed see
[EMAIL P
--- Comment #15 from ebotcazou at gcc dot gnu dot org 2008-09-01 21:46
---
> 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-freebsd8.0/bin/
> -B/usr/home/kargl/work/i386-unknown-free
--
jdemeyer at cage dot ugent dot be changed:
What|Removed |Added
CC||jdemeyer at cage dot ugent
|
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2008-09-01
20:44 ---
Subject: Re: libgcc2.c:806: ICE: vector VEC(me m_ref_p,base) index domain
error, in create_vop_ref_mapping_loopRO
> Sounds like stage2 is miscompiled then. Can you try the preprocessed source
> with
> the
--- 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
--- 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
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 #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
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 #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
--- 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
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
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
--- 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
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
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
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-
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
--- 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
--- 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 #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
--
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
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
--- 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
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 #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
--- 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=
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 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
--
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
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
--
jdemeyer at cage dot ugent dot be changed:
What|Removed |Added
Severity|normal |major
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37195
--- 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
--- 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 #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 #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 #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 #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++
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 #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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
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 #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
--- 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 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 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 #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
--
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 #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
--- 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
--
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 #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.
--- 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 #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 #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 #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
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||wrong-code
Summary|Bootstrap failure due to|[4.4 Regre
--
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
--- 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
--- 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 #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 #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
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 #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: '
--- 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 #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: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 #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 #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
[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 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
--- 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
$ 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
1 - 100 of 121 matches
Mail list logo
