This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
| Other format: | [Raw text] | |
On Dec 19, 2003, at 8:17 AM, law@redhat.com wrote:In message <978715DA-31C9-11D8-B11A-000A95D7CD40@apple.com>, Dale Johannesen wr
ites:I have a case where tree-ssa is calling fold() on this:We'd need more context to know what's happening. testcases help a lot :-)
<plus_expr 0x9c80a0
type <integer_type 0x40d42528 int SI
size <integer_cst 0x8e4780 constant invariant 32>
unit size <integer_cst 0x8e4798 constant invariant 4>...
invariant
arg 0 <integer_cst 0x40d40570 type <boolean_type 0x40d427f8 _Bool>
constant invariant 1>
arg 1 <integer_cst 0x97eed0 type <integer_type 0x40d42528 int>
constant invariant 1>>
which gets into int_const_binop, which thinks the result is _Bool and truncates it to 0. Not what we want. Would the preference be to fix this in fold(), or make tree_ssa produce trees that incorporate the C promotions?
I'm not asking anybody to fix the bug, I will do that, I just want to know what the
defined semantics of fold() are. Is is supposed to handle the tree above or not?
This arises from perlbmk in SPEC compiled -O3. It hangs at runtime and I'm surprised
nobody else has seen it. The original code was
x = (p !=0) + (q!=0)
and after a few rounds of optimization it transforms into the above.
I haven't tried to construct a small test yet, but it should certainly be possible.
Thanks, Andrew Pinski
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |