Hello,
The issue rate is currently been set in SMS by calling
targetm.sched.issue_rate function if it is defined. For rs6000 the
issue_rate is 1 if !reload_completed && !flag_sched_pressure.
To bypass that, SMS sets reload_completed to 1 before calling
targetm.sched.issue_rate and restores it's
On Wed, 18 May 2011 21:04:39 +0200
Pierre Vittet wrote:
> Hello,
>
> I have written a patch to allow the use of the GCC dominance functions
> into MELT.
[...]
> Changelog:
> 2011-05-17 Pierre Vittet
>
> * melt/xtramelt-ana-base.melt
> (is_dominance_info_available, is_post_dominanc
Hello,
The attached patch contains misc. fixes and changes.
The patch was tested together with the rest of the patches in this series.
On ppc64-redhat-linux regtest as well as bootstrap with SMS flags
enabling SMS also on loops with stage count 1. Regtested on SPU.
On arm-linux-gnueabi regtseted
Hello,
The attach patch tries to achieve optimised SC by normalizing the partial
schedule (having the cycles start from cycle zero). The branch location
must be placed in row ii-1 in the final scheduling. If that's not the
case after the normalization then it tries to move the branch to that
row
Hello,
The attached patch moves the creation of anti-dep edge from a
branch to it's def from create_ddg_dep_from_intra_loop_link () to
add_cross_iteration_register_deps () due to the fact the edge is with
distance 1 and thus should be in the later function.
The edge was added to avoid creating re
Hello,
The calculation of the number of instructions in a row is currently
done by updating row_rest_count field in struct ps_insn on the fly
while creating a new instruction. It is used to make sure we do not
exceed
the issue_rate.
This calculation assumes the instruction is inserted in the begi
2011-05-18 Jonathan Wakely
* include/bits/shared_ptr_base.h: Use noexcept. Define special member
functions as defaulted/deleted.
* include/bits/shared_ptr.h: Use noexcept.
* 20_util/shared_ptr/cons/43820_neg.cc: Adjust dg-error line numbers.
* 20_util/wea
The attached is the revised patch. Bootstrap and regression tested in
trunk on x86-64/linux.
Ok for checkin?
Thanks,
David
On Wed, May 18, 2011 at 1:34 PM, Xinliang David Li wrote:
> Will fix the Changelog, and add documentation.
>
> Thanks,
>
> David
>
>
>
> On Wed, May 18, 2011 at 1:26 PM, R
It seems like you're calculating maxbits correctly now, but an access
doesn't necessarily start from the beginning of the sequence of
bit-fields, especially given store_split_bit_field. That is,
struct A
{
int i;
int j: 32;
int k: 8;
char c[2];
};
Here maxbits would be 40, so we decid
This patch fixes three occurrences of "it's" with an incorrect apostrophe.
2011-05-18 Jonathan Wakely
* doc/xml/manual/bitmap_allocator.xml: Fix typos.
tested with 'make doc-xml-validate-docbook' and committed to trunk
I didn't bother regenerating the HTML for this, I'll do so next t
On Wed, May 18, 2011 at 10:37 PM, H.J. Lu wrote:
> This patch properly handles 256bit load cast. OK for trunk if there
> is no regression? I will also prepare a patch for 4.6 branch.
> 2011-05-18 H.J. Lu
>
> PR target/49002
> * config/i386/sse.md
> (avx__):
> Properly
Hi,
> + sa_cost = (TREE_CODE (expr) != MINUS_EXPR
> + ? shiftadd_cost[speed][mode][m]
> + : (mult == op1
> +? shiftsub1_cost[speed][mode][m]
> +: shiftsub0_cost[speed][mode][m]));
> + res = new_cost (sa_cost, 0);
> + res = add_costs (res,
Hi,
> Resubmitting with comment.
>
> This improves the estimation of cost of bound calculation:
> - It tries to estimate whether an ssa_name can be used in the loop
> at zero cost, or whether a regcopy is needed to keep the ssa_name
> alive during the loop, and counts the cost of the regcopy.
Hi,
> This patch attemps to estimate the number of iterations of the loop based on
> nonwrapping arithmetic in the loop body.
>
> 2011-05-05 Tom de Vries
>
> PR target/45098
> * tree-ssa-loop-ivopts.c (struct ivopts_data): Add fields
> max_iterations_p and max_iterations.
>
On 05/11/2011 08:26 AM, Jakub Jelinek wrote:
This patch duplicates parts of the gimplifier's work during genericization,
That seems unfortunate, but I'll accept your judgment that it's the
least-bad solution. The patch is OK.
Jason
Hello world,
the attached patch does the following:
- It removes the restriction on functions returning allocatables
for elimination (unnecessary since the introduction of allocatable
temporary variables)
- It allows character function elimination if the character length is
a constant kno
Hi,
> Resubmitting with comment.
>
> The init cost of an iv will in general not be zero. It will be
> exceptional that the iv register happens to be initialized with the
> proper value at no cost. In general, there will at the very least be a
> regcopy or a const set.
OK. Please add a comment e
On Wed, May 18, 2011 at 10:44 PM, Toon Moene wrote:
> On 05/18/2011 10:31 PM, Richard Guenther wrote:
>
>> Not that I'm too excited to see GCC built with a C++ compiler (or even C++
>> features being used).
>
> Hmmm, you think using "false" as a value for a pointer-returning function is
> just A-O
On 05/18/2011 10:31 PM, Richard Guenther wrote:
Not that I'm too excited to see GCC built with a C++ compiler (or even C++
features being used).
Hmmm, you think using "false" as a value for a pointer-returning
function is just A-OK ?
Duh, I'm glad I'm using Fortran, where the programmer isn
Hi,
This patch properly handles 256bit load cast. OK for trunk if there
is no regression? I will also prepare a patch for 4.6 branch.
Thanks.
H.J.
--
gcc/
2011-05-18 H.J. Lu
PR target/49002
* config/i386/sse.md
(avx__):
Properly handle load cast.
gcc/testsuite/
On Wed, May 18, 2011 at 10:32:49PM +0200, Richard Guenther wrote:
> On Wed, May 18, 2011 at 10:21 PM, Jakub Jelinek wrote:
> > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk/4.6?
>
> Ok.
Thanks.
> Isn't it latent on the 4.5 branch as well?
Not only latent, execute/pr49039
Will fix the Changelog, and add documentation.
Thanks,
David
On Wed, May 18, 2011 at 1:26 PM, Richard Guenther
wrote:
> On Wed, May 18, 2011 at 8:37 PM, David Li wrote:
>>
>> In gcc, not all passes have user level control to turn it on/off, and
>> there is no way to flip on/off the pass for
On Wed, May 18, 2011 at 10:21 PM, Jakub Jelinek wrote:
> Hi!
>
> The testcases below are miscompiled (execute/ by 4.6/4.7, pr49039.C
> by 4.6 and twice so by 4.7 (so much that it doesn't abort)), because
> VRP thinks that
> MIN_EXPR <~[-1UL, -1UL], ~[0, 0]> is ~[0, 0] (correct is VARYING and simil
On Wed, May 18, 2011 at 10:17 PM, Toon Moene wrote:
> On 05/18/2011 05:41 AM, Gabriel Dos Reis wrote:
>
>> On Tue, May 17, 2011 at 2:46 PM, Toon Moene wrote:
>
>>> On 05/17/2011 08:32 PM, Uros Bizjak wrote:
>>>
Tested on x86_64-pc-linux-gnu {, m32} with --enable-build-with-cxx.
Committe
On Wed, May 18, 2011 at 8:37 PM, David Li wrote:
>
> In gcc, not all passes have user level control to turn it on/off, and
> there is no way to flip on/off the pass for a subset of functions. I
> implemented a generic option handling scheme in gcc to allow
> disabling/enabling any gcc pass for any
Hi!
The testcases below are miscompiled (execute/ by 4.6/4.7, pr49039.C
by 4.6 and twice so by 4.7 (so much that it doesn't abort)), because
VRP thinks that
MIN_EXPR <~[-1UL, -1UL], ~[0, 0]> is ~[0, 0] (correct is VARYING and similarly
MAX_EXPR <~[-1UL, -1UL], ~[0, 0]> is ~[-1UL, -1UL]).
On Wed, May 18, 2011 at 7:20 PM, Jan Hubicka wrote:
>>
>> We can end up with an infinite recursion as gimple_register_type
>> tries to register TYPE_MAIN_VARIANT first. This is because we
>> are being called from the LTO type-fixup code which walks the
>> type graph and adjusts types to their lea
On 05/18/2011 05:41 AM, Gabriel Dos Reis wrote:
On Tue, May 17, 2011 at 2:46 PM, Toon Moene wrote:
On 05/17/2011 08:32 PM, Uros Bizjak wrote:
Tested on x86_64-pc-linux-gnu {, m32} with --enable-build-with-cxx.
Committed to mainline SVN as obvious.
Does that mean that I can now remove the
Hi,
the attached patch updates the documentation and error messages for
the -ffpe-trap= option:
- The IEEE 754 name for the "loss of precision" exception is
"inexact", and not "precision" (both in 754-1985 and 754-2008). So use
that instead, while still allowing precision as an alias for inexact
This patch continues the cleanup of ARM option handling by making
-mfpu= handling use Enum, with the table of FPUs moved to a new
arm-fpus.def.
Tested building cc1 and xgcc for cross to arm-eabi. Will commit to
trunk in the absence of target maintainer objections.
contrib:
2011-05-18 Joseph Mye
Verified identical binaries created and submitted.
Mark
On Wed, May 18, 2011 at 11:37 AM, Xinliang David Li wrote:
> Ok with that change to google/main with some retesting.
>
> David
>
> On Wed, May 18, 2011 at 11:34 AM, Mark Heffernan wrote:
>> On Wed, May 18, 2011 at 10:52 AM, Xinliang David
On 05/18/2011 03:00 PM, Nathan Froyd wrote:
Thank you for the review. I'll go back and try things the way you suggest;
before I go off and do that, I've taken your comments to mean that:
- fn_type_unification/type_unification_real and associated callers should take
a boolean `explain' parame
Thanks for the comment. Will fix those.
David
On Wed, May 18, 2011 at 12:30 PM, Joseph S. Myers
wrote:
> On Wed, 18 May 2011, David Li wrote:
>
>> + error ("Unrecognized option %s", is_enable ? "-fenable" :
>> "-fdisable");
>
>> + error ("Unknown pass %s specified in %s",
>> +
On Wed, 18 May 2011, DJ Delorie wrote:
> What about these?
>
> dependencies = { module=all-target-fastjar; on=all-target-libiberty; };
Bogus. fastjar is not a target module, not should it be one; all
references to target fastjar should be removed.
> dependencies = { module=all-target-libobjc;
What about these?
dependencies = { module=all-target-fastjar; on=all-target-libiberty; };
dependencies = { module=all-target-libobjc; on=all-target-libiberty; };
dependencies = { module=all-target-libstdc++-v3; on=all-target-libiberty; };
On Wed, 18 May 2011, David Li wrote:
> + error ("Unrecognized option %s", is_enable ? "-fenable" : "-fdisable");
> + error ("Unknown pass %s specified in %s",
> + phase_name,
> + is_enable ? "-fenable" : "-fdisable");
Follow GNU Coding Standards for diagnostics (start
On Wed, 18 May 2011, DJ Delorie wrote:
> At this point, though, I'm tempted to say "there's no such thing as a
> target libiberty" and rip all the target-libiberty rules out, and let
Yes please. I've been arguing for that for some time.
http://gcc.gnu.org/ml/gcc/2009-04/msg00410.html
http://gcc
>> The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk?
>
> OK. Thanks for the patch!
Thanks, Tobias. Committed as r173874.
> (What next on your gfortran agenda?)
Well, I am pretty busy with my "day job" at university and working on
my PhD, which will not allow me to make huge lea
Hello,
I have written a patch to allow the use of the GCC dominance functions
into MELT.
This is made in order to abstract the use of calculate_dominance_info
and free_dominance_info:
If the user use one of the MELT dominance related functions, it
will only call calculate_dominance_info
On 05/18/2011 01:45 PM, Jason Merrill wrote:
>> Thanks for the background; I will keep the principle in mind. IMHO, in
>> a case like this where we're logically printing one diagnostic (one
>> error and then some number of explanatory notes) keeping all the logic
>> for the diagnostic centralized
Ok with that change to google/main with some retesting.
David
On Wed, May 18, 2011 at 11:34 AM, Mark Heffernan wrote:
> On Wed, May 18, 2011 at 10:52 AM, Xinliang David Li
> wrote:
>> The new change won't help those. Your original place will be ok if you
>> test profile_arcs and branch_probabi
In gcc, not all passes have user level control to turn it on/off, and
there is no way to flip on/off the pass for a subset of functions. I
implemented a generic option handling scheme in gcc to allow
disabling/enabling any gcc pass for any specified function(s). The
new options will be very usefu
Hello!
This macro compiles by pure luck.
2011-05-18 Uros Bizjak
* config/i386/mingw32.h (OUTPUT_QUOTED_STRING): Fix macro
argument expansion.
Patch was compile tested by crosscompiling to ming32 target.
OK for mainline?
Uros.
Index: mingw32.h
===
On Wed, May 18, 2011 at 10:52 AM, Xinliang David Li wrote:
> The new change won't help those. Your original place will be ok if you
> test profile_arcs and branch_probability flags.
Ah, yes. I see your point now. Reverted to the original change with
condition profile_arc_flag and flag_branch_pro
2011/5/18 Kai Tietz :
> Hello
>
> As follow-up for logical to binary transition
>
> 2011-05-18 Kai Tietz
>
> * tree-cfg.c (verify_gimple_assign_binary): Barf on
> TRUTH_AND_EXPR, TRUTH_OR_EXPR, and TRUTH_XOR_EXPR.
> (gimplify_expr): Boolify TRUTH_ANDIF_EXPR, TRUTH_ORIF_EXPR,
Hi Zdenek,
On 05/18/2011 05:24 PM, Zdenek Dvorak wrote:
> Hi,
>
>> How about:
>> ...
>> @@ -2866,6 +2878,8 @@ computation_cost (tree expr, bool speed)
>>if (MEM_P (rslt))
>> cost += address_cost (XEXP (rslt, 0), TYPE_MODE (type),
>>TYPE_ADDR_SPACE (type), speed);
On May 18 14:03, DJ Delorie wrote:
>
> > And the problem is that libiberty is assuming that it *knows* what
> > functions newlib provides, so that it doesn't need to check
> > directly. This is just broken...
>
> Historically, cygwin was built using libiberty and newlib, so you did
> not have a
Hi,
tested x86_64-linux, committed.
Thanks,
Paolo.
//
2011-05-18 Paolo Carlini
* libsupc++/initializer_list: Use noexcept specifier.
(initializer_list<>::size, begin, end): Qualify as const.
* include/bits/move.h (__addressof, forward, move, addressof
> And the problem is that libiberty is assuming that it *knows* what
> functions newlib provides, so that it doesn't need to check
> directly. This is just broken...
Historically, cygwin was built using libiberty and newlib, so you did
not have a runtime at the time you were building libiberty,
Though not common, people can do this:
1. for profile gen:
gcc -fprofile-arcs ...
2. for profile use
gcc -fbranch-probabilities ...
The new change won't help those. Your original place will be ok if you
test profile_arcs and branch_probability flags.
David
On Wed, May 18, 2011 at 10:39 AM, Ma
On Tue, 2011-05-17 at 12:48 -0400, DJ Delorie wrote:
> > What I don't understand is why the newlib change broke older compilers.
>
> Older compilers have the older libiberty. At the moment, libiberty
> cannot be built by *any* released gcc, because you cannot *build* any
> released gcc, because
On Tue, May 17, 2011 at 11:34 PM, Xinliang David Li wrote:
> flag_profile_arcs and flag_branch_probabilities. -fprofile-use
> enables profile-arcs, and value profiling is enabled only when
> edge/branch profiling is enabled (so no need to be checked).
I changed the location where these parameter
Thanks for the background; I will keep the principle in mind. IMHO, in
a case like this where we're logically printing one diagnostic (one
error and then some number of explanatory notes) keeping all the logic
for the diagnostic centralized makes more sense.
I understand, but that means we have
Hello!
2011-05-18 Uros Bizjak
* config/i386/i386.md (*tls_global_dynamic_32_gnu): Split asm template.
(*tls_global_dynamic_64): Ditto.
(*tls_local_dynamic_base_32_gnu): Ditto.
(*tls_local_dynamic_base_64): Ditto.
(tls_initial_exec_64_sun): Ditto.
No fun
On 05/17/2011 09:24 AM, Tom de Vries wrote:
> On 05/17/2011 09:10 AM, Tom de Vries wrote:
>> Hi Zdenek,
>>
>> I have a patch set for for PR45098.
>>
>> 01_object-size-target.patch
>> 02_pr45098-rtx-cost-set.patch
>> 03_pr45098-computation-cost.patch
>> 04_pr45098-iv-init-cost.patch
>> 05_pr45098-bo
On 05/17/2011 09:21 AM, Tom de Vries wrote:
> On 05/17/2011 09:10 AM, Tom de Vries wrote:
>> Hi Zdenek,
>>
>> I have a patch set for for PR45098.
>>
>> 01_object-size-target.patch
>> 02_pr45098-rtx-cost-set.patch
>> 03_pr45098-computation-cost.patch
>> 04_pr45098-iv-init-cost.patch
>> 05_pr45098-bo
On 05/17/2011 09:21 AM, Tom de Vries wrote:
> On 05/17/2011 09:10 AM, Tom de Vries wrote:
>> Hi Zdenek,
>>
>> I have a patch set for for PR45098.
>>
>> 01_object-size-target.patch
>> 02_pr45098-rtx-cost-set.patch
>> 03_pr45098-computation-cost.patch
>> 04_pr45098-iv-init-cost.patch
>> 05_pr45098-bo
>
> We can end up with an infinite recursion as gimple_register_type
> tries to register TYPE_MAIN_VARIANT first. This is because we
> are being called from the LTO type-fixup code which walks the
> type graph and adjusts types to their leaders. So we can
> be called for type SCCs that are only
On 05/11/2011 05:27 PM, Jason Merrill wrote:
We want to allow a constexpr friend function that takes the current
class, so we need to defer checking the literality of parameter types
until any classes involved are complete.
It was pointed out to me that the restriction already only applies to
On 05/17/2011 09:20 AM, Tom de Vries wrote:
> On 05/17/2011 09:10 AM, Tom de Vries wrote:
>> Hi Zdenek,
>>
>> I have a patch set for for PR45098.
>>
>> 01_object-size-target.patch
>> 02_pr45098-rtx-cost-set.patch
>> 03_pr45098-computation-cost.patch
>> 04_pr45098-iv-init-cost.patch
>> 05_pr45098-bo
On 05/17/2011 09:19 AM, Tom de Vries wrote:
> On 05/17/2011 09:10 AM, Tom de Vries wrote:
>> Hi Zdenek,
>>
>> I have a patch set for for PR45098.
>>
>> 01_object-size-target.patch
>> 02_pr45098-rtx-cost-set.patch
>> 03_pr45098-computation-cost.patch
>> 04_pr45098-iv-init-cost.patch
>> 05_pr45098-bo
On 05/17/2011 09:18 AM, Tom de Vries wrote:
> On 05/17/2011 09:10 AM, Tom de Vries wrote:
>> Hi Zdenek,
>>
>> I have a patch set for for PR45098.
>>
>> 01_object-size-target.patch
>> 02_pr45098-rtx-cost-set.patch
>> 03_pr45098-computation-cost.patch
>> 04_pr45098-iv-init-cost.patch
>> 05_pr45098-bo
On 05/17/2011 09:17 AM, Tom de Vries wrote:
> On 05/17/2011 09:10 AM, Tom de Vries wrote:
>> Hi Zdenek,
>>
>> I have a patch set for for PR45098.
>>
>> 01_object-size-target.patch
>> 02_pr45098-rtx-cost-set.patch
>> 03_pr45098-computation-cost.patch
>> 04_pr45098-iv-init-cost.patch
>> 05_pr45098-bo
On Tue, Apr 26, 2011 at 6:05 AM, H.J. Lu wrote:
> On Thu, Mar 31, 2011 at 7:57 AM, H.J. Lu wrote:
>> On Mon, Mar 21, 2011 at 11:40 AM, H.J. Lu wrote:
>>> On Mon, Mar 14, 2011 at 12:28 PM, H.J. Lu wrote:
On Thu, Jan 27, 2011 at 2:40 AM, Richard Guenther
wrote:
> On Thu, Jan 27, 20
On 05/18/2011 03:46 PM, Henderson, Stuart wrote:
> * gcc.target/bfin/mcpu-bf592.c: New test.
>
>
> Ok to add to trunk?
Both patches ok.
Bernd
Hi,
The attached patch adds a new test for the bfin bf592 part.
* gcc.target/bfin/mcpu-bf592.c: New test.
Ok to add to trunk?
thanks,
Stu
Index: gcc/testsuite/gcc.target/bfin/mcpu-bf592.c
===
--- gcc/testsuite/gcc.target
Hi,
The attached patch adds support for the bfin bf592 part.
* doc/invoke.texi (Blackfin Options): -mcpu accepts bf592.
* config/bfin/t-bfin-elf (MULTILIB_MATCHES): Select bf532-none for
bf592-none.
* config/bfin/t-bfin-linux (MULTILIB_MATCHES): Likewise.
*
Hello!
> This patch fixes an obvious problem: the fma4_fmsubadd/fma4_fmaddsub
> instruction templates don't generate vfmsubaddpd/vfmaddsubpd because
> they don't use
>
> This passes bootstrap on x86_64 on trunk. Okay to commit?
See comments in the code.
> BTW, I'm testing on gcc-4_6-branch. S
Hello
As follow-up for logical to binary transition
2011-05-18 Kai Tietz
* tree-cfg.c (verify_gimple_assign_binary): Barf on
TRUTH_AND_EXPR, TRUTH_OR_EXPR, and TRUTH_XOR_EXPR.
(gimplify_expr): Boolify TRUTH_ANDIF_EXPR, TRUTH_ORIF_EXPR,
TRUTH_AND_EXPR, TRUTH_OR_
Janus Weil wrote:
> The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk?
OK. Thanks for the patch!
(What next on your gfortran agenda?)
Tobias
PS: For the following two patches review is pending:
My trans*.c coarray patch at
http://gcc.gnu.org/ml/fortran/2011-05/msg00123.html
Ja
On Tue, Apr 26, 2011 at 6:07 AM, H.J. Lu wrote:
> On Sat, Apr 9, 2011 at 6:52 PM, H.J. Lu wrote:
>> On Thu, Mar 24, 2011 at 12:15 AM, H.J. Lu wrote:
>>> On Wed, Mar 23, 2011 at 12:22 PM, Ulrich Weigand
>>> wrote:
Richard Henderson wrote:
> Because, really, if we consider the structure
Basile Starynkevitch writes:
> On Wed, May 18, 2011 at 10:27:11AM +0400, Andrey Belevantsev wrote:
>
>> On 17.05.2011 23:42, Basile Starynkevitch wrote:
>> >On Tue, 17 May 2011 21:30:44 +0200
>> >Pierre Vittet wrote:
>>
>> >>My contributor number is 634276.
>> You don't have to write your FSF c
On Tue, Apr 26, 2011 at 3:32 PM, H.J. Lu wrote:
> On Mon, Apr 4, 2011 at 6:05 PM, H.J. Lu wrote:
>> On Thu, Mar 31, 2011 at 5:05 AM, Kenneth Zadeck
>> wrote:
>>> we hit this limit trying to write the explicit semantics for a
>>> vec_interleave_evenv32qi.
>>>
>>> ;;(define_insn "vec_interleave_ev
On Sat, Oct 23, 2010 at 10:12 AM, H.J. Lu wrote:
> On Wed, Sep 8, 2010 at 9:43 AM, Martin Jambor wrote:
>> Hi,
>>
>> this patch reimplements build_ref_for_offset so that it simply creates
>> a MEM_REF rather than trying to figure out what combination of
>> component and array refs are necessary.
On Wed, May 18, 2011 at 1:30 PM, Rainer Orth
wrote:
>> The test (tls.c), used to check all TLS models is attached to the
>> message. I plan to convert it to proper dg test... ;)
>
> I've got it in my tree since you sent it to me while debugging/testing
> support for the various TLS models on Sola
Ping.
On 20/04/11 16:27, Andrew Stubbs wrote:
This patch adds basic support for the Thumb ADDW and SUBW instructions.
The patch permits the compiler to use the new instructions for constants
that can be loaded with a single instruction (i.e. 16-bit unshifted),
but does not support use of addw w
Hi!
The attached testcase ICEs on arm, because extract_fixed_bit_field
with tmode SImode (and SImode non-NULL target) decides to use DImode for
the signed shifts, but doesn't clear target and thus attempts to use
that SImode target for DImode shifts.
The code apparently already has if (mode != tmo
On 03/05/11 10:07, Bernd Schmidt wrote:
On 04/15/2011 12:54 PM, Andrew Stubbs wrote:
Ping.
Trying to unblock this...
I think the point is that both examples:
long long foolong (long long x, short *a, short *b)
{
return x + (long long)*a * (long long)*b;
}
and
long long
Uros,
> The test (tls.c), used to check all TLS models is attached to the
> message. I plan to convert it to proper dg test... ;)
I've got it in my tree since you sent it to me while debugging/testing
support for the various TLS models on Solaris. I'd really prefer (and
have modified it this way
This fixes PR49018, ifcombine looks for side-effects but instead
asks only gimple_has_volatile_ops. And gimple_has_side_effects
disregards that volatile asms have side-effects. The function
also doesn't handle all stmts gracefully so I fixed it as well
as turning the asserts to checking asserts.
On Wed, 18 May 2011, Eric Botcazou wrote:
> > * tree-ssa.c (useless_type_conversion_p): Preserve conversions
> > to non-1-precision BOOLEAN_TYPEs.
>
> This looks like overeager if you're allowing non-boolean types in tree-cfg.c.
> The conversion can be stripped if the source type has prec
> * tree-ssa.c (useless_type_conversion_p): Preserve conversions
> to non-1-precision BOOLEAN_TYPEs.
This looks like overeager if you're allowing non-boolean types in tree-cfg.c.
The conversion can be stripped if the source type has precision 1, can't it?
--
Eric Botcazou
This fixes the TRUTH_*_EXPR verification issues by making sure we
preserve conversions to BOOLEAN_TYPE where that carries useful
semantics - when the type has a TYPE_PRECISION other than 1. The
point of the TRUTH_*_EXPR operand sanitization was to make sure
we have two-valued types for their oper
> Another question: why does the model hijack %i7 to use it as frame pointer,
> instead of just using %fp? AFAICS both are kept as fixed registers by the
> code so the model seems to be wasting 1 register (2 without frame pointer).
Related question: why saving the Local and In registers in the fr
We can end up with an infinite recursion as gimple_register_type
tries to register TYPE_MAIN_VARIANT first. This is because we
are being called from the LTO type-fixup code which walks the
type graph and adjusts types to their leaders. So we can
be called for type SCCs that are only partially fi
Hi Zdenek,
thanks for the review.
On 05/18/2011 09:26 AM, Zdenek Dvorak wrote:
>> 2011-05-05 Tom de Vries
>>
>> PR target/45098
>> * tree-ssa-loop-ivopts.c (computation_cost): Prevent cost of 0.
>
> this looks strange. Something like
>
> cost = seq_cost (seq, speed);
> if (MEM
Hello!
> 2011-05-16 Zuxy Meng
> PR i386/48743
> * config/i386/cpuid.h (bit_MMXEXT): New
> * config/i386/driver-i386.c (host_detect_local_cpu): Detect Athlon by
> the presence of extended MMX instead of extended 3DNow!
PR target/48743
The patch is OK, but please also get a confirmation from som
On Wed, May 18, 2011 at 8:14 AM, Jakub Jelinek wrote:
> Hi!
>
> When an addressable var is optimized into non-addressable, we didn't
> clean up MEM_REFs containing ADDR_EXPR of such VARs in debug stmts. This
> got later on folded into the var itself and caused ssa verification errors.
> Fixed by
2011/5/18 Kai Tietz :
> 2011/5/18 Eric Botcazou :
>>> Hmm, you mean the initialization of boolean_false_node is wrong, too?
>>
>> Not wrong, but redundant, boolean_false_node is already set elsewhere.
>>
>> --
>> Eric Botcazou
>
> Hmm, right. Via build_common_tree_nodes_2 it is set. But well, then
On Wed, May 18, 2011 at 10:27:11AM +0400, Andrey Belevantsev wrote:
> On 17.05.2011 23:42, Basile Starynkevitch wrote:
> >On Tue, 17 May 2011 21:30:44 +0200
> >Pierre Vittet wrote:
>
> >>My contributor number is 634276.
> You don't have to write your FSF contributor number in each mail to
> gcc-
2011/5/18 Eric Botcazou :
>> Hmm, you mean the initialization of boolean_false_node is wrong, too?
>
> Not wrong, but redundant, boolean_false_node is already set elsewhere.
>
> --
> Eric Botcazou
Hmm, right. Via build_common_tree_nodes_2 it is set. But well, then
boolean_true_node initialization
> Hmm, you mean the initialization of boolean_false_node is wrong, too?
Not wrong, but redundant, boolean_false_node is already set elsewhere.
--
Eric Botcazou
2011/5/18 Eric Botcazou :
>> Ok, thanks for explaining it. So would be patch ok for apply without
>> the precision setting?
>
> Sure, everything but the gcc-interface/misc.c part is OK. Thanks.
>
> --
> Eric Botcazou
Hmm, you mean the initialization of boolean_false_node is wrong, too?
Not sure
> Ok, thanks for explaining it. So would be patch ok for apply without
> the precision setting?
Sure, everything but the gcc-interface/misc.c part is OK. Thanks.
--
Eric Botcazou
Hi,
> 2011-05-05 Tom de Vries
>
> PR target/45098
> * tree-ssa-loop-ivopts.c (computation_cost): Prevent cost of 0.
this looks strange. Something like
cost = seq_cost (seq, speed);
if (MEM_P (rslt))
the current code;
else
cost += rtx_cost (rslt, SET, speed));
woul
Hi,
> 2011-05-05 Tom de Vries
>
> PR target/45098
> * tree-ssa-loop-ivopts.c (seq_cost): Fix call to rtx_cost.
OK,
Zdenek
96 matches
Mail list logo
