Visual Studio 2012 cl.exe ICE while building LLVM for x64 (in TableGen) at -O2

Project Infrastructure LLVM Dev List Archives
#1

As an update to this:
http://connect.microsoft.com/VisualStudio/feedback/details/769222/cl-exe-ice-when-building-llvm-trunk-at-o2

Microsoft has reproduced the ICE, given a workaround, and is planning a fix for a future MSVC release. I know not a lot of people are building with VS, but it's nice to know. The workaround involves marking a single function with attribute((noinline)) and is detailed on the page, so nothing too horrible there.

Cheers,
Gordon Keiser
Software Development Engineer
Arxan Technologies

#2

As an update to this:
http://connect.microsoft.com/VisualStudio/feedback/details/769222/cl-exe-ice-when-building-llvm-trunk-at-o2

Microsoft has reproduced the ICE, given a workaround, and is planning a fix for a future MSVC release. I know not a lot of people are building with VS, but it's nice to know. The workaround involves marking a single function with attribute((noinline)) and is detailed on the page, so nothing too horrible there.

I'm guessing this was specific to the arm backend. As quite a few
people are building with MSVC daily.

It would be nice if MSVC defaulted to all targets instead of just x86
so we get more coverage on this type of stuff.

- Michael Spencer

#3

No, it happens targeting x64, and maybe x86 as well.

     Nick C.

#4

On Behalf Of Nicholas Chapman

>> As an update to this:
>> http://connect.microsoft.com/VisualStudio/feedback/details/769222/cl-
>> exe-ice-when-building-llvm-trunk-at-o2
>>
>> Microsoft has reproduced the ICE, given a workaround, and is planning a
fix for a future MSVC release. I know not a lot of people are building with
VS, but it's nice to know. The workaround involves marking a single function
with attribute((noinline)) and is detailed on the page, so nothing too horrible
there.
> I'm guessing this was specific to the arm backend. As quite a few
> people are building with MSVC daily.
>
>
No, it happens targeting x64, and maybe x86 as well.

     Nick C.

Right, it's specific to Visual Studio 2012, the crash happens in two tablegen files when inlining utostr. I've not run into it building with 2010 or 2008. It's rather odd that utostr_32 doesn't cause the same issue since they share nearly identical code.

Gordon Keiser
Software Development Engineer
Arxan Technologies
Protecting the App EconomyT

#5

I have reproduced one also on VS10 x64|RelWithDebInfo.

I suggest simply tweak usage.

--- a/llvm/lib/TableGen/TGParser.cpp
+++ b/llvm/lib/TableGen/TGParser.cpp
@@ -379,7 +379,8 @@ static bool isObjectStart(tgtok::TokKind K) {

static std::string GetNewAnonymousName() {
   static unsigned AnonCounter = 0;
- return "anonymous."+utostr(AnonCounter++);
+ unsigned n = AnonCounter++;
+ return "anonymous."+utostr(n);
}

/// ParseObjectName - If an object name is specified, return it. Otherwise,
diff --git a/llvm/utils/TableGen/CodeGenRegisters.cpp
b/llvm/utils/TableGen/CodeGenRegisters.cpp
index 20d439f..20933bf 100644
--- a/llvm/utils/TableGen/CodeGenRegisters.cpp
+++ b/llvm/utils/TableGen/CodeGenRegisters.cpp
@@ -701,7 +701,8 @@
CodeGenRegisterClass::CodeGenRegisterClass(CodeGenRegBank &RegBank,
Record *R)
   // Rename anonymous register classes.
   if (R->getName().size() > 9 && R->getName()[9] == '.') {
     static unsigned AnonCounter = 0;
- R->setName("AnonRegClass_"+utostr(AnonCounter++));
+ R->setName("AnonRegClass_"+utostr(AnonCounter));
+ ++AnonCounter;
   }

   std::vector<Record*> TypeList = R->getValueAsListOfDefs("RegTypes");

FYI, utosotr(++AnonCounter) could be accepted if 0-origination were
not important.

...Takumi

#6

Reviving the ancient post, but MS has fixed the ICE in VS2012 Update 2 :

Under C++ Fixes:
  * An internal compiler error occurs when you buiuld[sic] an LLVM-based project by using an x64-based compiler.

I haven't verified personally yet but since they had a full repro I'm going to trust them on that one... :slight_smile:

Cheers,
Gordon Keiser
Software Development Engineer
Arxan Technologies
gkeiser@arxan.com www.arxan.com
Protecting the App Economy(tm)