On Fri, Nov 23, 2012 at 6:05 PM, Jakub Jelinek wrote:
> Hi!
>
> This patch attempts to instrument __atomic_* and __sync_* builtins.
> Unfortunately for none of the builtins there is 1:1 mapping to the tsan
> replacements, tsan uses weirdo memory model encoding (instead of values
> from 0 to 5 appa
On Fri, Nov 23, 2012 at 6:05 PM, Jakub Jelinek wrote:
> Hi!
>
> This patch attempts to instrument __atomic_* and __sync_* builtins.
> Unfortunately for none of the builtins there is 1:1 mapping to the tsan
> replacements, tsan uses weirdo memory model encoding (instead of values
> from 0 to 5 appa
On Tue, Nov 27, 2012 at 12:13:42PM +0400, Dmitry Vyukov wrote:
> I've added 128-bit atomic ops:
> http://llvm.org/viewvc/llvm-project?view=rev&revision=168683
Thanks.
>
> Refactored atomic ops so that the atomic operation itself is done
> under the mutex:
> http://llvm.org/viewvc/llvm-project?vie
On 2012.11.26 at 13:58 -0800, H.J. Lu wrote:
> Hi,
>
> OPT_SPECIAL_unknown, OPT_SPECIAL_ignore, OPT_SPECIAL_program_name and
> OPT_SPECIAL_input_file are special options, which aren't in cl_options.
> This patch avoids
>
> if (!(cl_options[foption->opt_index].flags & CL_TARGET))
>
> on them. Th
On Tue, Nov 27, 2012 at 12:23 PM, Jakub Jelinek wrote:
> On Tue, Nov 27, 2012 at 12:13:42PM +0400, Dmitry Vyukov wrote:
>> I've added 128-bit atomic ops:
>> http://llvm.org/viewvc/llvm-project?view=rev&revision=168683
>
> Thanks.
>>
>> Refactored atomic ops so that the atomic operation itself is d
On Tue, Nov 27, 2012 at 12:47 PM, Dmitry Vyukov wrote:
> On Tue, Nov 27, 2012 at 12:23 PM, Jakub Jelinek wrote:
>> On Tue, Nov 27, 2012 at 12:13:42PM +0400, Dmitry Vyukov wrote:
>>> I've added 128-bit atomic ops:
>>> http://llvm.org/viewvc/llvm-project?view=rev&revision=168683
>>
>> Thanks.
>>>
>
This is an alternate fix for PR55331, bootstrapped and tested on
x86_64-unknown-linux-gnu, applied.
Richard.
2012-11-16 Richard Biener
PR middle-end/55331
* gimple-fold.c (gimplify_and_update_call_from_tree): Replace
stmt with a NOP instead of removing it.
*
> gcc/ChangeLog:
> 2012-11-26 Dehao Chen
>
>* cfgrtl.c (rtl_merge_blocks): Check with UNKNOWN_LOCATION correctly.
>(cfg_layout_merge_blocks): Likewise.
OK, thanks.
--
Eric Botcazou
On Mon, 2012-11-26 at 20:10 +0100, Ulrich Weigand wrote:
> I noticed what appears to be a long-standing bug in generating .dwarf_frame
> sections with GCC on Linux on PowerPC.
>
> It had been my understanding that .dwarf_frame is supposed to differ from
> .eh_frame on PowerPC w.r.t. register numbe
On Mon, Nov 26, 2012 at 11:54 PM, Dehao Chen wrote:
> The new patch is attached. Bootstrapped and passed gcc regression test.
>
> Ok for trunk?
Hmm ... this merely avoids some UNKNOWN_LOCATIONs which should
be ok. I think the issue is that gimplify_expr does:
saved_location = input_location;
> -Original Message-
> From: Ramana Radhakrishnan [mailto:ramana@googlemail.com]
> Sent: Saturday, November 24, 2012 7:20 AM
> To: Bin Cheng
> Cc: gcc-patches@gcc.gnu.org; Ramana Radhakrishnan; Richard Earnshaw;
Richard
> Sandiford
> Subject: Re: [PING Updated]: [PATCH GCC/ARM] Fix pr
> Or rather this one. Same hammer, different color. It turns out that
> the rtlanal.c change caused problems, so I've got to use a home-brewn
> equivalent of remove_reg_equal_equiv_notes_for_regno...
>
> Test case is unchanged so I'm omitting it here.
>
> Ciao!
> Steven
>
>
> gcc/
> * loo
Ping!
Siddhesh
On Wed, Nov 21, 2012 at 12:42:13PM +0530, Siddhesh Poyarekar wrote:
> Hi,
>
> Ping!
>
>
> Siddhesh
>
> On Thu, 15 Nov 2012 19:05:38 +0530, Siddhesh wrote:
>
> > Hi,
> >
> > Here's an updated version of the patch which warns the user if the
> > removing of redundant exits resu
Ping!
Siddhesh
On Wed, Nov 21, 2012 at 12:43:10PM +0530, Siddhesh Poyarekar wrote:
> Hi,
>
> Ping!
>
> Siddhesh
>
> On Thu, 15 Nov 2012 19:52:21 +0530, Siddhesh wrote:
>
> > Hi,
> >
> > Current HEAD fails build when --enable-languages=c, i.e. C++ is not
> > being built. Attached patch fixes
On Tue, Nov 27, 2012 at 1:06 AM, Kenneth Zadeck
wrote:
> Richard,
>
> I spent a good part of the afternoon talking to Mike about this. He is on
> the c++ standards committee and is a much more seasoned c++ programmer than
> I am.
>
> He convinced me that with a large amount of engineering and c++
On Thu, Nov 15, 2012 at 07:52:21PM +0530, Siddhesh Poyarekar wrote:
> 2012-11-15 Siddhesh Poyarekar
>
> * configure.ac: Disable libsanitizer if we're not building C++.
> * configure: Regenerate.
Ok, thanks.
Jakub
On Tue, Nov 27, 2012 at 9:32 AM, Markus Trippelsdorf
wrote:
> On 2012.11.26 at 13:58 -0800, H.J. Lu wrote:
>> Hi,
>>
>> OPT_SPECIAL_unknown, OPT_SPECIAL_ignore, OPT_SPECIAL_program_name and
>> OPT_SPECIAL_input_file are special options, which aren't in cl_options.
>> This patch avoids
>>
>> if (!(
On Mon, Nov 26, 2012 at 4:27 PM, Jakub Jelinek wrote:
> On Mon, Nov 26, 2012 at 04:24:41PM +0100, Richard Biener wrote:
>> On Thu, Nov 15, 2012 at 9:09 PM, Jakub Jelinek wrote:
>> > On the following testcase substitute_and_fold ICEs because memmove
>> > of length 1 on an empty class is optimized
Hi,
I committed the patch implementing register pressure directed hoist in TRUNK
and enabled the option "-fira-hoist-pressure" for all targets by reviewer's
suggestion, although it has no obvious effect on Thumb2/x86/x86_64. Now I
collected performance data with Os and found it causes performance
r
Richard Sandiford wrote:
After the discussions Richard Earnshaw had on IRC with Andrew Pinski, it was
felt that it was best to fix the standard predicate
'general_operand' to not allow SUBREG (MEM) with side-effects as it has known
issues associated with it - particularly reload not being able t
On Tue, Nov 27, 2012 at 11:05:47AM +0100, Jakub Jelinek wrote:
> On Thu, Nov 15, 2012 at 07:52:21PM +0530, Siddhesh Poyarekar wrote:
> > 2012-11-15 Siddhesh Poyarekar
> >
> > * configure.ac: Disable libsanitizer if we're not building C++.
> > * configure: Regenerate.
>
> Ok, thanks.
>
On Tue, Nov 27, 2012 at 10:55 AM, Eric Botcazou wrote:
>> Or rather this one. Same hammer, different color. It turns out that
>> the rtlanal.c change caused problems, so I've got to use a home-brewn
>> equivalent of remove_reg_equal_equiv_notes_for_regno...
>>
>> Test case is unchanged so I'm omit
Am 26.11.2012 17:53, schrieb H.J. Lu:
> Hi,
>
> There is a patch to enable both ld and gold in GCC:
>
> http://gcc.gnu.org/ml/gcc-patches/2011-06/msg02076.html
>
> and Diego asked if there is "anything in particular blocking
> this patch in trunk":
I think it's lack of review.
> http://gcc.gnu
I quoted the whole discussion, see a single line below.
On Mon, 19 Nov 2012, Eric Botcazou wrote:
> > 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/g
On Tue, Nov 27, 2012 at 11:34 AM, Steven Bosscher wrote:
>>> gcc/
>>> * loop-unroll.c (struct iv_to_split): Add new 'orig_var' member.
>>> (analyze_iv_to_split_insn): Record it.
>>> (maybe_strip_eq_note_for_split_iv): New function to remove REG_EQUAL
>>> notes that refer to
On Tue, Nov 27, 2012 at 06:44:23AM -0500, Hans-Peter Nilsson wrote:
> > We apparently have a small conflict between the meaning of volatile asms
> > with
> > operands at the source level and volatile_insn_p. However, I think that the
> > latter interpretation is the correct one: if your asm state
This removes dead code as suggested by Jakub.
Bootstrapped and tested on x86_64-unknown-linux-gnu.
Richard.
2012-11-27 Richard Biener
* gimple-fold.c (fold_stmt_1): Remove unnecessary code.
Index: gcc/gimple-fold.c
===
On Tue, Nov 27, 2012 at 01:00:05PM +0100, Richard Biener wrote:
>
> This removes dead code as suggested by Jakub.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu.
Looks as partial removal only. IMHO
gimple_stmt_iterator gsinext = *gsi;
gimple next_stmt;
gsi_next (&gsinext);
nex
On Tue, 27 Nov 2012, Jakub Jelinek wrote:
> On Tue, Nov 27, 2012 at 06:44:23AM -0500, Hans-Peter Nilsson wrote:
JFTR: No I didn't, Eric wrote the below. But, it made sense to me. :)
> > > We apparently have a small conflict between the meaning of volatile asms
> > > with
> > > operands at the s
On Tue, Nov 27, 2012 at 09:23:30AM +0100, Jakub Jelinek wrote:
> On Tue, Nov 27, 2012 at 12:13:42PM +0400, Dmitry Vyukov wrote:
> > I've added 128-bit atomic ops:
> > http://llvm.org/viewvc/llvm-project?view=rev&revision=168683
>
> Thanks.
+#if (defined(__clang__) && defined(__clang_major__) \
+
On Tue, Nov 27, 2012 at 1:00 PM, Steven Bosscher wrote:
> Now that USE of r719 is a use of a dead register, rendering the
> REG_EQUAL invalid. From there on the problem is the same as the ones I
> had to "fix" in loop-unroll.c. First the webizer puts the USE in a
> different web and renames the USE
On Tue, Nov 27, 2012 at 4:27 PM, Jakub Jelinek wrote:
> On Tue, Nov 27, 2012 at 09:23:30AM +0100, Jakub Jelinek wrote:
>> On Tue, Nov 27, 2012 at 12:13:42PM +0400, Dmitry Vyukov wrote:
>> > I've added 128-bit atomic ops:
>> > http://llvm.org/viewvc/llvm-project?view=rev&revision=168683
>>
>> Thank
On Tue, Nov 27, 2012 at 04:35:33PM +0400, Dmitry Vyukov wrote:
> On Tue, Nov 27, 2012 at 4:27 PM, Jakub Jelinek wrote:
> > On Tue, Nov 27, 2012 at 09:23:30AM +0100, Jakub Jelinek wrote:
> >> On Tue, Nov 27, 2012 at 12:13:42PM +0400, Dmitry Vyukov wrote:
> >> > I've added 128-bit atomic ops:
> >> >
On Mon, Nov 19, 2012 at 3:33 AM, Tom de Vries wrote:
> Richard,
>
> Consider the PR55124 example test.c:
> ...
> int a, b;
> long c;
>
> static void inline
> f2 (void)
> {
> unsigned long k = 1;
>
> foo (b ? k = 0 : 0);
>
> b = (((c = b)
> ? (k ?: (c = 0))
> : a)
>* c
On Tue, Nov 27, 2012 at 4:39 PM, Jakub Jelinek wrote:
> On Tue, Nov 27, 2012 at 04:35:33PM +0400, Dmitry Vyukov wrote:
>> On Tue, Nov 27, 2012 at 4:27 PM, Jakub Jelinek wrote:
>> > On Tue, Nov 27, 2012 at 09:23:30AM +0100, Jakub Jelinek wrote:
>> >> On Tue, Nov 27, 2012 at 12:13:42PM +0400, Dmitr
On Wed, Nov 21, 2012 at 5:58 PM, Martin Jambor wrote:
> Hi,
>
> On Tue, Nov 20, 2012 at 09:24:20AM -0800, Richard Henderson wrote:
>> The get_pointer_alignment function can indicate that it does not know
>> what the alignment should be, and it always fills in worst-case values
>> for that case. W
i will discuss this with mike when he wakes up.he lives on the west
pole so that will not be until after you go to bed.
the one point that i will take exception to is that the copying
operation is, in practice, any more time expensive than the pointer
copy. I never bother to initialize t
On Tue, Nov 27, 2012 at 1:28 PM, Steven Bosscher wrote:
> Dominique, could you give this a try and see if it helps?
> (But as I said up-thread: I'm not sure this is a proper fix, or just
> another band-aid...)
And more band-aid, but this time I'm not even sure where things go
wrong. In any case, w
On Tue, Nov 27, 2012 at 12:20 AM, Steven Bosscher wrote:
> Hello,
>
> This patch performs some necessary TLC on slim RTL printing in sched-vis.c:
>
> * Make it independent of the scheduler. Actually it already was,
> mostly. This patch completes the job.
>
> * Harmonize dumping templates for INSN_
On Mon, Nov 12, 2012 at 2:31 PM, Marc Glisse wrote:
> Hello,
>
> this patch lets us fold a bit_field_ref of a constructor even when the
> elements are vectors. Writing a testcase is not that convenient because of
> the lack of a dead code elimination pass after forwprop4 (RTL doesn't always
> remo
Hi!
This patch removes a bogus assertion (that predates introduction
of STMT_VINFO_PATTERN_DEF_SEQ (and STMT_VINFO_PATTERN_DEF_STMT
before that) in 4.7). stmt might be not just STMT_VINFO_RELATED_STMT
of orig_stmt, bt also could be anywhere in STMT_VINFO_PATTERN_DEF_SEQ
of it. We don't vectorize
Hi!
delete_insn_and_edges doesn't DTRT here, there is __builtin_unreachable
after the invalid inline asm goto. Rather than changing the CFG and trying
to figure out what to do to remove the bogus asm goto successfully, it seems
much easier to just turn it into asm goto ("" : : : clobbers... : lab
On Tue, Nov 13, 2012 at 1:50 AM, Andrew Pinski
wrote:
> Hi,
> I know we are in stage3, I thought I would send this out now for
> review as I finally have it ready for consumption as I finally got
> around to removing the limitation of it only working on big-endian.
> This pass was originally wri
On Tue, Nov 27, 2012 at 2:23 PM, Jakub Jelinek wrote:
> Hi!
>
> This patch removes a bogus assertion (that predates introduction
> of STMT_VINFO_PATTERN_DEF_SEQ (and STMT_VINFO_PATTERN_DEF_STMT
> before that) in 4.7). stmt might be not just STMT_VINFO_RELATED_STMT
> of orig_stmt, bt also could be
On Tue, Nov 27, 2012 at 2:26 PM, Jakub Jelinek wrote:
> Hi!
>
> delete_insn_and_edges doesn't DTRT here, there is __builtin_unreachable
> after the invalid inline asm goto. Rather than changing the CFG and trying
> to figure out what to do to remove the bogus asm goto successfully, it seems
> muc
On Tue, Nov 27, 2012 at 01:03:47PM +0100, Jakub Jelinek wrote:
> So, at least from var-tracking POV which doesn't attempt to perform any
> optimizations across any insn, just tries to track where values live, IMHO a
> volatile asm acts exactly the same as non-volatile, that is why I'm testing
> fol
On Tue, 27 Nov 2012, Richard Biener wrote:
On Mon, Nov 12, 2012 at 2:31 PM, Marc Glisse wrote:
Hello,
this patch lets us fold a bit_field_ref of a constructor even when the
elements are vectors. Writing a testcase is not that convenient because of
the lack of a dead code elimination pass afte
> Dominique, could you give this a try and see if it helps?
With the patch, the miscompilation of aermod.f90 is gone.
Thanks,
Dominique
On Wed, Mar 28, 2012 at 6:15 PM, H.J. Lu wrote:
> Hi,
>
> We shouldn't assume that we can define x86_64_fallback_frame_state
> for other x86-64 C libraries, like Bionic. OK for trunk?
>
> Thanks.
>
>
> H.J.
> ---
> 2012-03-27 H.J. Lu
>
> * config/i386/linux-unwind.h (x86_64_fallback_fr
On Tue, Nov 27, 2012 at 05:46:55PM +0400, Konstantin Serebryany wrote:
> This is libsanitizer merge from upstream 168699.
> Tested on x86_64 Ubuntu 12.04 with:
> rm -rf */{*/,}libsanitizer \
> && make -j 50 \
> && make -C gcc check-g{cc,++}
> RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} asan.
Done, r193849.
Now that the merging became 95% automated, I can do another merge upon request.
On Tue, Nov 27, 2012 at 5:53 PM, Jakub Jelinek wrote:
> On Tue, Nov 27, 2012 at 05:46:55PM +0400, Konstantin Serebryany wrote:
>> This is libsanitizer merge from upstream 168699.
>> Tested on x86_64 Ubu
Hi!
I've noticed we don't schedule asan/tsan passes for -Og, which results in
ICEs. For -O0 that is handled by pass_[at]san_O0, but for -Og which also
doesn't use the normal optimization queue there is nothing.
Ok for trunk?
2012-11-27 Jakub Jelinek
* passes.c (init_optimization_pas
On Wed, Nov 21, 2012 at 9:05 PM, Konstantin Serebryany
wrote:
> On Wed, Nov 21, 2012 at 8:40 PM, David Miller wrote:
>> From: Konstantin Serebryany
>> Date: Wed, 21 Nov 2012 19:39:52 +0400
>>
>>> There are various other things that asan library does not support.
>>
>> I'm trying to understand wh
On Tue, Nov 27, 2012 at 3:09 PM, Jakub Jelinek wrote:
> Hi!
>
> I've noticed we don't schedule asan/tsan passes for -Og, which results in
> ICEs. For -O0 that is handled by pass_[at]san_O0, but for -Og which also
> doesn't use the normal optimization queue there is nothing.
>
> Ok for trunk?
Ok.
> And more band-aid, ...
The gcc_assert triggers at bootstrap when compiling gcc/ada/ali.adb:
+===GNAT BUG DETECTED==+
| 4.8.0 20121127 (experimental) [trunk revision 193848p10]
(x86_64-apple-darwin10.8.0) GCC error:|
|
Il 27/11/2012 13:00, Steven Bosscher ha scritto:
> It all
> starts with PRE creating a REG_EQUAL note that references the register
> that's SET in the insn the note is attached to, but the register is
> live after the insn so from that point of view the note is not
> invalid.
This note seems very
On Tue, Nov 27, 2012 at 3:25 PM, Dominique Dhumieres wrote:
>> And more band-aid, ...
>
> The gcc_assert triggers at bootstrap when compiling gcc/ada/ali.adb:
>
> +===GNAT BUG DETECTED==+
> | 4.8.0 20121127 (experime
On Tue, Nov 27, 2012 at 1:46 AM, Richard Biener
wrote:
> On Mon, Nov 26, 2012 at 11:54 PM, Dehao Chen wrote:
>> The new patch is attached. Bootstrapped and passed gcc regression test.
>>
>> Ok for trunk?
>
> Hmm ... this merely avoids some UNKNOWN_LOCATIONs which should
> be ok. I think the issu
On Tue, Nov 27, 2012 at 3:54 PM, Dehao Chen wrote:
> On Tue, Nov 27, 2012 at 1:46 AM, Richard Biener
> wrote:
>> On Mon, Nov 26, 2012 at 11:54 PM, Dehao Chen wrote:
>>> The new patch is attached. Bootstrapped and passed gcc regression test.
>>>
>>> Ok for trunk?
>>
>> Hmm ... this merely avoids
This re-surrects Josephs patch to fix PR35634 - the fact that
the C frontend family does not properly promote the expression
operands of self-modify expressions. Accounting for this during
gimplification is indeed easiest (as long as fold isn't too clever
with the expressions in unpromoted form).
Hi,
this bug triggers in the compilation of QEMU with GCC 4.7.2. It is
latent on trunk because reg_known_value is completely broken. I'll
send a separate patch, but this one applies there too.
The problem arises when you have -fPIE (or -fPIC) and a huge function
with a lot of references to glob
When changing reg_known_value to a VEC, Steven sneaked in a small
semantic change. That change has the advantage of improving compilation
time substantially on some testcases (including PR55489), but it is a
bit heavy-handed: it also makes set_known_reg_value a no-op, while
get_known_reg_value wil
On Tue, Nov 27, 2012 at 2:46 AM, Matthias Klose wrote:
> Am 26.11.2012 17:53, schrieb H.J. Lu:
>> Hi,
>>
>> There is a patch to enable both ld and gold in GCC:
>>
>> http://gcc.gnu.org/ml/gcc-patches/2011-06/msg02076.html
>>
>> and Diego asked if there is "anything in particular blocking
>> this p
On Tue, Nov 27, 2012 at 5:00 PM, Paolo Bonzini wrote:
> When changing reg_known_value to a VEC, Steven sneaked in a small
> semantic change.
I don't sneak, I just tend to do stupid things from time to time ;-)
Thanks for catching this, and sorry for the breakage!
Ciao!
Steven
Hi,
I have just merged upstream gcc-4_7-branch into ARM/aarch64-4.7-branch, up
to r193800.
This merge didn't cause any regressions.
Thanks
Sofiane
On Tue, Nov 27, 2012 at 5:00 PM, Paolo Bonzini wrote:
> Note that the bug is present on older branches too, but it became much
> worse sometime between 4.4 and 4.7.
Probably around the time we (i.e. you and me) taught gcse.c to handle
REG_EQUAL expressions?
> 2012-11-26 Paolo Bonzini <>
>
>
Hi,
this fixes the couple of gnat.dg regressions on all platforms introduced by
the sizetype changes, as well as finishes the conversion of the Ada compiler
to the new scheme by invoking valid_constant_size_p and size_binop in the
appropriate places.
The 2 regressions were introduced by the kl
Extend expiration date for pr54127 and Google ref b/6983319.
Okay for google/gcc-4_7 branch? Thanks.
ChangeLog.google-4_7
2012-11-27 Simon Baldwin
* contrib/testsuite-management/powerpc-grtev3-linux-gnu.xfail:
Extend expiration date for pr54127 and Google ref b/6983319.
In
On Tue, Nov 27, 2012 at 11:45 AM, Simon Baldwin wrote:
> Extend expiration date for pr54127 and Google ref b/6983319.
>
> Okay for google/gcc-4_7 branch? Thanks.
>
>
> ChangeLog.google-4_7
> 2012-11-27 Simon Baldwin
>
> * contrib/testsuite-management/powerpc-grtev3-linux-gnu.xfail:
>
Hi,
This patch adds support for vectorizing across some of the rounding
functions in the C math library to the AArch64 back-end.
In particular, we add support for vectorizing across:
ceil (), ceilf (), lceil (),
floor (), floorf (), lfloor (),
round (), roundf (),
nearbyint (), nearbyintf (),
t
Il 27/11/2012 17:40, Steven Bosscher ha scritto:
> > Note that the bug is present on older branches too, but it became much
> > worse sometime between 4.4 and 4.7.
>
> Probably around the time we (i.e. you and me) taught gcse.c to handle
> REG_EQUAL expressions?
Hmm, no, that was much earlier. L
> This note seems very very weird. For one thing, it becomes invalid on
> the very instruction where it is created. I would say that it should
> not be there.
Agreed.
--
Eric Botcazou
On Tue, 27 Nov 2012, Marc Glisse wrote:
On Tue, 27 Nov 2012, Richard Biener wrote:
It passes bootstrap+testsuite.
... on x86_64-linux-gnu, sorry for the lack of precision (default languages,
Xeon E5520, graphite enabled).
[...]
Boostrapped and tested on ... ?
Ok if bootstrap / testing pa
Tested on x86_64-linux-gnu, powerpc64-linux-gnu and mipsisa64-elf.
Also tested by making sure that there were no changes in assembly
output for a set of gcc .ii files. On the other hand, the -march=octeon
output for a set of mips64-linux-gnu gcc .ii files showed the optimisation
kicking in as h
Il 27/11/2012 17:07, H.J. Lu ha scritto:
> There is no reply for
>
> http://gcc.gnu.org/ml/gcc-patches/2011-06/msg02121.html
That counts as lack of review...
Paolo
On Tue, Nov 27, 2012 at 9:20 AM, Paolo Bonzini wrote:
> Il 27/11/2012 17:07, H.J. Lu ha scritto:
>> There is no reply for
>>
>> http://gcc.gnu.org/ml/gcc-patches/2011-06/msg02121.html
>
> That counts as lack of review...
>
That is no response from patch submitter. It is different from
lack of re
On Tue, 27 Nov 2012, Richard Biener wrote:
> c-family/
> * c-gimplify.c (c_gimplify_expr): Gimplify self-modify expressions
> here and use a type with proper overflow behavior for types that would
> need to be promoted for the arithmetic.
The front-end changes are OK.
> *
On 11/22/2012 09:48 AM, Kirill Yukhin wrote:
> +.PHONY: s-mddump
> +s-mddump: $(BUILD_RTL) $(MD_DEPS) build/genmddump$(build_exeext)
> + $(RUN_GEN) build/genmddump$(build_exeext) $(md_file) 2> tmp-mddump.md
I think just
mddump: ...
$(RUN_GEN) ... > mddump
will be sufficient. This i
On 11/22/2012 09:36 AM, Kirill Yukhin wrote:
> @@ -2668,7 +2668,7 @@ add_c_test (const char *expr, int value)
> {
>struct c_test *test;
>
> - if (expr[0] == 0)
> + if (!expr || expr[0] == 0)
> return;
This looks like it's working around a bug elsewhere.
r~
> I strongly disagree with this. Outputs and clobbers have significant
> meaning even on volatile asms, asm volatile doesn't mean all registers and
> all memory are supposed to be considered clobbered. For memory you have
> "memory" clobber for that, for registers it is users responsibility to
>
> Bootstrap finished on x86_64-pc-linux-gnu, regtest in progress; ok for
> 4.7 and trunk if it passes?
>
> Paolo
>
> 2012-11-26 Paolo Bonzini
>
> PR rtl-optimization/55489
> * gcse.c (compute_transp): Precompute a canonical version
> of XEXP (x, 0), and pass it to canon_true
On 27/11/12 10:10, Bin Cheng wrote:
Hi,
I committed the patch implementing register pressure directed hoist in TRUNK
and enabled the option "-fira-hoist-pressure" for all targets by reviewer's
suggestion, although it has no obvious effect on Thumb2/x86/x86_64. Now I
collected performance data wit
On Mon, 26 Nov 2012, Richard Biener wrote:
Thus you are rejecting a boolean valued vector comparison which we
otherwise happily accept. I suppose that makes sense (even though
at least equality compares can make sense).
I agree that boolean equality comparison of vectors makes sense, but I
d
On 11/26/2012 09:05 AM, Richard Biener wrote:
> On Wed, Nov 7, 2012 at 10:51 PM, Meador Inge wrote:
>> Ping ^ 4.
>
> Ok.
Thanks for the review. Committed to trunk.
--
Meador Inge
CodeSourcery / Mentor Embedded
http://www.mentor.com/embedded-software
On Tue, Nov 27, 2012 at 06:35:52PM +0100, Eric Botcazou wrote:
> Now I agree that the discussion exists for volatile asms. But you have for
> example in the unmodified cse.c:
>
> /* A volatile ASM invalidates everything. */
> if (NONJUMP_INSN_P (insn)
> && GET_CODE (PATTERN (insn)) ==
This patch restores bootstrap when detailed memory stats are enabled.
No functional changes.
Paolo, could you try again with r193864?
Tested on x86_64. Committed to trunk.
2012-11-27 Diego Novillo
* vec.h: Replace 'class vec' with 'struct vec' everywhere.
(ggc_internal_clear
Permanently ignore pr54127 and Google ref b/6983319.
Okay for google/gcc-4_7 branch? Thanks.
ChangeLog.google-4_7
2012-11-27 Simon Baldwin
* contrib/testsuite-management/powerpc-grtev3-linux-gnu.xfail:
Permanently ignore pr54127 and Google ref b/6983319.
Index: contrib/tes
On Tue, Nov 27, 2012 at 1:22 PM, Simon Baldwin wrote:
> 2012-11-27 Simon Baldwin
>
> * contrib/testsuite-management/powerpc-grtev3-linux-gnu.xfail:
> Permanently ignore pr54127 and Google ref b/6983319.
Isn't giving up the sweetest of choices?
OK.
Diego.
Dear all,
effectively, this patch doesn't do anything. Except, it updates the –
deactivated – finalization wrapper.
Note: This patch does not include any code to actually call the
finalization wrapper. Nor is the modified code ever called in gfortran.
However, that patch paves the road to a
On Tue, Nov 27, 2012 at 9:23 AM, H.J. Lu wrote:
> On Tue, Nov 27, 2012 at 9:20 AM, Paolo Bonzini wrote:
>> Il 27/11/2012 17:07, H.J. Lu ha scritto:
>>> There is no reply for
>>>
>>> http://gcc.gnu.org/ml/gcc-patches/2011-06/msg02121.html
>>
>> That counts as lack of review...
>>
>
> That is no re
Hi!
This fixes a couple of asan ICEs found while running make check
with RUNTESTFLAGS='unix/-fsanitize=address'.
The last two hunks fix ICEs while instrumenting atomics with non-standard
sizes, those are always turned into library calls, and the first argument
is the length, not a pointer.
The oth
Mark Kettenis wrote:
> > Date: Mon, 26 Nov 2012 20:10:06 +0100 (CET)
> > From: "Ulrich Weigand"
> >
> > Hello,
> >
> > I noticed what appears to be a long-standing bug in generating .dwarf_frame
> > sections with GCC on Linux on PowerPC.
> >
> > ...
> >
> > So I'm wondering where to go from he
Hi!
E.g. on c_char_tests.f03 we have a stmt like
_2 = VIEW_CONVERT_EXPR(121)[1]{lb: 1 sz: 1};
after inlining (wonder why we never fold that to 121), which asan
incorrectly considered to be a load and thus attempted to instrument it,
by taking address of the rhs.
Fixed thusly, ok for trunk?
201
Mark Wielaard wrote:
> Which other unwinders are out there, that might rely on the current
> numbering?
Well, runtime unwinders using .eh_frame should be fine, since this
uses (and has always used) consistently the GCC numbering. I don't
know if there are other unwinders using .dwarf_frame ...
David Edelsohn wrote:
> On Mon, Nov 26, 2012 at 2:10 PM, Ulrich Weigand wrote:
>
> > So I'm wondering where to go from here. I guess we could:
> >
> > 1. Bring GCC (and gas) behaviour in compliance with the documented ABI
> >by removing the #undef DBX_REGISTER_NUMBER and changing gas's
> >
> Date: Tue, 27 Nov 2012 19:43:40 +0100 (CET)
> From: "Ulrich Weigand"
>
> Mark Kettenis wrote:
> > > Date: Mon, 26 Nov 2012 20:10:06 +0100 (CET)
> > > From: "Ulrich Weigand"
> > >
> > > Hello,
> > >
> > > I noticed what appears to be a long-standing bug in generating
> > > .dwarf_frame
> > >
Hello!
> On Tue, 27 Nov 2012, Jakub Jelinek wrote:
> > On Tue, Nov 27, 2012 at 06:44:23AM -0500, Hans-Peter Nilsson wrote:
>
> JFTR: No I didn't, Eric wrote the below. But, it made sense to me. :)
>
> > > > We apparently have a small conflict between the meaning of volatile
> > > > asms with
> >
The problem is that the symbol gets the host-associated flag as soon as
it is host associated even in the host's namespace. Solution: Test
additionally whether they have been declared in the same namespace.
(I wonder whether there is a case where the host-association is attr is
set and the nam
David Edelsohn writes:
> Below is the implementation as a new target hook.
Looks good to me. The documentation string needs filling in though,
with a hook placeholder in tm.texi.in.
Richard
Eric Botcazou writes:
>> OK, how about:
>>
>> /* ??? For historical reasons, reject modes that would normally
>> receive greater alignment, even if unaligned accesses are
>> acceptable. This has both advantages and disadvantages.
>
> Fine with me.
>
>> I think here we rea
1 - 100 of 127 matches
Mail list logo
