Ping? Or do I need to repost on the patches list?
http://gcc.gnu.org/ml/gcc/2014-01/msg00130.html
On Tue, 28 Jan 2014, DJ Delorie wrote:
Ping? Or do I need to repost on the patches list?
Repost on the patches list (with self-contained write-up, rationale for
choices made, etc.) at the start of stage 1 for 4.10/5.0, I suggest (this
clearly isn't stage 3 material).
--
Joseph S. Myers
Repost on the patches list (with self-contained write-up, rationale for
choices made, etc.) at the start of stage 1 for 4.10/5.0,
Ok.
I suggest (this clearly isn't stage 3 material).
Yup. Would be nice to back port it to 4.9 later, but... understood.
On Wed, 8 Jan 2014, DJ Delorie wrote:
So... OK if __int20 and __int128 keywords exist always (for ports that
request them, which for __int128 would be all of them), but still be
unsupported if for some reason the port doesn't support them because
of command line options?
That seems
I think a patch is more useful once believe feature-complete, which
means replacing the __int128 support with the new mechanism.
One of the side-effects of taking out the existing __int128 support is
that __int128 isn't in the integer_type_kind list, so isn't a type
that is usable for
On Wed, 8 Jan 2014, DJ Delorie wrote:
I think a patch is more useful once believe feature-complete, which
means replacing the __int128 support with the new mechanism.
One of the side-effects of taking out the existing __int128 support is
that __int128 isn't in the integer_type_kind list,
I don't see constants in that test.
// Test for int128 enums.
// { dg-do compile { target int128 } }
// { dg-options }
enum E {
e1 = 0x,
e2, e3
} e = e3;
#define SA(I,X) int a##I[(X)? 1 : -1]
SA(1, sizeof(E) == sizeof(__int128));
Integer constant types should be taken
On Thu, 19 Dec 2013, DJ Delorie wrote:
Where is the right place to set the array of this __intN mode is
enabled flags? I initially set it in tree.c where __int128 is set
up, but that happens *after* c_parse_init() needs the flag to set up
the RID_* keywords for them.
Maybe immediately after
This seems mostly plausible, though I don't see anything to ensure that
__intN does not exist at all if the size matches one of the standard C
types, or if the mode fails targetm.scalar_mode_supported_p.
What do we check against for this? Is there some table of standard
types we can read
On Fri, 20 Dec 2013, DJ Delorie wrote:
This seems mostly plausible, though I don't see anything to ensure that
__intN does not exist at all if the size matches one of the standard C
types, or if the mode fails targetm.scalar_mode_supported_p.
What do we check against for this? Is
I think using the macros for type sizes is fine, and float / vector /
complex types are completely irrelevant to this (so standard_type_bitsize
should maybe be standard_integer_type_bitsize).
Whew. Am I missing any in the previous code snippet (char, short,
int, long, long long) ? Those
On Fri, 20 Dec 2013, DJ Delorie wrote:
I think using the macros for type sizes is fine, and float / vector /
complex types are completely irrelevant to this (so standard_type_bitsize
should maybe be standard_integer_type_bitsize).
Whew. Am I missing any in the previous code snippet
Ok, so I've got it checking for existing types and checking the target
for supported modes. Any other features, or is it time for a second
patch? Should I cut out the __int128 parts yet, or do you just want
to see the new code still?
To-Do: C++ parser, C++ mangling. Still no idea what to do
On Fri, 20 Dec 2013, DJ Delorie wrote:
Ok, so I've got it checking for existing types and checking the target
for supported modes. Any other features, or is it time for a second
patch? Should I cut out the __int128 parts yet, or do you just want
to see the new code still?
I think a patch
Where is the right place to set the array of this __intN mode is
enabled flags? I initially set it in tree.c where __int128 is set
up, but that happens *after* c_parse_init() needs the flag to set up
the RID_* keywords for them.
Alternately, should I be calling targetm.scalar_mode_supported_p()
On Tue, Dec 10, 2013 at 7:42 PM, DJ Delorie d...@redhat.com wrote:
(For the types you do have, there's a need to define C++ name mangling.
I mentioned this before, and I don't have a good solution for it.
Both C++ and LTO need a mangled form of __intN types.
LTO shouldn't need any of this.
On Mon, 9 Dec 2013, DJ Delorie wrote:
First pass at actual code. I took the path of using a new macro in
TARGET-modes.def and having genmodes build the relevent tables. Part
of the table is created by genmodes, the rest is created at runtime.
This seems mostly plausible, though I don't see
This seems mostly plausible, though I don't see anything to ensure that
__intN does not exist at all if the size matches one of the standard C
types,
My thought here was that, since each __intN is specified by the
target, they'd know to only do so if it doesn't match an existing (for
that
On Tue, 10 Dec 2013, DJ Delorie wrote:
This seems mostly plausible, though I don't see anything to ensure that
__intN does not exist at all if the size matches one of the standard C
types,
My thought here was that, since each __intN is specified by the
target, they'd know to only do
(For the types you do have, there's a need to define C++ name mangling.
I mentioned this before, and I don't have a good solution for it.
Both C++ and LTO need a mangled form of __intN types.
First pass at actual code. I took the path of using a new macro in
TARGET-modes.def and having genmodes build the relevent tables. Part
of the table is created by genmodes, the rest is created at runtime.
genmodes: bitsize, mode.
runtime: signed/unsigned type trees
(eventually, flag for
On Fri, 22 Nov 2013, DJ Delorie wrote:
If I come up with some table-driven API to register
integer-like-types and search/sort/choose from them, would that be a
good starting point? Then we can #define *_type_node to a function
call perhaps.
I am doubtful that it's appropriate for e.g.
(more precisely, for int128_integer_type_node to cease to exist and
for any front-end places needing it to call a function, with a type
size that should not be a constant 128).
The complications I've seen there is, for example, when you're
iterating through types looking for a best type,
On Fri, 22 Nov 2013, DJ Delorie wrote:
(more precisely, for int128_integer_type_node to cease to exist and
for any front-end places needing it to call a function, with a type
size that should not be a constant 128).
The complications I've seen there is, for example, when you're
In general you need to analyze each such case individually to produce a
reasoned argument for what it should logically be doing. Given such
analyses, maybe then you can identify particular tables of types in
particular orders (for example) that should be set up to iterate through.
Ok,
On Fri, 22 Nov 2013, DJ Delorie wrote:
Does the target with __int20 actually have __int128 (i.e. pass
targetm.scalar_mode_supported_p (TImode))? But you should indeed be able
to have an arbitrary number of such types.
It doesn't support it, but it does *have* it. In that the compiler
DJ Delorie d...@redhat.com wrote:
Everything handling __int128 would be updated to work with a
target-determined set of types instead.
Preferably, the number of such keywords would be arbitrary (so I
suppose
there would be a single RID_INTN for them) - that seems cleaner than
the
system
On Sat, 16 Nov 2013, Richard Biener wrote:
I did a scan through the gcc source tree trying to track down all the
implications of this, and there were a lot of them, and not just the
RID_* stuff. There's also the integer_types[] array (indexed by
itk_*, which is its own mess)
I don't think
Everything handling __int128 would be updated to work with a
target-determined set of types instead.
Preferably, the number of such keywords would be arbitrary (so I suppose
there would be a single RID_INTN for them) - that seems cleaner than the
system for address space keywords with a
On Wed, 13 Nov 2013, DJ Delorie wrote:
I tried to hack in support for intN_t in a backend, and it was a maze
of initialization sequence nightmares. So I guess we need to do the
intN_t part first. Is someone working on this? If not, is there a
spec I could use to get started on it?
Instead
Instead of a target-independent __int128 keyword, there would be a set
(possibly empty) of __intN keywords, determined by a target hook.
Or *-modes.def ?
On Thu, 14 Nov 2013, DJ Delorie wrote:
Instead of a target-independent __int128 keyword, there would be a set
(possibly empty) of __intN keywords, determined by a target hook.
Or *-modes.def ?
That would be one possibility - if the idea is to define __intN for all
integer modes not
That would be one possibility - if the idea is to define __intN for all
integer modes not matching a standard type (and passing
targetm.scalar_mode_supported_p), I advise posting details of what effect
this would have for all targets so we can see how many such types would
get added.
I
On Thu, 14 Nov 2013, DJ Delorie wrote:
That would be one possibility - if the idea is to define __intN for all
integer modes not matching a standard type (and passing
targetm.scalar_mode_supported_p), I advise posting details of what effect
this would have for all targets so we can see
If you do want types without corresponding modes, that goes back to
having a hook to list the relevant type sizes.
Perhaps a FRACTIONAL_INT_TYPE() macro then, for when there's no
machine mode to go with it? Although I'm struggling to imagine a case
where a target would need to define a
On Thu, 14 Nov 2013, DJ Delorie wrote:
If you do want types without corresponding modes, that goes back to
having a hook to list the relevant type sizes.
Perhaps a FRACTIONAL_INT_TYPE() macro then, for when there's no
machine mode to go with it? Although I'm struggling to imagine a case
So, given all that, is there any way to add the target-specific
size_t portion without waiting for-who-knows-how-long for the intN_t
and enum-size-type projects to finish? Some form of interim API that
we can put in, so that we can start working on finding all the
assumptions about
On Wed, 30 Oct 2013, DJ Delorie wrote:
My proposal is to allow the target to define its own type for
pointers, sizeof_t, and ptrdiff_t to use, so that gcc can adapt to
weird pointer sizes instead of the target having to use power-of-two
pointer math.
This means the target would somehow
It is a deficiency that SIZE_TYPE is defined to be a string at all (and
likewise for all the other target macros for standard typedefs including
all those for stdint.h). Separately, it's a deficiency that these
things are target macros rather than target hooks.
My thought was that
On Wed, 30 Oct 2013, DJ Delorie wrote:
It is a deficiency that SIZE_TYPE is defined to be a string at all (and
likewise for all the other target macros for standard typedefs including
all those for stdint.h). Separately, it's a deficiency that these
things are target macros rather
So, given all that, is there any way to add the target-specific
size_t portion without waiting for-who-knows-how-long for the intN_t
and enum-size-type projects to finish? Some form of interim API that
we can put in, so that we can start working on finding all the
assumptions about size_t, while
On Wed, 30 Oct 2013, DJ Delorie wrote:
So, given all that, is there any way to add the target-specific
size_t portion without waiting for-who-knows-how-long for the intN_t
and enum-size-type projects to finish? Some form of interim API that
we can put in, so that we can start working on
42 matches
Mail list logo
