On 09/11/14 01:41 +0100, Marc Glisse wrote:
Hello,
I am digging out https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00637.html
It isn't completely clear if the libstdc++ part was accepted or not. I
won't commit immediately (waiting on another patch), but I'd like to
be ready.
The libstdc++
Hello,
I am digging out https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00637.html
It isn't completely clear if the libstdc++ part was accepted or not. I
won't commit immediately (waiting on another patch), but I'd like to be
ready.
The front-end part is included for reference, both versions
On Fri, 6 Jun 2014, Paolo Carlini wrote:
On 06/06/2014 04:16 PM, Marc Glisse wrote:
abi_check is broken before my patch (134 incompatible symbols).
Isn't broken for me, though. Likewise, AFAICS, on gcc-testresults. I would
recommend investigating in some detail what's going on at your end...
Hi,
On 07 giugno 2014 11:42:23 CEST, Marc Glisse marc.gli...@inria.fr wrote:
On Fri, 6 Jun 2014, Paolo Carlini wrote:
On 06/06/2014 04:16 PM, Marc Glisse wrote:
abi_check is broken before my patch (134 incompatible symbols).
Isn't broken for me, though. Likewise, AFAICS, on gcc-testresults.
Hi again,
On 06/07/2014 11:42 AM, Marc Glisse wrote:
On Fri, 6 Jun 2014, Paolo Carlini wrote:
On 06/06/2014 04:16 PM, Marc Glisse wrote:
abi_check is broken before my patch (134 incompatible symbols).
Isn't broken for me, though. Likewise, AFAICS, on gcc-testresults. I
would recommend
Hello,
here is a new try on adding __float128 typeinfo to libsupc++. The
front-end part is based on the discussion with Jason yesterday. The
libstdc++ part is copied from:
https://gcc.gnu.org/ml/libstdc++/2014-04/msg00077.html
(which wasn't reviewed), but I changed the testsuite.
Michael
Hi,
On 06/06/2014 04:16 PM, Marc Glisse wrote:
abi_check is broken before my patch (134 incompatible symbols).
Isn't broken for me, though. Likewise, AFAICS, on gcc-testresults. I
would recommend investigating in some detail what's going on at your end...
Paolo.
On Fri, Jun 6, 2014 at 3:16 PM, Marc Glisse marc.gli...@inria.fr wrote:
Hello,
here is a new try on adding __float128 typeinfo to libsupc++. The front-end
part is based on the discussion with Jason yesterday. The libstdc++ part is
copied from:
https://gcc.gnu.org/ml/libstdc++/2014-04
On 06/06/2014 10:16 AM, Marc Glisse wrote:
* config/abi/pre/float128.ver: New file.
+CXXABI_FLOAT128_1.3.9 {
What's your rationale for keeping this in a separate version block
rather than in 1.3.9 (like __int128)?
Jason
On Fri, 6 Jun 2014, Ramana Radhakrishnan wrote:
On Fri, Jun 6, 2014 at 3:16 PM, Marc Glisse marc.gli...@inria.fr wrote:
Hello,
here is a new try on adding __float128 typeinfo to libsupc++. The front-end
part is based on the discussion with Jason yesterday. The libstdc++ part is
copied from
On 06/06/14 16:40, Marc Glisse wrote:
On Fri, 6 Jun 2014, Ramana Radhakrishnan wrote:
On Fri, Jun 6, 2014 at 3:16 PM, Marc Glisse marc.gli...@inria.fr wrote:
Hello,
here is a new try on adding __float128 typeinfo to libsupc++. The front-end
part is based on the discussion with Jason
On Fri, 6 Jun 2014, Jason Merrill wrote:
On 06/06/2014 10:16 AM, Marc Glisse wrote:
* config/abi/pre/float128.ver: New file.
+CXXABI_FLOAT128_1.3.9 {
What's your rationale for keeping this in a separate version block rather
than in 1.3.9 (like __int128)?
On 06/06/2014 11:58 AM, Marc Glisse wrote:
On Fri, 6 Jun 2014, Jason Merrill wrote:
What's your rationale for keeping this in a separate version block
rather than in 1.3.9 (like __int128)?
Powerpc already has those symbols in CXXABI_LDBL_1.3 (for a type that
isn't __float128 but (de)mangles
On Fri, 6 Jun 2014, Jason Merrill wrote:
On 06/06/2014 11:58 AM, Marc Glisse wrote:
On Fri, 6 Jun 2014, Jason Merrill wrote:
What's your rationale for keeping this in a separate version block
rather than in 1.3.9 (like __int128)?
Powerpc already has those symbols in
On 06/06/2014 12:54 PM, Joseph S. Myers wrote:
If we want something like that as a standard type not supported on all
targets I'd think we should use the DTS 18661-3 naming (_Float128)
Ah, I wasn't aware of that TS, thanks. I'll check whether it's on the
C++ committee agenda yet.
Jason
On Fri, 6 Jun 2014, Jason Merrill wrote:
On 06/06/2014 11:58 AM, Marc Glisse wrote:
On Fri, 6 Jun 2014, Jason Merrill wrote:
What's your rationale for keeping this in a separate version block
rather than in 1.3.9 (like __int128)?
Powerpc already has those symbols in CXXABI_LDBL_1.3 (for a
On Fri, Jun 06, 2014 at 07:21:03PM +0200, Marc Glisse wrote:
DJ Delorie's work on __intN may be a good direction for __floatN as
well, IIUC we will have a global list of 4 __intN types, and the
target decides the value of N for each of them, so we can refer to
those type nodes in common code
On Fri, 6 Jun 2014, Marc Glisse wrote:
DJ Delorie's work on __intN may be a good direction for __floatN as well, IIUC
we will have a global list of 4 __intN types, and the target decides the value
of N for each of them, so we can refer to those type nodes in common code but
they are still
On 06/06/14 16:25, Ramana Radhakrishnan wrote:
On Fri, Jun 6, 2014 at 3:16 PM, Marc Glisse marc.gli...@inria.fr wrote:
Hello,
here is a new try on adding __float128 typeinfo to libsupc++. The front-end
part is based on the discussion with Jason yesterday. The libstdc++ part is
copied from
How about, in emit_support_tinfos, using type_for_mode to check for a
TF-mode floating point type different from long_double_type_node?
Jason
On Wed, 4 Jun 2014, Jason Merrill wrote:
How about, in emit_support_tinfos, using type_for_mode to check for a TF-mode
floating point type different from long_double_type_node?
What should I pass as the mode argument? I can't just write TFmode, that
will fail to compile on platforms that
On 06/04/2014 03:45 PM, Marc Glisse wrote:
Ah, we walk from GET_CLASS_NARROWEST_MODE (MODE_FLOAT) with
GET_MODE_WIDER_MODE steps and test if the associated type is not in the
list 0/float/double/long double. I think it should be ok with arm (it
would be good if they removed their unused XFmode,
On Wed, 21 May 2014, Jason Merrill wrote:
On 04/25/2014 05:04 AM, Marc Glisse wrote:
Does this approach seem ok, or do we need to try harder to find a way to
get this typeinfo into libsupc++?
The latter, I think; these are base types, so they should go in the library.
Hmm, ok. Because of
On 04/25/2014 05:04 AM, Marc Glisse wrote:
Does this approach seem ok, or do we need to try harder to find a way to
get this typeinfo into libsupc++?
The latter, I think; these are base types, so they should go in the
library. Sorry for the slow response.
Jason
Ping
http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01651.html
On Fri, 25 Apr 2014, Marc Glisse wrote:
On Fri, 25 Apr 2014, Marc Glisse wrote:
the previous patch had to be reverted as it broke the strange handling of
vectors in the ARM target. This new patch should be much more conservative
Hello,
the previous patch had to be reverted as it broke the strange handling of
vectors in the ARM target. This new patch should be much more conservative
I hope. Instead of adding this typeinfo to libsupc++, I am letting the FE
know that it isn't available in libsupc++. There are 2
On Fri, 25 Apr 2014, Marc Glisse wrote:
the previous patch had to be reverted as it broke the strange handling of
vectors in the ARM target. This new patch should be much more conservative I
hope. Instead of adding this typeinfo to libsupc++, I am letting the FE know
that it isn't available
27 matches
Mail list logo
