[Bug middle-end/50189] [4.5/4.6 Regression] Wrong code error in -O2 [-fstrict-enums] compile, target independent
rguenther at suse dot de
gcc-bugzilla@gcc.gnu.org
Wed Oct 12 14:23:00 GMT 2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50189
--- Comment #14 from rguenther at suse dot de <rguenther at suse dot de> 2011-10-12 14:21:48 UTC ---
On Wed, 12 Oct 2011, rguenther at suse dot de wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50189
>
> --- Comment #13 from rguenther at suse dot de <rguenther at suse dot de> 2011-10-12 14:15:56 UTC ---
> On Wed, 12 Oct 2011, pkoning at gcc dot gnu.org wrote:
>
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50189
> >
> > --- Comment #12 from Paul Koning <pkoning at gcc dot gnu.org> 2011-10-12 14:04:30 UTC ---
> > You said "GCC treats types compatible when they have the same precision".
> > That's where the problem lies, because enums with -fstrict-enums have their
> > precision set to just enough bits to hold the range of values, rather than the
> > precision of the base integer type. So in the test case in question, the
> > variable's precision is 32 bits while the right hand side precision is 2 bits.
>
> Well. At least we lose the conversion then here:
>
> const unsigned int D.2189;
> position_t D.2188;
>
> <bb 2>:
> D.2189_2 = this_1(D)->m_timestamp;
> D.2188_3 = MIN_EXPR <D.2189_2, 3>;
> return D.2188_3;
>
> I'll look into that.
Which is because even with -fstrict-enums the position_t is
unsigned and has precision 32.
<enumeral_type 0x7ffff5b80540 position_t
type <integer_type 0x7ffff5b805e8 unsigned int public unsigned SI
size <integer_cst 0x7ffff7eee2c0 constant 32>
unit size <integer_cst 0x7ffff7eee2e0 constant 4>
align 32 symtab 0 alias set -1 canonical type 0x7ffff5b805e8
precision 2 min <integer_cst 0x7ffff5b89480 0> max <integer_cst
0x7ffff5b894a0 3>>
unsigned SI size <integer_cst 0x7ffff7eee2c0 32> unit size
<integer_cst 0x7ffff7eee2e0 4>
align 32 symtab 0 alias set -1 canonical type 0x7ffff5b80540 precision
32 min <integer_cst 0x7ffff5b685a0 0> max <integer_cst 0x7ffff5b894c0 3>
without -fstrict-enums it looks like
<enumeral_type 0x7ffff5b80540 position_t
type <integer_type 0x7ffff5b805e8 unsigned int public unsigned SI
size <integer_cst 0x7ffff7eee2c0 constant 32>
unit size <integer_cst 0x7ffff7eee2e0 constant 4>
align 32 symtab 0 alias set -1 canonical type 0x7ffff5b805e8
precision 2 min <integer_cst 0x7ffff5b89480 0> max <integer_cst
0x7ffff5b894a0 3>>
unsigned SI size <integer_cst 0x7ffff7eee2c0 32> unit size
<integer_cst 0x7ffff7eee2e0 4>
align 32 symtab 0 alias set -1 canonical type 0x7ffff5b80540 precision
32 min <integer_cst 0x7ffff7eee300 0> max <integer_cst 0x7ffff7eee2a0
4294967295>
so it only does not have the TYPE_MIN/MAX_VALUE set to [0,3]
More information about the Gcc-bugs
mailing list