Hi,
On Thu, 5 Dec 2013 21:12:54, Jeff Law wrote:
>
> On 12/04/13 00:49, Bernd Edlinger wrote:
>>
>> Regarding the consistency of bitregion_start/end ,
>>
>> they should either both be zero, or
>>
>> bitregion_start <= bitpos && bitpos+bitsize-1 <= bitregion_end
> Presumably to satisfy the consecut
On Fri, Dec 6, 2013 at 11:50 AM, Jakub Jelinek wrote:
> Hi!
>
> With the new tsan tests, I've noticed that libbacktrace symbolization
> doesn't work when the binary is a PIE.
> The problem is that in that case we obviously can't use base_address
> of 0, the PIE typically will not have 0 bias, that
On Fri, Dec 06, 2013 at 12:19:45PM +0400, Dmitry Vyukov wrote:
> > And the reason why check-g++ tsan.exp fails even with this patch is
> > that apparently tsan doesn't try to demangle the symbol names, so we get
> > e.g.:
>
> Demangling must be done by the symbolizer.
> +samsonov for this
So why
On Thu, 5 Dec 2013, Jeff Law wrote:
> On 12/05/13 03:18, Richard Biener wrote:
> >
> > This fixes the issue in linux/vt.h that appears in SUSE SLE11 kernel
> > headers which contain a pre-release variant that is broken and not
> > compatible with C++ (using the 'new' keyword).
> >
> > The follow
Tom de Vries writes:
> On 27-04-13 12:01, Richard Sandiford wrote:
>> Tom de Vries writes:
>>> +/* { dg-do run } */
>>> +/* { dg-options "-fuse-caller-save -save-temps" } */
>>> +/* { dg-skip-if "" { *-*-* } { "*" } { "-Os" } } */
>>> +/* Testing -fuse-caller-save optimization option. */
>>> +
Hi,
On Thu, 5 Dec 2013 22:16:15, Jeff Law wrote:
>
> On 12/04/13 01:16, Bernd Edlinger wrote:
>
>>
>>> Looking for some more time your patch may be indeed the easiest
>>> without big re-factoring.
> Richard (or Bernd), can you comment on why? Something seems "off" here.
>
> Why do we need to hand
On Fri, Dec 6, 2013 at 12:25 PM, Jakub Jelinek wrote:
> On Fri, Dec 06, 2013 at 12:19:45PM +0400, Dmitry Vyukov wrote:
>> > And the reason why check-g++ tsan.exp fails even with this patch is
>> > that apparently tsan doesn't try to demangle the symbol names, so we get
>> > e.g.:
>>
>> Demangling
(now in plain-text mode).
ASan calls this function only for global variables (not functions). It
is needed because
we use a different machinery to pass global names to ASan runtime - we
register globals
by a call from instrumented code, which also tells runtime the
(mangled) global name.
OTOH, in
> one test case is this one:
>
> pr57748-3.c:
> /* PR middle-end/57748 */
> /* { dg-do run } */
> /* wrong code in expand_expr_real_1. */
>
> #include
>
> extern void abort (void);
>
> typedef long long V
> __attribute__ ((vector_size (2 * sizeof (long long)), may_alias));
>
> typedef stru
Il 06/12/2013 01:56, Tom de Vries ha scritto:
>>
>>
>> This patch series adds analysis of register usage of functions for
>> usage by IRA.
>> The original post is here
>> ( http://gcc.gnu.org/ml/gcc-patches/2013-01/msg01234.html ).
>>
>> This patch uses the information of which registers are clobbe
> Here's the Correct Fix(tm). We may or may not decide to go for it because
> of concerns about ABI changes; in the latter case, any kludge that we'll
> put in place instead must be restricted to the cases caught by this patch.
>
>
> * stor-layout.c (compute_record_mode): Return BLKmode fo
On Thu, 5 Dec 2013, Cong Hou wrote:
> Hi Richard
>
> You mentioned that Micha has a patch pending that enables of zero-step
> stores. What is the status of this patch? I could not find it through
> searching "Micha".
Well, it's pending on his harddisk :/ Too late for 4.9.
Richard.
> Thank you
On Thu, Dec 5, 2013 at 3:34 PM, Oleg Endo wrote:
> On Thu, 2013-12-05 at 14:56 +0100, Richard Biener wrote:
>> > but they are used somewhere else. I could replace the uses of those
>> > typedefs in a follow up patch, but for now I wanted to keep the changes
>> > minimal.
>>
>> I didn't mean those
On Thu, Dec 5, 2013 at 4:38 PM, Georg-Johann Lay wrote:
> Am 12/05/2013 04:09 PM, schrieb Richard Biener:
>
>> On Thu, Dec 5, 2013 at 3:53 PM, Georg-Johann Lay wrote:
>>>
>>> This is a fix of a wrong warning for a bas ISR name. The assumption was
>>> that if DECL_ASSEMBLER_NAME is set, it would a
On Fri, Dec 6, 2013 at 2:10 PM, Jeff Law wrote:
> On 11/26/13 03:52, Bin.Cheng wrote:
>>
>> On Tue, Nov 26, 2013 at 6:06 AM, Jeff Law wrote:
>>>
>>> On 11/25/13 02:11, Bin.Cheng wrote:
Slightly tune to make iv cand choosing algorithm more accurate:
http://gcc.gnu.org/ml/g
On Thu, Dec 5, 2013 at 10:05 PM, H.J. Lu wrote:
> On Thu, Dec 5, 2013 at 1:02 PM, Patrick Marlier
> wrote:
>> Hi,
>>
>>
>> On 12/05/2013 07:22 PM, H.J. Lu wrote:
>>>
>>> We'd like to add a new -mtune=ia option for x86 to optimize for both
>>> Haswell and Silvermont. Currently, -mtune=ia is alias
On Fri, Dec 06, 2013 at 10:38:27AM +0100, Richard Biener wrote:
> On Thu, Dec 5, 2013 at 10:05 PM, H.J. Lu wrote:
> > On Thu, Dec 5, 2013 at 1:02 PM, Patrick Marlier
> > wrote:
> >> On 12/05/2013 07:22 PM, H.J. Lu wrote:
> >>>
> >>> We'd like to add a new -mtune=ia option for x86 to optimize for
On Fri, 6 Dec 2013, Jan Hubicka wrote:
> > On Thu, 21 Nov 2013, Jan Hubicka wrote:
> >
> > > >
> > > > Why do you need an additional -fparallelism? Wouldn't
> > > > -fwpa=... be a better match, matching -flto=...? As we already
> > > > pass down a -fwpa option to WPA this would make things eas
On Fri, Dec 6, 2013 at 9:02 AM, Bernd Edlinger
wrote:
> Hi,
>
> On Thu, 5 Dec 2013 21:12:54, Jeff Law wrote:
>>
>> On 12/04/13 00:49, Bernd Edlinger wrote:
>>>
>>> Regarding the consistency of bitregion_start/end ,
>>>
>>> they should either both be zero, or
>>>
>>> bitregion_start <= bitpos && bi
On Fri, Dec 06, 2013 at 12:53:02PM +0400, Alexey Samsonov wrote:
> ASan calls this function only for global variables (not functions). It
> is needed because
> we use a different machinery to pass global names to ASan runtime - we
> register globals
> by a call from instrumented code, which also te
Hello,
This fixes a bug on the 4.8 branch which was initially described in PR
51244 comment 59 and also reported as a separate PR 59343.
Tested with
make -k check RUNTESTFLAGS="--target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"
and no new failures.
OK for 4.8?
C
On Fri, Dec 6, 2013 at 10:11 AM, Eric Botcazou wrote:
>> Here's the Correct Fix(tm). We may or may not decide to go for it because
>> of concerns about ABI changes; in the latter case, any kludge that we'll
>> put in place instead must be restricted to the cases caught by this patch.
>>
>>
>>
On Fri, Dec 6, 2013 at 6:16 AM, Jeff Law wrote:
> On 12/04/13 01:16, Bernd Edlinger wrote:
>
>>
>>> Looking for some more time your patch may be indeed the easiest
>>> without big re-factoring.
>
> Richard (or Bernd), can you comment on why? Something seems "off" here.
>
> Why do we need to handl
Hi,
On Thu, 5 Dec 2013 15:10:51, Richard Biener wrote:
>
> On Thu, Dec 5, 2013 at 1:27 PM, Bernd Edlinger
> wrote:
>> Hi Richard,
>>
>> I had just an idea how to solve that recursion problem without completely
>> ignoring the
>> memory mode. I hope you are gonna like it.
>>
>> This time I even a
On Mon, Nov 25, 2013 at 7:41 PM, Jeff Law wrote:
> On 11/25/13 02:22, bin.cheng wrote:
>>
>> Hi,
>> I previously committed two patches lowering complex address expression for
>> IVOPT at http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00546.html and
>> http://gcc.gnu.org/ml/gcc-patches/2013-11/msg011
On Fri, Dec 6, 2013 at 11:15 AM, Bernd Edlinger
wrote:
> Hi,
>
> On Thu, 5 Dec 2013 15:10:51, Richard Biener wrote:
>>
>> On Thu, Dec 5, 2013 at 1:27 PM, Bernd Edlinger
>> wrote:
>>> Hi Richard,
>>>
>>> I had just an idea how to solve that recursion problem without completely
>>> ignoring the
>>
>
> Hmm, same patch as last time attached?
>
> Richard.
>
Yes, only the change-log had one redundant line.
Bernd.
Hi,
Entry pr41488 shows a case in which induction variable can't be recognized
or coalesced. As noted in the bug entry, one possible fix is to teach PRE
not to do some specific transformation. However, it's in nature a scalar
evolution issue. Considering below snippet:
# i_17 = PHI
# _20
Could someone review and commit the patch at
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02105.html ?
TIA
Dominique
On Fri, Dec 6, 2013 at 6:19 PM, Richard Biener
wrote:
> On Mon, Nov 25, 2013 at 7:41 PM, Jeff Law wrote:
>> On 11/25/13 02:22, bin.cheng wrote:
>>
>> Unless there's a PR for this problem, I think this needs to wait.
>
> I agree. Btw, please split the patch.
Yes, I will get back to this after ent
Oleg Endo wrote:
> This fixes a bug on the 4.8 branch which was initially described in PR
> 51244 comment 59 and also reported as a separate PR 59343.
> Tested with
> make -k check RUNTESTFLAGS="--target_board=sh-sim
> \{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"
>
> and no new
On Fri, Dec 6, 2013 at 10:38 AM, Richard Biener
wrote:
> On Thu, Dec 5, 2013 at 10:05 PM, H.J. Lu wrote:
>> On Thu, Dec 5, 2013 at 1:02 PM, Patrick Marlier
>> wrote:
>>> Hi,
>>>
>>>
>>> On 12/05/2013 07:22 PM, H.J. Lu wrote:
We'd like to add a new -mtune=ia option for x86 to optimize f
On Fri, Dec 6, 2013 at 11:15 AM, Bernd Edlinger
wrote:
> Hi,
>
> On Thu, 5 Dec 2013 15:10:51, Richard Biener wrote:
>>
>> On Thu, Dec 5, 2013 at 1:27 PM, Bernd Edlinger
>> wrote:
>>> Hi Richard,
>>>
>>> I had just an idea how to solve that recursion problem without completely
>>> ignoring the
>>
Richard,
> Note I just want to help as well and I am not very familiar with
> the details of the implementation here. So I'd rather have
> a patch "obviously correct" to me - which expanding a condition
> by several more checks isn't ;)
>
Thanks a lot, I understand that very well. Any help is wel
On Fri, Dec 6, 2013 at 2:44 AM, Uros Bizjak wrote:
> On Fri, Dec 6, 2013 at 10:38 AM, Richard Biener
> wrote:
>> On Thu, Dec 5, 2013 at 10:05 PM, H.J. Lu wrote:
>>> On Thu, Dec 5, 2013 at 1:02 PM, Patrick Marlier
>>> wrote:
Hi,
On 12/05/2013 07:22 PM, H.J. Lu wrote:
>
>>
On Fri, Dec 6, 2013 at 11:29 AM, bin.cheng wrote:
> Hi,
> Entry pr41488 shows a case in which induction variable can't be recognized
> or coalesced. As noted in the bug entry, one possible fix is to teach PRE
> not to do some specific transformation. However, it's in nature a scalar
> evolution
On Fri, Dec 6, 2013 at 11:40 AM, Bin.Cheng wrote:
> On Fri, Dec 6, 2013 at 6:19 PM, Richard Biener
> wrote:
>> On Mon, Nov 25, 2013 at 7:41 PM, Jeff Law wrote:
>>> On 11/25/13 02:22, bin.cheng wrote:
>>>
>>> Unless there's a PR for this problem, I think this needs to wait.
>>
>> I agree. Btw, p
Hi all,
GCC version of Asan currently lacks options for detailed control over
code instrumentation. These are not usually necessary but for embedded
systems with scarce system resources Asan memory overhead of 2x-3x may
often be unacceptable.
It seems that LLVM provides some options to allow
Ok to commit, assuming other targets will not break.
But I will not be able to do another merge until the two versions
(upstream and GCC) are equivalent again.
So, please don't close
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59402 until it's done.
--kcc
On Thu, Dec 5, 2013 at 6:37 PM, H.J. Lu
Jakub Jelinek wrote:
On Wed, Dec 04, 2013 at 08:14:43AM -0800, H.J. Lu wrote:
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/vect-nop-move.c
@@ -0,0 +1,64 @@
+/* { dg-do run } */
+/* { dg-require-effective-target vect_float } */
+/* { dg-options "-O3 -fdump-rtl-combine-details" } */
Please chan
On Fri, Dec 06, 2013 at 03:28:50PM +0400, Yury Gribov wrote:
> Hi all,
>
> GCC version of Asan currently lacks options for detailed control
> over code instrumentation. These are not usually necessary but for
> embedded systems with scarce system resources Asan memory overhead
> of 2x-3x may often
On Fri, Dec 6, 2013 at 3:28 PM, Yury Gribov wrote:
> Hi all,
>
> GCC version of Asan currently lacks options for detailed control over code
> instrumentation. These are not usually necessary but for embedded systems
> with scarce system resources Asan memory overhead of 2x-3x may often be
> unacce
On Fri, Dec 6, 2013 at 3:31 AM, Konstantin Serebryany
wrote:
> Ok to commit, assuming other targets will not break.
> But I will not be able to do another merge until the two versions
> (upstream and GCC) are equivalent again.
> So, please don't close
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
Konstantin Serebryany wrote:
> only -asan-stack and -asan-globals affect the memory overhead
But disabling code also counts. -asan-instrument-reads=0 may result in
big code size reduction (I'd say over 50%).
-Y
> big code size reduction
I meant to say "instrumented code size reduction"...
-Y
---
From: Yury Gribov
Sent: Friday, December 06, 2013 3:55PM
To: Konstantin Serebryany
Cc: GCC Patches , Viacheslav Garbuzov
, Max Ostapenko
Subject: Re: RFC Asan
On Fri, Dec 6, 2013 at 7:20 PM, Richard Biener
wrote:
> On Fri, Dec 6, 2013 at 11:40 AM, Bin.Cheng wrote:
>> On Fri, Dec 6, 2013 at 6:19 PM, Richard Biener
>> wrote:
>>> On Mon, Nov 25, 2013 at 7:41 PM, Jeff Law wrote:
On 11/25/13 02:22, bin.cheng wrote:
Unless there's a PR for t
On Fri, Dec 06, 2013 at 03:28:50PM +0400, Yury Gribov wrote:
> Hi all,
>
> GCC version of Asan currently lacks options for detailed control
> over code instrumentation. These are not usually necessary but for
> embedded systems with scarce system resources Asan memory overhead
> of 2x-3x may often
On Fri, Dec 6, 2013 at 3:59 PM, Yury Gribov wrote:
>> big code size reduction
>
> I meant to say "instrumented code size reduction"...
I agree.
Reads are usually 2/3 of all memory accesses in a program (counted
both statically or dynamically).
So if you instrument only writes you get just 1/3 of
On Fri, Dec 6, 2013 at 4:09 PM, Jakub Jelinek wrote:
> On Fri, Dec 06, 2013 at 03:28:50PM +0400, Yury Gribov wrote:
>> Hi all,
>>
>> GCC version of Asan currently lacks options for detailed control
>> over code instrumentation. These are not usually necessary but for
>> embedded systems with scarc
On Fri, Dec 06, 2013 at 01:09:29PM +0100, Jakub Jelinek wrote:
> On Fri, Dec 06, 2013 at 03:28:50PM +0400, Yury Gribov wrote:
> > Hi all,
> >
> > GCC version of Asan currently lacks options for detailed control
> > over code instrumentation. These are not usually necessary but for
> > embedded sys
On Fri, Dec 06, 2013 at 01:32:42PM +0100, Ondřej Bílka wrote:
> On second though besides of decreasing of code size there is no reason
> to complicate compilation for these features. A more flexible way is add
> environment variable that will disable these at runtime.
That is not possible, the ins
Konstantin wrote:
> Jakub wrote:
>> I'm strongly against the blacklist,
> I don't like it either. We were forced to implement it by reality.
> ...
> imagine third-party code which you can build but can not change
Same situation here. Reality is that Asan is often thrown at huge (I
mean several M
Hi!
Here is an alternative version of the patch I've posted earlier to allow
building libsanitizer on 2.6.18-ish kernel headers, this time by adding
5 tiny kernel header wrappers.
The only drawback of this are warnings like:
../../../../libsanitizer/include/linux/aio_abi.h:2:2: warning: #include_n
On Fri, Dec 6, 2013 at 1:43 PM, Jakub Jelinek wrote:
> Hi!
>
> Here is an alternative version of the patch I've posted earlier to allow
> building libsanitizer on 2.6.18-ish kernel headers, this time by adding
> 5 tiny kernel header wrappers.
> The only drawback of this are warnings like:
> ../../
On Fri, Dec 6, 2013 at 4:39 PM, Yury Gribov wrote:
> Konstantin wrote:
>
>> Jakub wrote:
>>> I'm strongly against the blacklist,
>> I don't like it either. We were forced to implement it by reality.
>> ...
>
>> imagine third-party code which you can build but can not change
>
> Same situation here
On Fri, Dec 06, 2013 at 01:52:29PM +0100, Richard Biener wrote:
> > Note that testing still shows some issues, e.g. because the
> > kThreadDescriptorSize change has not been applied. But it at least builds
> > and for many tests works.
>
> What's wrong with just copying the kernel headers 1:1? I
Konstantin wrote:
> Can you have a target specific config for the particular target
> that will have its own shadow offset & scale?
Yes, we have this but I don't see how this can help with code
instrumentation overheads.
-Y
On Fri, Dec 6, 2013 at 2:04 PM, Jakub Jelinek wrote:
> On Fri, Dec 06, 2013 at 01:52:29PM +0100, Richard Biener wrote:
>> > Note that testing still shows some issues, e.g. because the
>> > kThreadDescriptorSize change has not been applied. But it at least builds
>> > and for many tests works.
>>
On Fri, Dec 6, 2013 at 5:10 PM, Yury Gribov wrote:
> Konstantin wrote:
>> Can you have a target specific config for the particular target
>> that will have its own shadow offset & scale?
>
> Yes, we have this but I don't see how this can help with code
> instrumentation overheads.
My comment about
On Fri, Dec 06, 2013 at 01:49:50PM +0100, Richard Biener wrote:
> Comments inline (scary large this patch for this stage ...)
Thanks.
> > +(define_expand "maskload"
> > + [(set (match_operand:V48_AVX2 0 "register_operand")
> > + (unspec:V48_AVX2
> > + [(match_operand: 2 "register_operand")
On Fri, 6 Dec 2013, Jakub Jelinek wrote:
> On Fri, Dec 06, 2013 at 01:49:50PM +0100, Richard Biener wrote:
> > Comments inline (scary large this patch for this stage ...)
>
> Thanks.
>
> > > +(define_expand "maskload"
> > > + [(set (match_operand:V48_AVX2 0 "register_operand")
> > > + (unspec:V
Konstantin wrote:
> My comment about "don't implement them" was only about the flags
> that change shadow offset & scale
Ah, I see. I didn't mention them in the first place so I got puzzled.
So it looks like people are generally ok with
* --param asan-instrument-reads=0/1
* --param asan-instrume
On Thu, Dec 5, 2013 at 12:40 PM, Vladimir Makarov wrote:
> The following patch fixes two GCC testsuite failures for LRA. The patch
> makes swap through registers instead of memory for the test cases when LRA
> is used.
>
> There are differences in reload and LRA constraint matching algorithm whic
> Hi, all
>
> This is the new patch for gcov-tool (previously profile-tool).
>
> Honza: can you comment on the new merge interface? David posted some
> comments in an earlier email and we want to know what's your opinion.
>
> Test patch has been tested with boostrap, regresssion,
> profiledboots
On Thu, Dec 5, 2013 at 11:50 PM, Jakub Jelinek wrote:
>
> 2013-12-06 Jakub Jelinek
>
> * elf.c (ET_DYN): Undefine and define again.
> (elf_add): Add exe argument, if true and ehdr.e_type is ET_DYN,
> return early -1 without closing the descriptor.
> (struct phdr_
On Fri, Dec 6, 2013 at 1:53 AM, Jakub Jelinek wrote:
>
> The alternative would be to just (perhaps under #ifdef SANITIZER_CP_DEMANGLE)
> compile in libiberty/cp-demangle.c (similarly how libstdc++ compiles it in)
> as part of libsanitizer/libiberty/ or even libsanitizer/libbacktrace/,
> and tweak
gcc/
* basic-block.h (last_basic_block_for_function): Rename to...
(last_basic_block_for_fn): ...this.
* ipa-utils.c (ipa_merge_profiles): Update for renaming of
last_basic_block_for_function to last_basic_block_for_fn.
* lto-streamer-in.c (input_cfg): Likewi
gcc/
* basic-block.h (FOR_EACH_BB_REVERSE): Eliminate macro.
* cfghooks.c (verify_flow_info): Replace uses of FOR_EACH_BB_REVERSE
with FOR_EACH_BB_REVERSE_FN, making uses of cfun explicit.
* cfgrtl.c (print_rtl_with_bb, rtl_verify_edges,
rtl_verify_bb_insns,
I have a series of 13 follow-up patches which remove the remaining
"cfun"-using macros from basic-block.h
Successfully bootstrapped®tested on x86_64-unknown-linux-gnu.
These were pre-approved in stage1, and are mechanical in nature [1]
I'd like to apply these to trunk now, but given that we're n
gcc/
* basic-block.h (label_to_block_map_for_function): Rename to...
(label_to_block_map_for_fn): ...this.
* lto-streamer-in.c (input_cfg): Update for renaming.
* tree-cfg.c (init_empty_tree_cfg_for_function): Likewise.
---
gcc/basic-block.h | 2 +-
gcc/lto-stre
gcc/
* basic-block.h (basic_block_info_for_function): Rename to...
(basic_block_info_for_fn): ...this.
(BASIC_BLOCK_FOR_FUNCTION): Rename to...
(BASIC_BLOCK_FOR_FN): ...this.
(SET_BASIC_BLOCK_FOR_FUNCTION): Rename to...
(SET_BASIC_BLOCK_FOR_FN): ...th
gcc/
* basic-block.h (SET_BASIC_BLOCK): Eliminate macro.
* cfg.c (compact_blocks): Replace uses of SET_BASIC_BLOCK
with SET_BASIC_BLOCK_FOR_FN, making use of cfun explicit.
(expunge_block): Likewise.
* cfgrtl.c (create_basic_block_structure): Likewise.
gcc/
* basic-block.h (basic_block_info): Eliminate macro.
* cfgrtl.c (rtl_create_basic_block): Replace uses of
basic_block_info with basic_block_info_for_fn, making uses
of cfun be explicit.
* tree-cfg.c (build_gimple_cfg, create_bb): Likewise.
---
gcc/basi
gcc/
* basic-block.h (profile_status_for_function): Rename to...
(profile_status_for_fn): ...this.
* cfg.c (check_bb_profile): Update for renaming.
* cgraphbuild.c (compute_call_stmt_bb_frequency): Likewise.
* lto-streamer-in.c (input_cfg): Likewise.
gcc/
* basic-block.h (label_to_block_map): Eliminate macro.
* gimple.c (gimple_set_bb): Replace uses of label_to_block_map
with uses of label_to_block_map_for_fn, making uses of cfun be
explicit.
* tree-cfg.c (delete_tree_cfg_annotations): Likewise.
gcc/
* basic-block.h (profile_status): Eliminate macro.
* cfgbuild.c (find_many_sub_basic_blocks): Eliminate use of
profile_status macro in favor of profile_status_for_fn, making
use of cfun explicit.
* cfghooks.c (account_profile_record): Likewise.
On Fri, Dec 06, 2013 at 01:34:43PM +0100, Jakub Jelinek wrote:
> On Fri, Dec 06, 2013 at 01:32:42PM +0100, Ondřej Bílka wrote:
> > On second though besides of decreasing of code size there is no reason
> > to complicate compilation for these features. A more flexible way is add
> > environment vari
gcc/
* basic-block.h (FOR_ALL_BB): Eliminate macro.
* cfg.c (alloc_aux_for_blocks, clear_aux_for_blocks): Replace
uses of FOR_ALL_BB with FOR_ALL_BB_FN, making uses of cfun explicit.
* cfganal.c (inverted_post_order_compute): Likewise.
* cfgcleanup.c (try_o
On Fri, Dec 06, 2013 at 04:10:31PM +0100, Ondřej Bílka wrote:
> Currently this code with sanitize=address gets expanded
>
> int foo(char *x, char *y, int i)
> {
> x[i] = y[i];
> }
>
> to
>
> snip
> movq%rsi, %rax
> movq%rsi, %rdx
> shrq$3, %rax
> andl
David Malcolm wrote:
>I have a series of 13 follow-up patches which remove the remaining
>"cfun"-using macros from basic-block.h
>
>Successfully bootstrapped®tested on x86_64-unknown-linux-gnu.
>
>These were pre-approved in stage1, and are mechanical in nature [1]
>
>I'd like to apply these to tru
On 12/6/2013, 8:44 AM, David Edelsohn wrote:
On Thu, Dec 5, 2013 at 12:40 PM, Vladimir Makarov wrote:
The following patch fixes two GCC testsuite failures for LRA. The patch
makes swap through registers instead of memory for the test cases when LRA
is used.
There are differences in reload and
On Fri, Dec 06, 2013 at 10:39:29AM -0500, Vladimir Makarov wrote:
> Ok. I guess there is only one option to use one pattern for LRA
> and reload without ?? in register alternative. In this case, reload
> and LRA will actually work according to GCC documentation (LRA
> treats ? cost as the cost o
On Fri, Dec 06, 2013 at 04:16:04PM +0100, Jakub Jelinek wrote:
> On Fri, Dec 06, 2013 at 04:10:31PM +0100, Ondřej Bílka wrote:
> > Currently this code with sanitize=address gets expanded
> >
> > int foo(char *x, char *y, int i)
> > {
> > x[i] = y[i];
> > }
> >
> > to
> >
> > snip
> > movq
> > Hi,
> >
> > Currently, on ARM, you have to either call abort() or raise(SIGTRAP)
> > to achieve a handy crash.
> >
> > This patch allows you to instead call __builtin_trap() which is much
> > more efficient at falling over because it becomes just a single
> > instruction that will trap for you.
On Fri, Dec 6, 2013 at 3:51 PM, David Malcolm wrote:
> * asan.c (transform_statements): Eliminate use of last_basic_block
> in favor of last_basic_block_for_fn, in order to make use of cfun
> explicit.
Can we please make all this _for_fn go away?
Ciao!
Steven
On 12/6/2013, 10:45 AM, Jakub Jelinek wrote:
On Fri, Dec 06, 2013 at 10:39:29AM -0500, Vladimir Makarov wrote:
Ok. I guess there is only one option to use one pattern for LRA
and reload without ?? in register alternative. In this case, reload
and LRA will actually work according to GCC docum
On Fri, Dec 06, 2013 at 10:59:37AM -0500, Vladimir Makarov wrote:
> It is still two different patterns. One for reload and one for LRA.
> Attribute enabled is mostly used to describe insn constraints for
> subtargets.
I meant something like:
(define_insn "*bswapdi2_64bit"
[(set (match_operand:D
Hi Kugan,
Thanks for working on this issue.
On 12/04/13 21:03, Kugan wrote:
Hi,
gcc trunk aarch64 bootstrapping fails with gas version 2.23.2 (with
error message similar to cannot compute suffix of object files) as this
particular version does not support -mabi=lp64. It succeeds with later
ver
On Thu, Dec 05, 2013 at 12:40:17PM -0500, Vladimir Makarov wrote:
> The following patch fixes two GCC testsuite failures for LRA. The
> patch makes swap through registers instead of memory for the test
> cases when LRA is used.
>
> There are differences in reload and LRA constraint matching
> alg
On 12/03/2013 11:52 AM, Richard Sandiford wrote:
Kenneth Zadeck writes:
Index: tree-vrp.c
===
--- tree-vrp.c (revision 205597)
+++ tree-vrp.c (working copy)
@@ -2611,22 +2611,28 @@ extract_range_from_binary_expr_1 (value_
Hi,
I am going to apply the patch below to trunk and 4.8-branch.
It adds a copy of the microblaze-*-elf section for microblaze-rtems* to
libgcc/config.host.
This is the missing patch I mentioned in
http://gcc.gnu.org/ml/gcc/2013-11/msg00548.html
Ralf
2013-12-06 Ralf Corsépius
* config
Hi,
ChangeLog
2013-12-06 Kai Tietz
PR target/56807
* config/i386/i386.c (ix86_expand_prologue):
Tested for i686-w64-mingw32, x86_64-unknown-linux-gnu. Ok for apply?
Regards,
Kai
Index: config/i386/i386.c
===
--- conf
On Fri, Dec 6, 2013 at 9:06 AM, Kai Tietz wrote:
> Hi,
>
>
> ChangeLog
>
> 2013-12-06 Kai Tietz
>
> PR target/56807
> * config/i386/i386.c (ix86_expand_prologue):
>
Incomplete ChangeLog entry.
--
H.J.
Jakub Jelinek wrote:
On Wed, Dec 04, 2013 at 08:14:43AM -0800, H.J. Lu wrote:
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/vect-nop-move.c
@@ -0,0 +1,64 @@
+/* { dg-do run } */
+/* { dg-require-effective-target vect_float } */
+/* { dg-options "-O3 -fdump-rtl-combine-details" } */
Please chan
Upps ... here is the missing Changlog
ChangeLog
2013-12-06 Kai Tietz
PR target/56807
* config/i386/i386.c (ix86_expand_prologue): Address saved
registers stack-relative, not via frame-pointer.
Hi all,
Following the implementation of the Crypto intrinsics I posted earlier this
week, this patch implements the vceq_p64 and vtst_p64 intrinsics that operate on
the new poly64_t type. They do not have a regular form and can thus not be
autogenerated from our beloved ML scripts and are ther
On Fri, Dec 06, 2013 at 05:12:08PM +, Tejas Belagod wrote:
> 2013-12-06 Tejas Belagod
>
> testsuite/
> * gcc.dg/vect/vect-nop-move.c: Fix dg options.
Ok, thanks.
> --- a/gcc/testsuite/gcc.dg/vect/vect-nop-move.c
> +++ b/gcc/testsuite/gcc.dg/vect/vect-nop-move.c
> @@ -1,6 +1,6 @@
Hello!
Currently, gcc emits wrong warning for MMX argument passing on 32 bit
targets, even when MMX is enabled:
pr59405.c: In function ‘foo32x2_be’:
pr59405.c:7:1: warning: SSE vector argument without SSE enabled
changes the ABI [enabled by default]
foo32x2_be (float32x2_t x)
Attached patch fix
Hi all,
The testcase gcc.dg/tree-ssa/loop-31.c started failing on arm with r202165. The
scan dump pattern looks for "+ 2" appearing exactly once. With r202165 the loop
header is modified from:
:
ivtmp.5_10 = (unsigned int) &a[4294967295];
_16 = (unsigned int) len_4(D);
_17 = _16 * 2;
On 12/6/2013, 11:28 AM, Michael Meissner wrote:
On Thu, Dec 05, 2013 at 12:40:17PM -0500, Vladimir Makarov wrote:
The following patch fixes two GCC testsuite failures for LRA. The
patch makes swap through registers instead of memory for the test
cases when LRA is used.
There are differences in
1 - 100 of 153 matches
Mail list logo
