c: Fix location for _Pragma tokens [PR97498]
Commit Message
Hello-
PR97498 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97498) is another PR
related to the fact that imprecise locations for _Pragma result in
counterintuitive behavior for GCC diagnostic pragmas, which inhibit the
ability to make convenient wrapper macros for enabling and disabling
diagnostics in specific scopes.
It looks like David did a lot of work a few years ago improving this
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69543 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69558), and in particular
r233637 added a lot of new test coverage for cases that had regressed in the
past.
I think the main source of problems for all remaining issues is that we use
the global input_location for deciding when/if a diagnostic should apply. I
think it should be eventually doable to eliminate this, and rather properly
resolve the token locations to the place they need to be so that _Pragma
type wrapper macros just work the way people expect.
That said, PR97498 can be solved easily with a 2-line fix without removing
input_location, and I think the resulting change to input_location's value
is an improvement that will benefit other areas, so I thought I'd see what
you think about this patch please?
Here is a typical testcase. Note the line continuations so it's all one
logical line.
===
_Pragma("GCC diagnostic push") \
_Pragma("GCC diagnostic ignored \"-Wunused-function\"") \
static void f() {} \
_Pragma("GCC diagnostic pop")
===
What happens is that in C++ mode, input_location is always updated to the
most recently-lexed token, so the above case works fine and does not warn
when compiled with "g++ -Wunused-functions". However, in C mode, it does
warn because input_location in C is almost always set to the start of the
line, and is in this case. So the pop is deemed to take place prior to the
definition of f().
Initially, I thought it best to change input_location for C mode to behave
like C++, and always update to the most recently lexed token. Maybe that's
still the right way to go, but there was a fair amount of testsuite fallout
from that. Most of it, was just that we would need to change the tests to look
for the new locations, and in many cases, the new locations seemed
preferable to the old ones, but it seemed a bit much for now, so I took a
more measured approach and just changed input_location in the specific case
of processing a pragma, to be the location of the CPP_PRAGMA token.
Unfortunately, it turns out that the CPP_PRAGMA token that libcpp provides
to represent the _Pragma() expression doesn't have a valid location with
which input_location could be overridden. Looking into that, in r232893
David added logic which sets the location of all tokens inside the
_Pragma(...) to a reasonable place (namely it points to "_Pragma" at the
expansion point). However, that patch didn't change the location of the
CPP_PRAGMA token itself to similarly point there, so the 2nd line of this
patch does that.
The rest of it is just tweaking a couple tests which were sensitive to the
location being output. In all these cases, the new locations seem more
informative to me than the old ones. With those tweaks, bootstrap + regtest
all languages looks good with no regressions.
Please let me know what you think? Thanks!
-Lewis
[PATCH] c: Fix location for _Pragma tokens [PR97498]
The handling of #pragma GCC diagnostic uses input_location, which is not always
as precise as needed; in particular the relative location of some tokens and a
_Pragma directive will crucially determine whether a given diagnostic is enabled
or suppressed in the desired way. PR97498 shows how the C frontend ends up with
input_location pointing to the beginning of the line containing a _Pragma()
directive, resulting in the wrong behavior if the diagnostic to be modified
pertains to some tokens found earlier on the same line. This patch fixes that by
addressing two issues:
a) libcpp was not assigning a valid location to the CPP_PRAGMA token
generated by the _Pragma directive.
b) C frontend was not setting input_location to something reasonable.
With this change, the C frontend is able to change input_location to point to
the _Pragma token as needed.
This is just a two-line fix (one for each of a) and b)), the testsuite changes
were needed only because the location on the tested warnings has been somewhat
improved, so the tests need to look for the new locations.
gcc/c/ChangeLog:
PR preprocessor/97498
* c-parser.cc (c_parser_pragma): Set input_location to the
location of the pragma, rather than the start of the line.
libcpp/ChangeLog:
PR preprocessor/97498
* directives.cc (destringize_and_run): Override the location of
the CPP_PRAGMA token from a _Pragma directive to the location of
the expansion point, as is done for the tokens lexed from it.
gcc/testsuite/ChangeLog:
PR preprocessor/97498
* c-c++-common/pr97498.c: New test.
* c-c++-common/gomp/pragma-3.c: Adapt for improved warning locations.
* c-c++-common/gomp/pragma-5.c: Likewise.
* gcc.dg/pragma-message.c: Likewise.
libgomp/ChangeLog:
* testsuite/libgomp.oacc-c-c++-common/reduction-5.c: Adapt for
improved warning locations.
* testsuite/libgomp.oacc-c-c++-common/vred2d-128.c: Likewise.
Comments
On 7/9/2022 2:52 PM, Lewis Hyatt via Gcc-patches wrote:
> Hello-
>
> PR97498 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97498) is another PR
> related to the fact that imprecise locations for _Pragma result in
> counterintuitive behavior for GCC diagnostic pragmas, which inhibit the
> ability to make convenient wrapper macros for enabling and disabling
> diagnostics in specific scopes.
>
> It looks like David did a lot of work a few years ago improving this
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69543 and
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69558), and in particular
> r233637 added a lot of new test coverage for cases that had regressed in the
> past.
>
> I think the main source of problems for all remaining issues is that we use
> the global input_location for deciding when/if a diagnostic should apply. I
> think it should be eventually doable to eliminate this, and rather properly
> resolve the token locations to the place they need to be
I've long wanted to see our dependency on input_location be diminished
with the goal of making it go away completely.
> so that _Pragma
> type wrapper macros just work the way people expect.
Certainly desirable since many projects have built wrapper macros which
use Pragmas to control warnings. One of the biggest QOI implementation
details we've had with the warnings has been problems with location data
leading to an inability to turn them off in specific locations.
So I'm all for improvements, in terms of getting our location data more
correct.
>
> That said, PR97498 can be solved easily with a 2-line fix without removing
> input_location, and I think the resulting change to input_location's value
> is an improvement that will benefit other areas, so I thought I'd see what
> you think about this patch please?
>
> Here is a typical testcase. Note the line continuations so it's all one
> logical line.
>
> ===
> _Pragma("GCC diagnostic push") \
> _Pragma("GCC diagnostic ignored \"-Wunused-function\"") \
> static void f() {} \
> _Pragma("GCC diagnostic pop")
> ===
>
> What happens is that in C++ mode, input_location is always updated to the
> most recently-lexed token, so the above case works fine and does not warn
> when compiled with "g++ -Wunused-functions". However, in C mode, it does
> warn because input_location in C is almost always set to the start of the
> line, and is in this case. So the pop is deemed to take place prior to the
> definition of f().
>
> Initially, I thought it best to change input_location for C mode to behave
> like C++, and always update to the most recently lexed token. Maybe that's
> still the right way to go, but there was a fair amount of testsuite fallout
> from that. Most of it, was just that we would need to change the tests to look
> for the new locations, and in many cases, the new locations seemed
> preferable to the old ones, but it seemed a bit much for now, so I took a
> more measured approach and just changed input_location in the specific case
> of processing a pragma, to be the location of the CPP_PRAGMA token.
>
> Unfortunately, it turns out that the CPP_PRAGMA token that libcpp provides
> to represent the _Pragma() expression doesn't have a valid location with
> which input_location could be overridden. Looking into that, in r232893
> David added logic which sets the location of all tokens inside the
> _Pragma(...) to a reasonable place (namely it points to "_Pragma" at the
> expansion point). However, that patch didn't change the location of the
> CPP_PRAGMA token itself to similarly point there, so the 2nd line of this
> patch does that.
>
> The rest of it is just tweaking a couple tests which were sensitive to the
> location being output. In all these cases, the new locations seem more
> informative to me than the old ones. With those tweaks, bootstrap + regtest
> all languages looks good with no regressions.
>
> Please let me know what you think? Thanks!
> gcc/c/ChangeLog:
>
> PR preprocessor/97498
> * c-parser.cc (c_parser_pragma): Set input_location to the
> location of the pragma, rather than the start of the line.
>
> libcpp/ChangeLog:
>
> PR preprocessor/97498
> * directives.cc (destringize_and_run): Override the location of
> the CPP_PRAGMA token from a _Pragma directive to the location of
> the expansion point, as is done for the tokens lexed from it.
>
> gcc/testsuite/ChangeLog:
>
> PR preprocessor/97498
> * c-c++-common/pr97498.c: New test.
> * c-c++-common/gomp/pragma-3.c: Adapt for improved warning locations.
> * c-c++-common/gomp/pragma-5.c: Likewise.
> * gcc.dg/pragma-message.c: Likewise.
>
> libgomp/ChangeLog:
>
> * testsuite/libgomp.oacc-c-c++-common/reduction-5.c: Adapt for
> improved warning locations.
> * testsuite/libgomp.oacc-c-c++-common/vred2d-128.c: Likewise.
OK for the trunk. Thanks for digging into this!
jeff
On Sat, Jul 9, 2022 at 11:59 PM Jeff Law via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
>
>
> On 7/9/2022 2:52 PM, Lewis Hyatt via Gcc-patches wrote:
> > Hello-
> >
> > PR97498 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97498) is another PR
> > related to the fact that imprecise locations for _Pragma result in
> > counterintuitive behavior for GCC diagnostic pragmas, which inhibit the
> > ability to make convenient wrapper macros for enabling and disabling
> > diagnostics in specific scopes.
> >
> > It looks like David did a lot of work a few years ago improving this
> > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69543 and
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69558), and in particular
> > r233637 added a lot of new test coverage for cases that had regressed in the
> > past.
> >
> > I think the main source of problems for all remaining issues is that we use
> > the global input_location for deciding when/if a diagnostic should apply. I
> > think it should be eventually doable to eliminate this, and rather properly
> > resolve the token locations to the place they need to be
> I've long wanted to see our dependency on input_location be diminished
> with the goal of making it go away completely.
> > so that _Pragma
> > type wrapper macros just work the way people expect.
> Certainly desirable since many projects have built wrapper macros which
> use Pragmas to control warnings. One of the biggest QOI implementation
> details we've had with the warnings has been problems with location data
> leading to an inability to turn them off in specific locations.
>
> So I'm all for improvements, in terms of getting our location data more
> correct.
>
>
>
> >
> > That said, PR97498 can be solved easily with a 2-line fix without removing
> > input_location, and I think the resulting change to input_location's value
> > is an improvement that will benefit other areas, so I thought I'd see what
> > you think about this patch please?
> >
> > Here is a typical testcase. Note the line continuations so it's all one
> > logical line.
> >
> > ===
> > _Pragma("GCC diagnostic push") \
> > _Pragma("GCC diagnostic ignored \"-Wunused-function\"") \
> > static void f() {} \
> > _Pragma("GCC diagnostic pop")
> > ===
> >
> > What happens is that in C++ mode, input_location is always updated to the
> > most recently-lexed token, so the above case works fine and does not warn
> > when compiled with "g++ -Wunused-functions". However, in C mode, it does
> > warn because input_location in C is almost always set to the start of the
> > line, and is in this case. So the pop is deemed to take place prior to the
> > definition of f().
> >
> > Initially, I thought it best to change input_location for C mode to behave
> > like C++, and always update to the most recently lexed token. Maybe that's
> > still the right way to go, but there was a fair amount of testsuite fallout
> > from that. Most of it, was just that we would need to change the tests to look
> > for the new locations, and in many cases, the new locations seemed
> > preferable to the old ones, but it seemed a bit much for now, so I took a
> > more measured approach and just changed input_location in the specific case
> > of processing a pragma, to be the location of the CPP_PRAGMA token.
> >
> > Unfortunately, it turns out that the CPP_PRAGMA token that libcpp provides
> > to represent the _Pragma() expression doesn't have a valid location with
> > which input_location could be overridden. Looking into that, in r232893
> > David added logic which sets the location of all tokens inside the
> > _Pragma(...) to a reasonable place (namely it points to "_Pragma" at the
> > expansion point). However, that patch didn't change the location of the
> > CPP_PRAGMA token itself to similarly point there, so the 2nd line of this
> > patch does that.
> >
> > The rest of it is just tweaking a couple tests which were sensitive to the
> > location being output. In all these cases, the new locations seem more
> > informative to me than the old ones. With those tweaks, bootstrap + regtest
> > all languages looks good with no regressions.
> >
> > Please let me know what you think? Thanks!
> > gcc/c/ChangeLog:
> >
> > PR preprocessor/97498
> > * c-parser.cc (c_parser_pragma): Set input_location to the
> > location of the pragma, rather than the start of the line.
> >
> > libcpp/ChangeLog:
> >
> > PR preprocessor/97498
> > * directives.cc (destringize_and_run): Override the location of
> > the CPP_PRAGMA token from a _Pragma directive to the location of
> > the expansion point, as is done for the tokens lexed from it.
> >
> > gcc/testsuite/ChangeLog:
> >
> > PR preprocessor/97498
> > * c-c++-common/pr97498.c: New test.
> > * c-c++-common/gomp/pragma-3.c: Adapt for improved warning locations.
> > * c-c++-common/gomp/pragma-5.c: Likewise.
> > * gcc.dg/pragma-message.c: Likewise.
> >
> > libgomp/ChangeLog:
> >
> > * testsuite/libgomp.oacc-c-c++-common/reduction-5.c: Adapt for
> > improved warning locations.
> > * testsuite/libgomp.oacc-c-c++-common/vred2d-128.c: Likewise.
> OK for the trunk. Thanks for digging into this!
Thanks very much for the feedback, this has been committed. I realized
that I need a similar 1-line patch for gcc -E, to similarly set
input_location to something reasonable (there it's worse actually,
input_location is always the first byte of the file currently). I'll
email that later after testing completes. Then I will plan to work on
eliminating input_location from c-pragma.cc as a longer term goal.
-Lewis
On Sat, Jul 9, 2022 at 11:59 PM Jeff Law via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
>
>
> On 7/9/2022 2:52 PM, Lewis Hyatt via Gcc-patches wrote:
> > Hello-
> >
> > PR97498 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97498) is another PR
> > related to the fact that imprecise locations for _Pragma result in
> > counterintuitive behavior for GCC diagnostic pragmas, which inhibit the
> > ability to make convenient wrapper macros for enabling and disabling
> > diagnostics in specific scopes.
> >
> > It looks like David did a lot of work a few years ago improving this
> > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69543 and
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69558), and in particular
> > r233637 added a lot of new test coverage for cases that had regressed in the
> > past.
> >
> > I think the main source of problems for all remaining issues is that we use
> > the global input_location for deciding when/if a diagnostic should apply. I
> > think it should be eventually doable to eliminate this, and rather properly
> > resolve the token locations to the place they need to be
> I've long wanted to see our dependency on input_location be diminished
> with the goal of making it go away completely.
> > so that _Pragma
> > type wrapper macros just work the way people expect.
> Certainly desirable since many projects have built wrapper macros which
> use Pragmas to control warnings. One of the biggest QOI implementation
> details we've had with the warnings has been problems with location data
> leading to an inability to turn them off in specific locations.
>
> So I'm all for improvements, in terms of getting our location data more
> correct.
>
>
>
> >
> > That said, PR97498 can be solved easily with a 2-line fix without removing
> > input_location, and I think the resulting change to input_location's value
> > is an improvement that will benefit other areas, so I thought I'd see what
> > you think about this patch please?
> >
> > Here is a typical testcase. Note the line continuations so it's all one
> > logical line.
> >
> > ===
> > _Pragma("GCC diagnostic push") \
> > _Pragma("GCC diagnostic ignored \"-Wunused-function\"") \
> > static void f() {} \
> > _Pragma("GCC diagnostic pop")
> > ===
> >
> > What happens is that in C++ mode, input_location is always updated to the
> > most recently-lexed token, so the above case works fine and does not warn
> > when compiled with "g++ -Wunused-functions". However, in C mode, it does
> > warn because input_location in C is almost always set to the start of the
> > line, and is in this case. So the pop is deemed to take place prior to the
> > definition of f().
> >
> > Initially, I thought it best to change input_location for C mode to behave
> > like C++, and always update to the most recently lexed token. Maybe that's
> > still the right way to go, but there was a fair amount of testsuite fallout
> > from that. Most of it, was just that we would need to change the tests to look
> > for the new locations, and in many cases, the new locations seemed
> > preferable to the old ones, but it seemed a bit much for now, so I took a
> > more measured approach and just changed input_location in the specific case
> > of processing a pragma, to be the location of the CPP_PRAGMA token.
> >
> > Unfortunately, it turns out that the CPP_PRAGMA token that libcpp provides
> > to represent the _Pragma() expression doesn't have a valid location with
> > which input_location could be overridden. Looking into that, in r232893
> > David added logic which sets the location of all tokens inside the
> > _Pragma(...) to a reasonable place (namely it points to "_Pragma" at the
> > expansion point). However, that patch didn't change the location of the
> > CPP_PRAGMA token itself to similarly point there, so the 2nd line of this
> > patch does that.
> >
> > The rest of it is just tweaking a couple tests which were sensitive to the
> > location being output. In all these cases, the new locations seem more
> > informative to me than the old ones. With those tweaks, bootstrap + regtest
> > all languages looks good with no regressions.
> >
> > Please let me know what you think? Thanks!
> > gcc/c/ChangeLog:
> >
> > PR preprocessor/97498
> > * c-parser.cc (c_parser_pragma): Set input_location to the
> > location of the pragma, rather than the start of the line.
> >
> > libcpp/ChangeLog:
> >
> > PR preprocessor/97498
> > * directives.cc (destringize_and_run): Override the location of
> > the CPP_PRAGMA token from a _Pragma directive to the location of
> > the expansion point, as is done for the tokens lexed from it.
> >
> > gcc/testsuite/ChangeLog:
> >
> > PR preprocessor/97498
> > * c-c++-common/pr97498.c: New test.
> > * c-c++-common/gomp/pragma-3.c: Adapt for improved warning locations.
> > * c-c++-common/gomp/pragma-5.c: Likewise.
> > * gcc.dg/pragma-message.c: Likewise.
> >
> > libgomp/ChangeLog:
> >
> > * testsuite/libgomp.oacc-c-c++-common/reduction-5.c: Adapt for
> > improved warning locations.
> > * testsuite/libgomp.oacc-c-c++-common/vred2d-128.c: Likewise.
> OK for the trunk. Thanks for digging into this!
>
> jeff
>
There was a request to backport this
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97498#c7) since it is
relevant to this one:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106267. Is that OK as
well for any of the current release branches please? It will work fine
as far back as 10. Thanks...
-Lewis
On 7/17/2022 9:24 AM, Lewis Hyatt wrote:
> On Sat, Jul 9, 2022 at 11:59 PM Jeff Law via Gcc-patches
> <gcc-patches@gcc.gnu.org> wrote:
>>
>>
>> On 7/9/2022 2:52 PM, Lewis Hyatt via Gcc-patches wrote:
>>> Hello-
>>>
>>> PR97498 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97498) is another PR
>>> related to the fact that imprecise locations for _Pragma result in
>>> counterintuitive behavior for GCC diagnostic pragmas, which inhibit the
>>> ability to make convenient wrapper macros for enabling and disabling
>>> diagnostics in specific scopes.
>>>
>>> It looks like David did a lot of work a few years ago improving this
>>> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69543 and
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69558), and in particular
>>> r233637 added a lot of new test coverage for cases that had regressed in the
>>> past.
>>>
>>> I think the main source of problems for all remaining issues is that we use
>>> the global input_location for deciding when/if a diagnostic should apply. I
>>> think it should be eventually doable to eliminate this, and rather properly
>>> resolve the token locations to the place they need to be
>> I've long wanted to see our dependency on input_location be diminished
>> with the goal of making it go away completely.
>>> so that _Pragma
>>> type wrapper macros just work the way people expect.
>> Certainly desirable since many projects have built wrapper macros which
>> use Pragmas to control warnings. One of the biggest QOI implementation
>> details we've had with the warnings has been problems with location data
>> leading to an inability to turn them off in specific locations.
>>
>> So I'm all for improvements, in terms of getting our location data more
>> correct.
>>
>>
>>
>>> That said, PR97498 can be solved easily with a 2-line fix without removing
>>> input_location, and I think the resulting change to input_location's value
>>> is an improvement that will benefit other areas, so I thought I'd see what
>>> you think about this patch please?
>>>
>>> Here is a typical testcase. Note the line continuations so it's all one
>>> logical line.
>>>
>>> ===
>>> _Pragma("GCC diagnostic push") \
>>> _Pragma("GCC diagnostic ignored \"-Wunused-function\"") \
>>> static void f() {} \
>>> _Pragma("GCC diagnostic pop")
>>> ===
>>>
>>> What happens is that in C++ mode, input_location is always updated to the
>>> most recently-lexed token, so the above case works fine and does not warn
>>> when compiled with "g++ -Wunused-functions". However, in C mode, it does
>>> warn because input_location in C is almost always set to the start of the
>>> line, and is in this case. So the pop is deemed to take place prior to the
>>> definition of f().
>>>
>>> Initially, I thought it best to change input_location for C mode to behave
>>> like C++, and always update to the most recently lexed token. Maybe that's
>>> still the right way to go, but there was a fair amount of testsuite fallout
>>> from that. Most of it, was just that we would need to change the tests to look
>>> for the new locations, and in many cases, the new locations seemed
>>> preferable to the old ones, but it seemed a bit much for now, so I took a
>>> more measured approach and just changed input_location in the specific case
>>> of processing a pragma, to be the location of the CPP_PRAGMA token.
>>>
>>> Unfortunately, it turns out that the CPP_PRAGMA token that libcpp provides
>>> to represent the _Pragma() expression doesn't have a valid location with
>>> which input_location could be overridden. Looking into that, in r232893
>>> David added logic which sets the location of all tokens inside the
>>> _Pragma(...) to a reasonable place (namely it points to "_Pragma" at the
>>> expansion point). However, that patch didn't change the location of the
>>> CPP_PRAGMA token itself to similarly point there, so the 2nd line of this
>>> patch does that.
>>>
>>> The rest of it is just tweaking a couple tests which were sensitive to the
>>> location being output. In all these cases, the new locations seem more
>>> informative to me than the old ones. With those tweaks, bootstrap + regtest
>>> all languages looks good with no regressions.
>>>
>>> Please let me know what you think? Thanks!
>>> gcc/c/ChangeLog:
>>>
>>> PR preprocessor/97498
>>> * c-parser.cc (c_parser_pragma): Set input_location to the
>>> location of the pragma, rather than the start of the line.
>>>
>>> libcpp/ChangeLog:
>>>
>>> PR preprocessor/97498
>>> * directives.cc (destringize_and_run): Override the location of
>>> the CPP_PRAGMA token from a _Pragma directive to the location of
>>> the expansion point, as is done for the tokens lexed from it.
>>>
>>> gcc/testsuite/ChangeLog:
>>>
>>> PR preprocessor/97498
>>> * c-c++-common/pr97498.c: New test.
>>> * c-c++-common/gomp/pragma-3.c: Adapt for improved warning locations.
>>> * c-c++-common/gomp/pragma-5.c: Likewise.
>>> * gcc.dg/pragma-message.c: Likewise.
>>>
>>> libgomp/ChangeLog:
>>>
>>> * testsuite/libgomp.oacc-c-c++-common/reduction-5.c: Adapt for
>>> improved warning locations.
>>> * testsuite/libgomp.oacc-c-c++-common/vred2d-128.c: Likewise.
>> OK for the trunk. Thanks for digging into this!
>>
>> jeff
>>
> There was a request to backport this
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97498#c7) since it is
> relevant to this one:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106267. Is that OK as
> well for any of the current release branches please? It will work fine
> as far back as 10. Thanks...
Generally we try to focus mostly on codegen issues and regressions on
the release branches, but it's not a strict rule. Given this has been
on the trunk for nearly a couple weeks without issues, feel free to go
ahead and backport per Martin's request.
jeff
On Sat, Jul 30, 2022 at 10:43 PM Jeff Law <jeffreyalaw@gmail.com> wrote:
> > There was a request to backport this
> > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97498#c7) since it is
> > relevant to this one:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106267. Is that OK as
> > well for any of the current release branches please? It will work fine
> > as far back as 10. Thanks...
> Generally we try to focus mostly on codegen issues and regressions on
> the release branches, but it's not a strict rule. Given this has been
> on the trunk for nearly a couple weeks without issues, feel free to go
> ahead and backport per Martin's request.
>
> jeff
Thank you, I'll do that. One question, does a backport need to be an
exact cherry-pick, or is it OK if I need to tweak a few things as
well? I wasn't sure if I need to re-post the patch here in that case.
The patch itself applies to gcc 12 branch fine, however I think I need
a couple small changes to the testsuite parts. Thanks...
-Lewis
On 7/31/2022 6:44 AM, Lewis Hyatt wrote:
> On Sat, Jul 30, 2022 at 10:43 PM Jeff Law <jeffreyalaw@gmail.com> wrote:
>>> There was a request to backport this
>>> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97498#c7) since it is
>>> relevant to this one:
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106267. Is that OK as
>>> well for any of the current release branches please? It will work fine
>>> as far back as 10. Thanks...
>> Generally we try to focus mostly on codegen issues and regressions on
>> the release branches, but it's not a strict rule. Given this has been
>> on the trunk for nearly a couple weeks without issues, feel free to go
>> ahead and backport per Martin's request.
>>
>> jeff
> Thank you, I'll do that. One question, does a backport need to be an
> exact cherry-pick, or is it OK if I need to tweak a few things as
> well? I wasn't sure if I need to re-post the patch here in that case.
> The patch itself applies to gcc 12 branch fine, however I think I need
> a couple small changes to the testsuite parts. Thanks...
I personally prefer cherry-pick when we can, but as you note, sometimes
minor twiddling is necessary, particularly as you go to older and older
branches. If you need to make minor changes, go ahead. Consider the
patch pre-approved with any minor changes you need to make to work with
the branch and just post the patch with a note that it was installed as
pre-approved.
Jeff
@@ -12397,6 +12397,7 @@ c_parser_pragma (c_parser *parser, enum pragma_context context, bool *if_p)
unsigned int id;
const char *construct = NULL;
+ input_location = c_parser_peek_token (parser)->location;
id = c_parser_peek_token (parser)->pragma_kind;
gcc_assert (id != PRAGMA_NONE);
@@ -1,13 +1,14 @@
/* { dg-additional-options "-fdump-tree-original" } */
/* PR preprocessor/103165 */
-#define inner(...) #__VA_ARGS__ ; _Pragma("omp error severity(warning) message (\"Test\") at(compilation)")
+#define inner(...) #__VA_ARGS__ ; _Pragma("omp error severity(warning) message (\"Test\") at(compilation)") /* { dg-line inner_location } */
#define outer(...) inner(__VA_ARGS__)
void
f (void)
{
- const char *str = outer(inner(1,2)); /* { dg-warning "'pragma omp error' encountered: Test" } */
+ const char *str = outer(inner(1,2));
+ /* { dg-warning "'pragma omp error' encountered: Test" "inner expansion" { target *-*-* } inner_location } */
}
#if 0
@@ -1,13 +1,14 @@
/* { dg-additional-options "-fdump-tree-original" } */
/* PR preprocessor/103165 */
-#define inner(...) #__VA_ARGS__ ; _Pragma ( " omp error severity (warning) message (\"Test\") at(compilation)" )
+#define inner(...) #__VA_ARGS__ ; _Pragma ( " omp error severity (warning) message (\"Test\") at(compilation)" ) /* { dg-line inner_location } */
#define outer(...) inner(__VA_ARGS__)
void
f (void)
{
- const char *str = outer(inner(1,2)); /* { dg-warning "'pragma omp error' encountered: Test" } */
+ const char *str = outer(inner(1,2));
+ /* { dg-warning "'pragma omp error' encountered: Test" "inner expansion" { target *-*-* } inner_location } */
}
#if 0
new file mode 100644
@@ -0,0 +1,4 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-Wunused-function" } */
+#pragma GCC diagnostic ignored "-Wunused-function"
+static void f() {} _Pragma("GCC diagnostic error \"-Wunused-function\"") /* { dg-bogus "-Wunused-function" } */
@@ -42,9 +42,11 @@
#pragma message ("Okay " THREE) /* { dg-message "Okay 3" } */
/* Create a TODO() that prints a message on compilation. */
-#define DO_PRAGMA(x) _Pragma (#x)
-#define TODO(x) DO_PRAGMA(message ("TODO - " #x))
-TODO(Okay 4) /* { dg-message "TODO - Okay 4" } */
+#define DO_PRAGMA(x) _Pragma (#x) /* { dg-line pragma_loc1 } */
+#define TODO(x) DO_PRAGMA(message ("TODO - " #x)) /* { dg-line pragma_loc2 } */
+TODO(Okay 4) /* { dg-message "in expansion of macro 'TODO'" } */
+/* { dg-message "TODO - Okay 4" "test4.1" { target *-*-* } pragma_loc1 } */
+/* { dg-message "in expansion of macro 'DO_PRAGMA'" "test4.2" { target *-*-* } pragma_loc2 } */
#if 0
#pragma message ("Not printed")
@@ -1930,6 +1930,7 @@ destringize_and_run (cpp_reader *pfile, const cpp_string *in,
maxcount = 50;
toks = XNEWVEC (cpp_token, maxcount);
toks[0] = pfile->directive_result;
+ toks[0].src_loc = expansion_loc;
do
{
@@ -12,7 +12,7 @@
const int n = 100;
-#define DO_PRAGMA(x) _Pragma (#x)
+#define DO_PRAGMA(x) _Pragma (#x) /* { dg-line pragma_loc } */
#define check_reduction(gwv_par, gwv_loop) \
{ \
@@ -46,7 +46,7 @@ main (void)
/* Nvptx targets require a vector_length or 32 in to allow spinlocks with
gangs. */
check_reduction (num_workers (nw) vector_length (vl), worker);
- /* { dg-warning "region is vector partitioned but does not contain vector partitioned code" "" { target *-*-* } .-1 } */
+ /* { dg-warning "region is vector partitioned but does not contain vector partitioned code" "test1" { target *-*-* } pragma_loc } */
check_reduction (vector_length (vl), vector);
check_reduction (num_gangs (ng) num_workers (nw) vector_length (vl), gang
worker vector);
@@ -17,7 +17,7 @@ int a1[n], a2[n];
void name () \
{ \
long i, j, t1, t2, t3; /* { dg-line vars } */ \
- _Pragma(outer) \
+ _Pragma(outer) /* { dg-line outer } */ \
for (i = 0; i < n; i++) \
{ \
t1 = 0; \
@@ -40,44 +40,44 @@ int a1[n], a2[n];
gentest (test1, "acc parallel loop gang vector_length (128) firstprivate (t1, t2)",
"acc loop vector reduction(+:t1) reduction(-:t2)")
-/* { dg-warning {'t1' is used uninitialized} {} { target *-*-* } .-1 }
+/* { dg-warning {'t1' is used uninitialized} {} { target *-*-* } outer }
{ dg-note {'t1' was declared here} {} { target *-*-* } vars }
{ dg-note {in expansion of macro 'gentest'} {} { target { ! offloading_enabled } } .-4 }
TODO See PR101551 for 'offloading_enabled' differences. */
-/* { dg-warning {'t2' is used uninitialized} {} { target *-*-* } .-5 }
+/* { dg-warning {'t2' is used uninitialized} {} { target *-*-* } outer }
{ dg-note {'t2' was declared here} {} { target *-*-* } vars }
{ DUP_dg-note {in expansion of macro 'gentest'} {} { target { ! offloading_enabled } } .-8 }
TODO See PR101551 for 'offloading_enabled' differences. */
gentest (test2, "acc parallel loop gang vector_length (128) firstprivate (t1, t2)",
"acc loop worker vector reduction(+:t1) reduction(-:t2)")
-/* { dg-warning {'t1' is used uninitialized} {} { target *-*-* } .-1 }
+/* { DUPdg-warning {'t1' is used uninitialized} {} { target *-*-* } outer }
{ DUP_dg-note {'t1' was declared here} {} { target *-*-* } vars }
{ dg-note {in expansion of macro 'gentest'} {} { target { ! offloading_enabled } } .-4 }
TODO See PR101551 for 'offloading_enabled' differences. */
-/* { dg-warning {'t2' is used uninitialized} {} { target *-*-* } .-5 }
+/* { DUPdg-warning {'t2' is used uninitialized} {} { target *-*-* } outer }
{ DUP_dg-note {'t2' was declared here} {} { target *-*-* } vars }
{ DUP_dg-note {in expansion of macro 'gentest'} {} { target { ! offloading_enabled } } .-8 }
TODO See PR101551 for 'offloading_enabled' differences. */
gentest (test3, "acc parallel loop gang worker vector_length (128) firstprivate (t1, t2)",
"acc loop vector reduction(+:t1) reduction(-:t2)")
-/* { dg-warning {'t1' is used uninitialized} {} { target *-*-* } .-1 }
+/* { DUPdg-warning {'t1' is used uninitialized} {} { target *-*-* } outer }
{ DUP_dg-note {'t1' was declared here} {} { target *-*-* } vars }
{ dg-note {in expansion of macro 'gentest'} {} { target { ! offloading_enabled } } .-4 }
TODO See PR101551 for 'offloading_enabled' differences. */
-/* { dg-warning {'t2' is used uninitialized} {} { target *-*-* } .-5 }
+/* { DUPdg-warning {'t2' is used uninitialized} {} { target *-*-* } outer }
{ DUP_dg-note {'t2' was declared here} {} { target *-*-* } vars }
{ DUP_dg-note {in expansion of macro 'gentest'} {} { target { ! offloading_enabled } } .-8 }
TODO See PR101551 for 'offloading_enabled' differences. */
gentest (test4, "acc parallel loop firstprivate (t1, t2)",
"acc loop reduction(+:t1) reduction(-:t2)")
-/* { dg-warning {'t1' is used uninitialized} {} { target *-*-* } .-1 }
+/* { DUPdg-warning {'t1' is used uninitialized} {} { target *-*-* } outer }
{ DUP_dg-note {'t1' was declared here} {} { target *-*-* } vars }
{ dg-note {in expansion of macro 'gentest'} {} { target { ! offloading_enabled } } .-4 }
TODO See PR101551 for 'offloading_enabled' differences. */
-/* { dg-warning {'t2' is used uninitialized} {} { target *-*-* } .-5 }
+/* { DUPdg-warning {'t2' is used uninitialized} {} { target *-*-* } outer }
{ DUP_dg-note {'t2' was declared here} {} { target *-*-* } vars }
{ DUP_dg-note {in expansion of macro 'gentest'} {} { target { ! offloading_enabled } } .-8 }
TODO See PR101551 for 'offloading_enabled' differences. */