Closed Bug 914523 Opened 11 years ago Closed 10 years ago

Please install Visual Studio 2013 on a Builder

Categories

(Release Engineering :: General, defect)

x86
macOS
defect
Not set
normal

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.
FYI, 2013RC cause ICE when building jsdtoa.obj with -O1 or -O2
https://connect.microsoft.com/VisualStudio/feedback/details/800094/
(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...
Blocks: VC12
Actually, let's first try to bring up the builds locally before we do this on our builders, I guess...
(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.
Using #pragma optimize("", off) and  #pragma optimize("", on) can make the build continue.
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
(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?
Component: Buildduty → Build Config
Product: Release Engineering → Core
QA Contact: armenzg
Moved to Build Config as per comment 3.
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
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
OK, we're now ready to start testing Visual Studio 2013 on our infra.  Reopening this bug.
Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---
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
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.
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.
Blocks: 669384
(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.
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).
Ted: that's correct, VS2012 was not being used for anything yet.
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)
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)
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
Depends on: 991330
Depends on: 1009807
We're now able to push try builds that use VS2013. Can we resolve this?
The crickets say yes. Reopen if I've missed something!
Status: REOPENED → RESOLVED
Closed: 11 years ago10 years ago
Resolution: --- → FIXED
Component: General Automation → General
You need to log in before you can comment on or make changes to this bug.