I think the problem is valgrind's Makefiles are passing -mcpu=cortex-a8
to the compiler. Cortex-a8 has Neon and the compiler now makes use of that.
On the subject of the configuration of GCC
--with-arch=armv7-a+fp
*is* the correct configuration for the baseline GCC; it adds a vfpv3
with 16 dou
On 17/09/2021 11:23, Florian Weimer via Gcc wrote:
* Matthias Klose:
Starting with GCC 8, the configury allows to encode extra features into the
architecture string. Debian and Ubuntu's armhf (hard float) architecture is
configured with
--with-arch=armv7-a --with-fpu=vfpv3-d16
and now s
> > I don't think there is a PR for it since the code in question does not
> > provoke the bug on a vanilla FSF build.
>
> Now I'm confused. If the bug is not present in 3.3.3, then what is there
> to backport?
The bug is present, by inspection.
> Or are you saying that the bug is present, bu
needs a back-port of this change. However, it's not completely
trivial since the code in question was a macro in arm.h for 3.3 whereas
it's now a function in arm.c.
2004-02-25 Richard Earnshaw <[EMAIL PROTECTED]>
* arm.c (arm_legitimate_index_p): For QImode the range of an
> On Wed, 2002-09-25 at 10:05, Richard Earnshaw wrote:
> > > python2.3 now builds fine on arm-linux with this patch. It's not yet
> > > checked into the 3.2 branch.
> >
> > Why on earth would a real application want to put part of a pointer into a
> &g
> python2.3 now builds fine on arm-linux with this patch. It's not yet
> checked into the 3.2 branch.
Why on earth would a real application want to put part of a pointer into a
bit-field? That sounds like it is highly non-portable.
R.
c void foo (void)
> {
> yy.field1 = (unsigned int ) (&x0);
> }
Please try the following patch:
2002-09-10 Richard Earnshaw <[EMAIL PROTECTED]>
* arm.md (insv): Use reg_or_int_operand for operand[3].
Index: arm.md
7 matches
Mail list logo
