On October 23, 2015 2:24:26 PM GMT+02:00, Matthew Wahab
wrote:
>The ARMv8.1 architecture extension adds two Adv.SIMD instructions,.
>This
>patch adds support in Dejagnu for ARMv8.1 Adv.SIMD specifiers and
>checks.
>
>The new test options are
>- { dg-add-options arm_v8_1a_neon }: Add compiler opti
On Fri, Oct 23, 2015 at 07:31:51PM -0700, Cesar Philippidis wrote:
> +static tree
> +c_parser_oacc_shape_clause (c_parser *parser, omp_clause_code kind,
> + const char *str, tree list)
> +{
> + const char *id = "num";
> + tree op0 = NULL_TREE, op1 = NULL_TREE, c;
> + loc
Dear All,
This patch does four things:
(i) On deallocating class components, the vptr is set to point to the
vtable of the declared type;
(ii) When digging out the last class reference, a NULL is returned if
the allocatable component is to the right of a part reference with
non-zero rank, so that
Dear Paul,
AFAICT no patch!
Dominique
On Wed, 7 Oct 2015, Bernd Schmidt wrote:
> I think not using -Wall -Werror is the right fix.
Of course there is a fair chance (and I'll likely end up proposing
this for Wine) is that people will use -Wnounused-variable instead.
Which will disable _all_ such warnings, not only those coming from
On Sat, 2015-10-24 at 15:47 +0200, Gerald Pfeifer wrote:
> On Wed, 7 Oct 2015, Bernd Schmidt wrote:
> > I think not using -Wall -Werror is the right fix.
>
> Of course there is a fair chance (and I'll likely end up proposing
> this for Wine) is that people will use -Wnounused-variable instead.
>
Shucks! Here it is
On 24 October 2015 at 15:08, Paul Richard Thomas
wrote:
> Dear All,
>
> This patch does four things:
> (i) On deallocating class components, the vptr is set to point to the
> vtable of the declared type;
> (ii) When digging out the last class reference, a NULL is returned i
Hi!
Committed to gomp-4_0-branch in r229286:
commit 1f455fe59102d51011da2ef885731830c3c24368
Merge: 1bc39c0 ecebe44
Author: tschwinge
Date: Sat Oct 24 14:34:38 2015 +
svn merge -r 228777:229177 svn+ssh://gcc.gnu.org/svn/gcc/trunk
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc
Hello all:
After have a test, "gcc version 6.0.0 20151023 (experimental) (GCC)" has
no this issue. And bug63510 can be closed. :-)
So for me, we need not spend additional time resources on it. I shall
continue to other issues in gcc or qemu. Now, I guess, my 1st priority
is to rewrite tilegx qemu
Hello,
this patch adds OBJ_TYPE_REF that is the only code handled by ipa-icf-gimple
but not bu operand_equal_p. I tried to make the following testcase:
/* { dg-do compile } */
/* { dg-options "-O2 -fdump-tree-pre" } */
struct foo {
virtual int test ();
};
int ret (struct foo *f, int v)
{
re
The attached patch fixes an ICE that occurs when gfortran
is not expecting a PROTECTED attribute. Built and tested
on x86_64-*-freebsd. OK to commit?
2015-10-24 Steven G. Kargl
PR fortran/68054
* decl.c (match_attr_spec): PROTECTED can only be a module.
2015-10-24 Steven
> Le 24 oct. 2015 à 15:46, Dominique d'Humières a écrit :
>
> Dear Paul,
>
> AFAICT no patch!
>
> Dominique
>
If I am not mistaken, your patch fixes pr67528 also.
Dominique
At revision r229288 compiling the following test
implicit none
type :: template_t
integer :: type
character(256) :: charset1, charset2
integer :: len1, len2
end type template_t
contains
subroutine match_quoted (tt, s, n, range)
type(template_t), intent(in) :: tt
c
Le 24/10/2015 19:50, Steve Kargl a écrit :
The attached patch fixes an ICE that occurs when gfortran
is not expecting a PROTECTED attribute. Built and tested
on x86_64-*-freebsd. OK to commit?
OK. Thanks.
Mikael
Le 24/10/2015 21:29, Dominique d'Humières a écrit :
At revision r229288 compiling the following test
[...]
while it compiles without error at r229261.
I believe the accesses to ref->u.ar should be guarded with ref->type ==
REF_ARRAY.
Steve, a patch doing that is preapproved.
Mikael
FAIL: g++.dg/torture/pr67600.C -O0 (test for excess errors)
Excess errors:
In file included from
/aux/hubicka/trunk-install/include/c++/6.0.0/bits/stl_algobase.h:61:0,
from
/aux/hubicka/trunk-install/include/c++/6.0.0/bits/char_traits.h:39,
from /aux/hubicka/t
On 10/24/2015 01:03 AM, Jakub Jelinek wrote:
> On Fri, Oct 23, 2015 at 07:31:51PM -0700, Cesar Philippidis wrote:
>
>> +static tree
>> +c_parser_oacc_shape_clause (c_parser *parser, omp_clause_code kind,
>> +const char *str, tree list)
>> +{
>> + const char *id = "num";
>>
On 10/23/2015 07:37 PM, Cesar Philippidis wrote:
> On 10/23/2015 01:25 PM, Cesar Philippidis wrote:
>> On 10/22/2015 01:52 AM, Jakub Jelinek wrote:
>>> On Wed, Oct 21, 2015 at 03:18:55PM -0400, Nathan Sidwell wrote:
This patch is the C++ changes matching the C ones of patch 4. In
finish_
On Fri, 23 Oct 2015, Hurugalawadi, Naveen wrote:
+ (minus (bit_and:cs @0 (bit_not @1)) (bit_and:s @0 @1))
I am not sure why we have :c on one bit_and but not the other.
+ (bit_ior:c (bit_and:c @0 (bit_not @1)) (bit_and:c (bit_not @0) @1))
Here on the other hand, I believe the :c on bit_ior is
This implements a suggestion from Nico that if the user requested
launch::async|launch::deferred and trying to create a new thread fails
then we should return a deferred function instead.
Tested powerp64le-linux, committed to trunk.
commit ce92109967225ed196cdca5afb185702e1fabc5e
Author: Jonatha
On Sat, 24 Oct 2015, Scott Haiden wrote:
> The US, Saint Louis mirror (http://gcc.petsads.us) seems to host only
> ads. I am not sure if this is a mistake on their part or if they're
> aware of it or not, but I figured I'd let somebody know just in case.
I do hope it's just a mistake and wasn't
This implements C++17's std::invoke(), as a call to std::__invoke() so
we can also use it in C++11 and C++14.
This includes the resolution of LWG 2219 which was just passed in
Kona.
Tested powerpc64le-linux, committed to trunk.
commit 9eb38ac574c84c515c98db57abc73581d50a45dd
Author: Jonathan W
On 8 May 2015 at 15:05, Ed Smith-Rowland <3dw...@verizon.net> wrote:
> On 05/07/2015 12:06 PM, Jonathan Wakely wrote:
>>
>> Hi Ed,
>>
>> The C++ committee is considering the
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4437.pdf
>> proposal to make C++17 include the contents of ISO 29
23 matches
Mail list logo
