When a vtable uses a deprecated virtual function, that's outside the
user's control and so shouldn't be warned about.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 3e78f42251b5a82bc3aa2c00b85e40abb54fc70f
Author: Jason Merrill
Date: Fri Aug 14 17:41:24 2015 +0100
PR c++/65974
FAIL: gcc.target/aarch64/target_attr_crypto_ice_1.c (internal compiler error)
In file included from
/opt/gcc/gcc-20150815/gcc/testsuite/gcc.target/aarch64/target_attr_crypto_ice_1.c:4:0:
/opt/gcc/gcc-20150815/Build/gcc/include/arm_neon.h: In function
'test_vsha1cq_u32':
/opt/gcc/gc
On Sat, Aug 15, 2015 at 2:47 AM, Kai Zhao wrote:
> Hi,
>
> There are some useless variables, class Gt, and struct CompLast in
>
> testsuite/25_algorithms/*
>
> This patch is to remove those useless variables, class Gt and struct
> CompLast.
>
> The patch is attached.
>
> commit d13ea592473ccbd2927
Robert Suchanek writes:
>> > You also need to do the same thing for TARGET_HARD_REGNO_SCRATCH_OK,
>> > to stop peephole2 from using unsaved registers as scratch registers.
>> >
>> > I should dig out my patches to clean up this interface. It's just
>> > too brittle to have two macros that say what
The symbol _ZNSt8ios_base7failureB5cxx11C1EPKcRKSt10error_code, which
appears in libstdc++, was being demangled as
std::ios_base::failure[abi:cxx11]::cxx11(char const*, std::error_code const&)
That is clearly incorrect: std::ios_base::failure does not have a
method cxx11, and anyhow if you look c
Hi Ian,
On 08/15/2015 03:23 PM, Ian Lance Taylor wrote:
The symbol _ZNSt8ios_base7failureB5cxx11C1EPKcRKSt10error_code, which
appears in libstdc++, was being demangled as
std::ios_base::failure[abi:cxx11]::cxx11(char const*, std::error_code const&)
That is clearly incorrect: std::ios_base::fai
I've committed this to the gomp4 branch. It extends the 'oacc function'
attribute's dimension handling to deal with routines. With the latter we now
use TREE_PURPOSE of the dimension list to indicate whether the routine may or
may not spawn a partitioned loop on a particular axis. I had to t
On Aug 15, 2015, at 3:32 AM, Richard Sandiford
wrote:
>
> The port is only buggy if they have define_peephole2s with match_scratches
> and those match_scratches require a register that would be saved by
> an interrupt function. In other cases defining T_H_R_S_O would have
> no effect (but still
... I think your patch fixes c++/63887. The libiberty testsuite passes
with the below applied.
Paolo.
//
Index: testsuite/demangle-expected
===
--- testsuite/demangle-expected (revision 226910)
+++ testsuite/demangl
On Aug 14, 2015, at 3:24 PM, Paolo Bonzini wrote:
> There are plenty of targets that do not require -fPIC because they always
> generate position independent code, but none of them feels the need to
> complain with the user about an unnecessary but perfectly valid option,
> on each and every .c->.
Mike Stump writes:
> On Aug 15, 2015, at 3:32 AM, Richard Sandiford
> wrote:
>>
>> The port is only buggy if they have define_peephole2s with match_scratches
>> and those match_scratches require a register that would be saved by
>> an interrupt function. In other cases defining T_H_R_S_O would
ok.
David
On Fri, Aug 14, 2015 at 11:13 PM, Teresa Johnson wrote:
> This patch resets the lambda scope based sequence numbering used to assign
> numbers to lambdas during parsing when we pop a module scope. This resets
> the numbering for subsequent modules imported during LIPO compilation.
>
>
All:
Please find the updated patch with suggestion and feedback incorporated.
Thanks Jeff and Richard for the review comments.
Following changes were done based on the feedback on RFC comments. and the
review for the previous patch.
1. Both tracer and path splitting pass are separate passes so
On Aug 15, 2015, at 9:19 AM, Richard Sandiford
wrote:
> Mike Stump writes:
>> On Aug 15, 2015, at 3:32 AM, Richard Sandiford
>> wrote:
>>>
>>> The port is only buggy if they have define_peephole2s with match_scratches
>>> and those match_scratches require a register that would be saved by
>>>
I've committed this patch to rectify the misinterpretation of the specification.
The pragma comes in two forms:
#pragma acc routine
fn-decl-or-defn
and
#pragma acc routine (name)
The latter form names a function already in scope, which makes it fairly
straight forwards. However, the
15 matches
Mail list logo
