Applied, thanks.
Jason
test.
Best regards,
Thomas
-Original Message-
From: Jason Merrill [mailto:ja...@redhat.com]
Sent: Friday, November 07, 2014 4:23 PM
To: Thomas Preud'homme; 'Nathan Sidwell'; gcc-patches@gcc.gnu.org
Subject: Re: [PATCH, C++] Fix PR63366: __complex not equivalent to
__complex double
From: Jason Merrill [mailto:ja...@redhat.com]
Sent: Wednesday, October 29, 2014 4:43 PM
Since this is a GNU extension, I think we want to be compatible with the
C front end, which has
else if (specs-complex_p)
{
specs-typespec_word = cts_double;
From: Nathan Sidwell [mailto:nat...@codesourcery.com]
Sent: Thursday, October 09, 2014 2:30 PM
On 10/09/14 09:25, Jason Merrill wrote:
I would think we want to handle this up in the existing defaulted_int
block:
my thought was to at least put it next to the explicit_int = -1 above.
It
On 10/29/14 02:47, Thomas Preud'homme wrote:
It seems more sensible to keep it in this block as the existing
defaulted_int block is for types for which it is not an error to omit the
int type specifier.
It's not an error to omit it for complex - but of course means something
different. IMHO
From: Nathan Sidwell [mailto:nathanmsidw...@gmail.com] On Behalf Of
Nathan Sidwell
It's not an error to omit it for complex - but of course means something
different. IMHO it would be confusing to set type to integer_type_node
when
that's definitely wrong. But then setting
On 10/29/14 07:32, Thomas Preud'homme wrote:
From: Nathan Sidwell [mailto:nathanmsidw...@gmail.com] On Behalf Of
Oh in that case the patch is incomplete. Currently a complex alone gives
an error at compilation which is why I added -fpermissive to the testcase.
The patch don't change this
On 10/29/2014 05:47 AM, Thomas Preud'homme wrote:
From: Nathan Sidwell [mailto:nat...@codesourcery.com]
Sent: Thursday, October 09, 2014 2:30 PM
On 10/09/14 09:25, Jason Merrill wrote:
I would think we want to handle this up in the existing defaulted_int
block:
my thought was to at least put
Ping?
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
Sent: Monday, September 29, 2014 3:33 PM
To: gcc-patches@gcc.gnu.org
Subject: [PATCH, C++] Fix PR63366: __complex not equivalent to
__complex double
On 10/09/2014 05:24 AM, Thomas Preud'homme wrote:
ISO C++ forbids declaration of %qs with no type, name);
type = integer_type_node;
+ defaulted_int = 1;
I would think we want to handle this up in the existing defaulted_int block:
/* No type at all: default
On 10/09/14 09:25, Jason Merrill wrote:
On 10/09/2014 05:24 AM, Thomas Preud'homme wrote:
ISO C++ forbids declaration of %qs with no type, name);
type = integer_type_node;
+ defaulted_int = 1;
I would think we want to handle this up in the existing
On 10/09/2014 09:30 AM, Nathan Sidwell wrote:
+ return typeid (__complex) != typeid (__complex double);
Don't we want this to be '=='?
I think it wants to check for _complex being __complex double, not not
being _complex int (other failure modes exist!)
Right, I was forgetting about
According to a comment in grokdeclarator in file gcc/cp/decl.c:
/* If we just have complex, it is equivalent to
complex double, but if any modifiers at all are specified it is
the complex form of TYPE. E.g, complex short is
complex short int. */
Yet, __complex is equivalent to
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
Sent: Monday, September 29, 2014 3:33 PM
ChangeLog are as follows:
*** gcc/cp/ChangeLog ***
2014-09-26 Thomas Preud'homme thomas.preudho...@arm.com
* decl.c
14 matches
Mail list logo