User account creation filtered due to spam.

Bug 68193 - _Generic -Woverflow false alarm
Summary: _Generic -Woverflow false alarm
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 5.2.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: diagnostic
Depends on:
Blocks:
 
Reported: 2015-11-02 23:46 UTC by Paul Eggert
Modified: 2015-12-02 17:10 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2015-11-03 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Eggert 2015-11-02 23:46:31 UTC
I ran into this problem when developing Gnulib code.  This is with GCC 5.2.0 on x86-64.  Compile the following program t.c with 'gcc -Wall t.c':

int
main (void)
{
  int i = 0;
  int j = _Generic (i,
		    int: 0,
		    long int: (i = (long int) 9223372036854775808UL));
  return i + j;
}

GCC generates the bogus warning:

t.c: In function 'main':
t.c:7:22: warning: overflow in implicit constant conversion [-Woverflow]
       long int: (i = (long int) 9223372036854775808UL));
                      ^

The warning is bogus because the corresponding expression is not evaluated, as per the semantics of _Generic.

Add 1 to that big constant, changing it to 9223372036854775809UL, and the bogus warning goes away.  So it's possible that there are two bugs here, one having to do with bogus warnings in unevaluated _Generic subexpressions, the other having to do with (unsigned long) LONG_MIN.
Comment 1 Richard Biener 2015-11-03 10:30:40 UTC
Confirmed.
Comment 2 Marek Polacek 2015-12-02 12:04:30 UTC
The problem here is that after we've parsed the selector (with warnings inhibited), we go over all the associations: process the type-name, then parse assignment-expression of the association also using c_parser_expr_no_commas, but this time without the warnings inhibited.  We should probably disable warnings when processing the associations and only warn for matched_assoc.  But I can't readily conceive how to do that.
Comment 3 Marek Polacek 2015-12-02 16:36:24 UTC
I think some kind of delayed warning could help (so parse expressions and print possible warnings to some "printer" and then print warnings from this "printer" only for the association that matched).  Because of "default:" selectors we can't parse just the one that matches.
Comment 4 joseph@codesourcery.com 2015-12-02 16:47:15 UTC
I agree delaying warnings would help, but you'd need to distinguish 
warnings relating to execution of the code that should be disabled in 
unevaluated code from warnings that should always be present (which 
include but aren't limited to pedwarns).  For example, you shouldn't lose 
a diagnostic for an implicit function declaration just because it's in an 
unevaluated _Generic selection.
Comment 5 Marek Polacek 2015-12-02 17:10:49 UTC
Yes, so this would be somehow tied to c_inhibit_evaluation_warnings as in we warn for
  0 ? foo () : 2;
if foo() wasn't declared but not for the div-by-zero here:
  0 ? 1 / 0 : 2;