/*/
x = cfun-machine-force_align_arg_pointer;
x = gen_frame_mem (Pmode, plus_constant (x, -8)) xor hard_frame_pointer_rtx;
insn = emit_insn (gen_push (x));
RTX_FRAME_RELATED_P (insn) = 1;
On Sun, Mar 21, 2010 at 3:43 AM, Jim Wilson wil...@codesourcery.com wrote:
On Sun, 2010-03-21 at 03:40 +0800, fanqifei wrote:
foor_expand_move is changed and it works now.
However, I still don't understand why there was no such error if below
condition was used and foor_expand_move was not
Snapshot gcc-4.3-20100321 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20100321/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
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
--- 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=20148action=view)
pr43464.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43464
--- 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=20149action=view)
proposed fix
The proposed fix is to recompute the loop closed SSA form after copy
propagation.
--
--- 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=gccview=revrev=157602
Log:
Fix PR43464: update loop close SSA once copy prop is done.
--- 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 #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
--- 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 #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
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--- 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
--- 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 #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
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 iostream
typedef int F(int i);
templateF* f
--- 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=20150action=view)
testcode and compiler invocation scripts
--
--- 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
--- 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)
--- 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 #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.
--- 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 #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 #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
--- 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
--
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 #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
--- 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 #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 sreg ends
~/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 #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
--- 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
--- 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
=/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 #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)?
--
--- 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've just
--- 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
--- 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
gcc-bugzi...@gcc.gnu.org wrote:
Why such a big hammer?
'cause I don't want to add more bugs,
and no I
--- 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
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 #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
--- 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 #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
--- 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 @@
bb 12:
# .MEM_16 = PHI .MEM_18(10), .MEM_20(11)
# s_66 = PHI s_1(10), s_1(11)
-s_13 = s_66;
+s_13 = s_1;
goto bb 16 (got_it);
--
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
--- 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=20151action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43467
--- 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
++,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 20100321
--- 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:
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/
--- 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
--- 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
= 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;
--- 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=20152action=view)
localealias.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43469
--- 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 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 #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 #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 #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=gccview=revrev=157604
Log:
PR target/42811 (prerequisite)
*
--- 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=gccview=revrev=157605
Log:
PR target/42811 (prerequisite)
* jvmti.cc
--- 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=gccview=revrev=157606
Log:
PR target/42811
* libjava/configure.ac (DLLTOOL):
--- 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 #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|
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)
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)
--
--- 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=20153action=view)
ghc30321_0.i - preprocessed offending file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43470
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
--- 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=20154action=view)
valgrind.log - sheds some light on SIGSEGV reason
...
==10526== Invalid write of size 8
==10526==at 0x105DC344:
--- 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=20155action=view)
whetstone.cbe.c
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43472
--- 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 #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=gccview=revrev=157609
Log:
PR target/42321
* arm.c
--- 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
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 #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
--- 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=gccview=revrev=157610
Log:
Backport from mainline:
2009-05-12 Paolo
--- 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 #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 #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 #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 #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 @@
bb 12:
# .MEM_16 = PHI .MEM_18(10), .MEM_20(11)
# s_66 = PHI s_1(10), s_1(11)
-s_13 = s_66;
+
--- 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 @@
bb 12:
# .MEM_16 = PHI .MEM_18(10), .MEM_20(11)
# s_66 = PHI s_1(10),
--- 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 your
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 stdio.h
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 ^=
--- 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
--- 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 #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 modi#64257;ed at most once by the evaluation of an expression.
Furthermore, the prior value
--- 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 modi#64257;ed at most once by the evaluation of an expression.
Furthermore, the prior value shall be read only to determine
--- 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
---
--- 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 #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
--- 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=gccview=revrev=157614
Log:
PR middle-end/42718
* pa.md (movmemsi): Set
--- 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=gccview=revrev=157615
Log:
PR middle-end/42718
* pa.md (movmemsi): Set
--- 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=gccview=revrev=157616
Log:
PR middle-end/42718
* pa.md (movmemsi): Set
--- 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=gccview=revrev=157617
Log:
Fix PR43464: loop close phi nodes can contain more than one
--- 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 #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
--- 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);
--- 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=gccview=revrev=157618
Log:
2010-03-21 Jerry DeLisle jvdeli...@gcc.gnu.org
--- 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.
--
99 matches
Mail list logo
