https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #40 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
Michael Meissner changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #38 from Jonathan Wakely ---
(In reply to Peter Bergner from comment #36)
> Is this fixed now?
Yes, I think the macros are defined consistently with the types now. Let's
close it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #37 from CVS Commits ---
The master branch has been updated by Alexandre Oliva :
https://gcc.gnu.org/g:86b31d583a3657f11d930ff156c07b2e20ab05eb
commit r13-7191-g86b31d583a3657f11d930ff156c07b2e20ab05eb
Author: Alexandre Oliva
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
Peter Bergner changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #35 from CVS Commits ---
The releases/gcc-10 branch has been updated by Michael Meissner
:
https://gcc.gnu.org/g:8437794102e86a1bd5f2257aa95ea76890810a28
commit r10-10493-g8437794102e86a1bd5f2257aa95ea76890810a28
Author: Michael Mei
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #34 from CVS Commits ---
The releases/gcc-11 branch has been updated by Michael Meissner
:
https://gcc.gnu.org/g:6f581f90e3757392a510f11279e2daf5fcfdefa8
commit r11-9649-g6f581f90e3757392a510f11279e2daf5fcfdefa8
Author: Michael Meis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #33 from Jakub Jelinek ---
In https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591521.html Segher said
those backports should be reverted.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #31 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:6f8abf2b9ff4f165a61295cdb3525ce1da2a77c6
commit r12-7576-g6f8abf2b9ff4f165a61295cdb3525ce1da2a77c6
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #30 from Segher Boessenkool ---
There should be a __SIZEOF_IEEE128__ as well, of course.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #29 from CVS Commits ---
The releases/gcc-10 branch has been updated by Michael Meissner
:
https://gcc.gnu.org/g:641b407763ecfee5d4ac86d8ffe9eb1eeea5fd10
commit r10-10486-g641b407763ecfee5d4ac86d8ffe9eb1eeea5fd10
Author: Michael Mei
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #28 from CVS Commits ---
The releases/gcc-11 branch has been updated by Michael Meissner
:
https://gcc.gnu.org/g:fa944e8660e158655beda58e12b69fd18dd49108
commit r11-9639-gfa944e8660e158655beda58e12b69fd18dd49108
Author: Michael Meis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #27 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #26)
> (In reply to Segher Boessenkool from comment #25)
> > It is defined to __ieee128 whenever that exists, and not defined otherwise?
> > Yes, the logic and co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #26 from Jakub Jelinek ---
(In reply to Segher Boessenkool from comment #25)
> It is defined to __ieee128 whenever that exists, and not defined otherwise?
> Yes, the logic and control flow are byzantine.
No, far from it.
E.g. on linu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #25 from Segher Boessenkool ---
It is defined to __ieee128 whenever that exists, and not defined otherwise?
Yes, the logic and control flow are byzantine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #24 from Jakub Jelinek ---
(In reply to Segher Boessenkool from comment #22)
> In rs6000_type_string, please just handle the error !type_node case first,
> so you don't have to consider it in all other cases separately.
Ok, will do.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #23 from Segher Boessenkool ---
Oh, and looks great, thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #22 from Segher Boessenkool ---
In rs6000_type_string, please just handle the error !type_node case first,
so you don't have to consider it in all other cases separately.
Do you need to change the __SIZEOF_FLOAT128__ code at all now?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #21 from Jakub Jelinek ---
Created attachment 52566
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52566&action=edit
gcc12-pr99708.patch
Updated patch I'm going to test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #20 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #19)
> I'd guess that else ieee128_float_type_node = ibm128_float_type_node =
> long_double_type_node;
> is there so that we don't ICE during the builtins creatio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #19 from Jakub Jelinek ---
builddir/gcc/rs6000-builtins.cc:
ibm128_float_type_node,
builddir/gcc/rs6000-builtins.cc:= build_function_type_list
(ibm128_float_type_node,
rs6000-builtin.cc: else if (ty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #18 from Segher Boessenkool ---
Ah, I didn't see the
else
ieee128_float_type_node = ibm128_float_type_node = long_double_type_node;
which looks completely garbage. It long double is just DP float, we certainly
do not want eithe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #17 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #13)
> I see
> Doesn't this mean that ieee128_float_type_node and ibm128_float_type_node is
> always non-NULL?
No. All of that code is inside
if (TARGET_F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #16 from Jakub Jelinek ---
So what about:
--- gcc/config/rs6000/rs6000-c.cc.jj2022-02-17 10:24:16.756113275 +0100
+++ gcc/config/rs6000/rs6000-c.cc 2022-03-03 19:06:25.771981905 +0100
@@ -584,6 +584,10 @@ rs6000_target_modif
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #15 from Jakub Jelinek ---
Perhaps another possible test could be
ieee128_float_type_node != ibm128_float_type_node
because whenever those two are different, we know __ieee128 and __ibm128 are
supported (but still need to verify wheth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #14 from Jakub Jelinek ---
Unfortunately, checking TYPE_NAME won't work either.
Because for the ibm128_float_type_node = long_double_type_node;
and ieee128_float_type_node = long_double_type_node; cases,
lang_hooks.types.register_buil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #13 from Jakub Jelinek ---
I see
if (TARGET_FLOAT128_TYPE)
{
if (!TARGET_IEEEQUAD && TARGET_LONG_DOUBLE_128)
ibm128_float_type_node = long_double_type_node;
else
{
ibm128_float_type_node = m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #12 from Segher Boessenkool ---
(In reply to Jonathan Wakely from comment #10)
> Maybe we could do this instead:
>
> --- a/gcc/config/rs6000/rs6000-c.cc
> +++ b/gcc/config/rs6000/rs6000-c.cc
> @@ -623,11 +623,13 @@ rs6000_cpu_cpp_bui
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
Segher Boessenkool changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #10 from Jonathan Wakely ---
Maybe we could do this instead:
--- a/gcc/config/rs6000/rs6000-c.cc
+++ b/gcc/config/rs6000/rs6000-c.cc
@@ -623,11 +623,13 @@ rs6000_cpu_cpp_builtins (cpp_reader *pfile)
if (TARGET_FRSQRTES)
built
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #9 from Jonathan Wakely ---
It looks like r12-7271-g687e57d7ac741d added it:
--- a/gcc/config/rs6000/rs6000-c.cc
+++ b/gcc/config/rs6000/rs6000-c.cc
@@ -623,7 +623,11 @@ rs6000_cpu_cpp_builtins (cpp_reader *pfile)
if (TARGET_FRSQR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #8 from Jonathan Wakely ---
It looks like trunk now defines __SIZEOF_FLOAT128__ on powerpc-ibm-aix* and
powerpc64*-*-linux-gnu, but it seems to be defined unconditionally, even if the
__float128 type *isn't* available!
On power8-aix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #7 from Jonathan Wakely ---
(In reply to Segher Boessenkool from comment #6)
> Yes. And it does not mean the type exist (or is usable), either.
Example?
> Do we? The types should always exist!
Please tell that to our IBM colleagu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #6 from Segher Boessenkool ---
(In reply to Jonathan Wakely from comment #5)
> (In reply to Segher Boessenkool from comment #3)
> > In an ideal world the user can just assume those types exist always.
> Arguably a __SIZEOF_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #5 from Jonathan Wakely ---
(In reply to Segher Boessenkool from comment #3)
> In an ideal world the user can just assume those types exist always. In a
> less ideal world, use autoconf? You have to anyway, if you want to support
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #4 from Jakub Jelinek ---
__SIZEOF_FLOAT128__ is predefined on all targets that have the __float128 type,
except for rs6000:
grep '"__float128"' */*
i386/i386-builtins.c: lang_hooks.types.register_builtin_type
(float128_type_node, "_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #3 from Segher Boessenkool ---
The only such __SIZEOF_* macro that is not about a standards-required type
is for int128. Not the best example ;-)
There are not predefines for __SIZEOF_FLOAT128__ etc. either.
In an ideal world the u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #2 from Jakub Jelinek ---
The __SIZEOF_*__ macros are widely used to detect both if a type can be used
and what sizeof (the_type) is when it needs to be checked in preprocessor
conditionals, including hundreds of times in GCC testsuit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #1 from Segher Boessenkool ---
Yes, the __SIZEOF_* macros do not say whether some type can be used. This is
true for all targets!
What would it be useful for to define these macros? They all are equivalent to
#define SIXTEEN 16
:
41 matches
Mail list logo
