'alignas' and '__declspec(align)' are not allowed on function declarations

RESOLVED FIXED in Firefox 40

Status

()

RESOLVED FIXED
4 years ago
3 years ago

People

(Reporter: c, Assigned: briansmith)

Tracking

Trunk
mozilla40
x86_64
Windows 8.1
Points:
---

Firefox Tracking Flags

(firefox40 fixed)

Details

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0
Build ID: 20150117134242

Steps to reproduce:

vc2015 ctp5
run into errors like
libyuv/source/rotate.cc(81): error C3323: 'alignas' and '__declspec(align)' are not allowed on function declarations
(Reporter)

Updated

4 years ago
Blocks: 1119082
(Reporter)

Comment 1

4 years ago
64bit builds don't have the issue.
Assignee: nobody → brian
Status: UNCONFIRMED → ASSIGNED
Component: Build Config → WebRTC: Audio/Video
Ever confirmed: true
Target Milestone: --- → mozilla40
Created attachment 8587161 [details] [diff] [review]
remove-decltype-libyuv.patch

MSVC 2015 CTP 6 refuses to compile the code with these, and MSVC already aligns functions at 16 byte boundaries in its normal configuration, AFAICT.
Attachment #8587161 - Flags: review?(padenot)
Comment on attachment 8587161 [details] [diff] [review]
remove-decltype-libyuv.patch

302 jesup, who is in vacation for now.
Attachment #8587161 - Flags: review?(padenot) → review?(rjesup)
Is this fixed in upstream?  Does declspec(aligned(16)) have any impact on versions before MSVC2015?  Since this is an upstream bug, we should attempt to align with whatever compiler targets libyuv is supposed to handle (or we need/want to handle) (with ifdefs or #defines if needed), and then put the patch up to upstream as well.

Thanks
Flags: needinfo?(brian)
Who normally works on libyuv for Mozilla? Who normally deals with pulling/pushing changes from/to upstream? I'd like to talk to get some help from those people to understand the best way of fixing this.
Flags: needinfo?(brian) → needinfo?(rjesup)
(In reply to Brian Smith (:briansmith, :bsmith, use NEEDINFO?) from comment #5)
> Who normally works on libyuv for Mozilla? Who normally deals with
> pulling/pushing changes from/to upstream? I'd like to talk to get some help
> from those people to understand the best way of fixing this.

I'm the only one who works on it; in fact I just landed a fix to re-enable MJPEG (and disable jpeg-turbo warnings to stderr is about to land).  I pulled the latest version specifically to get win64 SSE improvements (it was 1/10 as fast as Linux64).

Basically, I'd like to be able to take our patch and push it to their codereview site.
Flags: needinfo?(rjesup)
> I'm the only one who works on it; in fact I just landed a fix to re-enable
> MJPEG (and disable jpeg-turbo warnings to stderr is about to land).  I
> pulled the latest version specifically to get win64 SSE improvements (it was
> 1/10 as fast as Linux64).

To clarify, I pulled a copy of it to evaluate updating our pull to match the current tip.
Looks like Chromium also ran into the same problem. There's no an issue in libyuv's issue tracker.

Updated

3 years ago
Attachment #8587161 - Flags: review?(rjesup) → review+
https://hg.mozilla.org/mozilla-central/rev/8190c13db420
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
status-firefox40: --- → fixed
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.