On February 13, 2015 8:48:25 PM CET, Jakub Jelinek wrote:
>Hi!
>
>With LTO and -O0 initial compilation, -O1 linking we at some point used
>to
>add stmts normal after a PHI, which is invalid.
>This patch fixes that by inserting after labels instead.
>No testcase provided, as the issue is latent any
cpplib-5.1-b20150208.ru.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
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 Russian team of translators. The file is available at:
http://translationproject.org/latest/cpplib/ru.po
(This file, 'cpplib-5.1-b20150208
This also breaks the bootstrap on x86_64-apple-darwin14 due to a
similar stage 2/3 comparison failure.
On Fri, Feb 13, 2015 at 6:01 PM, H.J. Lu wrote:
> On Fri, Feb 13, 2015 at 1:11 PM, Jeff Law wrote:
>> This time with the right patch file.
>>
>> commit 48087ce0b383457b5919cbcc2ce1a5e1aaa264c3
Hi,
the attached patch fixes PR65048 by checking before jump-threading that a path
to be threaded is still valid: as the testcase shows, there may be paths that
are not connected anymore because the cfg has changed in a previous jump-thread.
PR tree-optimization/65048
* tree-ssa-t
On 02/12/15 05:40, Alex Velenko wrote:
On 09/02/15 23:32, Jeff Law wrote:
On 02/03/15 20:03, Bin.Cheng wrote:
I looked into the test and can confirm the previous compilation is
correct.
The cover letter of this patch said IRA mis-handled REQ_EQUIV before,
but in this case it is REG_EQUAL that i
On Fri, Feb 13, 2015 at 1:11 PM, Jeff Law wrote:
> This time with the right patch file.
>
> commit 48087ce0b383457b5919cbcc2ce1a5e1aaa264c3
> Author: Jeff Law
> Date: Fri Feb 13 14:08:06 2015 -0700
>
> PR tree-optimization/64823
> * tree-vrp.c (identify_jump_threads): Handle blo
On 02/13/15 12:52, Jakub Jelinek wrote:
Hi!
When moving assignment out of a conditional block before the condition, we
need to either reset or update SSA_NAME_RANGE_INFO, otherwise it might be
wrong, because when computed earlier, it could take into account that in
the conditional block the cond
Mike and FX,
Shouldn't we also apply...
Author: fxcoudert
Date: Mon Dec 22 21:57:45 2014
New Revision: 219035
URL: https://gcc.gnu.org/viewcvs?rev=219035&root=gcc&view=rev
Log:
* lib/ubsan-dg.exp: Add library path for libstdc++.
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/test
We can use the same trick used in the other tests. Patch attached.
Sorry about that!
2015-02-13 20:45 GMT+01:00 Jakub Jelinek :
> On Wed, Feb 11, 2015 at 12:26:33AM +0100, Andrea Azzarone wrote:
>> *
>> gcc/testsuite/g++.dg/cpp1y/udlit-char-template-vs-std-literal-operator.C:
>
> This fails o
On 02/13/2015 01:56 PM, Paolo Carlini wrote:
Anything you would recommend besides filing a new Bug Report (or marking
an existing one as regression)?!?
Definitely do that. I guess it has to do with not recognizing a
USING_DECL as a template...
Jason
In this testcase we were folding a bunch of nops within a
POINTER_PLUS_EXPR down to a single nop, and then tripping the assert in
maybe_constant_value that checks for useless rebuilding of the tree
because cp_tree_equal ignores NOPs. The reason for that choice seems to
have been so that we can
Hi David,
this is the patch I'm currently testing with gcc-4.8.4 for
http://gcc.gnu.org/PR65058
Thanks!
/haubi/
>From 0f5003fb25608cdae53445777e6a13fec3fbfffc Mon Sep 17 00:00:00 2001
From: Michael Haubenwallner
Date: Fri, 13 Feb 2015 19:26:27 +0100
Subject: [PATCH 1/5] Fix decorating referenced
This time with the right patch file.
commit 48087ce0b383457b5919cbcc2ce1a5e1aaa264c3
Author: Jeff Law
Date: Fri Feb 13 14:08:06 2015 -0700
PR tree-optimization/64823
* tree-vrp.c (identify_jump_threads): Handle blocks with no statements.
* tree-ssa-threadedge.c (potenti
Generally a block with PHIs, but no statements will be optimized away;
however, if the sole successor is a loop header, then such blocks will
not be optimized away.
We want to be able to thread through those blocks as sometimes we will
be able to thread from outside the loop to the loop exit
On 02/13/15 02:09, Richard Biener wrote:
Note that this can happen for GIMPLE as well for
struct X { long long a : 33; } x;
long long b;
b = x.a + x.a;
where you'll see 33bit temporaries from the loads of x.a (because C only
promotes bitfields up to size long).
We already have a related patte
On Fri, 13 Feb 2015, Marek Polacek wrote:
> This patch tweaks an error message a little bit so that we also print the
> type we're talking about.
>
> This is neither a regression nor a bug fix - should I queue this for GCC 6,
> or is it so minor that it can still go into GCC 5?
>
> Bootstrapped/
On Fri, 13 Feb 2015, Marek Polacek wrote:
> Since we had no testing for such cases whatsoever, I took existing flexible
> array member tests and duplicated them, only adjusted them to use a typedef
> name, so that we test as many scenarios as possible - I think this ought to
> give us a reasonable
Hi,
while looking for the soplex miscompilation I run across the following place
that
was not updated to polymorphic call contexts. When we do not know if type
is preserved, we only need to note that in the indirect_call_info.
Bootstrapped/regtested x86_64-linux, comitted.
Honza
PR ipa/
Hi,
the following patch by Martin Jambor fixes soplex miscompilation. I went ahead
regtested it on x86_64-linux and comitted.
Honza
--- Comment #4 from Martin Jambor ---
OK, so here are my findings. Switching off IPA-CP helps because the
pass then does not propagate polymorphic context from
_ZN
Hi!
When moving assignment out of a conditional block before the condition, we
need to either reset or update SSA_NAME_RANGE_INFO, otherwise it might be
wrong, because when computed earlier, it could take into account that in
the conditional block the condition is or is not true.
Fixed thusly, bo
Hi!
With LTO and -O0 initial compilation, -O1 linking we at some point used to
add stmts normal after a PHI, which is invalid.
This patch fixes that by inserting after labels instead.
No testcase provided, as the issue is latent anyway and I don't know how to
write lto testcases that use different
On Wed, Feb 11, 2015 at 12:26:33AM +0100, Andrea Azzarone wrote:
> *
> gcc/testsuite/g++.dg/cpp1y/udlit-char-template-vs-std-literal-operator.C:
This fails on i686-linux:
FAIL: g++.dg/cpp1y/udlit-char-template-vs-std-literal-operator.C -std=c++14
(test for excess errors)
Excess errors:
/h
On Fri, Feb 13, 2015 at 08:19:52PM +0100, Marek Polacek wrote:
> On Thu, Feb 12, 2015 at 05:14:19PM +0300, Ilya Enkovich wrote:
> > Hi,
> >
> > PR65002 is the second issue caused by SRA for functions wrongly marked as
> > read-only. Previous fix for PR64353 doesn't work for this case because SSA
On Thu, Feb 12, 2015 at 05:14:19PM +0300, Ilya Enkovich wrote:
> Hi,
>
> PR65002 is the second issue caused by SRA for functions wrongly marked as
> read-only. Previous fix for PR64353 doesn't work for this case because SSA
> update happens too late. Here is a patch to disable SRA for such fun
This patch tweaks an error message a little bit so that we also print the
type we're talking about.
This is neither a regression nor a bug fix - should I queue this for GCC 6,
or is it so minor that it can still go into GCC 5?
Bootstrapped/regtested on ppc64-linux.
2015-02-13 Marek Polacek
Hi,
On 02/13/2015 04:03 PM, Jason Merrill wrote:
On 02/11/2015 02:10 PM, Paolo Carlini wrote:
Today I was having a look to this pending issue and went astray due to
the broken thread: I wondered if, basing on Fabien' first try and the
comments accompanying tag_scope, it would make sense to use
As discussed in the PR, the problem with this test case:
typedef int A[];
struct S { int i; A a; };
is twofold. Firstly, we ICE with checking on, and secondly, we reject the
testcase. But there's nothing wrong with using typedef name as a flexible
array member.
Turned out the problem was that
On Fri, Feb 13, 2015 at 8:47 AM, Joseph Myers wrote:
> On Fri, 13 Feb 2015, H.J. Lu wrote:
>
>> the end. This patch adds gcc_default_target_compile, which is
>> almost identical to default_target_compile in dejagnu, except that
>> it has
>
> Duplicating large piles of code from DejaGnu seems a ba
On 02/13/2015 08:26 AM, Renlin Li wrote:
> + /* Complete overlap. We can remove the source ZERO_EXTEND. */
> + if (width == inner_size
> + && (regno < FIRST_PSEUDO_REGISTER)
> + && HARD_REGNO_MODE_OK (regno, mode))
> + {
> + rtx reg = gen_rtx_REG (mode, regno);
> +
On 02/13/2015 05:22 AM, John David Anglin wrote:
> + /* Reload sometimes tries to put const data symbolic operands in
> + readonly memory. The HP SOM linker doesn't allow symbolic data
> + in readonly memory. */
> + if (TARGET_SOM
> + && !function_label_operand (x, VOIDmode)
> +
Le 10/02/2015 23:35, Paul Richard Thomas a écrit :
> Dear Mikael, dear all,
>
> Thank you for the previous review. I believe that the attached
> responds to all of your comments and correctly compiles the three
> testcases that you provided. Two of these have been included in the
> original testca
On Fri, 13 Feb 2015, H.J. Lu wrote:
> the end. This patch adds gcc_default_target_compile, which is
> almost identical to default_target_compile in dejagnu, except that
> it has
Duplicating large piles of code from DejaGnu seems a bad idea - it's bound
to cause problems when DejaGnu makes its o
PING
-- Forwarded message --
From: H.J. Lu
Date: Wed, Jan 29, 2014 at 8:18 AM
Subject: PR testsuite/59971: multilib_flags is placed with the wrong order
To: gcc-patches@gcc.gnu.org
Cc: r...@cebitec.uni-bielefeld.de, mikest...@comcast.net
Hi,
Some testcases need explicit GCC opt
Hi all,
The following rtx pattern will be transformed into the second one,
which makes the compiler unable to remove the redundant zero_extend
operation.
(set (zero_extract:SI (reg/i:SI 0 x0)
(const_int 8 [0x8])
(const_int 0 [0]))
(and:SI (reg:SI 1
Hi!
On Thu, 18 Dec 2014 14:16:52 +0100, I wrote:
> --- /dev/null
> +++ gcc/config/i386/intelmic-offload.h
> +#define ACCEL_COMPILER_acc_device GOMP_DEVICE_INTEL_MIC
This one I got right...
> --- /dev/null
> +++ gcc/config/nvptx/offload.h
> @@ -0,0 +1,35 @@
> +#define ACCEL_COMPILER_acc_device
OK.
Jason
Hi,
this a second take, fixing the problem the way preferred by Jason in the
audit trail. Tested x86_64-linux.
Thanks,
Paolo.
/cp
2015-02-13 Paolo Carlini
PR c++/60211
* parser.c (cp_parser_pragma): Diagnose PRAGMA_IVDEP at
pragma_external
My patch to make the compiler give more friendly diagnostics about
cv-qual dropping in reference binding meant that we looked for
conversions to incomplete class type, leading to instantiating that
type, which can lead to errors that would not otherwise occur. So don't
try if the target is inc
On 02/11/2015 02:10 PM, Paolo Carlini wrote:
Today I was having a look to this pending issue and went astray due to
the broken thread: I wondered if, basing on Fabien' first try and the
comments accompanying tag_scope, it would make sense to use
strip_using_decl only when the scope is ts_global (
Hi all,
this patch try to fix PR c++/64948 (Lambda reference capture
initialization in template function creates segmentation fault).
2015-2-13 Andrea Azzarone
PR c++/64948
* lambda.c (add_capture) Do not consider as rvalues all expressions
involving template parameters.
--
Andrea Azzaron
OK.
Jason
OK.
Jason
Hi,
On 02/13/2015 03:14 PM, Paweł Tomulik wrote:
Hi,
the header file of libstdc++-v3 of gcc-4.9 is missing
return statement in the implementation of
basic_regex::assign(basic_regex&&). This is about line 619.
In current 4_9-branch, thus for 4.9.3, this is already fixed.
Thanks,
Paolo.
Hi,
the header file of libstdc++-v3 of gcc-4.9 is missing
return statement in the implementation of
basic_regex::assign(basic_regex&&). This is about line 619. The minimal
example to reproduce this bug is the following:
#include
int main()
{
std::regex re;
re.assign(std::regex("blabla"));
Hi!
For ARM EABI (the only target that returns non-void for ctors/dtors),
the C++ FE creates LABEL_DECL that survives into the middle-end with
NULL_TREE TREE_TYPE, which ICF ICEs on.
Most other places use void_type_node type for LABEL_DECLs, exception
is only LABEL_DECLs in templates that won't ma
On 02/13/2015 02:37 PM, Martin Liška wrote:
On 02/12/2015 05:57 PM, Jan Hubicka wrote:
From: mliska V
Date: Fri, 23 Jan 2015 14:58:36 +0100
Subject: [PATCH] Fix PR ipa/64693.
gcc/ChangeLog:
2015-02-12 Martin Liska
PR ipa/64693
* ipa-icf.c (sem_item_optimizer::execute): Call
identi
* config/avr/avr.c (avr_print_operand_address, avr_print_operand): Avoid
-Wformat-security warning.
* config/m68k/m68k.c (print_operand): Likewise.
* config/s390/s390.c (print_operand): Likewise.
* config/tilegx/tilegx.c (tilegx_print_operand): Likewise.
---
On 11/02/15 15:43, Jonathan Wakely wrote:
On 11/02/15 11:14 +, Matthew Wahab wrote:
Attached the fixed patch.
Tested by running check-target-libstdc++-v3, with the modified tests,
for arm-none-eabi and aarch64-none-linux-gnu.
Ok to commit?
OK, thanks.
Some DOS line endings were introduc
On 02/13/2015 02:37 PM, Martin Liška wrote:
On 02/12/2015 05:57 PM, Jan Hubicka wrote:
From: mliska V
Date: Fri, 23 Jan 2015 14:58:36 +0100
Subject: [PATCH] Fix PR ipa/64693.
gcc/ChangeLog:
2015-02-12 Martin Liska
PR ipa/64693
* ipa-icf.c (sem_item_optimizer::execute): Call
identi
On 02/12/2015 05:57 PM, Jan Hubicka wrote:
From: mliska V
Date: Fri, 23 Jan 2015 14:58:36 +0100
Subject: [PATCH] Fix PR ipa/64693.
gcc/ChangeLog:
2015-02-12 Martin Liska
PR ipa/64693
* ipa-icf.c (sem_item_optimizer::execute): Call
identify_address_sensitive_classes.
The recent change to use the "Q" constraint instead of the "m" constraint in
several patterns caused
a regression that broke the build of the Debian webkitgtk package. Memory
addresses (spills) with out
of range offsets were not being reloaded in functions with large frames. This
change fixes
Hi,
this one seems a typical very simple SFINAE issue, where we are not
correctly forwarding the tsubst_flags_t argument. Not sure if we are
still in time for 5.0...
Tested x86_64-linux.
Thanks,
Paolo.
///
/cp
2015-02-13 Paolo Carlini
PR c++/64970
* d
On 13/02/15 10:10, pins...@gmail.com wrote:
On Feb 13, 2015, at 1:48 AM, Kyrill Tkachov wrote:
Hi all,
In my tree added a pattern to the arm backend that's supposed to match:
(set (reg:SI r0)
(subreg:SI
(plus:DI
(mult:DI (sign_extend:DI (reg:SI r1))
On Fri, Feb 13, 2015 at 10:43 AM, Bin Cheng wrote:
> Hi,
> When dealing with PR62173, we found places in which overflow check on SCEVs
> can be improved by range information. This patch addresses one of them.
> Richard once suggested that we should trace range info all the way through
> SCEV thus
> On 13 Feb 2015, at 11:14, Richard Earnshaw
> wrote:
>
>> Is this ok?
>
> The repetitive nature of all these new cpus being added looks rather
> wooden. I think it would be better to merge them into one change block,
> that lists all the cpus and their internal names, then mentions once at
>
On 13/02/15 09:52, Kyrill Tkachov wrote:
> Hi all,
>
> This patch to changes.html mentions the xgene1 support in GCC 5 for arm
> and aarch64 and also the FreeBSD support for ARM.
>
> Is this ok?
The repetitive nature of all these new cpus being added looks rather
wooden. I think it would be bet
> On Feb 13, 2015, at 1:48 AM, Kyrill Tkachov wrote:
>
> Hi all,
>
> In my tree added a pattern to the arm backend that's supposed to match:
> (set (reg:SI r0)
> (subreg:SI
> (plus:DI
> (mult:DI (sign_extend:DI (reg:SI r1))
> (sign_extend:DI (reg:SI r2)))
>
Hi all,
This is a backport for gcc-4_9-branch of the patch " [PATCH][ARM]
__ARM_FP & __ARM_NEON_FP defined when -march=armv7-m" posted in:
https://gcc.gnu.org/ml/gcc-patches/2014-12/msg00250.html
arm-none-linux-gnueabi/hf tested without any new regressions.
OK for gcc-4_9-branch?
gcc/Change
Hi all,
This patch to changes.html mentions the xgene1 support in GCC 5 for arm
and aarch64 and also the FreeBSD support for ARM.
Is this ok?
I added the FreeBSD part in the Operating Systems section similar to
Dragonfly BSD.
Thanks,
KyrillIndex: htdocs/gcc-5/changes.html
==
Hi all,
In my tree added a pattern to the arm backend that's supposed to match:
(set (reg:SI r0)
(subreg:SI
(plus:DI
(mult:DI (sign_extend:DI (reg:SI r1))
(sign_extend:DI (reg:SI r2)))
(const_int 2147483648 [0x8000])) 4))
That is, take two SImode
Hi,
For the specific case reported in PR62173, overflow check on SCEV can be
improved using range information. Precisely, it's range information of ssa
name in IV's base that helps, rather than range information of the IV
itself. Since the IV is computed in the form of "IV_var = " in loop header,
Hi,
When dealing with PR62173, we found places in which overflow check on SCEVs
can be improved by range information. This patch addresses one of them.
Richard once suggested that we should trace range info all the way through
SCEV thus have it on CHREC structure. But as far as IVOPTs is concerne
> From: Alan Modra [mailto:amo...@gmail.com]
> Sent: Thursday, February 12, 2015 4:35 PM
> > >
> > >Actually this bit seems unnecessary as there is already some logic in
> > >nonzero_bits1 for the CONST_INT case. So I guess the code can be
> > >removed and the comment be moved there at the very lea
On 08/02/15 15:20, Christophe Lyon wrote:
On 3 February 2015 at 17:29, Richard Earnshaw wrote:
On 06/01/15 09:40, Mantas Mikaitis wrote:
Ping and changelog spaces removed.
Thank you,
Mantas M.
On 18/11/14 11:58, Richard Earnshaw wrote:
On 18/11/14 11:30, Mantas Mikaitis wrote:
Incorrect p
On Fri, Feb 13, 2015 at 10:21:42AM +0100, Richard Biener wrote:
> > I wonder if this won't pessimize const functions that just get called with
> > aggregate arguments passed by value, do those count as memory read or
> > just as parameters?
>
> They count as memory reads and thus cause a VUSE (sim
On Fri, Feb 13, 2015 at 9:54 AM, Jakub Jelinek wrote:
> On Fri, Feb 13, 2015 at 09:47:56AM +0100, Richard Biener wrote:
>> > 2015-02-12 Ilya Enkovich
>> >
>> > PR tree-optimization/65002
>> > * tree-cfg.c (pass_data_fixup_cfg): Don't update
>> > SSA on start.
>> >
2015-02-13 11:54 GMT+03:00 Jakub Jelinek :
> On Fri, Feb 13, 2015 at 09:47:56AM +0100, Richard Biener wrote:
>> > 2015-02-12 Ilya Enkovich
>> >
>> > PR tree-optimization/65002
>> > * tree-cfg.c (pass_data_fixup_cfg): Don't update
>> > SSA on start.
>> > * tree-sra
On Fri, Feb 13, 2015 at 12:23 AM, Jeff Law wrote:
> On 02/12/15 06:02, Richard Biener wrote:
>
>>>
>>> No strong opinion on separate pattern or integrating into existing
>>> pattern.
>>
>>
>> Yeah, I'd leave it as you did it for now. Btw, -ENOPATCH.
>
> This version should address all your commen
Segher Boessenkool writes:
> On Thu, Feb 12, 2015 at 03:54:21PM +, Richard Sandiford wrote:
>> "Hale Wang" writes:
>> > Ping?
>
> It's not a regression (or is it?), so it is not appropriate for stage4.
>
>
>> >> diff --git a/gcc/combine.c b/gcc/combine.c index 5c763b4..6901ac2 100644
>> >> --
On Fri, Feb 13, 2015 at 09:47:56AM +0100, Richard Biener wrote:
> > 2015-02-12 Ilya Enkovich
> >
> > PR tree-optimization/65002
> > * tree-cfg.c (pass_data_fixup_cfg): Don't update
> > SSA on start.
> > * tree-sra.c (some_callers_have_no_vuse_p): New.
> >
On Thu, Feb 12, 2015 at 3:14 PM, Ilya Enkovich wrote:
> Hi,
>
> PR65002 is the second issue caused by SRA for functions wrongly marked as
> read-only. Previous fix for PR64353 doesn't work for this case because SSA
> update happens too late. Here is a patch to disable SRA for such functions
>
72 matches
Mail list logo
