http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55277
Uros Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
Depends on||32647
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42536
Uros Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
Last reconfirmed|2010-03-20 13:03:43 |2012-09-02
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42536
--- Comment #12 from Uros Bizjak ubizjak at gmail dot com 2012-09-02 09:44:12
UTC ---
(In reply to comment #11)
Reconfirmed.
BTW: Moving the complex address to the temporary (as proposed in Comment #4)
would help
--- Comment #10 from ubizjak at gmail dot com 2010-01-18 08:42 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00958.html
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #14 from ubizjak at gmail dot com 2010-01-18 21:48 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from ubizjak at gmail dot com 2010-01-17 19:47 ---
Well, gcc would just generate invalid code without this assert.
Reduced test:
--cut here--
typedef unsigned short int uint16_t;
typedef unsigned int uint32_t;
typedef unsigned long int uint64_t;
typedef uint16_t u16
--- Comment #6 from ubizjak at gmail dot com 2010-01-17 20:25 ---
Created an attachment (id=19640)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19640action=view)
Patch to teach {,un}aligned_memory_operand about unaligned offsets
Mikael, can you please test attached patch on your
--- Comment #8 from ubizjak at gmail dot com 2010-01-17 21:50 ---
Created an attachment (id=19642)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19642action=view)
Patch for 4.3 and 4.4 branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42774
--- You are receiving
--- Comment #20 from ubizjak at gmail dot com 2010-01-08 07:48 ---
According to http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00213.html, ia64
should be fixed in the same way as x86.
The wrong code is located in ia64/ia64.c ia64_expand_vecint_compare, around
line 1730. Correct code
--- Comment #24 from ubizjak at gmail dot com 2010-01-07 08:50 ---
(In reply to comment #23)
The proposed change removes REG_EQUAL note only on moved insn, (insn 538) in
our case.
That's too aggressive in the general case, no need to remove a REG_EQUAL note
pointing
--- Comment #25 from ubizjak at gmail dot com 2010-01-07 09:17 ---
New patch revision in testing:
--cut here--
Index: ifcvt.c
===
--- ifcvt.c (revision 155686)
+++ ifcvt.c (working copy)
@@ -4087,7 +4087,8
--- Comment #26 from ubizjak at gmail dot com 2010-01-07 09:23 ---
Oops, brain dump error. This is correct:
Index: ifcvt.c
===
--- ifcvt.c (revision 155686)
+++ ifcvt.c (working copy)
@@ -4087,7 +4087,8
--- Comment #27 from ubizjak at gmail dot com 2010-01-07 11:21 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00318.html .
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #33 from ubizjak at gmail dot com 2010-01-08 07:33 ---
*** Bug 42619 has been marked as a duplicate of this bug. ***
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #14 from ubizjak at gmail dot com 2010-01-06 10:43 ---
This bug can be now reproduced with a crosscompiler to alpha-linux-gnu with
soon to be attached preprocessed source of tree-ssa-loop-im.i (please note
noinline attributes at determine_max_movement and add_dependency
--- Comment #15 from ubizjak at gmail dot com 2010-01-06 10:45 ---
Created an attachment (id=19483)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19483action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42511
--- You are receiving this mail
--- Comment #16 from ubizjak at gmail dot com 2010-01-06 15:17 ---
The problem turns out to be quite complex interaction between cse1, cprop3 and
cse2 pass.
Let's start with this RTL dump for from:
tree-ssa-loop-im.i.148r.subreg1
;; Function determine_max_movement
--- Comment #17 from ubizjak at gmail dot com 2010-01-06 18:14 ---
This bug is similar (or even a duplicate of) PR21767. ifcvt.c has a fixup code
for cases like this, grep ifcvt.c for:
/* PR 21767: When moving insns above a conditional branch, REG_EQUAL
notes might
--- Comment #18 from ubizjak at gmail dot com 2010-01-06 23:16 ---
Following patch changes the fix from PR21767 to remove REG_EQUAL notes from all
moved instructions, not only from ones that have non-function-invariant
sources.
--cut here--
Index: ifcvt.c
--- Comment #20 from ubizjak at gmail dot com 2010-01-07 07:29 ---
(In reply to comment #19)
Following patch changes the fix from PR21767 to remove REG_EQUAL notes from
all
moved instructions, not only from ones that have non-function-invariant
sources.
This seems like a tad
--- Comment #4 from ubizjak at gmail dot com 2010-01-05 12:29 ---
I got different error in the same place when configured with:
Target: alpha-linux-gnu
Configured with: ../gcc-svn/trunk/configure --host=alpha-linux-gnu
--build=alpha-linux-gnu --target=alpha-linux-gnu --enable-languages
--- Comment #5 from ubizjak at gmail dot com 2010-01-05 13:52 ---
Minimized testcase (from other bootstrap failure):
--cut here--
typedef struct
{
struct
{
int how;
} reg[64 + 1];
}
_Unwind_FrameState;
alpha_fallback_frame_state (_Unwind_FrameState * fs)
{
long i
--- Comment #8 from ubizjak at gmail dot com 2010-01-05 14:21 ---
It looks that tree loop IM FUBARs the compilation.
All testcases compile OK with -O2 -fno-tree-loop-im.
The dump for _.c.099t.lim1 looks quite strange (it resembles _.c.024t.ssa):
--cut here--
;; Function
--- Comment #9 from ubizjak at gmail dot com 2010-01-05 14:27 ---
(In reply to comment #7)
setting BOOT_CFLAGS to -g -O1 lets the build succeed. the testcase from
comment
#5 doesn't ice.
It will ICE with default build, with checkings enabled.
--
http://gcc.gnu.org/bugzilla
--- Comment #11 from ubizjak at gmail dot com 2010-01-05 16:24 ---
(In reply to comment #10)
Well, I can't see how this wouldn't be a problem on other targets thus I
re-iterate: which stages do show this behavior? Does the stage1 cc1
reproduce it?
No.
--
http://gcc.gnu.org
--- Comment #12 from ubizjak at gmail dot com 2010-01-05 20:47 ---
Got the problem. stage1 compiler miscompiles determine_max_movement() from
tree-ssa-loop-im.c.
Following patch fixes the testcase from comment #5:
Index: tree-ssa-loop-im.c
--- Comment #13 from ubizjak at gmail dot com 2010-01-05 21:15 ---
(In reply to comment #12)
I will restart bootstrap now.
Bootstraps OK for --enable-languages=c.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42511
--- You are receiving this mail because: ---
You
--- Comment #3 from ubizjak at gmail dot com 2010-01-04 16:07 ---
(In reply to comment #2)
The inline-asm is totally incorrect here ...
Actually, the asm is correct, it is just a couple of volatiles that are
missing. Please see arch/x86/include/asm/bitops.h from linux-2.6 for correct
--- Comment #1 from ubizjak at gmail dot com 2009-12-30 10:57 ---
Confirmed, I have a patch.
--
ubizjak at gmail dot com changed:
What|Removed |Added
AssignedTo
--- Comment #5 from ubizjak at gmail dot com 2009-12-30 11:49 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
URL
--- Comment #9 from ubizjak at gmail dot com 2009-09-29 21:41 ---
(In reply to comment #6)
Can someone check if this still fails on latest 4.3 branch?
It doesn't. See [1].
[1] http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg01497.html
--
ubizjak at gmail dot com changed
--- Comment #10 from ubizjak at gmail dot com 2009-09-29 22:06 ---
Libjava has zero failures with gcc 4.3.5, 4.4.2 and 4.5.0 for me on latest
Gentoo. Please reopen if it still fails for you.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #11 from ubizjak at gmail dot com 2009-08-14 08:11 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from ubizjak at gmail dot com 2009-08-11 06:46 ---
(In reply to comment #6)
Please add to gcc-4.3.x and gcc-4.4.x.
OK, I will post the patch, thanks for the analysis.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--
ubizjak at gmail dot com changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc
--
ubizjak at gmail dot com changed:
What|Removed |Added
Known to work||4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8603
--- You
--- Comment #2 from ubizjak at gmail dot com 2009-02-03 10:52 ---
libjava testsuite works OK on 4.3.4 branch for hppa-linux-gnu [1] and alpha
[2].
The remaining java failures on alpha are due to testsuite problem (dg ?/ expect
?/tcl ?), described in PR 33263.
[1] http://gcc.gnu.org/ml
--- Comment #6 from ubizjak at gmail dot com 2009-02-03 11:18 ---
Can someone check if this still fails on latest 4.3 branch?
4.4 works OK.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #7 from ubizjak at gmail dot com 2009-01-07 14:02 ---
(In reply to comment #0)
FAIL: natgetargssize.cc compilation
FAIL: natgetlocalvartable.cc compilation
FAIL: natgetstacktrace.cc compilation
FAIL: natevents.cc compilation
FAIL: natgetallthreads.cc compilation
FAIL
--- Comment #8 from ubizjak at gmail dot com 2009-01-07 14:05 ---
Closed as WORKSFORME, since bootstrap - well - works for me.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #1 from ubizjak at gmail dot com 2009-01-07 15:39 ---
Does this still fail?
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status
--- Comment #5 from ubizjak at gmail dot com 2009-01-07 17:56 ---
Following patch that changes addsi3 and subsi3 expander constraint fixes this
problem:
--cut here--
Index: alpha.md
===
--- alpha.md(revision 143157
--- Comment #12 from ubizjak at gmail dot com 2009-01-07 21:58 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from ubizjak at gmail dot com 2008-12-18 15:31 ---
This does not fail on 4.4 [1] branch.
[1] http://gcc.gnu.org/ml/gcc-testresults/2008-12/msg01564.html
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #22 from ubizjak at gmail dot com 2008-02-20 18:39 ---
Critical P2 bug and the patch gets unreviewed for so long?!
Is this bug still relevant for ia64-*-linux?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27880
--- You are receiving this mail because
--
ubizjak at gmail dot com changed:
What|Removed |Added
CC|uros at gcc dot gnu dot org |
AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com
--- Comment #4 from ubizjak at gmail dot com 2007-11-26 14:24 ---
Fixed for 4.2 branch, latent on mainline.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34215
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who
--- Comment #6 from ubizjak at gmail dot com 2007-11-26 15:54 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from ubizjak at gmail dot com 2007-09-13 06:32 ---
(In reply to comment #0)
$ g++ -c -O2 -g -fPIC -c libkformulalib_la.all_cc.iiIn file included from
libkformulalib_la.all_cc.cc:45:/scratch/packages/lpia/tmp/koffice-1.6.3/./lib/kformula/formulacursor.cc:
In member
--- Comment #4 from ubizjak at gmail dot com 2007-09-13 09:26 ---
(In reply to comment #3)
the compiler is configure with --with-arch=i686 --with-tune=i586 i686-linux
I can reproduce it with -march=i686, not with -march=i486.
Still no luck there to reproduce segfault. These were my
--- Comment #5 from ubizjak at gmail dot com 2007-09-13 09:28 ---
(In reply to comment #4)
1. Configured latest SVN gcc in _clean_ build dir (on i686-pc-linux-gnu) using
../gcc-svn/trunk/configure --with-mpfr=/usr/local --enable-languages=c,c++
--with-march=i686 --with-tune=i586
--- Comment #6 from ubizjak at gmail dot com 2007-09-13 12:26 ---
(In reply to comment #5)
1. Configured latest SVN gcc in _clean_ build dir (on i686-pc-linux-gnu)
using
../gcc-svn/trunk/configure --with-mpfr=/usr/local --enable-languages=c,c++
--with-march=i686 --with-tune
--- Comment #25 from ubizjak at gmail dot com 2007-05-18 09:48 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
URL|http://gcc.gnu.org
--- Comment #22 from ubizjak at gmail dot com 2007-05-11 14:09 ---
Alternative patch to emit_move_change_mode() to take push_operand away from
change_address():
Index: expr.c
===
--- expr.c (revision 124612
--- Comment #19 from ubizjak at gmail dot com 2007-05-07 08:19 ---
Here is the problem:
Compilation enteres emit_move_via_integer() with:
x = (mem/i:SD (pre_dec:SI (reg/f:SI 7 sp)) [0 S4 A32])
y = (reg/v:SD 59 [ arg ])
emit_move_change_mode() generates invalid insn from x because
--- Comment #20 from ubizjak at gmail dot com 2007-05-07 08:51 ---
Following one-liner fixes the failure. Note that this is for i386 only, as we
also need to skip other autoinc/autodec references.
This is now a generic RTL problem.
2007-05-07 Uros Bizjak [EMAIL PROTECTED
--- Comment #21 from ubizjak at gmail dot com 2007-05-07 11:11 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00390.html
--
ubizjak at gmail dot com changed:
What|Removed |Added
57 matches
Mail list logo
