Compiling llvm 3.4 using g++-4.7 on ARM: lib/LTO/LTOCodeGenerator.cpp:166:1: internal compiler error: in merge_if_block, at ifcvt.c

Hello,

I've managed to track down some code which causes GCC to fail with an internal compiler error when compiling llvm/clang for ARM. I've included the diff for this one file inline.. hope that's ok.

==================================8<====================================
--- ../llvm/lib/LTO/LTOCodeGenerator.cpp.old 2014-07-30 08:33:30 +0000
+++ ../llvm/lib/LTO/LTOCodeGenerator.cpp 2014-07-30 08:39:03 +0000
@@ -150,6 +150,9 @@
case LTO_DEBUG_MODEL_DWARF:
EmitDwarfDebugInfo = true;
return;

Hi Cy,

Unfortunately this goes against the general coding standards for LLVM:
http://llvm.org/docs/CodingStandards.html#don-t-use-default-labels-in-fully-covered-switches-over-enumerations

but as a local workaround it seems fine.

I wonder if GCC 4.7 for ARM should be listed here:
http://llvm.org/docs/GettingStarted.html#check-here

  • Kim

Probably worth adding a comment to exlpain why it needs to be there.

Also, there's a reason that coding standard is in place - because we
get better error (warning ) messages that way. Is there a way to
workaround the bug without sacrificing future warning quality?

David,

Would you do the honors? I don’t have commit access.

It would be best, of course, if there was a way to phrase this so GCC doesn’t die, but this pattern is everywhere so it might be futile to solve it only here.

  • Kim

David,

Would you do the honors? I don't have commit access.

If we come up with a good solution, sure.

It would be best, of course, if there was a way to phrase this so GCC
doesn't die, but this pattern is everywhere so it might be futile to solve
it only here.

Yeah, if this fires for all our switch-over-enum-without-default... I
don't think we'll fix it (& there's no point fixing 3 cases if we
leave hundreds more in-tree). So if it's just these three, that's
something & would still need comments most likely. But it'd be better
if there were a solution that didn't suppress diagnostics (oh, and
this change as-is will probably fire Clang's -Wcovered-switch-default
warning... which we'd have to suppress).

- David

> David,
>
> Would you do the honors? I don't have commit access.

If we come up with a good solution, sure.

Sorry, I meant adding ARM GCC 4.7 to the list here:
http://llvm.org/docs/GettingStarted.html#check-here

But it's a little premature until we know why it's failing.

> It would be best, of course, if there was a way to phrase this so GCC
> doesn't die, but this pattern is everywhere so it might be futile to
solve
> it only here.

Yeah, if this fires for all our switch-over-enum-without-default... I
don't think we'll fix it (& there's no point fixing 3 cases if we
leave hundreds more in-tree). So if it's just these three, that's
something & would still need comments most likely. But it'd be better
if there were a solution that didn't suppress diagnostics (oh, and
this change as-is will probably fire Clang's -Wcovered-switch-default
warning... which we'd have to suppress).

Definitely.

Maybe Cy can provide more details on the environment where this happens
(e.g. compiler command for this file, exact error message, ...)

Thanks,
- Kim