On Fri, Jan 22, 2016 at 05:36:14PM +1100, Kugan wrote:
> There is a redundant unshare_expr in ipa-prop. Attached patch removes
> it. Bootstrapped and regression tested on x86_64-pc-linux-gnu with no
> new regressions.
>
> Is this OK for trunk?
>
> Thanks,
> Kugan
>
> gcc/ChangeLog:
>
> 2016-01-
On Fri, Jan 22, 2016 at 08:40:26AM +0100, Thomas Schwinge wrote:
> On Thu, 21 Jan 2016 22:54:26 +0100, I wrote:
> > On Mon, 18 Jan 2016 18:26:49 +0100, Tom de Vries
> > wrote:
> > > [...] [OpenACC] kernels region [...]
> > > that parloops does not manage to parallelize:
>
> > Telling from real-w
Hi Jakub!
On Fri, 22 Jan 2016 09:36:25 +0100, Jakub Jelinek wrote:
> On Fri, Jan 22, 2016 at 08:40:26AM +0100, Thomas Schwinge wrote:
> > On Thu, 21 Jan 2016 22:54:26 +0100, I wrote:
> > > On Mon, 18 Jan 2016 18:26:49 +0100, Tom de Vries
> > > wrote:
> > > > [...] [OpenACC] kernels region [...]
> Isn't this kind of implied by the already documented restriction of
> taking the address of a union field? Still, you can add this or any kind
> of similar language if you like.
It's stronger I think since you can do type punning without taking an address.
--
Eric Botcazou
> This patch is OK.
Thanks.
> I wish somebody could fix the existing documentation for this attribute
> to use the present tense instead of the future to describe GCC's current
> behavior, though :-S
I think it's a common idiom: if you do this, then the compiler will do that.
I can see it i
Hi Han,
On 21/01/16 22:57, Han Shen wrote:
Hi Kyrill, the patched gcc generates correct asm for me for the test
case. (I'll then build the whole system to see if other it-block
related bugs are gone too.)
One short question, the newly generated RTL for
x = x |(a)
will be
orr %0,
As described in the PR, wi::divmod_internal was sign- rather than
zero-extending a modulus result in cases where the result has fewer
HWIs than the precision and the upper bit of the upper HWI was set.
This patch tries to make things more robust by getting wi_pack
to handle the canonicalisation st
Hi all,
PR target/65932 is a wrong-code bug affecting arm and has manifested itself
when compiling the Linux kernel, so it's something that we really
ought to fix. The problem stems from the fact that PROMOTE_MODE and
TARGET_PROMOTE_FUNCTION_MODE don't match up on arm.
PROMOTE_MODE also marks the
Hi all,
As part of investigating the codegen effects of a fix for PR 65932 I found we
assign
too high a cost for the sign-extending multiply instruction SMULBB.
This is because we add the cost of a multiply-extend but then also recurse into
the
SIGN_EXTEND sub-expressions rather than the regist
Hi all,
This patch is a consequence of the thread I started at
https://gcc.gnu.org/ml/gcc/2016-01/msg00100.html
The problem is that the fold_rtx call in cse_insn may overwrite its argument if
the insn argument is non-NULL.
This leads to CSE not considering the original form of the RTX when doin
Hi all,
This patch adds an execute testcase that is fixed by the arm.h hunk of Jim
Wilson's
patch that he posted at:
https://gcc.gnu.org/ml/gcc-patches/2015-06/msg02132.html
I propose this testsuite change instead of the testsuite changes in that patch
since
the gcc.target/arm/wmul-[123].c reg
Hi all,
In this final patch I adjust the troublesome gcc.target/arm/wmul-[123].c tests
to make them more helpful.
gcc.target/arm/wmul-[12].c may now generate either sign-extending multiplies
(+accumulate) or normal 32-bit multiplies since the arguments to the multiplies
are already sign-extended
On Fri, Jan 22, 2016 at 09:43:52AM +, Richard Sandiford wrote:
> gcc/
> PR tree-optimization/69400
> * wide-int.cc (wi_pack): Take the precision as argument and
> perform canonicalization here rather than in the callers.
> Use the main loop to handle all full-width HWIs.
On 21/01/16 10:22, Christian Bruel wrote:
A tiny patch to cleanup the cpp_opts->warn_builtin_macro_redefined setting in
arm_pragma_target_parse. Removes this hack obsoleted by the use of
NODE_CONDITIONAL for pr target/69180.
regtested for arm-linux-gnueabi -mfpu=vfp, -mfpu=neon,-mfpu=neon-fp-
On Thu, Jan 21, 2016 at 04:24:46PM +0100, Bernd Schmidt wrote:
> Thomas, I've mentioned this issue before - there is sometimes just too much
> irrelevant stuff to wade through in your patch submissions, and it
> discourages review. The discussion of the actual problem begins more than
> halfway thr
On Thu, Jan 21, 2016 at 07:17:59AM +0100, Thomas Schwinge wrote:
> Ping.
I'd prefer to keep the code as is, it is closer to what could result from
the user trying to do a similar thing, and thus has a better chance of
keeping being supported.
Jakub
On Wed, Jan 20, 2016 at 09:53:30PM +0300, Ilya Verbin wrote:
> If you're OK with this, I'll install this patch:
>
>
> libgomp/
> * target.c (gomp_get_target_fn_addr): Allow host fallback if target
> function wasn't mapped to the device with non-shared memory.
Ok, thanks.
> diff --gi
On Fri, Jan 22, 2016 at 9:32 AM, Kyrill Tkachov
wrote:
> Hi Han,
>
> On 21/01/16 22:57, Han Shen wrote:
>>
>> Hi Kyrill, the patched gcc generates correct asm for me for the test
>> case. (I'll then build the whole system to see if other it-block
>> related bugs are gone too.)
>>
>> One short que
On Tue, Jan 19, 2016 at 03:02:48PM +0900, Chung-Lin Tang wrote:
> Ping x 2.
I like the general idea of moving the gomp_fatal stuff up, out of the
plugins, but we now have another plugin, so it can't apply as is.
And in the intelmic plugin, adding return true; after abort (); looks wrong.
So, can y
On Sun, Jan 17, 2016 at 05:01:24PM -0600, James Norris wrote:
> The attached patch addresses the failure of declare-4 in the libgomp
> testsuite.
> The primary failure was the use a variable with a link clause for an OpenACC
> routine function. The patch changes the test to use a create clause. Th
On 21/01/16 19:07 -0500, Ed Smith-Rowland wrote:
On 01/21/2016 07:29 AM, Jonathan Wakely wrote:
On 20/01/16 20:30 -0500, Ed Smith-Rowland wrote:
Now that libstdc++ installs a proper math.h we can piggyback on
that to put in the last bit of TR29124.
This patch adds the math special functions t
This is a scan-tree-dump failure in vect-over-widen-3-big-array.c, that occurs
only on ARM - the only platform to have vect_widen_shift.
Tested on arm-none-eabi (armv8-crypto-neon-fp, plus a non-neon variant), also
aarch64 (token platform without vect_widen_shift).
gcc/testsuite/ChangeLog:
On Fri, Jan 22, 2016 at 11:51 AM, Alan Lawrence wrote:
> This is a scan-tree-dump failure in vect-over-widen-3-big-array.c, that occurs
> only on ARM - the only platform to have vect_widen_shift.
>
> Tested on arm-none-eabi (armv8-crypto-neon-fp, plus a non-neon variant), also
> aarch64 (token pla
> I only updated
> - /* Don't inline if the callee can throw non-call exceptions but the
> - caller cannot.
> - FIXME: this is obviously wrong for LTO where STRUCT_FUNCTION is
> missing. - Move the flag into cgraph node or mirror it in the inline
> summary. */ - else if (callee_fun &
On Fri, Jan 22, 2016 at 12:06 AM, Andrew MacLeod wrote:
> I was trying the ttype prototype for static type checking on fold-const.c to
> see how long it would take me to convert such a large file, and it choked on
> this snippet of code in fold_unary_loc, around lines 7690-7711:
>
> suspect code t
On Fri, Jan 22, 2016 at 2:17 AM, Andrew Pinski wrote:
> On Wed, Jan 13, 2016 at 4:36 AM, Richard Biener
> wrote:
>> On Wed, Jan 13, 2016 at 9:27 AM, Andrew Pinski wrote:
>>> Hi,
>>> The support -combine was removed a while back but cc1 still accepts
>>> more than one file if directly invoked.
> I am fine with it being relaxed and permitting inlining !non_call_exceptions
> to non_call_exceptions functions.. It would be also cool to have a
> testcases.
Thanks, patch installed with check_match changed to check_maybe_up, I'll work
towards adding an Ada+C LTO test but this will require fi
On Fri, Jan 22, 2016 at 10:52 AM, Kyrill Tkachov
wrote:
> Hi all,
>
> This patch is a consequence of the thread I started at
> https://gcc.gnu.org/ml/gcc/2016-01/msg00100.html
> The problem is that the fold_rtx call in cse_insn may overwrite its argument
> if the insn argument is non-NULL.
> This
On Fri, Jan 22, 2016 at 12:06 PM, Eric Botcazou wrote:
>> I am fine with it being relaxed and permitting inlining !non_call_exceptions
>> to non_call_exceptions functions.. It would be also cool to have a
>> testcases.
>
> Thanks, patch installed with check_match changed to check_maybe_up, I'll w
On Fri, Jan 22, 2016 at 12:41 PM, Christian Bruel
wrote:
>
>
> On 01/19/2016 04:18 PM, Richard Biener wrote:
>>
>> maybe just if (currently_expanding_to_rtl)?
>>
>> But yes, this looks like a safe variant of the fix.
>>
>> Richard.
>>
> thanks, currently_expanding_to_rtl works perfectly. So the fi
Thank u for the feedback. I hope this new patch solves the outstanding issues.
Please find it attached.
//Claudiu
0001-ARC-Add-basic-support-for-double-load-and-store-inst.patch
Description: 0001-ARC-Add-basic-support-for-double-load-and-store-inst.patch
> > I only updated
> > - /* Don't inline if the callee can throw non-call exceptions but the
> > - caller cannot.
> > - FIXME: this is obviously wrong for LTO where STRUCT_FUNCTION is
> > missing. - Move the flag into cgraph node or mirror it in the inline
> > summary. */ - else if (
On Thu, 2016-01-21 at 18:10 +0100, Richard Biener wrote:
> On Thu, Jan 21, 2016 at 5:57 PM, Michael Matz wrote:
> > Hi,
> >
> > this has bothered me for some time. The gcc configure with stage1
> > feels
> > like taking forever because some of the decl availability tests
> > (checking
> > for C
> Hmm, I see now. I wonder if we can also inline
> can_thorw_non_call_exceptions to !can_throw_non_call_exceptions provied
> that we set the flag in ipa-inline-transform. That way we can inline Ada to
> C and the observation about no EH regions should still hold.
I'd say you're the only one cari
> > Hmm, I see now. I wonder if we can also inline
> > can_thorw_non_call_exceptions to !can_throw_non_call_exceptions
> > provied
> > that we set the flag in ipa-inline-transform. That way we can inline Ada to
> > C and the observation about no EH regions should still hold.
>
> I'd say you're t
On Fri, Jan 22, 2016 at 1:00 PM, Jan Hubicka wrote:
>> > I only updated
>> > - /* Don't inline if the callee can throw non-call exceptions but the
>> > - caller cannot.
>> > - FIXME: this is obviously wrong for LTO where STRUCT_FUNCTION is
>> > missing. - Move the flag into cgraph nod
> Why do you say so? There are C->Ada calls as there are Ada->C calls in
> plenty of existing software.
But what percentage of the C->Ada ones are performance critical? Note that,
unlike the Ada->C or Ada/C++ ones, these have never been inlined and I can
imagine the kind of trouble this would i
On 01/22/2016 09:36 AM, Jakub Jelinek wrote:
I think it is a bad idea to go against what the user wrote. Warning that
some code might not be efficient? Perhaps (if properly guarded with some
warning option one can turn off, either on a per-source file or using
pragmas even more fine grained).
On Fri, Jan 22, 2016 at 02:18:38PM +0100, Bernd Schmidt wrote:
> On 01/22/2016 09:36 AM, Jakub Jelinek wrote:
> >
> >I think it is a bad idea to go against what the user wrote. Warning that
> >some code might not be efficient? Perhaps (if properly guarded with some
> >warning option one can turn
On 01/22/2016 02:25 PM, Jakub Jelinek wrote:
What about #pragma oacc parallel? That would never do that?
It shouldn't, no (IMO).
Bernd
On 01/22/2016 06:03 AM, Richard Biener wrote:
On Fri, Jan 22, 2016 at 12:06 AM, Andrew MacLeod wrote:
I was trying the ttype prototype for static type checking on fold-const.c to
see how long it would take me to convert such a large file, and it choked on
this snippet of code in fold_unary_loc,
Hi,
On Fri, 22 Jan 2016, Oleg Endo wrote:
> and have been put into system.h because there have
> been problems with malloc poisoning and C++ stdlib implementation other
> than libstdc++, which sometimes pull other headers which then cause
> trouble. The fix for this set of errors was to inc
On 12/16/2015 03:30 PM, Evandro Menezes wrote:
>
> On 10/30/2015 05:24 AM, Marcus Shawcroft wrote:
>
> On 20 October 2015 at 00:40, Evandro Menezes
>wrote:
>
> In the existing targets, it seems that it's always faster to zero
>up a DF
>
> register with "movi %d0,
Hi Christian,
On 22/01/16 14:07, Christian Bruel wrote:
Hi Kyrill,
On 01/21/2016 01:22 PM, Kyrill Tkachov wrote:
Hi Christian,
On 21/01/16 10:36, Christian Bruel wrote:
The current arm_set_current_function was both awkward and buggy. For instance
using partially set TARGET_OPTION set from p
Since r230292, these tests in gcc.dg/vect have been failing on ARM, AArch64,
and x86_64 with -march=haswell (among others - when prefer_avx128 is true):
vect-outer-1-big-array.c scan-tree-dump-times vect "grouped access in outer
loop" 2
vect-outer-1.c scan-tree-dump-times vect "grouped access in
Richard,
I fixed all remarks pointed by you in vectorizer part of patch. Could
you take a look on modified patch.
Uros,
Could you please review i386 part of patch related to support of
conditional branches with vector comparison.
Bootstrap and regression testing did not show any new failures.
I
On Fri, Jan 22, 2016 at 12:42 AM, Bill Schmidt
wrote:
> Hi,
>
> On Thu, 2016-01-21 at 21:21 -0600, Bill Schmidt wrote:
>> The testcase will need a slight adjustment, as currently it fails on
>> powerpc64 with -m32 testing. Working on a fix.
>>
>> Bill
>>
>
> This patch adjusts the gcc.target/powe
This breaks bootstrap on aarch64 by miscompiling the stage2 compiler.
../../../libgomp/priority_queue.h:422:11: internal compiler error: RTL flag
check: MEM_VOLATILE_P used with unexpected rtx code 'mem' in
set_mem_attributes_minus_bitpos, at emit-rtl.c:1833
if (list->tasks == node)
~~
On Fri, Jan 22, 2016 at 6:29 AM, Yuri Rumyantsev wrote:
> Richard,
>
> I fixed all remarks pointed by you in vectorizer part of patch. Could
> you take a look on modified patch.
>
> Uros,
>
> Could you please review i386 part of patch related to support of
> conditional branches with vector compar
On 01/22/2016 10:52 AM, Kyrill Tkachov wrote:
AFAICT the new sequence is better than the old one even for
-mtune=cortex-a9 since it contains two fewer instructions.
Just curious (I think this patch series is good but will leave it to the
arm folks) - are these instructions equally expensive?
Hi Bernd,
On 22/01/16 14:53, Bernd Schmidt wrote:
On 01/22/2016 10:52 AM, Kyrill Tkachov wrote:
AFAICT the new sequence is better than the old one even for
-mtune=cortex-a9 since it contains two fewer instructions.
Just curious (I think this patch series is good but will leave it to the arm
Hi,
As title. This testcase fails on arm-none-linux-gnueabihf, because we don't
have vectorization of doubles there.
Committed as obvious as revision 232731.
Thanks,
James
---
2016-01-22 James Greenhalgh
* gcc.dg/vect/bb-slp-pr68892.c: Require vect_double.
diff --git a/gcc/testsuit
Improve TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS target hook. It turns out there
is another case where the register allocator uses the union of register classes
without checking that the cost of the resulting register class is lower than
both (see https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01765.h
On Thu, 21 Jan 2016, Bill Schmidt wrote:
> +/* { dg-do compile { target { powerpc64*-linux-* } } } */
That's suboptimal; you should allow powerpc*-*-linux* targets so that the
test is also run for --enable-targets=all powerpc-linux builds when
testing a -m64 multilib.
--
Joseph S. Myers
jos..
OK, thanks, Joseph! I'll make that adjustment later today.
Bill
On Fri, 2016-01-22 at 15:51 +, Joseph Myers wrote:
> On Thu, 21 Jan 2016, Bill Schmidt wrote:
>
> > +/* { dg-do compile { target { powerpc64*-linux-* } } } */
>
> That's suboptimal; you should allow powerpc*-*-linux* targets s
On Fri, 2016-01-08 at 12:07 +0100, Torvald Riegel wrote:
> This patch fixes a thinko in the HTM fastpath implementation. In a
> nutshell, we also need to monitor the HTM fastpath control (ie,
> htm_fastpath) variable from within a HW transaction on the HTM fastpath,
> so that such a HW transaciton
On Thu, 21 Jan 2016, Patrick Palka wrote:
On Thu, 21 Jan 2016, Jason Merrill wrote:
On 01/19/2016 10:30 PM, Patrick Palka wrote:
* g++.dg/template/unify17.C: XFAIL.
Hmm, I'm not comfortable with deliberately regressing this testcase.
template
-void bar (void (T[5])); // { dg-error
On 22/01/16 08:44, Andreas Krebbel wrote:
On 01/22/2016 12:10 AM, Jeff Law wrote:
On 01/21/2016 03:05 AM, Andreas Krebbel wrote:
On 01/02/2016 08:16 PM, Marcin Kościelnicki wrote:
When an unconditional jump with side effects targets an immediately
following label, rtl_tidy_fallthru_edge is cal
Hi,
On Thu, 21 Jan 2016, Richard Biener wrote:
> I'm inclined to say #define INCLUDE_ALGORITHM is a better name,
I've done this. On a different (slower) machine than the one from the
initial mail:
without patch, -j31 bootstrap all,ada:
real35m2.655s
user395m28.135s
sys 12m10.814s
On 20/01/16 21:10, Christophe Lyon wrote:
On 19 January 2016 at 15:51, Alan Lawrence wrote:
On 19/01/16 11:15, Christophe Lyon wrote:
For neon_vdupn, I chose to implement neon_vdup_nv4hf and
neon_vdup_nv8hf instead of updating the VX iterator because I thought
it was not desirable to impact n
The bare CONST_INT inside the CCmode IF_THEN_ELSE is causing combine to make
incorrect simplifications. At this stage it feels safer to wrap the CONST_INT
inside of an UNSPEC than make more generic changes to combine.
But we should definitely investigate combine's CCmode issues for gcc7.
Ok?
On 22/01/16 17:07, Richard Henderson wrote:
> The bare CONST_INT inside the CCmode IF_THEN_ELSE is causing combine to
> make incorrect simplifications. At this stage it feels safer to wrap
> the CONST_INT inside of an UNSPEC than make more generic changes to
> combine.
>
> But we should definitel
On 21/01/16 17:23, Alan Lawrence wrote:
> On 18/01/16 17:10, Eric Botcazou wrote:
>>
>> Could you post the list of files that differ? How do they differ exactly?
>
> Hmmm. Well, I definitely had this failing to bootstrap once. I repeated that,
> to
> try to identify exactly what the differences
On Thu, Jan 21, 2016 at 01:49:14PM -0500, Jason Merrill wrote:
> On 01/21/2016 01:25 PM, Marek Polacek wrote:
> >The problem in this PR is that we have a PTRMEM_CST wrapped in NOP_EXPR
> >and fold_convert can't digest that.
>
> Why didn't we fold away the NOP_EXPR before calling fold_convert? I g
On 01/22/2016 02:37 PM, Andrew MacLeod wrote:
/* If the initializer is non-void, then it's a normal expression
that will be assigned to the slot. */
(*) if (!VOID_TYPE_P (t))
(*) return RECURSE (t);
I suspect this should also be
if (!VOID_TYPE_P(TREE_TYPE
On 01/22/2016 10:34 AM, Wilco Dijkstra wrote:
Improve TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS target hook. It turns out there
is another case where the register allocator uses the union of register classes
without checking that the cost of the resulting register class is lower than
both (see https
I discovered these tests were relying on implicitly using vector partitioning,
rather than specifying it explicitly.
Fixed thusly.
nathan
Index: gcc/testsuite/c-c++-common/goacc/reduction-1.c
===
--- gcc/testsuite/c-c++-common/goac
These two libgomp tests were likewise presuming vector partitioning, without
specifying it.
nathan
2016-01-22 Nathan Sidwell
* testsuite/libgomp.oacc-c-c++-common/routine-1.c: Specify vector.
* testsuite/libgomp.oacc-c-c++-common/routine-2.c: Likewise.
Index: libgomp/testsuite/libgomp.o
> > Why do you say so? There are C->Ada calls as there are Ada->C calls in
> > plenty of existing software.
>
> But what percentage of the C->Ada ones are performance critical? Note that,
> unlike the Ada->C or Ada/C++ ones, these have never been inlined and I can
I think we was inlining them
> Ok, rebased onto a more recent build, and bootstrapping with Ada posed no
> problems. Sorry for the noise.
Great, no problem, and thanks for double checking.
--
Eric Botcazou
Hi,
The attached patch fixes a defect reported with gcc 5.2
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69414).
It is also the case, the issue is present in the gomp4
branch. The patch also adds additional testing.
Committed to gomp4 after bootstrap and regtesting.
Thanks,
Jim
Index: ChangeL
Without the fix for PR 65656, g++ miscompiles __builtin_constant_p in
wi::lrshift in wide-int.h. Add a check with PR 65656 testcase to verify
that C++ __builtin_constant_p works properly.
Tested on x86-64 with working GCC:
gcc/auto-host.h:/* #undef HAVE_WORKING_CXX_BUILTIN_CONSTANT_P */
prev-gcc
Updated patch.
I've verified that I'm changing the only relevant place in
tree-ssa-loop-ivopts.c that creates a POINTER_PLUS_EXPR, so I do think
that this is the only changed to fix the problem for ivopts.
OK for mainline?
Ian
gcc/ChangeLog:
2016-01-22 Ian Lance Taylor
* common.opt (fkeep-
On 01/22/2016 08:03 PM, Ian Lance Taylor wrote:
Updated patch.
I've verified that I'm changing the only relevant place in
tree-ssa-loop-ivopts.c that creates a POINTER_PLUS_EXPR, so I do think
that this is the only changed to fix the problem for ivopts.
I don't think so. One of the problems wi
This fixes my name in gcc/ChangeLog.
Index: ChangeLog
===
--- ChangeLog (revision 232742)
+++ ChangeLog (working copy)
@@ -144,7 +144,7 @@
* lra-coalesce.c (lra_coalesce): Invalidate value for the result
pseudo ins
On Thu, Jan 21, 2016 at 8:57 AM, Michael Matz wrote:
> Hi,
>
> this has bothered me for some time. The gcc configure with stage1 feels
> like taking forever because some of the decl availability tests (checking
> for C function) include system.h, and that, since a while, unconditionally
> include
So as noted in BZ69347 we have regressed a bit in the amount of time
spent in DOM for included testcase. My previous patch helped a little,
but there's still some low hanging fruit.
One of the things that was added during this cycle was the ability to do
a bit of secondary equivalence discove
On Fri, Jan 22, 2016 at 12:09:43PM -0800, H.J. Lu wrote:
> > * system.h (string, algorithm): Include only conditionally.
> > (new): Include always under C++.
> > * bb-reorder.c (toplevel): Define USES_ALGORITHM.
> > * final.c (toplevel): Ditto.
> > * ipa-chkp
We're already handling capture of 'this' specially, but we need to do
that in the case of init-capture as well.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 3d101d4f78d0940b54838695df35874d18f827d0
Author: Jason Merrill
Date: Thu Jan 21 16:45:42 2016 -0500
PR c++/69392
* l
On 01/22/2016 12:20 PM, Marek Polacek wrote:
On Thu, Jan 21, 2016 at 01:49:14PM -0500, Jason Merrill wrote:
On 01/21/2016 01:25 PM, Marek Polacek wrote:
The problem in this PR is that we have a PTRMEM_CST wrapped in NOP_EXPR
and fold_convert can't digest that.
Why didn't we fold away the NOP_
On 01/20/2016 06:04 PM, Martin Sebor wrote:
Right. The problem is this code in is_late_template_attribute:
/* If the first attribute argument is an identifier, only consider
second and following arguments. Attributes like mode, format,
cleanup and several target specif
On 01/22/2016 11:17 AM, Patrick Palka wrote:
On Thu, 21 Jan 2016, Patrick Palka wrote:
On Thu, 21 Jan 2016, Jason Merrill wrote:
On 01/19/2016 10:30 PM, Patrick Palka wrote:
* g++.dg/template/unify17.C: XFAIL.
Hmm, I'm not comfortable with deliberately regressing this testcase.
tem
The example in the PR is a sneaky little problem. When is
included the following overload is declared:
template
_Expr
operator<<(const _Tp& __t, const valarray<_Tp>& __v);
This is a candidate function for any "a << b" expression with
namespace std as an associated namespace. In order to do over
These two tests presumed a particular ordering of atomicc operation execution,
which is kind of anethema to why you'd want atomic ops and parallelizing loops.
I've removed the more obviously incorrect assumptions, but I have a suspicion
the fortran one at least still contains undefined behavio
On Fri, Jan 22, 2016 at 03:38:26PM -0500, Jason Merrill wrote:
> If we have a NOP_EXPR to the same type, we should strip it here.
This helps for the unreduced testcases in the PR, but not for the reduced one,
because for the reduced one, the types are not the same. One type is
struct
{
void Di
Hi!
I've noticed we create a VEC_COND_EXPR tree just to grab the arguments from
it to construct a ternary gimple assign.
The following patch fixes that by creating the ternary gimple assign
directly. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
2016-01-22 Jakub Jelinek
I've committed this patch to gomp4 branch. It changes the auto partitioning
logic to allocate the outermost loop to the outermost available partitioning.
For instance, gang partitioning will be used for the outermost loop of a
parallel region. Innermost loops remain partitioned at the innerm
Hi!
With this option we generate a conditional library call. When expanding
such a call, do_pending_stack_adjust () is performed from expand_call
and if there are any needed sp adjustments, they are emitted. The
problem is that this happens only in conditionally executed code, so on some
path th
On Fri, Jan 22, 2016 at 09:23:48PM +0100, Jakub Jelinek wrote:
> On Fri, Jan 22, 2016 at 12:09:43PM -0800, H.J. Lu wrote:
> > > * system.h (string, algorithm): Include only conditionally.
> > > (new): Include always under C++.
> > > * bb-reorder.c (toplevel): Define USES_ALG
On Fri, 22 Jan 2016, Jason Merrill wrote:
On 01/22/2016 11:17 AM, Patrick Palka wrote:
On Thu, 21 Jan 2016, Patrick Palka wrote:
On Thu, 21 Jan 2016, Jason Merrill wrote:
On 01/19/2016 10:30 PM, Patrick Palka wrote:
* g++.dg/template/unify17.C: XFAIL.
Hmm, I'm not comfortable with de
> Hi!
>
> With this option we generate a conditional library call. When expanding
> such a call, do_pending_stack_adjust () is performed from expand_call
> and if there are any needed sp adjustments, they are emitted. The
> problem is that this happens only in conditionally executed code, so on
On 01/22/2016 05:39 AM, Jonathan Wakely wrote:
On 21/01/16 19:07 -0500, Ed Smith-Rowland wrote:
On 01/21/2016 07:29 AM, Jonathan Wakely wrote:
On 20/01/16 20:30 -0500, Ed Smith-Rowland wrote:
Now that libstdc++ installs a proper math.h we can piggyback on
that to put in the last bit of TR29124
On Fri, Jan 22, 2016 at 11:25 AM, Bernd Schmidt wrote:
> On 01/22/2016 08:03 PM, Ian Lance Taylor wrote:
>>
>> Updated patch.
>>
>> I've verified that I'm changing the only relevant place in
>> tree-ssa-loop-ivopts.c that creates a POINTER_PLUS_EXPR, so I do think
>> that this is the only changed
On January 22, 2016 11:15:38 PM GMT+01:00, Jakub Jelinek
wrote:
>On Fri, Jan 22, 2016 at 09:23:48PM +0100, Jakub Jelinek wrote:
>> On Fri, Jan 22, 2016 at 12:09:43PM -0800, H.J. Lu wrote:
>> > > * system.h (string, algorithm): Include only
>conditionally.
>> > > (new): Include alw
On January 22, 2016 11:09:06 PM GMT+01:00, Jakub Jelinek
wrote:
>Hi!
>
>I've noticed we create a VEC_COND_EXPR tree just to grab the arguments
>from
>it to construct a ternary gimple assign.
>
>The following patch fixes that by creating the ternary gimple assign
>directly. Bootstrapped/regtested
95 matches
Mail list logo
