This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 2/6] Generate virtual locations for tokens
- From: Dodji Seketeli <dodji at redhat dot com>
- To: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- Cc: gcc-patches at gcc dot gnu dot org, jason at redhat dot com, tromey at redhat dot com, gdr at integrable-solutions dot net, joseph at codesourcery dot com, burnus at net-b dot de, charlet at act-europe dot fr
- Date: Wed, 19 Oct 2011 18:33:46 +0200
- Subject: Re: [PATCH 2/6] Generate virtual locations for tokens
- References: <201110191359.p9JDxAgL021398@d06av02.portsmouth.uk.ibm.com>
"Ulrich Weigand" <uweigand@de.ibm.com> writes:
> The problem seems to be that the preprocessor somehow stripped
> off the "unsigned" keyword. A reduced test case is:
>
> #define isinf(__x)
>
> #define vec_uint4 __vector unsigned int
>
> vec_uint4 isinf;
>
> (Using the name of a function-like macro as identifer is maybe a bit odd,
> but should be perfectly legal C as far as I know ...)
>
> Running this through "cc1 -E" on a SPU target before the patch set yields:
>
> __attribute__((__spu_vector__)) unsigned int isinf;
>
> as expected, but after the patch set we get:
>
> __attribute__((__spu_vector__)) int isinf;
>
> instead.
>
> The problem is clearly related to the platform-specific "macro_to_expand"
> routine that is used on SPU to implement the context-sensitive __vector
> keyword.
>
> With your changes to cpp_get_token (which is the sole caller of the
> macro_to_expand callback), are there any changes in the interface
> to the callback?
Not that I would expect.
> Any suggestions what could be going on here?
Nothing obvious is coming to my mind right now, I am still looking
at the issue.
--
Dodji