--- Comment #13 from jvdelisle at gcc dot gnu dot org 2010-03-22 02:41
---
I will back port all of this business to 4.4 in a few days. Dominique, please
confirm this fixes it on your machine and I thank you very much for the report.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2010-03-22 02:39
---
Subject: Bug 43409
Author: jvdelisle
Date: Mon Mar 22 02:39:02 2010
New Revision: 157618
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157618
Log:
2010-03-21 Jerry DeLisle
PR fortran/43409
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2010-03-22 02:03
---
Found it:
Index: io.h
===
--- io.h(revision 157617)
+++ io.h(working copy)
@@ -331,7 +331,7 @@
CHARACTER2 (round);
CHARACTER1
--- Comment #10 from mckelvey at maskull dot com 2010-03-22 02:00 ---
OK I've been busy. I've replaced the old computer with a Windows 7 box, and
reinstalled cygwin from scratch. I get the same thing:
checking for i686-pc-cygwin-gcc... /cygdrive/j/Home/cvsroot/gcc-obj/./gcc/xgcc
-B/cygd
--- Comment #6 from danglin at gcc dot gnu dot org 2010-03-22 01:29 ---
Failure is avoided in back-end but middle-end problem remains.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42718
--- Comment #12 from spop at gcc dot gnu dot org 2010-03-22 01:29 ---
Subject: Bug 43464
Author: spop
Date: Mon Mar 22 01:28:51 2010
New Revision: 157617
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157617
Log:
Fix PR43464: loop close phi nodes can contain more than one argume
--- Comment #5 from danglin at gcc dot gnu dot org 2010-03-22 01:05 ---
Subject: Bug 42718
Author: danglin
Date: Mon Mar 22 01:05:19 2010
New Revision: 157616
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157616
Log:
PR middle-end/42718
* pa.md (movmemsi): Set a
--- Comment #4 from danglin at gcc dot gnu dot org 2010-03-22 01:03 ---
Subject: Bug 42718
Author: danglin
Date: Mon Mar 22 01:02:42 2010
New Revision: 157615
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157615
Log:
PR middle-end/42718
* pa.md (movmemsi): Set a
--- Comment #3 from danglin at gcc dot gnu dot org 2010-03-22 01:00 ---
Subject: Bug 42718
Author: danglin
Date: Mon Mar 22 01:00:30 2010
New Revision: 157614
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157614
Log:
PR middle-end/42718
* pa.md (movmemsi): Set a
--- Comment #6 from aflyhorse at foxmail dot com 2010-03-22 01:00 ---
In my recent build
I configured the binutils as:
../src/configure --target=x86_64-w64-mingw32
--enable-targets=x86_64-w64-mingw32,i686-w64-mingw32 --disable-shared
--enable-static --disable-nls --with-mpc=/local --with
--- Comment #2 from rearnsha at gcc dot gnu dot org 2010-03-22 00:51
---
Confirmed. Uxtb is better because for low regs it's only 16-bits.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #11 from spop at gcc dot gnu dot org 2010-03-22 00:26 ---
I would still like to see some extra checking after copyprop:
would this extra check be ok to commit with the fix?
diff --git a/gcc/tree-ssa-copy.c b/gcc/tree-ssa-copy.c
index 61e32cc..011a80a 100644
--- a/gcc/tree-ss
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2010-03-22 00:19
---
> "Between the previous and next sequence point an object shall have its stored
> value modified at most once by the evaluation of an expression.
> Furthermore, the prior value shall be read only to determine the v
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2010-03-22 00:18
---
More precisely, C99 6.5 §2 reads:
"Between the previous and next sequence point an object shall have its stored
value modified at most once by the evaluation of an expression.
Furthermore, the prior value shall be
--- Comment #10 from spop at gcc dot gnu dot org 2010-03-22 00:17 ---
Yes, this patch does fix the problem.
diff --git a/gcc/tree-ssa-copy.c b/gcc/tree-ssa-copy.c
index 57c6558..61e32cc 100644
--- a/gcc/tree-ssa-copy.c
+++ b/gcc/tree-ssa-copy.c
@@ -797,7 +797,6 @@ init_copy_prop (void)
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-22 00:09 ---
We don't warn about this but you are missing a sequence point between the
modifications of *pa (and also *pb).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
gcc 4.4.1 and 4.2.4 failed to generate the correct code under -O0; gcc 3.4.6
works fine.
---BEGIN code ---
#include
int main( )
{
int a, b;
a = 1;
b = 2;
register int *pa = &a;
register int *pb = &b;
/* Swap a and b using pointers pa and pb */
*pa ^= *pb ^= *pa ^= *
--- Comment #5 from nightstrike at gmail dot com 2010-03-21 23:35 ---
(In reply to comment #4)
> > Looks like we need a new variable for build includes
>
> I think, too. I've built successful with my patch. (I don't send my patch
> because it is half-finished.)
>
Have you finished you
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-03-21 23:07 ---
(In reply to comment #8)
> (In reply to comment #7)
> > The problem is that copyprop does this change:
> >
> > @@ -25,7 +25,7 @@
> >:
> > # .MEM_16 = PHI <.MEM_18(10), .MEM_20(11)>
> > # s_66 = PHI
>
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-03-21 23:05 ---
(In reply to comment #7)
> The problem is that copyprop does this change:
>
> @@ -25,7 +25,7 @@
>:
> # .MEM_16 = PHI <.MEM_18(10), .MEM_20(11)>
> # s_66 = PHI
> -s_13 = s_66;
> +s_13 = s_1;
>
--- Comment #19 from pinskia at gcc dot gnu dot org 2010-03-21 23:03
---
*** Bug 43470 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-03-21 23:03 ---
*** This bug has been marked as a duplicate of 39254 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-03-21 23:01 ---
Confirmed. Looks like a dup of PR43415.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from kkojima at gcc dot gnu dot org 2010-03-21 22:32 ---
Fixed.
--
kkojima at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #5 from kkojima at gcc dot gnu dot org 2010-03-21 22:29 ---
Subject: Bug 43417
Author: kkojima
Date: Sun Mar 21 22:29:19 2010
New Revision: 157610
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157610
Log:
Backport from mainline:
2009-05-12 Paolo Bon
--- Comment #3 from mikpe at it dot uu dot se 2010-03-21 20:56 ---
This is fixed by the patch for PR39254, which sadly never got applied to
upstream 4.4 branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43470
unsigned short a;
unsigned b;
#define d 0xC000
void ma()
{
unsigned short u = (d >> 1) & 0x;
a = (a & ~u) | d;
}
void mb()
{
unsigned short u = (d >> 1) & 0x;
b = (b & ~u) | d;
}
generates:
ma:
ldr r3, .L2
ldrhr2, [r3, #0]
--- Comment #8 from rearnsha at gcc dot gnu dot org 2010-03-21 20:30
---
Fixed in trunk
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #7 from rearnsha at gcc dot gnu dot org 2010-03-21 20:27
---
Subject: Bug 42321
Author: rearnsha
Date: Sun Mar 21 20:27:00 2010
New Revision: 157609
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157609
Log:
PR target/42321
* arm.c (arm_output_epilog
--- Comment #1 from manu at gcc dot gnu dot org 2010-03-21 20:23 ---
I cannot reproduce this in GCC 4.5, so probably it got fixed. Thanks for the
report.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from edwintorok at gmail dot com 2010-03-21 20:11 ---
Created an attachment (id=20155)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20155&action=view)
whetstone.cbe.c
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43472
--- Comment #2 from slyfox at inbox dot ru 2010-03-21 20:11 ---
Created an attachment (id=20154)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20154&action=view)
valgrind.log - sheds some light on SIGSEGV reason
...
==10526== Invalid write of size 8
==10526==at 0x105DC344: sch
gcc -O2 works on this file:
gcc whetstone.cbe.c -lm -O2 -fno-strict-aliasing -fno-inline -m64
-fomit-frame-pointer
gcc -O3 exhausts memory:
gcc whetstone.cbe.c -lm -O3 -fno-strict-aliasing -fno-inline -m64
-fomit-frame-pointer
virtual memory exhausted: Cannot allocate memory
$ gcc -v
Using buil
--- Comment #1 from slyfox at inbox dot ru 2010-03-21 20:09 ---
Created an attachment (id=20153)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20153&action=view)
ghc30321_0.i - preprocessed offending file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43470
code:
register int *p asm("r4");
void a()
{
asm volatile("" : "+m" (*p));
}
generates:
[...]
mov r3, r4
[...]
when it should generate no move as the address register won't be modified
inside asm().
Similar bugs: #40680, #34283, #13355.
(gcc 4.5 from svn 157582)
--
Tried to build one of itermediate ghc(glasgow haskell compiler) files and got
SIGSEGV:
gcc-4.4.3 -x c ghc30321_0.i -S -fno-strict-aliasing -O2 -o a.s
Yes, it's a gentoo patched gcc, but I'll check vanilla gcc-svn in shortest
time.
(bug is reproducible on gcc-4.3.3 as well)
/tmp/ghc30321_0/ghc3032
--- Comment #4 from laurent at guerby dot net 2010-03-21 19:56 ---
Summary work/fail.
--
laurent at guerby dot net changed:
What|Removed |Added
CC|
--- Comment #14 from davek at gcc dot gnu dot org 2010-03-21 19:42 ---
And another one bites the dust.
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from davek at gcc dot gnu dot org 2010-03-21 19:41 ---
Subject: Bug 42811
Author: davek
Date: Sun Mar 21 19:41:37 2010
New Revision: 157606
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157606
Log:
PR target/42811
* libjava/configure.ac (DLLTOOL)
--- Comment #12 from davek at gcc dot gnu dot org 2010-03-21 19:37 ---
Subject: Bug 42811
Author: davek
Date: Sun Mar 21 19:36:49 2010
New Revision: 157605
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157605
Log:
PR target/42811 (prerequisite)
* jvmti.cc (_Jv_G
--- Comment #11 from davek at gcc dot gnu dot org 2010-03-21 19:34 ---
Subject: Bug 42811
Author: davek
Date: Sun Mar 21 19:34:19 2010
New Revision: 157604
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157604
Log:
PR target/42811 (prerequisite)
* include/private
--- Comment #10 from davek at gcc dot gnu dot org 2010-03-21 19:25 ---
Recategorising; "target" narrowly wins out over "libjava". Patch was approved
at http://gcc.gnu.org/ml/java-patches/2010-q1/msg00062.html
--
davek at gcc dot gnu dot org changed:
What|Removed
--- Comment #10 from paolo dot carlini at oracle dot com 2010-03-21 19:15
---
*** Bug 43468 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43259
--- Comment #1 from paolo dot carlini at oracle dot com 2010-03-21 19:15
---
*** This bug has been marked as a duplicate of 43259 ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #2 from siarhei dot siamashka at gmail dot com 2010-03-21
19:07 ---
works fine with gcc 4.4.3
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43469
--- Comment #1 from siarhei dot siamashka at gmail dot com 2010-03-21
19:05 ---
Created an attachment (id=20152)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20152&action=view)
localealias.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43469
= the exact version of GCC
Freshly checked out SVN trunk for gcc 4.5.0 (r157602)
= the options given when GCC was configured/built;
--target=armv7a-unknown-linux-gnueabi --enable-languages=c --without-headers
= the complete command line that triggers the bug;
armv7a-unk
--- Comment #4 from steven at gcc dot gnu dot org 2010-03-21 19:04 ---
Development branches have extra checking enabled, and it's always been like
that. If you compile with -ftime-report, the compiler warns if the extra
checking is enabled, and that's quite enough.
--
steven at gcc d
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-03-21 19:02 ---
Combine bug (PR 39959) is a different issue from the matrix testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42149
spawn /home/dave/gnu/gcc/objdir/./gcc/g++ -shared-libgcc
-B/home/dave/gnu/gcc/ob
jdir/./gcc -nostdinc++ -L/home/dave/gnu/gcc/objdir/hppa-linux/libstdc++-v3/src
-
L/home/dave/gnu/gcc/objdir/hppa-linux/libstdc++-v3/src/.libs
-B/home/dave/opt/gn
u/gcc/gcc-4.5.0/hppa-linux/bin/
-B/home/dave/opt/gnu/gcc
--- Comment #1 from mirq-gccboogs at rere dot qmqm dot pl 2010-03-21 18:44
---
[looks like bug #39959]
The same happens with -combine on following code (arm-none-eabi target):
a.h:
struct a {
int b;
int c;
};
extern struct a *p asm("r4");
void d(int *);
b.c:
#incl
=c,c++,fortran,objc,obj-c++,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw
--with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--disable-libjava-multilib --enable-checking=release
Thread model: posix
gcc version 4.5.0 2010
--- Comment #5 from d dot g dot gorbachev at gmail dot com 2010-03-21
18:00 ---
My GCC (4.4 and 4.5) were configured with the following options:
`--build=mingw32 --enable-languages=c,c++
--enable-version-specific-runtime-libs --disable-win32-registry --disable-nls
--disable-shared'. I m
--- Comment #1 from d dot g dot gorbachev at gmail dot com 2010-03-21
17:25 ---
Created an attachment (id=20151)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20151&action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43467
--
Summary: LTO error "bytecode stream: trying to read 0 bytes after
the end of the input buffer"
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
As
--- Comment #7 from spop at gcc dot gnu dot org 2010-03-21 17:17 ---
The problem is that copyprop does this change:
@@ -25,7 +25,7 @@
:
# .MEM_16 = PHI <.MEM_18(10), .MEM_20(11)>
# s_66 = PHI
-s_13 = s_66;
+s_13 = s_1;
goto (got_it);
}
then verify_loop_c
--- Comment #6 from spop at gcc dot gnu dot org 2010-03-21 17:01 ---
Further reduced testcase:
typedef struct regnode
{
char flags;
} regnode;
extern const unsigned char A[];
char *foo (regnode *c, char *s, int norun)
{
int uskip;
while (s + (uskip = A[*s]))
{
if ((c->f
--- Comment #47 from mmitchel at gcc dot gnu dot org 2010-03-21 16:47
---
Closed at request of submitter.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #26 from sebpop at gmail dot com 2010-03-21 16:28 ---
Subject: Re: [4.5 Regression][graphite]
-fgraphite-identity miscompiles air.f90
On Sat, Mar 20, 2010 at 05:45, dominiq at lps dot ens dot fr wrote:
> Do you understand why graphite does not detect that the loop
On Sat, Mar 20, 2010 at 05:45, dominiq at lps dot ens dot fr wrote:
> Do you understand why graphite does not detect that the loop for [scat_1+1,
> T_10-2] depends on the one for [0, scat_1-1]?
Graphite does know this, but it does not ask CLooG to generate
[0, scat_1-1] after [scat_1+1, T_10-2],
--- Comment #7 from hjl dot tools at gmail dot com 2010-03-21 16:20 ---
(In reply to comment #6)
> Shouldn't there be a PR about the suboptimal performance from the core2 tuning
> (in hopes that original contributors from Intel will revisit these issues)?
>
Intel didn't contribute -mar
--- Comment #5 from sebpop at gmail dot com 2010-03-21 16:08 ---
Subject: Re: copy prop breaks loop closed SSA form
On Sun, Mar 21, 2010 at 04:54, steven at gcc dot gnu dot org
wrote:
> Why such a big hammer?
'cause I don't want to add more bugs,
and no I don't think compile time mat
--- Comment #6 from rearnsha at gcc dot gnu dot org 2010-03-21 15:58
---
testing fix
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|u
--- Comment #4 from nightstrike at gmail dot com 2010-03-21 14:56 ---
(In reply to comment #3)
> (In reply to comment #1)
> > This is probably due to the way you built GCC. To have a completely
> > relocatable toolchain, you need to use the --with-sysroot option to
> > configure,
> I'v
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2010-03-21
14:44 ---
Shouldn't there be a PR about the suboptimal performance from the core2 tuning
(in hopes that original contributors from Intel will revisit these issues)?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
=/usr/X11R6/lib
--disable-libjava-multilib
Thread model: posix
gcc version 4.5.0 20100321 (experimental) (GCC)
Using built-in specs.
Target: x86_64-apple-darwin10.3.0
Configured with: ../gcc-4.4.4/configure --prefix=/sw --prefix=/sw/lib/gcc4.4
--mandir=/sw/share/man --infodir=/sw/share/info
--enable
--- Comment #9 from steven at gcc dot gnu dot org 2010-03-21 14:35 ---
Still needs to be applied to GCC 4.4.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from jakub at gcc dot gnu dot org 2010-03-21 14:16 ---
I think there are two problems in reorder_blocks{,_1}:
1) BLOCK_FRAGMENT_CHAIN should be reversed on each block when reorder_blocks_1
finishes, otherwise the chain starts with the earliest fragment
(BLOCK_FRAGMEN
--- Comment #46 from dave at hiauly1 dot hia dot nrc dot ca 2010-03-21
14:03 ---
Subject: Re: [4.3/4.4/4.5 Regression] Undefined symbol: vtable for
__cxxabiv1::__vmi_class_type_info
> Can anyone reconfirm this bug for GCC 4.4 and/or GCC 4.5?
I think this bug should be closed. While
~/gcc/trunk/gcc/tmp/gcc$ ./xgcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --disable-bootstrap --enable-languages=c
Thread model: posix
gcc version 4.5.0 20100321 (experimental) [trunk revision 157602] (GCC)
~/gcc/trunk/gcc/tmp/gcc$ cat ~/ice.i
#pragma GCC
--- Comment #9 from ramana at gcc dot gnu dot org 2010-03-21 13:41 ---
(In reply to comment #8)
> What about just forbidding to use "q" registers in the inline assembly clobber
> list? Is it difficult to do?
>
It's not difficult to -
The patch only penalises the cases where an s ends
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2010-03-21 13:31
---
Dominiq, can you test the FSTAT intrinsic while you are at it? With the same
file I wonder if it gives the same results.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43409
--- Comment #6 from jakub at gcc dot gnu dot org 2010-03-21 13:26 ---
Found a problem - the patch relies on the fact that the fragments of each block
are sorted in ascending order of their PCs, but apparently that is not the
case. So how much the patch will actually save on .debug_loc si
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P5 |P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19192
--- Comment #10 from steven at gcc dot gnu dot org 2010-03-21 12:22 ---
With all attention going out to debug info in GCC 4.5, and with TER
more-or-less rewritten for GCC 4.5 -- perhaps re-evaluate this bug's priority?
--
steven at gcc dot gnu dot org changed:
What|Re
--- Comment #5 from steven at gcc dot gnu dot org 2010-03-21 12:20 ---
Bug in WAITING for a long time, no feedback. Very small, hard-to-catch code
difference. It's been noted before that the core2 scheduler description
(contributed by Intel itself!) often results in worse code than the g
--- Comment #16 from steven at gcc dot gnu dot org 2010-03-21 12:16 ---
Known to work in 4.4.0 so not a "4.4/4.5 Regression" anymore.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #45 from steven at gcc dot gnu dot org 2010-03-21 12:14 ---
Mark, I'm assuming you have no plans to work on this? If so, please unassign
yourself from this bug.
Can anyone reconfirm this bug for GCC 4.4 and/or GCC 4.5?
--
steven at gcc dot gnu dot org changed:
--- Comment #50 from steven at gcc dot gnu dot org 2010-03-21 12:13 ---
Performance loss within acceptable limits (by the "you give some, you take
some" principle). GCC 4.5 optimizes the test case away completely. I see no
reason to do anything more here. Fixed for GCC 4.5 and GCC 4.4. W
--- Comment #6 from steven at gcc dot gnu dot org 2010-03-21 12:09 ---
I believe this should be fixed for GCC 4.5. Setting to P3 to ask release
managers for their opinion.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #19 from steven at gcc dot gnu dot org 2010-03-21 12:03 ---
Cause here is better register allocation and lack of cross-jumping before
register allocation. This will not be fixed. For GCC 4.6 we should add a
cross-jumping patch (an improved version if this pass, anyway) before
--- Comment #9 from paolo dot carlini at oracle dot com 2010-03-21 11:13
---
Excellent, Silvius. Note, I'm not 100% sure about possible deadlines for 4.5.0:
I think the second week of April will be still ok, but I would suggest keeping
an eye to the gcc list and be prepared to move earl
--- Comment #1 from oschmidt_do_not_send_email_to_this_address at gmx dot
de 2010-03-21 10:10 ---
Created an attachment (id=20150)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20150&action=view)
testcode and compiler invocation scripts
--
http://gcc.gnu.org/bugzilla/show_bug
Hi,
if a private static method is passed as a template argument, the visibility
depends whether pointer syntax is used or not.
A simple example (more complex ones in attachment):
// ==
#include
typedef int F(int i);
template class Class1
{
--- Comment #8 from siarhei dot siamashka at gmail dot com 2010-03-21
10:05 ---
What about just forbidding to use "q" registers in the inline assembly clobber
list? Is it difficult to do?
As a nice bonus, the existing potentially unsafe inline assembly will fail to
compile, will be spo
--- Comment #1 from steven at gcc dot gnu dot org 2010-03-21 09:57 ---
How did you configure the compilers? (Think --enable-checking=release, etc.)
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from steven at gcc dot gnu dot org 2010-03-21 09:54 ---
Why such a big hammer? You should be able to figure out which copy props are
allowed and which should be disallowed in loop-closed SSA form.
Is "if (current_loops)" the right test here? This will break if Zdenek's
pa
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywo
--- Comment #7 from ramana at gcc dot gnu dot org 2010-03-21 09:23 ---
(In reply to comment #5)
> The proper solution seems to be extremely simple to me and it should do
> exactly
> the same what an application programmer would do to workaround the bug. Just
> when initially parsing cl
--- Comment #4 from carrot at google dot com 2010-03-21 09:18 ---
It is for thumb1, there should be another parameter that I missed
-march=armv5te. It still exists in today's trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42495
--- Comment #9 from dominiq at lps dot ens dot fr 2010-03-21 08:58 ---
The test fails gfortran.dg/inquire_size.f90 on powerpc-apple-darwin9 (see
http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg01801.html). The failures are
due to bad values of size, as shown by the following output of t
--- Comment #3 from andriys at gmail dot com 2010-03-21 08:15 ---
(In reply to comment #1)
> This is probably due to the way you built GCC. To have a completely
> relocatable toolchain, you need to use the --with-sysroot option to configure,
I've just checked out the latest sources from
--- Comment #3 from spop at gcc dot gnu dot org 2010-03-21 07:32 ---
Subject: Bug 43464
Author: spop
Date: Sun Mar 21 07:32:43 2010
New Revision: 157602
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157602
Log:
Fix PR43464: update loop close SSA once copy prop is done.
2010-03
--- Comment #2 from spop at gcc dot gnu dot org 2010-03-21 07:06 ---
Created an attachment (id=20149)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20149&action=view)
proposed fix
The proposed fix is to recompute the loop closed SSA form after copy
propagation.
--
http://gcc.
--- Comment #1 from spop at gcc dot gnu dot org 2010-03-21 07:01 ---
Created an attachment (id=20148)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20148&action=view)
pr43464.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43464
When copy propagation is called from the loop optimizer, copy prop
does not update the loop closed SSA form, and we end up on a
representation that crashes on verify_loop_closed_ssa ().
This bug appeared on the Graphite branch with -O3 on the attached
testcase reduced from perlbench.
Note that th
96 matches
Mail list logo
