.
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: suckfish at ihug dot co dot nz
GCC host triplet: x86_64-redhat-linux
http
--- Comment #1 from suckfish at ihug dot co dot nz 2010-01-28 06:51 ---
Created an attachment (id=19736)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19736action=view)
Test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42892
--- Comment #3 from suckfish at ihug dot co dot nz 2010-01-28 07:02 ---
So java front end bugs shouldn't be logged here?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42892
--- Comment #5 from suckfish at ihug dot co dot nz 2010-01-28 07:26 ---
Ok, it is an ecj bug. I'll report upstream as soon as their bugzilla stops
hanging...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42892
--- Comment #7 from suckfish at ihug dot co dot nz 2008-11-10 07:44 ---
Could someone commit the patch?
[http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00147.html] I don't have SVN
commit access.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37809
--- Comment #6 from suckfish at ihug dot co dot nz 2008-10-17 22:18 ---
Pleasantly, my fears that this was just the tip of the iceburg seems to be
wrong. Writing some test cases, found another bug involving a shift, and also
the ICE below [fixed by some combination of change above
--- Comment #4 from suckfish at ihug dot co dot nz 2008-10-14 07:17 ---
Digging a bit, in combine.c, the ASHIFTRT case of force_to_mode() contains two
calls to simplify_shift_const(). Disabling those for vector modes fixes the
test case here (patch below).
But I suspect this is just
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: suckfish at ihug dot co dot nz
GCC build triplet: x86-64
GCC host triplet: x86-64
GCC target triplet: x86-64
http
--- Comment #1 from suckfish at ihug dot co dot nz 2008-10-11 21:21 ---
Created an attachment (id=16482)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16482action=view)
Code showing exponential compile time.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37807
--- Comment #2 from suckfish at ihug dot co dot nz 2008-10-11 21:35 ---
Using '-da' it looks like the 'combine' pass is the culprit:
$ pidof cc1
6410
$ ls -l /proc/6410/fd
... 4 - ... slow.c.162r.combine
$ ls -s slow.c.162r.combine
0 slow.c.162r.combine
[is there an easier way to get
--- Comment #4 from suckfish at ihug dot co dot nz 2008-10-11 22:23 ---
BTW, __builtin_ia32_psrld and __builtin_ia32_pslld are not documented on the
'X86 built-in functions' page of the manual.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37807
--- Comment #5 from suckfish at ihug dot co dot nz 2008-10-11 23:02 ---
It looks like nonzero_bits1 in rtlanal.c is going into an exponential
recursion.
AFAICS, that function doesn't deal properly with vector arithmetic anyway?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37807
--- Comment #6 from suckfish at ihug dot co dot nz 2008-10-11 23:24 ---
I think this function actually gets miscompiled:
typedef int v2si __attribute__ ((vector_size (8)));
v2si foo (v2si x)
{
x = (v2si) 0xll;
x = __builtin_ia32_psrad (x, 1);
x = (v2si
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: suckfish at ihug dot co dot nz
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37809
--- Comment #7 from suckfish at ihug dot co dot nz 2008-10-12 02:39 ---
Bug 37809 opened for the issue in internal comment 6, as it is different.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37807
--- Comment #1 from suckfish at ihug dot co dot nz 2008-10-12 02:47 ---
Created an attachment (id=16483)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16483action=view)
Test case as a complete program.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37809
--- Comment #8 from suckfish at ihug dot co dot nz 2008-10-12 04:46 ---
Created an attachment (id=16484)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16484action=view)
Test-case modfied to take exponential time on trunk too.
It turns out that it was fast on trunk because inlining
--- Comment #9 from suckfish at ihug dot co dot nz 2008-10-12 05:22 ---
Created an attachment (id=16486)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16486action=view)
Possible fix for 37807
Patch above essentially stops nonzero_bits1 and num_sign_bit_copies1 processing
vector
--- Comment #10 from suckfish at ihug dot co dot nz 2008-10-12 05:27
---
Changelog for patch if accepted [will do full bootstrap make test]:
2008-10-12 Ralph Loader [EMAIL PROTECTED]
PR 37807
* rtlanal.c (numzero_bits1): Return early on vector types, avoiding
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: suckfish at ihug dot co dot nz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37743
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: suckfish at ihug dot co dot nz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25362
at ihug dot co dot nz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25363
: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: suckfish at ihug dot co dot nz
CC: gcc-bugs at gcc dot gnu dot org
GCC
23 matches
Mail list logo
