Closed Bug 922441 Opened 10 years ago Closed 9 years ago

VS2013: Internal compiler error during PGO on amd64_x86 cross-compile

Categories

(Core :: General, defect)

Product:
Core
Component:
General
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: away, Unassigned)

References

Details

I've hacked around bug 919735 by substituting the right dll. Now I get a fatal error in the build during the PGUPDATE phase.

Generating code
d:\src\central\gfx\gl\TextureGarbageBin.cpp : fatal error C1001: An internal error has occurred in the compiler.
(compiler file 'f:\dd\vctools\compiler\utc\src\p2\main.c', line 227)
 To work around this problem, try simplifying or changing the program near the locations listed above.
Please choose the Technical Support command on the Visual C++
 Help menu, or open the Technical Support help file for more information
d:\src\central\gfx\gl\TextureGarbageBin.cpp : fatal error C1001: An internal error has occurred in the compiler.
(compiler file 'f:\dd\vctools\compiler\utc\src\p2\main.c', line 227)
 To work around this problem, try simplifying or changing the program near the locations listed above.
Please choose the Technical Support command on the Visual C++
 Help menu, or open the Technical Support help file for more information

LINK : fatal error LNK1000: Internal error during IMAGE::BuildImage

  Version 12.00.20827.3

  ExceptionCode            = C0000005
  ExceptionFlags           = 00000000
  ExceptionAddress         = 000007FEE9F2CA74 (000007FEE9C20000) "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\BIN\amd64_x86\c2.dll"
  NumberParameters         = 00000002
  ExceptionInformation[ 0] = 0000000000000000
  ExceptionInformation[ 1] = 0000000169963B58

CONTEXT:
  Rax    = 0000000169963B58  R8     = 0000000000000000
  Rbx    = 0000000000000048  R9     = 00000000EA742930
  Rcx    = 000000004E476810  R10    = 00000000ED5A9C08
  Rdx    = 000000004E476810  R11    = 000000004E476810
  Rsp    = 000000000015E010  R12    = 0000000000000000
  Rbp    = 0000000002958C50  E13    = 0000000000000100
  Rsi    = 0000000000000001  R14    = 0000000000000010
  Rdi    = 0000000000000009  R15    = 000000002FA6EA00
  Rip    = 000007FEE9F2CA74  EFlags = 0000000000010202
  SegCs  = 0000000000000033  SegDs  = 000000000000002B
  SegSs  = 000000000000002B  SegEs  = 000000000000002B
  SegFs  = 0000000000000053  SegGs  = 000000000000002B
  Dr0    = 0000000000000000  Dr3    = 0000000000000000
  Dr1    = 0000000000000000  Dr6    = 0000000000000000
  Dr2    = 0000000000000000  Dr7    = 0000000000000000


I filed https://connect.microsoft.com/VisualStudio/feedback/details/804006/fatal-error-c1001-lnk1000-during-vs2013rc-pgo-amd64-x86-build
Didn't reproduce with VS 2003 RTM.
I still can reproduce this.
Sorry, I overlooked "during PGO".
When Max virtual memory is over 4GB, this occurs even if VS2013...  Check "TinderboxPrint: linker max vsize".
(In reply to comment #4)
> When Max virtual memory is over 4GB, this occurs even if VS2013...  Check
> "TinderboxPrint: linker max vsize".

Hmm, isn't the toolchain 64-bit?  I can't understand why this should be a problem, unless we're somehow building with the wrong toolchain.
It's the right tools. On Task Manager and Resource Monitor, I can see the linker exceed 4GB but not by too much, maybe like 4.5GB. (By the way, the Windows API used by the vsize tool has a 32-bit parameter, so it just maxes out and we can't distinguish between slightly-over-4GB and way-over-4GB)

Nonetheless, I suspect (but can't prove) that there are still some internal 32 bit-limits in some parts the code. I suspect this because disabling optimization on the failing file doesn't change anything (normally that kind of thing helps if it's like a logic bug).
Sadface.  :(
Blocks: 919735
I received an automated email from Microsoft saying my bug report was marked as duplicate, but it didn't say what the duplicate was (the primary bug might be in a non-public database) or give any indication when/whether there would be a fix.
I got a successful build. the linker-vsize is 4294967295.
I forgot to mention that I was using vs2013 update 2 ctp.
Same here, works with VS2013 update 2 CTP 2.

And it still works if I add more files to PGO by disregarding the opt-in at https://hg.mozilla.org/mozilla-central/file/4cfb6c61b137/config/config.mk#l375

And it still works if I do the above plus add gkmedias using the patch at bug 922912 comment 11.

(The linker vsize output can be misleading since that variable maxes out at 4GB. On my machine the actual linker memory went above 5GB.)
(In reply to comment #11)
> Same here, works with VS2013 update 2 CTP 2.
> 
> And it still works if I add more files to PGO by disregarding the opt-in at
> https://hg.mozilla.org/mozilla-central/file/4cfb6c61b137/config/config.mk#l375
> 
> And it still works if I do the above plus add gkmedias using the patch at bug
> 922912 comment 11.

This is great news!  David, do you have cycles to start looking into running tests on the build?  It would be great if we could move this forward.

> (The linker vsize output can be misleading since that variable maxes out at
> 4GB. On my machine the actual linker memory went above 5GB.)

Interesting to know, but we won't need to worry about linker memory usage for a very long time! :-)
(In reply to :Ehsan Akhgari (needinfo? me!) (slow responsiveness, emailapocalypse) from comment #12)
> This is great news!  David, do you have cycles to start looking into running
> tests on the build?  It would be great if we could move this forward.

Yeah, I'll try to run this through some tests on the side.
Resolving based on VS 2013 Update 2 CTP 2.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.