The following patch adds new knob to make GCC perform several iterations of
early optimizations and inlining.
This is for dont-care-about-compile-time-optimize-all-you-can scenarios.
Performing several iterations of optimizations does significantly improve code
speed on a certain proprietary s
On 10/11/11 11:05:18, Eric Botcazou wrote:
> > One easy way to address the current issue is to call
> > tree_int_cst_equal() if the integer constant tree pointers
> > do not match:
> >
> > if ((c1 != c2) && !tree_int_cst_equal (c1, c2))
> > /* integer constants aren't equal. */
>
> You
Richard,
I have a patch for PR50672.
When compiling the testcase from the PR with -ftree-tail-merge, the scenario is
as follows:
We start out tail_merge_optimize with blocks 14 and 20, which are alike, but not
equal, since they have different successors:
...
# BLOCK 14 freq:690
# PRED: 25 [6
2011/10/11 Jason Merrill :
> On 10/10/2011 03:56 PM, Fabien Chêne wrote:
>>
>> It tried to add the target declaration of a USING_DECL in the
>> method_vec of the class where the USING_DECL is declared. Thus, I
>> copied the target decl, adjusted its access, and then called
>> add_method with the ta
On 10/11/2011 12:57 PM, Jason Merrill wrote:
On 10/11/2011 12:55 PM, Jason Merrill wrote:
On 10/09/2011 07:19 PM, Ed Smith-Rowland wrote:
Does cp_parser_identifier (parser) *not* consume the identifier token?
I'm pretty sure it does.
It does.
Does it work to only complain if !cp_parser_par
ok.
David
On Tue, Oct 11, 2011 at 9:51 PM, Dehao Chen wrote:
> Attached is the new patch. Bootstrapped on x86_64, no regressions.
>
> gcc/ChangeLog.google-4_6:
> 2011-10-08 Dehao Chen
>
> Add a flag (-frecord-gcc-switches-in-elf) to record compiler
> command line options to .gnu.s
Attached is the new patch. Bootstrapped on x86_64, no regressions.
gcc/ChangeLog.google-4_6:
2011-10-08 Dehao Chen
Add a flag (-frecord-gcc-switches-in-elf) to record compiler
command line options to .gnu.switches.text sections of
the object file.
* coverage.c (writ
We were not saving enough data in the header of AGGR_INIT_EXPRs.
This does not fix any failures yet (the test case that uses these is
failing due to merging).
Tested on x86_64.
Diego.
* pph-streamer-in.c (pph_read_tree_header): Handle AGGR_INIT_EXPR.
* pph-streamer-out.c (pph_
On Oct 6, 2011, at 10:54 AM, Dr. David Alan Gilbert wrote:
> Test support for ARM 64bit sync intrinsics.
Ok. Watch for any fallout on non-arm systems. I'd always invite people who
think they know the best way to test volatile to chime in. There is the new
infrastructure to test multi core s
> -Original Message-
> From: Hans-Peter Nilsson [mailto:h...@bitrange.com]
> Sent: Wednesday, October 12, 2011 06:57
> To: Joey Ye
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [arm-embedded] Tune loop unrolling for cortex-m
>
> On Wed, 21 Sep 2011, Joey Ye wrote:
>
> > Committed in ARM/em
On 6 October 2011 18:54, Dr. David Alan Gilbert
wrote:
> Test support for ARM 64bit sync intrinsics.
>
> gcc/testsuite/
> * gcc.dg/di-longlong64-sync-1.c: New test.
> * gcc.dg/di-sync-multithread.c: New test.
> * gcc.target/arm/di-longlong64-sync-withhelpers.c: New test
On 6 October 2011 18:53, Dr. David Alan Gilbert
wrote:
> Add support for ARM 64bit sync intrinsics.
>
> gcc/
> * arm.c (arm_output_ldrex): Support ldrexd.
> (arm_output_strex): Support strexd.
> (arm_output_it): New helper to output it in Thumb2 mode only.
>
On 6 October 2011 18:52, Dr. David Alan Gilbert
wrote:
> Micahel K. Edwards points out in PR/48126 that the sync is in the
> wrong place
> relative to the branch target of the compare, since the load could
> float
> up beyond the ldrex.
>
> PR target/48126
>
>
> Any objections to this version of the patch ?
Fine with me though I think it's worthwhile to have such comments
without -dA but that's my personal impression. I don't care either
way.
cheers
Ramana
>
> Cheers
> Nick
>
> gcc/ChangeLog
> 2011-10-05 Nick Clifton
>
> * config/arm/arm.c
On 6 October 2011 18:54, Dr. David Alan Gilbert
wrote:
> Add ARM 64bit sync helpers for use on older ARMs. Based on 32bit
> versions but with check for sufficiently new kernel version.
>
> gcc/
> * config/arm/linux-atomic-64bit.c: New (based on linux-atomic.c)
> * confi
On 6 October 2011 18:52, Dr. David Alan Gilbert
wrote:
> Micahel K. Edwards points out in PR/48126 that the sync is in the
> wrong place
> relative to the branch target of the compare, since the load could
> float
> up beyond the ldrex.
>
> PR target/48126
>
>
On 6 October 2011 18:51, Dr. David Alan Gilbert
wrote:
> gcc/
> * config/arm/arm.c (TARGET_HAVE_DMB_MCR): MCR Not available in Thumb1
Hasn't this been approved ? Please commit this.
cheers
Ramana
>
> diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
> index 993e3a0..f6f1da7
On Fri, Sep 30, 2011 at 5:22 PM, Roman Zhuykov wrote:
> 2011/7/21 :
>> This patch should be applied only after pending patches by Revital.
>
>
> Ping. New version is attached, it suits current trunk without
> additional patches.
Thanks for the ping.
> Also this related patch needs approval:
> h
On Tue, Oct 11, 2011 at 10:32 AM, Joseph S. Myers
wrote:
> The problem comes down to an expression with the difference of two
> pointers being cast to int on a 64-bit system, resulting in
> convert_to_integer moving the conversions inside the subtraction.
> (These optimizations at conversion time
On Wed, 21 Sep 2011, Joey Ye wrote:
> Committed in ARM/embedded-4_6-branch.
>
> 2011-09-21 Jiangning Liu
>
> Tune loop unrolling for cortex-m
> * config/arm/arm-cores.def (cortex-m0): Change to new tune
> cortex_v6m.
> (cortex-m1): Likewise.
> * config/arm/arm-prot
> I see, so we can test the code generation in the testsuite even if the
> compiler was built against an assembler without support for the
> instructions.
At least partially, yes.
> But in such a case, I'm unsure if I understand why i386.exp needs
> these tests at all. The presence of support fo
On Tue, 2011-10-11 at 23:34 +0200, Eric Botcazou wrote:
> > Ok, it has been committed to both the FSF 4.6 and 4.5 branches now.
>
> The ChangeLog entry is in the wrong file, it must be moved to cp/ChangeLog.
Oops, thanks for catching that! Fixed now.
Peter
> I realized this one hasn't made it in, but is really nice. I made a
> number of minor edits (typos, markup, simplifying headings,... among
> others). What do you think -- should we include this?
>
> Many users still won't have GCC 4.6 deployed yet, so I think it's
> still worth it.
>
> Wha
From: Eric Botcazou
Date: Tue, 11 Oct 2011 23:08:50 +0200
>> Cool, Eric could you quickly test the following? This still leaves
>> the i386.exp case issue open, it stands to reason that something like
>> -Wall is needed for those tests too.
>
> I think that we should go the i386 way. This work
> Ok, it has been committed to both the FSF 4.6 and 4.5 branches now.
The ChangeLog entry is in the wrong file, it must be moved to cp/ChangeLog.
--
Eric Botcazou
This is a regression present on mainline and 4.6/4.5 branch. We generate wrong
code for the movcc patterns if the operands of the comparison have TFmode and
TARGET_HARD_QUAD is not set, because we fail to update the comparison code
after going through the comparison routine.
Tested on SPARC/So
On Mon, Oct 10, 2011 at 3:37 PM, Delesley Hutchins wrote:
>
> --- gcc/tree-threadsafe-analyze.c (revision 179771)
> +++ gcc/tree-threadsafe-analyze.c (working copy)
> @@ -1830,14 +1830,27 @@ remove_lock_from_lockset (tree lockable, struct po
This feels like a bug in lock_set_contains(
I committed this patch to mainline to remove an incorrect ChangeLog
entry (the gofrontend directory lives elsewhere; gcc/go/ChangeLog only
applies to the files in gcc/go outside of gcc/go/gofrontend) and to fix
spacing in a Go frontend file.
Ian
Index: gofrontend/gogo-tree.cc
Thanks -- I will back that line out for now and investigate. Regression
test was fine for the languages we normally build, but go and ada aren't
among those. Sorry for the trouble!
On Tue, 2011-10-11 at 14:00 -0700, Ian Lance Taylor wrote:
> On Tue, Oct 11, 2011 at 4:40 AM, Richard Guenther wro
> Cool, Eric could you quickly test the following? This still leaves
> the i386.exp case issue open, it stands to reason that something like
> -Wall is needed for those tests too.
I think that we should go the i386 way. This works on i386 because the
builtins are always available (when you pass
On Tue, Oct 11, 2011 at 4:40 AM, Richard Guenther wrote:
> this function misses to transfer TREE_THIS_NOTRAP which is supposed
> to be set on the base of old_ref or any contained ARRAY[_RANGE]_REF.
> If you make the function generic please adjust it to at least do ...
> ...
>
> TREE_THIS
Currently, the consistency check done on pre-processor symbols is
triggering on symbols that are not really problematic (e.g., symbols
used for double-include guards).
The problem is that in the testsuite, we are refusing to process PPH
images that fail that test, which means we don't get to test
From: Eric Botcazou
Date: Tue, 11 Oct 2011 21:57:18 +0200
>> I would expect that to spit out a warning. Do I need to explicitly
>> add "-Wall", "-Wno-implicit" or similar? Similar tests in i386.exp don't
>> seem to need this and that was what I used as my template.
>
> -Wall does yield a warni
On Oct 11, 2011, at 11:08 AM, Janis Johnson wrote:
> On 10/10/2011 01:19 PM, Janis Johnson wrote:
>> Tests gcc.target/powerpc/warn-[12].c fail for soft-float multilibs with
>> the unexpected warning "-mvsx requires hardware floating point [enabled
>> by default]". This patch skips those tests for
> What does "gcc -mcpu=niagara3 -mvis" give to you for the following
> source file:
>
> long long
> _vis3_fpadd64 (long long __X, long long __Y)
> {
> return __builtin_vis_fpadd64 (__X, __Y);
> }
Nothing at all, with or without the options.
> That's what the sp
This ICE is still a regression in 4.6, so I'm checking in this patch to
fix it. Note that after this patch, the code generated for new T[1]{}
is still wrong, but that isn't a regression. The value-initialization
semantics are fixed in 4.7.
Tested x86_64-pc-linux-gnu.
commit 25a2d664e6a3787cc
On Tue, Oct 11, 2011 at 08:31, wrote:
>
> http://codereview.appspot.com/5247044/diff/1/gcc/cp/pph-streamer.h
> File gcc/cp/pph-streamer.h (right):
>
> http://codereview.appspot.com/5247044/diff/1/gcc/cp/pph-streamer.h#newcode165
> gcc/cp/pph-streamer.h:165: struct pph_stream {
> 165 struct pph_st
From: Eric Botcazou
Date: Tue, 11 Oct 2011 20:10:34 +0200
>> * gcc.target/sparc/sparc.exp: Add vis3 target test.
>
> This doesn't work. The code always compiles:
What does "gcc -mcpu=niagara3 -mvis" give to you for the following
source file:
long long
_vis3_fpadd64 (long
For the 4.6 branch I'm only making the change for scalars.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit d8978a333ab71a4ad2c38446764c1b37092ea098
Author: Jason Merrill
Date: Mon Oct 3 17:06:02 2011 -0400
PR c++/49855
PR c++/49896
* call.c (perform_implicit_conversion_fl
On 10/11/2011 02:19 PM, Jason Merrill wrote:
For the 4.6 branch I'm only making the change for scalars.
Tested x86_64-pc-linux-gnu, applying to trunk.
Er, to 4.6.
On 10/09/2011 07:19 PM, Ed Smith-Rowland wrote:
Does cp_parser_identifier (parser) *not* consume the identifier token?
I'm pretty sure it does.
Does it work to only complain if !cp_parser_parsing_tentatively?
Jason
This patch teaches avr-gcc to skip 2-word instructions like STS and LDS.
It's just about looking into an 2-word insn and check if it's a 2-word
instruction or not.
Passes without regression. Ok to install?
Johann
PR target/49939
* config/avr/avr.md (*movqi): Rename to movqi_insn
> * gcc.target/sparc/sparc.exp: Add vis3 target test.
This doesn't work. The code always compiles:
(botcazou@ob) /nile.build/botcazou/gcc-head/sparc-sun-solaris2.10 $
gcc/xgcc -Bgcc -c -o vis.o vis.c
(botcazou@ob) /nile.build/botcazou/gcc-head/sparc-sun-solaris2.10 $ objdump -d
vis.o
vi
> How about .gnu.switches.text.quote_paths?
Sounds good to me.
-cary
On 10/10/2011 01:19 PM, Janis Johnson wrote:
> Tests gcc.target/powerpc/warn-[12].c fail for soft-float multilibs with
> the unexpected warning "-mvsx requires hardware floating point [enabled
> by default]". This patch skips those tests for soft-float multilibs and
> modifies the powerpc check fo
This patch fixes an error where Annotalysis generates bogus warnings
when using lock and unlock functions that are attached to a base class.
The canonicalize routine did not work correctly in this case.
Bootstrapped and passed gcc regression testsuite on
x86_64-unknown-linux-gnu. Okay for google/
The problem in both of these PRs is that G++ has assumed that we don't
ever need to actually perform non-dependent conversions in a template;
once we know that the conversion can be performed, we just generated a
NOP_EXPR to change the type of the expression. But this isn't good
enough for ini
On Tue, 2011-10-11 at 12:12 -0400, Jason Merrill wrote:
> On 10/11/2011 11:34 AM, Peter Bergner wrote:
> > On Fri, 2011-09-30 at 10:37 -0700, Janis Johnson wrote:
> >> Patch http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00625.html was
> >> approved by Jason last December but I never got around to ch
Hi,
I checked in this patch to remove the extra break.
H.J.
---
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 179810)
+++ config/i386/i386.c (working copy)
@@ -28096,7 +28096,6 @@ ix86_expand_special_args_builtin (
On 10/11/11 10:24:52, Richard Guenther wrote:
> GF: 1. Is it valid to assume that pointer equality is sufficient
> GF: to compare two integer constants for equality as long as they
> GF: have identical type and value?
>
> Yes, if both constants are "live"
The upc blocking factor hash table is dec
On Tue, 11 Oct 2011, Janis Johnson wrote:
> On 10/10/2011 06:23 PM, Joseph S. Myers wrote:
> > On Mon, 10 Oct 2011, Janis Johnson wrote:
> >
> >> This patch skips several Power-specific tests if hard_float support
> >> isn't available. OK for trunk?
> >
> > It looks like these are testing for p
On 10/11/2011 12:55 PM, Jason Merrill wrote:
On 10/09/2011 07:19 PM, Ed Smith-Rowland wrote:
Does cp_parser_identifier (parser) *not* consume the identifier token?
I'm pretty sure it does.
Does it work to only complain if !cp_parser_parsing_tentatively?
I suppose not, if you got no complain
On Tue, Oct 11, 2011 at 11:52 AM, Richard Guenther
wrote:
> On Mon, Oct 10, 2011 at 3:21 PM, Artem Shinkarov
> wrote:
>> On Mon, Oct 10, 2011 at 12:02 PM, Richard Guenther
>> wrote:
>>> On Fri, Oct 7, 2011 at 9:44 AM, Artem Shinkarov
>>> wrote:
On Fri, Oct 7, 2011 at 6:22 AM, Artem Shinkar
On 10/11/2011 11:34 AM, Peter Bergner wrote:
On Fri, 2011-09-30 at 10:37 -0700, Janis Johnson wrote:
Patch http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00625.html was
approved by Jason last December but I never got around to checking
it in. Paolo Carlini said in PR44473 that it was already appr
On 10/10/2011 06:23 PM, Joseph S. Myers wrote:
> On Mon, 10 Oct 2011, Janis Johnson wrote:
>
>> This patch skips several Power-specific tests if hard_float support
>> isn't available. OK for trunk?
>
> It looks like these are testing for particular instructions using FPRs and
> so powerpc_fprs
2011/10/11 Georg-Johann Lay :
> This is a small addendum to PR50447.
>
> It's a change to addsi3 insn; the actual insn sequence printed is still the
> same (except for adding +/-1 to l-reg) but the effect on cc0 is worked out so
> that it can be used to cancel out comparisons like in long loops.
>
2011/10/11 Georg-Johann Lay :
> This is bit of code cleanup and move macro code from avr.h to functions in
> avr.c.
>
> There's no change in functionality. Passed without regressions.
>
> Ok?
>
> Johann
>
> * config/avr/avr-protos.h (avr_mode_code_base_reg_class): New
> prototype.
>
On Tue, Oct 11, 2011 at 3:12 AM, Kirill Yukhin wrote:
> Hi
> Uros, you was right both with fpmath and configflags. That is why it
> was passing for me.
>
> Attached patch which cures the problem.
>
> testsuite/ChangeLog entry:
>
> 2011-10-11 Kirill Yukhin
>
> * gcc.target/i386/fma_double
On Fri, 2011-09-30 at 10:37 -0700, Janis Johnson wrote:
> Patch http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00625.html was
> approved by Jason last December but I never got around to checking
> it in. Paolo Carlini said in PR44473 that it was already approved
> and doesn't need a new approval, so
On 10/10/2011 03:56 PM, Fabien Chêne wrote:
It tried to add the target declaration of a USING_DECL in the
method_vec of the class where the USING_DECL is declared. Thus, I
copied the target decl, adjusted its access, and then called
add_method with the target decl.
Copying the decl is unlikely
This patch fixes PR 50565, a failure to accept certain offsetof-type
expressions in static initializers introduced by my constant
expressions changes. (These expressions are permitted but not
required by ISO C to be accepted; the intent of my constant
expressions model is that they should be valid
Hi,
On Tue, 11 Oct 2011, Kai Tietz wrote:
> So updated version for patch. It creates new simple_operand_p_2
> function instead of modifying simple_operand_p function.
FWIW: I also can't think of a nice short name for that predicate function
:) One thing: move the test for TREE_SIDE_EFFECTS to
On 10/10/2011 03:59 PM, Fabien Chêne wrote:
Sorry but I've failed to see why you called them callers of
lookup_field_1, could you elaborate ?
Hmm, I was assuming that the other functions would have gotten their
decls via lookup_field_1, but I suppose that isn't true for unqualified
lookup tha
On Tue, 2011-10-11 at 09:12 -0500, William J. Schmidt wrote:
> > The pattern matching is still very ad-hoc and doesn't consider
> > statements that feed the base address. There is conceptually
> > no difference between p->a[n] and *(p + n * 4).
>
> That's true. Since we abandoned the general ad
2011/10/11 Michael Matz :
> Hi,
>
> On Tue, 11 Oct 2011, Kai Tietz wrote:
>
>> > Better make it a separate function the first tests your new
>> > conditions, and then calls simple_operand_p.
>>
>> Well, either I make it a new function and call it instead of
>> simple_operand_p,
>
> That's what I me
That looks pretty good, but do you really need to build up a separate
data structure to search? You seem to be searching it in the same order
that it's built up, so why not just walk the expansion chain directly
when searching?
Jason
Hi,
On Tue, 11 Oct 2011, Kai Tietz wrote:
> > Better make it a separate function the first tests your new
> > conditions, and then calls simple_operand_p.
>
> Well, either I make it a new function and call it instead of
> simple_operand_p,
That's what I meant, yes.
> >> @@ -5149,13 +5176,6 @
2011/10/4 Richard Henderson :
> On 10/04/2011 08:42 AM, Joseph S. Myers wrote:
>> On Tue, 4 Oct 2011, Ilya Tocar wrote:
>>
>>> Hi everyone,
>>>
>>> This patch fixes PR 50038 (redundant zero extensions) by modifying
>>> implicit-zee pass
>>> to also remove unneeded zero extensions from QImode to SIm
Hi Richard,
Thanks for the comments -- a few responses below.
On Tue, 2011-10-11 at 13:40 +0200, Richard Guenther wrote:
> On Sat, 8 Oct 2011, William J. Schmidt wrote:
>
>
> > + c4 = uhwi_to_double_int (bitpos / BITS_PER_UNIT);
>
> You don't verify that bitpos % BITS_PER_UNIT is zero anyw
Hi,
on s390 we need a backchain in order to implement
__builtin_return_address for arguments other than 0.
Committed to mainline.
Bye,
-Andreas-
2011-10-11 Andreas Krebbel
* gcc.dg/pr49994-3.c: Add -mbackchain for s390 and s390x.
Index: gcc/testsuite/gcc.dg/pr49994-3.c
==
So updated version for patch. It creates new simple_operand_p_2
function instead of modifying simple_operand_p function.
ChangeLog
2011-10-11 Kai Tietz
* fold-const.c (simple_operand_p_2): New function.
(fold_truthop): Rename to
(fold_truth_andor_1): function name.
> "Sandeep" == Sandeep Soni writes:
Sandeep> The following patch is a basic attempt to build a symbol table that
Sandeep> stores the names of all the declarations made in the input file.
I don't know anything about gimplefe, but unless you have complicated
needs, it is more usual to just put
> It isn't a standoff, we can choose to just fix the issue and be compatible,
> if we want.
I guess you're right and I'm probably using the wrong word - English is not my
first language. ;-)
But I meant that they could have made the same choice to be compatible (by
fixing the issue
in their co
On 10/11/2011 01:40 PM, Richard Guenther wrote:
The pattern matching is still very ad-hoc and doesn't consider
statements that feed the base address. There is conceptually
no difference between p->a[n] and *(p + n * 4). You placed this
lowering in reassoc to catch CSE opportunities with DOM, ri
OK.
Jason
2011/10/11 Michael Matz :
> Hi,
>
> On Mon, 10 Oct 2011, Kai Tietz wrote:
>
>> To ensure that we use simple_operand_p in all cases, beside for
>> branching AND/OR chains, in same way as before, I added to this function
>> an additional argument, by which the looking into comparisons can be
>> activ
Hi,
tested x86_64-linux, committed.
Paolo.
2011-10-11 Emil Wojak
PR c++/50661
* include/bits/stl_algobase.h (equal): Compare arrays of pointers
too with memcmp.
Index: include/bits/stl_algobase.h
==
Bernd Schmidt writes:
> On 10/09/11 10:01, Richard Sandiford wrote:
>> Reload 0: GR_REGS, RELOAD_FOR_OUTPUT_ADDRESS (opnum = 0), can't combine,
>> secondary_reload_p
>> reload_reg_rtx: (reg:SI 5 $5)
>> Reload 1: reload_out (SI) = (reg:SI 32 $f0 [1655])
>> MD1_REG, RELOAD_FOR_OUTPU
http://codereview.appspot.com/5247044/diff/1/gcc/cp/pph-streamer.h
File gcc/cp/pph-streamer.h (right):
http://codereview.appspot.com/5247044/diff/1/gcc/cp/pph-streamer.h#newcode165
gcc/cp/pph-streamer.h:165: struct pph_stream {
165 struct pph_stream {
You need the typedef. Stage 1 is still bui
This is a small addendum to PR50447.
It's a change to addsi3 insn; the actual insn sequence printed is still the
same (except for adding +/-1 to l-reg) but the effect on cc0 is worked out so
that it can be used to cancel out comparisons like in long loops.
cc insn attribute gets one more alternat
Hi,
for this largish testcase (reduced from a big one by Jakub) we ICE due
to error reporting routines re-entered. In 4_6-branch the situation is
worse, because for the original testcase we don't produce any useful
diagnostics at all before ICEing.
Thus the below, which seems pretty straight
Hi,
On Mon, 10 Oct 2011, Kai Tietz wrote:
> To ensure that we use simple_operand_p in all cases, beside for
> branching AND/OR chains, in same way as before, I added to this function
> an additional argument, by which the looking into comparisons can be
> activated.
Better make it a separate
Since we have the alias oracle we no longer optimize the testcase below
because I initially restricted the stmt walking to give up for PHIs
with more than 2 arguments because of compile-time complexity issues.
But it's easy to see that compile-time is not an issue when we
reduce PHI args pairwise
On Sat, 8 Oct 2011, William J. Schmidt wrote:
> Greetings,
>
> Here are the revised changes for the tree portions of the patch. I've
> attempted to resolve all comments to date on those portions. Per
> Steven's comment, I moved copy_ref_info into tree-ssa-address.c; let me
> know if there's a b
Hi,
in the 20090223-1.c gcc complains about functions possibly not being
inlined although they have the always_inline attribute on it. The
original failure could only be observed with these functions being
inlined. The attached patch forces GCC to suppress the warning.
Committed to mainline.
By
On 10/11/2011 03:04 AM, Jason Merrill wrote:
On 10/10/2011 12:40 PM, Paolo Carlini wrote:
+ // The fraction 643/2136 approximates log10(2) to 7 significant
digits.
+ int max_digits10 = 2 + (is_decimal ? fmt->p : fmt->p * 643L / 2136);
Please cite N1822 in the comment and convert it to C syn
On Mon, Oct 10, 2011 at 3:21 PM, Artem Shinkarov
wrote:
> On Mon, Oct 10, 2011 at 12:02 PM, Richard Guenther
> wrote:
>> On Fri, Oct 7, 2011 at 9:44 AM, Artem Shinkarov
>> wrote:
>>> On Fri, Oct 7, 2011 at 6:22 AM, Artem Shinkarov
>>> wrote:
On Wed, Oct 5, 2011 at 12:35 PM, Richard Guenthe
I'm not completely following this yet, so please bear with me...
On 10/09/11 10:01, Richard Sandiford wrote:
> Reload 0: GR_REGS, RELOAD_FOR_OUTPUT_ADDRESS (opnum = 0), can't combine,
> secondary_reload_p
> reload_reg_rtx: (reg:SI 5 $5)
> Reload 1: reload_out (SI) = (reg:SI 32 $f0 [1655])
Thank you!
K
On Tue, Oct 11, 2011 at 2:19 PM, Uros Bizjak wrote:
> On Tue, Oct 11, 2011 at 12:12 PM, Kirill Yukhin
> wrote:
>
>> Uros, you was right both with fpmath and configflags. That is why it
>> was passing for me.
>>
>> Attached patch which cures the problem.
>>
>> testsuite/ChangeLog e
On Tue, Oct 11, 2011 at 12:12 PM, Kirill Yukhin wrote:
> Uros, you was right both with fpmath and configflags. That is why it
> was passing for me.
>
> Attached patch which cures the problem.
>
> testsuite/ChangeLog entry:
>
> 2011-10-11 Kirill Yukhin
>
> * gcc.target/i386/fma_double_1.
Hi
Uros, you was right both with fpmath and configflags. That is why it
was passing for me.
Attached patch which cures the problem.
testsuite/ChangeLog entry:
2011-10-11 Kirill Yukhin
* gcc.target/i386/fma_double_1.c: Add -mfpmath=sse.
* gcc.target/i386/fma_double_2.c: Ditto.
On Oct 11, 2011, at 2:05 AM, Nicola Pero wrote:
>>> Unfortunately, the report was correct in that clang is producing incorrect
>>> code and
>>> abusing the higher bits of the class->info field to store some other
>>> information.
>>
>> The clang folks are pretty responsive. I'd always give them
Hi!
This patch generates LDRD instead of POP in epilogue for A15 ARM mode.
For optimize_size, original epilogue is generated for A15.
The work involves defining new functions, predicates and patterns.
In this patch we keep on accumulating non-consecutive registers till
register-pair to be popped
Hi!
This patch generates STRD instead of PUSH in prologue for A15 ARM mode.
For optimize_size, original prologue is generated for A15.
The work involves defining new functions, predicates and patterns, along
with minor changes in existing code:
* STRD in ARM mode needs consecutive registers to be
Hi!
This patch generates STRD instruction instead of PUSH in thumb2 mode for
A15.
For optimize_size, original prologue is generated for A15.
The work involves defining new functions, predicates and patterns.
The patch is tested with check-gcc, check-gdb and bootstrap with no
regression.
Change
Hi!
This patch generates LDRD instead of POP for Thumb2 epilogue in A15.
For optimize_size, original epilogue is generated for A15.
The work involves defining new functions, predicates and patterns.
As LDRD cannot be generated for PC, if PC is in register-list, LDRD is
generated for all other r
Hi!
This patch adds new field in tune_params to indicate if LDRD/STRD are
preferred over PUSH/POP in prologue/epilogue of specific core.
It also creates new tune for cortex-A15 and updates tunes for other
cores to set new field to default value.
Changelog entry for Patch to create tune for corte
> In fact, the integer constant was needed because it appeared
> in the blocking factor hash table, but not via a direct pointer.
> Rather it was referenced by nature of the fact that
> the blocking factor hash table referenced the integer constant
> that is mapped in the integer constant hash tabl
This series of 5 patches generate LDRD/STRD instead of POP/PUSH in
epilogue/prologue for ARM and Thumb-2 mode of A15.
Patch [1/5] introduces new field in tune which can be used to indicate
whether LDRD/STRD are preferred over POP/PUSH by the specific core.
Patches [2-5/5] use this field to determ
>> Unfortunately, the report was correct in that clang is producing incorrect
>> code and
>> abusing the higher bits of the class->info field to store some other
>> information.
>
> The clang folks are pretty responsive. I'd always give them a chance to
> `fix' thier code, before putting hack-
1 - 100 of 103 matches
Mail list logo
