On Monday, January 11, 2016 04:57:18 PM Bernd Schmidt wrote:
> On 01/08/2016 10:33 AM, Thomas Preud'homme wrote:
> > 2016-01-08 Thomas Preud'homme
> >
> > * g++.dg/pr67989.C: Remove ARM-specific option.
> > * gcc.target/arm/pr67989.C: New file.
>
> I checked some other arm te
Hi Nick,
Thanks for your detailed review.
Please find an updated version of this patch here. I have tried to modify
it as per your suggestions.
> I would suggest:
> static bool
Done.
> + if (recog_memoized (insn) == CODE_FOR_udivmodsi4_g13
> have an attribute on these insns, and then test f
When promote_function_mode and promote_ssa_mode changes the sign
differently, following is the cause for the problem in PR67714.
_8 = fn1D.5055 ();
f_13 = _8;
function returns -15 and in _8 it is sign extended. In the second
statement, we say that the value is SUBREG_PROMOTED and promote
Hi James,
> -Original Message-
> From: James Greenhalgh [mailto:james.greenha...@arm.com]
> Sent: Monday, January 11, 2016 5:24 PM
> To: gcc-patches@gcc.gnu.org
> Cc: n...@arm.com; marcus.shawcr...@arm.com;
> richard.earns...@arm.com; Kumar, Venkataramanan;
> philipp.toms...@theobroma-syst
OK.
Jason
On 12/22/2015 09:32 PM, Martin Sebor wrote:
+ if (is_attribute_p ("aligned", name)
+ || is_attribute_p ("vector_size", name))
+{
+ /* Attribute argument may be a dependent indentifier. */
+ if (tree t = args ? TREE_VALUE (args) : NULL_TREE)
+ if (value_dependent_express
On 01/11/2016 03:32 AM, Richard Biener wrote:
Yeah, reassoc is largely about canonicalization.
Plus doing it in TER is almost certainly more complex than getting it right
in reassoc to begin with.
I guess canonicalizing differently is ok but you'll still create
((a & b) & 1) & c then if you
The HP libm doesn't support the ERANGE error for exp2(). So, we need to skip
this test as on sun unix.
Tested on hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11.
Committed to trunk.
Dave
--
John David Anglin dave.ang...@bell.net
2016-01-11 John David Anglin
PR tree-optimizati
On 2015-12-18, at 9:05 PM, John David Anglin wrote:
> On 2015-12-09, at 8:00 PM, John David Anglin wrote:
>
>> The attached fixes an ICE building gridengine. The problem is we are asked
>> to do an HImode reload
>> for a floating pointing register. However, we can only do 32 and 64-bit
>> loa
Ping:
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg02074.html
On 01/04/2016 09:49 PM, Martin Sebor wrote:
Ping: looking for review/approval of the patch below:
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg02074.html
Thanks
Martin
On 12/22/2015 07:32 PM, Martin Sebor wrote:
The attach
On Mon, 11 Jan 2016, Michael Meissner wrote:
> I fixed the #ifdef to use __NO_FPRS__ (thanks for the heads up on that). I
> also believe I fixed the various formatting issues. These two patches build
> on
> a big endian power7 host and little endian power8 host with no regressions in
> the test
On Mon, 11 Jan 2016, H.J. Lu wrote:
> Here is the updated patch. Joseph, is this OK?
I have no objections to this patch.
--
Joseph S. Myers
jos...@codesourcery.com
On Mon, Jan 11, 2016 at 05:04:16PM -0500, Jason Merrill wrote:
> >You mean:
> >
> >--- gcc/cp/pt.c.jj 2016-01-05 16:46:02.891896607 +0100
> >+++ gcc/cp/pt.c 2016-01-11 21:33:09.065184178 +0100
> >@@ -12207,6 +12207,8 @@ tsubst_decl (tree t, tree args, tsubst_f
> > DECL_TEMPLATE_INSTA
From: Trevor Saunders
Hi,
this hardly counts as a bug fix, but going through open bugs I saw PR54809, and
realized we don't actually need this attribute any more, so we might as well
just remove it.
bootstrapped + regtested on x86_64-linux-gnu, ok for now or gcc 7? I don't
mind waiting, but it
On 01/11/2016 05:53 AM, James Greenhalgh wrote:
I'd like to switch the logic around in aarch64.c such that
-mlow-precision-recip-sqrt causes us to always emit the low-precision
software expansion for reciprocal square root. I have two reasons to do
this; first is consistency across -mcpu targets,
On 01/11/2016 03:47 AM, Dominik Vogt wrote:
On Mon, Jan 11, 2016 at 11:46:21AM +0100, Dominik Vogt wrote:
The following two patches fix some test cases for S/390.
Patch 1:
gcc.dg/tree-ssa/20040204-1.c does not fail on S/390 at the moment.
The series looks fine to me.
jeff
> I posted last version of patch where I took review comments into account
> month ago:
>
> https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01328.html
I'm OK with this version.
On 01/11/2016 04:52 PM, Jakub Jelinek wrote:
On Mon, Jan 11, 2016 at 04:44:46PM -0500, Jason Merrill wrote:
On 01/11/2016 03:01 PM, Nathan Sidwell wrote:
On 01/09/16 02:41, Jakub Jelinek wrote:
Hi!
I'd like to ping the PR c++/66808, PR c++/69000
http://gcc.gnu.org/ml/gcc-patches/2015-12/msg02
On Mon, Jan 11, 2016 at 04:44:46PM -0500, Jason Merrill wrote:
> On 01/11/2016 03:01 PM, Nathan Sidwell wrote:
> >On 01/09/16 02:41, Jakub Jelinek wrote:
> >>Hi!
> >>
> >>I'd like to ping the PR c++/66808, PR c++/69000
> >>http://gcc.gnu.org/ml/gcc-patches/2015-12/msg02019.html
> >>patch, fixing IC
On 01/11/2016 03:01 PM, Nathan Sidwell wrote:
On 01/09/16 02:41, Jakub Jelinek wrote:
Hi!
I'd like to ping the PR c++/66808, PR c++/69000
http://gcc.gnu.org/ml/gcc-patches/2015-12/msg02019.html
patch, fixing ICE with GNU __thread vars in templates.
Can't you unconditionally clear DECL_TEMPLAT
Hi,
On 11.01.2016 20:20, Michael Meissner wrote:
> On Sun, Jan 10, 2016 at 05:10:29PM -0600, Peter Bergner wrote:
>> On Sun, 2016-01-10 at 19:28 +, Bernd Edlinger wrote:
>>> Hi Peter,
>>>
@@ -4167,6 +4167,7 @@
-d "/opt/$with_advance_toolchain/bin/." -a \
The standard says that whether an implicitly defined constructor is
deleted depends on whether "any potentially constructed subobject has a
type with a destructor that is deleted or inaccessible from the
defaulted default constructor", but it does not say the same about
triviality, nor that it
Hi,
On 11.01.2016 20:03, Richard Biener wrote:
> On January 11, 2016 7:21:59 PM GMT+01:00, Bernd Schmidt
> wrote:
>> On 01/05/2016 07:43 PM, Richard Biener wrote:
>>> IIRC the logic at some point at least used host CPU detection to
>>> select asm. That's undesirable if you want to run binaries
On 01/09/16 02:41, Jakub Jelinek wrote:
Hi!
I'd like to ping the PR c++/66808, PR c++/69000
http://gcc.gnu.org/ml/gcc-patches/2015-12/msg02019.html
patch, fixing ICE with GNU __thread vars in templates.
Can't you unconditionally clear DECL_TEMPLATE_INFO regardless of local_p?
if (DECL_LANG_SP
On 11.01.16 19:57, Jakub Jelinek wrote:
On Mon, Jan 11, 2016 at 07:37:30PM +0100, Andreas Tobler wrote:
@@ -104,6 +104,10 @@
AC_CHECK_LIB(rt, shm_open,
[link_sanitizer_common="-lrt $link_sanitizer_common"])
+# Do a configure time check for -ldl
+AC_CHECK_LIB(dl, dlsym,
+ [link_sanitizer_
On Sun, Jan 10, 2016 at 05:10:29PM -0600, Peter Bergner wrote:
> On Sun, 2016-01-10 at 19:28 +, Bernd Edlinger wrote:
> > Hi Peter,
> >
> > > @@ -4167,6 +4167,7 @@
> > > -d "/opt/$with_advance_toolchain/bin/." -a \
> > > -d "/opt/$with_advance_toolchain/incl
On January 11, 2016 7:21:59 PM GMT+01:00, Bernd Schmidt
wrote:
>On 01/05/2016 07:43 PM, Richard Biener wrote:
>> IIRC the logic at some point at least used host CPU detection to
>> select asm. That's undesirable if you want to run binaries on
>> different hosts. Not sure if this is still the ca
On 01/08/2016 03:13 PM, Jakub Jelinek wrote:
Hi!
The following testcase ICEs, because move_plus_up attempts to
optimize (subreg:HI (plus:SI (...) (const_int 0xff78)) 0)
into (plus:HI (subreg:HI (...) 0) (const_int 0xff78)) which is
incorrect, HImode CONST_INT with MSB set should be (const_int -1
On Mon, Jan 11, 2016 at 07:37:30PM +0100, Andreas Tobler wrote:
> @@ -104,6 +104,10 @@
> AC_CHECK_LIB(rt, shm_open,
>[link_sanitizer_common="-lrt $link_sanitizer_common"])
>
> +# Do a configure time check for -ldl
> +AC_CHECK_LIB(dl, dlsym,
> + [link_sanitizer_common="-lrt $link_sanitizer_co
I fixed the #ifdef to use __NO_FPRS__ (thanks for the heads up on that). I
also believe I fixed the various formatting issues. These two patches build on
a big endian power7 host and little endian power8 host with no regressions in
the testsuite (the gcc patch is included here, but it hasn't chan
Hi Bernd,
On 11.01.16 19:28, Bernd Schmidt wrote:
On 11/10/2015 11:00 PM, Andreas Tobler wrote:
the attached patch removes the hard-coded requirement for the link
operation with -ldl. On FreeBSD we do not need that, it breaks compilation.
# Common libraries that we need to link against for
On 11/10/2015 11:00 PM, Andreas Tobler wrote:
the attached patch removes the hard-coded requirement for the link
operation with -ldl. On FreeBSD we do not need that, it breaks compilation.
# Common libraries that we need to link against for all sanitizer libs.
-link_sanitizer_common='-lpthrea
On 01/05/2016 07:43 PM, Richard Biener wrote:
IIRC the logic at some point at least used host CPU detection to
select asm. That's undesirable if you want to run binaries on
different hosts. Not sure if this is still the case with newer
gmp/mpfr, but as long as we allow the ancient ones we shoul
On Mon, 2016-01-11 at 16:51 +0100, Bernd Schmidt wrote:
> On 12/18/2015 08:05 PM, David Malcolm wrote:
> > On Thu, 2015-12-17 at 19:21 +0100, Bernd Schmidt wrote:
> >> On 12/17/2015 07:32 PM, David Malcolm wrote:
> >>> + if (close_paren_loc)
> >>
> >> close_paren_loc != UNKNOWN_LOCATION
OK.
Jason
This patch from Andrew Wilkins makes the use of ps in the libgo
testsuite more portable. This should fix GCC PR 68980. Committed to
mainline.
Ian
Index: libgo/testsuite/gotest
===
--- libgo/testsuite/gotest (revision 231693)
++
I posted last version of patch where I took review comments into account
month ago:
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01328.html
Andris
On January 11, 2016 6:40:28 PM GMT+01:00, Jakub Jelinek
wrote:
>Hi!
>
>As the testcase shows, simplify_cond_using_ranges has one place where
>it can extend range of SSA_NAME_OCCURS_IN_ABNORMAL_PHI ssa names and
>cause SSA corruption by that.
>
>Fixed by only optimizing that if it is not (ab). Th
On Mon, Jan 11, 2016 at 10:39:58AM -0700, Jeff Law wrote:
> On 01/11/2016 10:10 AM, Jakub Jelinek wrote:
> >Hi!
> >
> >As mentioned in the PR, this is a test new in GCC 6, that relies on rtx
> >costs to be right to succeed, and on i?86 (32-bit) they are not right.
> >While the costs look weird on i
Hi!
Seems since delayed C++ folding fold_* can sometimes be called with
operand(s) that are NOP_EXPR of INTEGER_CST. Unfortunately the folder
is heavily unprepared to deal with that, I think it is not dozens but
hundreds of places where it assumes that if argN (result of STRIP_NOPS)
is INTEGER_CS
On January 11, 2016 6:15:48 PM GMT+01:00, Jakub Jelinek
wrote:
>Hi!
>
>Related to the PR69207 changes, the problem there has been that
>fold_convertible_p allowed conversion from a vector type to same sized
>integral type, and fold_convert used NOP_EXPR in that case. But,
>such an operation is m
On January 11, 2016 5:36:33 PM GMT+01:00, Bernd Schmidt
wrote:
>On 01/11/2016 05:33 PM, Matthew Wahab wrote:
>>
>> The case I'm trying to fix has (short)abs((int)short_var). I'd
>thought
>> that if
>> abs(short_var) was undefined because the result couldn't be
>represented
>> then the type
>> con
Hi!
As the testcase shows, simplify_cond_using_ranges has one place where
it can extend range of SSA_NAME_OCCURS_IN_ABNORMAL_PHI ssa names and
cause SSA corruption by that.
Fixed by only optimizing that if it is not (ab). The optimized
statements are GIMPLE_CONDs with SSA_NAME cmp INTEGER_CST, s
On 01/11/2016 10:10 AM, Jakub Jelinek wrote:
Hi!
As mentioned in the PR, this is a test new in GCC 6, that relies on rtx
costs to be right to succeed, and on i?86 (32-bit) they are not right.
While the costs look weird on i?86, it is cost code in generic code, and I'm
afraid changing those is to
On Tue, Jan 05, 2016 at 09:47:59AM -0600, James Norris wrote:
> I've updated the original patch after some very helpful
> comments from Sandra (thank you, thank you).
I'd prefer if OpenMP
* Enabling OpenMP::How to enable OpenMP for your applications.
* Runtime Library Routines:: The
On 11/01/16 16:39, Jakub Jelinek wrote:
On Mon, Jan 11, 2016 at 05:11:21PM +0100, Christophe Lyon wrote:
I tested a similar version on my side. It just makes the test become
UNSUPPORTED for arm/aarch64 + newlib. They used to pass, though.
Is anything bad on that? The test tests functions that
Hi!
If errors are reported in unrelated functions, then due to recent
Cilk+ related change in cp_gimplify_expr basically all gimplification
results in almost no statements to be added to the IL, while returning
SSA_NAMEs set by the missing code, because for INIT_EXPRs cp_gimplify_expr
would just r
On 01/05/2016 04:47 PM, James Norris wrote:
I've updated the original patch after some very helpful
comments from Sandra (thank you, thank you).
OK to commit to trunk?
I'm probably not fully qualified to review the contents either, but few
people are and it looks reasonable enough that I gues
Hi!
Related to the PR69207 changes, the problem there has been that
fold_convertible_p allowed conversion from a vector type to same sized
integral type, and fold_convert used NOP_EXPR in that case. But,
such an operation is much better handled using VCE.
Bootstrapped/regtested on x86_64-linux a
Hi!
Based on discussions on IRC, I'm submitting following fix for a regression
on aarch64 - partial reversion (the case where VCE works too, just I thought
using NOP_EXPR would be nicer) and change in the assert - op better be
some integral value if converting it to VECTOR_BOOLEAN_TYPE_P's element
Hi!
As mentioned in the PR, this is a test new in GCC 6, that relies on rtx
costs to be right to succeed, and on i?86 (32-bit) they are not right.
While the costs look weird on i?86, it is cost code in generic code, and I'm
afraid changing those is too risky now so late in stage3, so I'm just
prop
Hi all,
The test gcc.target/aarch64/tst_3.c fails for an explicit -mcpu=cortex-a53
because we don't
handle the recent compare with zero_extract pattern properly in rtx costs, so
we end up recursing
into its operands and end up rejecting the combination for some CPUs,
generating an AND-immediat
This adds a specialization of std::allocator_traits>
in order to avoid doing all the heavy SFINAE work to detect which
members are present in the allocator. We don't need to check for them
because we know the exact properties of std::allocator so can just
hard-code them.
This helps reduce some of
Hi all,
This patch fixes the test gcc.target/aarch64/pr66776.c for -mcpu=cortex-a53.
Currently we don't handle the (if_then_else (cond) (zero_extend r1)
(zero_extend r2))
form of CSEL, so we end up recursing into the operands of the if_then_else and
for some CPUs
reject the combination. We end
Hello!
With older binutils, dg-require-effective-target maybe_x32 works
correctly only on 64bit targets.
2016-01-11 Uros Bizjak
* gcc.target/i386/pr66232-10.c: Do not compile on ia32 target.
* gcc.target/i386/pr66232-11.c: Ditto.
* gcc.target/i386/pr66232-12.c: Ditto.
* gcc.ta
On Mon, Jan 11, 2016 at 05:11:21PM +0100, Christophe Lyon wrote:
> I tested a similar version on my side. It just makes the test become
> UNSUPPORTED for arm/aarch64 + newlib. They used to pass, though.
Is anything bad on that? The test tests functions that newlib does not
implement, so it is not
On Mon, Jan 11, 2016 at 09:41:31AM +0100, Richard Biener wrote:
> Hum. Can't you check id->remapping_type_depth? That said, how do
> we end up recursing into remap_decl when copying the variable length
> decl/type? Can't we avoid the recursion (basically avoid remapping
> variable-size types at
On 01/08/2016 06:21 PM, Martin Sebor wrote:
The point of this warning is that there are certain cases of incompatible
types that are less serious than others - namely, those where the only
aspect of the type that is different is its signedness. Those get a more
specific warning, which is given u
On 01/11/2016 05:33 PM, Matthew Wahab wrote:
The case I'm trying to fix has (short)abs((int)short_var). I'd thought
that if
abs(short_var) was undefined because the result couldn't be represented
then the type
conversion from int to short would also be undefined. In fact, it's
implementation
def
On Mon, Jan 11, 2016 at 8:15 AM, Uros Bizjak wrote:
> On Mon, Jan 11, 2016 at 3:52 PM, H.J. Lu wrote:
>> When FPU isn't used, there is no excess precision. We should set
>> FLT_EVAL_METHOD to 0 if 387 is disabled.
>>
>> OK for trunk?
>>
>> Thanks.
>>
>> H.J.
>> ---
>> gcc/
>>
>> PR targe
On 08/01/16 22:24, Joseph Myers wrote:
On Fri, 8 Jan 2016, Matthew Wahab wrote:
Hello,
The C/C++ front-ends apply type conversions to expressions using ABS
with integral arguments of type smaller than int. This means that, for
short x, ABS(x) becomes something like (short)ABS((int)x)). When th
On Mon, Jan 11, 2016 at 3:52 PM, H.J. Lu wrote:
> When FPU isn't used, there is no excess precision. We should set
> FLT_EVAL_METHOD to 0 if 387 is disabled.
>
> OK for trunk?
>
> Thanks.
>
> H.J.
> ---
> gcc/
>
> PR target/69225
> * config/i386/i386.h (TARGET_FLT_EVAL_METHOD): Se
Hi,
A wrong code bug is reported in PR68911, which GCC generates infinite loop for
below example after loop niter analysis changes. After that change,
scev_probably_wraps_p identifies that e_1 in below case never overflow/wrap:
:
e_15 = e_1 + 1;
:
# e_1 = PHI
if (e_1 <= 93)
On 11 January 2016 at 16:56, John David Anglin wrote:
> On 2016-01-11 8:24 AM, Jakub Jelinek wrote:
>>
>> On Mon, Jan 11, 2016 at 02:16:31PM +0100, Christophe Lyon wrote:
>
> In any case, we have no_c99_libc_has_function on hpux and everything on
> linux. So, I
> don't think testi
On 01/08/2016 02:23 PM, Olivier Hainque wrote:
+ /* Undefined variable references in specs are harmless if
+ we're running for --help or --version alone, or together. */
+ spec_undefvar_allowed =
+(((print_version || print_help_list)
+ && decoded_options_count == 2)
+ ||
+
On 01/08/2016 10:33 AM, Thomas Preud'homme wrote:
2016-01-08 Thomas Preud'homme
* g++.dg/pr67989.C: Remove ARM-specific option.
* gcc.target/arm/pr67989.C: New file.
I checked some other arm tests and they have things like
/* { dg-skip-if "avoid conflicting multilib optio
On 2016-01-11 8:24 AM, Jakub Jelinek wrote:
On Mon, Jan 11, 2016 at 02:16:31PM +0100, Christophe Lyon wrote:
In any case, we have no_c99_libc_has_function on hpux and everything on linux.
So, I
don't think testing with function_c99_misc on hppa will show any difference.
Okay with function_c99
The following fixes PR69173.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2016-01-11 Richard Biener
PR tree-optimization/69173
* tree-vect-loop.c (vect_fixup_scalar_cycles_with_patterns): Only
fixup the cycle if all stmts are in a pattern.
On 12/18/2015 08:05 PM, David Malcolm wrote:
On Thu, 2015-12-17 at 19:21 +0100, Bernd Schmidt wrote:
On 12/17/2015 07:32 PM, David Malcolm wrote:
+ if (close_paren_loc)
close_paren_loc != UNKNOWN_LOCATION - it's very confusing otherwise.
Bernd
Here's an updated version; the on
Hi!
On 01/11/2016 05:55 AM, Thomas Schwinge wrote:
Hi!
On Thu, 7 Jan 2016 12:57:32 -0600, James Norris
wrote:
The checking of variables declared by OpenACC declare directives
used within an OpenACC routine procedure was not being done correctly.
This fix adds the checking required and also a
On 01/11/2016 07:34 AM, Bernd Schmidt wrote:
> On 01/08/2016 11:37 PM, Cesar Philippidis wrote:
>> In openacc there are situations where a user may fail to mark a variable
>> or function as offloadable (either using declare or routine). This patch
>> makes the lto wrapper reduce the missing decl as
On 01/08/2016 11:37 PM, Cesar Philippidis wrote:
In openacc there are situations where a user may fail to mark a variable
or function as offloadable (either using declare or routine). This patch
makes the lto wrapper reduce the missing decl assertion to an error.
Hmm, it might be good to have a
On 01/11/2016 04:10 AM, Thomas Schwinge wrote:
> On Wed, 6 Jan 2016 19:55:02 -0800, Cesar Philippidis
> wrote:
>> This patch updates the way that private reductions are handled in gomp4
>> to be more like trunk.
>
> Anything to commit to trunk (test cases at least?)?
I could possibly apply the
When FPU isn't used, there is no excess precision. We should set
FLT_EVAL_METHOD to 0 if 387 is disabled.
OK for trunk?
Thanks.
H.J.
---
gcc/
PR target/69225
* config/i386/i386.h (TARGET_FLT_EVAL_METHOD): Set to 0 if
TARGET_80387 is false.
gcc/testsuite
PR tar
Another patch reducing the accuracy required in the bessel_6 test.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany
gcc/testsuite/ChangeLog
* gfortran.dg/bessel_6.f90: Reduce accuracy for S/390.
>From 70a35dd6f6bf906d8e5907667ad0f04f981a61ac Mon Sep 17 00:00:00 2001
From: Dominik Vog
On Thu, Jan 07, 2016 at 03:39:42PM +, Kyrill Tkachov wrote:
> Hi all,
>
> This is an aarch64-specific approach to fixing the issue I raised in the
> thread at:
> https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01779.html
>
> The guidance there was to define aarch64 patterns for comparing QImod
On 11/01/16 12:54, Christian Bruel wrote:
Hi Kyrill,
On 01/11/2016 12:32 PM, Kyrill Tkachov wrote:
Hi Christian,
On 07/01/16 15:40, Christian Bruel wrote:
as discussed with Kyrill
(https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00307.html), this patch avoids
confusing (for the testsuite) ma
On 01/11/16 07:18, Thomas Schwinge wrote:
Hi!
On Tue, 5 Jan 2016 09:22:46 -0500, Nathan Sidwell wrote:
This patch merges my most recent sequence of ptx backend changes to the gomp4
branch.
I suppose it's not been intentional that during that, you dropped some of
the changes present on gomp-
This was an attempt to make more of the vect testsuite compilable with a stage-1
compiler, i.e. without standard header files like stdlib.h, to ease looking for
differences in assembly output. (It is still necessary to comment out most of
tree-vect.h to do this, but at least such temporary/local ch
Hi Robert,
Do you have an updated version of this patch? It no longer applies cleanly.
Thanks,
Matthew
> -Original Message-
> From: Robert Suchanek
> Sent: 05 January 2016 16:17
> To: catherine_mo...@mentor.com; Matthew Fortune
> Cc: gcc-patches@gcc.gnu.org
> Subject: RE: [PATCH 3/4] Add
James,
ok from our side—good to see that this also benefits the A57.
Best,
Philipp.
> On 11 Jan 2016, at 13:04, James Greenhalgh wrote:
>
>
> Hi,
>
> I've seen a couple of large performance issues caused by expanding
> the high-precision reciprocal square root for Cortex-A57, so I'd like
> t
Hi Robert,
Thanks for the update and detailed comments. There are a couple of things
which I think still need addressing based solely on your comments but
generally the changes seem to have simplified things which is nice to see.
I haven't read the patch again yet and given the changes it looks l
On Mon, Jan 11, 2016 at 02:16:31PM +0100, Christophe Lyon wrote:
> >> In any case, we have no_c99_libc_has_function on hpux and everything on
> >> linux. So, I
> >> don't think testing with function_c99_misc on hppa will show any
> >> difference.
> >>
> >> Okay with function_c99_misc?
> >
> > Ok
On 9 January 2016 at 17:48, Jakub Jelinek wrote:
> On Thu, Dec 31, 2015 at 12:52:21PM -0500, John David Anglin wrote:
>> On 2015-12-30, at 6:46 PM, Joseph Myers wrote:
>>
>> > On Mon, 28 Dec 2015, John David Anglin wrote:
>> >
>> >> The attach change fixes PR middle-end/68743 on hppa*-*-hpux*. In
On Mon, Jan 11, 2016 at 01:28:36PM +0100, Dominik Vogt wrote:
> On Mon, Jan 11, 2016 at 11:46:21AM +0100, Dominik Vogt wrote:
> > The following two patches fix some test cases for S/390.
>
> Patch 3:
>
> Disable g++.dg/init/const9.C on S/390 as discussed here:
> https://gcc.gnu.org/bugzilla/s
On 10 January 2016 at 13:15, Thomas Schwinge wrote:
> Hi!
>
> On Fri, 8 Jan 2016 11:30:16 +, Alan Lawrence
> wrote:
>> Here's an alternative patch, [...]
>
>> +/* { dg-final { scan-tree-dump "note: Built SLP cancelled: can use
>> load/store-lanes" { target { vect_perm && vect_load_lanes }
The attached patch improves the help text of the -mmvcle option on
S/390.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany
gcc/ChangeLog
* config/s390/s390.opt (mmvcle): More verbose help text.
>From 817358341388950641967d709ca2945bc8305998 Mon Sep 17 00:00:00 2001
From: Dominik Vogt
On Mon, 11 Jan 2016, Jakub Jelinek wrote:
> This patch is ok for trunk with proper attribution in the ChangeLog.
I went ahead and applied the patch myself.
Thanks.
Alexander
On Mon, Jan 11, 2016 at 11:46:21AM +0100, Dominik Vogt wrote:
> The following two patches fix some test cases for S/390.
Patch 3:
Disable g++.dg/init/const9.C on S/390 as discussed here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56194
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany
Hi,
when doing an ftree-parallelize-loops=2 build (PR68967), I ran into an
ICE building gcc/ada/g-debpoo.adb.
The problem occurs when handling a loop with header bb 109, latch bb 108
and exit bb 110:
...
;; basic block 109
# ivtmp_520 = PHI <0(129), ivtmp_151(108)>
# RANGE [0, 1022] NONZERO
Hi!
On Tue, 5 Jan 2016 09:22:46 -0500, Nathan Sidwell wrote:
> This patch merges my most recent sequence of ptx backend changes to the
> gomp4
> branch.
I suppose it's not been intentional that during that, you dropped some of
the changes present on gomp-4_0-branch, once installed for "[gomp4
On 11 January 2016 at 10:46, Alan Lawrence wrote:
> However, the test doesn't really look at whether we're using glibc vs
> musl/bionic/uclibc, only at whether we are targeting -linux-gnu or
> -none-elf.
Fair point, the test case is not aligned with the implementation.
Rather than hang the test
On Fri, Dec 18, 2015 at 12:13:31PM +, James Greenhalgh wrote:
>
> On Mon, Dec 14, 2015 at 11:49:26AM +, Marcus Shawcroft wrote:
> > On 14 December 2015 at 11:01, James Greenhalgh
> > wrote:
> > > On Wed, Dec 09, 2015 at 01:13:20PM +, Marcus Shawcroft wrote:
> > >> On 27 November 2015
Hi!
On Wed, 6 Jan 2016 19:55:02 -0800, Cesar Philippidis
wrote:
> This patch updates the way that private reductions are handled in gomp4
> to be more like trunk.
Anything to commit to trunk (test cases at least?)?
> This patch has been applied to gomp-4_0-branch.
> PR other/68813
Can
Hi,
I've seen a couple of large performance issues caused by expanding
the high-precision reciprocal square root for Cortex-A57, so I'd like
to turn it off by default.
This is good for art (~2%) from Spec2000, bad (~3.5%) for fma3d from
Spec2000, good (~5.5%) for gromcas from Spec2006, and very
Ok, this works too. Here is a version that adds orig_x to the if_info
struct and passes it down
to bbs_ok_for_cmove_arith.
This passes bootstrap and test on arm, aarch64, x86_64.
I think this is ok.
Bernd
There are quite a few redundant type conversions in arm_neon.h, all of
them are intrinsics taking argument of vector float type and return result
of vector unsigned integer type.
The problem is currently we support UNOP and UNOPU qualifiers for unary
"signed <- signed", "unsigned <- unsigned" res
Hi!
On Thu, 7 Jan 2016 12:57:32 -0600, James Norris
wrote:
> The checking of variables declared by OpenACC declare directives
> used within an OpenACC routine procedure was not being done correctly.
> This fix adds the checking required and also adds to the testing.
>
> This fix resolves the is
Hi,
I'd like to switch the logic around in aarch64.c such that
-mlow-precision-recip-sqrt causes us to always emit the low-precision
software expansion for reciprocal square root. I have two reasons to do
this; first is consistency across -mcpu targets, second is enabling more
-mcpu targets to us
Hello HJ,
On 10 Jan 14:28, H.J. Lu wrote:
> This patch removes snprintf from _(load|store)_mask
> patterns. Tested on x86-64. OK for trunk?
The patch is OK for main trunk.
--
Thanks, K
>
> H.J.
> ---
>
> * config/i386/sse.md (_load_mask): Remove
> snprintf.
> (_store_mask): L
1 - 100 of 129 matches
Mail list logo
