This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [ubsan] Introduce pointer_sized_int_node
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: Marek Polacek <polacek at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 28 Aug 2013 13:10:59 +0200
- Subject: Re: [ubsan] Introduce pointer_sized_int_node
- Authentication-results: sourceware.org; auth=none
- References: <20130826101509 dot GH4968 at redhat dot com> <CAFiYyc2O5N91=kDF-aJOTUz67_m7RpF9b7m6zi9apw0bZECkrA at mail dot gmail dot com> <20130827125616 dot GB574 at redhat dot com> <CAFiYyc0SLeXgLOZmE-uJrxTvnpepqN6HMTgg_KUyTZHoi7Zi1g at mail dot gmail dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Wed, Aug 28, 2013 at 12:48:41PM +0200, Richard Biener wrote:
> On Tue, Aug 27, 2013 at 2:56 PM, Marek Polacek <polacek@redhat.com> wrote:
> > On Tue, Aug 27, 2013 at 01:48:29PM +0200, Richard Biener wrote:
> >> > + TI_POINTER_SIZED_TYPE,
> >>
> >> I'd rather see TI_UINTPTR_TYPE and TI_INTPTR_TYPE (note they might
> >> not be exactly of POINTER_SIZE but larger).
> >
> > We already have [u]intptr_type_node -- but only in c-family/, thus
> > ubsan.c/asan.c cannot use those nodes. I can create both
> > TI_SIGNED_POINTER_SIZED_TYPE and TI_UNSIGNED_POINTER_SIZED_TYPE,
> > but we currently need only the latter...
>
> So simply move them to the middle-end. The set of C language types that
> define the target ABI should be constructed and maintained by the middle-end
> (you need it for various builtins anyway)
That is not easily possible. The thing is, in the C FEs they are created
from the C/C++ type name (for stdint purposes):
if (INTPTR_TYPE)
intptr_type_node =
TREE_TYPE (identifier_global_value (c_get_ident (INTPTR_TYPE)));
if (UINTPTR_TYPE)
uintptr_type_node =
TREE_TYPE (identifier_global_value (c_get_ident (UINTPTR_TYPE)));
and are supposed to match the stdint.h previously used type, because
it is part of ABI etc. (long vs. long long vs. int e.g. when two of these
are the same precision).
So the middle-end uintptr type needs to be something different, while it
ideally should have the same precision, it is not the same language type.
Jakub