On 06/04/2012 09:16 PM, Jason Merrill wrote:
On 06/04/2012 02:50 PM, Paolo Carlini wrote:
Ok. The below passes the testsuite on x86_64-linux. Ok for mainline and
4.7.1?
OK. But let's leave the bug open until we fix the warning not to
complain about this testcase even with -Wenum-compare on.
On 06/04/2012 02:50 PM, Paolo Carlini wrote:
Ok. The below passes the testsuite on x86_64-linux. Ok for mainline and
4.7.1?
OK. But let's leave the bug open until we fix the warning not to
complain about this testcase even with -Wenum-compare on.
Jason
On 06/04/2012 08:24 PM, Jason Merrill wrote:
On 06/04/2012 01:52 PM, Paolo Carlini wrote:
Ok, this would be simple to do. The only issue I can see, is that in C++
-Wenum-compare has a name, thus can be easily disabled but it's ON by
default.
The warning is already on by default, so that wouldn't
On 06/04/2012 01:52 PM, Paolo Carlini wrote:
Ok, this would be simple to do. The only issue I can see, is that in C++
-Wenum-compare has a name, thus can be easily disabled but it's ON by
default.
The warning is already on by default, so that wouldn't be a change; this
just creates a way for u
Hi,
On 06/04/2012 06:55 PM, Jason Merrill wrote:
On 05/31/2012 10:55 AM, Paolo Carlini wrote:
On 05/31/2012 04:43 PM, Jason Merrill wrote:
Does the C front end warn about this mismatch?
I just tried the first test of g++.old-deja/g++.other/cond5.C and the C
front-end does *not* warn neither b
On 05/31/2012 10:55 AM, Paolo Carlini wrote:
On 05/31/2012 04:43 PM, Jason Merrill wrote:
Does the C front end warn about this mismatch?
I just tried the first test of g++.old-deja/g++.other/cond5.C and the C
front-end does *not* warn neither by default, neither with -Wall.
Do we warn about
(resending to the mailing list because due to html content)
On 05/31/2012 04:43 PM, Jason Merrill wrote:
Does the C front end warn about this mismatch?
I just tried the first test of g++.old-deja/g++.other/cond5.C and the C
front-end does *not* warn neither by default, neither with -Wall.
Does the C front end warn about this mismatch? Do we warn about
mismatch in comparisons?
Jason
Hi,
when I fixed PR16603 (for 4.7.0) I didn't anticipate that we would warn
more easily about mismatching enum types for user code using conditional
expressions to define enumerators basing on other enumerators of the
same open enum, like the testcase in this PR shows. Generally speaking,
IMH
