- Prevent unmatched expected error patterns from self-matching
- Prevent infinite recursion on unmatched expected warnings
- Always print the error message for unmatched error patterns
- Add test coverage for all unmatched message types
- Add test coverage for excess matched logs and warnings
Newer GCCs emit the following warning for opt_dff:
passes/opt/opt_dff.cc:560:17: warning: operation on ‘ff.Yosys::FfData::has_clk’ may be undefined [-Wsequence-point]
560 | ff.has_clk = ff.has_ce = ff.has_clk = false;
| ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Which is correct: the order of whether the read or write of has_clk
occurs first is undefined since there is no sequence point between them.
This is almost certainly just a typo/copy paste error and objectively
wrong, so just fix it.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Anlogic FPGAs all have two kinds of BRAMs, one is 9bit*1K when being
true dual port (or 18bit*512 when simple dual port), the other is
16bit*2K.
Supports mapping of these two kinds of BRAMs. 9Kbit BRAM in SDP mode and
32Kbit BRAM with 8bit width are not support yet.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
The preprocessor currently destroys double slash containing escaped
identifiers (for example \a//b ). This is due to next_token trying to
convert single line comments (//) into /* */ comments. This then leads
to an unintuitive error message like this:
ERROR: syntax error, unexpected '*'
This patch fixes the error by recognizing escaped identifiers and
returning them as single token. It also adds a testcase.
Before this commit, values, wires, and memories with an initializer
were value-initialized in emitted C++ code. After this commit, all
values, wires, and memories are default-initialized, and the default
constructor of generated modules calls the reset() method, which
assigns the members that have an initializer.
Before this commit, zero width sigspecs were dumped as "" (empty
string). Unfortunately, 1364-2005 5.2.3.3 indicates that an empty
string is equivalent to "\0", and is 8 bits wide, so that's wrong.
After this commit, a replication operation with a count of zero is
used instead, which is explicitly permitted per 1364-2005 5.1.14,
and is defined to have size zero. (Its operand has to have a non-zero
size for it to be legal, though.)
PR #1203 has addressed this issue before, but in an incomplete way.
Zachary Snow
github-actions[bot]
Austin Seipp
N. Engelhardt
gatecat
Miodrag Milanovic
Catherine
Lofty
Marcelina Kościelnicka
Icenowy Zheng
Thomas Sailer
Claire Xenia Wolf