public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug target/32187] Complex __float128 is rejected
       [not found] <bug-32187-4@http.gcc.gnu.org/bugzilla/>
@ 2023-05-15  7:09 ` pinskia at gcc dot gnu.org
  0 siblings, 0 replies; 10+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-05-15  7:09 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32187

--- Comment #13 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to joseph@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 
> supported (although not supporting that means also not supporting _Complex 
> __ibm128 for powerpc64le; both are built-in typedefs, and no _Float* 
> keyword can be used for __ibm128).
> 
> _Float128 isn't supported for C++, although there's the argument that 
> there std::complex<__float128> is the thing support should be added / 
> enabled for, rather than adding to the support for C-style complex types 
> in C++.

C++'s _Float128 support was added with r13-2887-b04208895fed34 .

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug target/32187] Complex __float128 is rejected
  2007-06-02 13:16 [Bug target/32187] New: " fxcoudert at gcc dot gnu dot org
                   ` (7 preceding siblings ...)
  2009-09-27  9:28 ` ktietz at gcc dot gnu dot org
@ 2010-05-03  7:22 ` and_j_rob at yahoo dot com
  8 siblings, 0 replies; 10+ messages in thread
From: and_j_rob at yahoo dot com @ 2010-05-03  7:22 UTC (permalink / raw)
  To: gcc-bugs



------- 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 trying to learn about how the ABI works (with the attached code) when I
stumbled upon this.

Here is an overview of different combinations of floats and languages.

complex<*>..|.C..............|.C++
------------+----------------+--------
long double.|.(good).........|.(good)
__float80...|.(syntax error).|.(good)
__float128..|.(syntax error).|.(internal compiler error)

the ICE is
test.cpp:25: internal compiler error: in write_builtin_type, at
cp/mangle.c:1793

so I think what caused the ICE was the std::complex<__float128> snippet.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32187


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug target/32187] Complex __float128 is rejected
  2007-06-02 13:16 [Bug target/32187] New: " fxcoudert at gcc dot gnu dot org
                   ` (6 preceding siblings ...)
  2009-09-27  9:26 ` ktietz at gcc dot gnu dot org
@ 2009-09-27  9:28 ` ktietz at gcc dot gnu dot org
  2010-05-03  7:22 ` and_j_rob at yahoo dot com
  8 siblings, 0 replies; 10+ messages in thread
From: ktietz at gcc dot gnu dot org @ 2009-09-27  9:28 UTC (permalink / raw)
  To: gcc-bugs



------- 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 base
> type, instead of the current type declaration as "mode" attribute does.
> 
> by defining __float128 as '#define __float128 float __attribute__
> ((basetype_mode(DF)))'
> 
> Constructs like '__complex__ DFtype z;' getting handled proper, too.
Err, I meant here of course '__complex__ __float128 z;'

> Maybe this is a way to solve this issue.
> 
> Kai
> 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32187


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug target/32187] Complex __float128 is rejected
  2007-06-02 13:16 [Bug target/32187] New: " fxcoudert at gcc dot gnu dot org
                   ` (5 preceding siblings ...)
  2008-07-02 10:32 ` jsm28 at gcc dot gnu dot org
@ 2009-09-27  9:26 ` ktietz at gcc dot gnu dot org
  2009-09-27  9:28 ` ktietz at gcc dot gnu dot org
  2010-05-03  7:22 ` and_j_rob at yahoo dot com
  8 siblings, 0 replies; 10+ messages in thread
From: ktietz at gcc dot gnu dot org @ 2009-09-27  9:26 UTC (permalink / raw)
  To: gcc-bugs



------- 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 current type declaration as "mode" attribute does.

by defining __float128 as '#define __float128 float __attribute__
((basetype_mode(DF)))'

Constructs like '__complex__ DFtype z;' getting handled proper, too.

Maybe this is a way to solve this issue.

Kai


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32187


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug target/32187] Complex __float128 is rejected
  2007-06-02 13:16 [Bug target/32187] New: " fxcoudert at gcc dot gnu dot org
                   ` (4 preceding siblings ...)
  2007-06-25 20:26 ` fxcoudert at gcc dot gnu dot org
@ 2008-07-02 10:32 ` jsm28 at gcc dot gnu dot org
  2009-09-27  9:26 ` ktietz at gcc dot gnu dot org
                   ` (2 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: jsm28 at gcc dot gnu dot org @ 2008-07-02 10:32 UTC (permalink / raw)
  To: gcc-bugs



------- 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
----------------------------------------------------------------------------
                 CC|                            |hjl dot tools at gmail dot
                   |                            |com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32187


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug target/32187] Complex __float128 is rejected
  2007-06-02 13:16 [Bug target/32187] New: " fxcoudert at gcc dot gnu dot org
                   ` (3 preceding siblings ...)
  2007-06-02 21:35 ` joseph at codesourcery dot com
@ 2007-06-25 20:26 ` fxcoudert at gcc dot gnu dot org
  2008-07-02 10:32 ` jsm28 at gcc dot gnu dot org
                   ` (3 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: fxcoudert at gcc dot gnu dot org @ 2007-06-25 20:26 UTC (permalink / raw)
  To: gcc-bugs



------- 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 on whether or not this is a bug, so
that we can work on libgfortran accordingly?

(for us, being able to use _Complex __float128 would really be a lot simpler)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32187


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug target/32187] Complex __float128 is rejected
  2007-06-02 13:16 [Bug target/32187] New: " fxcoudert at gcc dot gnu dot org
                   ` (2 preceding siblings ...)
  2007-06-02 20:28 ` gdr at cs dot tamu dot edu
@ 2007-06-02 21:35 ` joseph at codesourcery dot com
  2007-06-25 20:26 ` fxcoudert at gcc dot gnu dot org
                   ` (4 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: joseph at codesourcery dot com @ 2007-06-02 21:35 UTC (permalink / raw)
  To: gcc-bugs



------- 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 specifiers.
> 
> Out of curiosity, do you happen to know why typedefs to floating point
> types should be disallowed?

Typedefs have never been allowed along with other type specifiers; it's 
much the same as not allowing "unsigned T" or "T unsigned" where T is a 
typedef for int.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32187


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug target/32187] Complex __float128 is rejected
  2007-06-02 13:16 [Bug target/32187] New: " fxcoudert at gcc dot gnu dot org
  2007-06-02 19:44 ` [Bug target/32187] " ubizjak at gmail dot com
  2007-06-02 20:09 ` joseph at codesourcery dot com
@ 2007-06-02 20:28 ` gdr at cs dot tamu dot edu
  2007-06-02 21:35 ` joseph at codesourcery dot com
                   ` (5 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: gdr at cs dot tamu dot edu @ 2007-06-02 20:28 UTC (permalink / raw)
  To: gcc-bugs



------- 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" <gcc-bugzilla@gcc.gnu.org> writes:

| 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__((mode(DF)));
| > 
| > __complex__ DFtype z;
| 
| Of course, 6.7.2 paragraph 2 does not include _Complex typedef-name in the 
| possible sets of type specifiers.

Out of curiosity, do you happen to know why typedefs to floating point
types should be disallowed?

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32187


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug target/32187] Complex __float128 is rejected
  2007-06-02 13:16 [Bug target/32187] New: " fxcoudert at gcc dot gnu dot org
  2007-06-02 19:44 ` [Bug target/32187] " ubizjak at gmail dot com
@ 2007-06-02 20:09 ` joseph at codesourcery dot com
  2007-06-02 20:28 ` gdr at cs dot tamu dot edu
                   ` (6 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: joseph at codesourcery dot com @ 2007-06-02 20:09 UTC (permalink / raw)
  To: gcc-bugs



------- 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__((mode(DF)));
> 
> __complex__ DFtype z;

Of course, 6.7.2 paragraph 2 does not include _Complex typedef-name in the 
possible sets of type specifiers.  __float128 is a built-in typedef, but 
there probably is a case for allowing certain such typedefs to be treated 
like keywords with regard to adding _Complex, signed or unsigned.

You should be able to use

typedef _Complex float TCtype __attribute__((mode(TC)));

or similar to access _Complex __float128 at present.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32187


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug target/32187] Complex __float128 is rejected
  2007-06-02 13:16 [Bug target/32187] New: " fxcoudert at gcc dot gnu dot org
@ 2007-06-02 19:44 ` ubizjak at gmail dot com
  2007-06-02 20:09 ` joseph at codesourcery dot com
                   ` (7 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: ubizjak at gmail dot com @ 2007-06-02 19:44 UTC (permalink / raw)
  To: gcc-bugs



------- 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/bugzilla/show_bug.cgi?id=32187


^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2023-05-15  7:09 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <bug-32187-4@http.gcc.gnu.org/bugzilla/>
2023-05-15  7:09 ` [Bug target/32187] Complex __float128 is rejected pinskia at gcc dot gnu.org
2007-06-02 13:16 [Bug target/32187] New: " fxcoudert at gcc dot gnu dot org
2007-06-02 19:44 ` [Bug target/32187] " ubizjak at gmail dot com
2007-06-02 20:09 ` joseph at codesourcery dot com
2007-06-02 20:28 ` gdr at cs dot tamu dot edu
2007-06-02 21:35 ` joseph at codesourcery dot com
2007-06-25 20:26 ` fxcoudert at gcc dot gnu dot org
2008-07-02 10:32 ` jsm28 at gcc dot gnu dot org
2009-09-27  9:26 ` ktietz at gcc dot gnu dot org
2009-09-27  9:28 ` ktietz at gcc dot gnu dot org
2010-05-03  7:22 ` and_j_rob at yahoo dot com

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).