The following fixes a miscompilation of the linux kernel which does
patching of instructions by accessing memory relative to function
addresses (that's undefined in C and won't work for targets using
function descriptors but hey - those guys say they know what they
are doing).
Thus the following
This crash happens because LRA tries to save an AVX hard reg in a large
mode, and it only appears in the function in smaller modes. Stack
alignment isn't set up to support the larger mode.
Currently, biggest_mode for hard registers is set up from regno_reg_rtx,
set up to a large mode for argum
Hi,
this patch fixes re-opened PR68915 on sparc.
It xfails a scan line that's not applicable for sparc.
Committed to trunk.
Thanks,
- Tom
Xfail pr46032.c scan if alignment requirements not met
2016-03-10 Tom de Vries
PR testsuite/68915
* gcc.dg/vect/pr46032.c: Xfail scan if alignment re
This is a case where bogus #line directives can confuse libcpp into
producing nonsensical line numbers, even leading to a crash later on in LTO.
The following patch moves the test earlier to a point where we can more
easily recover from the error condition. I should note that I changed
the raw
Here is a small patch to allow the special maths functions that came in
with TR29124 into C++17 in Jacksonville.
I am leaving the TR29124 access with __STDCPP_WANT_MATH_SPEC_FUNCS__ for
C++ < 17.
I added the SD-6 feature macro:
#define __cpp_lib_math_special_functions 20163L
Passes testing on
On Thu, Mar 10, 2016 at 03:44:26AM -0500, Ed Smith-Rowland wrote:
> Here is a small patch to allow the special maths functions that came in with
> TR29124 into C++17 in Jacksonville.
> I am leaving the TR29124 access with __STDCPP_WANT_MATH_SPEC_FUNCS__ for C++
> < 17.
>
> I added the SD-6 feature
On 03/10/2016 03:48 AM, Jakub Jelinek wrote:
On Thu, Mar 10, 2016 at 03:44:26AM -0500, Ed Smith-Rowland wrote:
Here is a small patch to allow the special maths functions that came in with
TR29124 into C++17 in Jacksonville.
I am leaving the TR29124 access with __STDCPP_WANT_MATH_SPEC_FUNCS__ for
On Thu, 10 Mar 2016, Tom de Vries wrote:
> Hi,
>
> I wrote attached patch to print the actual contents of the varmap variable in
> tree-ssa-structalias.c.
>
> Does it make sense to rewrite this into a dump_varmap/debug_varmap patch?
Yes (but please not dump it by default) and I'd rather have a
On 09/03/16 16:57, Andre Vieira (lists) wrote:
On 08/03/16 14:56, Kyrill Tkachov wrote:
Hi Andre,
On 08/03/16 11:05, Andre Vieira (lists) wrote:
On 03/03/16 11:28, Kyrill Tkachov wrote:
Hi Andre,
On 02/03/16 12:21, Andre Vieira (lists) wrote:
Hi,
Tests used to check for "r8" which will no
Doing the indirect jump optimization turned out to be quite easy.
Bootstrapped and regression tested powerpc64le-linux, gcc-6, gcc-5 and
gcc-4.9. Bootstrap and regression test x86_64-linux still running.
OK to apply?
gcc/
PR rtl-optimization/69195
PR rtl-optimization/47992
On 03/10/2016 10:18 AM, Alan Modra wrote:
Doing the indirect jump optimization turned out to be quite easy.
Bootstrapped and regression tested powerpc64le-linux, gcc-6, gcc-5 and
gcc-4.9. Bootstrap and regression test x86_64-linux still running.
OK to apply?
So much nicer. Ok, and thanks.
B
On 09/03/16 17:03, Mike Stump wrote:
> On Mar 9, 2016, at 8:57 AM, Andre Vieira (lists)
> wrote:
>>> I'm seeing a DejaGNU error while testing
>>> RUNTESTFLAGS="arm.exp=pr45701-*.c":
>>> ERROR: (DejaGnu) proc "^-" does not exist.
>
>> 2016-03-09 Andre Vieira
>>
>> * gcc.target/arm/pr45701-1.c: E
Hi,
Curently when vectorizing masked load/store we don't check
mask and value have the same number of elements. Usually
conversion patterns apply and we don't have such case but
conversion patterns may fail to properly determine mask
type and we shouldn't rely on it so hard.
Unfortunately I cou
Ed Smith-Rowland wrote:
> --- include/bits/specfun.h
> (svn+ssh://e...@gcc.gnu.org/svn/gcc/trunk/libstdc++-v3/include) (working copy)
> +++ svn+ssh://e...@gcc.gnu.org/svn/gcc/trunk/libstdc++-v3/include
> (revision 234098)
> @@ -1,6 +1,6 @@
> // Mathematical Special Functions for -*- C++
On Thu, Mar 10, 2016 at 11:12 AM, Ilya Enkovich wrote:
> Hi,
>
> Curently when vectorizing masked load/store we don't check
> mask and value have the same number of elements. Usually
> conversion patterns apply and we don't have such case but
> conversion patterns may fail to properly determine m
On Wed, Mar 9, 2016 at 6:54 PM, Alan Lawrence
wrote:
> On 07/03/16 11:02, Alan Lawrence wrote:
>>
>> On 04/03/16 13:27, Richard Biener wrote:
>>>
>>> I think to make it work with LTO you need to mark it 'Optimization'.
>>> Also it's about
>>> arrays so maybe
>>>
>>> 'Assume common declarations may
On Tue, Mar 08, 2016 at 03:20:52PM +0100, Christophe Lyon wrote:
> Hi,
>
> Our bug report https://bugs.linaro.org/show_bug.cgi?id=2123
> complains about aarch64's missing plugin dependency.
>
> IFAIT, the problem is present on trunk too, and the small attached
> patch fixes it.
> OK?
This is OK.
On Tue, Jan 26, 2016 at 03:43:36PM +0100, Christophe Lyon wrote:
> With the attachment
>
>
> On 26 January 2016 at 15:42, Christophe Lyon
> wrote:
> > Hi,
> >
> > This is a followup to PR63304.
> >
> > As discussed in bugzilla, this patch disables pcrelative_literal_loads
> > when -mfix-cor
Ping.
https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00237.html
Thanks,
Kyrill
On 03/03/16 11:38, Kyrill Tkachov wrote:
Hi all,
This patch fixes the ICE that was introduced by my earlier patch to
aarch64_set_current_function:
FAIL: gcc.dg/torture/pr52429.c -O2 -flto -fno-use-linker-plugin
-flt
On 10 March 2016 at 12:43, James Greenhalgh wrote:
> On Tue, Jan 26, 2016 at 03:43:36PM +0100, Christophe Lyon wrote:
>> With the attachment
>>
>>
>> On 26 January 2016 at 15:42, Christophe Lyon
>> wrote:
>> > Hi,
>> >
>> > This is a followup to PR63304.
>> >
>> > As discussed in bugzilla, t
Here, we got ourselves into infinite recursion in fold, resulting in a stack
overflow. I believe the crux is that we're passing UNARY_PLUS_EXPR, a C++-only
code, into fold which can't really fold e.g. 1 + UNARY_PLUS_EXPR <1>. I think
cp_fold should be able to fold this to 2, but currently is not.
On Wed, 9 Mar 2016, Nathan Sidwell wrote:
> > Furthermore, this is not useful without support in libgomp/plugin-nvptx.c
> > and nvptx-none-run.c (PTX JIT does not propagate lineinfo by default).
> > Would you like me to submit patches for those?
>
> please.
Here's the pull request for nvptx-run.c
On Thu, Mar 10, 2016 at 01:46:45PM +0100, Marek Polacek wrote:
> 2016-03-10 Marek Polacek
>
> PR c++/70153
> * cp-gimplify.c (cp_fold): Handle UNARY_PLUS_EXPR.
>
> * g++.dg/delayedfold/unary-plus1.C: New test.
>
> diff --git gcc/cp/cp-gimplify.c gcc/cp/cp-gimplify.c
> index
On 03/09/16 11:41, Alexander Monakov wrote:
:|x86_64-pc-linux-gnu-accel-nvptx-none-gcc -xc - -S -o- -gstabs
:1:0: sorry, unimplemented: stabs debug format not supported
cc1: error: target system does not support the ‘stabs’ debug format
:|x86_64-pc-linux-gnu-accel-nvptx-none-gcc -xc - -S -o- -
On Thu, Mar 10, 2016 at 01:56:41PM +0100, Jakub Jelinek wrote:
> On Thu, Mar 10, 2016 at 01:46:45PM +0100, Marek Polacek wrote:
> > 2016-03-10 Marek Polacek
> >
> > PR c++/70153
> > * cp-gimplify.c (cp_fold): Handle UNARY_PLUS_EXPR.
> >
> > * g++.dg/delayedfold/unary-plus1.C: New t
On 03/10/16 07:52, Alexander Monakov wrote:
On Wed, 9 Mar 2016, Nathan Sidwell wrote:
Furthermore, this is not useful without support in libgomp/plugin-nvptx.c
and nvptx-none-run.c (PTX JIT does not propagate lineinfo by default).
Would you like me to submit patches for those?
please.
Here's
On Thu, 10 Mar 2016, Nathan Sidwell wrote:
> Hm, something must have changed since I found that sorry neccessary.
As I already said in my opening sentence (not quoted in your response), you
removed the unnecessary override. This is exactly what lets toplevel code see
requested debug format now,
On Wed, Mar 09, 2016 at 03:35:43PM -0600, Evandro Menezes wrote:
> On 03/01/16 13:08, Evandro Menezes wrote:
> >On 03/01/16 13:02, Wilco Dijkstra wrote:
> >>Evandro Menezes wrote:
> >>>The meaning of these attributes are not clear to me. Is there a
> >>>reference somewhere about which insns are FP
On Thu, Mar 10, 2016 at 01:37:50PM +0100, Christophe Lyon wrote:
> On 10 March 2016 at 12:43, James Greenhalgh wrote:
> > On Tue, Jan 26, 2016 at 03:43:36PM +0100, Christophe Lyon wrote:
> >> With the attachment
> >>
> >>
> >> On 26 January 2016 at 15:42, Christophe Lyon
> >> wrote:
> >> > H
On 02/03/16 12:21, Andre Vieira (lists) wrote:
> Hi,
>
> Tests used to check for "r8" which will not work because cortex-r8
> string is now included in the assembly. Fixed by checking for "[^\-]r8".
>
> Is this Ok?
>
> Cheers,
> Andre
>
> gcc/testsuite/ChangeLog:
>
> 2016-03-02 Andre Vieira
On 02/03/16 12:20, Andre Vieira (lists) wrote:
>
> gcc/ChangeLog:
>
> 2016-03-02 Andre Vieira
>
> * config/arm/arm-cores.def (cortex-r8): New.
> * config/arm/arm-tables.opt (cortex-r8): New.
> * config/arm/arm-tune.md: Regenerate.
> * gcc/doc/invoke.texi: Add cortex-r8 to
On 09/03/16 16:57, Andre Vieira (lists) wrote:
> On 08/03/16 14:56, Kyrill Tkachov wrote:
>> Hi Andre,
>>
>> On 08/03/16 11:05, Andre Vieira (lists) wrote:
>>> On 03/03/16 11:28, Kyrill Tkachov wrote:
Hi Andre,
On 02/03/16 12:21, Andre Vieira (lists) wrote:
> Hi,
>
> Test
Hi,
This patch fixes ~230 internal compiler errors that showed up after
the fix for PR 69764. After the patch, target backends need to
explicitly specify mode for operand 2 of shift and rotate patterns -
see md.texi mod at
https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/doc/md.texi?r1=23
On 09/03/16 16:55, Andre Vieira (lists) wrote:
> Hi there,
>
> This patch adds cortex-r8 to the list of cores using the armv7 multilib.
>
> This patch is based on Thomas' multilib patch series:
> https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01584.html
> https://gcc.gnu.org/ml/gcc-patches/2015-12
On 07.03.2016 12:59, Richard Henderson wrote:
On 03/06/2016 07:24 PM, Matthias Klose wrote:
On 05.03.2016 19:28, Richard Henderson wrote:
When I went to apply my symbol versioning patch to upstream,
I discovered that upstream had already bumped their soname to
6.4.0, beyond the bump that I'd ap
On Thu, Mar 10, 2016 at 3:03 PM, Matthias Klose wrote:
> On 07.03.2016 12:59, Richard Henderson wrote:
>>
>> On 03/06/2016 07:24 PM, Matthias Klose wrote:
>>>
>>> On 05.03.2016 19:28, Richard Henderson wrote:
When I went to apply my symbol versioning patch to upstream,
I discovered
On 03/10/2016 08:07 AM, Marek Polacek wrote:
On Thu, Mar 10, 2016 at 01:56:41PM +0100, Jakub Jelinek wrote:
On Thu, Mar 10, 2016 at 01:46:45PM +0100, Marek Polacek wrote:
2016-03-10 Marek Polacek
PR c++/70153
* cp-gimplify.c (cp_fold): Handle UNARY_PLUS_EXPR.
* g++.
On Thu, Mar 03, 2016 at 11:38:11AM +, Kyrill Tkachov wrote:
> Hi all,
>
> This patch fixes the ICE that was introduced by my earlier patch to
> aarch64_set_current_function:
> FAIL: gcc.dg/torture/pr52429.c -O2 -flto -fno-use-linker-plugin
> -flto-partition=none (internal compiler error)
>
On Thu, Mar 10, 2016 at 09:34:17AM -0500, Jason Merrill wrote:
> On 03/10/2016 08:07 AM, Marek Polacek wrote:
> >On Thu, Mar 10, 2016 at 01:56:41PM +0100, Jakub Jelinek wrote:
> >>On Thu, Mar 10, 2016 at 01:46:45PM +0100, Marek Polacek wrote:
> >>>2016-03-10 Marek Polacek
> >>>
> >>> PR c++/70
On 03/10/2016 09:53 AM, Marek Polacek wrote:
+case UNARY_PLUS_EXPR:
+ op0 = cp_fold_maybe_rvalue (TREE_OPERAND (x, 0), rval_ops);
You can just use cp_fold_rvalue here. OK with that change.
Jason
On Thu, Mar 10, 2016 at 09:59:07AM -0500, Jason Merrill wrote:
> On 03/10/2016 09:53 AM, Marek Polacek wrote:
> >+case UNARY_PLUS_EXPR:
> >+ op0 = cp_fold_maybe_rvalue (TREE_OPERAND (x, 0), rval_ops);
>
> You can just use cp_fold_rvalue here. OK with that change.
Thanks. Final patch I'
On Mon, Mar 07, 2016 at 01:12:16PM +, Nick Clifton wrote:
> Hi Kyrill,
>
> > This is missing a second hunk from the patch you attached in the PR that I
> > think is necessary
> > for this to work (setting to x_flag_omit_frame_pointer)...
>
> Doh! Silly me - there was a snafu restoring the p
On 03/10/2016 05:24 AM, Tobias Burnus wrote:
Ed Smith-Rowland wrote:
--- include/bits/specfun.h
(svn+ssh://e...@gcc.gnu.org/svn/gcc/trunk/libstdc++-v3/include) (working copy)
+++ svn+ssh://e...@gcc.gnu.org/svn/gcc/trunk/libstdc++-v3/include
(revision 234098)
@@ -1,6 +1,6 @@
// Mat
Hi all,
When extending the aarch64_handle_option function for GCC 6 I introduced a
thinko
when handling the -momit-leaf-frame-pointer option and had it set the variable
for -fomit-frame-pointer instead. This hasn't been particularly impactful
because
-momit-leaf-frame-pointer is on by default a
On 10/03/16 15:23, James Greenhalgh wrote:
On Mon, Mar 07, 2016 at 01:12:16PM +, Nick Clifton wrote:
Hi Kyrill,
This is missing a second hunk from the patch you attached in the PR that I
think is necessary
for this to work (setting to x_flag_omit_frame_pointer)...
Doh! Silly me - there
Hi,
my first fix was just partial and fixed ICE in one branch not in other.
The issue is that code does not expect cxa_pure_virtual in target list and ICEs
handling
it as a method while checking whether it should suggest final.
Bootstrapped/regtested x86_64-linux, comitted.
ipa/69630
Hi,
this patch fixes ICE in ipa-cp that detects local function that is dead.
The issue is that virutal functions may have no address taken but still may
be virtual call targets. This patch makes remove_unreachable_nodes to handle
this and not mark them local (since they are not)
Honza
*
Alan,
The test gfortran.dg/unconstrained_commons.f fails in the 32 bit mode. It needs
some regexp capturing
mycommon.x[j_1] = _5;
as in " mycommon\.x\[.?_[0-9]+\] = _[0-9]+;"
TIA
Dominique
On Thu, Mar 10, 2016 at 05:12:59PM +0100, Jan Hubicka wrote:
> --- testsuite/g++.dg/lto/pr69589_0.C (revision 0)
> +++ testsuite/g++.dg/lto/pr69589_0.C (working copy)
> @@ -0,0 +1,26 @@
> +// { dg-lto-do link }
> +// { dg-lto-options "-O2 -rdynamic" }
Shouldn't this have
// { dg-require-visibil
On Thu, Mar 10, 2016 at 03:42:38PM +, Kyrill Tkachov wrote:
> Hi all,
>
> When extending the aarch64_handle_option function for GCC 6 I introduced a
> thinko
> when handling the -momit-leaf-frame-pointer option and had it set the variable
> for -fomit-frame-pointer instead. This hasn't been p
On 03/10/16 07:23, James Greenhalgh wrote:
On Wed, Mar 09, 2016 at 03:35:43PM -0600, Evandro Menezes wrote:
On 03/01/16 13:08, Evandro Menezes wrote:
On 03/01/16 13:02, Wilco Dijkstra wrote:
Evandro Menezes wrote:
The meaning of these attributes are not clear to me. Is there a
reference some
On 03/10/16 10:27, Evandro Menezes wrote:
On 03/10/16 07:23, James Greenhalgh wrote:
On Wed, Mar 09, 2016 at 03:35:43PM -0600, Evandro Menezes wrote:
On 03/01/16 13:08, Evandro Menezes wrote:
On 03/01/16 13:02, Wilco Dijkstra wrote:
Evandro Menezes wrote:
The meaning of these attributes are
> On Thu, Mar 10, 2016 at 05:12:59PM +0100, Jan Hubicka wrote:
> > --- testsuite/g++.dg/lto/pr69589_0.C(revision 0)
> > +++ testsuite/g++.dg/lto/pr69589_0.C(working copy)
> > @@ -0,0 +1,26 @@
> > +// { dg-lto-do link }
> > +// { dg-lto-options "-O2 -rdynamic" }
>
> Shouldn't this
On Thu, Mar 10, 2016 at 10:32:15AM -0600, Evandro Menezes wrote:
> >I agree to postpone until GCC 7.
> >
> >[AArch64] Replace insn to zero up SIMD registers
> >
> >gcc/
> >* config/aarch64/aarch64.md
> >(*movhf_aarch64): Add "movi %0, #0" to zero up register.
Hi,
On Tue, Mar 01, 2016 at 09:04:25AM +1100, kugan wrote:
> Hi,
>
> As discussed in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69708 and
> corresponding mailing list discussion, IPA CP is not detecting a
> jump-function with the sq function as value.
>
>
sorry it took so long for me to loo
Hi Evandro,
> I have however encountered precision issues with DF, namely some benchmarks
> in the SPECfp CPU2000 suite would fail to validate.
Accuracy is not an issue, the computation is extremely accurate. The issue is
that your patch doesn't support sqrt(0.0) - it returns NaN rather than z
On 03/10/16 10:52, Wilco Dijkstra wrote:
Hi Evandro,
I have however encountered precision issues with DF, namely some benchmarks in
the SPECfp CPU2000 suite would fail to validate.
Accuracy is not an issue, the computation is extremely accurate. The issue is
that your patch doesn't support s
Hi!
As mentioned in the PR, the compile time and compile memory are wasted
if a large array is is using value or default initialization, and
if the resulting initializer value is simple enough, we can just share
it by all the elements.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for
On Wed, Mar 09, 2016 at 06:18:31PM +0100, Jakub Jelinek wrote:
> So, what approach do you prefer? I've so far bootstrapped/regtested the
> second patch, which showed those
> +FAIL: g++.dg/cilk-plus/AN/builtin_fn_custom_tplt.cc
> +UNRESOLVED: g++.dg/cilk-plus/AN/builtin_fn_custom_tplt.cc
> +FAIL: g
OK.
Jason
Hi James,
>> OK to apply ?
>
> OK, thanks.
Thanks - applied.
>>> Note that this patch would expose a bug in
>>> common/config/aarch64/aarch64-common.c
>>> where there's a thinko in the handling of OPT_momit_leaf_frame_pointer.
>>> That's my bad and I'll propose a patch for it soon.
>
> I don'
On Thu, Mar 10, 2016 at 12:03 PM, Jakub Jelinek wrote:
> Hi!
>
> As mentioned in the PR, the compile time and compile memory are wasted
> if a large array is is using value or default initialization, and
> if the resulting initializer value is simple enough, we can just share
> it by all the eleme
On Thu, Mar 10, 2016 at 12:34:40PM -0500, Patrick Palka wrote:
> Doesn't this mean that we call initializer_constant_valid_p at each
> iteration? This would slow down the non-constant case even further.
> So I wonder if the return value of initializer_constant_valid_p could
> be cached or somethin
On 03/10/2016 03:26 AM, Bernd Schmidt wrote:
This crash happens because LRA tries to save an AVX hard reg in a
large mode, and it only appears in the function in smaller modes.
Stack alignment isn't set up to support the larger mode.
Currently, biggest_mode for hard registers is set up from
r
On Thu, Mar 10, 2016 at 06:37:32PM +0100, Jakub Jelinek wrote:
> On Thu, Mar 10, 2016 at 12:34:40PM -0500, Patrick Palka wrote:
> > Doesn't this mean that we call initializer_constant_valid_p at each
> > iteration? This would slow down the non-constant case even further.
> > So I wonder if the ret
When I submitted my previous lra-remat patch, I mentioned I had some
concerns about the way we dealt with register number comparisons, but I
didn't want to change things blindly without a testcase. PR70123 has now
provided such a testcase where we are trying to rematerialize a hard
register (r6
On Thu, Mar 10, 2016 at 12:56 PM, Jakub Jelinek wrote:
> On Thu, Mar 10, 2016 at 06:37:32PM +0100, Jakub Jelinek wrote:
>> On Thu, Mar 10, 2016 at 12:34:40PM -0500, Patrick Palka wrote:
>> > Doesn't this mean that we call initializer_constant_valid_p at each
>> > iteration? This would slow down t
OK.
Jason
On Thu, Mar 10, 2016 at 01:32:10PM -0500, Patrick Palka wrote:
> Looks fine to me :)
On a closer look, this doesn't handle the multi-dimensional array cases,
and even for single-dimensional ones will not share the CONSTRUCTOR
if init_subob_ctx created one, and call init_subob_ctx many times
and in
On 03/10/16 10:52, Wilco Dijkstra wrote:
> Hi Evandro,
>
>> I have however encountered precision issues with DF, namely some benchmarks
>> in the SPECfp CPU2000 suite would fail to validate.
> Accuracy is not an issue, the computation is extremely accurate. The issue is
> that your patch doesn't
On Thu, Mar 10, 2016 at 07:39:57PM +0100, Jakub Jelinek wrote:
> Is this also ok, if it passes bootstrap/regtest?
>
> 2016-03-10 Jakub Jelinek
>
> PR c++/70001
> * constexpr.c (cxx_eval_vec_init_1): Reuse CONSTRUCTOR initializers
> for 1..max even for multi-dimensional arrays
On 03/10/16 13:10, Wilco Dijkstra wrote:
frsqrte s1, s0
fmul s2, s1, s1
frsqrts s2, s0, s2
fcmp s0, 0.0
fmul s1, s1, s2
fmul s2, s1, s1
fmul s1, s0, s1
frsqrts s2, s0, s2
fcsels1, s0, s1, eq
fmul s0, s1, s2
That's
On 11/03/16 03:39, Martin Jambor wrote:
Hi,
On Tue, Mar 01, 2016 at 09:04:25AM +1100, kugan wrote:
Hi,
As discussed in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69708 and
corresponding mailing list discussion, IPA CP is not detecting a
jump-function with the sq function as value.
sor
This patch updates a libgomp test case which was expecting char to be
signed when that's not guaranteed to be the case. Jakub pre-approved
this patch in the PR.
I'll apply this patch to trunk and backport it to gomp-4_0-branch shortly.
Cesar
2016-03-10 Cesar Philippidis
libgomp/
PR testsuit
Within a lambda we should implicitly capture an outer const variable
only if it's odr-used in the body of the lambda. But we are currently
making the decision of whether to capture such a variable, or else to
fold it to a constant, too early -- before we can know whether it's
being odr-used or not
On Thu, Mar 10, 2016 at 5:58 PM, Patrick Palka wrote:
> Within a lambda we should implicitly capture an outer const variable
> only if it's odr-used in the body of the lambda. But we are currently
> making the decision of whether to capture such a variable, or else to
> fold it to a constant, too
Hello,
this patch fixes PR target/70168, a wrong code generation problem
caused by rs6000_expand_atomic_compare_and_swap not properly handling
the case where changing retval clobbers newval due to a register overlap.
Tested with no regressions on powerpc64le-linux on mainline
and gcc-5-branch.
O
On Thu, Mar 10, 2016 at 6:10 PM, Ulrich Weigand wrote:
> Hello,
>
> this patch fixes PR target/70168, a wrong code generation problem
> caused by rs6000_expand_atomic_compare_and_swap not properly handling
> the case where changing retval clobbers newval due to a register overlap.
>
> Tested with
I ran the command
git grep -l "dg-do compile" | xargs grep -l __builtin_abort | xargs grep -lw
main
to find tests marked as compile-time tests that likely ought to instead
be marked as run-time tests, by the rationale that they use
__builtin_abort and they also define main(). (I also then con
On Thu, Mar 10, 2016 at 6:38 PM, Patrick Palka wrote:
> I ran the command
>
> git grep -l "dg-do compile" | xargs grep -l __builtin_abort | xargs grep
> -lw main
>
> to find tests marked as compile-time tests that likely ought to instead
> be marked as run-time tests, by the rationale that they
So, we have been discussing this issue for 4 months now. Over that
time, I have tried to incorporate everyone's feedback.
As a result we have gone from a tiny doc patch (just describe the
current semantics), to a big doc patch (completely deprecate basic asm
when used in a function) to a medi
Evandro Menezes wrote:
>
> That's what I had in mind too, but around the approximation for x^-1/2
> and using masks for vector cases thusly:
>
>fcmne v3.4s, v0.4s, #0.0
> frsqrte v1.4s, v0.4s
> fmulv2.4s, v1.4s, v1.4s
> frsqrts v2.4s, v0.4s, v2.4s
> fm
As discussed in the BZ, we have multiple problems with how we sort the
coalesce list during out-of-ssa coalescing.
First, the sort is not stable. If the cost of two coalesce pairs is the
same, we break the tie by looking at the underlying SSA_NAME_VERSION of
the first, then the second eleme
Here's another force_paren_expr issue. Hopefully I described the issue
adequately in the inline comments that are part of the patch. The
relevant function that builds the temporary SCOPE_REF is
finish_non_static_data_member.
Does this patch look OK to commit after bootstrap + regtest?
gcc/cp/Ch
84 matches
Mail list logo
