[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