http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53524
--- Comment #15 from Lawrence Crowl <crowl at google dot com> 2012-05-31 17:18:49 UTC --- > When we emit the warning, arg2_type and arg3_type are the types > of arg2 and arg3, thus, post PR16603, exactly the types of the > two initializing expressions, because we are still defining the > enumerator NumLowBitsAvailable of the same enum and the enum > is not complete. And indeed, those types are *different* as > the warning says. The types of PointerLikeTypeTraits < PT1 >::NumLowBitsAvailable and PointerLikeTypeTraits < PT2 >::NumLowBitsAvailable are enums, but the types of PT1BitsAv and PT2BitsAv are the underlying type, some form of int. The normal integral promotion should provide the ?: result type. That is, we cannot just copy the type of the initializer for PT1BitsAv, we need to determine the underlying type corresponding to the converted value. > Thus, it seems to me, the warning is behaving as designed, just, > post PR16603, it triggers also while we are defining individual > enumerators basing on other enumerators of the same enum. I agree that the basic warning is right. I am not convinced that the enumerator types are handled as per the standard. > Of course this didn't happen before PR16603 because we weren't > honoring the two-phase typing mechanism. Then it seems to me that > we have nothing to strictly-speaking "fix", but only to agree > on how we want to put the warning under control. I'm tempted to > propose again just to add a -Wenum-mismatch, I note that the EDG > front-end doesn't warn with -Wall for the reference very simple > case discussed in Comments #7 and #8. I *do* understand that > ideally we would like to tell the code in build_conditional_expr_1: > "hey we are comparing the types of the initializing expressions > of two enumerators of the same enum, which are different, but the > difference will go away at the end of the enum when we'll have a > single underlying type, thus please don't warn now" but I don't > see a simple way to do this: if, for example, we just compare > underlying types, we suppress a lot of other warnings, like the > one in Comment #7. Given what I see for EDG (what about CLANG?), > I'm not sure we should spend a lot of time right now tuning the > mechanism of the warning itself. I see two approaches. First as you suggest above, which requires passing context into the comparison. Second, set each enumerator type at the point of its definition to its unique underlying type, and at the end of the enumeration, update all the enumerators to have the enumeration's underlying type.
