This was a fudge to work around using VlWide in `if` conditions without
a `_ != 0` check. That check is actually inserted by V3Width (or an
equivalent reduction), so the offending code was only generated
internally. Hopefully fixed the single instance where this really
happened. (If not, C++ will fail to compile with "cannot convert VlWide
to bool in 'if (__HERE__)'" errors, still better than the old version
which used to silently not do the right test due to incorrect implicit
conversions.)
Change WDataInP/WDataOutP to be opaque handles types instead of aliases
to raw pointers. This subsequently eliminates needing an implicit cast
operator in VlWide, which is replaced with implicit constructors of
WDataInP/WDataOutP that can create a handle from a VlWide. This
eliminates some unsafe conversions that the previous implicit cast
operator unintentionally enabled (e.g. #7618). It also eliminates
having to insert ".data()" in various places int he generated code, which
simplifies internals (the only place ".data()" should be needed is in
calls to variadic functions where the expected type of the argument is
not WDataInP/WDataOutP).
The handles otherwise behave like pointers, implementing the minimal
amount of operators required to code the runtime. The handle is still
only a single pointer, and will be passed in registers as before, so
this patch should be performance neutral.
As part of this removed WData, which used to be an alias for EData.
All uses are now either EData*, WDataInP, WDataOutP, or VlWide directly.
Remove parallel (using the FST library writer thread) and offloaded
(separate Verilator internal thread) tracing (only used by FST). These
are not compatible with #6992, and #5806 should yield better performance
in all cases.
Consequently mark '--trace-threads' and '--trace-fst-thread' options as
deprecated
Apple clang rejects `-o` when a precompiled header (.gch) is involved,
reporting "cannot specify -o when generating multiple output files".
Remove the unnecessary `-o $@` from the two PCH build rules; the
`%.o: %.cpp` pattern already implies the correct output name.