Major Tools
Other Tools
General Info

Issue #1058

GCC 6.1.1 "Verilator internal fault" when trying to run on any file

Added by Lasse Schuirmann 10 months ago. Updated 9 months ago.

% Done:




I'm trying to integrate verilator's lint functionality into coala ( so it can be used together with other static code analysis.

The issue is very simple to me but seems to occur only on my system, maybe related to the package I used.

Steps to reproduce

  1. Install the verilator package via the ArchLinux AUR package (
  2. Create a simple flipflop.v file with the example code given on
  3. Run verilator --lint-only flipflop.v
lasse@lssteady ~/tmp/vl % verilator --version
Verilator 3.882 2016-03-01 rev verilator_3_882-1-gacff683

Expected Results


Actual Results

lasse@lssteady ~/tmp/vl % verilator --lint-only flipflop.v
%Error: Verilator internal fault, sorry.  Consider trying --debug --gdbbt
%Error: Command Failed /usr/bin/verilator_bin --lint-only flipflop.v

Further Debug Data

Additional Info

I'm getting this also when running verilator --cc or so. I tried other examples from the wiki article as well, same result. Marking this as high priority initially since it's not possible to use verilator with any basic example data, reprioritize as needed.


#1 Updated by Wilson Snyder 10 months ago

It doesn't crash with --debug? That's very unusual. Could you try to make a core file and dump backtrace of it? Otherwise I need to install arch and all, which archlinux version are you using?

#2 Updated by Lasse Schuirmann 10 months ago

Can you provide instructions on how I can get the information you desire? I haven't used verilator except those few commands.

I use the latest ArchLinux (rolling release, so no version number here.)

#3 Updated by Wilson Snyder 10 months ago

  uname -a
  cat /etc/*release
  ulimit -c unlimited
  verilator --lint-only flipflop.v
  gdb /usr/bin/verilator_bin core

#4 Updated by Lasse Schuirmann 10 months ago

Apparently I need to generate a core somehow?

#5 Updated by Wilson Snyder 10 months ago

Looks like they stripped the executable. I'll give a try at installing it.

#6 Updated by Wilson Snyder 10 months ago

You're using Antergos Linux, not Arch. Antergos is a rolling system, so I don't know how to create the same configuration you have. Also I downloaded Arch and it's a PITA to install, I see this page

and it's like 30 steps - isn't there something more sane to get a boot image? If you can provide a virtualbox .vdi file or .iso showing the issue I'll look at it, otherwise sorry but I can't really spend a few hours figuring all this out.

#7 Updated by Lasse Schuirmann 10 months ago

Hey, you can download an ISO from and install that really quick, there's a GUI for the installation so you don't have to go through the whole ArchLinux installation.

You can also use the Antergos Live ISO and try out my issue without installing the OS at all.

/me regretfully admits that he didn't have enough time in his GSoC to write express installation for ArchLinux for GNOME Boxes.

#8 Updated by Lasse Schuirmann 10 months ago

Antergos will basically give you a preconfigured archlinux with yaourt already set up, so when you boot it up you should be able to install verilator with yaourt -Sy verilator --noconfirm.

#9 Updated by Wilson Snyder 10 months ago

  • Status changed from New to AskedReporter

Well, got the OS up. Installed it, and your example runs fine. BTW I noted when installing it says:

l otrfan commented on 2016-03-26
I'm not actively using verilator anymore. I bumped the pkgver and it seemed to build (relatively) cleanly, but that's all the testing I did.

So basically you were already in a bad spot. If you want to debug further it's yours to maintain packaging for, or use a different distro which has an active maintainer. If you figure out that some code change is needed I'll of course take the patch back. Sorry.

#10 Updated by Jannis Harder 10 months ago

I ran into the same issue when trying to use verilator on a recent arch system. It also happens when building from source, ignoring the unmaintained AUR package.

Since all versions of verilator that I tried seemed to be affected, I assumed some change in a dependency, or default compiler option caused this.

I finally figured out the cause when trying to compiler verilator with clang++ instead of g++. I got tons of the following warning:

./V3Ast__gen_impl.h:95:62: warning: 'this' pointer cannot be null in well-defined C++ code; pointer may be assumed to always convert to true [-Wundefined-bool-conversion]

I read a short time ago that gcc now also optimizes away null checks on this pointers. As of gcc version "gcc (GCC) 6.1.1 20160501" it seems to be certainly the case. It doesn't seem that gcc is able to generate warnings for this though.

As a quick work-around I got verilator to work on the flipflop example by compiling with the gcc flag "-fno-delete-null-pointer-checks", which makes gcc assume that 0 is also a valid address and thus might negatively impact other optimizations too. A proper fix would be to change the code to be valid, well-defined C++ code. Due to the amount of warnings clang produced, and as I'm not familiar with the verilator code base, I didn't attempt to provide a fix for this.

#11 Updated by Wilson Snyder 10 months ago

  • Subject changed from "Verilator internal fault" when trying to run on any file to GCC 6.1.1 "Verilator internal fault" when trying to run on any file
  • Category set to Configure/Make/Compiling
  • Status changed from AskedReporter to Resolved

Excellent. It's strange that clang which gives that warning didn't use that optimization.

I added -fno-delete-null-pointer-checks to the configure script. If you could try the git version from scratch it would be appreciated.

The internals require this because a dynamic cast takes in NULL. It's a case where the standard is badly written, and to change would be a fairly major overhaul. The Verilator output code however was cleaned of this.

#12 Updated by Jannis Harder 9 months ago

It seems the -fno-delete-null-pointer-checks flag is only added when specifying --enable-ccwarn during configure. As verilator produces warnings on my gcc version this does not compile.

Would you be open to patches that eliminate this undefined behavior from the verilator codebase and thus avoid the need to maintain work-around flags?

#13 Updated by Wilson Snyder 9 months ago

  • Status changed from Resolved to Assigned

I'll fix the flags. While I'd love a patch it's very difficult to fix the real issue, but I'll get to it eventually.

#14 Updated by Wilson Snyder 9 months ago

  • Status changed from Assigned to Resolved

Pushed configure change to hopefully pass the flag correctly this time. Be sure to make distclean before this may work.

#15 Updated by Wilson Snyder 9 months ago

  • Status changed from Resolved to Closed

In 3.884.

Also available in: Atom