On 10/13/11 06:15:31, Laurynas Biveinis wrote:
> [...] In your case (correct me if I misunderstood something)
> you have one hash table, marking of which will mark more objects
> which are required for the correct marking of the second hash table.
> GC might be simply walking the second one first.
On Thu, Oct 13, 2011 at 01:38:44AM +0200, Michael Matz wrote:
> IMO reading the standard to allow an access to be
> based "on s.p _as well as_ t->p" and that this should result in any
> sensible behaviour regarding restrict is interpreting too much into it.
No. Because s.p and t->p designates
This fixes PR50698, a failure to disambiguate &MEM[&mem + 10] from
&MEM[&mem] in data-reference analysis. Fixed by also looking
at offsets for non-subsetted references.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2011-10-13 Richard Guenther
PR tr
On Oct 12, 2011, at 2:37 PM, Artem Shinkarov wrote:
> This patch fixed PR50704.
>
> gcc/testsuite:
>* gcc.target/i386/warn-vect-op-3.c: Exclude ia32 target.
>* gcc.target/i386/warn-vect-op-1.c: Ditto.
>* gcc.target/i386/warn-vect-op-2.c: Ditto.
>
> Ok for trunk?
Ok. Is t
On Wed, Oct 12, 2011 at 9:24 PM, Tom de Vries wrote:
> Richard,
>
> This patch fixes a trivial problem in gimplify_parameters, introduced by the
> patch that introduced BUILT_IN_ALLOCA_WITH_ALIGN.
> BUILT_IN_ALLOCA_WITH_ALIGN has 2 parameters, so the number of arguments in the
> corresponding buil
On Thu, Oct 13, 2011 at 10:41 AM, Jakub Jelinek wrote:
> On Thu, Oct 13, 2011 at 01:38:44AM +0200, Michael Matz wrote:
>> IMO reading the standard to allow an access to be
>> based "on s.p _as well as_ t->p" and that this should result in any
>> sensible behaviour regarding restrict is interpretin
On Thu, Oct 13, 2011 at 10:59 AM, Mike Stump wrote:
> On Oct 12, 2011, at 2:37 PM, Artem Shinkarov wrote:
>> This patch fixed PR50704.
>>
>> gcc/testsuite:
>> * gcc.target/i386/warn-vect-op-3.c: Exclude ia32 target.
>> * gcc.target/i386/warn-vect-op-1.c: Ditto.
>> * gcc.target
On Thu, Oct 13, 2011 at 11:21:58AM +0200, Richard Guenther wrote:
> I suggested that for a final patch we only add ADD_RESTRICT in the
> gimplifier for restrict qualified parameters, to make the inlining case
> work again. ADD_RESTRICTs for casts to restrict qualified pointers
> I would add at par
On Thu, Oct 13, 2011 at 10:23 AM, Richard Guenther
wrote:
> On Thu, Oct 13, 2011 at 10:59 AM, Mike Stump wrote:
>> On Oct 12, 2011, at 2:37 PM, Artem Shinkarov wrote:
>>> This patch fixed PR50704.
>>>
>>> gcc/testsuite:
>>> * gcc.target/i386/warn-vect-op-3.c: Exclude ia32 target.
>>>
On 10/12/2011 10:13 AM, Tom de Vries wrote:
> On 10/10/2011 05:50 PM, Eric Botcazou wrote:
>>> So, the patch for build_constant_desc does not have the desired effect.
>>
>> OK, too bad that we need to play this back-and-forth game with MEMs. So the
>> original patch is OK (with TREE_READONLY (bas
On 10/13/2011 01:04 AM, Richard Kenner wrote:
I still don't like the patch, but I'm no longer as familiar with the code
as I used to be so can't suggest a replacement. Let's see what others
think about it.
Same here, I don't like it but I hardly see any alternative. The only
possibility cou
This change fixes the error handling circuitry in the initialization routine
for suspension objects so that Storage_Error is propagated as intended if
the allocation of the underlying OS entities fails.
No test (requires system resource allocation failure).
Tested on x86_64-pc-linux-gnu, committe
This change ensures fixes an improper usage of Defer_Abort where
Defer_Abort_Nestable is meant, that would cause a failed assrtion
if a timed selective accept statement occurs when there already is
a pending call to the accepted entry.
The following program must compile and execute quietly:
with
This change factors a chunk of code that was duplicated between
Par.Ch2.P_Identifier and Par.Ch3.P_Defining_Identifier.
No behaviour change, no test.
Tested on x86_64-pc-linux-gnu, committed on trunk
2011-10-13 Thomas Quinot
* par-ch2.adb, par.adb, par-util.adb, par-ch3.adb
(
An operator can be declared Import (Intrinsic) only if the current view of the
operand type (s) is a numeric type. With this patch the compiler properly
rejects the pragma if the operand type is private or incomplete.
Compiling mysystem.ads must yield:
mysystem.ads:3:13: intrinsic operator can
a component association for component X has a boc, then X is covered in the
aggregate even if there is not default value for X in the type declaration, and
X has to be default-initialized. If the aggregate also has an others clause, X
is not covered by it.
The following must compile quietly in gna
When an enumeration type appears in an attribute reference, all literals of
the type are marked as referenced. This must only be done if the attribute
reference appears in the current source. Else the information on references
may differ between a normal compilation and one that performs inlining.
This patch removes an improper check on type to which the pragma Unchecked_Union
applies. Such a type can be limitied.
The following must compile quietly:
package UU is
type Val is (One, Two);
type T (X : Val := One) is limited record
case X is
when One => A : Long_Long_
In Ada 2005, several constructs of a limited type can be built in place, and
as such can be returned by function calls. In Ada 2012, the new expression forms
conditional expressions and case expressions can also be built in place if each
of their dependent expressions can be built in place.
The fo
In Ada 2012 a qualified expression is a valid name, and for example a function
call that is disambiguated by means of a qualification can appear in the place
of a constant object. On the other hand A qualified expression that appears as
a statement denotes a machine code insertion. With the new rul
Box associations are used to initialize aggregate components through the default
value of the corresponding components, or through calls to initialization
procedures. In general aggregates with such initializations cannot be built
statically. With this patch the following must compile quietly:
If there was an unknown attribute (such as IDE'Gnat) in any member
project of an aggregate project, then gprbuild fails if it is invoked on
the aggregate project.
Tested on x86_64-pc-linux-gnu, committed on trunk
2011-10-13 Vincent Celier
* prj-conf.adb (Get_Or_Create_Configuration_Fi
This patch fixes a bug in which the global heap was used, even when a
user-defined storage pool had been specified. The bug occurred when the
function result type is immutably limited (so build-in-place is used),
and the result subtype is unconstrained or tagged (so has caller-unknown-size),
and th
When a for loop for an enumeration type with an enumeration representation
clause is expanded, it's rewritten as a loop over an integer loop parameter
and the original loop parameter is moved into a new nested block. When
the block is analyzed, the moved entity gets appended to the block scope's
en
Hi Arnaud,
--- exp_ch5.adb (revision 179894)
+++ exp_ch5.adb (working copy)
@@ -3458,6 +3458,20 @@
Statements => Statements (N,
End_Label => End_Label (N)));
+
+ -- The loop parameter's entity must be removed from the loop
+
Using the existing definition, we'd have to first convert a complex vector
to a real one by computing the modulus ("abs") of each element. Constructing
an extra temporary vector is inefficient and may use an unexpected amount
of extra storage. No change in behavior for the real case though, this ju
This prepares for reusing the Sqrt implementation in Generic_Complex_Arrays.
The local implementation avoids having to instantiate entire new copies of
Generic_Elementary_Functions just to get square root.
Tested on x86_64-pc-linux-gnu, committed on trunk
2011-10-13 Geert Bosch
* a-ng
Use proper "abs" function returning a real for comparing magnitude of
elements. The previous local implementation using "-" only was correct
for real values. This prepares for the pure Ada reimplementation of
Generic_Complex_Arrays.
Tested on x86_64-pc-linux-gnu, committed on trunk
2011-10-13 Ge
Some left-overs from an earlier patch. Applied on the mainline.
2011-10-13 Eric Botcazou
PR ada/50589
* s-linux-alpha.ads: Do not "with" Interfaces.C.
* s-linux-sparc.ads: Likewise.
--
Eric Botcazou
Index: s-linux-sparc.ads
==
This completes the removal of dependencies on BLAS and LAPACK for these
packages. The main reason for this is limited availability of these libraries
on some platforms and for some types, in particular types wider than 64 bits.
Furthermore, some BLAS implementations may use sub-cubic implementation
Hi,
in this simple PR, submitter remarks that there isn't a real reason not
to have -W(no-)format-zero-length working in C++ exactly like in C.
In fact, the status quo is that the warning *is* active in C++ too, part
of -Wformat, but it cannot be *disabled*, because
-Wno-format-zero-length i
Hello,
this new version addresses the comments from Michael and additional fixes
an latent issue shown up by this rewrite in fold-const.
On gimplify.c's gimple_boolify we didn't handled the case that operands
for TRUTH-expressions need to have same operand-size for transformation to
bitwise operat
On Wed, Oct 12, 2011 at 23:36, Lawrence Crowl wrote:
> Use the mangled name for merging, as this should enable us to
> handle function overloads. We use the regular identifier for other
> declarations, as that should be sufficient and avoids the problem of
> different typedefs mangling to the sam
On Thu, Oct 13, 2011 at 01:01, Lawrence Crowl wrote:
> /* Read and return a location_t from STREAM.
> - FIXME pph: If pph_trace didn't depend on STREAM, we could avoid having to
> - call this function, only for it to call lto_input_location, which calls
> the
> - streamer hook back to pph
On Thu, Oct 13, 2011 at 1:25 PM, Kai Tietz wrote:
> Hello,
>
> this new version addresses the comments from Michael and additional fixes
> an latent issue shown up by this rewrite in fold-const.
> On gimplify.c's gimple_boolify we didn't handled the case that operands
> for TRUTH-expressions need
This fixes PR50712, an issue with IPA split uncovered by adding
verifier calls after it ... we need to also gimplify reads of
register typed memory when passing it as argument.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2011-10-13 Richard Guenther
PR tre
2011/10/13 Richard Guenther :
> On Thu, Oct 13, 2011 at 1:25 PM, Kai Tietz wrote:
>> Hello,
>>
>> this new version addresses the comments from Michael and additional fixes
>> an latent issue shown up by this rewrite in fold-const.
>> On gimplify.c's gimple_boolify we didn't handled the case that o
On 13 Oct 2011, at 11:22, Arnaud Charlet wrote:
An operator can be declared Import (Intrinsic) only if the current
view of the
operand type (s) is a numeric type. With this patch the compiler
properly
rejects the pragma if the operand type is private or incomplete.
Compiling mysystem.ads m
Ping
http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01002.html
http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01003.html
and
http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01596.html
The last one needs a tweak.
s/FUNCTION_VALUE_REGNO_P/targetm.calls.function_value_regno_p/,
or wrap the whole patch in #i
[To the right list this time]
The test fails with a link error, as 'round' and 'rint' are only C99.
Fixed thusly, tested on SPARC/Solaris 8, applied on the mainline as obvious.
2011-10-13 Eric Botcazou
* gcc.dg/builtins-67.c: Guard iround and irint with HAVE_C99_RUNTIME.
--
Eric
2011/10/13 Gary Funck :
> On 10/13/11 06:15:31, Laurynas Biveinis wrote:
>> [...] In your case (correct me if I misunderstood something)
>> you have one hash table, marking of which will mark more objects
>> which are required for the correct marking of the second hash table.
>> GC might be simply
Hello,
This patch adds further optimization to gimple's ifcombine pass for single-bit
andif operations.
New patterns recognized are:
* if ((a & 4) == 0) if ((a & 8) == 0) -> if ((a & 12) == 0)
* if ((a & 4) != 0) if ((a & 8) == 0) -> if ((a & 12) == 4)
* if ((a & 4) == 0) if ((a & 8) != 0) -> if
> Same here, I don't like it but I hardly see any alternative. The only
> possibility could be to prevent calling expand_compound_operation
> completely for addresses. Richard, what do you think? Don't worry,
> combine hasn't changed much since your days. :)
The problem wasn't potential chan
Hi,
On Thu, 13 Oct 2011, Jakub Jelinek wrote:
> I'd sum up my previous mail as noting that restricted pointers are objects,
> so restrict is not property of expressions. So e.g. I don't think
> we should add ADD_RESTRICT (or, at least, not an ADD_RESTRICT with different
> tag) on every assignmen
Given that we support the LEON series of processors in 4.6.x and later, it may
make sense to provide a workaround for the erratum of the AT697F processor.
The compiler isn't supposed to generate the problematic instructions sequences
in the 4.5 and later series (unlike the 4.4 series) under norma
Why not support it in Obj-C++, too?
Jason
On 13/10/11 00:21, Janis Johnson wrote:
> Tests gcc.target/arm/pr48252.c and gcc.target/arm/neon-vset_lanes8.c
> expect little-endian code and fail when compiled with -mbig-endian.
> This patch skips the test if the current multilib does not generate
> little-endian code.
>
> I'm not able to run e
On 10/13/2011 02:51 PM, Richard Kenner wrote:
case MEM:
/* Ensure that our address has any ASHIFTs converted to MULT in case
address-recognizing predicates are called later. */
temp = make_compound_operation (XEXP (x, 0), MEM);
SUBST (XEXP (x, 0), temp);
On 10/8/2011 23:50, Kai Tietz wrote:
> 2011/10/8 Paolo Carlini:
>> Hi,
>>
>>> Ok, fixed it, I made a very dumb mistake in configure.host, new patch
>>> attached.
>>
>> Patch is still ok with me, if Kai is ok with it (remember for next time:
>> regenerated files are not posted, are just a distracti
Hello,
this new version addresses the comments from you.
On gimplify.c's gimplify_expr we didn't handled the case that operands
for TRUTH-AND/OR/XOR expressions need to have same operand-size in
case of transformation to bitwise-binary operation. This shows up
for Fortran, as there are more than
Hi!
Andrew mentioned on IRC he found walk_stmt_load_store_addr_ops
doesn't handle COND_EXPR weirdo first argument well, the following
patch is an attempt to handle that.
I've noticed similar spot in verify_ssa, though in that case I'm not
sure about whether the change is so desirable, as it doesn
Hi,
On Thu, 13 Oct 2011, Kai Tietz wrote:
> this new version addresses the comments from Michael and additional fixes
> an latent issue shown up by this rewrite in fold-const.
> On gimplify.c's gimple_boolify we didn't handled the case that operands
> for TRUTH-expressions need to have same opera
Hi!
This patch is partly taken from my part of the PR50374 patch,
though that patch will need some further work in the vectorizer
etc.
SSE4.1 has the phminposuw insn which can be used for reduction
instead of 3 shuffles and 3 min insns:
...
- vpsrldq $8, %xmm0, %xmm1
- vpminuw %xmm1,
>
> Ping, did this go in trunk already?
I would be surprised to see this happening if nobody like you or Kai actually
does the commit ;)
P
On Thu, Oct 13, 2011 at 9:47 AM, Paolo Carlini wrote:
>>
>> Ping, did this go in trunk already?
>
> I would be surprised to see this happening if nobody like you or Kai actually
> does the commit ;)
>
> P
>
Does Jon have commit access?
Yes, I have already sent an patch with Richard's wish. Indeed we need
only to do this type-casting for operands on transcription of
TRUTH_(AND|OR|XOR)_EXPR to BIT_(AND|OR|XOR)_EXPR.
Cheers,
Kai
Hi,
this is a regression present on the mainline and 4.6 branch, introduced by the
offsetof folding change. The compiler now rejects:
int fails = __builtin_offsetof (C, b.offset);
error: cannot apply 'offsetof' to a non constant address
whereas it still accepts:
int works = (int)(&(((C*)0)->
Hi,
> Why not support it in Obj-C++, too?
Yes I briefly wondered that but I know *so* little about that front end... Do
you think we can just add it? Probably yes ;)
Paolo
2011/10/13 Paolo Carlini :
>>
>> Ping, did this go in trunk already?
>
> I would be surprised to see this happening if nobody like you or Kai actually
> does the commit ;)
>
> P
I will take care to apply it.
Kai
On Thu, Oct 13, 2011 at 02:57:56PM +0200, Michael Matz wrote:
> struct S {int * restrict p;};
> void foo (struct S *s, struct S *t) {
> s->p[0] = 0;
> t->p[0] = 1; // undefined if s->p == t->p; the caller was responsible
> // to not do that
This is undefined only if s->p == t
> Or being fooled by the 0xfffc masking, perhaps.
No, I'm pretty sure that's NOT the case. The *whole point* of the
routine is to deal with that masking.
On 10/13/2011 09:53 AM, Paolo Carlini wrote:
Yes I briefly wondered that but I know *so* little about that front end... Do
you think we can just add it? Probably yes ;)
Definitely. Anything supported in C++ should also be in Obj-C++ by default.
Jason
Ping.
On 20/09/11 11:51, Andrew Stubbs wrote:
On 09/09/11 12:55, Richard Earnshaw wrote:
The part number field is meaningless outside of the context of a a
specific vendor -- only taken as a pair can they refer to a specific
part. So why is the vendor field hard-coded rather than factored into
This is yet another attempt to fix PR46278 (fake X addressing).
After the previous clean-ups it is just a small change.
caller-saves.c tries to eliminate call-clobbered hard-regs allocated to pseudos
around function calls and that leads to situations that reload is no more
capable to perform all
On 10/13/2011 06:44 AM, Jakub Jelinek wrote:
> * config/i386/sse.md (reduc_umin_v8hi): New pattern.
> * config/i386/i386.c (ix86_build_const_vector): Handle
> also V32QI, V16QI, V16HI and V8HI modes.
> (emit_reduc_half): New function.
> (ix86_expand_reduc): Use phminpo
On Thu, 13 Oct 2011, Richard Earnshaw wrote:
> 2) Change the compiler to make initializers of vectors assign elements
> of initializers to consecutive lanes in a vector, rather than the
> current behaviour of 'casting' an array of elements to a vector.
>
> While the second would be my preferred c
> Committed to the 4.6 branch as r179864:
... and to 4.5 as r179923.
Cheers,
Janus
> 2011/10/9 Janus Weil :
>> Hi all,
>>
>> I have just committed as obvious a patch for an ICE-on-valid problem
>> with PROCEDURE statements:
>>
>> http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179723
>>
>> Th
Hi,
On Thu, 13 Oct 2011, Jakub Jelinek wrote:
> On Thu, Oct 13, 2011 at 02:57:56PM +0200, Michael Matz wrote:
> > struct S {int * restrict p;};
> > void foo (struct S *s, struct S *t) {
> > s->p[0] = 0;
> > t->p[0] = 1; // undefined if s->p == t->p; the caller was responsible
> >
Hi,
looks like an obvious typo. Ok for trunk ?
Tristan.
2011-10-13 Tristan Gingold
* config/rs6000/rs6000.c (rs6000_init_builtins): Fix typo.
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 4fd2192..3bfe33e 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gc
On 13/10/11 15:56, Joseph S. Myers wrote:
> On Thu, 13 Oct 2011, Richard Earnshaw wrote:
>
>> 2) Change the compiler to make initializers of vectors assign elements
>> of initializers to consecutive lanes in a vector, rather than the
>> current behaviour of 'casting' an array of elements to a vect
I'm seeing an infinite loop in g++.dg/pph/c1limits-externalid.cc. The
while() loop in pph_search_in_chain is not ending. Or maybe it's
falling into the N^2 trap you mention in that routine?
I've added a short timeout to this test and XFAIL'd it so you can debug it.
Diego.
On Thu, 13 Oct 2011, Michael Matz wrote:
> Yeah. But I continue to think that this reading is against the intent (or
> should be). All the examples in the standard and rationale never say
> anything about pointers to restricted objects and the problematic cases
> one can construct with them,
.. this looks like an (almost) obvious fix for the bootstrap breakage...
OK for trunk?
Iain
Index: gcc/config/darwin.c
===
--- gcc/config/darwin.c (revision 179865)
+++ gcc/config/darwin.c (working copy)
@@ -2957,10 +2957,11 @@ darwi
On Thu, Oct 13, 2011 at 4:55 AM, Richard Guenther wrote:
>
> This fixes PR50712, an issue with IPA split uncovered by adding
> verifier calls after it ... we need to also gimplify reads of
> register typed memory when passing it as argument.
>
> Bootstrapped on x86_64-unknown-linux-gnu, testing in
Hi
I would like to share some plans about improving the situation with
vector alignment tracking. First of all, I would like to start with a
well-known bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50716.
There are several aspects of the problem:
1) We would like to avoid the quiet segmentati
I think this may be an infinite loop, but it may also just be taking a
long time to do the merge operations.
Teste on x86_64. Committed to branch.
Diego.
* g++.dg/pph/c1limits-externalid.cc: Add shorter timeout.
Document failure mode.
diff --git a/gcc/testsuite/g++.dg/pph/c1l
To avoid confusion, I moved the callbacks into pph-streamer.c so they
can be internal to that file. They don't need to be called directly
ever.
Tested on x86_64. Committed to branch.
Diego.
* pph-streamer-in.c (pph_in_mergeable_tree): Fix comment.
(pph_read_tree): Move to pph
On Mon, 2011-09-12 at 15:29 -0400, David Edelsohn wrote:
> First, please choose a more informative option name.
> -mpreserve-link-stack seems like something generally useful for all
> processors and someone may randomly add the option. It always is
> useful to preserve the link stack -- that's why
Artem Shinkarov writes:
>
> 1) Currently in C we cannot provide information that an array is
> aligned to a certain number. The problem is hidden in the fact, that
Have you considered doing it the other way round: when an optimization
needs something to be aligned, make the declaration aligned?
On Thu, Oct 13, 2011 at 7:14 AM, Richard Kenner
wrote:
>> Or being fooled by the 0xfffc masking, perhaps.
>
> No, I'm pretty sure that's NOT the case. The *whole point* of the
> routine is to deal with that masking.
>
I got
(gdb) step
make_compound_operation (x=0x7139c4c8, in_code=MEM)
This patch seems to have caused PR50717:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50717
Thanks,
Matt
On 19/08/11 15:49, Andrew Stubbs wrote:
On 14/07/11 15:35, Richard Guenther wrote:
Ok.
I've just committed this updated patch.
I found bugs with VOIDmode constants that have caused me
On Thu, Oct 13, 2011 at 4:54 PM, Andi Kleen wrote:
> Artem Shinkarov writes:
>>
>> 1) Currently in C we cannot provide information that an array is
>> aligned to a certain number. The problem is hidden in the fact, that
>
> Have you considered doing it the other way round: when an optimization
>
> at the end. make_compound_operation doesn't know how to
> restore ZERO_EXTEND.
It does in general. See make_extraction, which it calls. The question is
why it doesn't in this case. That's the bug.
Hi!
I've noticed that
#define vector(elcount, type) \
__attribute__((vector_size((elcount)*sizeof(type type
vector (4, int)
f1 (vector (4, int) a, int b)
{
((int *)&a)[0] = b;
return a;
}
as well as
vector (4, int)
f2 (vector (4, int) a, int b)
{
a[0] = b;
return a;
}
don't result
Hi!
As noted by Kirill Yukhin (and what lead to the previous tree-ssa.c patch),
vec_set wasn't wired for 32-byte vectors.
Although ix86_expand_vector_set handles 32-byte vectors just fine (even for
AVX and integer vectors), without the expander we'd force things into memory
etc.
Fixed thusly, boo
On 10/13/2011 09:21 AM, Jakub Jelinek wrote:
> * config/i386/sse.md (vec_set): Change V_128 iterator mode to V.
Ok.
r~
On Thu, Oct 13, 2011 at 9:11 AM, Richard Kenner
wrote:
>> at the end. make_compound_operation doesn't know how to
>> restore ZERO_EXTEND.
>
> It does in general. See make_extraction, which it calls. The question is
> why it doesn't in this case. That's the bug.
>
It never calls make_extractio
> It never calls make_extraction. There are several cases handled
> for AND operation. But
>
> (and:DI (plus:DI (subreg:DI (mult:SI (reg/v:SI 85 [ i ])
>(const_int 4 [0x4])) 0)
>(subreg:DI (reg:SI 106) 0))
>(const_int 4294967292 [0xfffc]))
>
> isn't one of them.
On 10/13/2011 05:27 AM, Alan Modra wrote:
> Ping
> http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01002.html
> http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01003.html
Ok.
> http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01596.html
>
> The last one needs a tweak.
> s/FUNCTION_VALUE_REGNO_P/targetm.ca
On 10/13/11 14:27, Alan Modra wrote:
> Without the ifcvt
> optimization for a function "int foo (int x)" we might have something
> like
>
> r29 = r3; // save r3 in callee saved reg
> if (some test) goto exit_label
> // main body of foo, calling other functions
> r3 = 0;
> return;
> exit_label
> Or I am missing someting?
I often see the x86 vectorizer with -mtune=generic generate a lot of
complicated code just to adjust for potential misalignment.
My thought was just if the alias oracle knows what the original
declaration is, and it's available for changes (e.g. LTO), it would be
like
On 10/13/2011 06:35 PM, Richard Kenner wrote:
It never calls make_extraction. There are several cases handled
for AND operation. But
(and:DI (plus:DI (subreg:DI (mult:SI (reg/v:SI 85 [ i ])
(const_int 4 [0x4])) 0)
(subreg:DI (reg:SI 106) 0))
(const_int 4294967292 [0x
On 10/13/2011 08:49 AM, Peter Bergner wrote:
> + if (TARGET_LINK_STACK)
> + asm_fprintf (file, "\tbl 1f\n\tb 2f\n1:\n\tblr\n2:\n");
> + else
> + asm_fprintf (file, "\tbcl 20,31,1f\n1:\n");
Wouldn't it be better to set up an out-of-line "blr" insn that could
be shared by
On Thu, Oct 13, 2011 at 06:57:47PM +0200, Andi Kleen wrote:
> > Or I am missing someting?
>
> I often see the x86 vectorizer with -mtune=generic generate a lot of
> complicated code just to adjust for potential misalignment.
>
> My thought was just if the alias oracle knows what the original
> de
On 10/13/11 18:50, Bernd Schmidt wrote:
> On 10/13/11 14:27, Alan Modra wrote:
>> Without the ifcvt
>> optimization for a function "int foo (int x)" we might have something
>> like
>>
>> r29 = r3; // save r3 in callee saved reg
>> if (some test) goto exit_label
>> // main body of foo, calling ot
> An and:DI is cheaper than a zero_extend:DI of an and:SI.
That depends strongly on the constants and whether the machine is 32-bit
or 64-bit.
But that's irrelevant in this case since the and:SI will be removed (it
reflects what already been done).
On Thu, Oct 13, 2011 at 10:01 AM, Paolo Bonzini wrote:
> On 10/13/2011 06:35 PM, Richard Kenner wrote:
>>>
>>> It never calls make_extraction. There are several cases handled
>>> for AND operation. But
>>>
>>> (and:DI (plus:DI (subreg:DI (mult:SI (reg/v:SI 85 [ i ])
>>> (const_int
On Thu, Oct 13, 2011 at 19:19, H.J. Lu wrote:
> On Thu, Oct 13, 2011 at 10:01 AM, Paolo Bonzini wrote:
>> On 10/13/2011 06:35 PM, Richard Kenner wrote:
It never calls make_extraction. There are several cases handled
for AND operation. But
(and:DI (plus:DI (subreg:DI (mul
On Thu, Oct 13, 2011 at 10:21 AM, Paolo Bonzini wrote:
> On Thu, Oct 13, 2011 at 19:19, H.J. Lu wrote:
>> On Thu, Oct 13, 2011 at 10:01 AM, Paolo Bonzini wrote:
>>> On 10/13/2011 06:35 PM, Richard Kenner wrote:
>
> It never calls make_extraction. There are several cases handled
> fo
On Thu, Oct 13, 2011 at 19:06, Richard Kenner
wrote:
>> An and:DI is cheaper than a zero_extend:DI of an and:SI.
>
> That depends strongly on the constants and whether the machine is 32-bit
> or 64-bit.
Yes, the rtx_costs take care of that.
> But that's irrelevant in this case since the and:SI w
1 - 100 of 166 matches
Mail list logo
