This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] libcpp: use better locations for _Pragma tokens (preprocessor/69126)


On Thu, 2016-01-28 at 11:12 -0800, Steve Ellcey wrote:
> David,
> 
> This patch has broken the top-of-tree glibc build

Bother; sorry.  FWIW, I'm about to get on a plane (for FOSDEM), so I'm
not in a great position to tackle this yet.

> I get an error on an
> undef that is supposed to be protected by Pragmas.  It happens when
> compiling intl/plural.c in glibc.  I created a preprocessed source
> file
> but when I compile it, the error doesn't happen.

PR preprocessor/69126 was all about the location of where _Pragma
macros expand to, so it would make sense that you might see different
behaviors with -save-temps.

> I will try to create a
> small unpreprocessed standalone test case but maybe this is enough
> for
> you to know what is happening.
> 
> If I look at the preprocessed code, the statement in question is
> under ingore warning pragmas.
> 
> #pragma GCC diagnostic push
> #pragma GCC diagnostic ignored "-Wuninitialized"
> #pragma GCC diagnostic ignored "-Wmaybe-uninitialized"
>   *++yyvsp = __gettextlval;
> #pragma GCC diagnostic pop
> 
> 
> Steve Ellcey
> sellcey@imgtec.com
> 
> plural.c: In function '__gettextparse':
> plural.c:1767:12: error: '__gettextlval.num' may be used
> uninitialized
> in this function [-Werror=maybe-uninitialized]
>    *++yyvsp = yylval;
>              
> plural.c:66:25: note: '__gettextlval.num' was declared here
>  #define yylval          __gettextlval
>                          ^
> plural.c:1265:9: note: in expansion of macro 'yylval'
>  YYSTYPE yylval YY_INITIAL_VALUE(yyval_default);
>          ^~~~~~
> cc1: all warnings being treated as errors

Code in question appears to be here:
https://sourceware.org/git/?p=glibc.git;a=blob;f=intl/plural.c;h=a94af3
c542b1aeadebbe02d67dabd2d535f70726;hb=HEAD#l1767

1766   YY_IGNORE_MAYBE_UNINITIALIZED_BEGIN
1767   *++yyvsp = yylval;
1768   YY_IGNORE_MAYBE_UNINITIALIZED_END

Macro itself is defined at line 1244:

1244 # define YY_IGNORE_MAYBE_UNINITIALIZED_BEGIN \
1245     _Pragma ("GCC diagnostic push") \
1246     _Pragma ("GCC diagnostic ignored \"-Wuninitialized\"")\
1247     _Pragma ("GCC diagnostic ignored \"-Wmaybe-uninitialized\"")
1248 # define YY_IGNORE_MAYBE_UNINITIALIZED_END \
1249     _Pragma ("GCC diagnostic pop")

Maybe there's an issue with having a _Pragma inside another macro; my
hunch would be that my patch is making it use the location of the
_Pragma within the *definition* of the
YY_IGNORE_MAYBE_UNINITIALIZED_BEGIN/END macros, rather than their
expansion.  But that's just a hunch at this stage.

I think I have a minimal reproducer:

$ cat /tmp/test.c
# define YY_IGNORE_MAYBE_UNINITIALIZED_BEGIN \
    _Pragma ("GCC diagnostic push") \
    _Pragma ("GCC diagnostic ignored \"-Wuninitialized\"")\
    _Pragma ("GCC diagnostic ignored \"-Wmaybe-uninitialized\"")
# define YY_IGNORE_MAYBE_UNINITIALIZED_END \
    _Pragma ("GCC diagnostic pop")

void test (char yylval)
{
  char *yyvsp;
  YY_IGNORE_MAYBE_UNINITIALIZED_BEGIN
  *++yyvsp = yylval;
  YY_IGNORE_MAYBE_UNINITIALIZED_END
}

$ ./xgcc -B. -c /tmp/test.c -Wall
/tmp/test.c: In function âtestâ:
/tmp/test.c:12:12: warning: âyyvspâ is used uninitialized in this
function [-Wuninitialized]
   *++yyvsp = yylval;
   ~~~~~~~~~^~~~~~~~

$ ./xgcc -B. -c /tmp/test.c -save-temps
$ ./xgcc -B. -c test.i -Wall
(compiles with no warnings)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]