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

--- Comment #14 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <ja...@gcc.gnu.org>:

https://gcc.gnu.org/g:dd346b613886aea9761dbb5e7a8d6c47922750b2

commit r15-3330-gdd346b613886aea9761dbb5e7a8d6c47922750b2
Author: Jakub Jelinek <ja...@redhat.com>
Date:   Sat Aug 31 15:58:23 2024 +0200

    c: Add support for unsequenced and reproducible attributes

    C23 added in N2956 ( https://open-std.org/JTC1/SC22/WG14/www/docs/n2956.htm
)
    two new attributes, which are described as similar to GCC const and pure
    attributes, but they aren't really same and it seems that even the paper
    is missing some of the differences.
    The paper says unsequenced is the same as const on functions without
pointer
    arguments and reproducible is the same as pure on such functions (except
    that they are function type attributes rather than function
    declaration ones), but it seems the paper doesn't consider the finiteness
GCC
    relies on (aka non-DECL_LOOPING_CONST_OR_PURE_P) - the paper only talks
    about using the attributes for CSE etc., not for DCE.

    The following patch introduces (for now limited) support for those
    attributes, both as standard C23 attributes and as GNU extensions (the
    difference is that the patch is then less strict on where it allows them,
    like other function type attributes they can be specified on function
    declarations as well and apply to the type, while C23 standard ones must
    go on the function declarators (i.e. after closing paren after function
    parameters) or in type specifiers of function type.

    If function doesn't have any pointer/reference arguments, the patch
    adds additional internal attribute with " noptr" suffix which then is used
    by flags_from_decl_or_type to handle those easy cases as
    ECF_CONST|ECF_LOOPING_CONST_OR_PURE or
    ECF_PURE|ECF_LOOPING_CONST_OR_PURE
    The harder cases aren't handled right now, I'd hope they can be handled
    incrementally.

    I wonder whether we shouldn't emit a warning for the
    gcc.dg/c23-attr-{reproducible,unsequenced}-5.c cases, while the standard
    clearly specifies that composite types should union the attributes and it
    is what GCC implements for decades, for ?: that feels dangerous for the
    new attributes, it would be much better to be conservative on say
    (cond ? unsequenced_function : normal_function) (args)

    There is no diagnostics on incorrect [[unsequenced]] or [[reproducible]]
    function definitions, while I think diagnosing non-const static/TLS
    declarations in the former could be easy, the rest feels hard.  E.g. the
    const/pure discovery can just punt on everything it doesn't understand,
    but complete diagnostics would need to understand it.

    2024-08-31  Jakub Jelinek  <ja...@redhat.com>

            PR c/116130
    gcc/
            * doc/extend.texi (unsequenced, reproducible): Document new
function
            type attributes.
            * calls.cc (flags_from_decl_or_type): Handle "unsequenced noptr"
and
            "reproducible noptr" attributes.
    gcc/c-family/
            * c-attribs.cc (c_common_gnu_attributes): Add entries for
            "unsequenced", "reproducible", "unsequenced noptr" and
            "reproducible noptr" attributes.
            (handle_unsequenced_attribute): New function.
            (handle_reproducible_attribute): Likewise.
            * c-common.h (handle_unsequenced_attribute): Declare.
            (handle_reproducible_attribute): Likewise.
            * c-lex.cc (c_common_has_attribute): Return 202311 for standard
            unsequenced and reproducible attributes.
    gcc/c/
            * c-decl.cc (handle_std_unsequenced_attribute): New function.
            (handle_std_reproducible_attribute): Likewise.
            (std_attributes): Add entries for "unsequenced" and "reproducible"
            attributes.
            (c_warn_type_attributes): Add TYPE argument.  Allow unsequenced
            or reproducible attributes if it is FUNCTION_TYPE.
            (groktypename): Adjust c_warn_type_attributes caller.
            (grokdeclarator): Likewise.
            (finish_declspecs): Likewise.
            * c-parser.cc (c_parser_declaration_or_fndef): Likewise.
            * c-tree.h (c_warn_type_attributes): Add TYPE argument.
    gcc/testsuite/
            * c-c++-common/attr-reproducible-1.c: New test.
            * c-c++-common/attr-reproducible-2.c: New test.
            * c-c++-common/attr-unsequenced-1.c: New test.
            * c-c++-common/attr-unsequenced-2.c: New test.
            * gcc.dg/c23-attr-reproducible-1.c: New test.
            * gcc.dg/c23-attr-reproducible-2.c: New test.
            * gcc.dg/c23-attr-reproducible-3.c: New test.
            * gcc.dg/c23-attr-reproducible-4.c: New test.
            * gcc.dg/c23-attr-reproducible-5.c: New test.
            * gcc.dg/c23-attr-reproducible-5-aux.c: New file.
            * gcc.dg/c23-attr-unsequenced-1.c: New test.
            * gcc.dg/c23-attr-unsequenced-2.c: New test.
            * gcc.dg/c23-attr-unsequenced-3.c: New test.
            * gcc.dg/c23-attr-unsequenced-4.c: New test.
            * gcc.dg/c23-attr-unsequenced-5.c: New test.
            * gcc.dg/c23-attr-unsequenced-5-aux.c: New file.
            * gcc.dg/c23-has-c-attribute-2.c: Add tests for unsequenced
            and reproducible attributes.
  • [Bug c/116130] Implement C23 N2... cvs-commit at gcc dot gnu.org via Gcc-bugs

Reply via email to