Hi!
On Thu, 14 Apr 2016 22:27:40 +0200, I wrote:
> On Thu, 14 Apr 2016 18:01:13 +0200, I wrote:
> > "simdclone" pass, with the
> > respective supporting code. I will certainly submit line-diff patches if
> > we agree that this is sound -- these two may actually be good candidates
> > to do first,
On 04/14/2016 07:10 PM, Olivier Hainque wrote:
>
>> On 14 Apr 2016, at 18:50, Jeff Law wrote:
>>
>> I thought we had code to handle this case specially, but I can't immediately
>> find it in sched-deps.c.
>
> Unless I misunderstood what you were exactly looking for,
> the special code is in ali
split_nonconstant_init_1 didn't know how to deal with arrays when
building a cleanup. Rather than add that logic there, we can use
cxx_maybe_build_cleanup, which does understand arrays, once we adjust it
to handle non-VAR_DECLs.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 4c385da85b
The problem with this testcase was that in order to determine whether J
is a literal type, we needed to implicitly declare its default
constructor, which calls the H default constructor, and instantiating
the template arguments for H() requires the K default constructor, which
needs the First d
Hi,
This now also shows up on GCC 5, see PR70672. It there happens in
the jump1 pass already.
Is this okay to backport to 5 and 4.9?
Segher
On Wed, Dec 09, 2015 at 08:17:51PM +, Segher Boessenkool wrote:
> The meaning of ZERO_EXTRACT depends on BITS_BIG_ENDIAN, not on
> BYTES_BIG_ENDIAN.
On Thu, Apr 14, 2016 at 6:43 PM, Michael Meissner
wrote:
> When adding the basic __float128 support, I forgot to enable direct move
> support for moving __float128 between VSX registers and GPR registers.
>
> This patch enables using direct move for __float128 variables on Power8
> systems. I boo
When adding the basic __float128 support, I forgot to enable direct move
support for moving __float128 between VSX registers and GPR registers.
This patch enables using direct move for __float128 variables on Power8
systems. I bootstrapped the compiler and found no regressions with this
patch. I
On Mon, Apr 11, 2016 at 12:15:10PM +0200, Olivier Hainque wrote:
>
> > On Mar 28, 2016, at 19:41 , Richard Henderson wrote:
> >
> > But I expect for stage4, the best solution is to strengthen the stack_tie
> > pattern to block all memory. Early scheduling of the stack frame
> > deallocation (
This patch fixes a segfault in libgomp.oacc-fortran/non-scalar-data.f90.
The problem here is that 'n' is a parameter, and the kernels region
implicitly adds a copy clause to n. Naturally, the test segfaults when
it comes time to write the value back to the host as the kernels region
terminates. Thi
My change to how we check for consistency of multiple declarators for
the same auto type-specifier failed to consider declarators of different
forms; we need to compare only the part of the declared type that
corresponds to the type-specifier.
Tested x86_64-pc-linux-gnu, applying to trunk.
com
After I applied the fix for PR 70640, one the regression testers reported the
test as an error. This system is a power7 system that does not have an
asembler that understands the power8/power9 instructions. This means that
-mcpu=power8 will only generate power7 code.
The difference for this test
When we consider whether the initializer for a constant variable makes
it value-dependent, we should check type-dependence as well as
value-dependence.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 4af96532b224029a20b192be2e7cedc60b9d12d0
Author: Jason Merrill
Date: Thu Apr 14 13:23:
When we overwrite one CONSTRUCTOR with another, we need to transfer
CONSTRUCTOR_NO_IMPLICIT_ZERO as well.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit aa2f91a9e517f9351ae9624d35b27f6a25fc1b97
Author: Jason Merrill
Date: Thu Apr 14 13:08:20 2016 -0400
PR c++/70648
* constex
On April 14, 2016 8:31:32 PM GMT+02:00, Jakub Jelinek wrote:
>Hi!
>
>On a testcase Tobias provided privately there is a -fcompare-debug
>failure due to different cgraph node->order values in the printout.
>The problem is in different result from the
>noncall_stmt_may_be_vtbl_ptr_store function on
Hi!
On a testcase Tobias provided privately there is a -fcompare-debug
failure due to different cgraph node->order values in the printout.
The problem is in different result from the
noncall_stmt_may_be_vtbl_ptr_store function on a store, which is caused
by too aggressive block pruning with -g0.
On 04/12/2016 05:57 AM, Bernd Schmidt wrote:
With some changes I was working on, I produced a situation where one of
the x86 peepholes made an incorrect transformation. In the prologue
expansion code, we have
/* When using red zone we may start register saving before allocating
the stack fra
> On 14 Apr 2016, at 18:50, Jeff Law wrote:
>
> I thought we had code to handle this case specially, but I can't immediately
> find it in sched-deps.c.
Unless I misunderstood what you were exactly looking for,
the special code is in alias.c. E.g. write_dependence_p:
/* (mem:BLK (scratch)) i
On Thu, Apr 14, 2016 at 10:40:43AM -0600, Jeff Law wrote:
> Given the BZ & list discussion, I'd consider the patch approved.
>
> I *think* the way to deal with the BZ is to change the regression marker to
> 7 and the target milestone as well. I think leaving it as a P1 would be
> fine as that'll
On 04/14/2016 09:47 AM, Andreas Krebbel wrote:
On 04/11/2016 12:15 PM, Olivier Hainque wrote:
On Mar 28, 2016, at 19:41 , Richard Henderson wrote:
But I expect for stage4, the best solution is to strengthen the stack_tie
pattern to block all memory. Early scheduling of the stack frame deal
On 04/14/2016 10:12 AM, Marek Polacek wrote:
On Thu, Apr 14, 2016 at 11:18:59AM -0400, Jason Merrill wrote:
On 04/14/2016 11:05 AM, Jakub Jelinek wrote:
On Thu, Apr 14, 2016 at 11:01:02AM -0400, Jason Merrill wrote:
On 04/14/2016 10:30 AM, Marek Polacek wrote:
+ /* FIXME: this is violated by
On Thu, Apr 14, 2016 at 11:18:59AM -0400, Jason Merrill wrote:
> On 04/14/2016 11:05 AM, Jakub Jelinek wrote:
> >On Thu, Apr 14, 2016 at 11:01:02AM -0400, Jason Merrill wrote:
> >>On 04/14/2016 10:30 AM, Marek Polacek wrote:
> >>>+ /* FIXME: this is violated by the C++ FE as discussed in PR70029,
Hi!
On Wed, 13 Apr 2016 18:01:09 +0200, I wrote:
> On Fri, 08 Apr 2016 11:36:03 +0200, I wrote:
> > On Thu, 10 Dec 2015 09:08:35 +0100, Jakub Jelinek wrote:
> > > On Wed, Dec 09, 2015 at 06:23:22PM +0100, Bernd Schmidt wrote:
> > > > On 12/09/2015 05:24 PM, Thomas Schwinge wrote:
> > > > >how abo
On 04/14/2016 03:36 PM, Thomas Schwinge wrote:
I don't know how meaningful it is to create/discuss/review/commit the
following patch until the overall approach has been agreed upon?
Why not? We agree the file should be split, and this makes it easier. So
I'll approve it for stage1, or earlier
On 14/04/16 14:15, Andrew Pinski wrote:
> On Thu, Apr 14, 2016 at 9:08 PM, Maxim Kuvyrkov
> wrote:
>> On Mar 14, 2016, at 11:14 AM, Li Bin wrote:
>>>
>>> As ARM64 is entering enterprise world, machines can not be stopped for
>>> some critical enterprise production environment, that is, live patch
On 04/11/2016 12:15 PM, Olivier Hainque wrote:
>
>> On Mar 28, 2016, at 19:41 , Richard Henderson wrote:
>>
>> But I expect for stage4, the best solution is to strengthen the stack_tie
>> pattern to block all memory. Early scheduling of the stack frame
>> deallocation (a simple logic insn) can
It caused:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70652
Sorry about that (I missed java among the languages when configuring
my build for regression testing). I'm testing a libjava patch that
I expect will eliminate the linker error.
Martin
Hi!
On Tue, 15 Apr 2014 09:58:41 +0200, Richard Biener
wrote:
> On Mon, Apr 14, 2014 at 4:48 PM, Patrick Palka wrote:
> > This patch marks "static" a bunch of locally-used, non-debug functions
> > within the GCC sources. Doing so addresses a subset of the warnings emitted
> > when compiling th
VLA's non-constant (runtime) bounds
+// causes an exception to be thrown. Test also verifies that valid
+// VLAs and their initializers don't cause such an exception.
+
+// { dg-do run { target c++11 } }
+// { dg-additional-options "-Wno-vla" }
On m68k:
/daten/aranym/
On 04/14/2016 11:05 AM, Jakub Jelinek wrote:
On Thu, Apr 14, 2016 at 11:01:02AM -0400, Jason Merrill wrote:
On 04/14/2016 10:30 AM, Marek Polacek wrote:
+ /* FIXME: this is violated by the C++ FE as discussed in PR70029, when
+ FUNCTION_*_QUALIFIED flags are set. */
+ if (0 && TYPE_MAIN_
On Thu, Apr 14, 2016 at 11:01:02AM -0400, Jason Merrill wrote:
> On 04/14/2016 10:30 AM, Marek Polacek wrote:
> >+ /* FIXME: this is violated by the C++ FE as discussed in PR70029, when
> >+ FUNCTION_*_QUALIFIED flags are set. */
> >+ if (0 && TYPE_MAIN_VARIANT (t) == t && ct && TYPE_MAIN_VA
On 04/14/2016 10:30 AM, Marek Polacek wrote:
+ /* FIXME: this is violated by the C++ FE as discussed in PR70029, when
+ FUNCTION_*_QUALIFIED flags are set. */
+ if (0 && TYPE_MAIN_VARIANT (t) == t && ct && TYPE_MAIN_VARIANT (ct) != ct)
How about guarding this check with flag_checking rat
Looking at this PR again, seems we have reached conclusion that the way forward
for GCC 6 is to temporarily disable the check, so I'm posting a patch for that,
so as to finally resolve this PR. The problem is that the C++ FE violates the
check when it sets FUNCTION_*_QUALIFIED flags.
Bootstrapped
On Thu, Apr 14, 2016 at 09:43:26AM -0400, Jason Merrill wrote:
> On 04/14/2016 09:25 AM, Nathan Sidwell wrote:
> >On 04/13/16 15:41, Jason Merrill wrote:
> >
> >>The fini_constexpr stuff is OK immediately.
> >
> >As those two objects are currently GTY((deletable)) I don't think that's
> >necessary.
On 04/14/2016 09:25 AM, Nathan Sidwell wrote:
On 04/13/16 15:41, Jason Merrill wrote:
The fini_constexpr stuff is OK immediately.
As those two objects are currently GTY((deletable)) I don't think that's
necessary. Have I missed something?
True, I suppose it doesn't make much difference.
J
Hi!
On Wed, 13 Apr 2016 20:20:19 +0200, Bernd Schmidt wrote:
> On 04/13/2016 07:56 PM, Thomas Schwinge wrote:
> > 0001-Split-up-gcc-omp-low.c-plain.patch.xz attached.
>
> That looks much better. However, the //OMPWHATEVER comments are not
> really all that helpful.
They're helpful in the word-
On Thu, Apr 14, 2016 at 02:24:48PM +0100, Kyrill Tkachov wrote:
> Ping.
> https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00142.html
>
> Thanks,
> Kyrill
> On 04/04/16 10:10, Kyrill Tkachov wrote:
> >Hi all,
> >
> >I'd like to backport Nicks' patch for PR 70044 to the GCC 5 branch.
> >The patch does
On 04/13/16 15:41, Jason Merrill wrote:
The fini_constexpr stuff is OK immediately.
As those two objects are currently GTY((deletable)) I don't think that's
necessary. Have I missed something?
The rest of the patch is OK if Jakub thinks it should go in, but if his approach
addresses the p
Ping.
https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00142.html
Thanks,
Kyrill
On 04/04/16 10:10, Kyrill Tkachov wrote:
Hi all,
I'd like to backport Nicks' patch for PR 70044 to the GCC 5 branch.
The patch doesn't apply cleanly because the
aarch64_override_options_after_change and
associated ma
On Thu, 14 Apr 2016, Bill Schmidt wrote:
> On Thu, 2016-04-14 at 13:22 +0200, Richard Biener wrote:
> > The following fixes PR70130 - improved SLP capabilities now run into
> > the realignment code on ppc which doesn't properly verify that all
> > vector loads emitted by vectorizable_load share th
On Thu, Apr 14, 2016 at 9:08 PM, Maxim Kuvyrkov
wrote:
> On Mar 14, 2016, at 11:14 AM, Li Bin wrote:
>>
>> As ARM64 is entering enterprise world, machines can not be stopped for
>> some critical enterprise production environment, that is, live patch as
>> one of the RAS features is increasing mor
On Thu, 2016-04-14 at 13:22 +0200, Richard Biener wrote:
> The following fixes PR70130 - improved SLP capabilities now run into
> the realignment code on ppc which doesn't properly verify that all
> vector loads emitted by vectorizable_load share the same alignment.
>
> Bootstrap / regtest pending
On Mar 14, 2016, at 11:14 AM, Li Bin wrote:
>
> As ARM64 is entering enterprise world, machines can not be stopped for
> some critical enterprise production environment, that is, live patch as
> one of the RAS features is increasing more important for ARM64 arch now.
>
> Now, the mainstream live
On Thu, Apr 14, 2016 at 12:25 PM, Jakub Jelinek wrote:
> On Thu, Apr 14, 2016 at 12:19:26PM +0100, Ramana Radhakrishnan wrote:
>> Is this a valid example for what you have in mind ?
>>
>> struct baz
>> {
>> char a[1024];
>> };
>> struct foo : baz
>> {
>> };
>>
>> int bar (struct foo b, int x)
>
On Thu, Apr 14, 2016 at 12:19:26PM +0100, Ramana Radhakrishnan wrote:
> Is this a valid example for what you have in mind ?
>
> struct baz
> {
> char a[1024];
> };
> struct foo : baz
> {
> };
>
> int bar (struct foo b, int x)
No, I meant say:
struct A {};
struct B { A a[1024]; };
int bar (stru
The following fixes PR70130 - improved SLP capabilities now run into
the realignment code on ppc which doesn't properly verify that all
vector loads emitted by vectorizable_load share the same alignment.
Bootstrap / regtest pending on x86_64-unknown-linux-gnu.
Bootstrapped / tested on ppc64le by
On Thu, Apr 14, 2016 at 11:36 AM, Jakub Jelinek wrote:
> On Thu, Apr 14, 2016 at 11:25:07AM +0100, Ramana Radhakrishnan wrote:
>> > I see the test failing on aarch64-none-linux-gnu (native)
>> > with no output, just:
>> > spawn [open ...]
>> > FAIL: g++.dg/abi/empty13.C -std=gnu++98 execution tes
The following patch (the 2nd hunk actually) brings down compile-time
for the testcase in the PR from to 0.5s.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2016-04-14 Richard Biener
PR tree-optimization/70614
* tree-scalar-evolution.c (analyze_evol
As partial antic compute ignores back-edges (it's a union DF problem
and thus would blow up when working over back-edges) we can avoid
iterating if we use the correct processing order (postorder).
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Queued for stage1.
Richard.
2016-0
more elements than the VLA's non-constant (runtime) bounds
> +// causes an exception to be thrown. Test also verifies that valid
> +// VLAs and their initializers don't cause such an exception.
> +
> +// { dg-do run { target c++11 } }
> +// { dg-additional-options "-W
On Thu, Apr 14, 2016 at 11:25:07AM +0100, Ramana Radhakrishnan wrote:
> > I see the test failing on aarch64-none-linux-gnu (native)
> > with no output, just:
> > spawn [open ...]
> > FAIL: g++.dg/abi/empty13.C -std=gnu++98 execution test
> >
> > And I see it passing on aarch64-none-elf.
>
> IIRC
On Thu, Apr 14, 2016 at 10:41 AM, Kyrill Tkachov
wrote:
>
> On 14/04/16 09:02, Christophe Lyon wrote:
>>
>> On 13 April 2016 at 22:12, Jason Merrill wrote:
>>>
>>> On 04/13/2016 03:18 PM, Jakub Jelinek wrote:
On Wed, Apr 13, 2016 at 03:11:34PM -0400, Jason Merrill wrote:
>
> com
Hi,
in this regression we ICE during error recovery after an additional
redundant error message. I think it's one of those cases (we have got
quite a few elsewhere, in semantics.c too) when it's better to
immediately return error_mark_node when mark_used returns false, even if
we aren't in a
On 14/04/16 09:02, Christophe Lyon wrote:
On 13 April 2016 at 22:12, Jason Merrill wrote:
On 04/13/2016 03:18 PM, Jakub Jelinek wrote:
On Wed, Apr 13, 2016 at 03:11:34PM -0400, Jason Merrill wrote:
commit 761983a023b5217ef831a43f423779940c788ecf
Author: Jason Merrill
Date: Tue Apr 12 13:1
On 13 April 2016 at 22:12, Jason Merrill wrote:
> On 04/13/2016 03:18 PM, Jakub Jelinek wrote:
>>
>> On Wed, Apr 13, 2016 at 03:11:34PM -0400, Jason Merrill wrote:
>>>
>>> commit 761983a023b5217ef831a43f423779940c788ecf
>>> Author: Jason Merrill
>>> Date: Tue Apr 12 13:16:50 2016 -0400
>>>
>>>
54 matches
Mail list logo
