Hello,
with this move to t-bpabi other targets like RTEMS profit also from this
change. This is very good since the unwinder pull-in for 64-bit divisions was
pretty bad for small Cortex-M3 systems with internal flash only.
--
Sebastian Huber, embedded brains GmbH
Address : Obere Lagerstr.
On Fri, Jul 27, 2012 at 5:24 PM, Ulrich Weigand uweig...@de.ibm.com wrote:
Richard Guenther wrote:
On Mon, Jun 11, 2012 at 5:25 PM, Richard Earnshaw rearn...@arm.com wrote:
On 11/06/12 15:53, Richard Guenther wrote:
The type argument or the size argument looks redundant.
Technically,
On Fri, 27 Jul 2012, Richard Guenther wrote:
This avoids triggering update-ssa right after into-ssa just because
we didn't rename virtual operands yet. Simply do that on-the-fly,
update_stmt will have added bare symbols as operands already.
Surprisingly simple ... no idea why I chose the
On 28 July 2012 10:26, Marc Glisse marc.gli...@inria.fr wrote:
On Mon, 18 Jun 2012, Ramana Radhakrishnan wrote:
This patch following on from the fix for turning on __builtin_shuffle
for c++ , enables folding of vec_perm_exprs in the front-end for
constexpr and constructor style values.
Hi,
I've been working on a small project to improve neon intrinsic
and I kept getting bothered by random failures in gcc.target/arm/neon
and I got sufficiently irritated that I decided to clean that bit up
and then found myself in a maze of rabbit holes. I've always been
somewhat bothered by
Patch 1 fixes up the vaba and vabal patterns to use a canonical RTL
form with the first operand to the plus being the more complex one.
This patch canonicalizes the instruction patterns for the
vaba and vabal intrinsics so that the more complex operand
to plus is the first operand. This
Patch 2 is a bug fix that fixes up the splitters so that they take
into account the right register for the right mode . For instance a
register not fit for a TImode value shouldn't be put in one even if
the larger mode allows a different register . This is possible for
OImode values or indeed
Hi,
lower-subreg.c goes completely bonkers at times with code
that uses the large vector modes, especially the vld3 / vst3
type operations. In these cases these large modes are usually
split into SImode moves which then cause massive spilling
and in these cases we end up generating really really
On 30 July 2012 12:41, Ramana Radhakrishnan
ramana.radhakrish...@linaro.org wrote:
Hi,
I've been working on a small project to improve neon intrinsic
and I kept getting bothered by random failures in gcc.target/arm/neon
and I got sufficiently irritated that I decided to clean that bit up
On 30 July 2012 12:41, Ramana Radhakrishnan
ramana.radhakrish...@linaro.org wrote:
Patch 5 - Bug fix that fixes up a set of ICEs because we were always
generating vec_duplicate of DImode values into other DImode values.
Possibly needs backporting to older versions.
The recent changes to the
Hi,
This is similar to the previous patch except that it prevents
(vec_select:DI (operand:DI)) type operations.
Exposed by the vst*_lane*.c tests in the new testsuite.
regards,
Ramana
2012-07-27 Ramana Radhakrishnan ramana.radhakrish...@linaro.org
* config/arm/neon.md
Ehm ...
* gcc.target/i386/sse-13.c: Ditto.
* gcc.target/i386/sse-14.c: Ditto.
* g++.dg/other/i386-2.C: Ditto.
* g++.dg/other/i386-3.C: Ditto.
Sorry, what's wrong here?
I suggest you implement handling of this builtin in the same way
rdrandmode_1 is
I only remembered to add DEF_VEC_A handlgin to gengtype.c a second after
committing the previous patch [1].
Here it is, done as a follow up. With some luck, this will be short-lived code
because of the C++ conversion.
Bootstrapped and regtested on x86_64 linux. OK for trunk?
2012-07-30
On Mon, Jul 30, 2012 at 2:05 PM, Kirill Yukhin kirill.yuk...@gmail.com wrote:
Ehm ...
* gcc.target/i386/sse-13.c: Ditto.
* gcc.target/i386/sse-14.c: Ditto.
* g++.dg/other/i386-2.C: Ditto.
* g++.dg/other/i386-3.C: Ditto.
Sorry, what's wrong here?
Not here,
On Mon, Jul 30, 2012 at 2:05 PM, Kirill Yukhin kirill.yuk...@gmail.com wrote:
ChangeLog entry:
2012-07-25 Kirill Yukhin kirill.yuk...@intel.com
Michael Zolotukhin michael.v.zolotuk...@intel.com
* common/config/i386/i386-common.c (OPTION_MASK_ISA_RDSEED_SET): New.
Joseph == Joseph S Myers jos...@codesourcery.com writes:
Tom I wasn't really aware of 6.3.2.1, but after reading it and re-reading
Tom 6.5.1.1, I think I agree with his model 0 interpretation: no promotion
Tom or conversion.
Tom I don't have a standards-based reason for this, though; just my
OK with that change.
Thanks a lot!
Checked into the trunk: http://gcc.gnu.org/ml/gcc-cvs/2012-07/msg00878.html
Thanks, K
On Mon, Jul 30, 2012 at 2:41 PM, Laurynas Biveinis
laurynas.bivei...@gmail.com wrote:
I only remembered to add DEF_VEC_A handlgin to gengtype.c a second after
committing the previous patch [1].
Here it is, done as a follow up. With some luck, this will be short-lived
code because of the C++
Richard Henderson wrote:
Tested only as far as cross-compile. I had a browse through
objdump of libatomic for a brief sanity check.
Can you please test on real hw and report back?
I'll run a test, but a couple of things I noticed:
/* Shift the values to the correct bit positions. */
Hi,
I've been investigating a patch which we've been using locally to fix
an issue with backtraces (using, e.g., glibc's backtrace() function)
through C++ exception-handling constructs on ARM. The original author of
the patch was Daniel Jacobowitz (please correct me if my understanding
is
This makes into-SSA no longer rely on variable annotations and instead
uses on-the-side information local to into/update-SSA. Lookups can
probably be avoided in some places if we pass around the auxiliar
information instead of looking it up all the time.
Bootstrapped and tested on
On Mon, 30 Jul 2012, Tom Tromey wrote:
6.3 is about conversions, and the first paragraph starts several
operators convert Based on this, and other such phrases in the
text, I think the entire section applies to operators.
6.3.2.1 paragraphs 2 and 3 are phrased in terms of operators
Richard Guenther wrote:
On Fri, Jul 27, 2012 at 5:24 PM, Ulrich Weigand uweig...@de.ibm.com wrote:
OK for mainline?
Ok. Please add to the documentation that the default vector alignment
has to be a power-of-two multiple of the default vector element alignment.
Committed, thanks. The
On Fri, 27 Jul 2012 15:40:35 +0200 Richard Guenther
richard.guent...@gmail.com wrote:
Also it looks less efficient than sbitmap in the case when
your main operation is adding to the set and querying the set randomly.
How so? Adding/deleting a member to a sparseset is an O(1) operation,
as is
Joseph == Joseph S Myers jos...@codesourcery.com writes:
Joseph On Mon, 30 Jul 2012, Tom Tromey wrote:
6.3 is about conversions, and the first paragraph starts several
operators convert Based on this, and other such phrases in the
text, I think the entire section applies to operators.
On Mon, Jul 30, 2012 at 4:43 PM, Peter Bergner berg...@vnet.ibm.com wrote:
On Fri, 27 Jul 2012 15:40:35 +0200 Richard Guenther
richard.guent...@gmail.com wrote:
Also it looks less efficient than sbitmap in the case when
your main operation is adding to the set and querying the set randomly.
On Mon, Jul 30, 2012 at 4:53 PM, Richard Guenther
richard.guent...@gmail.com wrote:
No, but less space efficient and of comparable speed as sbitmap which
is also O(1).
But iterating an sbitmap has worse complexity than sparseset.
Ciao!
Steven
On 2012-07-30 07:09, Ulrich Weigand wrote:
Richard Henderson wrote:
Tested only as far as cross-compile. I had a browse through
objdump of libatomic for a brief sanity check.
Can you please test on real hw and report back?
I'll run a test, but a couple of things I noticed:
/*
This patch implements a new lock-free restriction. Thus, implicit dereferences
of access values prevent, as well as explicit dereference, the lock-free
implementation of protected objects.
The test below illustrates the new lock-free restriction:
-- Source --
generic
On Mon, Jul 30, 2012 at 5:14 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Mon, Jul 30, 2012 at 5:05 PM, Steven Bosscher stevenb@gmail.com
wrote:
On Mon, Jul 30, 2012 at 4:53 PM, Richard Guenther
richard.guent...@gmail.com wrote:
No, but less space efficient and of comparable
This change fixes the circuitry that passes binder flags from gnatmake:
for some switches, relative path arguments are changed to absolute paths.
However, for gnatbind the -A switch must not undergo this transformation.
Tested on x86_64-pc-linux-gnu, committed on trunk
2012-07-30 Thomas Quinot
On Mon, Jul 30, 2012 at 5:05 PM, Steven Bosscher stevenb@gmail.com wrote:
On Mon, Jul 30, 2012 at 4:53 PM, Richard Guenther
richard.guent...@gmail.com wrote:
No, but less space efficient and of comparable speed as sbitmap which
is also O(1).
But iterating an sbitmap has worse complexity
This change adds a special case to Get_Socket_Option and Set_Socket_Option
to account for a deviation of Windows' behaviour with respect to the
standard sockets API: on that target, SO_RCVTIMEO and SO_SNDTIMEO expect
a DWORD containing a milliseconds count, not a struct timeval, and furthermore
if
On 2012-07-29 15:56, Oleg Endo wrote:
+ can_create_pseudo_p ()
+ [(set (match_dup 5) (ashift:SI (match_dup 1) (match_dup 2)))
+ (set (match_dup 6) (plus:SI (match_dup 5) (match_dup 3)))
+ (set (match_dup 0) (mem:SI (plus:SI (match_dup 6) (match_dup 4]
Don't create new mems like
On 2012-07-27 16:21, Nathan Froyd wrote:
* defaults.h (GO_IF_MODE_DEPENDENT_ADDRESS): Delete.
* targhooks.c (default_mode_dependent_address_p): Delete code
for GO_IF_MODE_DEPENDENT_ADDRESS.
* system.h (GO_IF_MODE_DEPENDENT_ADDRESS): Poison.
* doc/tm.texi.in
On Mon, 30 Jul 2012, Tom Tromey wrote:
Joseph == Joseph S Myers jos...@codesourcery.com writes:
Joseph On Mon, 30 Jul 2012, Tom Tromey wrote:
6.3 is about conversions, and the first paragraph starts several
operators convert Based on this, and other such phrases in the
text, I
Richard Henderson wrote:
On 2012-07-30 07:09, Ulrich Weigand wrote:
This seems to disable use of ICM / STCM to perform byte or
aligned halfword access. Why is this necessary? Those operations
are supposed to provide the required operand consistency ...
Because MEM_P for cmp and new_rtx
Committed as obvious.
Tested on hppa2.0w-hp-hpux11.11 and hppa-unknown-linux-gnu.
Dave
--
J. David Anglin dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
2012-07-30 John David Anglin
On 07/30/2012 03:18 PM, Julian Brown wrote:
There are two issues in play here:
1. Exception-handling is handled in a target-specific way for ARM,
defined in the EHABI document (Exception handling ABI for the ARM
architecture, IHI 0038A). However, no mention of forced unwinding is
made in
Hi,
On Mon, 30 Jul 2012, Richard Guenther wrote:
This makes into-SSA no longer rely on variable annotations and instead
uses on-the-side information local to into/update-SSA. Lookups can
probably be avoided in some places if we pass around the auxiliar
information instead of looking it up
The MIPS back end has an option -mno-float that is supported by
bare-metal configs using the SDE library. However, this option is not
properly documented in the manual, and MIPS_ARCH_FLOAT_SPEC doesn't know
about it as one of the explicit floating-point configuration changes
that should
On 07/30/2012 08:40 AM, Ulrich Weigand wrote:
I presume a good test case to examine for ICM is with such an operand
coming from a global. What about STCM? I don't see the output from
sync_compare_and_swap ever being allowed in memory...
Actually, it's only ICM that is of interest here; it
This fixes the de-canonicalization of commutative GIMPLE operations in
the vectorizer that occurs when processing reductions. A loop_vec_info
is flagged for cleanup when a de-canonicalization has occurred in that
loop, and the cleanup is done when the loop_vec_info is destroyed.
Bootstrapped on
On Thu, Jul 19, 2012 at 1:39 PM, Jason Merrill ja...@redhat.com wrote:
On 07/10/2012 03:14 PM, Sriraman Tallam wrote:
I am using the questions you asked previously
to explain how I solved each of them. When working on this patch, these
are the exact questions I had and tried to address it.
On 30 July 2012 20:16, François Dumont wrote:
Ok for trunk ?
OK, thanks.
Sandra Loosemore san...@codesourcery.com writes:
The MIPS back end has an option -mno-float that is supported by
bare-metal configs using the SDE library. However, this option is not
properly documented in the manual, and MIPS_ARCH_FLOAT_SPEC doesn't know
about it as one of the explicit
On Mon, 30 Jul 2012 12:51:47 +0100
Ramana Radhakrishnan ramana.radhakrish...@linaro.org wrote:
This patch converts the testsuite generator to actually produce
something more sensible than the current set of tests. It changes
these to generate the following form for a test instead of the
On Mon, 2012-07-30 at 08:28 -0700, Richard Henderson wrote:
On 2012-07-29 15:56, Oleg Endo wrote:
+ can_create_pseudo_p ()
+ [(set (match_dup 5) (ashift:SI (match_dup 1) (match_dup 2)))
+ (set (match_dup 6) (plus:SI (match_dup 5) (match_dup 3)))
+ (set (match_dup 0) (mem:SI
On 07/28/2012 11:28 AM, Paolo Carlini wrote:
as the testcase shows (merge of 53624 54104), in case of local types
(possibly synthesized for a lambda) we check for the default template
arguments of the synthesized template parameters according to the rules
for *types* (instead of those for
Now that we can freely change the representation of the cost fields in
struct target_expmed, the patch below does so, by only requiring arrays
to hold enough storage for integer modes and/or vector integer modes,
as appropriate.
default_target_expmed shrinks from ~200KB to ~85KB on
On 07/30/2012 01:38 PM, Richard Sandiford wrote:
...unfortunately, it doesn't prevent the use floating-point operations.
That's why it's such a bad option. The only difference from the compiler
proper's point of view between -msoft-float and -mno-float is that they
define different
On 07/30/2012 01:38 PM, Richard Sandiford wrote:
...unfortunately, it doesn't prevent the use floating-point operations.
That's why it's such a bad option. The only difference from the compiler
proper's point of view between -msoft-float and -mno-float is that they
define different
Hi,
On 07/30/2012 10:10 PM, Jason Merrill wrote:
On 07/28/2012 11:28 AM, Paolo Carlini wrote:
as the testcase shows (merge of 53624 54104), in case of local types
(possibly synthesized for a lambda) we check for the default template
arguments of the synthesized template parameters according
The atomic_load/storedi_1 patterns are fixed to use LM, STM.
I've had a go at generating better code in the HQImode CAS
loop for aligned memory, but I don't know that I'd call it
the most efficient thing ever. Some of this is due to
deficiencies in other parts of the compiler (including the
Try RISBG last, after other mechanisms have failed; don't require
operands in registers for it but force them there instead. Try a
limited form of ICM.
---
gcc/config/s390/s390.c | 129 ++-
1 files changed, 82 insertions(+), 47 deletions(-)
diff
Split out s390_two_part_insv from s390_expand_cs_hqi to try
harder to use bit insertion instructions in the CAS loop.
---
gcc/config/s390/s390-protos.h |3 +-
gcc/config/s390/s390.c| 141 ++-
gcc/config/s390/s390.md | 401 +
On 07/30/2012 02:05 PM, Nathan Froyd wrote:
* expmed.h (NUM_MODE_VECTOR_INT): Define.
(struct expmed_op_cheap, struct expmed_op_costs): New structures.
(struct target_expmed): Convert x_mul_highpart_cost and
x_mul_widen_cost fields to be indexed by integer modes.
On 07/30/2012 06:26 PM, Paolo Carlini wrote:
+ if ((cxx_dialect == cxx98)
+ || (TREE_CODE (decl) != FUNCTION_DECL is_primary))
We shouldn't do this check for non-primary templates in C++98 mode, either.
Jason
Hello,
This PR concerns a huge compile time regression since
-ftrack-macro-expansion=2 became the default. It turns out that
gengtype generates code that is quadratic in the GTY((length)) of
arrays, and in this case (a PCH for a Boost header...) there are 183k
maps for macro expansion line maps
On 07/31/2012 12:42 AM, Jason Merrill wrote:
On 07/30/2012 06:26 PM, Paolo Carlini wrote:
+ if ((cxx_dialect == cxx98)
+ || (TREE_CODE (decl) != FUNCTION_DECL is_primary))
We shouldn't do this check for non-primary templates in C++98 mode,
either.
Yes. Thus the below also passes
OK.
Jason
Hi,
This patch fixed the problem when a LOOP_EXIT edge for the inner loop
happened to target at the LOOP_LATCH of the outer loop. As the outer
loop is processed first, the LOOP_BRANCH heuristic is honored
(first_match), thus the inner loop's trip count is 0. (The attached
unittest demonstrates
Hi,
This patch fixes the source location for automatically generated calls
to deallocator. For example:
19 void foo(int i)
20 {
21 for (int j = 0; j 10; j++)
22 {
23 t test;
24 test.foo();
25 if (i + j)
26 {
27 test.bar();
28 return;
The TPF assembler supports dwarf4 discriminators, but the TPF
debuggers do not. Ok to apply?
* config/s390/tpf.h (SUPPORTS_DISCRIMINATOR): Define to 0 for TPF.
Index: gcc/config/s390/tpf.h
===
--- gcc/config/s390/tpf.h
Hi -
See http://gcc.gnu.org/PR53880#c27
Could you please have a look at that problem, and see if you, with all
your GTY-fu, see an easy way out?
It looks like you beat me to it :)
--
Laurynas
Steven -
Bootstrappedtested on powerpc64-unknown-linux-gnu. OK for trunk?
Thanks for working on this. It looks good, couple of minor comments:
Please add an assert that d-have_this_obj == true in
write_types_local_process_field, before the oprintf that outputs
this_obj.
@@ -3444,6 +3449,7 @@
66 matches
Mail list logo
