> 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 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
> > 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
> 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
> 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/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
> >
> 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
> > >+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)) +
> 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
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
> 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
> 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
> 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
> 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
> 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 (
> 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
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
.
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
>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
> 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
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_
> 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
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/
24 matches
Mail list logo
