[Bug c/107947] New: __has_c_attribute incorrectly identifies attribute as supported

[Bug c/107947] New: __has_c_attribute incorrectly identifies attribute as supported

[xen0n at gentoo dot org]

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

            Bug ID: 107947
           Summary: __has_c_attribute incorrectly identifies attribute as
                    supported
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: xen0n at gentoo dot org
  Target Milestone: ---

Created attachment 53999
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53999&action=edit
minimal reproducing example

The gcc trunk incorrectly indicates that the [[noreturn]] spelling of the
noreturn attribute works on -std=gnu99 with the attached source:

> $ ./gcc/xgcc -B./gcc -E -P -std=gnu99 ../x.h
> C standard version is 199901L, has "__has_c_attribute"
> "__has_c_attribute(noreturn)" = 202202

This is commit abf05583dbc86a6667b63f5bda6ba57fe55a1b25, while:

> $ gcc-12.1.1 -E -P -std=gnu99 x.h
> C standard version is 199901L, has "__has_c_attribute"
> "__has_c_attribute(noreturn)" = 0

and:

> $ clang-15 -E -P -std=gnu99 x.h
> 
> C standard version is 199901L, has "__has_c_attribute"
> "__has_c_attribute(noreturn)" = 0

I haven't bisected yet but can help doing so if necessary. One of the affected
code in the wild is the fresh tzdb-2022g from https://www.iana.org/time-zones.

[Bug c/107947] __has_c_attribute incorrectly identifies attribute as supported

[xen0n at gentoo dot org]

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

--- Comment #1 from WANG Xuerui <xen0n at gentoo dot org> ---
The corresponding Gentoo bug is at https://bugs.gentoo.org/883719.

[Bug c/107947] __has_c_attribute incorrectly identifies attribute as supported

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Yes it is supported with -std=gnu99.
The bug is in tzdata where it does:
static [[noreturn]] void f();
That is invalid, the attribute cannot be in the middle of a declaration
specification rather it should be before or after.

[Bug c/107947] __has_c_attribute incorrectly identifies attribute as supported

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to WANG Xuerui from comment #0)
> I haven't bisected yet but can help doing so if necessary.

Bisection shows that it changed with r13-2976 which is the commit that added
support for the [[noreturn]] attribute. So it's totally correct that
__has_c_attribute starts to be non-zero then, because it started to be
supported then.

    c: C2x noreturn attribute

    C2x adds a standard [[noreturn]] attribute (which can also be spelt
    [[_Noreturn]] for use with <stdnoreturn.h>), so allowing non-returning
    functions to be declared in a manner compatible with C++; the
    _Noreturn function specifier remains available but is marked
    obsolescent.

[Bug c/107947] __has_c_attribute incorrectly identifies attribute as supported

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
To expand on the invalid placement of the attribute, the C++ front-end also
rejects it and also see PR 101682 which is also asking about it, gnulib was
broken at one point.

I did find that clang accepts the invalid placement of the attribute for its C
front-end in non-pedantic mode which might be the reason why some folks think
it should work.

[Bug c/107947] __has_c_attribute incorrectly identifies attribute as supported

[eggert at cs dot ucla.edu]

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

--- Comment #5 from eggert at cs dot ucla.edu ---
Thanks for reporting the conformance bug in TZDB. I fixed it in the TZDB
development repository here:

https://github.com/eggert/tz/commit/9cfe9507fcc22cd4a0c4da486ea1c7f0de6b075f

and the fix should appear in the next TZDB release.

[Bug c/107947] __has_c_attribute incorrectly identifies attribute as supported

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marxin at gcc dot gnu.org

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 108213 has been marked as a duplicate of this bug. ***