Bug#1014091: armhf: gcc has wrong configuration
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 double-precision registers. +vfpv3-fp16 would add support for the float16 load/store operations, while +nosimd is a nop because no other options have been added to enable SIMD. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Re: ARM32 configury changes, with no FPU as a default
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 should be configured with --with-arch=armv7-a+fp The --with-fpu configure option is deprecated. The problem with this approach is that there is no default for the fpu setting, while old compilers silently pick up the -mfpu from the configured compiler. FWIW, Fedora uses: --with-tune=generic-armv7-a --with-arch=armv7-a \ --with-float=hard --with-fpu=vfpv3-d16 --with-abi=aapcs-linux \ Not sure how it is impacted by this change. This breaks software which explicitly configures things like -march=armv7-a, or where the architecture string is embedded in the source as an attribute. So going from one place in the compiler about configuring the ABI for a distro arch, this config now moves to some dozen places in different packages. Not the thing I would expect. I don't know if we have seen such problems in Fedora. I don't remember any reports. That's still using the now-deprecated --with-fpu option. I want to remove that from GCC eventually in favour of the new way of adding the FP configuration as part of the architecture. Recent versions of the Arm architecture do not document separate FPU versions, but just add features to the main architecture, so we need to move away from the old approach. R. Thanks, Florian
Re: 3.3.4 status, and some questions
> > 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, but that this > particular testcase doesn't tweak the bug because of some other difference > between Debian's gcc and ours? That seems to be the case. R.
Re: 3.3.4 status, and some questions
> On Fri, 2004-03-12 at 06:38, Matthias Klose wrote: > > > - Is 14302 the bug that caused XFree86 4.3 builds to fail on Debian ARM? > > > > CCed Phil Blundell > > No. The XFree86 problem was also in GO_IF_LEGITIMATE_ADDRESS, but this > was a different bug. I don't think we had a PR filed for the XFree86 > thing. > > p. > > 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. In fact, the patch for that bug hasn't been installed on the 3.3 branch yet. It 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 offset is -4095...+4095 inclusive. Phil, were you going to commit the back-port you had done? R.
Re: c/7873: arm-linux-gcc fails when assigning address to a bit field
> 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 > > bit-field? That sounds like it is highly non-portable. > > I think Matthias is actually talking about a different bug. The Python > 2.3 build failure was caused by the problem with conditional returns > having the wrong length attribute. > > p. > Then why did he quote the pointer-in-bitfield patch? R.
Re: c/7873: arm-linux-gcc fails when assigning address to a bit field
> 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.
Re: c/7873: arm-linux-gcc fails when assigning address to a bit field
> >How-To-Repeat:
>
> /** Run "arm-linux-gcc -c" on this preprocessed segment : **/
>
>
> unsigned int x0 = 0;
>
> typedef struct {
> unsigned int field1 : 20;
> unsigned int field2 : 12;
> } XX;
>
> static XX yy;
>
> static 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
===
RCS file: /cvs/gcc/gcc/gcc/config/arm/arm.md,v
retrieving revision 1.104
diff -p -r1.104 arm.md
*** arm.md 29 Jul 2002 12:41:46 - 1.104
--- arm.md 10 Sep 2002 09:44:07 -
***
*** 1866,1872
[(set (zero_extract:SI (match_operand:SI 0 "s_register_operand" "")
(match_operand:SI 1 "general_operand" "")
(match_operand:SI 2 "general_operand" ""))
! (match_operand:SI 3 "nonmemory_operand" ""))]
"TARGET_ARM"
"
{
--- 1866,1872
[(set (zero_extract:SI (match_operand:SI 0 "s_register_operand" "")
(match_operand:SI 1 "general_operand" "")
(match_operand:SI 2 "general_operand" ""))
! (match_operand:SI 3 "reg_or_int_operand" ""))]
"TARGET_ARM"
"
{
