[Bug tree-optimization/115177] New: incorrect TBAA for derived types involving hardbool types

[Bug tree-optimization/115177] New: incorrect TBAA for derived types involving hardbool types

[muecker at gwdg dot de]

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

            Bug ID: 115177
           Summary: incorrect TBAA for derived types involving hardbool
                    types
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: muecker at gwdg dot de
  Target Milestone: ---

This is another example where type compatibility in the C FE disagrees with
TBAA. Not sure whether those types should be made incompatible instead.

https://godbolt.org/z/e6nYzWMzx


typedef int A;
typedef int __attribute__ (( hardbool(0, 1) )) B;

_Static_assert(_Generic((A*){ 0 }, B*: 1), "");

void* foo(void* a, void *b, A *c, B *d)
{
        *(A**)a = c;
        *(B**)b = d;
        return *(A**)a;
}

int main()
{
        A *a, b, c;
        if (&c != (A*)foo(&a, &a, &b, &c))
                __builtin_abort();
}

[Bug tree-optimization/115177] incorrect TBAA for derived types involving hardbool types

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|unknown                     |15.0
                 CC|                            |aoliva at gcc dot gnu.org

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
hardbool is an extension, so how it should behave is up to us?  It probably
makes sense to inter-operate with its base type though?  You are testing
for inter-operability between Base * and Hardbool * though.

Alex, what was the idea here?

[Bug tree-optimization/115177] incorrect TBAA for derived types involving hardbool types

[muecker at gwdg dot de]

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

Martin Uecker <muecker at gwdg dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=115157

--- Comment #2 from Martin Uecker <muecker at gwdg dot de> ---

They are internally implemented as enums, so the issue is basically the same as
PR115157. The types can alias via the langhook but TYPE_CANONICAL is different
and so derived types can not alias. It needs to be fixed somewhere else though.

[Bug tree-optimization/115177] incorrect TBAA for derived types involving hardbool types

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Martin Uecker <uecker@gcc.gnu.org>:

https://gcc.gnu.org/g:867d1264fe71d4291194373d1a1c409cac97a597

commit r15-933-g867d1264fe71d4291194373d1a1c409cac97a597
Author: Martin Uecker <uecker@tugraz.at>
Date:   Sun May 19 23:13:22 2024 +0200

    C: allow aliasing of compatible types derived from enumeral types
[PR115157]

    Aliasing of enumeral types with the underlying integer is now allowed
    by setting the aliasing set to zero.  But this does not allow aliasing
    of derived types which are compatible as required by ISO C.  Instead,
    initially set structural equality.  Then set TYPE_CANONICAL and update
    pointers and main variants when the type is completed (as done for
    structures and unions in C23).

            PR tree-optimization/115157
            PR tree-optimization/115177

    gcc/c/
            * c-decl.cc (shadow_tag-warned,parse_xref_tag,start_enum,
            finish_enum): Set SET_TYPE_STRUCTURAL_EQUALITY / TYPE_CANONICAL.
            * c-objc-common.cc (get_alias_set): Remove special case.
            (get_aka_type): Add special case.

    gcc/c-family/
            * c-attribs.cc (handle_hardbool_attribute): Set TYPE_CANONICAL
            for hardbools.

    gcc/
            * godump.cc (go_output_typedef): Use TYPE_MAIN_VARIANT instead
            of TYPE_CANONICAL.

    gcc/testsuite/
            * gcc.dg/enum-alias-1.c: New test.
            * gcc.dg/enum-alias-2.c: New test.
            * gcc.dg/enum-alias-3.c: New test.
            * gcc.dg/enum-alias-4.c: New test.

[Bug tree-optimization/115177] incorrect TBAA for derived types involving hardbool types

[aoliva at gcc dot gnu.org]

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

--- Comment #4 from Alexandre Oliva <aoliva at gcc dot gnu.org> ---
One could argue either way.  As a hardened type, discouraging aliasing that
would bypass the hardening could also make sense.  It was modeled after Ada,
whose aliasing is much stricter, but I guess in C it is reasonable to make it
more C-like in C, and allow it to alias with the underlying integral type.  The
feature request did not specify it either way, so I suspect reliable lax
aliasing was not expected.

[Bug tree-optimization/115177] incorrect TBAA for derived types involving hardbool types

[muecker at gwdg dot de]

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

--- Comment #5 from Martin Uecker <muecker at gwdg dot de> ---

If we do want to constrain the type, we should make them incompatible at the
language level. Aliasing is secondary. From a safety perspective, it is always
safer to allow aliasing, because the optimizer breaks code that assumes
otherwise but not vice versa.