Closed
Bug 914523
Opened 11 years ago
Closed 10 years ago
Please install Visual Studio 2013 on a Builder
Categories
(Release Engineering :: General, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: ehsan.akhgari, Unassigned)
References
Details
Apparently Visual Studio 2013 RC introduces a 64-bit cross compiling toolchain for building x86 programs. This may enable us to fix the PGO problem by using the 64-bit compiler. We need to set this up on a build machine and start investigating our builds and tests to see if we can ship Firefox with this compiler when the final version is available.
Comment 1•11 years ago
|
||
FYI, 2013RC cause ICE when building jsdtoa.obj with -O1 or -O2 https://connect.microsoft.com/VisualStudio/feedback/details/800094/
Reporter | ||
Comment 2•11 years ago
|
||
(In reply to comment #1) > FYI, 2013RC cause ICE when building jsdtoa.obj with -O1 or -O2 > https://connect.microsoft.com/VisualStudio/feedback/details/800094/ Is that the only build issue? Is there a bug on file for that? I can probably bring this up with my Microsoft contact if it's something which we can't easily work around by marking a function as not-optimized...
Reporter | ||
Comment 3•11 years ago
|
||
Actually, let's first try to bring up the builds locally before we do this on our builders, I guess...
Comment 4•11 years ago
|
||
(In reply to :Ehsan Akhgari (needinfo? me!) from comment #2) > (In reply to comment #1) > > FYI, 2013RC cause ICE when building jsdtoa.obj with -O1 or -O2 > > https://connect.microsoft.com/VisualStudio/feedback/details/800094/ > > Is that the only build issue? Is there a bug on file for that? I can > probably bring this up with my Microsoft contact if it's something which we > can't easily work around by marking a function as not-optimized... Yes. If using --enable-optimize, we cannot build js modules due to this bug. They say "We will fix it in a future release." via connect, but I don't know whether this is fixed by RTM version. If we have a premier support contract, they can provide the hotfix even if this isn't fixed until RTM version and they can answer whether this is fixed by RTM version.
Comment 5•11 years ago
|
||
Using #pragma optimize("", off) and #pragma optimize("", on) can make the build continue.
Comment 6•11 years ago
|
||
another problem is in ctype. the amd_x86 cross compiler has problem, though the native one is fine. cl -nologo -EP -I. -Id:/develop/mozilla/central/js/src/ctypes/libffi -I. -Id:/d evelop/mozilla/central/js/src/ctypes/libffi/include -Iinclude -Id:/develop/mozil la/central/js/src/ctypes/libffi/src -I. -Id:/develop/mozilla/central/js/src/ctyp es/libffi/include -Iinclude -Id:/develop/mozilla/central/js/src/ctypes/libffi/sr c -DHAVE_CONFIG_H d:/develop/mozilla/central/js/src/ctypes/libffi/src/x86/win32 .S > src/x86/win32.asm win32.S ml -nologo -safeseh -c -Fosrc/x86/win32.obj src/x86/win32.asm Assembling: src/x86/win32.asm MASM : fatal error A1016: Internal error Version 12.00.20824.1 ExceptionCode = C0000005 ExceptionFlags = 00000000 ExceptionAddress = 00007FF79414F407 (00007FF794130000) "c:\Program Fil es (x86)\Microsoft Visual Studio 12.0\VC\BIN\amd64_x86\ml.exe" NumberParameters = 00000002 ExceptionInformation[ 0] = 0000000000000000 ExceptionInformation[ 1] = FFFFFFFFFFFFFFFF CONTEXT: Rax = 0000000000000000 R8 = 0000000000000000 Rbx = 0000002F81D6C2D8 R9 = 000000000000002D Rcx = 0000002F81D6C300 R10 = 00007FF98B8A72A0 Rdx = 0000000000000000 R11 = 0000002F81D6BF90 Rsp = 0000002F81B7EAF0 R12 = 0000000000000000 Rbp = 0000000000000007 E13 = 0000000000000000 Rsi = 0000000000000000 R14 = 00007FF7941A55AE Rdi = 414C460400000000 R15 = 00007FF794130000 Rip = 00007FF79414F407 EFlags = 0000000000010206 SegCs = 0000000000000033 SegDs = 000000000000002B SegSs = 000000000000002B SegEs = 000000000000002B SegFs = 0000000000000053 SegGs = 000000000000002B Dr0 = 0000000000000000 Dr3 = 0000000000000000 Dr1 = 0000000000000000 Dr6 = 0000000000000000 Dr2 = 0000000000000000 Dr7 = 0000000000000000
Comment 7•11 years ago
|
||
(In reply to zhoubcfan from comment #6) > another problem is in ctype. the amd_x86 cross compiler has problem, though > the native one is fine. > > > cl -nologo -EP -I. -Id:/develop/mozilla/central/js/src/ctypes/libffi -I. > -Id:/d > evelop/mozilla/central/js/src/ctypes/libffi/include -Iinclude > -Id:/develop/mozil > la/central/js/src/ctypes/libffi/src -I. > -Id:/develop/mozilla/central/js/src/ctyp > es/libffi/include -Iinclude > -Id:/develop/mozilla/central/js/src/ctypes/libffi/sr > c -DHAVE_CONFIG_H > d:/develop/mozilla/central/js/src/ctypes/libffi/src/x86/win32 > .S > src/x86/win32.asm > win32.S > ml -nologo -safeseh -c -Fosrc/x86/win32.obj src/x86/win32.asm > Assembling: src/x86/win32.asm > > MASM : fatal error A1016: Internal error > > Version 12.00.20824.1 > > ExceptionCode = C0000005 > ExceptionFlags = 00000000 > ExceptionAddress = 00007FF79414F407 (00007FF794130000) "c:\Program > Fil > es (x86)\Microsoft Visual Studio 12.0\VC\BIN\amd64_x86\ml.exe" > NumberParameters = 00000002 > ExceptionInformation[ 0] = 0000000000000000 > ExceptionInformation[ 1] = FFFFFFFFFFFFFFFF > > CONTEXT: > Rax = 0000000000000000 R8 = 0000000000000000 > Rbx = 0000002F81D6C2D8 R9 = 000000000000002D > Rcx = 0000002F81D6C300 R10 = 00007FF98B8A72A0 > Rdx = 0000000000000000 R11 = 0000002F81D6BF90 > Rsp = 0000002F81B7EAF0 R12 = 0000000000000000 > Rbp = 0000000000000007 E13 = 0000000000000000 > Rsi = 0000000000000000 R14 = 00007FF7941A55AE > Rdi = 414C460400000000 R15 = 00007FF794130000 > Rip = 00007FF79414F407 EFlags = 0000000000010206 > SegCs = 0000000000000033 SegDs = 000000000000002B > SegSs = 000000000000002B SegEs = 000000000000002B > SegFs = 0000000000000053 SegGs = 000000000000002B > Dr0 = 0000000000000000 Dr3 = 0000000000000000 > Dr1 = 0000000000000000 Dr6 = 0000000000000000 > Dr2 = 0000000000000000 Dr7 = 0000000000000000 could you file a bug to connect.microsoft.com?
Comment 8•11 years ago
|
||
I file as ml.exe issue as https://connect.microsoft.com/VisualStudio/feedback/details/800216/. Thanks, zhoubcfan.
Updated•11 years ago
|
Component: Buildduty → Build Config
Product: Release Engineering → Core
QA Contact: armenzg
Reporter | ||
Comment 10•11 years ago
|
||
This is still a releng bug, it's just that we don't need it right now. I'll reopen once we do.
Status: NEW → RESOLVED
Closed: 11 years ago
Component: Build Config → General Automation
Product: Core → Release Engineering
QA Contact: catlee
Resolution: --- → INCOMPLETE
Comment 11•11 years ago
|
||
I pulled out the compiler discussions into separate bugs so we can keep them active: Bug 920740: MASM crash in ctypes with VS2013 amd64_x86 cross-compile Bug 920751: VS2013 internal compiler error in dtoa.c and prdtoa.c
Reporter | ||
Comment 12•10 years ago
|
||
OK, we're now ready to start testing Visual Studio 2013 on our infra. Reopening this bug.
Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---
Comment 13•10 years ago
|
||
For our testing we should install VS2013 Update 2 CTP2 or newer, as it contains some key bug fixes in the compiler and linker.
Summary: Please install Visual Studio 2013 RC on a Builder → Please install Visual Studio 2013 on a Builder
Comment 14•10 years ago
|
||
We already have a staging install of VS2012 configured via group policy (see bug 946859, bug 960561). It was created to address bug 669384. If you are happy to take VS2012 instead of VS2013 we can get that set up for you much sooner. Otherwise we can look into skipping VS2012 and going straight to VS2013.
I think we should just skip to 2013.
Comment 16•10 years ago
|
||
We should skip 2012 and go straight to 2013 update 2. We know 2012 won't solve the big problem we want to solve and 2013 appears to.
Reporter | ||
Comment 17•10 years ago
|
||
(In reply to comment #14) > We already have a staging install of VS2012 configured via group policy (see > bug 946859, bug 960561). > It was created to address bug 669384. > > If you are happy to take VS2012 instead of VS2013 we can get that set up for > you much sooner. > Otherwise we can look into skipping VS2012 and going straight to VS2013. Do you know what the 2012 installation is used for besides the Win64 work? We should move other consumers of that compiler to 2013 CTP2 as well.
Comment 18•10 years ago
|
||
I don't think it was being used by anything yet, it was just being installed to try to get Win64 builds working more usefully (bug 669384, as noted).
Comment 19•10 years ago
|
||
Ted: that's correct, VS2012 was not being used for anything yet.
Comment 20•10 years ago
|
||
What work remains here? I see that the GPO bug has been resolved, but I'm not sure what that means for this bug.
Flags: needinfo?(jhopkins)
Comment 21•10 years ago
|
||
Now that we have a recipe to install VS2013 on a machine using group policy objects (GPO). It would be good if someone verified: a) that the installation of VS2013 works as expected b) that the existing VS2010 install still works properly, since we'll need both toolchains to coexist on a finite set of physical hardware machines. We would like to avoid having to do another prolonged staged rollout of machines like with win64-rev2 (which took months) if at all possible. We can create loaner machines for someone to work on this - just file a loan request.
Flags: needinfo?(jhopkins)
Comment 22•10 years ago
|
||
Once we have some confidence in the toolchain install, we can do: - staging nightly builds - run through nightly tests - have QA do some inspection on the resulting builds
Comment 23•10 years ago
|
||
We're now able to push try builds that use VS2013. Can we resolve this?
Comment 24•10 years ago
|
||
The crickets say yes. Reopen if I've missed something!
Status: REOPENED → RESOLVED
Closed: 11 years ago → 10 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•6 years ago
|
Component: General Automation → General
You need to log in
before you can comment on or make changes to this bug.
Description
•