[Bug c++/105460] New: sizeof (unsigned int) != sizeof (uint8_t *)

[Bug c++/105460] New: sizeof (unsigned int) != sizeof (uint8_t *)

[zhonghao at pku dot org.cn]

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

            Bug ID: 105460
           Summary: sizeof (unsigned int) != sizeof (uint8_t *)
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: zhonghao at pku dot org.cn
  Target Milestone: ---

Clang's comments say there is an `unsigned int`-sized "reserved" member here,
because when the objc4 modern runtime is used on LP64 platforms, there would
otherwise be a 32-bit-sized hole here for alignment reasons.

However, it doesn't actually add the "reserved" field to its AST data
structures.
GCC *does* add the field explicitly. On LP64, adding it or not is irrelevant. 
But on AVR, sizeof (unsigned int) == sizeof (uint8_t *), and it matters.

An example is
from:https://github.com/mhjacobson/avr-objc/commit/6187e336d706f1a87a7f0cbd9efa838f9d966737

This means that I have to compile Objective-C code either all with clang or all
with GCC.

[Bug target/105460] sizeof (unsigned int) != sizeof (uint8_t *)

[pinskia at gcc dot gnu.org]

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

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

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
#define INT_TYPE_SIZE (TARGET_INT8 ? 8 : 16)
#define SHORT_TYPE_SIZE (INT_TYPE_SIZE == 8 ? INT_TYPE_SIZE : 16)
#define LONG_TYPE_SIZE (INT_TYPE_SIZE == 8 ? 16 : 32)
#define LONG_LONG_TYPE_SIZE (INT_TYPE_SIZE == 8 ? 32 : 64)
#define FLOAT_TYPE_SIZE 32
#define DOUBLE_TYPE_SIZE (avr_double)
#define LONG_DOUBLE_TYPE_SIZE (avr_long_double)

#define SIZE_TYPE (INT_TYPE_SIZE == 8 ? "long unsigned int" : "unsigned int")
#define PTRDIFF_TYPE (INT_TYPE_SIZE == 8 ? "long int" :"int")

#define Pmode HImode


mint8
Target Mask(INT8)
Use an 8-bit 'int' type.

What options are you using?
Because GCC's default is an 8 bit int for avr. You should use -mno-int8 if you
want it different from the default.

[Bug target/105460] sizeof (unsigned int) != sizeof (uint8_t *)

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to zhonghao from comment #0)
> Clang's comments say there is an `unsigned int`-sized "reserved" member
> here,

Where is "here"? Don't just copy comments from code on GitHub and paste them as
big reports, like they're your own words.

[Bug target/105460] sizeof (unsigned int) != sizeof (uint8_t *)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |iains at gcc dot gnu.org,
                   |                            |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
>From what I can see, gcc is doing this since r0-106771-gd764a8e6bdae09aecb when
the OBJCv2 support has been introduced.
The comment says:
+  /* This ABI is currently only used on m64 NeXT, we choose to
+     make the alignment padding explicit.  */
+  /* uint32_t const reserved. */
+  add_field_decl (integer_type_node, "reserved", &chain);

[Bug target/105460] sizeof (unsigned int) != sizeof (uint8_t *)

[iains at gcc dot gnu.org]

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

--- Comment #4 from Iain Sandoe <iains at gcc dot gnu.org> ---
for the record, I am aware of the issue and Matt (github reference quoted
below) proposed a patch - however that patch breaks Objective-C++ and it's "in
my queue" to see how we can produce a version that allows NeXT ABI 2 to be used
with a ILP32 targets (and without breaking Objective-C++ on LP64).

I am open to reviewing patches that resolve this - but they must work with LP64
and Objective-C++.