https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87950
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Vitali from comment #2)
> Why has clang made a different decision? Also, this warning is present in
> C++ code too.
You need to ask clang why they made that decision. C rules are clear about
value ranges of enums and all.
In C++, (unlike C), out of ranges are just unspecified rather than undefined.
This means the warning is correct too. NOTE there is a big difference between
the three: implmenentation defined, undefined and unspecified behaviors.
implmenentation defined is behavior that needs to be documented. Undefined
behavior means the behavior can be different at different runs. unspecified
behaviors means the behavior does not need to be documented but it has to be
constitiant between runs.
So there is no bug here again.
See PR12242 also about a warning for the unspecified behavior when doing the
conversion; NOTE it is not undefined which is different.
See also https://gcc.gnu.org/ml/gcc-patches/2010-04/msg01694.html .
Also see PR 53479 for the C++ side of the warning too (for enum classes).
--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Vitali from comment #2)
> Why has clang made a different decision? Also, this warning is present in
> C++ code too.
You need to ask clang why they made that decision. C rules are clear about
value ranges of enums and all.
In C++, (unlike C), out of ranges are just unspecified rather than undefined.
This means the warning is correct too. NOTE there is a big difference between
the three: implmenentation defined, undefined and unspecified behaviors.
implmenentation defined is behavior that needs to be documented. Undefined
behavior means the behavior can be different at different runs. unspecified
behaviors means the behavior does not need to be documented but it has to be
constitiant between runs.
So there is no bug here again.
See PR12242 also about a warning for the unspecified behavior when doing the
conversion; NOTE it is not undefined which is different.
See also https://gcc.gnu.org/ml/gcc-patches/2010-04/msg01694.html .
Also see PR 53479 for the C++ side of the warning too (for enum classes).
