New issue
Advanced search Search tips

Issue 810443 link

Starred by 3 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 3
Type: Bug



Sign in to add a comment

ffmpeg_internal failing to build on arm with arm_version=8

Reported by claudiom...@gmail.com, Feb 8 2018

Issue description

I'm not sure when this started, but I usually build the code for arm version 8. Now the build is broken.

gn gen out/Default "is_official_build=true target_cpu=\"arm\" arm_version=8"
ninja -C out/Default ffmpeg_internal

The build will be broken with the following errors

In file included from ../../third_party/ffmpeg/libavcodec/autorename_libavcodec_flacdsp.c:2:
In file included from ../../third_party/ffmpeg/libavcodec/flacdsp.c:22:
In file included from ../../third_party/ffmpeg/libavutil/samplefmt.h:24:
In file included from ../../third_party/ffmpeg/libavutil/avutil.h:296:
In file included from ../../third_party/ffmpeg/libavutil/common.h:106:
In file included from ../../third_party/ffmpeg/libavutil/intmath.h:30:
../../third_party/ffmpeg/libavutil/arm/intmath.h:121:47: error: applying IT instruction to more than one subsequent instruction is deprecated [-Werror,-Winline-asm]
    __asm__ ("adds   %1, %R2, %Q2, lsr #31  \n\t"
                                              ^
<inline asm>:2:2: note: instantiated into assembly here
        itet   ne                     
        ^
In file included from ../../third_party/ffmpeg/libavcodec/autorename_libavcodec_flacdsp.c:2:
In file included from ../../third_party/ffmpeg/libavcodec/flacdsp.c:22:
In file included from ../../third_party/ffmpeg/libavutil/samplefmt.h:24:
In file included from ../../third_party/ffmpeg/libavutil/avutil.h:296:
In file included from ../../third_party/ffmpeg/libavutil/common.h:106:
In file included from ../../third_party/ffmpeg/libavutil/intmath.h:30:
../../third_party/ffmpeg/libavutil/arm/intmath.h:122:47: error: deprecated instruction in IT block [-Werror,-Winline-asm]
             "itet   ne                     \n\t"
                                              ^
<inline asm>:3:2: note: instantiated into assembly here
        mvnne  r2, #1<<31             
        ^

I'm fairly sure I had done a build before with version 8, and this issue is fairly new.

Cheers.
 
Components: Blink>Media
Components: -Blink>Media Internals>Media>FFmpeg
Status: Untriaged (was: Unconfirmed)
I have no idea what this means, so probably we can just suppress? :) Seems there's more discussion on  issue 686903 .
"error: deprecated instruction in IT block" probably wants us to use a newer instruction on arm 8.
I wouldn’t mind to fix the instructions myself to support armv8, but advice would appreciated 
So, any updates on this... I followed the discussion with the engineer from Arm, and apparently he submitted a patch to FFmpeg with the new instructions that was rejected because the new arm instruction provide no benefit over the C macro they used to have, so they would rather revert to the C macro for armv8. After that reply, the ARM engineers seems to have abandoned the patch.

Does anyone know how we to proceed in this case?

Comment 8 by thakis@chromium.org, Feb 12 2018

The ARM folks probably added this compiler error. So the ways forward are:

- the ffmpeg folks have to convince the ARM folks who added the error to remove it again
- the ffmpeg folks accept the patch since it makes a warning go away
- if neither of those happen, we have to build ffmpeg with this warning disabled
Thanks for the reply. This has been an issue for more than a year though, according to  crbug.com/686903 , so it does look like both sides have given up on it. Not sure what is the average timeframe to get these things fixed.
Owner: thakis@chromium.org
Status: Assigned (was: Untriaged)
give to thakis@ as per c#8, can you follow up with ARM folks or resolve this bug appropriately?
Cc: thakis@chromium.org
Owner: wolenetz@chromium.org
I don't think this needed to be assigned, but over to current ffmpeg owner.
@#8-11, some questions:

if we built ffmpeg with this warning disabled: under which conditions and which warning would need disabling? Would that introduce other regression vectors such that we shouldn't go this route?

I suppose I could also ping ffmpeg if I knew the precise patch that's been stalled here, to see if they can assist getting to a resolution on this. What is that patch identity?

Is this correctly P3 (and not higher priority)?

By default, I'll probably not act on this during this M67 roll period unless its priority is indeed higher; it'll likely fall through either to next ffmpeg roll owner or back to thakis@.
I also asked for an update from (I think) the ARM folks at https://bugs.chromium.org/p/chromium/issues/detail?id=686903#c57 just now.
Cc: wolenetz@chromium.org
Owner: liber...@chromium.org
Over to current ffmpeg roller (M68), caveat #11.

Sign in to add a comment