Il 19/11/2012 05:35, H.J. Lu ha scritto:
> On Sun, Nov 18, 2012 at 7:28 AM, Paolo Bonzini wrote:
>> Il 18/11/2012 00:54, H.J. Lu ha scritto:
>>> +@if gcc-bootstrap
>>> +ifneq ($(filter bootstrap-asan,$(BUILD_CONFIG)),)
>>> +LIBASAN_LIBS=-B$$r/prev-$(TARGET_SUBDIR)/libsanitizer/asan/.libs
>>> +endi
On Sun, Nov 18, 2012 at 09:07:07PM -0800, H.J. Lu wrote:
> This patch adds explicit -I for libstdc++-v3 header files when building
> libsanitizer so that it can be used for bootstrapping GCC. Othewise,
> -funconfigured-libstcd++-v3 will be used to compile multilib
> libsanitizer. OK to install?
Upstream change
http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/sanitizer_common/sanitizer_linux.cc?r1=168301&r2=168300&pathrev=168301
hopefully fixes the SPARC build.
We need to resolve http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55376
before we can automatically pull the fresh version
Hi!
On Sat, Nov 17, 2012 at 12:27:51PM -0500, Jason Merrill wrote:
> I suppose these changes are fine, but it might be more future-proof
> to compile with -fno-threadsafe-statics...or fix the build system so
Yeah, -fno-threadsafe-statitics might be a good idea, at least until/if ever
somebody sta
> Does -faddress-sanitizer add a CPP symbol that lets you work around it?
> If not, it's a bug. If so, please make libcpp revert to the dump
> algorithm if said symbol is defined.
Do you mean, does asan compilation cause some special preprocessor
symbol to be defined?
No, asan compilation does
On Sat, Nov 17, 2012 at 3:08 AM, Peter Bergner wrote:
> Attached below is an initial port of ASAN to powerpc*-linux.
> With the patch below along with Jakub's ASAN testsuite patch:
>
> http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01365.html
>
> ASAN not only builds, but seems to be working. The
> Unfortunately, it causes regressions; read on for a very brief
> analysis.
>
> For x86_64-linux (base multilib):
>
> Running
> /home/hp/gcctop/tmp/pr55030-2n/gcc/gcc/testsuite/gcc.dg/guality/guality.exp
> ... ...
> FAIL: gcc.dg/guality/pr36728-1.c -O1 line 12 arg7 == 30
> [...]
>
> I looked i
On Mon, Nov 19, 2012 at 12:15 AM, Dominique Dhumieres wrote:
>> I think this should fix it. Can't test it right now, so help
>> appreciated (Honza: hint hint! ;-)
>
> The change at
> http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01511/remove_dead_eq_notes.diff
> (revision 192526) caused
>
> http://
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of James Greenhalgh
> Sent: 12 November 2012 12:00
> To: gcc-patches@gcc.gnu.org
> Cc: Marcus Shawcroft
> Subject: Re: [PATCH] [AArch64] Refactor Advanced SIMD builtin
> initialisa
Hello guys,
I've checked that in:
http://gcc.gnu.org/ml/gcc-cvs/2012-11/msg00565.html with tiny obvious
fix
Thanks a lot for your inputs and comments!
Thanks, K
On Sat, Nov 17, 2012 at 10:50 PM, Richard Henderson wrote:
> On 11/15/2012 05:50 AM, Kirill Yukhin wrote:
>> Hi guys,
>> thanks for rev
> Yes, I'll be looking into this soon.
We have a related regression on SPARC:
FAIL: gfortran.dg/minmaxloc_5.f90 -O3 -fomit-frame-pointer -funroll-loops
execution test
FAIL: gfortran.dg/minmaxloc_5.f90 -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions execution test
FAIL: gfortr
Tom de Vries writes:
> On 21/09/12 03:40, Sandra Loosemore wrote:
>> Re:
>>
>>> I think tree-ssa-loop-ivopts is simply
>>> asking for the wrong thing, and needs to be changed. As I say,
>>> Sandra had some fixes in this area.
>>
>> This patch:
>>
>> http://gcc.gnu.org/ml/gcc-patches/2012-06/ms
Hi,
On Sat, Nov 17, 2012 at 03:54:41PM -0800, H.J. Lu wrote:
> Hi,
>
> This patch adds --with-build-config=bootstrap-asan support. OK to
> install?
I suppose this should be also described in gcc/doc/install.texi?
Thanks,
Martin
>
> Thanks.
>
>
> H.J.
> ---
> 2012-11-17 H.J. Lu
>
>
On 16 November 2012 12:22, Bin Cheng wrote:
>
>
>> -Original Message-
>> From: Matthew Gretton-Dann [mailto:matthew.gretton-d...@linaro.org]
>> Sent: Friday, November 16, 2012 6:30 PM
>> To: Bin Cheng
>> Cc: gcc-patches@gcc.gnu.org
>> Subject: Re: [PATCH ARM]Define LOGICAL_OP_NON_SHORT_CIR
Selectively disable system header canonicalizations.
Backport trunk r193569. Adds command line and configure flags so that libcpp
system file header path canonicalization is conditional.
Trunk patch details: http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00459.html
Okay for google/integrate branc
Hi,
this is patch I will try to test once I have chance :)
t simply prevents unroller from analyzing loops when they are already too large.
* tree-ssa-loop-ivcanon.c (tree_estimate_loop_size): Add UPPER_BOUND
parameter.
(try_unroll_loop_completely) Update.
Index: tree-ssa-l
Hi,
On Fri, 16 Nov 2012, Andrew Pinski wrote:
> >> Ah, yes. This one was amusing. When we were drafting the proposal,
> >> Lawrence kept wondering what this NOP_EXPR thing is. I've been
> >> suffering this name for so long, that it no longer irritates me.
> >> Had it been named CAST_EXPR,
On Sun, Nov 18, 2012 at 10:50:53AM +, Richard Sandiford wrote:
> Tom de Vries writes:
> > 2012-11-17 Tom de Vries
> >
> > PR rtl-optimization/55315
> >
> > * rtlanal.c (nonzero_address_p): Don't assume a nonzero address plus a
> > const is a nonzero address.
> >
> > * gcc.ta
On 11/19/2012 03:14 AM, Jakub Jelinek wrote:
PR. The reason for my patch was solely that it is more costly to have local
statics. With -fno-threadsafe-statics it will be less costly than before,
still it is about an extra guard var and need to load it/test it before
every first use in the funct
When I implemented inheriting constructors, I thought that the wording
that said that base copy/move constructors are not inherited was a
wording problem, but discussion on the reflector indicates that it was
intended, so that wrapper classes act like strong typedefs rather than
drop-in replace
Hi,
the issue is that we accept a stray comma at the end of a member
declaration. The reason is very simple: toward the end of the
cp_parser_member_declaration main loop, we simply consume a comma token,
without checking that isn't immediately followed by a semi colon. Thus
the below, which p
OK.
Jason
On Mon, Nov 19, 2012 at 12:09 AM, Jakub Jelinek wrote:
> On Sun, Nov 18, 2012 at 09:07:07PM -0800, H.J. Lu wrote:
>> This patch adds explicit -I for libstdc++-v3 header files when building
>> libsanitizer so that it can be used for bootstrapping GCC. Othewise,
>> -funconfigured-libstcd++-v3 will
On Mon, 2012-11-19 at 15:02 +0400, Dmitry Vyukov wrote:
> I am on a conference today and tomorrow, so I will be able to
> review the patch on Wed. Where can I see the whole patch?
You can find the patch here:
http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01425.html
Peter
On Fri, Nov 16, 2012 at 05:08:06PM -0600, Peter Bergner wrote:
> One question that I have is that the toplev.c test for port support
> tests for !FRAME_GROWS_DOWNWARD. The rs6000 port has FRAME_GROWS_DOWNWARD
> defined as (flag_stack_protect != 0), so ASAN only works when we use
> -fstack-protecto
On Sun, Nov 18, 2012 at 10:18 PM, Ian Lance Taylor wrote:
> On Sun, Nov 18, 2012 at 5:14 PM, David Edelsohn wrote:
>>
>> The problem is AIX stdlib.h defines
>>
>> #define vec_free free
>
> Ouch.
>
>> I am not sure where
>>
>> #undef vec_free
>>
>> should be placed. In vec.h or system.h?
>
> I th
On Mon, 2012-11-19 at 15:29 +0100, Jakub Jelinek wrote:
> On Fri, Nov 16, 2012 at 05:08:06PM -0600, Peter Bergner wrote:
> > One question that I have is that the toplev.c test for port support
> > tests for !FRAME_GROWS_DOWNWARD. The rs6000 port has FRAME_GROWS_DOWNWARD
> > defined as (flag_stack_
On Mon, Nov 19, 2012 at 08:49:30AM -0600, Peter Bergner wrote:
> On Mon, 2012-11-19 at 15:29 +0100, Jakub Jelinek wrote:
> > On Fri, Nov 16, 2012 at 05:08:06PM -0600, Peter Bergner wrote:
> > > One question that I have is that the toplev.c test for port support
> > > tests for !FRAME_GROWS_DOWNWARD
On Mon, Nov 19, 2012 at 12:01 AM, Paolo Bonzini wrote:
> Il 19/11/2012 05:35, H.J. Lu ha scritto:
>> On Sun, Nov 18, 2012 at 7:28 AM, Paolo Bonzini wrote:
>>> Il 18/11/2012 00:54, H.J. Lu ha scritto:
+@if gcc-bootstrap
+ifneq ($(filter bootstrap-asan,$(BUILD_CONFIG)),)
+LIBASAN_LIB
On 19/11/12 14:00, Jakub Jelinek wrote:
> On Sun, Nov 18, 2012 at 10:50:53AM +, Richard Sandiford wrote:
>> Tom de Vries writes:
>>> 2012-11-17 Tom de Vries
>>>
>>> PR rtl-optimization/55315
>>>
>>> * rtlanal.c (nonzero_address_p): Don't assume a nonzero address plus a
>>> const
On Wed, 14 Nov 2012, Andrew Hughes wrote:
>> --- status.html 1 Nov 2011 14:07:02 - 1.31
>> +++ status.html 1 Nov 2012 22:16:48 -
>> -You can also see http://www.kaffe.org/~stuart/japi/";>a
>> -comparison of libgcj with the JDK. This is updated nightly. It
>> -is run agains
On Mon, Nov 19, 2012 at 6:49 PM, Peter Bergner wrote:
> On Mon, 2012-11-19 at 15:29 +0100, Jakub Jelinek wrote:
>> On Fri, Nov 16, 2012 at 05:08:06PM -0600, Peter Bergner wrote:
>> > One question that I have is that the toplev.c test for port support
>> > tests for !FRAME_GROWS_DOWNWARD. The rs60
On Mon, Nov 19, 2012 at 07:28:18PM +0400, Konstantin Serebryany wrote:
> On Mon, Nov 19, 2012 at 6:49 PM, Peter Bergner wrote:
> > On Mon, 2012-11-19 at 15:29 +0100, Jakub Jelinek wrote:
> >> On Fri, Nov 16, 2012 at 05:08:06PM -0600, Peter Bergner wrote:
> >> > One question that I have is that the
Hi,
On Mon, 19 Nov 2012, Steven Bosscher wrote:
> On Mon, Nov 19, 2012 at 2:10 PM, Michael Matz wrote:
> > Hi,
> >
> > On Fri, 16 Nov 2012, Andrew Pinski wrote:
> >
> >> >> Ah, yes. This one was amusing. When we were drafting the proposal,
> >> >> Lawrence kept wondering what this NOP_EXPR thin
On Mon, 12 Nov 2012, Tobias Burnus wrote:
> Well, "flag" is GCC teminology (see "man gcc"), though it seems to be
> only used for the -f* options while I (mis)used it here for -W*. I
> think it is better to use the more common term "command-line option".
Okay, so I went ahead and applied the patc
Gerald Pfeifer wrote:
There is one sentence (preceding my patch) which I don't quite
understand (specifically around the "to"):
"...which diagnose when code to is inserted for automatic
(re)allocation of a variable during assignment."
Let me try to explain what the warning does and what
libgo-fix-arm.diff: Work around parse error of struct timex_ on ARM (both trunk
and 4.7 branch).
libgo-hardening.diff: Avoid compiler warnings in libgo with -D_FORTIFY_SOURCE=2,
which let the build fail with -Werror. first chunk for the trunk and 4.7, second
chunk for trunk only.
libgo-mksysinfo.
In PR 53764 Roland Stigge points out a typo in an error message in the
Go frontend. This patch fixes it. Bootstrapped on
x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r 30a5084faeb6 go/parse.cc
--- a/go/parse.cc Sun Nov 18 21:33:28 2012 -0800
+++ b/go/parse.cc Mon Nov 19 08:25:46
Hi Diego,
2012-11-15 Diego Novillo
Adjust for new vec API (http://gcc.gnu.org/wiki/cxx-conversion/cxx-vec)
* config/rx/rx.c: Use new vec API in vec.h.
This is fine.
Cheers
Nick
On 2012-11-18 23:53, Jakub Jelinek wrote:
> I'd prefer to only invalidate the stack pointer on the first assignment
> to the hard pointer. If the cselib link between sp and hfp is already
> broken, invalidating sp will only result in worse code. Dunno if there
> are any targets that adjust the ha
a x32 multilib libatomic build on x86-linux-gnu currently fails, because it
tries to build with -march=i486. This patch handles -mx32 like -m64. Ok for the
trunk?
Matthias
2012-11-19 Matthias Klose
* configure.tgt (i[3456]86): Handle -mx32 like -m64.
--- libatomic/configure.tgt~ 2012-11-0
On 16 Nov 2012, at 16:20, James Greenhalgh wrote:
> <0001-Patch-AArch64-Refactor-thunks-code-generation.patch>
OK
Hi all,
This patch updates the arm_abssi2 and arm_neg_abssi2 patterns in the ARM
machine description.
We define the predicable attribute based on the alternative. When the
patterns were introduced it was not possible to do that.
Now the second alternative in each of the patterns that supports predi
On 11/19/12 17:51, Kyrylo Tkachov wrote:
Hi all,
This patch updates the arm_abssi2 and arm_neg_abssi2 patterns in the ARM
machine description.
We define the predicable attribute based on the alternative. When the
patterns were introduced it was not possible to do that.
Now the second alternative
Mans pointed our in the PR that the change to not save VRSAVE register
affected saving of callee saved registers. This patch partially
reverts the earlier patch so vrsave_mask is computed, but VRSAVE is
not written and not saved unless TARGET_ALTIVEC_VRSAVE is set.
Committed.
- David
2012-11-19
Hi,
This patch is to change -faddress-sanitizer to -fsanitize=address. Ok for trunk?
2012-11-19 Wei Mi
* cfgexpand.c (partition_stack_vars): Change flag_asan to
flag_sanitize.
(expand_stack_vars): Likewise.
(defer_stack_allocation): Likewise.
(expand_us
Recently g++ comparisons of the full log files stopped working as well as they
used to, as sort is locale aware. This defeats some of the new fangled magic
that breaks comparisons.
* compare_tests (Usage): Add export LC_ALL=C to make sort happier.
Index: compare_tests
=
On Mon, Nov 19, 2012 at 10:14:21AM -0800, Wei Mi wrote:
> This patch is to change -faddress-sanitizer to -fsanitize=address. Ok for
> trunk?
Ok, thanks.
> 2012-11-19 Wei Mi
>
> * cfgexpand.c (partition_stack_vars): Change flag_asan to
> flag_sanitize.
> (expand_stack_
FYI
Clang also supports the no- form (-fno-sanitize=address).
We probably want it here too, but preferably as a separate patch.
(or is it automatically implemented via some internal magic?)
--kcc
On Mon, Nov 19, 2012 at 10:14 PM, Wei Mi wrote:
> Hi,
>
> This patch is to change -faddress-sanitize
On 16 Nov 2012, at 16:03, James Greenhalgh wrote:
> <0001-Patch-AArch64-Implementent-sync-gen-and-atomic-built.patch>
OK, and back port to ARM/aarch64-4.7-branch please.
/Marcus
Questions: are -fsanitize=thread -fsanitize=address mutually exclusive
here? If yes, that will be wrong.
How about -fsanitize=all option?
As kcc mentioned, the -fno-.. form is not handled.
David
On Mon, Nov 19, 2012 at 10:14 AM, Wei Mi wrote:
> Hi,
>
> This patch is to change -faddress-saniti
On 12 Nov 2012, at 11:59, James Greenhalgh wrote:
> <0001-Patch-AArch64-Refactor-Advanced-SIMD-builtin-initial.patch>
OK
/Marcus
On 16 Nov 2012, at 18:52, Ian Bolton wrote:
> This patch implements the standard pattern bswaphi2 for AArch64.
>
> Regression tests all pass.
>
> OK for trunk and backport to arm/aarch64-4.7-branch?
OK
/Marcus
Dear all,
attached is a first draft for -faddress-sanitizer in the release notes.
I am aware that some changes are imminent,* but I want make a start.
Comments?
Tobias
* For instance:
- PowerPC/PowerPC64 Linux support
- Renaming to -fsanitizer=address
- Addition of -fsanitizer=thread
- libsani
This looks like a memory leak.
OK for trunk?
commit ca98b795aa229e3c277d6f0475bd30c16a5a9a8c
Author: Aldy Hernandez
Date: Mon Nov 19 12:53:03 2012 -0600
* trans-mem.c (execute_tm_mark): Release bb_regions.
diff --git a/gcc/trans-mem.c b/gcc/trans-mem.c
index 15c02bd..79be8b9 10064
5 of them fail on Solaris 9 and 10 because they require __cxa_atexit to pass.
And 4 others fail on Solaris 9 only because of a TLS initialization failure.
Adjusted thus, tested on SPARC/Solaris 9, SPARC/Solaris 10 and x86-64/Linux,
applied on the mainline.
2012-11-19 Eric Botcazou
On Mon, Nov 19, 2012 at 10:26:26PM +0400, Konstantin Serebryany wrote:
> FYI
> Clang also supports the no- form (-fno-sanitize=address).
> We probably want it here too, but preferably as a separate patch.
> (or is it automatically implemented via some internal magic?)
So, how does it work in clang
On Mon, Nov 19, 2012 at 10:57 AM, Jakub Jelinek wrote:
> On Mon, Nov 19, 2012 at 10:26:26PM +0400, Konstantin Serebryany wrote:
>> FYI
>> Clang also supports the no- form (-fno-sanitize=address).
>> We probably want it here too, but preferably as a separate patch.
>> (or is it automatically implem
On Tue, Nov 13, 2012 at 10:59 PM, Uros Bizjak wrote:
> On Tue, Nov 13, 2012 at 7:23 PM, H.J. Lu wrote:
>
> Since x32 runs in 64-bit mode, for address -0x4300(%rax),
> hardware
> sign-extends displacement from 32-bits to 64-bits and adds it to
> %rax.
I cannot remove RejectNegative and use -fno-sanitize=address, or else
I will break an assertion (opts-common.c:614). The assertion requires
-fxxx=var options set RejectNegative if var is of enumerater type. I
see that all the other -fxxx=xxx options in common.opt set
RejectNegative.
Is it ok for
On Mon, Nov 19, 2012 at 11:21:27AM -0800, Wei Mi wrote:
> I cannot remove RejectNegative and use -fno-sanitize=address, or else
> I will break an assertion (opts-common.c:614). The assertion requires
> -fxxx=var options set RejectNegative if var is of enumerater type. I
> see that all the other -
e should not be using offsetof
> with non-PODs.
>
> Thanks,
> Andrew Pinski
The changes to tree-data-ref.c have broken the bootstrap on
x86_64-apple-darwin11/12
using the Apple clang 4.1 compiler...
clang++ -c -g -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W
On Fri, 2012-11-16 at 15:47 -0800, Konstantin Serebryany wrote:
> On Fri, Nov 16, 2012 at 3:08 PM, Peter Bergner wrote:
> > The lone ASAN
> > test case does fail, but it seems to be related to us using
> > _Unwind_Backtrace() and we end up with two extra frames at the
> > bottom of our stack frame
ki
>
> The changes to tree-data-ref.c have broken the bootstrap on
> x86_64-apple-darwin11/12
> using the Apple clang 4.1 compiler...
>
> clang++ -c -g -DIN_GCC -fno-exceptions -fno-rtti
> -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
> -Wcast-qual
On Mon, Nov 19, 2012 at 12:24 PM, Eric Botcazou wrote:
>> Yes, I'll be looking into this soon.
>
> We have a related regression on SPARC:
>
> FAIL: gfortran.dg/minmaxloc_5.f90 -O3 -fomit-frame-pointer -funroll-loops
> execution test
> FAIL: gfortran.dg/minmaxloc_5.f90 -O3 -fomit-frame-pointer -f
On Mon, Nov 19, 2012 at 4:06 PM, H.J. Lu wrote:
> On Mon, Nov 19, 2012 at 12:01 AM, Paolo Bonzini wrote:
>> Il 19/11/2012 05:35, H.J. Lu ha scritto:
>>> On Sun, Nov 18, 2012 at 7:28 AM, Paolo Bonzini wrote:
Il 18/11/2012 00:54, H.J. Lu ha scritto:
> +@if gcc-bootstrap
> +ifneq ($(fi
Hi all,
here is another contribution in trying to reduce the still too large
number of regressions in the Fortran front end (which used to be
basically zero for some time in the past).
The attached patch is rather straightforward and fixes a bogus
unused-variable warning. I would be grateful for
On Mon, Nov 19, 2012 at 08:56:22AM -0800, Richard Henderson wrote:
> On 2012-11-18 23:53, Jakub Jelinek wrote:
> > I'd prefer to only invalidate the stack pointer on the first assignment
> > to the hard pointer. If the cselib link between sp and hfp is already
> > broken, invalidating sp will only
Hi!
The GCC_4.8.0 symver is used in several *.ver files now, but without
%inherit for it the version script maker does the wrong thing, e.g.
puts two local: *; lines into the version script.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
2012-11-19 Jakub Jeli
Hi!
As the following testcase (with disabled LRA) shows, cross-jumping
sometimes leads into dwarf2cfi ICEs, because traps or even arbitrary insns
followed by __builtin_unreachable () with different args size depth can be
cross-jumped together.
Fixed by emitting REG_ARGS_SIZE notes on traps, and f
On Mon, Nov 19, 2012 at 12:34 PM, Paolo Bonzini wrote:
> On Mon, Nov 19, 2012 at 4:06 PM, H.J. Lu wrote:
>> On Mon, Nov 19, 2012 at 12:01 AM, Paolo Bonzini wrote:
>>> Il 19/11/2012 05:35, H.J. Lu ha scritto:
On Sun, Nov 18, 2012 at 7:28 AM, Paolo Bonzini wrote:
> Il 18/11/2012 00:54, H
On Mon, Nov 19, 2012 at 9:34 PM, Steven Bosscher wrote:
> On Mon, Nov 19, 2012 at 12:24 PM, Eric Botcazou wrote:
>>> Yes, I'll be looking into this soon.
>>
>> We have a related regression on SPARC:
>>
>> FAIL: gfortran.dg/minmaxloc_5.f90 -O3 -fomit-frame-pointer -funroll-loops
>> execution test
>
> Thanks for this reduced test case, that's saving me a lot of work!
You're welcome.
> Can you please try and see if the following C test case also fails?
Yup, with the same compilation options, there are the same dreadful lines
ld [%g0+0], %fn
in the assembly file, which translat
* include/bits/hashtable.h: Improve comments.
* include/bits/hashtable_policy.h: Likewise.
Tested x86_64-linux, committed to trunk.
commit 4855142e5e3273ccd197273027116ea12ebe663c
Author: Jonathan Wakely
Date: Mon Nov 19 20:50:01 2012 +
* include/bits/hashtable.h: I
On 11/19/2012 12:39 PM, Jakub Jelinek wrote:
> + if (reload_completed
> + && frame_pointer_needed
> + && RTX_FRAME_RELATED_P (insn)
> + && fp_setter_insn (insn))
> +cselib_invalidate_rtx (stack_pointer_rtx);
...
> if (fp_cfa_offset != -1
> &&
On 11/19/2012 12:46 PM, Jakub Jelinek wrote:
> 2012-11-19 Jakub Jelinek
>
> PR middle-end/55094
> * builtins.c (expand_builtin_trap): Add REG_ARGS_SIZE note
> on the trap insn for !ACCUMULATE_OUTGOING_ARGS.
> * cfgcleanup.c (outgoing_edges_match): Don't look at debug ins
On Mon, Nov 19, 2012 at 01:42:06PM -0800, Richard Henderson wrote:
> On 11/19/2012 12:39 PM, Jakub Jelinek wrote:
> > + if (reload_completed
> > + && frame_pointer_needed
> > + && RTX_FRAME_RELATED_P (insn)
> > + && fp_setter_insn (insn))
> > +cselib_invalidate_rtx (stack_pointe
> The root cause is the bad REG_EQUAL note. I think the most robust
> solution is to make the webizer re-compute notes before renaming.
> Patch for that is attached.
Thanks for the analysis. However...
> Ciao!
> Steven
>
>
> PR rtl-optimization/55006
> * web.c (web_main): Add t
On 11/19/2012 01:45 PM, Jakub Jelinek wrote:
> Ah, forgot to remove it in the callers. Will do. Is it ok with that change?
Yes.
r~
On Mon, Nov 19, 2012 at 10:50 PM, Eric Botcazou wrote:
>> The root cause is the bad REG_EQUAL note. I think the most robust
>> solution is to make the webizer re-compute notes before renaming.
>> Patch for that is attached.
>
> Thanks for the analysis. However...
>
>> Ciao!
>> Steven
>>
>>
>>
On 11/19/2012 10:54 AM, Aldy Hernandez wrote:
>* trans-mem.c (execute_tm_mark): Release bb_regions.
Ok.
r~
Hi,
the IA-64 has a red zone of 16 bytes at the bottom of the stack:
/* IA64 has a 16 byte scratch area that is at the bottom of the stack. */
#define STACK_POINTER_OFFSET 16
but doesn't maintain it for leaf functions:
/* We always use the 16-byte scratch area provided by the caller, but
* include/bits/stl_algo.h (reverse_copy): Update comment per DR 2074.
* include/bits/unordered_map.h: Apply DR 2005 resolution.
* doc/xml/manual/status_cxx2011.xml: Update per DR 2048.
* include/bits/allocator.h (allocator): Apply DR 2103 resolution.
* includ
A small improvement:
* testsuite/20_util/allocator/requirements/typedefs.cc: Check rebind
and improve propagate_on_container_move_assignment check.
Tested x86_64-linux, committed to trunk.
commit 9d600a18ed7750ca21232b766f8b90d295b8e2ec
Author: Jonathan Wakely
Date: Mon Nov 19
This patch uses the new working set information from the profile to select
the hot count threshold for an application instead of using a hard cutoff.
Currently the threshold is set by default to the minimum counter value
needed to reach 99.9% of the profiled execution time, but I have added
a param
> That could be done, yes. Cleaning up the REG_EQ* notes requires
> liveness at the insn level, so it'd require a bigger re-organization
> of the code. Perhaps adding a new pass (conditional on DF_EQ_NOTES)
> over all insn in df_lr_finalize, tracking liveness and calling
> df_remove_dead_eq_notes o
On Mon, Nov 19, 2012 at 11:42 PM, Eric Botcazou wrote:
>> That could be done, yes. Cleaning up the REG_EQ* notes requires
>> liveness at the insn level, so it'd require a bigger re-organization
>> of the code. Perhaps adding a new pass (conditional on DF_EQ_NOTES)
>> over all insn in df_lr_finalize
On Mon, 19 Nov 2012, Jakub Jelinek wrote:
> Hi!
>
> The GCC_4.8.0 symver is used in several *.ver files now, but without
> %inherit for it the version script maker does the wrong thing, e.g.
> puts two local: *; lines into the version script.
>
> Fixed thusly, bootstrapped/regtested on x86_64-li
This patch fixes PR 55359, which is an ICE caused by my removal
of a validate_subreg call in:
http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01353.html
The question then is whether the caller of simplify_(gen_)subreg is
responsible for checking whether a subreg is valid, or whether the
simplifi
This just adds the multiarch dirname for aarch64. ok for the trunk? There were
macro redefinitions before in aarch64-linux.h (STANDARD_STARTFILE_PREFIX_[12]).
I don't think these are necessary.
Thanks, Matthias
PS: ping on the patch for arm-linux-gnueabi multiarch.
--- config/aarch64/t-aarch6
On Mon, Nov 19, 2012 at 11:07:23PM +, Richard Sandiford wrote:
> PR middle-end/55359
> * simplify-rtx.c (simplify_subreg): Return null for invalid offsets.
>
> gcc/testsuite/
> * gcc.target/i386/pr55359.c: New test.
Ok, thanks.
Jakub
I am working on support for a future processor, and I noticed that when I did
the power7 work initially in 2009, that I ordered the DF moves so that the VSX
moves came before traditional floating point moves.
If reload needs to reload a floating point register, it will match first on the
VSX instr
On Tue, 20 Nov 2012, Matthias Klose wrote:
> This just adds the multiarch dirname for aarch64. ok for the trunk? There
> were
> macro redefinitions before in aarch64-linux.h
> (STANDARD_STARTFILE_PREFIX_[12]).
> I don't think these are necessary.
Don't you need to allow for big-endian, and us
I looks like there were a couple
#ifdef __GXX_EXPERIMENTAL_CXX0X__
in the patch. I think you want to change these to
#if __cplusplus >= 201103L
?
Regards,
Ed
On 19 November 2012 23:43, wrote:
> I looks like there were a couple
> #ifdef __GXX_EXPERIMENTAL_CXX0X__
> in the patch. I think you want to change these to
> #if __cplusplus >= 201103L
>
> ?
Oops, I thought I'd updated them all. I'll fix it, thanks.
On Mon, Nov 19, 2012 at 6:25 PM, Michael Meissner
wrote:
> I am working on support for a future processor, and I noticed that when I did
> the power7 work initially in 2009, that I ordered the DF moves so that the VSX
> moves came before traditional floating point moves.
>
> If reload needs to rel
On 19 November 2012 23:45, Jonathan Wakely wrote:
> On 19 November 2012 23:43, wrote:
>> I looks like there were a couple
>> #ifdef __GXX_EXPERIMENTAL_CXX0X__
>> in the patch. I think you want to change these to
>> #if __cplusplus >= 201103L
>>
>> ?
>
> Oops, I thought I'd updated them all. I'll
Am 20.11.2012 00:39, schrieb Joseph S. Myers:
> On Tue, 20 Nov 2012, Matthias Klose wrote:
>
>> This just adds the multiarch dirname for aarch64. ok for the trunk? There
>> were
>> macro redefinitions before in aarch64-linux.h
>> (STANDARD_STARTFILE_PREFIX_[12]).
>> I don't think these are nec
Ping, as Joseph Prostko is saying that this patch shall solve the same
problem he's facing.
> -Original Message-
> From: Joey Ye [mailto:joey...@arm.com]
> Sent: Friday, September 21, 2012 15:42
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH, libgcc] Make possible to disable JCR in crtstu
On Sun, 18 Nov 2012, Richard Sandiford wrote:
>HOST_WIDE_INT start = bitpos_ - (bitpos_ % unit);
>if (bitregion_start_ && start < bitregion_start_)
> break;
> - if (bitregion_end_ && start + unit > bitregion_end_ + 1)
> + if (start + unit > bitregion_end_ + 1)
This
1 - 100 of 113 matches
Mail list logo
