This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix __has_{cpp_}attribute with -traditional-cpp (PR preprocessor/65238)
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Jason Merrill <jason at redhat dot com>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, Marek Polacek <polacek at redhat dot com>, Dodji Seketeli <dseketel at redhat dot com>, gcc-patches at gcc dot gnu dot org
- Date: Fri, 20 Mar 2015 17:48:49 +0100
- Subject: Re: [PATCH] Fix __has_{cpp_}attribute with -traditional-cpp (PR preprocessor/65238)
- Authentication-results: sourceware.org; auth=none
- References: <20150311191054 dot GQ1746 at tucnak dot redhat dot com> <550C4B34 dot 7010203 at redhat dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Fri, Mar 20, 2015 at 12:30:44PM -0400, Jason Merrill wrote:
> On 03/11/2015 03:10 PM, Jakub Jelinek wrote:
> >__has_{cpp_,}attribute builtin macros are effectively function-like macros
> >taking one argument (and the ISO preprocessor expands macros in the argument
> >which is IMHO desirable), but the traditional preprocessor has been crashing
> >on them or reporting errors.
>
> Why do we want ISO preprocessor behavior in this specific situation?
You mean that we would handle
#define U unused
#if __has_attribute(U)
int u __attribute__((unused));
#endif
differently between ISO and traditional preprocessing?
That would be surprising to users. IMHO either we want to expand
the arguments in both cases (what the patch does), or in none
(that would be then consistent with clang++, guess would mean adding
pfile->state.prevent_expansion++; / pfile->state.prevent_expansion--;
pair around something in the ISO case, and would slightly but not too much
simplify the traditional __has_attribute handling; still we'd need to build
the buffer with the argument and feed it to the langhook, which parses it
with ISO preprocessor with disabled expansion).
Jakub