When global <sys/mman.h> was removed from tile.h it also removed
<unistd.h> nearby. This exposes the lack of <unistd.h> being
included where needed using APIs like close()/read()/unlink()/isatty()
the WASM build seems to show this as the header file set is structured
differently.
keyword in LEF. FOREIGN may take an origin offset, but it is
optional. The routine to check that there were no offset values
in the statement incorrectly checked for a NULL token instead of
a value ";" which would indicate an end-of-statement.
All naked access to `ti_client` now uses the function-like-macro
to encapsulate this action. This macro existed before this just
makes all sites utilize it.
Added additional INT and PTR variants to remove the programmer
load on thinking about casing and casts polluting the point
of use. So the use now looks cleaner.
Equivalent prototypes:
void TiSetClient(Tile*, ClientData)
void TiSetClientINT(Tile*, intptr_t) /* pointertype */
void TiSetClientPTR(Tile*, void*)
ClientData TiGetClient(Tile*)
intptr_t TiGetClientINT(Tile*) /* pointertype */
void *TiGetClientPTR(Tile*)
macro. Based on observation of cells in PDKs where ORIGIN and/or
FOREIGN are non-zero, added code that forces a correction of LEF
macro coordinates to match the GDS coordinates, with an
equivalent negative shift of the LEF macro ORIGIN to compensate.
Normally, both ORIGIN and FOREIGN will be zero and the added code
will do nothing. Note that this code does not handle the
additional optional orientation. A LEF macro with a different
coordinate system than its GDS is already weird; a LEF macro
with a different rotation than its GDS is hopefully something
that nobody ever does in practice. If needed, I'll cross that
bridge when I come to it.
LefHelper_DBTechNameType_LefLower() identified and introduced during
conversion to const data usage.
Only side-effect is some log messages will use original verbatim token
now instead of lowercase version (but this seems ok when file parsing,
to quote the problematic information source verbatim)
Some function parameters (char *sname) have been made const due
referencing const data sources.
K&R obsolete syntax removal for C23 compatibility series
Due to use of strcasecmp() or similar C API.
Maybe HAVE_STRINGS_H is needed ? If so which platforms needs this ?
clang18 default warning cleanup (strict)
lefTech.c:107:16: warning: suggest parentheses around assignment used as truth value
lefTech.c:160:16: warning: suggest parentheses around assignment used as truth value
lefTech.c:426:16: warning: suggest parentheses around assignment used as truth value
lefTech.c:453:16: warning: suggest parentheses around assignment used as truth value
lefTech.c:486:16: warning: suggest parentheses around assignment used as truth value
lefWrite.c:190:9: warning: suggest parentheses around assignment used as truth value
lefWrite.c:303:12: warning: suggest parentheses around assignment used as truth value
lefWrite.c:315:12: warning: suggest parentheses around assignment used as truth value
lefWrite.c:377:16: warning: suggest parentheses around assignment used as truth value
lefWrite.c:439:16: warning: suggest parentheses around assignment used as truth value
lefWrite.c:1222:12: warning: suggest parentheses around assignment used as truth value
lefWrite.c:2246:12: warning: suggest parentheses around assignment used as truth value
defWrite.c:415:12: warning: suggest parentheses around assignment used as truth value
defWrite.c:447:12: warning: suggest parentheses around assignment used as truth value
defWrite.c:2039:16: warning: suggest parentheses around assignment used as truth value
defWrite.c:2104:16: warning: suggest parentheses around assignment used as truth value
defWrite.c:2478:16: warning: suggest parentheses around assignment used as truth value
defWrite.c:2498:20: warning: suggest parentheses around assignment used as truth value
defWrite.c:3066:16: warning: suggest parentheses around assignment used as truth value
defWrite.c:3084:28: warning: suggest parentheses around assignment used as truth value
defWrite.c:3111:28: warning: suggest parentheses around assignment used as truth value
lefRead.c:651:12: warning: suggest parentheses around assignment used as truth value
GCC14 -Wall cleanup series [-Wparentheses]
Looks like a logic bug, hiding behind this compiler warning
lefTech.c:507:21: warning: suggest parentheses around assignment used as truth value
lefTech.c:509:21: warning: suggest parentheses around assignment used as truth value
GCC14 -Wall cleanup series [-Wparentheses]
Fix code scanning alert no. 53: Multiplication result converted to larger type (#48)
Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
Fix code scanning alert no. 23: Call to function with fewer arguments than declared parameters (#38)
Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
Fix code scanning alert no. 63: Too few arguments to formatting function (#3)
* Create codeql.yml
* Fix code scanning alert no. 63: Too few arguments to formatting function
Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
---------
Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
Fix code scanning alert no. 62: Too few arguments to formatting function (#1)
* Create codeql.yml
* Fix code scanning alert no. 62: Too few arguments to formatting function
Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
---------
Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
that no nets will be checked for antenna gate and diffusion area,
and no antenna properties will be output to the LEF file. This can
greatly speed up LEF output file generation for a large design.
Thank you to Tamas Hubai for the code patch.
report it after "Failure to read in entire sub-tree". This will
not report every failing cell (since it quits reading after the
first failure) but will avoid the existing issue of printing
nothing and leaving the user with no feedback as to which cell
was the problem.
previously, MASTERSLICE layers would not be added to obstruction
layers made by "-hide". However, an nwell, for example, that
stuck outside of a prBoundary *would* be recorded, which was
inconsistent. Resolved this by allowing MASTERSLICE layers
in the OBS block, but only for layers that are not a substrate
type. NOTE: It may be better to just insist that a MASTERSLICE
layer define an obstruction type in the "lef" section of the
tech file, and treat it like routing obstructions. Alternatively,
one may question whether special obstruction types are needed at
all, as one could simply define an obstruction as a type without
a port label.
did not need to be changed, but the line below it that depended
on the layer being a contact type was wrong; the contact had
to be identified independently of the last layer type, which
might not be the contact cut type.
Darryl L. Miles
R. Timothy Edwards
Kareem Farid