On 5/24/2021 4:12 AM, Martin Liška wrote:
On 5/20/21 10:03 AM, Richard Biener wrote:
Martin - was this intended? Can you fix it up please? (g:cb50701ec2c7)
It was not intentional. Fixed in the attached patch (where I did
a refactoring as well).
Patch can bootstrap on x86_64-linux-gnu and
On 5/20/21 10:03 AM, Richard Biener wrote:
Martin - was this intended? Can you fix it up please? (g:cb50701ec2c7)
It was not intentional. Fixed in the attached patch (where I did
a refactoring as well).
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be insta
On Thu, May 20, 2021 at 7:00 AM Jeff Law via Gcc-patches
wrote:
>
>
> On 5/19/2021 3:01 PM, Martin Sebor via Gcc-patches wrote:
> > The front end -Wnonnull handler has code to suppress warning for
> > lambdas with null this pointers but the middle end handler has
> > no corresponding logic. This
On 5/19/2021 3:01 PM, Martin Sebor via Gcc-patches wrote:
The front end -Wnonnull handler has code to suppress warning for
lambdas with null this pointers but the middle end handler has
no corresponding logic. This leads to spurious -Wnonnull in
lambda calls that aren't inlined. That might ha
The front end -Wnonnull handler has code to suppress warning for
lambdas with null this pointers but the middle end handler has
no corresponding logic. This leads to spurious -Wnonnull in
lambda calls that aren't inlined. That might happen at low
optimization levels such as -O1 or -Og and with s
