On Tue, Nov 20, 2012 at 10:20 AM, David Miller wrote:
> From: Konstantin Serebryany
> Date: Tue, 20 Nov 2012 09:34:14 +0400
>
>> On Tue, Nov 20, 2012 at 9:26 AM, David Miller wrote:
>>> From: Konstantin Serebryany
>>> Date: Tue, 20 Nov 2012 09:20:29 +0400
>>>
Please do (the same that was a
On Tue, Nov 20, 2012 at 12:04 AM, Peter Bergner wrote:
> 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
From: Konstantin Serebryany
Date: Tue, 20 Nov 2012 09:34:14 +0400
> On Tue, Nov 20, 2012 at 9:26 AM, David Miller wrote:
>> From: Konstantin Serebryany
>> Date: Tue, 20 Nov 2012 09:20:29 +0400
>>
>>> Please do (the same that was applied upstream).
>>
>> Which one was that?
> http://llvm.org/vie
On Tue, Nov 20, 2012 at 9:26 AM, David Miller wrote:
> From: Konstantin Serebryany
> Date: Tue, 20 Nov 2012 09:20:29 +0400
>
>> Please do (the same that was applied upstream).
>
> Which one was that?
http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/sanitizer_common/sanitizer_linux.cc?r1=
From: Konstantin Serebryany
Date: Tue, 20 Nov 2012 09:20:29 +0400
> Please do (the same that was applied upstream).
Which one was that?
> Please also note:
> - I am on vacation with random access to PC, that's why I did not
> want to rush with my first commits to gcc trunk.
This is actually
On Tue, Nov 20, 2012 at 9:16 AM, Xinliang David Li wrote:
> If that is a limitation, the compiler should give a warning about it
> instead of making them silently suppress each other. Think about some
> other sanitizer options that can co-exist with asan or tsan in the
> future.
Yes, that's what
On Tue, Nov 20, 2012 at 9:16 AM, David Miller wrote:
>
> I don't think it's reasonable that the sparc bootstrap is still broken
> in the tree, even though a fix has existed for nearly a week.
>
> It is not acceptable to say "everyone has to apply a special patch
> until some external dependency th
> -Original Message-
> From: Matthew Gretton-Dann [mailto:matthew.gretton-d...@linaro.org]
> Sent: Monday, November 19, 2012 8:20 PM
> To: Bin Cheng
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH ARM]Define LOGICAL_OP_NON_SHORT_CIRCUIT for ARM target
>
> On 16 November 2012 12:22, B
If that is a limitation, the compiler should give a warning about it
instead of making them silently suppress each other. Think about some
other sanitizer options that can co-exist with asan or tsan in the
future.
David
On Mon, Nov 19, 2012 at 9:07 PM, Konstantin Serebryany
wrote:
> On Mon, Nov
I don't think it's reasonable that the sparc bootstrap is still broken
in the tree, even though a fix has existed for nearly a week.
It is not acceptable to say "everyone has to apply a special patch
until some external dependency that will take an unknown, variable,
length of time to resolve is
On Mon, Nov 19, 2012 at 11:21 PM, 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 -fxxx=xx
On Mon, Nov 19, 2012 at 10:31 PM, Xinliang David Li wrote:
> Questions: are -fsanitize=thread -fsanitize=address mutually exclusive
> here? If yes, that will be wrong.
>
> How about -fsanitize=all option?
asan and tsan can not coexist in the same process.
Until recently, using both flags with cla
On Mon, Nov 19, 2012 at 10:44 PM, Tobias Burnus wrote:
> 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?
stack overflow is something different, I guess we want to say "stack
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
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
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
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
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: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.
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 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 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 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
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
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
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
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
> 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
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
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
* 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
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
On 11/19/2012 10:54 AM, Aldy Hernandez wrote:
>* trans-mem.c (execute_tm_mark): Release bb_regions.
Ok.
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 01:45 PM, Jakub Jelinek wrote:
> Ah, forgot to remove it in the callers. Will do. Is it ok with that change?
Yes.
r~
> 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 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
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 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
> &&
* 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
> 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
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
>
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
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
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
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 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 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
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
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 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
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 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 -
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 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.
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 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
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
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
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
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
On 12 Nov 2012, at 11:59, James Greenhalgh wrote:
> <0001-Patch-AArch64-Refactor-Advanced-SIMD-builtin-initial.patch>
OK
/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 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
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 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_
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
=
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
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
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
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 16 Nov 2012, at 16:20, James Greenhalgh wrote:
> <0001-Patch-AArch64-Refactor-thunks-code-generation.patch>
OK
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 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
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
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
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.
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
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
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, 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
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 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 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 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 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, 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 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 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 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 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
OK.
Jason
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
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
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
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
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,
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
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
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
1 - 100 of 113 matches
Mail list logo
