* [Patch] libcpp: Fix _Pragma in #__VA_ARGS__ [PR103165]
@ 2021-11-10 20:12 Tobias Burnus
2021-11-10 21:30 ` Joseph Myers
0 siblings, 1 reply; 6+ messages in thread
From: Tobias Burnus @ 2021-11-10 20:12 UTC (permalink / raw)
To: gcc-patches, Jakub Jelinek
[-- Attachment #1: Type: text/plain, Size: 1512 bytes --]
This patch fixes a pseudo regression of my previous _Pragma patch.
The issue was that a tokenized '_Pragma' (-> CPP_PRAGMA) could end
up as to-be quoted argument ('#__VA_ARG__') and that wasn't never
handled and gave an ICE for a GCC after my previous patch and before
this patch.
The expected 'gcc -E' output is in the '#if 0' block in the testcase.
Before my previous patch, "gcc -E" yielded the following, which is
obviously wrong:
const char *str =
#pragma omp error severity(warning) message ("Test") at(compilation)
"\"1,2\" ;" ;
#pragma omp error severity(warning) message ("Test") at(compilation)
;
Build on x86-64-gnu-linux, the "make -k check" is running.
OK when it passes?
* * *
Disclaimer: While this patch does a step into the right direction,
it probably does help with any of the other _Pragma issues. Neither
with 'gcc -E' when the pragma wasn't registered (still expanded too
early) nor with the 'GCC diagnostic' issues in general as there the
input_location is used to decide when to pop - and depending on the
column numbers, this may or may not work.
See https://gcc.gnu.org/pipermail/gcc-patches/2021-October/582927.html
for some more details and links to PRs.
Tobias
-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955
[-- Attachment #2: pragma2-fix.diff --]
[-- Type: text/x-patch, Size: 7118 bytes --]
libcpp: Fix _Pragma in #__VA_ARGS__ [PR103165]
Using '#define inner(...) #__VA_ARGS__ _Pragma("...")' yields a string plus
the _Pragma, passing this to another '#__VA_ARGS__' lead to having a
CPP_PRAGMA inside stringify_arg, which wasn't handled before this commit and
gave an ICE.
In GCC versions before r12-4797-g0078a058 (cf. PR102409), instead of giving
an ICE, the _Pragma wasn't stringified but output as a #pragma before the
actual macro expansion.
PR preprocessor/103165
libcpp/ChangeLog:
* directives.c (_cpp_get_pragma_by_id): New.
* internal.h (_cpp_get_pragma_by_id): New prototype.
* macro.c (stringify_arg): Use it; hande stringification of _Pragma.
gcc/testsuite/ChangeLog:
* c-c++-common/gomp/pragma-3.c: New test.
* c-c++-common/gomp/pragma-4.c: New test.
gcc/testsuite/c-c++-common/gomp/pragma-3.c | 20 ++++++++++++++++++++
gcc/testsuite/c-c++-common/gomp/pragma-4.c | 20 ++++++++++++++++++++
libcpp/directives.c | 23 +++++++++++++++++++++++
libcpp/internal.h | 3 +++
libcpp/macro.c | 29 +++++++++++++++++++++++++++--
5 files changed, 93 insertions(+), 2 deletions(-)
diff --git a/gcc/testsuite/c-c++-common/gomp/pragma-3.c b/gcc/testsuite/c-c++-common/gomp/pragma-3.c
new file mode 100644
index 00000000000..f8b741138e7
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/gomp/pragma-3.c
@@ -0,0 +1,20 @@
+/* { dg-additional-options "-fdump-tree-original" } */
+/* PR preprocessor/103165 */
+
+#define inner(...) #__VA_ARGS__ ; _Pragma("omp error severity(warning) message (\"Test\") at(compilation)")
+#define outer(...) inner(__VA_ARGS__)
+
+void
+f (void)
+{
+ const char *str = outer(inner(1,2)); /* { dg-warning "'pragma omp error' encountered: Test" } */
+}
+
+#if 0
+After preprocessing, the expected result are the following three lines:
+ const char *str = "\"1,2\" ; _Pragma(\"omp error severity(warning) message (\"Test\") at(compilation)\")" ;
+#pragma omp error severity(warning) message ("Test") at(compilation)
+ ;
+#endif
+
+/* { dg-final { scan-tree-dump "const char \\* str = \\(const char \\*\\) \"\\\\\"1,2\\\\\" ; _Pragma\\(\\\\\"omp error severity\\(warning\\) message \\(\\\\\"Test\\\\\"\\) at\\(compilation\\)\\\\\"\\)\";" "original" } } */
diff --git a/gcc/testsuite/c-c++-common/gomp/pragma-4.c b/gcc/testsuite/c-c++-common/gomp/pragma-4.c
new file mode 100644
index 00000000000..608dddc7e6a
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/gomp/pragma-4.c
@@ -0,0 +1,20 @@
+/* { dg-additional-options "-fdump-tree-original -save-temps" } */
+/* PR preprocessor/103165 */
+
+#define inner(...) #__VA_ARGS__ ; _Pragma("omp error severity(warning) message (\"Test\") at(compilation)")
+#define outer(...) inner(__VA_ARGS__)
+
+void
+f (void)
+{
+ const char *str = outer(inner(1,2)); /* { dg-warning "'pragma omp error' encountered: Test" } */
+}
+
+#if 0
+After preprocessing, the expected result are the following three lines:
+ const char *str = "\"1,2\" ; _Pragma(\"omp error severity(warning) message (\"Test\") at(compilation)\")" ;
+#pragma omp error severity(warning) message ("Test") at(compilation)
+ ;
+#endif
+
+/* { dg-final { scan-tree-dump "const char \\* str = \\(const char \\*\\) \"\\\\\"1,2\\\\\" ; _Pragma\\(\\\\\"omp error severity\\(warning\\) message \\(\\\\\"Test\\\\\"\\) at\\(compilation\\)\\\\\"\\)\";" "original" } } */
diff --git a/libcpp/directives.c b/libcpp/directives.c
index 34f7677f718..9eefb20d4d4 100644
--- a/libcpp/directives.c
+++ b/libcpp/directives.c
@@ -1236,6 +1236,29 @@ do_ident (cpp_reader *pfile)
check_eol (pfile, false);
}
+/* Convert a pragma id back to the space + name. Currently used by
+ stringify_arg for _Pragma. The assumption is that it is only very rarely
+ called such that O(num-pragmas + num-pragma-spaces) checks is acceptable. */
+void
+_cpp_get_pragma_by_id (cpp_reader *pfile, const cpp_token *token,
+ cpp_hashnode const **space, cpp_hashnode const **name)
+{
+ struct pragma_entry *s, *n = NULL;
+ for (s = pfile->pragmas; s; s = s->next)
+ {
+ if (!s->is_nspace)
+ continue;
+ for (n = s->u.space; n; n = n->next)
+ if (token->val.pragma == n->u.ident)
+ break;
+ if (n)
+ break;
+ }
+ gcc_assert (s && n);
+ *space = s->pragma;
+ *name = n->pragma;
+}
+
/* Lookup a PRAGMA name in a singly-linked CHAIN. Returns the
matching entry, or NULL if none is found. The returned entry could
be the start of a namespace chain, or a pragma. */
diff --git a/libcpp/internal.h b/libcpp/internal.h
index 8577cab6c83..9e31564cf23 100644
--- a/libcpp/internal.h
+++ b/libcpp/internal.h
@@ -762,6 +762,9 @@ extern void _cpp_define_builtin (cpp_reader *, const char *);
extern char ** _cpp_save_pragma_names (cpp_reader *);
extern void _cpp_restore_pragma_names (cpp_reader *, char **);
extern int _cpp_do__Pragma (cpp_reader *, location_t);
+extern void _cpp_get_pragma_by_id (cpp_reader *, const cpp_token*,
+ cpp_hashnode const **,
+ cpp_hashnode const **);
extern void _cpp_init_directives (cpp_reader *);
extern void _cpp_init_internal_pragmas (cpp_reader *);
extern void _cpp_do_file_change (cpp_reader *, enum lc_reason, const char *,
diff --git a/libcpp/macro.c b/libcpp/macro.c
index b2f797cae35..1642b96e835 100644
--- a/libcpp/macro.c
+++ b/libcpp/macro.c
@@ -839,6 +839,7 @@ stringify_arg (cpp_reader *pfile, const cpp_token **first, unsigned int count,
unsigned int i, escape_it, backslash_count = 0;
const cpp_token *source = NULL;
size_t len;
+ cpp_hashnode const *pragma_space = NULL, *pragma_name = NULL;
if (BUFF_ROOM (pfile->u_buff) < 3)
_cpp_extend_buff (pfile, &pfile->u_buff, 3);
@@ -887,7 +888,15 @@ stringify_arg (cpp_reader *pfile, const cpp_token **first, unsigned int count,
/* Room for each char being written in octal, initial space and
final quote and NUL. */
- len = cpp_token_len (token);
+ if (token->type == CPP_PRAGMA)
+ {
+ gcc_assert (token->flags & PRAGMA_OP);
+ _cpp_get_pragma_by_id (pfile, token, &pragma_space, &pragma_name);
+ len = (strlen ("_Pragma(\"") + pragma_space->ident.len
+ + 1 + pragma_name->ident.len);
+ }
+ else
+ len = cpp_token_len (token);
if (escape_it)
len *= 4;
len += 3;
@@ -909,7 +918,23 @@ stringify_arg (cpp_reader *pfile, const cpp_token **first, unsigned int count,
}
source = NULL;
- if (escape_it)
+ if (token->type == CPP_PRAGMA)
+ {
+ memcpy (dest, "_Pragma(\\\"", strlen("_Pragma(\\\""));
+ dest += strlen("_Pragma(\\\"");
+ memcpy (dest, pragma_space->ident.str, pragma_space->ident.len);
+ dest += pragma_space->ident.len;
+ *dest = ' ';
+ dest++;
+ memcpy (dest, pragma_name->ident.str, pragma_name->ident.len);
+ dest += pragma_name->ident.len;
+ }
+ else if (token->type == CPP_PRAGMA_EOL)
+ {
+ memcpy (dest, "\\\")", 3);
+ dest += 3;
+ }
+ else if (escape_it)
{
_cpp_buff *buff = _cpp_get_buff (pfile, len);
unsigned char *buf = BUFF_FRONT (buff);
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Patch] libcpp: Fix _Pragma in #__VA_ARGS__ [PR103165]
2021-11-10 20:12 [Patch] libcpp: Fix _Pragma in #__VA_ARGS__ [PR103165] Tobias Burnus
@ 2021-11-10 21:30 ` Joseph Myers
2021-11-18 11:24 ` Jakub Jelinek
0 siblings, 1 reply; 6+ messages in thread
From: Joseph Myers @ 2021-11-10 21:30 UTC (permalink / raw)
To: Tobias Burnus; +Cc: gcc-patches, Jakub Jelinek
On Wed, 10 Nov 2021, Tobias Burnus wrote:
> Disclaimer: While this patch does a step into the right direction,
> it probably does help with any of the other _Pragma issues. Neither
> with 'gcc -E' when the pragma wasn't registered (still expanded too
> early) nor with the 'GCC diagnostic' issues in general as there the
> input_location is used to decide when to pop - and depending on the
> column numbers, this may or may not work.
And fully correct stringization of _Pragma should respect the spelling of
the preprocessing tokens (of the string-literal preprocessing token, that
is; spelling variations for the other preprocessing tokens aren't possible
here) and the presence or absence of whitespace between them.
_Pragma("foo")
_Pragma ("foo")
_Pragma("foo" )
_Pragma(L"foo")
_Pragma ( "foo" )
(for example) should all have their spelling preserved by stringization
(but any nonempty white space sequence becomes a single space).
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Patch] libcpp: Fix _Pragma in #__VA_ARGS__ [PR103165]
2021-11-10 21:30 ` Joseph Myers
@ 2021-11-18 11:24 ` Jakub Jelinek
2021-11-18 21:55 ` Joseph Myers
0 siblings, 1 reply; 6+ messages in thread
From: Jakub Jelinek @ 2021-11-18 11:24 UTC (permalink / raw)
To: Joseph Myers; +Cc: Tobias Burnus, gcc-patches
On Wed, Nov 10, 2021 at 09:30:29PM +0000, Joseph Myers wrote:
> On Wed, 10 Nov 2021, Tobias Burnus wrote:
>
> > Disclaimer: While this patch does a step into the right direction,
> > it probably does help with any of the other _Pragma issues. Neither
> > with 'gcc -E' when the pragma wasn't registered (still expanded too
> > early) nor with the 'GCC diagnostic' issues in general as there the
> > input_location is used to decide when to pop - and depending on the
> > column numbers, this may or may not work.
>
> And fully correct stringization of _Pragma should respect the spelling of
> the preprocessing tokens (of the string-literal preprocessing token, that
> is; spelling variations for the other preprocessing tokens aren't possible
> here) and the presence or absence of whitespace between them.
>
> _Pragma("foo")
> _Pragma ("foo")
> _Pragma("foo" )
> _Pragma(L"foo")
> _Pragma ( "foo" )
>
> (for example) should all have their spelling preserved by stringization
> (but any nonempty white space sequence becomes a single space).
Yeah. And not just that, I think also all the exact whitespace in the
string literal (this time with no replacement of nonempty white space with a
single space).
Consider in pragma-3.c e.g.
#define inner(...) #__VA_ARGS__ ; _Pragma ( " omp error severity (warning) message (\"Test\") at(compilation)" )
should yield:
const char *str = "\"1,2\" ; _Pragma ( \" omp error severity (warning) message (\\\"Test\\\") at(compilation)\" )";
I guess we could encode the PREV_WHITE flags from the ( and ) tokens as 2 separate
bits somewhere (e.g. in some bits of the pragma id), but we need to encode the whole
string literal somewhere too.
Now, in cpp_token we have:
union cpp_token_u {
/* Caller-supplied identifier for a CPP_PRAGMA. */
unsigned int GTY ((tag ("CPP_TOKEN_FLD_PRAGMA"))) pragma;
}
where several other members of the union are structs, either with a pair
of unsigned and pointer or two pointers. So, could we make
the pragma union member also a struct with the pragma id and
pointer to the _Pragma string literal cpp_token?
Though, that doesn't solve the case where in destringize_and_run
pfile->directive_result.type != CPP_PRAGMA.
Are we handling the pragma at a wrong phase of preprocessing?
Jakub
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Patch] libcpp: Fix _Pragma in #__VA_ARGS__ [PR103165]
2021-11-18 11:24 ` Jakub Jelinek
@ 2021-11-18 21:55 ` Joseph Myers
2021-11-22 9:23 ` [PATCH] libcpp, v2: " Jakub Jelinek
0 siblings, 1 reply; 6+ messages in thread
From: Joseph Myers @ 2021-11-18 21:55 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: Tobias Burnus, gcc-patches
On Thu, 18 Nov 2021, Jakub Jelinek via Gcc-patches wrote:
> Are we handling the pragma at a wrong phase of preprocessing?
I think that converting it to a single preprocessing token (rather than
four separate preprocessing tokens), at a stage when stringizing might
still occur, does indicate it's being processed too soon, and it would be
better to do that only when it's known that the _Pragma preprocessing
token will actually occur in the results of preprocessing the source file.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH] libcpp, v2: Fix _Pragma in #__VA_ARGS__ [PR103165]
2021-11-18 21:55 ` Joseph Myers
@ 2021-11-22 9:23 ` Jakub Jelinek
2021-11-22 20:56 ` Joseph Myers
0 siblings, 1 reply; 6+ messages in thread
From: Jakub Jelinek @ 2021-11-22 9:23 UTC (permalink / raw)
To: Joseph Myers; +Cc: Tobias Burnus, gcc-patches
On Thu, Nov 18, 2021 at 09:55:52PM +0000, Joseph Myers wrote:
> On Thu, 18 Nov 2021, Jakub Jelinek via Gcc-patches wrote:
>
> > Are we handling the pragma at a wrong phase of preprocessing?
>
> I think that converting it to a single preprocessing token (rather than
> four separate preprocessing tokens), at a stage when stringizing might
> still occur, does indicate it's being processed too soon, and it would be
> better to do that only when it's known that the _Pragma preprocessing
> token will actually occur in the results of preprocessing the source file.
So like this? I.e. don't process _Pragma during expand_args where we can't
know what the macro will do with it?
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2021-11-22 Jakub Jelinek <jakub@redhat.com>
Tobias Burnus <tobias@codesourcery.com>
PR preprocessor/103165
libcpp/
* internal.h (struct lexer_state): Add ignore__Pragma field.
* macro.c (builtin_macro): Don't interpret _Pragma if
pfile->state.ignore__Pragma.
(expand_arg): Temporarily set pfile->state.ignore__Pragma to 1.
gcc/testsuite/
* c-c++-common/gomp/pragma-3.c: New test.
* c-c++-common/gomp/pragma-4.c: New test.
* c-c++-common/gomp/pragma-5.c: New test.
--- libcpp/internal.h.jj 2021-11-18 12:33:18.409679558 +0100
+++ libcpp/internal.h 2021-11-20 11:00:58.044399990 +0100
@@ -287,6 +287,9 @@ struct lexer_state
/* Nonzero if the deferred pragma being handled allows macro expansion. */
unsigned char pragma_allow_expansion;
+
+ /* Nonzero if _Pragma should not be interpreted. */
+ unsigned char ignore__Pragma;
};
/* Special nodes - identifiers with predefined significance. */
--- libcpp/macro.c.jj 2021-11-18 12:33:18.462678802 +0100
+++ libcpp/macro.c 2021-11-20 11:02:03.249478159 +0100
@@ -750,8 +750,10 @@ builtin_macro (cpp_reader *pfile, cpp_ha
if (node->value.builtin == BT_PRAGMA)
{
/* Don't interpret _Pragma within directives. The standard is
- not clear on this, but to me this makes most sense. */
- if (pfile->state.in_directive)
+ not clear on this, but to me this makes most sense.
+ Similarly, don't interpret _Pragma inside expand_args, we might
+ need to stringize it later on. */
+ if (pfile->state.in_directive || pfile->state.ignore__Pragma)
return 0;
return _cpp_do__Pragma (pfile, loc);
@@ -2648,6 +2650,7 @@ expand_arg (cpp_reader *pfile, macro_arg
size_t capacity;
bool saved_warn_trad;
bool track_macro_exp_p = CPP_OPTION (pfile, track_macro_expansion);
+ bool saved_ignore__Pragma;
if (arg->count == 0
|| arg->expanded != NULL)
@@ -2670,6 +2673,9 @@ expand_arg (cpp_reader *pfile, macro_arg
push_ptoken_context (pfile, NULL, NULL,
arg->first, arg->count + 1);
+ saved_ignore__Pragma = pfile->state.ignore__Pragma;
+ pfile->state.ignore__Pragma = 1;
+
for (;;)
{
const cpp_token *token;
@@ -2692,6 +2698,7 @@ expand_arg (cpp_reader *pfile, macro_arg
_cpp_pop_context (pfile);
CPP_WTRADITIONAL (pfile) = saved_warn_trad;
+ pfile->state.ignore__Pragma = saved_ignore__Pragma;
}
/* Returns the macro associated to the current context if we are in
--- gcc/testsuite/c-c++-common/gomp/pragma-3.c.jj 2021-11-20 11:04:27.636429378 +0100
+++ gcc/testsuite/c-c++-common/gomp/pragma-3.c 2021-11-20 11:27:46.892589048 +0100
@@ -0,0 +1,20 @@
+/* { dg-additional-options "-fdump-tree-original" } */
+/* PR preprocessor/103165 */
+
+#define inner(...) #__VA_ARGS__ ; _Pragma("omp error severity(warning) message (\"Test\") at(compilation)")
+#define outer(...) inner(__VA_ARGS__)
+
+void
+f (void)
+{
+ const char *str = outer(inner(1,2)); /* { dg-warning "'pragma omp error' encountered: Test" } */
+}
+
+#if 0
+After preprocessing, the expected result are the following three lines:
+ const char *str = "\"1,2\" ; _Pragma(\"omp error severity(warning) message (\\\"Test\\\") at(compilation)\")" ;
+#pragma omp error severity(warning) message ("Test") at(compilation)
+ ;
+#endif
+
+/* { dg-final { scan-tree-dump "const char \\* str = \\(const char \\*\\) \"\\\\\"1,2\\\\\" ; _Pragma\\(\\\\\"omp error severity\\(warning\\) message \\(\\\\\\\\\\\\\"Test\\\\\\\\\\\\\"\\) at\\(compilation\\)\\\\\"\\)\";" "original" } } */
--- gcc/testsuite/c-c++-common/gomp/pragma-4.c.jj 2021-11-20 11:04:35.355319742 +0100
+++ gcc/testsuite/c-c++-common/gomp/pragma-4.c 2021-11-20 11:28:22.995078169 +0100
@@ -0,0 +1,20 @@
+/* { dg-additional-options "-fdump-tree-original -save-temps" } */
+/* PR preprocessor/103165 */
+
+#define inner(...) #__VA_ARGS__ ; _Pragma("omp error severity(warning) message (\"Test\") at(compilation)")
+#define outer(...) inner(__VA_ARGS__)
+
+void
+f (void)
+{
+ const char *str = outer(inner(1,2)); /* { dg-warning "'pragma omp error' encountered: Test" } */
+}
+
+#if 0
+After preprocessing, the expected result are the following three lines:
+ const char *str = "\"1,2\" ; _Pragma(\"omp error severity(warning) message (\\\"Test\\\") at(compilation)\")" ;
+#pragma omp error severity(warning) message ("Test") at(compilation)
+ ;
+#endif
+
+/* { dg-final { scan-tree-dump "const char \\* str = \\(const char \\*\\) \"\\\\\"1,2\\\\\" ; _Pragma\\(\\\\\"omp error severity\\(warning\\) message \\(\\\\\\\\\\\\\"Test\\\\\\\\\\\\\"\\) at\\(compilation\\)\\\\\"\\)\";" "original" } } */
--- gcc/testsuite/c-c++-common/gomp/pragma-5.c.jj 2021-11-20 11:05:22.855645064 +0100
+++ gcc/testsuite/c-c++-common/gomp/pragma-5.c 2021-11-20 11:30:33.777227520 +0100
@@ -0,0 +1,20 @@
+/* { dg-additional-options "-fdump-tree-original" } */
+/* PR preprocessor/103165 */
+
+#define inner(...) #__VA_ARGS__ ; _Pragma ( " omp error severity (warning) message (\"Test\") at(compilation)" )
+#define outer(...) inner(__VA_ARGS__)
+
+void
+f (void)
+{
+ const char *str = outer(inner(1,2)); /* { dg-warning "'pragma omp error' encountered: Test" } */
+}
+
+#if 0
+After preprocessing, the expected result are the following three lines:
+ const char *str = "\"1,2\" ; _Pragma ( \" omp error severity (warning) message (\\\"Test\\\") at(compilation)\" )" ;
+#pragma omp error severity(warning) message ("Test") at(compilation)
+ ;
+#endif
+
+/* { dg-final { scan-tree-dump "const char \\* str = \\(const char \\*\\) \"\\\\\"1,2\\\\\" ; _Pragma \\( \\\\\" omp\\\\t\\\\terror severity \\(warning\\)\\\\tmessage \\(\\\\\\\\\\\\\"Test\\\\\\\\\\\\\"\\) at\\(compilation\\)\\\\\" \\)\";" "original" } } */
Jakub
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] libcpp, v2: Fix _Pragma in #__VA_ARGS__ [PR103165]
2021-11-22 9:23 ` [PATCH] libcpp, v2: " Jakub Jelinek
@ 2021-11-22 20:56 ` Joseph Myers
0 siblings, 0 replies; 6+ messages in thread
From: Joseph Myers @ 2021-11-22 20:56 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: Tobias Burnus, gcc-patches
On Mon, 22 Nov 2021, Jakub Jelinek via Gcc-patches wrote:
> On Thu, Nov 18, 2021 at 09:55:52PM +0000, Joseph Myers wrote:
> > On Thu, 18 Nov 2021, Jakub Jelinek via Gcc-patches wrote:
> >
> > > Are we handling the pragma at a wrong phase of preprocessing?
> >
> > I think that converting it to a single preprocessing token (rather than
> > four separate preprocessing tokens), at a stage when stringizing might
> > still occur, does indicate it's being processed too soon, and it would be
> > better to do that only when it's known that the _Pragma preprocessing
> > token will actually occur in the results of preprocessing the source file.
>
> So like this? I.e. don't process _Pragma during expand_args where we can't
> know what the macro will do with it?
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
OK.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-11-22 20:56 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-11-10 20:12 [Patch] libcpp: Fix _Pragma in #__VA_ARGS__ [PR103165] Tobias Burnus
2021-11-10 21:30 ` Joseph Myers
2021-11-18 11:24 ` Jakub Jelinek
2021-11-18 21:55 ` Joseph Myers
2021-11-22 9:23 ` [PATCH] libcpp, v2: " Jakub Jelinek
2021-11-22 20:56 ` Joseph Myers
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).