On Fri, Mar 18, 2016 at 5:34 PM, Jakub Jelinek <ja...@redhat.com> wrote:
> Hi!
>
> The following testcase is diagnosed as errorneous, because the preprocessor
> mishandles
>
> #define c(x) x
> vector c;
>
> and
>
> #define int(x) x
> vector int n;
>
> The thing is if a function-like macro is not followed by (, then it is kept
> as is, but the builtin conditional macro handling expects it always expands
> as something and calls cpp_get_token on it. For non-function-like macros
> or function-like macros followed by ( that is not a problem, that
> cpp_get_token call just eats the macro token and pushes instead the
> replacement tokens, but for function-like macro not followed by ( it results
> in the token being dropped on the floor.
> So, in the above mentioned cases we preprocess it as
> vector ;
> and
> vector n;
> and when compiling, error on the first one, and (due to previous
> typedef int vector;) handle it at int n; rather than
> __attribute__((__vector)) int n;
>
> Fixed by peeking at the next token after the macro token (or more, if there
> are CPP_PADDING tokens) and if it is not followed by CPP_OPEN_PAREN, not
> calling cpp_get_token. Unfortunately, cpp_macro structure is opaque outside
> of libcpp, so I had to add a helper function into libcpp.
>
> Bootstrapped/regtested on powerpc64{,le}-linux, ok for trunk?
>
> 2016-03-18 Jakub Jelinek <ja...@redhat.com>
>
> PR target/70296
> * include/cpplib.h (cpp_fun_like_macro_p): New prototype.
> * macro.c (cpp_fun_like_macro_p): New function.
>
> * config/rs6000/rs6000-c.c (rs6000_macro_to_expand): If IDENT is
> function-like macro, peek following token(s) if it is followed
> by CPP_OPEN_PAREN token with optional padding in between, and
> if not, don't treat it like a macro.
>
> * gcc.target/powerpc/altivec-36.c: New test.
I'm not an expert in this part of the compiler, but the rs6000 bits
are fine with me.
Thanks, David
