--- Comment #4 from rwgk at yahoo dot com 2008-12-07 07:44 ---
Testing with:
g++ (GCC) 4.4.0 20081206 (experimental)
svn revision 142514
pr37922repro1.cpp should always exit with status 0.
However, it fails this test when compiling with -O3 and -O2:
g++ -Wall -fPIC -O3
--- Comment #3 from rwgk at yahoo dot com 2008-12-07 07:34 ---
Created an attachment (id=16844)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16844&action=view)
reproducer, no dependencies, no includes
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37922
--- Comment #6 from dirtyepic at gentoo dot org 2008-12-07 06:42 ---
This is up to four failures now:
FAIL: gcc.c-torture/compile/limits-structnest.c -O2 (test for excess errors)
FAIL: gcc.c-torture/compile/limits-structnest.c -O3 -fomit-frame-pointer
(test for excess errors)
FAIL:
--- Comment #40 from bonzini at gnu dot org 2008-12-07 02:55 ---
IIUC this is a typical case in which CSE was fixing something that earlier
passes messed up. Unfortunately fwprop does (better) what CSE was meant to do,
but does not do what I assumed was already done before CSE.
If the
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-12-07 01:18
---
Fixed on trunk:
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
St
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-12-07 01:17
---
Subject: Bug 38425
Author: jvdelisle
Date: Sun Dec 7 01:15:46 2008
New Revision: 142535
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142535
Log:
2008-12-06 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #9 from hjl dot tools at gmail dot com 2008-12-07 01:13 ---
Those 3 still aren't fixed:
FAIL: gcc.dg/vect/vect-67.c scan-tree-dump-times vect "vectorized 1 loops" 1
FAIL: gcc.dg/vect/no-scevccp-outer-13.c scan-tree-dump-times vect "OUTER LOOP
VECTORIZED." 1
FAIL: gcc.dg/vect
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-12-07 01:12
---
Subject: Bug 38425
Author: jvdelisle
Date: Sun Dec 7 01:10:42 2008
New Revision: 142534
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142534
Log:
2008-12-06 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #5 from hjl dot tools at gmail dot com 2008-12-07 01:11 ---
See PR 36792.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37853
--- Comment #38 from pinskia at gcc dot gnu dot org 2008-12-07 00:58
---
*** Bug 38433 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-12-07 00:58 ---
*** This bug has been marked as a duplicate of 8270 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #39 from pinskia at gcc dot gnu dot org 2008-12-07 01:01
---
>From JSM in PR 38433:
On Sat, 6 Dec 2008, eric dot niebler at gmail dot com wrote:
> In the attached file, there is a comment terminated with a line-termination
> character (\) followed by spaces. This should NO
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-12-07 00:54 ---
(In reply to comment #3)
> I read this as permitting a mapping of characters, but not a deletion of
> characters, which is what gcc is doing. The only deletion of characters I see
> permitted is the deletion of a new
--- Comment #3 from eric dot niebler at gmail dot com 2008-12-07 00:46
---
If you are referring to 2.1/1 ...
"Physical source file characters are mapped, in an implementation-defined
manner, to the basic source character set (introducing new-line characters for
end-of-line indicators)
--- Comment #2 from joseph at codesourcery dot com 2008-12-07 00:28 ---
Subject: Re: New: Incorrect handling of line termination
character with trailing spaces
On Sat, 6 Dec 2008, eric dot niebler at gmail dot com wrote:
> In the attached file, there is a comment terminated with a l
--- Comment #4 from dominiq at lps dot ens dot fr 2008-12-07 00:17 ---
The failure appeared at revision 137631 (not in r137630, see
http://gcc.gnu.org/ml/gcc-testresults/2008-07/msg01011.html).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37853
--- Comment #3 from dominiq at lps dot ens dot fr 2008-12-07 00:11 ---
Fails also on
x86_64-unknown-linux-gnu:
http://gcc.gnu.org/ml/gcc-testresults/2008-12/msg00519.html
ia64-unknown-linux-gnu:
http://gcc.gnu.org/ml/gcc-testresults/2008-12/msg00518.html,
powerpc64-suse-linux-gnu:
http
--- Comment #1 from eric dot niebler at gmail dot com 2008-12-06 23:59
---
Created an attachment (id=16843)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16843&action=view)
Compile with: g++ -Wall test.cpp
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38433
In the attached file, there is a comment terminated with a line-termination
character (\) followed by spaces. This should NOT be considered a line
terminator, yet gcc considers it as such. From 2.1/2 in the C++03 standard:
"Each instance of a new-line character and an immediately preceding backsla
--- Comment #2 from dominiq at lps dot ens dot fr 2008-12-06 23:56 ---
The output of -ftree-vectorizer-verbose=6 gives:
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/vect-67.c:30: note: not
vectorized: too many BBs in loop.
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/vect-67.c:17: not
--- Comment #14 from steven at gcc dot gnu dot org 2008-12-06 22:54 ---
Fixed in GCC 4.4.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #15 from steven at gcc dot gnu dot org 2008-12-06 22:54 ---
Subject: Bug 36365
Author: steven
Date: Sat Dec 6 22:52:43 2008
New Revision: 142529
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142529
Log:
PR rtl-optimization/36365
* df-core.c (df_work
--- Comment #4 from joseph at codesourcery dot com 2008-12-06 22:53 ---
Subject: Re: __builtin_constant_p(t) ? t : 1 is not considered
a constant integer expression
On Sat, 6 Dec 2008, sabre at nondot dot org wrote:
> Ok, so this is a special case when __builtin_constant_p is immedia
--- Comment #6 from sabre at nondot dot org 2008-12-06 22:44 ---
FWIW, llvm-g++ gets this right.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11211
--- Comment #13 from zadeck at naturalbridge dot com 2008-12-06 22:33
---
Subject: Re: [4.3/4.4 Regression] Hang in df_analyze
steven at gcc dot gnu dot org wrote:
> --- Comment #12 from steven at gcc dot gnu dot org 2008-12-06 21:25
> ---
> Patch here:
> http://gcc.gnu.org/
--- Comment #1 from burnus at gcc dot gnu dot org 2008-12-06 22:18 ---
I wanted to write: That loop will never be run, sorry for the miswording.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
-
Ignoring overflows, the following program would run for ever. NAG f95 prints
the
Warning: DO loop has zero iteration count
integer :: i
do i = 1, -3, 1
end do
end
--
Summary: Add warning for endless loops
Product: gcc
Version: 4.4.0
Status: UNCONF
--- Comment #11 from steven at gcc dot gnu dot org 2008-12-06 22:05 ---
What's the status of this bug? Fixed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37948
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2008-12-06 21:54
---
Subject: Bug 38291
Author: jvdelisle
Date: Sat Dec 6 21:53:11 2008
New Revision: 142528
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142528
Log:
2008-12-06 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #5 from hp at gcc dot gnu dot org 2008-12-06 21:33 ---
Sorry, it didn't help.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38430
--- Comment #3 from sabre at nondot dot org 2008-12-06 21:31 ---
Ok, so this is a special case when __builtin_constant_p is immediately the
operand of "?:"? Do you allow things like __builtin_constant_p(...)+0 as the
operand?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38377
--- Comment #12 from steven at gcc dot gnu dot org 2008-12-06 21:25 ---
Patch here:
http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00409.html
Approval mail never made it through, but you can see traces of it here:
http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00410.html
--
steven at gc
--- Comment #6 from jakub at gcc dot gnu dot org 2008-12-06 21:17 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #4 from hp at gcc dot gnu dot org 2008-12-06 21:15 ---
(In reply to comment #3)
> Try this and let me know.
Will do.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38430
--- Comment #5 from jakub at gcc dot gnu dot org 2008-12-06 21:08 ---
Subject: Bug 38428
Author: jakub
Date: Sat Dec 6 21:06:43 2008
New Revision: 142527
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142527
Log:
PR middle-end/38428
* tree-ssa-operands.c (get_ex
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-12-06 21:01
---
I did miss an fbuf_flush. I am not sure why it matters unless it is avoiding
some actual disk operations for us. Try this and let me know.
@@ -2146,7 +2155,10 @@ data_transfer_init (st_parameter_dt *dtp
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-12-06 20:25 ---
This could also be useful when done in the middle-end,
see PR 21046.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from steven at gcc dot gnu dot org 2008-12-06 20:17 ---
Created an attachment (id=16842)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16842&action=view)
Remove overeager solver
Bootstrapped and tested on ia64-unknown-linux-gnu.
Time-tested by compiling cc1-i/cc1p
--- Comment #2 from hp at gcc dot gnu dot org 2008-12-06 20:09 ---
If there was an ftruncate call in the execution path, then I'd see the
"required ftruncate or chsize support not present" message in the log, and I
don't.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38430
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-12-06 19:35
---
This very well could be the ftruncate issue since I did modify the code path.
however, it seems that if these test cases worked before then we are
unnecessarily doing the ftruncate for the pos= code path in data_
the current graphite branch segfaults & ICEs on several files from CP2K.
Compiling with '-O2 -ffast-math -funroll-loops -ftree-vectorize -march=native
-fgraphite -fgraphite-identity'
To reproduce get
http://www.pci.uzh.ch/vandevondele/tmp/CP2K_2008_12_03.tgz
untar and type make
at least on the
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfi
With revision 142513 these test passed.
>From revision 142516 and on, these tests have failed as follows
(together with related tests:
Running /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gfortran.dg/dg.exp ...
...
FAIL: gfortran.dg/streamio_1.f90 -O0 execution test
FAIL: gfortran.dg/streamio_10.f90
--- Comment #2 from joseph at codesourcery dot com 2008-12-06 19:09 ---
Subject: Re: __builtin_constant_p(t) ? t : 1 is not considered
a constant integer expression
On Sat, 6 Dec 2008, sabre at nondot dot org wrote:
> This is a bug in the C front-end. They need to use __builtin_choo
--- Comment #11 from jv244 at cam dot ac dot uk 2008-12-06 18:54 ---
(In reply to comment #10)
> If the code layout (see comment #2) is indeed causing the slow-down, this
> problem might have been fixed along with bug 38074.
No, timings are still identical:
gcc version 4.4.0 20
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-12-06 18:43
---
On it
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unass
--- Comment #1 from sabre at nondot dot org 2008-12-06 18:42 ---
This is a bug in the C front-end. They need to use __builtin_choose_expr.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38377
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2008-12-06
16:53 ---
Ignore my last comment. I misread the proposed syntax.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38300
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2008-12-06
16:49 ---
Remember we don't want to match darwin10. Mike Stump recommended recently that
not worrying about darwin1 and darwin2 would be okay. So the alternative would
be...
*-*-darwin[3-8]|*-*-darwin[3-8].*) ...
--- Comment #39 from lucier at math dot purdue dot edu 2008-12-06 16:37
---
I may have narrowed down the problem a bit.
With this compiler (revision 118491):
pythagoras-277% /tmp/lucier/install/bin/gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../../ma
--- Comment #10 from steven at gcc dot gnu dot org 2008-12-06 15:37 ---
If the code layout (see comment #2) is indeed causing the slow-down, this
problem might have been fixed along with bug 38074.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38306
--
drow at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirme
--- Comment #3 from drow at gcc dot gnu dot org 2008-12-06 15:18 ---
I tried 4.4.0 20081130; it does not look fixed.
:
# mult_acc.14_40 = PHI
[break.c : 12] D.2737_41 = value_13 + -1;
[break.c : 12] D.2738_42 = (unsigned int) D.2674_12;
[break.c : 12] D.2739_43 = 2 - D.2738_42;
--- Comment #8 from janus at gcc dot gnu dot org 2008-12-06 13:57 ---
Created an attachment (id=16841)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16841&action=view)
patch v1
Here is a draft patch which correctly copies the typespec and formal args for a
PROCEDURE statement with
--- Comment #2 from jan dot kratochvil at redhat dot com 2008-12-06 13:22
---
It looks fixed in 4.4 for me, tested on:
GNU C (GCC) version 4.4.0 20081202 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.4.0 20081202 (experimental), GMP version
4.2.2, MPFR ve
--- Comment #4 from jakub at gcc dot gnu dot org 2008-12-06 13:06 ---
Apparently caused by my PR37248 patch. We have a volatile bitfield, and the
patch (similarly to 4.3) creates a TREE_THIS_VOLATILE TREE_SIDE_EFFECTS
BIT_FIELD_REF, but apparently the trunk is upset about it.
Either we
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-12-06 13:05 ---
typedef unsigned int __u32;
typedef __u32 uint32_t;
typedef struct {
volatile struct {
uint32_t online : 1;
} flags;
} scsi_qla_host_t;
int qla2x00_wait_for_hba_online(scsi_qla_host_t *ha) {
int r
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Component|c |middle-end
Keywords||ice-on-val
--- Comment #5 from jakub at gcc dot gnu dot org 2008-12-06 12:49 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-12-06 12:50 ---
reducing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38428
--- Comment #4 from jakub at gcc dot gnu dot org 2008-12-06 12:48 ---
Subject: Bug 38422
Author: jakub
Date: Sat Dec 6 12:47:15 2008
New Revision: 142521
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142521
Log:
PR middle-end/38422
* fold-const.c (fold_unary) :
--- Comment #1 from dcb314 at hotmail dot com 2008-12-06 12:28 ---
Created an attachment (id=16840)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16840&action=view)
C source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38428
I just tried to compile the Linux kernel version 2.6.27.7
with the GNU C compiler version 4.4 snapshot 20081205.
The compiler said
drivers/scsi/qla2xxx/qla_os.c: In function 'qla2x00_free_device':
drivers/scsi/qla2xxx/qla_os.c:1809: internal compiler error: in
gimple_rhs_has_side_effects, at gimp
--- Comment #7 from burnus at gcc dot gnu dot org 2008-12-06 12:25 ---
Check backed out in PR 38415, cf.
http://gcc.gnu.org/ml/fortran/2008-12/msg00089.html
"I'm afraid I'll have to remove the gfc_compare_interfaces check in
gfc_check_pointer_assign again, since I just noticed that it
--- Comment #6 from janus at gcc dot gnu dot org 2008-12-06 12:23 ---
Reopening. The check for comparing the interfaces was taken out again in
r142520, since there were problems with intrinsics. Details will follow.
--
janus at gcc dot gnu dot org changed:
What|Remove
--- Comment #3 from janus at gcc dot gnu dot org 2008-12-06 12:18 ---
Fixed with r142520. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from janus at gcc dot gnu dot org 2008-12-06 12:17 ---
Subject: Bug 38415
Author: janus
Date: Sat Dec 6 12:15:49 2008
New Revision: 142520
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142520
Log:
2008-12-06 Janus Weil <[EMAIL PROTECTED]>
PR fortran/3
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-12-06 12:03 ---
Confirmed. It would be error-recovery if GCC rejected the code as required
(2.95.4 rejects it). Default-initialization of references is not valid.
--
rguenth at gcc dot gnu dot org changed:
What
I just tried to compile the following C++ source code
with the GNU C compiler version 4.4 snapshot 20081205.
struct S
{
int & ref;
S() : ref() {
};
};
The compiler said
$ ~/gcc/20081205/results/bin/g++ jun17.cc
jun17.cc: In constructor 'S::S()':
jun17.cc:5: warning: defau
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-12-06 11:10 ---
It seems that this was fixed recently (works for me with r142437). I can
confirm
this crash with r141893.
Please update your tree and verify the problem is fixed. If not, re-open this
bug. Thanks.
--
rguenth
--- Comment #10 from rguenth at gcc dot gnu dot org 2008-12-06 11:05
---
Yep. Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|N
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-12-06 11:05 ---
Confirmed.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #9 from tkoenig at gcc dot gnu dot org 2008-12-06 10:51 ---
This is now fixed:
$ cat foo.c
int foo(unsigned char x)
{
return (x+1) != 0;
}
$ gcc -O3 -fdump-tree-optimized -S foo.c
$ cat foo.s
.file "foo.c"
.text
.p2align 4,,15
.globl foo
--- Comment #3 from paolo dot carlini at oracle dot com 2008-12-06 10:27
---
Fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Statu
--- Comment #2 from paolo at gcc dot gnu dot org 2008-12-06 10:26 ---
Subject: Bug 38421
Author: paolo
Date: Sat Dec 6 10:25:24 2008
New Revision: 142519
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142519
Log:
2008-12-06 Paolo Carlini <[EMAIL PROTECTED]>
PR libstd
--- Comment #1 from paolo dot carlini at oracle dot com 2008-12-06 10:22
---
Let's take care of this.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #3 from jakub at gcc dot gnu dot org 2008-12-06 10:03 ---
http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00389.html
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from d dot g dot gorbachev at gmail dot com 2008-12-06
09:52 ---
Created an attachment (id=16839)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16839&action=view)
Preprocessed source
mingw32-gcc -S -Os -momit-leaf-frame-pointer -fno-unit-at-a-time win32.i
C source
GCC-4.4
[EMAIL PROTECTED]:
pushl %ebp
pushl %edi
pushl %esi
pushl %ebx
subl$28, %esp
movl-2100956, %ebx
movl56(%ebx), %ebp
%ebp is used as a spare register in a non-leaf function.
--
Summary: Incorrect code
--- Comment #12 from tkoenig at gcc dot gnu dot org 2008-12-06 09:37
---
Still present with current trunk.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Cf. http://gcc.gnu.org/ml/fortran/2008-12/msg00043.html
!--
character(len=30) :: str
open(3,access='stream')
! C919 (R913) If io-unit is not a file-unit-number, the
! io-control-spec-list shall not contain a REC= specifier
! or a POS= specif
--- Comment #5 from jakub at gcc dot gnu dot org 2008-12-06 09:01 ---
To close as dup of PR38371.
*** This bug has been marked as a duplicate of 38371 ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from jakub at gcc dot gnu dot org 2008-12-06 09:01 ---
*** Bug 38224 has been marked as a duplicate of this bug. ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from jakub at gcc dot gnu dot org 2008-12-06 09:00 ---
Reopening...
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|RESOLVE
--- Comment #13 from jakub at gcc dot gnu dot org 2008-12-06 08:59 ---
Fixed, thanks.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #3 from edwintorok at gmail dot com 2008-12-06 08:37 ---
This got fixed somewhere between r142405 and r142487, because
r142487 has bootstrapped successfully.
--
edwintorok at gmail dot com changed:
What|Removed |Added
--
--- Comment #12 from hubicka at gcc dot gnu dot org 2008-12-06 08:35
---
Subject: Bug 38074
Author: hubicka
Date: Sat Dec 6 08:34:20 2008
New Revision: 142517
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142517
Log:
PR tree-optimization/38074
* cgraphbuild.c
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2008-12-06 08:32
---
And I cannot reproduce with a cross:
[EMAIL PROTECTED]:~/build/gcc-4_3-branch/arm-linux-gnueabi> gcc/cc1plus -quiet
-nostdinc++ -v -g -O2 -Wswitch-enum -Wextra -Wall -version -fno-rtti
-fnon-call-exceptions -fdol
--- Comment #2 from jakub at gcc dot gnu dot org 2008-12-06 08:28 ---
Likely caused by PR35422. Endless recursion, always fold_converting the same
type and operand.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38422
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2008-12-06 08:11
---
> r142149 | ebotcazou | 2008-11-24 09:36:43 +0100 (Mon, 24 Nov 2008) | 4 lines
>
> * df-scan.c (df_get_call_refs): For unconditional noreturn calls
> add EH_USES regs as artificial uses.
>
90 matches
Mail list logo
