[Bug c++/107802] New: -Wsuggest-attribute=format ignores [[gnu::format(...)]]

[Bug c++/107802] New: -Wsuggest-attribute=format ignores [[gnu::format(...)]]

[adam.f.badura at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107802

            Bug ID: 107802
           Summary: -Wsuggest-attribute=format ignores
                    [[gnu::format(...)]]
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: adam.f.badura at gmail dot com
  Target Milestone: ---

I checked the issue with GCC 10.2 and trunk as on Compiler Explorer using
arguments

 -std=c++17 -O3 -Wall -Wextra -Wpedantic -Wsuggest-attribute=format

The following code (https://godbolt.org/z/qP91h5Knv):

 #include <cstdarg>
 #include <cstdio>
 #include <cstdlib>

 __attribute__((format(printf, 4, 5))) [[noreturn]] void raise(
     [[maybe_unused]] const char* const file,
     [[maybe_unused]] const unsigned line,
     [[maybe_unused]] const char* const condition,
     const char* assertionMessage,
     ...)
 {
     std::fprintf(stderr, "*** Assertion message: ");
     va_list args;
     va_start(args, assertionMessage);
     std::vfprintf(stderr, assertionMessage, args);
     va_end(args);
     std::fprintf(stderr, "\n");

     std::abort();
 }

passes fine.

However, if we replace

 __attribute__((format(printf, 4, 5)))

with

 [[gnu::format(printf, 4, 5)]]

a warning shows up (https://godbolt.org/z/oecjj4Tzv):

 <source>: In function 'void raise(const char*, unsigned int, const char*,
const char*, ...)':
 <source>:15:49: warning: function 'void raise(const char*, unsigned int, const
char*, const char*, ...)' might be a candidate for 
 'gnu_printf' format attribute [-Wsuggest-attribute=format]
    15 |     std::vfprintf(stderr, assertionMessage, args);
       |                                                 ^

My overall experience is that the [[gnu::...]] syntax for attributes doesn't
behave the same as the __attribute__((...)) syntax. Not only it seems to be
more limited to where we can place it (this is up to C++, not GCC) but also it
seems attributes provided this way are more likely to be more or less ignored.
However, this is the first time I caught the issue so clearly.

[Bug c/107802] -Wsuggest-attribute=format ignores [[gnu::format(...)]]

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107802

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
          Component|c++                         |c
           Keywords|                            |ice-checking,
                   |                            |ice-on-valid-code
   Last reconfirmed|                            |2022-11-22
     Ever confirmed|0                           |1

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Well Looks like it ICEs on the trunk with -Wsuggest-attribute=format -W -Wall :
```
#include <stdarg.h>
 #include <stdio.h>
 #include <stdlib.h>

[[gnu::format(printf, 1, 2)]]
void  raise(
     const char* assertionMessage,
     ...) 
 {
     va_list args;
     va_start(args, assertionMessage);
     vfprintf(stderr, assertionMessage, args);
     va_end(args);
     abort();
 }

void f(void)
{
  raise("%s", 1223);
}
```
With both the C and C++ front-ends.

Confirmed.

[Bug c/107802] -Wsuggest-attribute=format ignores [[gnu::format(...)]]

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107802

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |DUPLICATE
             Status|NEW                         |RESOLVED

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Dup of bug 98487.

*** This bug has been marked as a duplicate of bug 98487 ***

[Bug c/107802] -Wsuggest-attribute=format ignores [[gnu::format(...)]]

[adam.f.badura at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107802

--- Comment #3 from Adam Badura <adam.f.badura at gmail dot com> ---
Why is this marked as a duplicate of bug 98487? I have seen bug 98487 before
reporting it. Furthermore, I experienced it while trying my code sample on the
trunk version to see if the problem still exists.

However, since trunk version breaks completely with the same code it is not
possible to determine if the problem reported here exists there or not. After
preventing the compiler from crashing we may very well start to observe the
problem reported here.

Or is bug 98487 intended to solve the problem reported here as well along the
way?

[Bug c/107802] -Wsuggest-attribute=format ignores [[gnu::format(...)]]

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107802

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Adam Badura from comment #3)
> Why is this marked as a duplicate of bug 98487? I have seen bug 98487 before
> reporting it. Furthermore, I experienced it while trying my code sample on
> the trunk version to see if the problem still exists.

Because the problem is exactly the same. That is with release checking set, the
ICE does not happen and instead the attribute gets ignored.

> However, since trunk version breaks completely with the same code it is not
> possible to determine if the problem reported here exists there or not.
> After preventing the compiler from crashing we may very well start to
> observe the problem reported here.
> 
> Or is bug 98487 intended to solve the problem reported here as well along
> the way?

The later. The ICE is due to how attributes are represented internally inside
GCC. The scoped attributes are done slightly different from the gnu style
attributes but then that was forgotten in the code and only handle the gnu
style attribute and that causes an ICE. The fix is to use the functions which
handle both ways and it will also fix the ignoring part too.

Also if you compile the trunk with --enable-checking=release, you get the
behavior reported here of ignoring the attribute; the ignoring is a symptom and
the ICE shows the cause (but is hidden in releases for speed reasons).