On Fri, 19 Aug 2016, Richard Biener wrote:
> Ok if libcpp maintainers do not object.
I consider the libcpp changes something I can self-approve - but, any
comments?
> Can you quickly verify if LTO works with the new types? I don't see anything
> that would prevent it but having new global tree
On Fri, Aug 19, 2016 at 1:05 PM, Joseph Myers wrote:
> On Fri, 19 Aug 2016, Richard Biener wrote:
>
>> Ok if libcpp maintainers do not object.
>
> I consider the libcpp changes something I can self-approve - but, any
> comments?
No comments on that part.
>> Can you quickly verify if LTO works wi
On Fri, 19 Aug 2016, Richard Biener wrote:
> >> Can you quickly verify if LTO works with the new types? I don't see
> >> anything
> >> that would prevent it but having new global trees and backends
> >> initializing them
> >> might come up with surprises (see tree-streamer.c:preload_common_node
On 17/08/16 21:17, Joseph Myers wrote:
> Although there is HFmode support for ARM and AArch64, use of that for
> _Float16 is not enabled. Supporting _Float16 would require additional
> work on the excess precision aspects of TS 18661-3: there are new
> values of FLT_EVAL_METHOD, which are not curr
On Fri, 2016-08-19 at 14:40 +, Joseph Myers wrote:
> On Fri, 19 Aug 2016, Richard Biener wrote:
>
> > > > Can you quickly verify if LTO works with the new types? I
> > > > don't see anything
> > > > that would prevent it but having new global trees and backends
> > > > initializing them
> > >
On Fri, 19 Aug 2016, Szabolcs Nagy wrote:
> On 17/08/16 21:17, Joseph Myers wrote:
> > Although there is HFmode support for ARM and AArch64, use of that for
> > _Float16 is not enabled. Supporting _Float16 would require additional
> > work on the excess precision aspects of TS 18661-3: there are
On Fri, 19 Aug 2016, David Malcolm wrote:
> Please could you take this opportunity to add some examples to the
> header comment for that function, both for the common cases e.g. "f",
> and for the new suffixes; nothing in the patch body appears to document
> them. (ideally, referencing the standa
On Fri, 2016-08-19 at 16:51 +, Joseph Myers wrote:
> On Fri, 19 Aug 2016, David Malcolm wrote:
>
> > Please could you take this opportunity to add some examples to the
> > header comment for that function, both for the common cases e.g.
> > "f",
> > and for the new suffixes; nothing in the pat
On Aug 17 2016, Joseph Myers wrote:
> Index: gcc/testsuite/gcc.dg/torture/fp-int-convert-float128x-timode.c
> ===
> --- gcc/testsuite/gcc.dg/torture/fp-int-convert-float128x-timode.c
> (nonexistent)
> +++ gcc/testsuite/gcc.dg/tor
On Sun, 21 Aug 2016, Andreas Schwab wrote:
> > + TEST_I_F(TItype, UTItype, _Float128, FLT128X_MANT_DIG, FLT128X_MAX_EXP);
>
> s/_Float128/_Float128x/
Thanks, fixed.
gcc/testsuite:
2016-08-22 Joseph Myers
* gcc.dg/torture/fp-int-convert-float128x-timode.c,
gcc.dg/torture/fp-
Hello,
On 17/08/16 21:17, Joseph Myers wrote:
[Version 6 changes the testsuite to use dg-add-options systematically
to add any options that may be needed for the types to be supported;
this should allow the _Float128 and _Float64x tests to run for
powerpc64le, but I have not tested that; it coul
On Mon, 22 Aug 2016, Matthew Wahab wrote:
> > + TEST_I_F(TItype, UTItype, _Float32, FLT32X_MANT_DIG, FLT32X_MAX_EXP);
> > + exit (0);
> > +
>
> This test fails with an abort at runtime. The other float32x tests pass.
That should be fixed by the commit I made to fix the issue pointed out by
An
On Mon, 22 Aug 2016, Joseph Myers wrote:
> > This change makes gcc.dg/torture/arm-fp16-int-convert-{alt,ieee].c fail
> > because they still pass four arguments to the macro, not five.
>
> I've applied this patch that should fix this.
I should point, however, that these tests are currently using
On Fri, Aug 19, 2016 at 04:23:55PM +, Joseph Myers wrote:
> On Fri, 19 Aug 2016, Szabolcs Nagy wrote:
>
> > On 17/08/16 21:17, Joseph Myers wrote:
> > > Although there is HFmode support for ARM and AArch64, use of that for
> > > _Float16 is not enabled. Supporting _Float16 would require addit
On Wed, 31 Aug 2016, James Greenhalgh wrote:
> My concern with this is that the use of comparisons of FLT_EVAL_METHOD
> against 0 that Szabolcs is referring to is common and can have performance
> implications. In glibc for example,
>
> static FLOAT
> overflow_value (int negative)
> {
>
On 31/08/16 18:26, Joseph Myers wrote:
> On Wed, 31 Aug 2016, James Greenhalgh wrote:
>
>> My concern with this is that the use of comparisons of FLT_EVAL_METHOD
>> against 0 that Szabolcs is referring to is common and can have performance
>> implications. In glibc for example,
>>
>> static FLO
On Thu, 1 Sep 2016, Szabolcs Nagy wrote:
> it seems that the FLT_EVAL_METHOD change in TS 18661 was a
> bad decision: existing code have to be modified to conform
> to the new semantics. this situation could have been avoided
> by introducing new macros or only changing behaviour when
> the user r
On Aug 17 2016, Joseph Myers wrote:
> Index: gcc/testsuite/gcc.dg/torture/float32-basic.c
> ===
> --- gcc/testsuite/gcc.dg/torture/float32-basic.c (nonexistent)
> +++ gcc/testsuite/gcc.dg/torture/float32-basic.c (working co
On Sat, 3 Sep 2016, Andreas Schwab wrote:
> On Aug 17 2016, Joseph Myers wrote:
>
> > Index: gcc/testsuite/gcc.dg/torture/float32-basic.c
> > ===
> > --- gcc/testsuite/gcc.dg/torture/float32-basic.c(nonexistent)
> > +++ gcc/test
On Mon, Sep 5, 2016 at 1:40 PM, Joseph Myers wrote:
> On Sat, 3 Sep 2016, Andreas Schwab wrote:
>
>> On Aug 17 2016, Joseph Myers wrote:
>>
>> > Index: gcc/testsuite/gcc.dg/torture/float32-basic.c
>> > ===
>> > --- gcc/testsuite/gcc.
On Tue, 6 Sep 2016, Richard Biener wrote:
> Note that this makes it maybe a good idea to only enable _FloatXX support
> for targets that have explicitely done so once we near the GCC 7 release.
I don't think that's a good idea; it's a recipe for most targets never
supporting the new types when i
Hi Joseph!
On Wed, 2016-08-17 20:17:07 +, Joseph Myers wrote:
[...]
> ISO/IEC TS 18661-3:2015 defines C bindings to IEEE interchange and
> extended types, in the form of _FloatN and _FloatNx type names with
> corresponding fN/FN and fNx/FNx constant suffixes and FLTN_* / FLTNX_*
> macros. T
Hi!
I trimmed the CC list -- I'm looking for advice about debugging a lto1
ICE.
On Fri, 19 Aug 2016 11:05:59 +, Joseph Myers
wrote:
> On Fri, 19 Aug 2016, Richard Biener wrote:
> > Can you quickly verify if LTO works with the new types? I don't see
> > anything
> > that would prevent it b
On Mon, 22 Aug 2016, Jan-Benedict Glaw wrote:
> Between dee8cef0c1c1ebf85fceb5c37996ed12a2bec352 (Fri Aug 19 15:42:11
> 2016 +) and 82c85aba845985e55c27a7a9c448810d433adb17 (Fri Aug 19
> 17:43:26 2016 +), a new build regression for
> x86_64-{linux,rtems,elf} showed up and I think this patc
On Wed, Sep 7, 2016 at 1:52 PM, Thomas Schwinge wrote:
> Hi!
>
> I trimmed the CC list -- I'm looking for advice about debugging a lto1
> ICE.
>
> On Fri, 19 Aug 2016 11:05:59 +, Joseph Myers
> wrote:
>> On Fri, 19 Aug 2016, Richard Biener wrote:
>> > Can you quickly verify if LTO works with
Hi!
On Wed, 7 Sep 2016 14:23:18 +0200, Richard Biener
wrote:
> On Wed, Sep 7, 2016 at 1:52 PM, Thomas Schwinge
> wrote:
> > I trimmed the CC list -- I'm looking for advice about debugging a lto1
> > ICE.
> >
> > On Fri, 19 Aug 2016 11:05:59 +, Joseph Myers
> > wrote:
> >> On Fri, 19 Aug
On Thu, Sep 8, 2016 at 1:43 PM, Thomas Schwinge wrote:
> Hi!
>
> On Wed, 7 Sep 2016 14:23:18 +0200, Richard Biener
> wrote:
>> On Wed, Sep 7, 2016 at 1:52 PM, Thomas Schwinge
>> wrote:
>> > I trimmed the CC list -- I'm looking for advice about debugging a lto1
>> > ICE.
>> >
>> > On Fri, 19 Au
Hi!
(CCing Bernd and Jakub -- for your information, or: "amusement" -- as
you've discussed offloading preload_common_nodes issues before...)
Got to look into this some more, yesterday:
On Thu, 08 Sep 2016 13:43:30 +0200, I wrote:
> On Wed, 7 Sep 2016 14:23:18 +0200, Richard Biener
> wrote:
> >
On Fri, Sep 16, 2016 at 9:05 AM, Thomas Schwinge
wrote:
> Hi!
>
> (CCing Bernd and Jakub -- for your information, or: "amusement" -- as
> you've discussed offloading preload_common_nodes issues before...)
>
> Got to look into this some more, yesterday:
>
> On Thu, 08 Sep 2016 13:43:30 +0200, I wro
Hi!
On Fri, 16 Sep 2016 10:59:16 +0200, Richard Biener
wrote:
> On Fri, Sep 16, 2016 at 9:05 AM, Thomas Schwinge
> wrote:
> > On Thu, 08 Sep 2016 13:43:30 +0200, I wrote:
> >> On Wed, 7 Sep 2016 14:23:18 +0200, Richard Biener
> >> wrote:
> >> > On Wed, Sep 7, 2016 at 1:52 PM, Thomas Schwinge
On Fri, 16 Sep 2016, Richard Biener wrote:
> Humm ... do we anywhere compare to those global trees by pointer equivalence?
> If so then it breaks LTO support for those types.
The C front end compares main variants to those types for handling usual
arithmetic conversions (and more generally for t
On Fri, 16 Sep 2016, Thomas Schwinge wrote:
> That's what I was afraid of: for example, I can't tell if it holds for
> all GCC configurations (back ends), that complex types' component types
> will always match one of the already existing global trees? (I can
Well, a component type could certain
On Fri, Sep 16, 2016 at 7:07 PM, Joseph Myers wrote:
> On Fri, 16 Sep 2016, Thomas Schwinge wrote:
>
>> That's what I was afraid of: for example, I can't tell if it holds for
>> all GCC configurations (back ends), that complex types' component types
>> will always match one of the already existing
On Fri, Sep 16, 2016 at 3:32 PM, Thomas Schwinge
wrote:
> Hi!
>
> On Fri, 16 Sep 2016 10:59:16 +0200, Richard Biener
> wrote:
>> On Fri, Sep 16, 2016 at 9:05 AM, Thomas Schwinge
>> wrote:
>> > On Thu, 08 Sep 2016 13:43:30 +0200, I wrote:
>> >> On Wed, 7 Sep 2016 14:23:18 +0200, Richard Biener
Hi!
On Mon, 19 Sep 2016 10:12:48 +0200, Richard Biener
wrote:
> On Fri, Sep 16, 2016 at 7:07 PM, Joseph Myers wrote:
> > On Fri, 16 Sep 2016, Thomas Schwinge wrote:
> >
> >> That's what I was afraid of: for example, I can't tell if it holds for
> >> all GCC configurations (back ends), that comp
Hi!
On Mon, 19 Sep 2016 10:18:35 +0200, Richard Biener
wrote:
> On Fri, Sep 16, 2016 at 3:32 PM, Thomas Schwinge
> wrote:
> > --- gcc/tree-core.h
> > +++ gcc/tree-core.h
> > @@ -553,20 +553,6 @@ enum tree_index {
> >TI_BOOLEAN_FALSE,
> >TI_BOOLEAN_TRUE,
> >
> > - TI_COMPLEX_INTEGER_TYP
On Mon, Sep 19, 2016 at 1:19 PM, Thomas Schwinge
wrote:
> Hi!
>
> On Mon, 19 Sep 2016 10:18:35 +0200, Richard Biener
> wrote:
>> On Fri, Sep 16, 2016 at 3:32 PM, Thomas Schwinge
>> wrote:
>> > --- gcc/tree-core.h
>> > +++ gcc/tree-core.h
>> > @@ -553,20 +553,6 @@ enum tree_index {
>> >TI_BO
On Mon, 19 Sep 2016, Thomas Schwinge wrote:
> > The question is whether such a complex type could be a global tree which I
> > don't think it could.
>
> Specifically, my question was whether for every complex type that is part
> of the global trees, it holds that the complex type's component type
38 matches
Mail list logo
