> > Do I understand correctly that the "only" issue is memory vs. register
> > element ordering? Thus a fixup could be as simple as extra shuffles
> > inserted after vector memory loads and before vector memory stores?
> > (with the hope of RTL optimizers optimizing those)?
>
> It's not even nece
> > > I can't exactly remember why we didn't do that to start with. I
> > > think the problem was ABI-related, or to do with transferring NEON
> > > vectors to/from ARM registers when it was necessary to do that...
> > > I'm planning to do some archaeology to try to see if I can figure
> > > out a
> I somehow missed the "Appendix A: Support for Advanced SIMD Extensions"
> in the AAPCS document (it's not in the TOC!). It looks like the
> builtin vector types are indeed defined to be stored in memory in
> vldm/vstm order -- I think that means we're back to square one.
There's still the possib
> I checked the attached patch, test results at
> http://gcc.gnu.org/ml/gcc-testresults/2011-10/msg01377.html
>
> which are the same as with my suggested patch.
>
> Ok for the trunk?
I probably don't have authority to approve this, but looks OK to me.
Paul
ready logic to make sure we keep the
original. My guess is this bug is probably latent in other IPA passes.
Tested on mips-linux and bootstrap+test x86_64-linux
Ok?
Paul
2011-10-27 Paul Brook
gcc/
* cgraphunit.c: Don't mark clones as static constructors.
gcc
> Ok if you move the clearing to after
>
> /* Generate a new name for the new version. */
> DECL_NAME (new_decl) = clone_function_name (old_decl, clone_name);
> SET_DECL_ASSEMBLER_NAME (new_decl, DECL_NAME (new_decl));
> SET_DECL_RTL (new_decl, NULL);
>
> using new_decl directly, thus add
> > >+strcpy (pattern, \"fldmfdd\\t\");
> > >+strcat (pattern,
> > >+reg_names[REGNO (SET_DEST (XVECEXP (operands[0], 0,
> > >0)))]); +strcat (pattern, \"!, {\");
> > >+strcat (pattern, table[(REGNO (XEXP (XVECEXP (operands[0], 0, 1),
> > >0)) +
> Hi,
>
> The patch that Andrew Stubbs sent upstream here:
>
> http://gcc.gnu.org/ml/gcc-patches/2011-04/msg02130.html
>
> seems to have become stalled after Ramana's question here:
>
> http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00291.html
>
> This was discussed with ARM personnel (i.e. Lee
> Testing:
> * Crossbuild for target arm-none-eabi with cpu cortex-a9 neon softfp and
> tested in three configuration: -marm (default), -mthumb, -mapcs-frame. No
> regression on qemu.
> * Crossbuild for target arm-none-eabi thumb2 with cpu cortex-m3. No
> regression on qemu.
> * Crossbuild for targ
we proceed as before.
Tested on arm-none-eabi
Applied to svn.
Paul
2011-09-19 Paul Brook
gcc/
* config/arm/predicates.md (shift_amount_operand): Check constant
shift count is in range.
(const_shift_
> Hi Nick,
>
> On 27 September 2011 15:38, Nick Clifton wrote:
> > Any comments or objections to this patch ? If not, I will apply it
> > next week.
>
> I've got a few objections to this patch as it stands today while I
> don't object to the motivation for it.
>
> > +/* Get the definitions o
>2. Abandon using a header file at all. Instead use a configure test
> to see if we are using an assembler that supports textual names in a
> .eabi_attribute directive and if so use the names rather than the numbers.
I'm not sure this is mutually exclusive with using a header file, but using
.
Applied to svn trunk.
Paul
2011-10-03 Paul Brook
libgcc/
* unwind-arm-common.inc: Handle ID3/4 unwinding data.
Index: libgcc/unwind-arm-common.inc
===
--- libgcc/unwind-arm-common.inc(revision 179178)
+++ libgcc
Patch below makes gcc emit the resuired assembly directives for c6x unwinding
tables, same as ARM and IA64. This fixes most of the unwinding related
failures.
Tested on c6x-elf
Ok?
Paul
2011-10-03 Paul Brook
* config/c6x/c6x.c (c6x_asm_emit_except_personality
> On 10/03/11 17:57, Paul Brook wrote:
> > Patch below makes gcc emit the resuired assembly directives for c6x
> > unwinding tables, same as ARM and IA64. This fixes most of the
> > unwinding related failures.
>
> Most?
There are a number of failures in g++.dg/torture
> I believe this patch to be nothing but an improvement over the current
> state, and that a fix to the constraint problem should be a separate patch.
>
> In that basis, am I OK to commit?
One minor nit:
> (define_special_predicate "shift_operator"
>...
>+ (ior (match_test "GET_CODE (XEXP (
> Oh, I forgot to say, I don't understand why the "rotate" operator is
> special cased?
>
> If I understand it correctly, the effect of the (existing) rotate is
> both to check the constant range, AND to disallow registers as the shift
> amount. This difference has no effect on Thumb, but might ca
> Done, and attached.
Ok.
Two changes to the testcase that I'll pre-approve:
- Add a comment along the lines of
/* ARM has shift-and-alu insns. Depending on the ALU op GCC represents some
of these as a left shift, others as a multiply. Check that we match the
right one. */
- Also test
> Index: libjava/exception.cc
> ===
> --- libjava/exception.cc (revision 179739)
> +++ libjava/exception.cc (working copy)
> @@ -135,6 +135,7 @@
> {
>_Unwind_Ptr Start;
>_Unwind_Ptr LPStart;
> + _Unwind_Ptr ttype_ba
> while I have your attention: what is an virtual unwind frame? ;)
No such thing exists.
Throwing an exception is a muti-stage process. It requires unwinding the
stack frame twice, taking different actions in the process. "Forced"
unwinding and backtracing add extra complications. The _US_*
> On 01/29/2012 07:57 AM, Tom de Vries wrote:
> > Richard,
> >
> > [now cc-ing gcc-patches]
> >
> > this patch fixes PR50283 in a target-independent way.
> >
> > it asserts on frame-related insns in the delay slot of insns that can
> > throw, and prevents the assert by testing for the same condi
> On 01/30/2012 11:07 AM, Paul Brook wrote:
> > It's worth noting that -fasync-unwind-tables does not guarantee
> > backtrace/unwind from arbitrary points. Only from those instructions
> > that may result in a synchronous trap (which matches the semantics of
> >
time.
Tested on arm-none-eabi
Applied to SVN head.
Paul
2011-06-01 Paul Brook
gcc/
* config/arm/arm-cores.def: Add cortex-r5. Add DIV flags to
Cortex-A15.
* config/arm/arm-tune.md: Regenerate.
* config/arm/arm-tables.opt: Regenerate.
* config/arm/
> gcc/
> * config/arm/arm.c (arm_libcall_uses_aapcs_base)
> (arm_init_cumulative_args): Use correct ABI for double-precision
> helper functions in hard-float mode if only single-precision
> arithmetic is supported in hardware.
Ok, though I'd add a bit more explanation to the co
24 matches
Mail list logo
