On 10/21/2016 6:24 PM, Chen Gang wrote:
On 10/20/16 06:42, Jeff Law wrote:
On 6/4/16 21:25, cheng...@emindsoft.com.cn wrote:
From: Chen Gang
r10 may also be as parameter stack pointer for the nested function, so
need save it before call mcount.
Also clean up code: use '!' instead of "== 0" f
> Le 22 oct. 2016 à 16:42, Steve Kargl a
> écrit :
>
> On Sat, Oct 22, 2016 at 02:22:47PM +0200, Dominique d'Humières wrote:
>> See comments in pr78033. What are the plans to handle pr54730?
>>
>
> Not sure what you mean. I certainly will not remove
> Mikael's checkpointing in the array cons
Tested on SPARC/Solaris, applied on the mainline.
2016-10-22 Eric Botcazou
* gcc.dg/tree-ssa/pr71347.c: Remove XFAIL on SPARC.
--
Eric BotcazouIndex: gcc.dg/tree-ssa/pr71347.c
===
--- gcc.dg/tree-ssa/pr71347.c (revision
On Sat, 22 Oct 2016, Jakub Jelinek wrote:
On Sat, Oct 22, 2016 at 01:46:30PM +0200, Uros Bizjak wrote:
On Fri, Oct 21, 2016 at 5:37 PM, Uros Bizjak wrote:
On Fri, Oct 21, 2016 at 5:26 PM, Jakub Jelinek wrote:
This patch on top of the just posted patch adds folding for a couple more
builtin
On 22 October 2016 at 19:34, Ville Voutilainen
wrote:
> Cross-port the latest resolution of LWG2756 and some
> bug-fixes to experimental::optional.
> PR libstc++/77288
> PR libstdc++/77727
And yes, I'll fix that first PR reference before committing the
ChangeLog changes. :)
Tested on Linux-x64. Ok for trunk and the gcc-6 branch?
2016-10-22 Ville Voutilainen
Cross-port the latest resolution of LWG2756 and some
bug-fixes to experimental::optional.
PR libstc++/77288
PR libstdc++/77727
* include/experimental/optional (_Optional_base):
Remove c
Bug 71115 - [5/6 Regression] Missing warning: excess elements
in struct initializer, was fixed on trunk but the bug is still
open since the patch hasn't been backported to the affected
branches.
Is it okay to go ahead and backport it to 6.x and 5.x?
The original patch was posted here:
https://
On Sat, Oct 22, 2016 at 01:46:30PM +0200, Uros Bizjak wrote:
> On Fri, Oct 21, 2016 at 5:37 PM, Uros Bizjak wrote:
> > On Fri, Oct 21, 2016 at 5:26 PM, Jakub Jelinek wrote:
> >
> >> This patch on top of the just posted patch adds folding for a couple more
> >> builtins (though, hundreds or thousa
On Sat, Oct 22, 2016 at 02:22:47PM +0200, Dominique d'Humières wrote:
> See comments in pr78033. What are the plans to handle pr54730?
>
Not sure what you mean. I certainly will not remove
Mikael's checkpointing in the array constructor code,
leaving array_constructor_43.f90 broken.
--
Steve
Hi Paul,
thanks for the review. Committed as r241439.
The first nit has gone to the patch for pr78053 as agreed upon.
The second nit:
> + class(r), allocatable :: foo ! Need this declared of copy_R is not
> generated.
has magically disappeared. I assume that it was necessary on an intermedia
Hello world,
this rather self-explanatory patch fixes a problem where two
function invocations with 'c' and 'c' as arguments
were considered equal.
Regression-tested. OK for trunk and 6 and 5 branches?
Regards
Thomas
2016-10-22 Thomas Koenig
PR fortran/78021
*
See comments in pr78033. What are the plans to handle pr54730?
Dominique
On 21/10/16 18:01 +0100, Jonathan Wakely wrote:
LWG2720 implement filesystem::perms::symlink_nofollow
* include/experimental/bits/fs_fwd.h (perms::resolve_symlinks):
Replace with symlink_nofollow (LWG 2720).
* src/filesystem/ops.cc (permissions(const path&, perms, erro
On Fri, Oct 21, 2016 at 5:37 PM, Uros Bizjak wrote:
> On Fri, Oct 21, 2016 at 5:26 PM, Jakub Jelinek wrote:
>
>> This patch on top of the just posted patch adds folding for a couple more
>> builtins (though, hundreds or thousands of other md builtins remain unfolded
>> even though they actually c
Hi Eric,
Thanks for the patch. Unfortunately there is a big problem with it :-(
On Sat, Oct 22, 2016 at 01:03:33AM +0200, Eric Botcazou wrote:
> this implements support for signed overflow arithmetic on PowerPC. It's an
> implementation for Power ISA v2.0x, i.e. it doesn't take account the new
On 21/10/16 21:21 +0200, François Dumont wrote:
Hi
I configured libstdc++ to use gnu-version-namespace and there are
a number of failures, see below. But none of them related to this
patch so is it ok to commit ?
Yes, OK to commit - it doesn't make the test results any worse than
they wer
Dear Andre,
For the bulk of the patch, I have no comments. However, for the
testcase alloc_comp_class_5.f03, please eliminate the commented out
lines and the TODO, as discussed on #gfortran. Add them to the
testcase for for PR78053, as we agreed.
In realloc_on_assign_27.f08, you have the followin
> However, it was pointed out to me that apparently there is a policy
> or convention of not backporting to release branches bug fixes that
> cause GCC to reject code that was previously accepted, even if the
> code is invalid.
It's more of a judgment call I'd say, if the accept-invalid leads to w
I also see
FAIL: gfortran.dg/select_type_9.f03 -O (test for errors, line 16)
FAIL: gfortran.dg/select_type_9.f03 -O (test for excess errors)
The errors emitted by the test have changed from
/opt/gcc/_clean/gcc/testsuite/gfortran.dg/select_type_9.f03:16:11:
class is (t) ! { dg-error "D
Hi Dominique,
Thanks for the heads up!
I was going to review Andre's patch this morning, so I will clean my
tree, apply it, confirm that it is regression free and then will
generate a compatible version of my patch for PR69834. I strongly
suspect that the core of the patch is OK and that it is th
20 matches
Mail list logo
