--- Comment #34 from rguenth at gcc dot gnu dot org 2008-01-25 12:07
---
Subject: Bug 33887
Author: rguenth
Date: Fri Jan 25 12:06:31 2008
New Revision: 131823
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131823
Log:
2008-01-25 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #33 from mmitchel at gcc dot gnu dot org 2008-01-25 05:35
---
This patch:
http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00862.html
is OK. This patch:
http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00951.html
is OK if no objections from a Java maintainer within 24 hours.
--- Comment #32 from rguenth at gcc dot gnu dot org 2008-01-23 14:24
---
Patches pending for review:
http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00862.html
http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00951.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33887
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org
--- Comment #31 from rguenth at gcc dot gnu dot org 2008-01-21 09:20
---
Err, did I really close this bug?! I wanted to assign it to myself ...
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #30 from aoliva at gcc dot gnu dot org 2008-01-19 00:51 ---
I tried that myself (patch in comment #11) and got no regressions. It's a
reasonable possibility, but isn't it a bit too early to close the bug? :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33887
--- Comment #29 from rguenth at gcc dot gnu dot org 2008-01-18 21:04
---
I'm trying again with enabling the langhook for C++.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #28 from aoliva at gcc dot gnu dot org 2008-01-18 19:11 ---
Subject: Bug 33887
Author: aoliva
Date: Fri Jan 18 19:11:15 2008
New Revision: 131632
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131632
Log:
PR c++/33887
* link.cc (_Jv_Linker::prepare_constant_time_tabl
--- Comment #27 from aoliva at gcc dot gnu dot org 2008-01-18 18:47 ---
Found it (or at least the first one):
in link.cc:665, has_interfaces is a jboolean (unsigned 1-bit type), but it's
operated on like this:
has_interfaces += klass0->interface_count;
if interface_count is even (
--- Comment #26 from aoliva at gcc dot gnu dot org 2008-01-18 18:08 ---
I installed the patch in comment #11 and rebuilt all libraries, then I started
investigating the first testsuite failure: libjava.cni/PR9577.java.
So far, I've found out that it is the gnu.classpath.SystemProperties
--- Comment #25 from rguenth at gcc dot gnu dot org 2008-01-15 14:05
---
Unassigning. I like to have help from somebody knowing how to debug the
libjava failures. The only bitfields are defined in jvmti.h.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #24 from rguenth at gcc dot gnu dot org 2008-01-15 13:23
---
So the issue is that for
void foo(unsigned int) (i)
{
i.0;
:
i.0 = () i;
sv.f2 = i.0;
if ((unsigned int) i.0 != 0)
we neither emit code for the narrowing nor for the widening, but only
for the bitfield
--- Comment #23 from rguenth at gcc dot gnu dot org 2008-01-15 09:45
---
I don't see where there is a problem with widening conversions. The problem is
we re-use the (unsigned : 24) i; value for the comparison, which looks
reasonable, but this _narrowing_ conversion is not reflected b
--- Comment #22 from aoliva at gcc dot gnu dot org 2008-01-14 19:56 ---
Both are cases in which the absence of bit-field reduction *on widening
conversions* causes the problem.
I realize the absence of such reductions can be harmful in other cases as well,
e.g. division and right-shifts
--- Comment #21 from rguenth at gcc dot gnu dot org 2008-01-14 17:08
---
Another testcase we miscompile due to the fact in comment #20 (w/o the
temporary
tmp fold converts the comparison to a comparision with a BIT_FIELD_REF, which
is handled correctly (not optimized)):
extern "C" voi
--- Comment #20 from rguenth at gcc dot gnu dot org 2008-01-14 16:55
---
So even if you fix that, and you'll end up with
D.2029;
:
D.2029 = () (unsigned int) ((int) x.i + -1);
x.i = D.2029;
if (D.2029 != 16777215)
goto ;
else
goto ;
before expand, the truncation at
--- Comment #19 from rguenth at gcc dot gnu dot org 2008-01-14 15:45
---
The bug here is that the FE does not perform integer promotion for ++sv.f2,
but emits
<>>
>>;
which is gimplified to operations on a bitfield type:
D.2043;
D.2044;
D.2043 = sv.f2;
D.2044 = D.20
--- Comment #18 from aoliva at gcc dot gnu dot org 2008-01-11 06:46 ---
I don't see anything in expand_expr_real_1 that, given something like
(wider)narrower_typed_value, would reduce the value in a way that takes the
narrower_type into account. NOP_EXPR and CONVERT_EXPR will just expan
--- Comment #17 from rguenth at gcc dot gnu dot org 2008-01-02 15:22
---
Looking at assembly differences in libjava doesn't reveal something obvious.
It
seems to be neither boolean bitfields nor enums (which would have been the
obvious differences where C and C++ semantics differ). Ma
--- Comment #16 from rguenther at suse dot de 2007-12-14 14:36 ---
Subject: Re: [4.1/4.2/4.3 Regression] Reference to bitfield
gets wrong value when optimizing
On Fri, 14 Dec 2007, bonzini at gnu dot org wrote:
> I have a patch that makes the reduce_bitfield_operations langhook a per
--- Comment #15 from bonzini at gnu dot org 2007-12-14 14:31 ---
I have a patch that makes the reduce_bitfield_operations langhook a per-type
field, but it doesn't affect code generation.
Isn't there a testcase in the C++ library that fails if the langhook is
false?...
--
http://gc
--- Comment #14 from rguenth at gcc dot gnu dot org 2007-12-12 22:47
---
Great. That doesn't make too much sense ;) Because the testcase in comment #7
cannot be "optimized" on the tree level, but I see it is wrongly expanded to
RTL instead.
Now, the revisions are
103956: make tree-
--- Comment #13 from janis at gcc dot gnu dot org 2007-12-12 22:04 ---
Additional regression hunts on trunk discovered that the test starts failing
with:
http://gcc.gnu.org/viewcvs?view=rev&rev=103956
r103956 | steven | 2005-09-06 18:51:26 + (Tue, 06 Sep 2005)
and starts p
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33887
--- Comment #12 from janis at gcc dot gnu dot org 2007-12-11 23:56 ---
Before noticing comment #9, I tested a few saved installs of trunk and ran a
regression hunt for trunk on powerpc-linux using the testcase from comment #7,
which found this patch that caused the test to start failing:
--- Comment #11 from rguenth at gcc dot gnu dot org 2007-12-11 15:55
---
The following fixes this failure, but breaks libjava a lot:
Index: cp/cp-lang.c
===
--- cp/cp-lang.c(revision 130773)
+++ cp/cp-lang.c
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-12-11 13:34
---
I wonder what broke this. Janis, can you hunt this with the testcase in
comment #7? (g++ -O is enough)
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-12-11 13:31 ---
Fails since 4.1.0, works up to 4.0.4.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
28 matches
Mail list logo
