On Sun, Feb 15, 2015 at 9:53 PM, H.J. Lu wrote:
> Hi,
>
> This is a backport of the patch for PR middle-end/53623 plus all bug
> fixes caused by it. Tested on Linux/x86-32, Linux/x86-64 and x32. OK
> for 4.8 branch?
Ok if nobody objects within 24h (you changed the bug to wrong-code
which is why
On Sun, Feb 15, 2015 at 12:53:39PM -0800, H.J. Lu wrote:
> This is a backport of the patch for PR middle-end/53623 plus all bug
> fixes caused by it. Tested on Linux/x86-32, Linux/x86-64 and x32. OK
> for 4.8 branch?
What about PR64286 and PR63659, are you sure those aren't related?
I mean, they
> From: Joseph Myers
> ...
> > +@table @gcctabopt
> > +
> > +@item -mspace
> > +@opindex mspace
> > +Enable code-size optimizations.
> > +Some of these optimizations incur a minor performance penalty.
>
> We already have -Os, so why is an architecture-specific option for this
> needed?
>
> > +A 1
2015-02-15 20:25 GMT+03:00 Mike Stump :
> On Feb 13, 2015, at 11:25 AM, Jakub Jelinek wrote:
2015-02-12 Ilya Enkovich
PR tree-optimization/65002
* gcc.dg/pr65002.C: New.
>>>
>>> This test should have gone into g++.dg.
>>
>> Into g++.dg/opt or g++.dg/ipa in particular
Hi,
The RTL cprop pass in GCC operates by doing a local constant/copy propagation
first and then a global one. In the local one, if a constant cannot be
propagated (eg. due to constraints of the destination instruction) a copy
propagation is done instead. However, at the global level copy propa
On Mon, 16 Feb 2015, Thomas Preud'homme wrote:
> Hi,
>
> The RTL cprop pass in GCC operates by doing a local constant/copy
> propagation first and then a global one. In the local one, if a constant
> cannot be propagated (eg. due to constraints of the destination
> instruction) a copy propagat
The CUR_PARAM can be null at this place, so check for that.
I had hoped that extra testing the original patch by running the C testsuite
with -Wformat=2 enabled would detect such a case, but apparently not. :(
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2015-02-16 Marek Polacek
On Mon, Feb 16, 2015 at 12:05:06PM +0100, Marek Polacek wrote:
> The CUR_PARAM can be null at this place, so check for that.
>
> I had hoped that extra testing the original patch by running the C testsuite
> with -Wformat=2 enabled would detect such a case, but apparently not. :(
>
> Bootstrapped
Le 15/02/2015 19:00, Jerry DeLisle a écrit :
> On 02/15/2015 09:48 AM, Mikael Morin wrote:
>
>> [*] I have a few failing testcases (also without the patch), namely the
>> following; does this ring a bell ?
>> FAIL: gfortran.dg/erf_3.F90
>> FAIL: gfortran.dg/fmt_g0_7.f08
>> FAIL: gfortran.dg/fmt_en
On Mon, Feb 16, 2015 at 11:26 AM, Thomas Preud'homme
wrote:
> Hi,
>
> The RTL cprop pass in GCC operates by doing a local constant/copy propagation
> first and then a global one. In the local one, if a constant cannot be
> propagated (eg. due to constraints of the destination instruction) a copy
Hello.
This patch is fix which was attached by Honza to the PR. Patch was tested on
x86_64-linux-pc and no new
regression is introduced. Patch is pre-approved by Honza and I'm going to
install the patch.
Martin
>From cfe7bd6b57cc6e0768fd72d27a7b222ab1136b32 Mon Sep 17 00:00:00 2001
From: mlisk
On Mon, Feb 16, 2015 at 1:35 AM, Jakub Jelinek wrote:
> On Sun, Feb 15, 2015 at 12:53:39PM -0800, H.J. Lu wrote:
>> This is a backport of the patch for PR middle-end/53623 plus all bug
>> fixes caused by it. Tested on Linux/x86-32, Linux/x86-64 and x32. OK
>> for 4.8 branch?
>
> What about PR642
On Mon, Feb 16, 2015 at 4:30 AM, H.J. Lu wrote:
> On Mon, Feb 16, 2015 at 1:35 AM, Jakub Jelinek wrote:
>> On Sun, Feb 15, 2015 at 12:53:39PM -0800, H.J. Lu wrote:
>>> This is a backport of the patch for PR middle-end/53623 plus all bug
>>> fixes caused by it. Tested on Linux/x86-32, Linux/x86-6
On Mon, Feb 16, 2015 at 05:15:02AM -0800, H.J. Lu wrote:
> On Mon, Feb 16, 2015 at 4:30 AM, H.J. Lu wrote:
> > On Mon, Feb 16, 2015 at 1:35 AM, Jakub Jelinek wrote:
> >> On Sun, Feb 15, 2015 at 12:53:39PM -0800, H.J. Lu wrote:
> >>> This is a backport of the patch for PR middle-end/53623 plus all
On Mon, Feb 16, 2015 at 5:18 AM, Jakub Jelinek wrote:
> On Mon, Feb 16, 2015 at 05:15:02AM -0800, H.J. Lu wrote:
>> On Mon, Feb 16, 2015 at 4:30 AM, H.J. Lu wrote:
>> > On Mon, Feb 16, 2015 at 1:35 AM, Jakub Jelinek wrote:
>> >> On Sun, Feb 15, 2015 at 12:53:39PM -0800, H.J. Lu wrote:
>> >>> Thi
Hello!
> 2015-02-12 H.J. Lu
> Richard Henderson
>
> PR rtl/32219
> * cgraphunit.c (cgraph_node::finalize_function): Set definition
> before notice_global_symbol.
> (varpool_node::finalize_decl): Likewise.
> * varasm.c (default_binds_local_p_
On Mon, Feb 16, 2015 at 5:24 AM, H.J. Lu wrote:
> On Mon, Feb 16, 2015 at 5:18 AM, Jakub Jelinek wrote:
>> On Mon, Feb 16, 2015 at 05:15:02AM -0800, H.J. Lu wrote:
>>> On Mon, Feb 16, 2015 at 4:30 AM, H.J. Lu wrote:
>>> > On Mon, Feb 16, 2015 at 1:35 AM, Jakub Jelinek wrote:
>>> >> On Sun, Feb
On Mon, Feb 16, 2015 at 05:44:45AM -0800, H.J. Lu wrote:
> Should it be a concern for 4.8 backport? Should we also backport r215205:
Probably. But, please wait for Jeff Law's approval of all of this before
committing.
> commit b71346c449d2b4a63985a39c4c092ecdfb37b5a0
> Author: jiwang
> Date:
On Mon, Feb 16, 2015 at 5:25 AM, Uros Bizjak wrote:
> Hello!
>
>> 2015-02-12 H.J. Lu
>> Richard Henderson
>>
>> PR rtl/32219
>> * cgraphunit.c (cgraph_node::finalize_function): Set definition
>> before notice_global_symbol.
>> (varpool_node::finaliz
Predictive commoning happens to re-use SSA names it released while
there are still uses of them (oops), confusing the hell out of
other code (expected). Fixed thus.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
Richard.
2015-02-16 Richard Biener
PR tree-optimization/63
This fixes another leakage of random LTO temporary filenames into
executables, this time via .symtab FILE entries. Removing it
doesn't work (GNU ld adds it back) and is said to be incorrect.
So the following patch, similar to the dwarf CU DW_AT_name uses
.
Bootstrapped on x86_64-unknown-linux-gn
The following removes an optimization not considering FP values
to carry pointers from PTA. Instead to fix the underlying problem
in PR37021 this patch adds handling of the rest of handled_components_p.
Bootstrap and regtest in progress on x86_64-unknown-linux-gnu.
Richard.
2015-02-16 Richard
On Mon, Feb 02, 2015 at 13:10:19 +0100, Jakub Jelinek wrote:
> [...] Generally, the solution if something goes
> wrong during the offloading compilation should be just to give up on the
> offloading to the particular offloading target (i.e. fill in the sections
> libgomp reads in a way that will r
Hi,
This patch restricts usage of Pointer Bounds Checker with Sanitizer. OK for
trunk?
Thanks,
Ilya
--
gcc/
2015-02-16 Ilya Enkovich
PR target/65044
* toplev.c (process_options): Restrict Pointer Bounds Checker
usage with sanitizers.
gcc/testsuite/
2015-02-16 Ily
On Mon, Feb 16, 2015 at 6:25 AM, Richard Biener wrote:
>
> This fixes another leakage of random LTO temporary filenames into
> executables, this time via .symtab FILE entries. Removing it
> doesn't work (GNU ld adds it back) and is said to be incorrect.
FWIW, ld.bfd will be fixed in 2.26. But i
On Mon, Feb 16, 2015 at 06:20:59PM +0300, Ilya Enkovich wrote:
> This patch restricts usage of Pointer Bounds Checker with Sanitizer. OK for
> trunk?
There are many sanitizers, and for most of them I don't see why they would
be in any conflict with -mmpx, it is just -fsanitize=address and
-fsani
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 Swedish team of translators. The file is available at:
http://translationproject.org/latest/cpplib/sv.po
(This file, 'cpplib-5.1-b20150208
cpplib-5.1-b20150208.sv.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
On 16 Feb 16:31, Jakub Jelinek wrote:
> On Mon, Feb 16, 2015 at 06:20:59PM +0300, Ilya Enkovich wrote:
> > This patch restricts usage of Pointer Bounds Checker with Sanitizer. OK
> > for trunk?
>
> There are many sanitizers, and for most of them I don't see why they would
> be in any conflict wi
On Tue, Feb 3, 2015 at 5:37 AM, Iain Sandoe wrote:
> Hi Jonathan,
>
> On 1 Feb 2015, at 15:10, Jonathan Wakely wrote:
>
>> On 01/02/15 15:08 +, Jonathan Wakely wrote:
>>> I failed to CC gcc-patches on this patch ...
>>>
>>> On 29/01/15 13:02 +, Jonathan Wakely wrote:
Jakub pointed out
On Mon, Feb 16, 2015 at 06:56:45PM +0300, Ilya Enkovich wrote:
> On 16 Feb 16:31, Jakub Jelinek wrote:
> > On Mon, Feb 16, 2015 at 06:20:59PM +0300, Ilya Enkovich wrote:
> > > This patch restricts usage of Pointer Bounds Checker with Sanitizer. OK
> > > for trunk?
> >
> > There are many sanitize
On 03/02/15 10:37 +, Iain Sandoe wrote:
Hi Jonathan,
On 1 Feb 2015, at 15:10, Jonathan Wakely wrote:
On 01/02/15 15:08 +, Jonathan Wakely wrote:
I failed to CC gcc-patches on this patch ...
On 29/01/15 13:02 +, Jonathan Wakely wrote:
Jakub pointed out that we have some attribute
Hi,
Looking at https://gcc.gnu.org/install/specific.html , aarch64*-*-* is
in an odd place and isn't linked to from the top of the file.
This patch fixes that by reordering the entries and adding a link
from the menu at the top of the page.
I've built the documentation with no new issues, and h
On 02/16/2015 06:01 AM, H.J. Lu wrote:
> On Mon, Feb 16, 2015 at 5:25 AM, Uros Bizjak wrote:
>> Hello!
>>
>>> 2015-02-12 H.J. Lu
>>> Richard Henderson
>>>
>>> PR rtl/32219
>>> * cgraphunit.c (cgraph_node::finalize_function): Set definition
>>> before notice
On Mon, Feb 16, 2015 at 8:30 AM, Richard Henderson wrote:
> On 02/16/2015 06:01 AM, H.J. Lu wrote:
>> On Mon, Feb 16, 2015 at 5:25 AM, Uros Bizjak wrote:
>>> Hello!
>>>
2015-02-12 H.J. Lu
Richard Henderson
PR rtl/32219
* cgraphunit.c (cgra
On 02/14/2015 06:50 AM, John David Anglin wrote:
> Possibly the constant can somehow be forced into the data section where the
> relocations
> aren't a problem?
Hmm. It looks like we might already do that. See default_select_rtx_section.
r~
Hi!
If there are lambdas in C++11 constexpr return-stmts, we get implicit
typedefs of the lambda types, but those are artificial and we should ignore
them.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2015-02-16 Paolo Carlini
Jakub Jelinek
PR c++
Hi!
As discussed in the PR, in 4.9 we used to clone DECL_SECTION_NAME
through using copy_node on the FUNCTION_DECL, and only in selected places
(e.g. when creating artificial_thunk.*, or when creating virtual clones
of DECL_ONE_ONLY functions) we used to explicitly clear DECL_SECTION_NAME.
In 5 th
On 16 Feb 17:01, Jakub Jelinek wrote:
> On Mon, Feb 16, 2015 at 06:56:45PM +0300, Ilya Enkovich wrote:
> > On 16 Feb 16:31, Jakub Jelinek wrote:
> > > On Mon, Feb 16, 2015 at 06:20:59PM +0300, Ilya Enkovich wrote:
> > > > This patch restricts usage of Pointer Bounds Checker with Sanitizer.
> > >
On Mon, 16 Feb 2015, H.J. Lu wrote:
> On Mon, Feb 16, 2015 at 6:25 AM, Richard Biener wrote:
> >
> > This fixes another leakage of random LTO temporary filenames into
> > executables, this time via .symtab FILE entries. Removing it
> > doesn't work (GNU ld adds it back) and is said to be incorre
On Mon, 16 Feb 2015, James Bowman wrote:
> I have updated the target options. Space-saving is now enabled by
> -Os. There is also a new option -msim to enable building for the
> simulator (the simulator is pending submission to gdb-binutils).
The documentation in this patch doesn't seem to have b
Hi,
> Hi!
>
> As discussed in the PR, in 4.9 we used to clone DECL_SECTION_NAME
> through using copy_node on the FUNCTION_DECL, and only in selected places
> (e.g. when creating artificial_thunk.*, or when creating virtual clones
> of DECL_ONE_ONLY functions) we used to explicitly clear DECL_SECTI
This fixes the validation of the argument to the deviceptr clause.
Bootstrapped and regtested on x86_64-unknown-linux-gnu.
OK to commit to trunk?
Jim
diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index ceb9e1a..9f0d7af 100644
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -10334,11 +1033
On Mon, Feb 16, 2015 at 07:23:33PM +0100, Jan Hubicka wrote:
> > --- gcc/cgraphclones.c.jj 2015-01-09 21:59:44.0 +0100
> > +++ gcc/cgraphclones.c 2015-02-16 14:02:16.564725881 +0100
> > @@ -577,7 +577,7 @@ cgraph_node::create_virtual_clone (vec >char *name;
> >
> >if (!in_l
> On Mon, Feb 16, 2015 at 07:23:33PM +0100, Jan Hubicka wrote:
> > > --- gcc/cgraphclones.c.jj 2015-01-09 21:59:44.0 +0100
> > > +++ gcc/cgraphclones.c2015-02-16 14:02:16.564725881 +0100
> > > @@ -577,7 +577,7 @@ cgraph_node::create_virtual_clone (vec > >char *name;
> > >
> > >
On 2015-02-16, at 11:38 AM, Richard Henderson wrote:
>>
>> Possibly the constant can somehow be forced into the data section where the
>> relocations
>> aren't a problem?
>
> Hmm. It looks like we might already do that. See default_select_rtx_section.
Thanks, I see the problem. default_relo
On Thu, Jan 08, 2015 at 16:49:40 +0100, Jakub Jelinek wrote:
> BTW, today when looking at the TARGET_OPTION_NODE streaming caused
> regressions, I've discovered that it is very hard to debug issues in the
> offloading compiler. Would be nice if
> -save-temps -v
> printed enough information that it
On 02/13/15 23:12, Jack Howarth wrote:
This also breaks the bootstrap on x86_64-apple-darwin14 due to a
similar stage 2/3 comparison failure.
Thanks. I'm pretty sure I've got the root cause of both of these
failures. There's a gsi_last_bb in some existing code that really needs
to be changed
Good day,
I have been trying to reach you without success. Glad I could be able to get in
touch with you today. Kindly reply as soon as possible in order to get back to
you in regards to reason i have been trying to reach you.
Regards
Mr. David Nicodemus
Executive Director
Hi,
this patch fixes PR64980 and PR61960 at the same time.
The unreduced test case for PR64230 is also included, because a previous version
of this patch caused this test to fail but the complete test suite passed
without any
indication of any problem.
Boot-strapped and regression-tested on X8
again, with attachments,
sorry.
>
> Hi,
>
>
> this patch fixes PR64980 and PR61960 at the same time.
>
> The unreduced test case for PR64230 is also included, because a previous
> version
> of this patch caused this test to fail but the complete test suite passed
> without any
> indication of
On Mon, Feb 16, 2015 at 11:26 AM, Thomas Preud'homme wrote:
> /* Subroutine of cprop_insn that tries to propagate constants into
> @@ -1044,40 +1042,41 @@ cprop_insn (rtx_insn *insn)
> - /* Constant propagation. */
> - if (cprop_constant_p (src))
> - {
> - if (constprop
On 02/12/2015 11:27 AM, Jason Merrill wrote:
On 02/12/2015 01:04 PM, Aldy Hernandez wrote:
On 02/10/2015 02:52 AM, Richard Biener wrote:
On Fri, Feb 6, 2015 at 5:42 PM, Aldy Hernandez wrote:
Of course I wonder why you need to separate handling of functions and
variables
The variables need
The prior version of this patch failed to bootstrap with some
non-standard configure options on x86_64-unknown-linux-gnu. The problem
was existing code which looked for the last statement in a block. It
should have looked through non-debug insns which was a trivial change to
use gsi_last_no
Hi!
On Mon, Feb 09, 2015 at 11:20:00AM +0100, Richard Biener wrote:
> I think (also communicated that on IRC) we should instead try not streaming
> machine-modes at all but generating them at stream-in time via layout_type
> or layout_decl.
Here is a WIP prototype for being able to stream a machi
On Mon, Feb 16, 2015 at 02:00:32PM -0700, Jeff Law wrote:
> --- a/gcc/tree-vrp.c
> +++ b/gcc/tree-vrp.c
> @@ -10176,13 +10176,20 @@ identify_jump_threads (void)
>/* We only care about blocks ending in a COND_EXPR. While there
>may be some value in handling SWITCH_EXPR here, I doubt
On February 16, 2015 10:11:07 PM CET, Jakub Jelinek wrote:
>On Mon, Feb 16, 2015 at 02:00:32PM -0700, Jeff Law wrote:
>> --- a/gcc/tree-vrp.c
>> +++ b/gcc/tree-vrp.c
>> @@ -10176,13 +10176,20 @@ identify_jump_threads (void)
>>/* We only care about blocks ending in a COND_EXPR. While
>ther
On Mon, Feb 16, 2015 at 10:20:23PM +0100, Richard Biener wrote:
> On February 16, 2015 10:11:07 PM CET, Jakub Jelinek wrote:
> >On Mon, Feb 16, 2015 at 02:00:32PM -0700, Jeff Law wrote:
> >> --- a/gcc/tree-vrp.c
> >> +++ b/gcc/tree-vrp.c
> >> @@ -10176,13 +10176,20 @@ identify_jump_threads (void)
On February 16, 2015 10:08:12 PM CET, Jakub Jelinek wrote:
>Hi!
>
>On Mon, Feb 09, 2015 at 11:20:00AM +0100, Richard Biener wrote:
>> I think (also communicated that on IRC) we should instead try not
>streaming
>> machine-modes at all but generating them at stream-in time via
>layout_type
>> or la
On Mon, Feb 16, 2015 at 10:35:30PM +0100, Richard Biener wrote:
> Seeing the real format string you introduce I wonder if identifying modes
> by their names wouldn't work in 99% of all cases (apart from PSImode
> maybe).
There are various corner cases. Plus of course sometimes insignificant, but
Aha yes. Revised attached. invoke.texi now has:
These options are defined specifically for the FT32 port.
@table @gcctabopt
@item -msim
@opindex msim
Specifies that the program will be run on the simulator. This causes
an alternate runtime startup and library to be linked.
You must not use this
On 02/16/15 14:11, Jakub Jelinek wrote:
On Mon, Feb 16, 2015 at 02:00:32PM -0700, Jeff Law wrote:
--- a/gcc/tree-vrp.c
+++ b/gcc/tree-vrp.c
@@ -10176,13 +10176,20 @@ identify_jump_threads (void)
/* We only care about blocks ending in a COND_EXPR. While there
may be some value i
> From: Steven Bosscher [mailto:stevenb@gmail.com]
> Sent: Tuesday, February 17, 2015 4:19 AM
> To: Thomas Preud'homme
> Cc: GCC Patches; Richard Biener
> Subject: Re: [PATCH, GCC, stage1] Fallback to copy-prop if constant-prop
> not possible
>
> On Mon, Feb 16, 2015 at 11:26 AM, Thomas Preud'
OK.
Jason
On Sun, Feb 15, 2015 at 7:35 PM, Segher Boessenkool
wrote:
> Hi Terry,
>
> I still think this is stage1 material.
>
>> + /* Don't combine if dest contains a user specified register and i3
>> contains
>> + ASM_OPERANDS, because the user specified register (same with dest) in
>> i3
>> + w
On 02/14/15 04:23, Maxim Kuvyrkov wrote:
FYI, (and not related to the core issue of this patch)
The use of mult vs shift by combine is a problem that Venkat is
working on, see "[RFC] Tighten memory type assumption in RTL combiner
pass" . The combiner uses MULTs instead of SHIFTs for rtx'es tha
On 02/11/15 02:20, James Greenhalgh wrote:
On Mon, Feb 09, 2015 at 11:16:56PM +, Jeff Law wrote:
On 02/06/15 05:24, James Greenhalgh wrote:
---
2015-02-06 James Greenhalgh
* haifa-sched.c (recompute_todo_spec): After applying a
replacement and cancelling a dependency,
On 02/13/15 16:50, Sebastian Pop wrote:
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 t
Hi David,
Am 2015-02-14 um 22:05 schrieb David Edelsohn:
> Hi, Michael
>
> Thanks for noticing this. This patch generally seems to be on the
> right track. The original ASM_OUTPUT_EXTERNAL code was not completely
> correct in the pedantic sense. It should use [UA] mapping class
> instead of [R
69 matches
Mail list logo
