Produces NEON code on armhf even when explicitly asked not to

Bug #937864 reported by Steve McIntyre
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Linaro GCC
Won't Fix
Undecided
Michael Collison
gcc-4.6 (Debian)
Fix Released
Unknown
gcc-4.6 (Ubuntu)
Incomplete
Undecided
Unassigned

Bug Description

As referenced in Debian bug #657157:

Looking at a FTBFS bug on armhf in the pytables package. gcc-4.6 seems
to be emitting NEON code even when explicitly told not to:

(sid)93sam@harris:~$ gcc -c typeconv.c -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -mthumb -o typeconv.o
(sid)93sam@harris:~$ objdump -D typeconv.o | grep vldr
  a8: ed93 6b00 vldr d6, [r3]
  ae: ed93 7b00 vldr d7, [r3]
  be: ed9f 7b44 vldr d7, [pc, #272] ; 1d0 <conv_float64_timeval32+0x1d0>
 118: ed9f 7b2f vldr d7, [pc, #188] ; 1d8 <conv_float64_timeval32+0x1d8>

There's other NEON code in the assembly output too, the grep is just
to show an example...

The single small source file is attached.

Revision history for this message
Steve McIntyre (steve-mcintyre) wrote :
Revision history for this message
Ulrich Weigand (uweigand) wrote :

Maybe I'm missing something, but as I understand those *are* valid VFPv3 (even VFPv2) instructions, not just NEON instructions ...

Changed in gcc-4.6 (Debian):
status: Unknown → New
Revision history for this message
Steve McIntyre (steve-mcintyre) wrote : Re: [Bug 937864] Re: Produces NEON code on armhf even when explicitly asked not to

On Tue, Feb 21, 2012 at 03:52:29PM -0000, Ulrich Weigand wrote:
>Maybe I'm missing something, but as I understand those *are* valid VFPv3
>(even VFPv2) instructions, not just NEON instructions ...

Oh, hmmm...

Maybe I'm being too quick to complain for *these* specific
instructions. This came out of a discussion on #debian-arm a few weeks
back, related to the build failure referenced in

  https://buildd.debian.org/status/fetch.php?pkg=pytables&arch=armhf&ver=2.3.1-1&stamp=1327297899

Oh, hmmm. Looking at the irc log for that discussion, the user in
question is pointing at another instruction instead:

2012-01-23 22:14 GMT< yoh> Program received signal SIGILL, Illegal instruction.
2012-01-23 22:14 GMT< yoh> conv_float64_timeval32 (base=<optimized out>, byteoffset=<optimized out>, bytestride=<optimized out>, nrecords=49932, nelements=2, sense=0) at src/typeconv.c:72
2012-01-23 22:14 GMT< yoh> 72 | (lround((*fieldbase - (int)(*fieldbase)) * 1e+6)
2012-01-23 22:16 GMT< yoh> I think that is the one /home/yoh/pytables/build/temp.linux-armv7l-2.6/src/typeconv.o
2012-01-23 22:17 GMT< yoh> disassemble gives => 0x2bc6950a <+170>: vcvt.s32.f64 s14, d8

I was too quick at jumping on vldr without thinking about VFPv3.

Cheers,
--
Steve McIntyre <email address hidden>
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs

Revision history for this message
Ramana Radhakrishnan (ramana) wrote :

On 21 February 2012 16:25, Steve McIntyre <email address hidden> wrote:
> On Tue, Feb 21, 2012 at 03:52:29PM -0000, Ulrich Weigand wrote:
>>Maybe I'm missing something, but as I understand those *are* valid VFPv3
>>(even VFPv2) instructions, not just NEON instructions ...
>
> Oh, hmmm...
>
> Maybe I'm being too quick to complain for *these* specific
> instructions. This came out of a discussion on #debian-arm a few weeks
> back, related to the build failure referenced in
>
> https://buildd.debian.org/status/fetch.php?pkg=pytables&arch=armhf&ver=2.3.1-1&stamp=1327297899
>
> Oh, hmmm. Looking at the irc log for that discussion, the user in
> question is pointing at another instruction instead:
>
> 2012-01-23 22:14 GMT< yoh> Program received signal SIGILL, Illegal instruction.
> 2012-01-23 22:14 GMT< yoh> conv_float64_timeval32 (base=<optimized out>, byteoffset=<optimized out>, bytestride=<optimized out>, nrecords=49932, nelements=2, sense=0) at src/typeconv.c:72
> 2012-01-23 22:14 GMT< yoh> 72                        | (lround((*fieldbase - (int)(*fieldbase)) * 1e+6)
> 2012-01-23 22:16 GMT< yoh> I think that is the one /home/yoh/pytables/build/temp.linux-armv7l-2.6/src/typeconv.o
> 2012-01-23 22:17 GMT< yoh> disassemble gives => 0x2bc6950a <+170>:   vcvt.s32.f64    s14, d8

That again doesn't indicate an illegal instruction to me - it's a
truncation from a double precision value into a signed 32 bit integer.
D8 is a valid register to use - ( it's d0-d15 in vfpv3-d16 mode which
is what I think the Debian compilers default to) that is valid. So
clearly needs some more investigation in this area . Remember that the
disassembler shows instructions in unified syntax for both VFP and
Neon instructions.

Ramana

Revision history for this message
Ramana Radhakrishnan (ramana) wrote :

Looking at the disassembly it wasn't obvious to me what was wrong. Can someone debug and find out what is going wrong here ? The instructions generated are valid for vfpv3-d16 unless I've missed something while looking at this -

Is there a problem with an unaligned memory address or something for a vstr or a vldr ? These will trap with alignment exceptions but the program shouldn't crash because of a SIGILL ?

Ramana

Changed in gcc-linaro:
status: New → Incomplete
Changed in gcc-4.6 (Debian):
status: New → Fix Released
Matthias Klose (doko)
Changed in gcc-4.6 (Ubuntu):
status: New → Incomplete
Revision history for this message
Michael Collison (michael-collison) wrote :

Neon code is not produced by linaro 4.7, 4.8 or 4.9 for the provided test case.

Changed in gcc-linaro:
assignee: nobody → Michael Collison (michael-collison)
status: Incomplete → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.