On Tue, Mar 27, 2018 at 11:11 PM, Jakub Jelinek wrote:
> Hi!
>
> In 6.x we've changed unsigned if (a < b) a++; into ADD_OVERFLOW ifn,
> which results in different expanded code, which on the following testcase
> unfortunately doesn't combine anymore into the optimal 3 instructions.
>
> The problem
On 03/21/2018 01:44 PM, Jakub Jelinek wrote:
On Wed, Mar 21, 2018 at 01:40:08PM +0100, Martin Liška wrote:
2018-03-21 Martin Liska
PR target/84988
* config/i386/i386.c (ix86_function_arg_advance): Do not call
chkp_type_bounds_count if MPX is not enabled.
---
gcc/con
On Mar 23, 2018, Jason Merrill wrote:
> On Fri, Mar 23, 2018 at 4:55 PM, Jason Merrill wrote:
>> On Fri, Mar 23, 2018 at 12:44 PM, Jason Merrill wrote:
>>> Seems like cp_fold should update CALL_EXPR_FN with "callee" if non-null.
>>
>> Did you try this? That should avoid it being ADDR_EXPR of
On 03/27/2018 01:53 PM, Mikael Morin wrote:
Le 26/03/2018 à 03:53, Jerry DeLisle a écrit :
On 03/25/2018 02:11 PM, Mikael Morin wrote:
Le 25/03/2018 à 21:27, Jerry DeLisle a écrit :
On 03/25/2018 10:49 AM, Mikael Morin wrote:
Le 25/03/2018 à 00:25, Jerry DeLisle a écrit :
On 03/24/2018 02:56
Hi Bill,
On Tue, Mar 27, 2018 at 04:10:00PM -0500, Bill Schmidt wrote:
> The xmmintrin.h compatibility header embeds altivec.h to use the Power
> vector intrinsics. However, it needs to be careful not to use the "bool"
> keyword with vectors so the headers don't cause potential problems in C++
>
On Wed, Mar 07, 2018 at 08:22:54PM +, Segher Boessenkool wrote:
> This adds a new option -mreadonly-in-sdata (on by default) that
> controls whether readonly data can be put in sdata. (For EABI this
> does nothing, readonly data is put in sdata2 as usual).
I now have backported this to GCC 7
On Fri, Mar 23, 2018 at 03:19:03PM -0400, Michael Meissner wrote:
> 2018-03-23 Michael Meissner
>
> PR target/84914
> * config/rs6000/rs6000.c (create_complex_muldiv): New helper
> function to create the function decl for complex long double
> multiply and divide for -ma
Hi!
On Fri, Mar 23, 2018 at 12:41:38PM -0500, Peter Bergner wrote:
> This is the second patch to fix PR84912, which is an ICE when calling some
> extended divide builtin functions. This patch is relative to the first
> patch. This fixes the ICE by adding a new mask to the builtin functions
> tha
When I last worked on fusion, I put a bunch of support to save the insn code of
various functions for creating fusion. I never actually used these functions,
except printing them out with -mdebug=reg. This patch deletes the generator
functions for the insns, but it does not delete the actual insn
On Fri, Mar 23, 2018 at 12:40:09PM -0500, Peter Bergner wrote:
> This is the first patch to fix PR84912, which is an ICE when calling some
> extended divide builtin functions. In discussing this offline, we decided
> that all div*o builtin functions make no sense because we don't model the
> OV bi
On 03/27/2018 09:19 PM, Martin Sebor wrote:
> On 03/27/2018 01:38 PM, Pedro Alves wrote:
>> On 03/27/2018 07:18 PM, Martin Sebor wrote:
>>> +Because a @code{pure} function can have no side-effects it does not
>>
>> FWIW, I'd suggest rephrasing as:
>>
>> Because a @code{pure} function cannot have s
Hi!
In 6.x we've changed unsigned if (a < b) a++; into ADD_OVERFLOW ifn,
which results in different expanded code, which on the following testcase
unfortunately doesn't combine anymore into the optimal 3 instructions.
The problem is that we want adc[lq] $0, %reg instruction, but simplify-rtx.c
le
Hi,
The xmmintrin.h compatibility header embeds altivec.h to use the Power
vector intrinsics. However, it needs to be careful not to use the "bool"
keyword with vectors so the headers don't cause potential problems in C++
and C11 code when using strict-ANSI. I noticed a few cases where this was
Hi!
As mentioned in the PR, sw_absorption.fppized.f90 relies on pow in
x = log10 (something) - y;
for (...)
{
x = x + y;
z = pow (10.0, x);
}
where x + y in the first iteration is exactly -3 to be >= 0.001,
unfortunately with the pow(cst, x) -> exp (log (cst) * x) optimization
with -Of
Le 26/03/2018 à 03:53, Jerry DeLisle a écrit :
On 03/25/2018 02:11 PM, Mikael Morin wrote:
Le 25/03/2018 à 21:27, Jerry DeLisle a écrit :
On 03/25/2018 10:49 AM, Mikael Morin wrote:
Le 25/03/2018 à 00:25, Jerry DeLisle a écrit :
On 03/24/2018 02:56 PM, Steve Kargl wrote:
On Sat, Mar 24, 2018
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'cpplib' has been submitted
by the Spanish team of translators. The file is available at:
http://translationproject.org/latest/cpplib/es.po
(This file, 'cpplib-8.1-b20180128
cpplib-8.1-b20180128.es.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
On 03/27/2018 01:38 PM, Pedro Alves wrote:
On 03/27/2018 07:18 PM, Martin Sebor wrote:
+Because a @code{pure} function can have no side-effects it does not
FWIW, I'd suggest rephrasing as:
Because a @code{pure} function cannot have side effects
because "can have no side-effects" can be read
OK.
On Tue, Mar 27, 2018 at 4:33 AM, Paolo Carlini wrote:
> Hi,
>
> Volker noticed that a tweak I committed back in September, which tidied the
> diagnostic we produce in C++11 mode for the testcase in c++/68754 causes
> this error recovery regression. We could try restoring the consistency, for
OK.
On Tue, Mar 27, 2018 at 4:52 AM, Jakub Jelinek wrote:
> Hi!
>
> Both build_{reference,pointer}_type start with if (to_type ==
> error_mark_node) return error_mark_node;
>
> cp_build_reference_type uses build_reference_type, so in many cases it will
> just return error_mark_node if it is passe
OK.
On Tue, Mar 27, 2018 at 4:54 AM, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs, because we assert that we see a COMPOUND_EXPR
> only for static data member in a volatile struct, but as the testcase shows,
> we can see it also if using some component of the static data member.
>
>
OK.
On Tue, Mar 27, 2018 at 5:18 AM, Jakub Jelinek wrote:
> Hi!
>
> The following testcase regressed for 8+, because we delayed folding in
> SAVE_EXPRs and end up passing a CONSTRUCTOR with V4SFmode and 4x 0.0
> constants in it rather than a VECTOR_CST to the middle-end folder, which
> uses real_
On 03/27/2018 07:18 PM, Martin Sebor wrote:
> +Because a @code{pure} function can have no side-effects it does not
FWIW, I'd suggest rephrasing as:
Because a @code{pure} function cannot have side effects
because "can have no side-effects" can be read as
"is allowed to have no side effects", whi
Hi again,
On Tue, Mar 27, 2018 at 07:59:30PM +0200, Uros Bizjak wrote:
> > (the two compares were combined, by fwprop1) but without the flag we get
> >
> > fcmpo 5,1,2
> > li 3,-1
> > bltlr 5
> > mfcr 3,4
> > rlwinm 3,3,22,1
> > fcmpo 7,1,2
> >
Hello world,
I have just committed r258900 as obvious on trunk to fix an
out-of-memory error in front-end optimization, which was
caused by gfortran's AST being in an inconsistent state.
I suspect that this will also fix other, as yet unknown
errors.
I will backport to the other affected branch
From some feedback I received on some of the attribute warnings
new in GCC 8 it seems that the manual could stand to be clarified
to explain why it makes no sense for a function declared with
attribute const (and pure) to return void. The attached patch
adds a bit more text to make it clear.
In
On Tue, Mar 27, 2018 at 7:20 PM, Segher Boessenkool
wrote:
> Hi!
>
> On Tue, Mar 27, 2018 at 09:30:35AM +0200, Uros Bizjak wrote:
>> +(define_insn "*cmpdd_cmpo"
>> + [(set (match_operand:CCFP 0 "cc_reg_operand" "=y")
>> + (compare:CCFP (match_operand:DD 1 "gpc_reg_operand" "d")
>> + (match_o
Hello Harald,
The attached obvious one-liner adds a missing check for type
compatibility in a structure constructor.
Testcase from report. Changelogs below.
Regtested on i686-pc-linux-gnu.
Whoever reviews this, please feel free to commit.
Reviewed and dommitted as r258899. I have changed
Hi!
On Tue, Mar 27, 2018 at 09:30:35AM +0200, Uros Bizjak wrote:
> +(define_insn "*cmpdd_cmpo"
> + [(set (match_operand:CCFP 0 "cc_reg_operand" "=y")
> + (compare:CCFP (match_operand:DD 1 "gpc_reg_operand" "d")
> + (match_operand:DD 2 "gpc_reg_operand" "d")))
> + (unspec [(match_dup 1) (ma
On Tue, Mar 27, 2018 at 10:08 AM, Uros Bizjak wrote:
> On Mon, Mar 26, 2018 at 10:42 PM, Tsimbalist, Igor V
> wrote:
>>> -Original Message-
>>> From: H.J. Lu [mailto:hjl.to...@gmail.com]
>>> Sent: Monday, March 26, 2018 5:59 PM
>>> To: Tsimbalist, Igor V
>>> Cc: gcc-patches@gcc.gnu.org;
An assertion in the test fails on a number of targets due to
a missing strlen optimization. I plan to add the optimization
for GCC 9 but it's too late to add it now. To prevent the
failure r258896 disables and xfails the assertion for targets
other than x86. Attached is the change for reference
On Mon, Mar 26, 2018 at 10:42 PM, Tsimbalist, Igor V
wrote:
>> -Original Message-
>> From: H.J. Lu [mailto:hjl.to...@gmail.com]
>> Sent: Monday, March 26, 2018 5:59 PM
>> To: Tsimbalist, Igor V
>> Cc: gcc-patches@gcc.gnu.org; Uros Bizjak
>> Subject: Re: [PATCH] i386: Insert ENDBR to tram
On Tue, Mar 27, 2018 at 02:39:12PM +0100, Kyrill Tkachov wrote:
> Hi all,
>
> The test in question fails for ilp32. The initial analysis I did in the PR
> for it
> is that for ILP32 we generate somewhat different address forms that we'd need
> to adjust aarch64_classify_address to catch.
> Given
On 21/03/18 11:40, Sudakshina Das wrote:
Hi
On 21/03/18 08:51, Christophe Lyon wrote:
On 20 March 2018 at 11:58, Sudakshina Das wrote:
Hi
On 20/03/18 10:03, Richard Earnshaw (lists) wrote:
On 14/03/18 10:11, Sudakshina Das wrote:
Hi
This patch fixes PR82989 so that we avoid NEON instruc
Hi Jakub,
Gentle ping.
Thanks,
Sebastian
> -Original Message-
> From: Kirill Yukhin [mailto:kirill.yuk...@gmail.com]
> Sent: Friday, March 23, 2018 6:49 AM
> To: ja...@redhat.com; Peryt, Sebastian
> Cc: 'gcc-patches@gcc.gnu.org'
> Subject: Re: [PATCH][i386,AVX] Fix PR84783 - backport m
I'm bringing this to the direct attention of the
release-maintainers, asking for approval for gcc-8.
(If this is in your queue already, then sorry for nagging, but
IIUC you both filter gcc-patches@ traffic heavily.)
All patches are to MIPS-specific code.
libsanitizer:
Add __sanitizer.lock.pad init
On Tue, Jun 6, 2017 at 1:25 AM, Kyrill Tkachov
wrote:
> Hi all,
>
> I'm trying to improve some of the RTL-level handling of vector lane
> operations on aarch64 and that
> involves dealing with a lot of vec_merge operations. One simplification that
> I noticed missing
> from simplify-rtx are combin
This has been in my patch stack for quite some time. The problem here
was that we weren't handling arm_word_relocations in
arm_valid_symbolic_address and is the surest fix for this
for GCC8 and GCC7.
Regression tested on arm-none-linux-gnueabihf . Applying to
trunk and backporting to GCC-7 in a da
On Tue, Mar 27, 2018 at 6:32 AM, Richard Biener wrote:
>
> Status
> ==
>
> The GCC 8 trunk is open for regression and documentation fixes. Following
> past releases we are aiming at a first release candidate mid April though
> if you look at the quality data below that looks ambitious.
>
> So
Hi all,
The test in question fails for ilp32. The initial analysis I did in the PR for
it
is that for ILP32 we generate somewhat different address forms that we'd need
to adjust aarch64_classify_address to catch.
Given the optimisation this test checks for was added for GCC 8 it is not a
regre
Status
==
The GCC 8 trunk is open for regression and documentation fixes. Following
past releases we are aiming at a first release candidate mid April though
if you look at the quality data below that looks ambitious.
So please help tackling (and confirming, bisecting, reducing, etc.)
regre
On Tue, 27 Mar 2018, Peter Bergner wrote:
> On 3/27/18 3:18 AM, Richard Biener wrote:
> > On Mon, 26 Mar 2018, Peter Bergner wrote:
> >>/* Create inter-loop true dependences and anti dependences. */
> >>for (r_use = DF_REF_CHAIN (last_def); r_use != NULL; r_use =
> >> r_use->next)
> >>
On 3/27/18 3:18 AM, Richard Biener wrote:
> On Mon, 26 Mar 2018, Peter Bergner wrote:
>>/* Create inter-loop true dependences and anti dependences. */
>>for (r_use = DF_REF_CHAIN (last_def); r_use != NULL; r_use = r_use->next)
>> {
>> + /* PR84878: Some definitions of global hard
Hi
This patch adds the no variant to -mstrict-align and the corresponding
function attribute. To enable the function attribute, I have modified
aarch64_can_inline_p () to allow checks even when the callee function
has no attribute. The need for this is shown by the new test
target_attr_18.c.
Tes
On 03/02/2018 09:47 PM, Cesar Philippidis wrote:
two test cases.
Committed as separate patch, while ignoring the warnings "using
vector_length \\(32\\), ignoring 128".
Thanks,
- Tom
[openacc] Add vector_length 128 testcases
2018-03-27 Cesar Philippidis
Tom de Vries
* testsuite/l
On 03/26/2018 06:33 PM, Tom de Vries wrote:
+ loop->mask = targetm.goacc.adjust_parallelism (loop->mask, outer_mask);
loop->mask |= this_mask;
I committed the above, but the original:
...
@@ -1397,6 +1407,8 @@ oacc_loop_auto_partitions (oacc_loop *loop, unsigned
outer_mask,
The following attempts to fix PR82847 by introducing a check whether
ssse3 is available and enable vect_perm_short if so. Somewhat of
a kludge but I can't think of anything better right now.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2018-03-27 Richard Biener
>From the alias-oracle walk we don't get here with valueized VUSE
so valueize it before looking up an existing value, otherwise
we'll ICE upon insertion which does valueize.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2018-03-27 Richard Biener
PR tree-opt
The following guards the fold_plusminus_mult patterns with explicit
single_use checks to avoid regressing gcc.dg/wmul-1.c, that is,
introduction of additional multiplications.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
I've checked with a cross to aarch64 that the FAIL is gon
Hi Jakub,
> -Original Message-
> From: Jakub Jelinek
> Sent: Tuesday, March 27, 2018 4:43 PM
> To: Kumar, Venkataramanan
> Cc: Richard Biener ; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] Improve TRUTH_{AND,OR}IF_EXPR expansion (PR rtl-
> optimization/78200)
>
> On Tue, Mar 27, 2018
On Tue, Mar 27, 2018 at 11:04:35AM +, Kumar, Venkataramanan wrote:
> > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk if it
> > helps for SPEC? Venkat, do you think you could benchmark it in the setup
> > where you've measured the slowdown to see if it helps? I see the pa
Hi Jakub,
> -Original Message-
> From: Jakub Jelinek
> Sent: Tuesday, March 27, 2018 2:40 PM
> To: Richard Biener
> Cc: gcc-patches@gcc.gnu.org; Kumar, Venkataramanan
>
> Subject: [PATCH] Improve TRUTH_{AND,OR}IF_EXPR expansion (PR rtl-
> optimization/78200)
>
> Hi!
>
> The following
On 03/27/2018 04:49 AM, Jakub Jelinek wrote:
Hi!
As the comment says, in a valid program we wals find thunk_binfo, but if the
covariancy is invalid, we've already diagnosed error and we might not find
it. We have case to handle thunk_binfo NULL or not finding it in the chain,
but on the followi
On 03/27/2018 03:08 AM, Volker Reichelt wrote:
On 03/26/2018 01:19 PM, Nathan Sidwell wrote:
On 03/25/2018 10:18 AM, Volker Reichelt wrote:
How about the following then?
I rephrased the last three errors a little to really make them
stand-alone errors.
Again, bootstrapped and regtested.
O
Hi Paul,
> ChangeLog entries:
>
> gcc/testsuite/ChangeLog
>
> 2018-03-24 Chenghua Xu
>
> * gcc.target/mips/fix-r4000-1.c: Delete "[^\n]" in dg-final.
> * gcc.target/mips/fix-r4000-2.c: Likewise.
> * gcc.target/mips/fix-r4000-3.c: Likewise.
> * gcc.target/mips/fix-r4000-4.c: Li
Hi Paul
> ChangeLog entries:
>
> gcc/testsuite/ChangeLog
>
> 2018-03-24 Chenghua Xu
>
> * gcc.target/mips/umips-stroe16-2.c: Change "length = 2"
> to "l=2" in dg-final.
Looks good. Thanks for the cleanup. OK to commit.
Matthew
Tested on x86_64-unknown-linux-gnu, applied.
Richard.
2018-03-27 Richard Biener
PR testsuite/84004
* gcc.dg/vect/vect-95.c: Never expect the loop to be peeled for
alignment.
Index: gcc/testsuite/gcc.dg/vect/vect-95.c
==
On Mon, Mar 19, 2018 at 12:12 PM, James Greenhalgh
wrote:
> On Tue, Mar 13, 2018 at 01:35:56PM +, Ramana Radhakrishnan wrote:
>> Jakub commented here that
>> https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01325.html we don't turn
>> on fasynchronous-unwind-tables for AArch64. I note that x86_64
Hi!
The following testcase regressed for 8+, because we delayed folding in
SAVE_EXPRs and end up passing a CONSTRUCTOR with V4SFmode and 4x 0.0
constants in it rather than a VECTOR_CST to the middle-end folder, which
uses real_zerop and thus doesn't recognize the CONSTRUCTOR in
VEC_COND_EXPR as z
Hi Jakub,
> -Original Message-
> From: Jakub Jelinek
> Sent: Tuesday, March 27, 2018 2:40 PM
> To: Richard Biener
> Cc: gcc-patches@gcc.gnu.org; Kumar, Venkataramanan
>
> Subject: [PATCH] Improve TRUTH_{AND,OR}IF_EXPR expansion (PR rtl-
> optimization/78200)
>
> Hi!
>
> The following
Hi!
The following patch attempts to improve expansion, if we have code like:
[local count: 102513059]:
if_conversion_var_52 = MEM[base: st1_22, offset: 0B];
if (if_conversion_var_52 < 0)
goto ; [41.00%]
else
goto ; [59.00%]
...
[local count: 60482706]:
_81 = _11 == 2;
_82
Hi!
The following testcase ICEs, because we assert that we see a COMPOUND_EXPR
only for static data member in a volatile struct, but as the testcase shows,
we can see it also if using some component of the static data member.
Fixed by using get_base_address, plus, as the check isn't as cheap as
b
Hi!
Both build_{reference,pointer}_type start with if (to_type ==
error_mark_node) return error_mark_node;
cp_build_reference_type uses build_reference_type, so in many cases it will
just return error_mark_node if it is passed, but if rval is true, it will
assume build_reference_type returned som
Hi!
As the comment says, in a valid program we wals find thunk_binfo, but if the
covariancy is invalid, we've already diagnosed error and we might not find
it. We have case to handle thunk_binfo NULL or not finding it in the chain,
but on the following testcase base_binfo is NULL and we ICE when
Hi,
Volker noticed that a tweak I committed back in September, which tidied
the diagnostic we produce in C++11 mode for the testcase in c++/68754
causes this error recovery regression. We could try restoring the
consistency, for example along the lines of the patchlet I posted on the
audit tr
On Mon, 26 Mar 2018, Peter Bergner wrote:
> PR84878 shows an example where we segv while creating data dependence edges
> for SMS.
>
> ddg.c:add_cross_iteration_register_deps():
>
> /* Create inter-loop true dependences and anti dependences. */
> for (r_use = DF_REF_CHAIN (last_def); r_use
On 03/26/2018 11:57 PM, Cesar Philippidis wrote:
As noted in PR85056, the nvptx BE isn't declaring external arrays using
PTX array notation. Specifically, it's emitting code that's missing the
empty angle brackets '[]'.
[ FYI, see https://en.wikipedia.org/wiki/Bracket
For '[]' I find "square
Hello!
+(define_insn "*cmpdd_cmpo"
+ [(set (match_operand:CCFP 0 "cc_reg_operand" "=y")
+ (compare:CCFP (match_operand:DD 1 "gpc_reg_operand" "d")
+ (match_operand:DD 2 "gpc_reg_operand" "d")))
+ (unspec [(match_dup 1) (match_dup 2)] UNSPEC_CMPO)]
+ "TARGET_DFP"
+ "dcmpo %0,%1,%2"
+ [(s
On 03/26/2018 01:19 PM, Nathan Sidwell wrote:
On 03/25/2018 10:18 AM, Volker Reichelt wrote:
Index: gcc/cp/search.c
===
--- gcc/cp/search.c (revision 258835)
+++ gcc/cp/search.c (working copy)
@@ -1918,12 +1918,14 @@
69 matches
Mail list logo
