On Fri, Nov 24, 2017 at 8:31 AM, Marc Glisse wrote:
> Hello,
>
> @@ -4247,9 +4248,20 @@ build_operator_new_call (tree fnname, vec va_gc> **args,
> we disregard block-scope declarations of "operator new". */
>fns = lookup_function_nonclass (fnname, *args,
Hello,
@@ -4247,9 +4248,20 @@ build_operator_new_call (tree fnname, vec
**args,
we disregard block-scope declarations of "operator new". */
fns = lookup_function_nonclass (fnname, *args, /*block_p=*/false);
+ if (align_arg)
+{
+ vec* align_args
+
On 16/09/16 13:12 +0100, Jonathan Wakely wrote:
On 16/09/16 11:56 +0100, Jonathan Wakely wrote:
On 16/09/16 11:37 +0200, Marc Glisse wrote:
Is the division (by a non-constant denominator) really necessary?
Probably not, but I've asked the committee for clarification what this
function should
Hi Jonathan,
> I've committed the patch now, to fix the failures for Solaris. I'll
> revisit it when I get clarification from the committee about invalid
> alignment arguments.
Solaris bootstraps with the revised patch included just completed
successfully.
Thanks.
Rainer
--
On 16/09/16 11:56 +0100, Jonathan Wakely wrote:
On 16/09/16 11:37 +0200, Marc Glisse wrote:
On Fri, 16 Sep 2016, Jonathan Wakely wrote:
On 16/09/16 09:04 +0200, Rainer Orth wrote:
Hi Jason,
OK, one more:
this works just fine on both sparc-sun-solaris2.12 and
i386-pc-solaris2.12.
Once
On 16/09/16 11:37 +0200, Marc Glisse wrote:
On Fri, 16 Sep 2016, Jonathan Wakely wrote:
On 16/09/16 09:04 +0200, Rainer Orth wrote:
Hi Jason,
OK, one more:
this works just fine on both sparc-sun-solaris2.12 and
i386-pc-solaris2.12.
Once Jonathan's patch to heed aligned_alloc's
On Fri, 16 Sep 2016, Jonathan Wakely wrote:
On 16/09/16 09:04 +0200, Rainer Orth wrote:
Hi Jason,
OK, one more:
this works just fine on both sparc-sun-solaris2.12 and
i386-pc-solaris2.12.
Once Jonathan's patch to heed aligned_alloc's requirement on size being
a multiple of alignment is
On 16/09/16 09:04 +0200, Rainer Orth wrote:
Hi Jason,
OK, one more:
this works just fine on both sparc-sun-solaris2.12 and
i386-pc-solaris2.12.
Once Jonathan's patch to heed aligned_alloc's requirement on size being
a multiple of alignment is in, all is fine on Solaris.
I've got a
On 16 September 2016 at 09:04, Rainer Orth
wrote:
> Hi Jason,
>
>> OK, one more:
>
> this works just fine on both sparc-sun-solaris2.12 and
> i386-pc-solaris2.12.
>
> Once Jonathan's patch to heed aligned_alloc's requirement on size being
> a multiple of alignment
Hi Jason,
> OK, one more:
this works just fine on both sparc-sun-solaris2.12 and
i386-pc-solaris2.12.
Once Jonathan's patch to heed aligned_alloc's requirement on size being
a multiple of alignment is in, all is fine on Solaris.
Thanks.
Rainer
--
OK, one more:
On Thu, Sep 15, 2016 at 8:12 AM, Christophe Lyon
wrote:
> On 15 September 2016 at 11:26, Rainer Orth
> wrote:
>> Hi Jason,
>>
I confirm no change on arm* either.
On aarch64, gen-attrs-[25]1.C, and devirt-33 now
On 15 September 2016 at 11:26, Rainer Orth
wrote:
> Hi Jason,
>
>>> I confirm no change on arm* either.
>>> On aarch64, gen-attrs-[25]1.C, and devirt-33 now work.
>>> name-clash11.C still fails on both targets
>>
>> Ah, I needed to remove the limit on field
Hi Jason,
>> I confirm no change on arm* either.
>> On aarch64, gen-attrs-[25]1.C, and devirt-33 now work.
>> name-clash11.C still fails on both targets
>
> Ah, I needed to remove the limit on field alignment as well. This
> seems to fix things.
The failures are gone on Solaris/SPARC
On Wed, Sep 14, 2016 at 12:08 PM, Christophe Lyon
wrote:
> On 14 September 2016 at 14:11, Andreas Schwab wrote:
>> On Sep 13 2016, Jason Merrill wrote:
>>
>>> On Tue, Sep 13, 2016 at 9:03 AM, Andreas Schwab
On 14 September 2016 at 14:11, Andreas Schwab wrote:
> On Sep 13 2016, Jason Merrill wrote:
>
>> On Tue, Sep 13, 2016 at 9:03 AM, Andreas Schwab
>> wrote:
>>> On Sep 13 2016, Jason Merrill wrote:
>>>
Does
On Sep 13 2016, Jason Merrill wrote:
> On Tue, Sep 13, 2016 at 9:03 AM, Andreas Schwab wrote:
>> On Sep 13 2016, Jason Merrill wrote:
>>
>>> Does this help?
>>
>> Unfortunatly no.
>
> It occurs to me that this function doesn't need to
Hi Jonathan,
>>* For 64-bit, I get
>>
>>+FAIL: g++.dg/cpp1z/aligned-new5.C -std=gnu++11 execution test
>>+FAIL: g++.dg/cpp1z/aligned-new5.C -std=gnu++14 execution test
>>+FAIL: g++.dg/cpp1z/aligned-new5.C -std=gnu++98 execution test
>>
>> which fails like this:
>>
>>terminate called after
On Tue, Sep 13, 2016 at 9:03 AM, Andreas Schwab wrote:
> On Sep 13 2016, Jason Merrill wrote:
>
>> Does this help?
>
> Unfortunatly no.
It occurs to me that this function doesn't need to restrict types at
all. I'm checking this in; hopefully it will do
On Sep 13 2016, Jason Merrill wrote:
> Does this help?
Unfortunatly no.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
On 10/09/16 07:59, Christophe Lyon wrote:
> On 9 September 2016 at 23:20, Jason Merrill wrote:
>> On Thu, Sep 8, 2016 at 7:06 AM, Jonathan Wakely wrote:
>>> On 08/09/16 09:10 +0200, Marc Glisse wrote:
Do we want a generic fallback implementation
Does this help?
On Tue, Sep 13, 2016 at 8:32 AM, Andreas Schwab wrote:
> On Sep 12 2016, Jason Merrill wrote:
>
>> I'm checking in this patch, which should fix the remaining issues:
>
> Unfortunatly that breaks a few other tests:
>
> FAIL:
On Sep 12 2016, Jason Merrill wrote:
> I'm checking in this patch, which should fix the remaining issues:
Unfortunatly that breaks a few other tests:
FAIL: g++.dg/cpp0x/alignas5.C -std=c++11 (test for excess errors)
FAIL: g++.dg/cpp0x/alignas5.C -std=c++14 (test for excess
On 12 September 2016 at 22:57, Jason Merrill wrote:
> I'm checking in this patch, which should fix the remaining issues:
>
Hi Jason,
Since this commit (r240100), I'm seeing failures on:
g++.dg/cpp0x/gen-attrs-21.C -std=c++11 (test for excess errors)
I'm checking in this patch, which should fix the remaining issues:
On Sat, Sep 10, 2016 at 2:14 PM, Andreas Schwab wrote:
> FAIL: g++.dg/cpp1z/aligned-new1.C (test for excess errors)
> Excess errors:
>
On Mon, Sep 12, 2016 at 12:10 PM, Jonathan Wakely wrote:
> On 12/09/16 16:13 +0200, Rainer Orth wrote:
>>
>> Jason Merrill writes:
>>
>>> On Thu, Sep 8, 2016 at 7:06 AM, Jonathan Wakely
>>> wrote:
On 08/09/16 09:10 +0200, Marc
On 12/09/16 16:13 +0200, Rainer Orth wrote:
Jason Merrill writes:
On Thu, Sep 8, 2016 at 7:06 AM, Jonathan Wakely wrote:
On 08/09/16 09:10 +0200, Marc Glisse wrote:
Do we want a generic fallback implementation (similar to
Jason Merrill writes:
> On Thu, Sep 8, 2016 at 7:06 AM, Jonathan Wakely wrote:
>> On 08/09/16 09:10 +0200, Marc Glisse wrote:
>>>
>>> Do we want a generic fallback implementation (similar to
>>> gcc/config/i386/gmm_malloc.h)? A windows version with
On 11/09/16 11:55 +0200, Christophe Lyon wrote:
On 11 September 2016 at 11:38, Jonathan Wakely wrote:
Hmm, I'm not sure why it's not failing on all targets, but this should
I don't know either: the same target (arm-none-eabi) but
--with-cpu=cortex-a9 does build.
fix it.
On 11 September 2016 at 11:38, Jonathan Wakely wrote:
> On 11/09/16 09:08 +0200, Christophe Lyon wrote:
>>
>> On 10 September 2016 at 08:59, Christophe Lyon
>> wrote:
>>>
>>> On 9 September 2016 at 23:20, Jason Merrill wrote:
On 11/09/16 10:38 +0100, Jonathan Wakely wrote:
On 11/09/16 09:08 +0200, Christophe Lyon wrote:
On 10 September 2016 at 08:59, Christophe Lyon
wrote:
On 9 September 2016 at 23:20, Jason Merrill wrote:
On Thu, Sep 8, 2016 at 7:06 AM, Jonathan
On 11/09/16 09:08 +0200, Christophe Lyon wrote:
On 10 September 2016 at 08:59, Christophe Lyon
wrote:
On 9 September 2016 at 23:20, Jason Merrill wrote:
On Thu, Sep 8, 2016 at 7:06 AM, Jonathan Wakely wrote:
On 08/09/16
On 10 September 2016 at 08:59, Christophe Lyon
wrote:
> On 9 September 2016 at 23:20, Jason Merrill wrote:
>> On Thu, Sep 8, 2016 at 7:06 AM, Jonathan Wakely wrote:
>>> On 08/09/16 09:10 +0200, Marc Glisse wrote:
Do we
FAIL: g++.dg/cpp1z/aligned-new1.C (test for excess errors)
Excess errors:
/daten/aranym/gcc/gcc-20160910/gcc/testsuite/g++.dg/cpp1z/aligned-new1.C:10:20:
warning: requested alignment 64 is larger than 16 [-Wattributes]
FAIL: g++.dg/cpp1z/aligned-new1.C execution test
FAIL:
On 10/09/16 11:25 +0200, Marc Glisse wrote:
On Sat, 10 Sep 2016, Christophe Lyon wrote:
On aarch64*-elf and arm-eabi (using newlib), I'm seeing:
/gccsrc/libstdc++-v3/libsupc++/new_opa.cc:66: undefined reference to
`aligned_alloc'
On 09/09/16 17:20 -0400, Jason Merrill wrote:
OK, this is what I'm checking in; could someone test it on MinGW?
MSDN suggests we need for _aligned_malloc, but I'm not
sure. Last time I tried to build and test MinGW it made me cry, and I
no longer have any access to Windows machines anyway.
On Sat, 10 Sep 2016, Christophe Lyon wrote:
On aarch64*-elf and arm-eabi (using newlib), I'm seeing:
/gccsrc/libstdc++-v3/libsupc++/new_opa.cc:66: undefined reference to
`aligned_alloc'
On 9 September 2016 at 23:20, Jason Merrill wrote:
> On Thu, Sep 8, 2016 at 7:06 AM, Jonathan Wakely wrote:
>> On 08/09/16 09:10 +0200, Marc Glisse wrote:
>>>
>>> Do we want a generic fallback implementation (similar to
>>> gcc/config/i386/gmm_malloc.h)? A
On Thu, Sep 8, 2016 at 7:06 AM, Jonathan Wakely wrote:
> On 08/09/16 09:10 +0200, Marc Glisse wrote:
>>
>> Do we want a generic fallback implementation (similar to
>> gcc/config/i386/gmm_malloc.h)? A windows version with _aligned_malloc /
>> _aligned_free would also be
On 08/09/16 09:10 +0200, Marc Glisse wrote:
Do we want a generic fallback implementation (similar to
gcc/config/i386/gmm_malloc.h)? A windows version with _aligned_malloc
/ _aligned_free would also be possible.
Making it work for MinGW would be nice. If there are other targets
that don't
On 08/09/16 02:06 -0400, Jason Merrill wrote:
This patch adds support for C++17 allocation of types with alignment
greater than max_align_t using 'new'. This is on by default in C++17
and can also be enabled for other -std= with -falign-new.
Nice.
If a user wants to use a different boundary
On Thu, 8 Sep 2016, Jason Merrill wrote:
This patch adds support for C++17 allocation of types with alignment
greater than max_align_t using 'new'. This is on by default in C++17
and can also be enabled for other -std= with -falign-new.
Great :-)
If a user wants to use a different boundary
This patch adds support for C++17 allocation of types with alignment
greater than max_align_t using 'new'. This is on by default in C++17
and can also be enabled for other -std= with -falign-new.
If a user wants to use a different boundary than alignof(max_align_t),
perhaps because their malloc
42 matches
Mail list logo