--- Comment #1 from jakub at gcc dot gnu dot org 2009-12-01 08:19 ---
Simplified testcase without the undefined signed underflow:
void
foo (int x)
{
struct S { int s; } d = { 1 };
unsigned int e = 1;
if (x)
e = x && d.s;
else
for (e = 0; e <= 3; e--)
;
e++;
}
The
Compile the attached source code with options -Os -fpic -mthumb, gcc generates
following code for the constructor:
push{r4, r5, r6, r7, lr}
.LCFI2:
.pad #12
sub sp, sp, #12
.LCFI3:
str r3, [sp]
add r3, sp, #32//A, B
ldrbr3, [
--- Comment #1 from carrot at google dot com 2009-12-01 09:01 ---
Created an attachment (id=19194)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19194&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42235
--- Comment #3 from janus at gcc dot gnu dot org 2009-12-01 09:11 ---
This simple patch fixes comment #0 (but not comment #1):
Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c(revision 154840)
+++ gcc/fo
--- Comment #4 from paolo at gcc dot gnu dot org 2009-12-01 09:20 ---
Subject: Bug 42057
Author: paolo
Date: Tue Dec 1 09:19:47 2009
New Revision: 154865
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154865
Log:
2009-12-01 Paolo Carlini
PR c++/42057
* g++.d
--- Comment #5 from paolo dot carlini at oracle dot com 2009-12-01 09:22
---
Done, thank you.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #26 from rguenther at suse dot de 2009-12-01 09:42 ---
Subject: Re: Weird translation of DO loops
On Mon, 30 Nov 2009, tkoenig at gcc dot gnu dot org wrote:
>
>
> --- Comment #22 from tkoenig at gcc dot gnu dot org 2009-11-30 19:15
> ---
> (In reply to comment
The following program triggers a bug box.
gcc-4.4 -c t.adb
+===GNAT BUG DETECTED==+
| 4.4.2 (x86_64-pc-linux-gnu) Assert_Failure sinfo.adb:1149|
| Error detected at t.adb:49:13|
| Please
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-12-01 09:58 ---
It was indeed Bernds patch. Bernd - the patch discription suggested it was
a compile-time performance fix and not going to change code? There is quite
big effect (including this negative one) on SPEC CPU 2006 on x8
--- Comment #4 from nbenoit at tuxfamily dot org 2009-12-01 10:11 ---
It seems that this regression first appeared with revision 151080
* with -O1
GCC-4.4.2 7.4 s
GCC-trunk-r151078 7.4 s
GCC-trunk-r151079 7.4 s
GCC-trunk-r151080 9.4 s
GCC-trunk-r151081 9.4 s
GCC-trunk-r1510
Compiling of qt-x11-opensource-src-4.5.3-64/tools/qdoc3/cppcodeparser.cpp
failed with:
> g++ -c -fpreprocessed -m32 -O2 cppcodeparser.1.i -o cppcodeparser.1.o
cppcodeparser.1.i: In function 'QMutableListIterator::previous()':
cppcodeparser.1.i:18150:1: error: invalid rhs for gimple memory store
*
--- Comment #1 from mario-baumann at web dot de 2009-12-01 10:56 ---
Created an attachment (id=19195)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19195&action=view)
Reduced version of cppcodeparser.cpp
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42237
--- Comment #2 from mario-baumann at web dot de 2009-12-01 10:56 ---
Created an attachment (id=19196)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19196&action=view)
preprocessed cpp file of cppcodeparser.1.cpp
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42237
--- Comment #3 from mario-baumann at web dot de 2009-12-01 11:00 ---
> uname -a
Linux yoda.intec.dom 2.6.18-164.el5 #1 SMP Thu Sep 3 03:28:30 EDT 2009 x86_64
x86_64 x86_64 GNU/Linux
> rpm -qa "glibc*" | grep -e 'glibc-[0-9]' | sort -u
glibc-2.5-42
> g++ -v
Using built-in specs.
COLLECT
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-12-01 11:14 ---
Confirmed. IPA-SRA generates this.
# .MEM_9 = VDEF <.MEM_14>
*ISRA.13_16(D) = *ISRA.12_2(D);
if that's invalid gimple it means that the type is is_gimple_reg_type.
--
rguenth at gcc dot gnu dot org changed:
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Keywords||missed-op
--- Comment #5 from matz at gcc dot gnu dot org 2009-12-01 11:24 ---
Hmpf, something fishy is going on, as this patch should have been only
refactoring without influence on the generated code. I'll look at it.
--
matz at gcc dot gnu dot org changed:
What|Removed
When compiling the following code I expect a warning about usage of
uninitialized variable.
int main(int argc, const char*[]){
do {
int a = a;
} while(1);
return 0;
}
Even when compiled with "-Wall -Winit-self" I get no warning. I have tried with
both g++-
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-12-01 12:15 ---
Re-confirmed. Rafael - as you seem to have caused this can you look into it?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-12-01 12:23
---
A cross to spu-elf from x86_64 doesn't ICE. Can someone re-confirm that the
bug is still happening?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from jamborm at gcc dot gnu dot org 2009-12-01 13:04 ---
Right. IPA-SRA currently relies on that it can always replace a memory
reference with a memory reference. But both sides of this assignment
were originally one field structures turned into scalars and so the
assumpt
--- Comment #2 from jakub at gcc dot gnu dot org 2009-12-01 13:34 ---
Reduced testcase:
extern int foo (void);
extern int g;
void
bar ()
{
#pragma omp critical
{
int j;
for (j = 0; j < foo (); j++) ;
if (0)
if (g >= 4) ;
}
}
--
jakub at gcc dot gnu dot org chan
--- Comment #6 from eres at il dot ibm dot com 2009-12-01 13:45 ---
(In reply to comment #5)
> test.f works on amd64-linux on the graphite branch.
> I am doing the merge of the graphite branch to trunk,
> and this should be fixed then.
Running test.f using trunk -r154872 on powerpc64-su
The following program (to be run through gnatchop) is supposed
to exit with status 17. It exits with status 0 instead. Inspecting
the generated machine code reveals that the call to Close is
not emitted:
<_ada_u>:
0: 55 push %rbp
1: 48 89 e5
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-12-01 14:09 ---
You seem to have outdated graphite build requirements so it wasn't compiled in.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41498
--- Comment #6 from jamborm at gcc dot gnu dot org 2009-12-01 14:10 ---
Created an attachment (id=19197)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19197&action=view)
Simple testcase
A simple test case that exhibits this bug and ICEs on both i386 and x86_64.
--
http://gcc.
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-01 14:13 ---
On trunk I see
_ada_u:
.LFB1:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
movq%rsp, %rbp
.cfi_offset 6, -16
.cfi_def_cfa_register 6
movl$17, %ed
--- Comment #6 from dominiq at lps dot ens dot fr 2009-12-01 14:23 ---
It seems to be fixed by the commits in comments #4 and #5. Closing since it
seems unlikely that the fix will be backported to 4.3.
--
dominiq at lps dot ens dot fr changed:
What|Removed
--- Comment #7 from jamborm at gcc dot gnu dot org 2009-12-01 14:47 ---
Created an attachment (id=19198)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19198&action=view)
Patch dealing with such assignments
I'm currently testing this patch to address the problem.
--
http://gc
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-12-01 15:00 ---
Ok if it passes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42237
--- Comment #10 from arjen dot verweij at tass-safe dot com 2009-12-01
15:10 ---
Hi,
Is there any discussion going on still about this? We are getting rid of all of
our UNIX workstations and moving to Linux. Incorporating the patch as an
optional switch or similar would be nice.
Thank
--- Comment #28 from ghazi at gcc dot gnu dot org 2009-12-01 15:14 ---
Backport to 4.4? Or close this and PR41501?
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #11 from rmansfield at qnx dot com 2009-12-01 15:16 ---
I can still reproduce it using a arm-unknown-linux-gnueabi target. 20091201
(experimental) [trunk revision 154872])
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41491
--- Comment #29 from rguenth at gcc dot gnu dot org 2009-12-01 15:16
---
The CFI stuff isn't on the 4.4 branch, so WONTFIX there.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-12-01 15:17 ---
Too big for backporting (and not a regression?).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from dominiq at lps dot ens dot fr 2009-12-01 15:19 ---
The patch in comment #3 allows the test in comment #0 to be compiled and run
(though I don't know if the executable is valid). However there are still
errors at link time for the test in comment #1.
--
http://gcc
--- Comment #5 from bernds_cb1 at t-online dot de 2009-12-01 15:26 ---
Code generation changes are expected for two reasons - the code became less
conservative when determining conflicts with other registers, so we can usually
rename in more cases. There are also a few cases where we ha
--- Comment #6 from rguenther at suse dot de 2009-12-01 15:35 ---
Subject: Re: [4.5 Regression] rev 15458[78]
regress 464.h264ref peak 20%
On Tue, 1 Dec 2009, bernds_cb1 at t-online dot de wrote:
> --- Comment #5 from bernds_cb1 at t-online dot de 2009-12-01 15:26
> ---
> C
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-12-01 16:17
---
I can reproduce it with a x86_64 -> arm-unknown-linux-gnueabi cross, so I'll
look into this.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
Hello!
Following code is Producing an infinit loop, so main() is never reached
extern int main(void);
int main(void){
while(1);
}
#include
/*Seed aus SRAM Zellen*/
static uint16_t seedram __attribute__ ((section (".noinit")));
void __init_seed(void) __attribute__ ((naked, section (".init
--- Comment #1 from stefan dot dreyer at yahoo dot de 2009-12-01 16:19
---
Created an attachment (id=19199)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19199&action=view)
Compileable testfile
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42240
--- Comment #14 from burnus at gcc dot gnu dot org 2009-12-01 16:21 ---
Some further notes based on the discussion with Kai:
ftruncate: Replace by a configure check for "ftruncate64" and a fallback using
first "SetFilePointer" and then "SetEndOfFile(_get_osfhandle(fd))". Note: The
funct
--- Comment #2 from stefan dot dreyer at yahoo dot de 2009-12-01 16:44
---
Created an attachment (id=19200)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19200&action=view)
Compileable testfile
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42240
--- Comment #3 from stefan dot dreyer at yahoo dot de 2009-12-01 16:44
---
Created an attachment (id=19201)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19201&action=view)
generatet assambly file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42240
--- Comment #4 from stefan dot dreyer at yahoo dot de 2009-12-01 16:46
---
(From update of attachment 19201)
in
/* epilogue start */
rjmp .L6
infinite, never leaves function
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42240
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-12-01 16:46 ---
Just reverting rev. 154688 and using the training set gets us from
464.h264ref--228 -- S
to
464.h264ref--170 -- S
at -O3 -ffast-ma
--- Comment #7 from dje at gcc dot gnu dot org 2009-12-01 16:52 ---
The changes are not available in any version and the changes are not complete.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35484
--- Comment #5 from j at uriah dot heep dot sax dot de 2009-12-01 16:58
---
My first analysis shows that this is likely to be related to the
introduction of RTL prologues/epilogues in GCC 4.3. GCC 4.2.2
has:
if (avr_naked_function_p (current_function_decl))
{
fputs ("/* ep
The following code compiles but the linker balks at the use of one of the class
variables used within a conditional expression:
// simple.cpp
class BiState
{
int state;
public:
static const int OFF = 0,
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-12-01 17:03 ---
The hot loop is mv-search.c:SetupFastFullPelSearch
for (pos = 0; pos < max_pos; pos++)
{
abs_y = offset_y + spiral_search_y[pos];
abs_x = offset_x + spiral_search_x[pos];
if (range_partly_outside)
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-12-01 17:07 ---
You only have a declaration of BiState:: OFF and BiState::ON, you need to
definite it also.
*** This bug has been marked as a duplicate of 42101 ***
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #9 from pinskia at gcc dot gnu dot org 2009-12-01 17:07 ---
*** Bug 42241 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #15 from burnus at gcc dot gnu dot org 2009-12-01 17:08 ---
Regarding the ftruncate(64) fall back: one should check that it doesn't operate
on none character devices (isatty) and set errno to something like EBADF.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40812
--- Comment #9 from bernds_cb1 at t-online dot de 2009-12-01 17:25 ---
Created an attachment (id=19202)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19202&action=view)
Test patch to attempt to narrow down the problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42216
--- Comment #10 from bernds_cb1 at t-online dot de 2009-12-01 17:27 ---
Yes, regrename should only affect the second scheduling pass.
I'm attaching a stab-in-the-dark patch. It contains a fix for the ia64
regressions (testing in progress), it adds a few warnings which could be useful
t
--- Comment #18 from dominiq at lps dot ens dot fr 2009-12-01 17:28 ---
At revision 154851 and later the failures have disappeared (tested on
x86_64-apple-darwin10 and i686-apple-darwin9). Before I close the PR as fixed,
does anybody has an explanation for the failures and their fix?
-
--- Comment #9 from jamborm at gcc dot gnu dot org 2009-12-01 17:40 ---
Subject: Bug 42237
Author: jamborm
Date: Tue Dec 1 17:39:44 2009
New Revision: 154874
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154874
Log:
2009-12-01 Martin Jambor
PR tree-optimization/422
--- Comment #10 from jamborm at gcc dot gnu dot org 2009-12-01 17:49
---
Fixed.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--
jb at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jb at gcc dot gnu dot org
|dot org |
This code shows that the resize member function is calling the null constructor
even when the size does not need to be changed.
#include
#include
class c {
public:
c() { std::cerr << "c null constructor called\n"; }
c(int i) : i(i) {}
int i;
};
int main
--- Comment #1 from redi at gcc dot gnu dot org 2009-12-01 18:21 ---
this is caused by the default argument to resize:
void
resize(size_type __new_size, value_type __x = value_type());
It would be possible to avoid the default construction by replacing that member
with two overloads o
--- Comment #2 from ramana at gcc dot gnu dot org 2009-12-01 18:26 ---
(In reply to comment #0)
> Compile the attached source code with options -Os -fpic -mthumb, gcc generates
> following code for the constructor:
Could you do some more analysis of where this is coming from using rtl /
--- Comment #2 from redi at gcc dot gnu dot org 2009-12-01 18:30 ---
On second thoughts, it might be necessary to split it into two overloads for
C++1x, because this should work:
#include
struct moveable {
explicit moveable(int) { }
moveable(const moveable&) = delete;
move
--- Comment #27 from jb at gcc dot gnu dot org 2009-12-01 18:32 ---
Subject: Bug 42131
Author: jb
Date: Tue Dec 1 18:32:37 2009
New Revision: 154876
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154876
Log:
PR fortran/42131 Sign test using ternary operator
Modified:
trunk
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-12-01 18:33 ---
(In reply to comment #1)
> It would be possible to avoid the default construction by replacing that
> member
> with two overloads of resize, but I'm not sure it's worth doing.
The C++03 standard only lists the fun
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-12-01 18:34 ---
(In reply to comment #2)
> On second thoughts, it might be necessary to split it into two overloads for
> C++1x, because this should work:
But std::vector::resize (size_type sz, T c = T()); is the only one listed at
--- Comment #5 from redi at gcc dot gnu dot org 2009-12-01 18:37 ---
(In reply to comment #2)
> On second thoughts, it might be necessary to split it into two overloads for
> C++1x, because this should work:
Gah, ignore that, I'm talking rubbish and that shouldn't work
Andrew, the stan
--- Comment #16 from jb at gcc dot gnu dot org 2009-12-01 18:39 ---
Patch
--
jb at gcc dot gnu dot org changed:
What|Removed |Added
URL|
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-12-01 18:40 ---
(In reply to comment #5)
> (In reply to comment #2)
> > On second thoughts, it might be necessary to split it into two overloads for
> > C++1x, because this should work:
>
> Gah, ignore that, I'm talking rubbish and
Bootstrap on powerpc-apple-darwin9 at revision 154872 is broken:
...
libtool: compile: /opt/gcc/darwin_buildw/./gcc/xgcc
-B/opt/gcc/darwin_buildw/./gcc/ -B/opt/gcc/gcc4.5w/powerpc-apple-darwin9/bin/
-B/opt/gcc/gcc4.5w/powerpc-apple-darwin9/lib/ -isystem
/opt/gcc/gcc4.5w/powerpc-apple-darwin9/incl
--- Comment #7 from redi at gcc dot gnu dot org 2009-12-01 18:54 ---
Yes, it would be an ABI change, although that symbol isn't exported from the
library.
vector::resize() was changed from one function to two in the n2284 draft, as a
result of n1858, the rationale is the same as for deq
--- Comment #17 from jb at gcc dot gnu dot org 2009-12-01 18:58 ---
Updated patch: http://gcc.gnu.org/ml/fortran/2009-12/msg00017.html
--
jb at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #8 from chris at bubblescope dot net 2009-12-01 19:01 ---
The only change in C++0x is that a new function is added, so it won't break any
existing code, and we will be able to add it without moving to v7.
--
chris at bubblescope dot net changed:
What|Remov
--- Comment #9 from igodard at pacbell dot net 2009-12-01 19:02 ---
FWIW, I think it is a design error in the standard. The resize function seems
to be designed from an assumption that the vector type T is POD. The second
argument should not be a T, it should be a constructor, so any add
--- Comment #10 from chris at bubblescope dot net 2009-12-01 19:07 ---
Anyway, the result of this bug is that the fix to resize() given in the latest
draft of C++0x should be applied. The resulting code would only be invoked if
you ask the compiler to use C++0x mode, but if care about pe
--- Comment #6 from a dot kaiser at gmx dot net 2009-12-01 19:21 ---
Same for ARM target, when compiled for Thumb instruction set (-fthumb).
--
a dot kaiser at gmx dot net changed:
What|Removed |Added
---
--- Comment #11 from igodard at pacbell dot net 2009-12-01 19:26 ---
Subject: Re: vector::resize could be split up into two
different functions
We await r-value references with baited breath :-)
chris at bubblescope dot net wrote:
> --- Comment #10 from chris at bubblescope dot n
--- Comment #12 from chris at bubblescope dot net 2009-12-01 19:28 ---
No need to wait, they are in g++ 4.3 and 4.4, use -std=c++0x to activate
features from C++0x. Obviously they are all subject to change, but are now
fairly close to standardised.
--
http://gcc.gnu.org/bugzilla/sho
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-12-01 19:31 ---
:
# a_1 = PHI
a_3 = a_1;
goto ;
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-12-01 19:32 ---
0xa5a5a5a5a5a5a5d5 is a GC'd address.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-12-01 19:37 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #7 from a dot kaiser at gmx dot net 2009-12-01 19:37 ---
Confirmed for 4.4.2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42240
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42199
--- Comment #2 from jakub at gcc dot gnu dot org 2009-12-01 19:42 ---
Subject: Bug 42234
Author: jakub
Date: Tue Dec 1 19:41:52 2009
New Revision: 154878
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154878
Log:
PR c++/42234
* tree-cfgcleanup.c (cleanup_omp_ret
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Summary|ICE when SRAing partial |[4.
--- Comment #3 from jakub at gcc dot gnu dot org 2009-12-01 19:44 ---
Subject: Bug 42234
Author: jakub
Date: Tue Dec 1 19:44:34 2009
New Revision: 154879
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154879
Log:
PR c++/42234
* tree-cfgcleanup.c (cleanup_omp_ret
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Summary|Segmentation fault with |[4.
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-12-01 19:47 ---
Confirmed a generic issue.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
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
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Summary|gcc.dg/graphite/interchange-|[4.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Summary|verify_cgraph_node failed |[4.
--- Comment #1 from dominiq at lps dot ens dot fr 2009-12-01 19:57 ---
I have no idea if this the right fix, but the following patch allows bootstrap
to proceed:
--- ../_gcc_clean/libffi/src/powerpc/ffi_darwin.c 2009-12-01
13:16:43.0 +0100
+++ ../gcc-4.5-work/libffi/src/po
--- Comment #36 from jakub at gcc dot gnu dot org 2009-12-01 20:09 ---
Subject: Bug 3187
Author: jakub
Date: Tue Dec 1 20:09:37 2009
New Revision: 154880
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154880
Log:
PR c++/3187
* optimize.c (cdtor_comdat_group): Ne
--
daney at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42164
--- Comment #9 from jason at gcc dot gnu dot org 2009-12-01 21:58 ---
Subject: Bug 41611
Author: jason
Date: Tue Dec 1 21:58:04 2009
New Revision: 154885
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154885
Log:
PR c++/41611
* decl2.c (get_guard): Copy DECL_COM
--- Comment #19 from howarth at nitro dot med dot uc dot edu 2009-12-01
22:06 ---
What was the last revision exhibiting this problem? I suspect it was either
accidentally fixed or went latent. It would be worthwhile to pin down the exact
revision that eliminated these failures so a gue
--- Comment #5 from janus at gcc dot gnu dot org 2009-12-01 22:09 ---
Btw: The example in comment #1 is affected by PR41829, which can be avoided by
moving the subroutine 'rescale' to the main program. However, this still fails
(also with the patch from comment #3):
module foo_module
i
--- Comment #8 from a dot kaiser at gmx dot net 2009-12-01 22:50 ---
For the ARM target, falling off the end of the function does not make sense
anyway, since the last byte usually is followed by the constant pool. So the
AVR target finally caught up with the ARM target and doesn't work
GCC trunk gets an internal compiler error when building SPEC CPU2000 test
300.twolf with "-O2 -g -ffloat-store -fmodulo-sched" on powerpc-linux, as
demonstrated by this minimized testcase:
extern int numerator, denom;
double
compute_and_combination (double states)
{
for (; numerator >
--- Comment #20 from dominiq at lps dot ens dot fr 2009-12-01 23:20 ---
The last revision for which I saw the failures is revision 154715.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41988
1 - 100 of 125 matches
Mail list logo
