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++ pa
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 w
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 invest
Hi,
On 07 giugno 2014 11:42:23 CEST, 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
>
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...
On 06/06/14 16:25, Ramana Radhakrishnan wrote:
> On Fri, Jun 6, 2014 at 3:16 PM, Marc Glisse 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
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 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 cod
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 t
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
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 t
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)?
https://gcc.gnu.org/bugzilla/s
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 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
On Fri, 6 Jun 2014, Ramana Radhakrishnan wrote:
On Fri, Jun 6, 2014 at 3:16 PM, Marc Glisse 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
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, Jun 6, 2014 at 3:16 PM, Marc Glisse 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++/201
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.
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.
Mi
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, b
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 don'
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, 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 th
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
I
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 in
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 versions,
27 matches
Mail list logo