https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32187
--- Comment #13 from Andrew Pinski ---
(In reply to jos...@codesourcery.com from comment #12)
> You can now use _Complex _Float128. Given that, it's not obvious that
> _Complex __float128, with the legacy __float128 type name, should be
> supp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32187
--- Comment #12 from joseph at codesourcery dot com ---
You can now use _Complex _Float128. Given that, it's not obvious that
_Complex __float128, with the legacy __float128 type name, should be
supported (although not supporting that means al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32187
--- Comment #11 from Joseph S. Myers ---
Author: jsm28
Date: Fri Aug 19 17:43:26 2016
New Revision: 239625
URL: https://gcc.gnu.org/viewcvs?rev=239625&root=gcc&view=rev
Log:
Implement C _FloatN, _FloatNx types.
ISO/IEC TS 18661-3:2015 defines C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32187
--- Comment #10 from emsr at gcc dot gnu.org ---
Author: emsr
Date: Tue Aug 16 14:56:55 2016
New Revision: 239504
URL: https://gcc.gnu.org/viewcvs?rev=239504&root=gcc&view=rev
Log:
Commit Joseph Myers Implement C _FloatN, _FloatNx types [version
--- Comment #9 from and_j_rob at yahoo dot com 2010-05-03 07:22 ---
Created an attachment (id=20540)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20540&action=view)
Was a C/C++ comparison
I found a similar problem while comparing C/C++ complexes, I'm on a x86_64 mac,
and was tryi
--- Comment #8 from ktietz at gcc dot gnu dot org 2009-09-27 09:28 ---
(In reply to comment #7)
> The new attribute "basetype_mode" (see
> http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01907.html for patch) could
> provide a way to solve this, as it makes sure that it is associated to the
--- Comment #7 from ktietz at gcc dot gnu dot org 2009-09-27 09:25 ---
The new attribute "basetype_mode" (see
http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01907.html for patch) could
provide a way to solve this, as it makes sure that it is associated to the base
type, instead of the curr
--- Comment #6 from jsm28 at gcc dot gnu dot org 2008-07-02 10:31 ---
*** Bug 36692 has been marked as a duplicate of this bug. ***
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-06-25 20:26
---
(In reply to comment #2)
> there probably is a case for allowing certain such typedefs to be treated
> like keywords with regard to adding _Complex, signed or unsigned.
I second that. Can a decision be reached o
--- Comment #4 from joseph at codesourcery dot com 2007-06-02 21:35 ---
Subject: Re: Complex __float128 is rejected
On Sat, 2 Jun 2007, gdr at cs dot tamu dot edu wrote:
> | Of course, 6.7.2 paragraph 2 does not include _Complex typedef-name in the
> | possible sets of type specifier
--- Comment #3 from gdr at cs dot tamu dot edu 2007-06-02 20:28 ---
Subject: Re: Complex __float128 is rejected
"joseph at codesourcery dot com" <[EMAIL PROTECTED]> writes:
| Subject: Re: Complex __float128 is rejected
|
| On Sat, 2 Jun 2007, ubizjak at gmail dot com wrote:
|
| > I
--- Comment #2 from joseph at codesourcery dot com 2007-06-02 20:09 ---
Subject: Re: Complex __float128 is rejected
On Sat, 2 Jun 2007, ubizjak at gmail dot com wrote:
> Is this a parser problem? Compilation fails even for generic:
>
> --cut here--
> typedef float DFtype __attribute_
--- Comment #1 from ubizjak at gmail dot com 2007-06-02 19:44 ---
Is this a parser problem? Compilation fails even for generic:
--cut here--
typedef float DFtype __attribute__((mode(DF)));
__complex__ DFtype z;
void test(void) { z = 1.0+2.0i; }
--cut here--
--
http://gcc.gnu.org/
13 matches
Mail list logo
