DJ Delorie d...@redhat.com writes:
FAIL: g++.dg/init/enum1.C -std=gnu++11 (test for errors, line 12)
FAIL: g++.dg/init/enum1.C -std=gnu++1y (test for errors, line 12)
FAIL: g++.dg/init/enum1.C -std=gnu++98 (test for errors, line 12)
That used to complain about enum1.C:12:1: error: no
On Thu, Oct 16, 2014 at 1:48 AM, Markus Trippelsdorf
mar...@trippelsdorf.de wrote:
On 2014.10.15 at 17:00 -0400, DJ Delorie wrote:
If you could implement the second option, it would be appreciated.
Could you please test this for me? It builds as a powerpc-elf
cross-compiler (at least the
This is okay.
Thanks! Committed.
FAIL: g++.dg/init/enum1.C -std=gnu++11 (test for errors, line 12)
FAIL: g++.dg/init/enum1.C -std=gnu++1y (test for errors, line 12)
FAIL: g++.dg/init/enum1.C -std=gnu++98 (test for errors, line 12)
That used to complain about enum1.C:12:1: error: no integral type can
represent all of
On 2014.10.14 at 17:10 -0400, DJ Delorie wrote:
../../gcc/gcc/config/rs6000/rs6000-c.c:237:24: error: ‘RID_INT128’ was not
declared in this scope
Two options:
1. If you know the RS6000 will never have any __intN other than
__int128, just use RID_INT_N_0, although this is a hack it
Hi,
On 10/14/2014 09:44 PM, DJ Delorie wrote:
extensions. Is this OK? If so, is there anything else, or can I
check the whole mess in yet?
Go ahead.
Thanks! Committed.
A couple of small issues in std/limits and in the testsuite are causing
regressions which I'm fixing with the below.
On Wed, 15 Oct 2014, Paolo Carlini wrote:
A couple of small issues in std/limits and in the testsuite are causing
regressions which I'm fixing with the below.
- max() _GLIBCXX_USE_NOEXCEPT { return __glibcxx_max_b (TYPE, BITSIZE);; } \
+ max() _GLIBCXX_USE_NOEXCEPT { return
If you could implement the second option, it would be appreciated.
Could you please test this for me? It builds as a powerpc-elf
cross-compiler (at least the host half) but I don't have a power
machine here to test on.
Index: rs6000-c.c
On 2014.10.15 at 17:00 -0400, DJ Delorie wrote:
If you could implement the second option, it would be appreciated.
Could you please test this for me? It builds as a powerpc-elf
cross-compiler (at least the host half) but I don't have a power
machine here to test on.
Index: rs6000-c.c
On 10/13/2014 04:54 PM, DJ Delorie wrote:
This is what I ended up with for the test case. It was a bit tricky
since it only works with msp430x (not msp430) and requires the gnu
extensions. Is this OK? If so, is there anything else, or can I
check the whole mess in yet?
Go ahead.
Jason
extensions. Is this OK? If so, is there anything else, or can I
check the whole mess in yet?
Go ahead.
Thanks! Committed.
On 2014.08.25 at 23:03 -0400, DJ Delorie wrote:
I'd like to see the updated version of the whole of patch 3 (tested
to be actually independent of the other patches) for review, though
I won't be reviewing the C++ parts.
Here it is. Tested on x86_64. I include the msp430-modes.def
../../gcc/gcc/config/rs6000/rs6000-c.c:237:24: error: ‘RID_INT128’ was not
declared in this scope
Two options:
1. If you know the RS6000 will never have any __intN other than
__int128, just use RID_INT_N_0, although this is a hack it will
work as long as there *is* an __int128 for
This is what I ended up with for the test case. It was a bit tricky
since it only works with msp430x (not msp430) and requires the gnu
extensions. Is this OK? If so, is there anything else, or can I
check the whole mess in yet?
// { dg-do compile { target msp430*-*-* } }
// { dg-options
OK, thanks.
Jason
if (same_type_p (TYPE_MAIN_VARIANT (t1), long_long_unsigned_type_node)
|| same_type_p (TYPE_MAIN_VARIANT (t2),
long_long_unsigned_type_node))
return build_type_attribute_variant (long_long_unsigned_type_node,
On 10/03/2014 04:11 PM, DJ Delorie wrote:
Note that there is a separate __int128_t type that isn't part of the
standard extension. Maybe it's there for that type?
Otherwise, I don't see what moving the test would accomplish. If
long is never 128 bits, it doesn't matter if the int128 test is
Otherwise, I don't see what moving the test would accomplish. If
long is never 128 bits, it doesn't matter if the int128 test is
before or after it, and the other intN are never the same size as
standard types,
I don't see how you can assert that these will never happen.
It's checked
On 10/02/2014 02:00 PM, DJ Delorie wrote:
Ah, good point. In which case I don't see what this code is trying to
accomplish relative to falling through to the prefer the unsigned one
code below. Shall we just remove it?
I don't know for sure. There was __int128 code there, I replaced it
with
Note that there is a separate __int128_t type that isn't part of the
standard extension. Maybe it's there for that type?
Otherwise, I don't see what moving the test would accomplish. If
long is never 128 bits, it doesn't matter if the int128 test is
before or after it, and the other intN are
On 10/01/2014 11:52 PM, DJ Delorie wrote:
It seems like the int128 code here was broken and this is continuing
that brokenness. Extended integer types have integer conversion rank
corresponding to their bitsize, so int128 should have higher rank than
long long, but here it was being checked
On 10/02/2014 10:22 AM, Jason Merrill wrote:
Extended integer types larger than long long also participate in
enumeral promotion if needed, but I think your changes to
c_common_type_for_size handle that.
...and it seems we currently don't support enums with underlying type
larger than long
The C++ standard says that extended integer types participate in the
usual arithmetic conversions. If I add a 32-bit int and an __int48, the
usual arithmetic conversions should convert the int to __int48.
Except the code you're referring to isn't part of that conversion. It
only handles
On 10/02/2014 12:41 PM, DJ Delorie wrote:
The C++ standard says that extended integer types participate in the
usual arithmetic conversions. If I add a 32-bit int and an __int48, the
usual arithmetic conversions should convert the int to __int48.
Except the code you're referring to isn't part
Ah, good point. In which case I don't see what this code is trying to
accomplish relative to falling through to the prefer the unsigned one
code below. Shall we just remove it?
I don't know for sure. There was __int128 code there, I replaced it
with the same code, so as to avoid any
The test would only pass for msp430x (and fail for msp430, which is
the same target back-end). Do I need to redo the big patch, or would
a separate one suffice?
Separate is fine.
Turns out it's mangled like this:
__int20 foo (__int20 a, unsigned __int20 b);
_Z3foou5int20u6uint20
On 09/30/2014 07:14 PM, DJ Delorie wrote:
Could one of you two please review the remaining C++ parts (cp/*) ?
https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02360.html
+ for (i = 0; i NUM_INT_N_ENTS; i ++)
{
+ if (int_n_enabled_p [i]
+ (same_type_p
It seems like the int128 code here was broken and this is continuing
that brokenness. Extended integer types have integer conversion rank
corresponding to their bitsize, so int128 should have higher rank than
long long, but here it was being checked after long long, and your code
also
Joseph S. Myers jos...@codesourcery.com wrote:
The non-C++/libstdc++ parts are OK with those changes.
Jonathan Wakely jwak...@redhat.com wrote:
* libstdc++-v3/
* src/c++11/limits.cc: Add support for __intN types.
* include/std/type_traits: Likewise.
* include/std/limits:
On 30/09/14 15:37 -0400, DJ Delorie wrote:
Joseph S. Myers jos...@codesourcery.com wrote:
The non-C++/libstdc++ parts are OK with those changes.
Jonathan Wakely jwak...@redhat.com wrote:
* libstdc++-v3/
* src/c++11/limits.cc: Add support for __intN types.
* include/std/type_traits:
Joseph S. Myers jos...@codesourcery.com wrote:
The non-C++/libstdc++ parts are OK with those changes.
Jonathan Wakely jwak...@redhat.com wrote:
These libstdc++ changes are OK for trunk.
Jason/Nathan,
Could one of you two please review the remaining C++ parts (cp/*) ?
Just one question about the include/std/limits changes below.
It seems that __glibcxx_signed_b isn't strictly necessary as it
doesn't use the B argument, so is it just there for consistency?
Yup.
On 29/09/14 14:06 -0400, DJ Delorie wrote:
Just one question about the include/std/limits changes below.
It seems that __glibcxx_signed_b isn't strictly necessary as it
doesn't use the B argument, so is it just there for consistency?
Yup.
OK, thanks for confirming.
On 25/08/14 23:03 -0400, DJ Delorie wrote:
I'd like to see the updated version of the whole of patch 3 (tested
to be actually independent of the other patches) for review, though
I won't be reviewing the C++ parts.
Here it is. Tested on x86_64. I include the msp430-modes.def patch
for
On Mon, 25 Aug 2014, DJ Delorie wrote:
+ for (i = 0; i NUM_INT_N_ENTS; i ++)
+if (int_n_enabled_p[i])
+ {
+ char buf[35+20+20];
+
+ /* These are used to configure the C++ library. */
+
+ if (!flag_iso || int_n_data[i].bitsize == POINTER_SIZE)
+ {
+
On Fri, 22 Aug 2014, DJ Delorie wrote:
Maybe you need to refactor __glibcxx_digits so there is a version taking
the bitsize as an argument rather than using sizeof(T) * __CHAR_BIT__, but
that should be the only change needed to handle such types with the
existing macros. The bitsize
Maybe you need to refactor __glibcxx_digits so there is a version taking
the bitsize as an argument rather than using sizeof(T) * __CHAR_BIT__,
but
that should be the only change needed to handle such types with the
existing macros. The bitsize macros should be the only ones
On Fri, 22 Aug 2014, DJ Delorie wrote:
Maybe you need to refactor __glibcxx_digits so there is a version
taking
the bitsize as an argument rather than using sizeof(T) * __CHAR_BIT__,
but
that should be the only change needed to handle such types with the
existing
I don't see flag_iso as relevant here (since the macros are in the
implementation namespace). The definitions could reasonably be restricted
to c_dialect_cxx (), though, given that they are specifically for use by
libstdc++ (and it's easier to add a macro later for C if needed, than to
On Wed, 13 Aug 2014, DJ Delorie wrote:
+ for (i = 0; i NUM_INT_N_ENTS; i ++)
+{
+ int_n_trees[i].signed_type = make_signed_type (int_n_data[i].bitsize);
+ int_n_trees[i].unsigned_type = make_unsigned_type
(int_n_data[i].bitsize);
+ TYPE_SIZE
Why are types only entered in integer_types if wider than long long?
IIRC it was so that TImode (__int128) could get into the array (it was
there before) without adding the other smaller types, which (I think)
don't need to be in there. I don't recall why they're left out,
but... ah, I
On Thu, 21 Aug 2014, DJ Delorie wrote:
+ /* This must happen after the backend has a chance to process
+ command line options, but before the parsers are
+ initialized. */
+ for (i = 0; i NUM_INT_N_ENTS; i ++)
+ if (targetm.scalar_mode_supported_p (int_n_data[i].m)
I don't see any corresponding HOST_BITS_PER_WIDE_INT test for __int128
being removed (and anyway HOST_BITS_PER_WIDE_INT is now always 64, so such
a test for __int128 would be dead code).
It was there when I started the patch, honest! :-)
Removed ;-)
For each __intN we need to provide
On Thu, 21 Aug 2014, DJ Delorie wrote:
Maybe you need to refactor __glibcxx_digits so there is a version
taking the bitsize as an argument rather than using sizeof(T) *
__CHAR_BIT__, but that should be the only change needed to handle
such types with the existing macros.
Since the
Maybe you need to refactor __glibcxx_digits so there is a version taking
the bitsize as an argument rather than using sizeof(T) * __CHAR_BIT__, but
that should be the only change needed to handle such types with the
existing macros. The bitsize macros should be the only ones needing
On Wed, 2014-08-13 at 18:11 -0400, DJ Delorie wrote:
This is the main __int128 - __intN conversion patch. We support up
to four __intN types per target, which may include __int128. I
include the minimal change to the msp430 backend to illustrate how to
add a target-specific __intN type.
A while ago I've removed a couple of those 'typedef struct' things, as
they are not required in C++ anymore. Is there any particular reason
why this couldn't be simply 'struct int_n_data_t' ?
No particular reason.
47 matches
Mail list logo
