> Again: Is this really the direction we should be going in? (I haven't
> any better ideas...)
Do you mean for self-referencing notes? If so, definitely, these notes are
either wrong or almost always redundant so we should eliminate them.
As for the more general problem of REG_EQ* notes, perhap
Hello,
Attached patch intends to fix a bug on how to check argument register number
which should consider the PCS. A test case is also included. Without this
fix, one of the function argument will be overridden in the case. Tested on
QEMU for cortex-m3, no regression found. Is it OK to trunk?
BR,
Hi,
I back ported r193841 from TRUNK to ARM Embedded-4_7-branch as r193881.
Thanks.
Hi,
Please find attached the patch “asm-subreg.patch” for aarch64 which
fixes ICE for /gcc.dg/torture/asm-subreg-1.c testcase.
The error was the result of reload problems in
“aarch64_load_symref_appropriately” function.
The higher part of symbol_ref moved to temporary RTX “tmp_reg” does
not cont
On Tue, Nov 27, 2012 at 8:47 PM, Hurugalawadi, Naveen
wrote:
> Hi,
>
> Please find attached the patch “asm-subreg.patch” for aarch64 which
> fixes ICE for /gcc.dg/torture/asm-subreg-1.c testcase.
>
> The error was the result of reload problems in
> “aarch64_load_symref_appropriately” function.
>
>
Hi,
Please find attached the patch “asm-subreg.patch” for aarch64 which
fixes ICE for /gcc.dg/torture/asm-subreg-1.c testcase.
The error was the result of reload problems in
“aarch64_load_symref_appropriately” function.
The higher part of symbol_ref moved to temporary RTX “tmp_reg” does
not c
Here is a final patch for PR52654 hopefully.
Ultimately we should probably revisit this and 54413 by parsing the literal
numbers in the C++ front end. That won't happen for 4.8.
This builds and passes on x86_64-linux.
Ed
Index: gcc/c-family/c-lex.c
On Sun, Oct 7, 2012 at 8:56 AM, Richard Sandiford
wrote:
> Eric Botcazou writes:
>>> I think modelling it as a TRUNCATE operation is correct for
>>> !TRULY_NOOP_TRUNCATION (it's the bug that Andrew pointed out).
>>> And we shouldn't generate an actual TRUNCATE rtx for
>>> TRULY_NOOP_TRUNCATION (t
> -Original Message-
> From: Richard Earnshaw
> Sent: Wednesday, November 28, 2012 2:02 AM
> To: Bin Cheng
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH ARM] Disable "-fira-hoist-pressure" on Thumb2
>
> On 27/11/12 10:10, Bin Cheng wrote:
> > Hi,
> > I committed the patch implementin
On 26 November 2012 23:51, Jonathan Wakely wrote:
> PR libstdc++/55463
> * include/std/functional (_Mem_fn): Handle rvalue objects. Add
> noexcept-specifications.
> * testsuite/20_util/function_objects/mem_fn/55463.cc: New.
> * testsuite/20_util/bind/ref_neg.
On Wed, Nov 28, 2012 at 12:58 AM, Steven Bosscher wrote:
> On Wed, Nov 28, 2012 at 12:53 AM, Steven Bosscher wrote:
>> On Wed, Nov 28, 2012 at 12:47 AM, Eric Botcazou wrote:
Count me in, too. So let's avoid it:
* gcse.c (struct reg_use): Remove unused struct.
(
As part of a code analysis experiment, the gc compiler implements a
feature based on comments: if a //go:nointerface comment appears before
a method for a type, that method is not included in any interfaces.
This works in conjunction with a field tracking feature, not yet
implemented in gccgo, that
On Wed, Nov 28, 2012 at 12:53 AM, Steven Bosscher wrote:
> On Wed, Nov 28, 2012 at 12:47 AM, Eric Botcazou wrote:
>>> Count me in, too. So let's avoid it:
>>>
>>> * gcse.c (struct reg_use): Remove unused struct.
>>> (gcse_emit_move_after): Do not create REG_EQUAL notes that referen
On Wed, Nov 28, 2012 at 12:47 AM, Eric Botcazou wrote:
>> Count me in, too. So let's avoid it:
>>
>> * gcse.c (struct reg_use): Remove unused struct.
>> (gcse_emit_move_after): Do not create REG_EQUAL notes that reference
>> the SET_DEST of the instruction the note would be attache
> Count me in, too. So let's avoid it:
>
> * gcse.c (struct reg_use): Remove unused struct.
> (gcse_emit_move_after): Do not create REG_EQUAL notes that reference
> the SET_DEST of the instruction the note would be attached to.
OK (with PR rtl-optimization/55006) if it passes boo
On Tue, Nov 27, 2012 at 5:57 PM, Eric Botcazou wrote:
>> 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.
Count me in, too. So let's avoid it:
* gcse.c (struct reg_
On Tue, Nov 27, 2012 at 8:47 PM, Mike Stump wrote:
> On Nov 27, 2012, at 8:51 AM, James Greenhalgh
> wrote:
>> In particular, we add support for vectorizing across:
>>
>> ceil (), ceilf (), lceil (),
>
>> We add testcases ensuring that each of the expected functions are
>> vectorized. As the i38
> I suppose I was putting too much store by the expmed.c code. How does
> this version look? Tested on x86_64-linux-gnu, powerpc64-linux-gnu
> and cris-elf.
>
> Richard
>
>
> gcc/
> PR middle-end/55438
> * expmed.c (simple_mem_bitfield_p): New function, extracted from
> store
On Tue, Nov 27, 2012 at 8:22 PM, Richard Sandiford
wrote:
> Ramana Radhakrishnan writes:
>>> 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 -mar
The following patch fixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55458
The patch was successfully bootstrapped and tested on x86/x86-64.
Committed as rev. 193871.
2012-11-27 Vladimir Makarov
PR rtl-optimization/55458
* lra-assigns.c: Include rtl-error.h.
2012/11/27 Tobias Burnus :
> 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-associ
On Tue, Nov 27, 2012 at 2:07 AM, Richard Biener
wrote:
> 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 optio
This patch fixes an incorrect invocation of the @headername Doxygen
macro. Namely, multiple values must be separated by commas, not "or".
The effect can be observed at
http://gcc.gnu.org/onlinedocs/gcc-4.7.2/libstdc++/api/a01484.html:
"This is an internal header file, included by other library h
On Nov 27, 2012, at 8:51 AM, James Greenhalgh wrote:
> In particular, we add support for vectorizing across:
>
> ceil (), ceilf (), lceil (),
> We add testcases ensuring that each of the expected functions are
> vectorized. As the i386 and rs6000 backends both ostensibly support
> these optimisa
On Tue, Nov 27, 2012 at 3:17 PM, Richard Sandiford
wrote:
> 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.
Yes.
Thanks, David
Hi,
On Tue, Nov 27, 2012 at 02:02:42PM +0100, Richard Biener wrote:
> 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 a
Ramana Radhakrishnan writes:
>> 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
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
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
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
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
> >
> 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
> > >
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
> >
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 ...
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 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!
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
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
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 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.
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
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
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)) ==
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 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 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
> 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
> 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
>
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~
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 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 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
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
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
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
> 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
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
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
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:
>
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
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
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,
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:
> 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
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
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
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
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).
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
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: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
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
> 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:|
|
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.
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
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
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
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.
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
> 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 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
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, 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 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 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
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
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
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
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 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
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 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
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 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 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 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 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 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, 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 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
1 - 100 of 127 matches
Mail list logo
