On Wed, Apr 06, 2011 at 04:08:38PM +, Joseph S. Myers wrote:
> RMS approved relicensing gcov-io.c, so I've applied this patch to trunk,
> 4.6 and 4.5 branch to add the license exception. Perhaps someone with a
> 4.4 branch checkout could apply it there as well?
Done.
> 2011-04-06 Joseph M
This patch adds lightweight debug checks (if enabled by macros).
To be applied only to google/integration branch.
Tested by bootstrapping and running "make check".
2011-04-12 Paul Pluzhnikov
* libstdc++-v3/include/bits/stl_algo.h: Add comparator debug checks
when __google_st
Nathan Froyd writes:
> On Thu, Mar 10, 2011 at 11:23:10PM -0500, Nathan Froyd wrote:
>> Now that we have a structure where not every node might include
>> TREE_CHAIN or TREE_TYPE, we need to make sure that when we call said
>> accessors that the argument is properly typed. This requires a number
On Tue, Apr 12, 2011 at 22:43, Nathan Froyd wrote:
> On Thu, Mar 10, 2011 at 11:23:10PM -0500, Nathan Froyd wrote:
>> Now that we have a structure where not every node might include
>> TREE_CHAIN or TREE_TYPE, we need to make sure that when we call said
>> accessors that the argument is properly t
On Thu, Mar 10, 2011 at 11:23:10PM -0500, Nathan Froyd wrote:
> Now that we have a structure where not every node might include
> TREE_CHAIN or TREE_TYPE, we need to make sure that when we call said
> accessors that the argument is properly typed. This requires a number
> of changes:
http://gcc.g
On Fri, Apr 8, 2011 at 8:49 AM, Richard Guenther wrote:
>
> This is the "real" fix for PR46076 that I wanted to persue. Make
> function pointer type conversions useless as to more aggressively
> be able to turn indirect into direct calls. This requires that we
> preserve the original type signat
On Tue, Apr 12, 2011 at 04:00:45PM -0500, Pat Haugen wrote:
> --- gcc/config/rs6000/rs6000.c (revision 172327)
> +++ gcc/config/rs6000/rs6000.c (working copy)
> @@ -7976,7 +7976,7 @@ call_ABI_of_interest (tree fndecl)
> return true;
>
>/* Interesting functions that we are emittin
On Tue, Apr 12, 2011 at 20:02, wrote:
> One oddity, otherwise LGTM.
>
>
> http://codereview.appspot.com/4389045/diff/1/gcc/cp/parser.c
> File gcc/cp/parser.c (right):
>
> http://codereview.appspot.com/4389045/diff/1/gcc/cp/parser.c#newcode375
> gcc/cp/parser.c:375: if (flag)
> This code will neve
On Tue, Apr 12, 2011 at 20:41, Lawrence Crowl wrote:
> This change is not source compatible with existing code using
> the callbacks (which may not be in the gcc svn). Perhaps a new
> callback is needed?
Well, it only changes the return value for the callback. Existing
users do not really need
This change is not source compatible with existing code using
the callbacks (which may not be in the gcc svn). Perhaps a new
callback is needed?
On 4/12/11, Diego Novillo wrote:
>
> During pph processing, when we find an included file that we are going
> to instantiate from an image, we don't wa
On Tue, Apr 12, 2011 at 18:56, Paul Pluzhnikov wrote:
> This patch adds lightweight debug checks (if enabled by macros).
>
> To be applied only to google/integration branch.
>
> Tested by bootstrapping and running "make check".
>
>
> 2011-04-12 Paul Pluzhnikov
>
> * libstdc++-v3/include/
LGTM
On 4/12/11, Diego Novillo wrote:
>
> This patch, together with the others I sent today, allows us to
> reconstruct all the symbols and types stored inside a pph image. This
> is not all we need, but it allows me to get basic declarations and
> types reconstructed from pph images.
>
> This c
LGTM
On 4/12/11, Diego Novillo wrote:
>
> In reconstructing pph images, I found some more language-specific
> fields that we were not pickling. There's a few more that I will be
> sending shortly.
>
> Tested on x86_64. Committed to pph.
>
>
> 2011-04-12 Diego Novillo
>
> * pph-streamer
On Apr 12, 2011, at 2:23 PM, Gerald Pfeifer wrote:
> This was inspired by Mike, though he probably doesn't know it. :-)
I recall the conversation... :-) Arguably, having a pre-commit hook would be
even more whiz-bang.
One oddity, otherwise LGTM.
http://codereview.appspot.com/4389045/diff/1/gcc/cp/parser.c
File gcc/cp/parser.c (right):
http://codereview.appspot.com/4389045/diff/1/gcc/cp/parser.c#newcode375
gcc/cp/parser.c:375: if (flag)
This code will never print "false", so why have it?
http://codereview.ap
On 04/13/2011 01:45 AM, Michael Matz wrote:
> And is there any chance to transform this:
>
> +#ifdef HAVE_cc0
> + if (!sets_cc0_p (insn))
> +#endif
> + max_to = insn;
>
> into this:
>
> + if (!sets_cc0_p (insn))
> max_to = insn;
>
> ? Yes, that implies mak
Hi,
On Tue, 12 Apr 2011, Bernd Schmidt wrote:
> This fixes a problem on cc0 machines where we split a sequence of insns
> at a point where we shouldn't - between a cc0 setter and a cc0 user.
>
> The fix is simple enough; just make sure not to pick a cc0 setter as the
> end of such a sequence. Th
This fixes 20020425-1.c when the compiler under test is built with -O0 and
we're on a machine with an 8 meg stack.
Ok?
2011-04-12 Mike Stump
* c-typeck.c (c_finish_if_stmt): Fold result.
* fold-const.c (fold_ternary_loc): Handle an empty else.
This fixes 20020425-1.c so that
On 04/12/2011 01:06 PM, Jakub Jelinek wrote:
+: (unsigned)TREE_STRING_LENGTH (ary)
+ * (TYPE_PRECISION (TREE_TYPE (TREE_TYPE (ary)))
+ / TYPE_PRECISION (char_type_node)));
Don't you mean / instead of * here? Let's also calculate the size of
the element once rather
This patch adds lightweight debug checks (if enabled by macros).
To be applied only to google/integration branch.
Tested by bootstrapping and running "make check".
2011-04-12 Paul Pluzhnikov
* libstdc++-v3/include/ext/vstring.h: Enable debug checks when
__google_stl_debug_st
From: Rainer Orth
Date: Tue, 12 Apr 2011 15:00:53 +0200
> On Solaris 10, as assembles the test just fine, but ld cannot deal with
> gas 2.21 output:
>
> ld: fatal: relocation error: R_SPARC_GOTDATA_HIX22: file gotdata.o: symbol
> : offset 0xff370163 is non-aligned
> ld: fatal: relocation error:
On 12/04/11 20:16, Janis Johnson wrote:
On 04/08/2011 04:37 PM, Mike Stump wrote:
On Apr 8, 2011, at 8:07 AM, Janis Johnson wrote:
Test gcc.target/arm/pr43698.c specifies -march=armv7-a and fails
execution for multilibs whose hardware or simulator doesn't support that
architecture.
Ideally, I
Add a test to ensure that PPH files are #included at global scope.
Initially, this test is XFAIL, as it's a low priority error.
Index: gcc/testsuite/ChangeLog.pph
2011-04-12 Lawrence Crowl
* g++.dg/pph/y2smother.cc: New.
Index: gcc/testsuite/g++.dg/pph/y2smother.cc
=
This was inspired by Mike, though he probably doesn't know it. :-)
Remove the XHTML button from the standard footer and merge the Last
Modified line with the first line, saving a fair amount of space.
For those inclined, the dot at the end of the first line still links
to the validator. :-)
Live
Discussed the following with Martin on irc to bring rs6000 target up to date
with his changes to the cgraph code. Bootstrap/regtest on powerpc64-linux.
Committed as obvious.
-Pat
2011-04-12 Pat Haugen
* config/rs6000/rs6000.c (call_ABI_of_interest): Call
cgraph_get_create_
On Tue, 12 Apr 2011, Gunther Nikl wrote:
> I was under the impression that the used (bin-)utils had to offer
> required target support (instructions, directives, object file format)
> to be usable with GCC. AFAICT newer binutils versions (in my case
And command-line options.
> >2.9.1) configured
This fixes a problem on cc0 machines where we split a sequence of insns
at a point where we shouldn't - between a cc0 setter and a cc0 user.
The fix is simple enough; just make sure not to pick a cc0 setter as the
end of such a sequence. The patch below was regression tested on
m68k-rtems4.11 by J
During pph processing, when we find an included file that we are going
to instantiate from an image, we don't want libcpp to stack and read
it.
I've implemented this by allowing the 'include' callback to return a
boolean value. If it returns true, then we call _cpp_stack_include.
Otherwise, the
On Apr 12, 2011, at 12:12 PM, Nicola Pero wrote:
> This saves a few thousands strlen() calls per compilation by reusing
> the length of selector strings instead of calculating it again.
>
> Ok to commit ?
Ok.
On 8 April 2011 16:08, Janis Johnson wrote:
> Test gcc.target/arm/sync-1.c specifies -march=armv7-a and fails
> execution for multilibs whose hardware or simulator doesn't support that
> architecture. The test uses __sync_fetch_and_add, which GCC doesn't
> support for all arm targets. Using the
On 12 April 2011 20:16, Janis Johnson wrote:
> On 04/08/2011 04:37 PM, Mike Stump wrote:
>> On Apr 8, 2011, at 8:07 AM, Janis Johnson wrote:
>>> Test gcc.target/arm/pr43698.c specifies -march=armv7-a and fails
>>> execution for multilibs whose hardware or simulator doesn't support that
>>> archite
This patch, together with the others I sent today, allows us to
reconstruct all the symbols and types stored inside a pph image. This
is not all we need, but it allows me to get basic declarations and
types reconstructed from pph images.
This causes ~57 failures in pph.exp. The more problematic
In reconstructing pph images, I found some more language-specific
fields that we were not pickling. There's a few more that I will be
sending shortly.
Tested on x86_64. Committed to pph.
2011-04-12 Diego Novillo
* pph-streamer-in.c (pph_stream_unpack_value_fields): Unpack
This patch adds some debugging support for printing namespace_decls and
their associated binding level.
Committed to pph branch.
2011-04-12 Diego Novillo
* cp-tree.h (print_namespace): Declare.
* name-lookup.c (print_namespace): New.
* parser.c (cp_debug_print_contex
On 04/08/2011 04:37 PM, Mike Stump wrote:
> On Apr 8, 2011, at 8:07 AM, Janis Johnson wrote:
>> Test gcc.target/arm/pr43698.c specifies -march=armv7-a and fails
>> execution for multilibs whose hardware or simulator doesn't support that
>> architecture.
>
> Ideally, I'd like target people to weigh
This saves a few thousands strlen() calls per compilation by reusing
the length of selector strings instead of calculating it again.
Ok to commit ?
Thanks
PS: I'll come back to hashtables later, as they do deserve some
discussion. I want to get all the other obvious tiny changes in
first.
Inde
Hi Janne,
the attached patch does a bit of janitorial type cleanup for the
library. It replaces the use of ssize_t with ptrdiff_t or index_type
where appropriate; this is entirely for documentation purposes, as on
all targets we support ssize_t == ptrdiff_t.
ssize_t is a POSIX type used in the
On Tue, Apr 12, 2011 at 14:49, Lawrence Crowl wrote:
> This patch provides more finer, more precise compile time information.
> I sent an advisory mail some time ago, and it was good then. Please
> confirm for trunk.
The patch looks fine to me, but of course it's Jason the one you need
an OK fro
2011/4/12 Richard Henderson :
> On 04/12/2011 05:47 AM, Kai Tietz wrote:
>> ChangeLog gcc/
>>
>> * config/i386/mingw32.h (TARGET_SUBTARGET_DEFAULT): Add
>> MASK_MS_BITFIELD_LAYOUT bit.
>>
>> ChangeLog gcc/testsuite
>>
>> * g++.dg/ext/bitfield2.C: Add for i?86/x86_64-*-mingw*
>>
Hi,
the attached patch does a bit of janitorial type cleanup for the
library. It replaces the use of ssize_t with ptrdiff_t or index_type
where appropriate; this is entirely for documentation purposes, as on
all targets we support ssize_t == ptrdiff_t.
ssize_t is a POSIX type used in the IO funct
This patch to the Go frontend brings it up to date with Martin's change
to the cgraph code. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r cc9719612058 go/gogo-tree.cc
--- a/go/gogo-tree.cc Thu Apr 07 10:07:32 2011 -0700
+++ b/go/gogo-tree.cc T
On Apr 12, 2011, at 11:37 AM, Nicola Pero wrote:
> This fixes another small inefficiency in the Objective-C compiler.
>
> It's more about cleaning up the codebase and migrating it from Lisp to C.
You do know that we are reimplementing gcc in lisp, right? ^L It's a joke,
just a joke.
> Ok to
On Apr 12, 2011, at 11:04 AM, Nicola Pero wrote:
> This patch fixes another inefficiency in the Objective-C compiler.
> Ok to commit ?
Ok.
This patch stops targets not using the Linux kernel from using
linux*.h config headers.
gnu-user.h has TARGET_C99_FUNCTIONS and TARGET_HAS_SINCOS added
(defined to 1, overridden in linux.h) so that the non-Linux targets do
not need to have any libc-choice-related definitions from linux.h and
confi
This fixes another small inefficiency in the Objective-C compiler.
When a method invocation is found, and the parser calls objc_build_method_expr()
to compile it, it used to invoke it as in
objc_build_message_expr (build_tree_list (rec, args));
this (trivial) patch removes the need to create t
On Tue, Apr 12, 2011 at 09:31, Ralf Wildenhues wrote:
> Hi Janne,
>
> * Janne Blomqvist wrote on Mon, Apr 11, 2011 at 10:34:58PM CEST:
>> the attached patch removes the definition of _GNU_SOURCE from
>> AM_CPPFLAGS. This is not needed anymore since nowadays we're calling
>> AC_USE_SYSTEM_EXTENSION
Joseph S. Myers wrote:
> On Thu, 7 Apr 2011, Gunther Nikl wrote:
>
>>> an alias for -mcpu=68332 rather than -mcpu=cpu32, to match the old
>>> code in m68k_handle_option.) This significantly simplifies the
>>> multilibs code in t-mlibs, since it no longer needs to handle those
>>> old-style option
This patch fixes another inefficiency in the Objective-C compiler.
When it was comparing method signatures, it would copy all the argument types
into some temporary node chains, and then compare these copies. The copies
are then thrown away. It all seems really pointless (since you can just
acce
On 04/12/2011 05:47 AM, Kai Tietz wrote:
> ChangeLog gcc/
>
> * config/i386/mingw32.h (TARGET_SUBTARGET_DEFAULT): Add
> MASK_MS_BITFIELD_LAYOUT bit.
>
> ChangeLog gcc/testsuite
>
> * g++.dg/ext/bitfield2.C: Add for i?86/x86_64-*-mingw*
> targets the additional -mno-ms-bit
> This patch reintroduce the -mflat option on SPARC. The -mfalt option was
> deprecated in february 2004 with GCC 3.4.6. Now, with the support of
> LEON processor on GCC, this option has found a new interest.
Just a couple of remarks:
- the epilogue isn't fully RTL-ized,
- delay slot filling for
> Looks good to me, but please wait for Eric to chime in since you've been
> discussing it with him already.
Fine with me as well.
--
Eric Botcazou
On Apr 12, 2011, at 4:46 AM, Laurynas Biveinis wrote:
>> So what's the plan for the case where you need to change the lifetime of
>> an object?
>
> Copying it. Frankly at the moment I don't how much trouble does deep
> copying from scratch to function entails,
The code to copy isn't too hard and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/12/11 11:08, Jakub Jelinek wrote:
> On Tue, Apr 12, 2011 at 09:18:01AM +0200, Eric Botcazou wrote:
>>> The propagate_for_debug change alone could fix it, we should never
>>> fall through into next basic block. We are unforuntately not deleting
>
On Tue, Apr 12, 2011 at 09:18:01AM +0200, Eric Botcazou wrote:
> > The propagate_for_debug change alone could fix it, we should never
> > fall through into next basic block. We are unforuntately not deleting
> > just jumps (which ought to appear at the end of bbs), but also
> > any other noop move
Hi!
As the testcase below shows, cxx_eval_array_reference only works
properly if ary is CONSTRUCTOR or narrow STRING_CST, if it is
wchar_t/char16_t/char32_t string literal, it still reads a single
byte from the string as if it was a char string.
The following patch fixes that, bootstrapped/regtes
On Tue, 12 Apr 2011, Axel Freyn wrote:
> Hi,
>
> as that's the first time I propose a patch for gcc: sorry for all formal
> mistakes (and please tell me what I should do differently ...)
>
> Those lines were introduced in svn:164531 (22. Sep. 2010), but in
> svn:166534 (10. Nov. 2010) the part w
Changelog:
2011-04-12 Yufeng Zhang
* MAINTAINERS (Write After Approval): Add myself.
Regards,
Yufeng ZhangIndex: MAINTAINERS
===
--- MAINTAINERS (revision 172321)
+++ MAINTAINERS (working copy)
@@ -510,6 +510,7 @@
Joey Y
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/07/11 04:47, Bernd Schmidt wrote:
> PR47976 is a followup to PR47166; the patch there caused this problem.
>
> The problem occurs in reload. There are two autoinc addresses which
> inherit from one another, and we delete an insn that is necessar
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/11/11 13:52, Jakub Jelinek wrote:
> Hi!
>
> On the following testcase build_unary_op ICEs, because
> the element type of the array variable (which is TREE_READONLY)
> unexpectedly is not TYPE_READONLY.
> The problem seems to come from store_init
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/12/11 05:54, Bernd Schmidt wrote:
> On 04/11/2011 10:03 PM, Jeff Law wrote:
>> One of the fundamental problems you have to watch out for when dealing
>> with scratch objects is how to handle the case when you belatedly
>> realize you want the obj
On 12.04.11 17:06, Joern Rennecke wrote:
2011-03-12 Andreas Tobler
* config/rs6000/freebsd.h: (RELOCATABLE_NEEDS_FIXUP): Define in
terms of target_flags_explicit. Adjust copyright year.
* config.gcc: Add FreeBSD PowerPC soft-float libgcc bits.
* config/rs6
On Tue, Apr 12, 2011 at 04:54:43PM +0200, Richard Guenther wrote:
> On Tue, Apr 12, 2011 at 4:51 PM, Nathan Froyd
> wrote:
> > True, but maybe those testcases should be adjusted--per-pass flags,
> > rather than blindly assuming -O2 includes them. And it's not clear to
>
> It's easier to add thi
2011-03-12 Andreas Tobler
* config/rs6000/freebsd.h: (RELOCATABLE_NEEDS_FIXUP): Define in
terms of target_flags_explicit. Adjust copyright year.
* config.gcc: Add FreeBSD PowerPC soft-float libgcc bits.
* config/rs6000/t-freebsd: New file. Add override fo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/12/11 02:45, Steven Bosscher wrote:
> On Tue, Apr 12, 2011 at 9:01 AM, Jakub Jelinek wrote:
>> On Tue, Apr 12, 2011 at 08:33:56AM +0200, Steven Bosscher wrote:
>>> I think all these comments from you "old guys" ;-) are more
>>> discouraging than
On Tue, Apr 12, 2011 at 4:37 PM, Richard Guenther
wrote:
> Yes, I used it exactly for that. And also to verify that passes don't
> do anything if replicated (well, for those that shouldn't at least).
What about passes that undo the work of previous patches -- and then
followed by a patch that re
"H.J. Lu" writes:
> I think your patch caused:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48573
Sorry, this didn't show up on pure x86_64. It was caused by the
optabs.c patch rather than this one. I've reverted it for now.
One fix would be:
/* If the operand is a memory, try forcing th
On Tue, Apr 12, 2011 at 4:51 PM, Nathan Froyd wrote:
> On Tue, Apr 12, 2011 at 04:37:42PM +0200, Richard Guenther wrote:
>> On Tue, Apr 12, 2011 at 4:32 PM, Nathan Froyd
>> wrote:
>> > Thanks. I may go twiddle that patch to do something similar to mine and
>> > submit that. Do you use your pat
On Tue, Apr 12, 2011 at 04:37:42PM +0200, Richard Guenther wrote:
> On Tue, Apr 12, 2011 at 4:32 PM, Nathan Froyd
> wrote:
> > Thanks. I may go twiddle that patch to do something similar to mine and
> > submit that. Do you use your patch for checking that the same set of
> > optimizations get p
Hello,
Sorry for getting back to this just now, and thank you very much for the
review. Please find below my reply to your comments.
Tom Tromey writes:
> Dodji>expanded_location xloc;
> Dodji>if (loc <= BUILTINS_LOCATION)
> Dodji> -{
> Dodji> - xloc.file = loc == UNKNOWN_LOCAT
Richard Guenther writes:
> On Tue, Apr 12, 2011 at 3:28 PM, Richard Sandiford
> wrote:
>> This patch just reindents part of vectorizable_load and vectorizable_store
>> so that the main diff is easier to read. It also CSEs the element type,
>> which seemed better than breaking the long lines.
>>
On Tue, Apr 12, 2011 at 4:32 PM, Nathan Froyd wrote:
> On Tue, Apr 12, 2011 at 04:27:01PM +0200, Richard Guenther wrote:
>> On Tue, Apr 12, 2011 at 4:16 PM, Nathan Froyd
>> wrote:
>> > It's a shame more passes don't make use of the statistics_*
>> > infrastructure. This patch is a step towards
This patch adds a test for stride-3 accesses. I didn't add any
particularly complicated cases because I think the testsuite already
covers the interaction between the strided loads & stores and other
operations pretty well. Let me know if there's something I should
add though.
Tested on x86_64-l
On Tue, Apr 12, 2011 at 04:27:01PM +0200, Richard Guenther wrote:
> On Tue, Apr 12, 2011 at 4:16 PM, Nathan Froyd
> wrote:
> > It's a shame more passes don't make use of the statistics_*
> > infrastructure. This patch is a step towards rectifying that and adds
> > statistics_counter_event calls
This patch replaces the general vect_strided target selector with
a group of vect_stridedN selectors, one for each tested stride factor N.
Also, some tests used vect_interleave && vect_extract_even_odd for
strided accesses. The two conditions used to be equivalent, but aren't
after this series fo
On Tue, Apr 12, 2011 at 4:16 PM, Nathan Froyd wrote:
> It's a shame more passes don't make use of the statistics_*
> infrastructure. This patch is a step towards rectifying that and adds
> statistics_counter_event calls to passes mentioned in $SUBJECT.
> postreload-gcse already tracked the stats
The next patch introduces separate vect_stridedN target selectors
for each tested stride factor N. At the moment, some tests contain
several independent loops that have different stride factors.
It's easier to make the next change if we put these loops into
separate tests.
Tested on x86_64-linux-
It's a shame more passes don't make use of the statistics_*
infrastructure. This patch is a step towards rectifying that and adds
statistics_counter_event calls to passes mentioned in $SUBJECT.
postreload-gcse already tracked the stats for the dump file and so only
needs the statistics_counter_eve
Hi,
as that's the first time I propose a patch for gcc: sorry for all formal
mistakes (and please tell me what I should do differently ...)
Those lines were introduced in svn:164531 (22. Sep. 2010), but in
svn:166534 (10. Nov. 2010) the part which could change "argv_copied"
was removed. As no-whe
We have separate vect_extract_even_odd and vect_extract_even_odd_wide
target selectors, and separate vect_strided and vect_strided_wide
selectors. The comment suggests that "wide" is for 32+ bits,
but we often use the non-wide forms for 32-bit tests. We also have
tests that combine 16-bit and 32-
On Tue, Apr 12, 2011 at 5:28 AM, Richard Sandiford
wrote:
> This patch is a prerequisite for:
>
> http://gcc.gnu.org/ml/gcc-patches/2011-03/msg02168.html
>
> (approved but not yet applied, because I'd forgotten about this).
>
> At the moment, gen* programs that want predicate information need
>
This patch adds vec_load_lanes and vec_store_lanes patterns for NEON.
They feed directly into the corresponding intrinsic patterns.
Tested on x86_64-linux-gnu and arm-linux-gnueabi. OK to install?
Richard
gcc/
* config/arm/neon.md (vec_load_lanes): New expanders,
(vec_store_lan
This patch adds vec_load_lanes and vec_store_lanes optabs for instructions
like NEON's vldN and vstN. The optabs are defined this way because the
vectors must be allocated to a block of consecutive registers.
Tested on x86_64-linux-gnu and arm-linux-gnueabi. OK to install?
Richard
gcc/
On Tue, Apr 12, 2011 at 3:44 PM, Richard Sandiford
wrote:
> NEON has vld3 and vst3 instructions, which support an interleaving of
> three vectors. This patch therefore removes the blanket power-of-two
> requirement for interleaving and enforces it on a per-operation
> basis instead.
>
> The patch
NEON has vld3 and vst3 instructions, which support an interleaving of
three vectors. This patch therefore removes the blanket power-of-two
requirement for interleaving and enforces it on a per-operation
basis instead.
The patch also replaces:
/* Check that the operation is supported. */
if
vectorizable_store contains the code:
for (j = 0; j < ncopies; j++)
{
for (i = 0; i < vec_num; i++)
{
...
if (j == 0)
STMT_VINFO_VEC_STMT (stmt_info) = *vec_stmt = new_stmt;
else
STMT_VINFO_RELATED_STMT (prev
On Tue, Apr 12, 2011 at 3:28 PM, Richard Sandiford
wrote:
> This patch just reindents part of vectorizable_load and vectorizable_store
> so that the main diff is easier to read. It also CSEs the element type,
> which seemed better than breaking the long lines.
>
> I've included both the real diff
On Tue, Apr 12, 2011 at 3:24 PM, Richard Sandiford
wrote:
> This first patch generalises vect_create_data_ref_ptr & bump_data_ref_ptr
> so that they can handle array as well as vector types. The two cases are
> so similar that it's mostly a renaming exercise.
>
> Tested on x86_64-linux-gnu and ar
This patch just reindents part of vectorizable_load and vectorizable_store
so that the main diff is easier to read. It also CSEs the element type,
which seemed better than breaking the long lines.
I've included both the real diff and a -b version.
Tested on x86_64-linux-gnu and arm-linux-gnueabi
This first patch generalises vect_create_data_ref_ptr & bump_data_ref_ptr
so that they can handle array as well as vector types. The two cases are
so similar that it's mostly a renaming exercise.
Tested on x86_64-linux-gnu and arm-linux-gnueabi. OK to install?
Richard
gcc/
* tree-vect
The vectoriser can handle interleaved loads such as:
for (int i = 0; i < N; i++)
res[i] = a[2 * i] + a[2 * i + 1];
The vectorised code loads two consecutive vectors from A, then permutes
the elements. It can handle stores in a similar way.
This patch series adds support for load and s
On Tue, Apr 12, 2011 at 3:09 PM, Richard Sandiford
wrote:
> vectorizable_load allocates n_copies+1 dr_chains, even though only
> the first n_copies are needed. This patch removes the extra one and
> IMO makes the flow a bit more obvious.
>
> Tested on x86_64-linux-gnu and arm-linux-gnueabi. OK t
On Tue, Apr 12, 2011 at 3:05 PM, Richard Sandiford
wrote:
> vectorizable_store prints the number of copies in the dump output,
> but vectorizable_loads doesn't.
>
> Tested on x86_64-linux-gnu and arm-linux-gnueabi. OK to install?
Ok.
Thanks,
Richard.
> Richard
>
>
> gcc/
> * tree-vect-s
vectorizable_load allocates n_copies+1 dr_chains, even though only
the first n_copies are needed. This patch removes the extra one and
IMO makes the flow a bit more obvious.
Tested on x86_64-linux-gnu and arm-linux-gnueabi. OK to install?
Richard
gcc/
* tree-vect-stmts.c (vectorizable
vectorizable_store prints the number of copies in the dump output,
but vectorizable_loads doesn't.
Tested on x86_64-linux-gnu and arm-linux-gnueabi. OK to install?
Richard
gcc/
* tree-vect-stmts.c (vectorizable_load): Print the number of copies
in the dump file.
Index: gcc/tre
David Miller writes:
> From: Rainer Orth
> Date: Mon, 11 Apr 2011 14:57:58 +0200
>
>> The follwing patch uses the easy way out and just tests ld_ver. Tested
>> with make configure-gcc on sparc-sun-solaris2.11 with Sun as/ld, GNU
>> as/Sun ld, and GNU as/ld without change to gcc/auto-host.h and
Hello,
This patch enables by default for native Windows targets the
-mms-bitfields option, like the netware target does.
ChangeLog gcc/
* config/i386/mingw32.h (TARGET_SUBTARGET_DEFAULT): Add
MASK_MS_BITFIELD_LAYOUT bit.
ChangeLog gcc/testsuite
* g++.dg/ext/bitfield2.C:
On 04/12/2011 02:28 PM, Richard Sandiford wrote:
> This patch is a prerequisite for:
>
> http://gcc.gnu.org/ml/gcc-patches/2011-03/msg02168.html
>
> (approved but not yet applied, because I'd forgotten about this).
>
> At the moment, gen* programs that want predicate information need
> t
On Apr 12 2011, Michael Matz wrote:
On Mon, 11 Apr 2011, Steven Bosscher wrote:
Isn't there a way to put a maximum on the size of the arrays on stack,
e.g. -fstack-arrays-limit= or something like that?
Not without generating contorded code. The problem is that these arrays
are variable leng
This patch is a prerequisite for:
http://gcc.gnu.org/ml/gcc-patches/2011-03/msg02168.html
(approved but not yet applied, because I'd forgotten about this).
At the moment, gen* programs that want predicate information need
to process the DEFINE*_PREDICATE directives themselves. They can
On Tue, 2011-04-12 at 11:14 +0100, Andrew Stubbs wrote:
> [Ignoring the other issues for now ...]
>
> On 12/04/11 11:02, Richard Earnshaw wrote:
> > Also, your change to use a double-letter sequence beginning with 'j'
> > means any hand-written inline assembly code using a single 'j' will
> > bre
1 - 100 of 128 matches
Mail list logo
