This is reducing nearby calls to TiGetClient() API when the value
can be looked up one time and stored in a local variable to make
other decisions about.
This is due to TiGetClient() potentially having a slightly higher
cost to call than previously, this is a kind of peephole
optimization approach (if I can see multiple getters used within
the window it got optmized).
'ticlient' was used for retrieval as ClientData so that future
greps across the codebase for `ti_client` should only match naked
access.
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*)
After futher review of this function it looks like the existing
fclose() is not in the correct place, and recent patches have
added fclose() to this function in better places (covering all
returns) but did not take into account the existing misplaced
fclose().
created use of 'alloc' local variable to track when an allocation occurred
so exit path logic is more straight forward for compiler/analyser to see
potential optimisations.
Guided by CodeQL static code analyser.
FileMayNotBeClosed.ql
FileMayNeverBeClosed.ql
The trick with "if(fp != stdout)" is problematic (to analyser) as
technically 'stdout' can be a global pointer that COULD be modified any
time, so it might have changed between the fopen() and fclose() calls so
the close MAY NEVER occurs (which is problem the analyzer can see).
So local state is maintained as a bool which will also clarify to the
compiler see the intention without concern for external stdout
modification.
Some items appear to be out and out leaks when certain commands are use.
connection to a net that has been decomposed into a resistor array
cannot be found. This indicates some fundamental error in the way
extresist works. However, it should not be producing an invalid
and unsimulatable netlist. Instead, it makes an arbitrary connection
from the device terminal to the resistor array and adds an entry in
the output netlist (.res.ext file). This results in a poor
representation of the resistor network to that terminal, but an
otherwise simulatable netlist. A warning is issued to note that an
arbitrary connection has been made. This is most typically a
"garbage in, garbage out" situation in which insufficient information
exists in a layout to inform magic on which direction current is
traveling through a net. However, it should be possible to rewrite
the extresist code so that magic makes somewhat informed decisions
about current paths and produces a halfway decent representation of
the actual net, instead of just giving up on the detailed extraction.
Looks to be used as integer bitmask which is flagged by compiler warning
as dubious, when using compiler provided type 'bool' from stdbool.h
in C99 instead of unsigned char type.
C29 bool type compatibility
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)
The '&' has higher precedence, so the expression of the '&' side receive
extra parentheses.
ResMakeRes.c:671:37: warning: suggest parentheses around '&&' within '||'
ResMakeRes.c:942:32: warning: suggest parentheses around '&&' within '||'
ResSimple.c:201:70: warning: suggest parentheses around '&&' within '||'
ResRex.c:1036:28: warning: suggest parentheses around '&&' within '||'
ResRex.c:1038:50: warning: suggest parentheses around '&&' within '||'
ext2sim.c:1341:47: warning: suggest parentheses around '&&' within '||'
ext2spice.c:172:44: warning: suggest parentheses around '&&' within '||'
ext2spice.c:173:49: warning: suggest parentheses around '&&' within '||'
ext2spice.c:3655:50: warning: suggest parentheses around '&&' within '||'
ext2hier.c:1412:50: warning: suggest parentheses around '&&' within '||'
gcrDebug.c:638:55: warning: suggest parentheses around '&&' within '||'
selEnum.c:323:28: warning: suggest parentheses around '&&' within '||'
GCC14 -Wall cleanup series [-Wparentheses]
PlowRules1.c:439:9: warning: suggest parentheses around assignment used as truth value
PlowTech.c:645:17: warning: suggest parentheses around assignment used as truth value
PlowTech.c:652:17: warning: suggest parentheses around assignment used as truth value
PlowTech.c:1019:17: warning: suggest parentheses around assignment used as truth value
ResReadSim.c:270:13: warning: suggest parentheses around assignment used as truth value
ResReadSim.c:871:9: warning: suggest parentheses around assignment used as truth value
ResRex.c:1840:17: warning: suggest parentheses around assignment used as truth value
getrect.c:72:9: warning: suggest parentheses around assignment used as truth value
getrect.c:79:9: warning: suggest parentheses around assignment used as truth value
getrect.c:86:9: warning: suggest parentheses around assignment used as truth value
getrect.c:93:9: warning: suggest parentheses around assignment used as truth value
hash.c:732:16: warning: suggest parentheses around assignment used as truth value
heap.c:328:17: warning: suggest parentheses around assignment used as truth value
heap.c:344:17: warning: suggest parentheses around assignment used as truth value
netlist.c:323:17: warning: suggest parentheses around assignment used as truth value
niceabort.c:121:9: warning: suggest parentheses around assignment used as truth value
path.c:1102:12: warning: suggest parentheses around assignment used as truth value
pathvisit.c:245:13: warning: suggest parentheses around assignment used as truth value
pathvisit.c:295:17: warning: suggest parentheses around assignment used as truth value
tech.c:656:17: warning: suggest parentheses around assignment used as truth value
ext2spice.c:1591:16: warning: suggest parentheses around assignment used as truth value
ext2spice.c:1622:16: warning: suggest parentheses around assignment used as truth value
ext2spice.c:1813:12: warning: suggest parentheses around assignment used as truth value
ext2spice.c:1862:12: warning: suggest parentheses around assignment used as truth value
ext2spice.c:3808:16: warning: suggest parentheses around assignment used as truth value
CalmaRdio.c:437:9: warning: suggest parentheses around assignment used as truth value
CalmaWrite.c:396:9: warning: suggest parentheses around assignment used as truth value
CalmaWrite.c:1772:29: warning: suggest parentheses around assignment used as truth value
CalmaWriteZ.c:372:9: warning: suggest parentheses around assignment used as truth value
CalmaWriteZ.c:1608:29: warning: suggest parentheses around assignment used as truth value
CIFrdtech.c:209:9: warning: suggest parentheses around assignment used as truth value
CIFrdtech.c:214:9: warning: suggest parentheses around assignment used as truth value
CIFrdtech.c:220:9: warning: suggest parentheses around assignment used as truth value
CIFrdtech.c:226:9: warning: suggest parentheses around assignment used as truth value
CIFrdutils.c:1258:12: warning: suggest parentheses around assignment used as truth value
GCC14 -Wall cleanup series [-Wparentheses]
Compiler is expressing range concern with the warning mitigated by using
unsigned C array offsets. This also draws attention to the range concern
when reading the code and making changes.
DBundo.c:263:45: warning: array subscript has type 'char'
DBundo.c:279:49: warning: array subscript has type 'char'
DBundo.c:317:52: warning: array subscript has type 'char'
DBundo.c:318:64: warning: array subscript has type 'char'
DBundo.c:324:52: warning: array subscript has type 'char'
DBundo.c:325:64: warning: array subscript has type 'char'
DBundo.c:329:50: warning: array subscript has type 'char'
DBundo.c:330:58: warning: array subscript has type 'char'
DBundo.c:338:52: warning: array subscript has type 'char'
DBundo.c:339:64: warning: array subscript has type 'char'
DBundo.c:345:52: warning: array subscript has type 'char'
DBundo.c:346:64: warning: array subscript has type 'char'
DBundo.c:350:50: warning: array subscript has type 'char'
DBundo.c:351:58: warning: array subscript has type 'char'
DBundo.c:371:52: warning: array subscript has type 'char'
DBundo.c:372:64: warning: array subscript has type 'char'
DBundo.c:378:52: warning: array subscript has type 'char'
DBundo.c:379:64: warning: array subscript has type 'char'
DBundo.c:383:50: warning: array subscript has type 'char'
DBundo.c:384:58: warning: array subscript has type 'char'
DBundo.c:392:52: warning: array subscript has type 'char'
DBundo.c:393:57: warning: array subscript has type 'char'
DBundo.c:399:52: warning: array subscript has type 'char'
DBundo.c:400:57: warning: array subscript has type 'char'
DBundo.c:403:53: warning: array subscript has type 'char'
DBundo.c:407:50: warning: array subscript has type 'char'
DBundo.c:408:58: warning: array subscript has type 'char'
EFbuild.c:1048:32: warning: array subscript has type 'char'
EFbuild.c:1056:32: warning: array subscript has type 'char'
ExtBasic.c:2358:43: warning: array subscript has type 'char'
ExtBasic.c:2493:43: warning: array subscript has type 'char'
ExtBasic.c:2519:43: warning: array subscript has type 'char'
ExtBasic.c:2644:43: warning: array subscript has type 'char'
ExtBasic.c:2678:43: warning: array subscript has type 'char'
ResPrint.c:143:43: warning: array subscript has type 'char'
plotRutils.c:713:34: warning: array subscript has type 'char'
plotRutils.c:786:29: warning: array subscript has type 'char'
GCC14 -Wall cleanup series [-Wchar-subscripts]
request #325 from Daryl Miles. Made a few simple style changes
to conform to (what is vaguely defined as) the overall programming
style for magic (passed down from John Ousterhout).
Fix code scanning alert no. 64: Too few arguments to formatting function
Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
Fix code scanning alert no. 109: Wrong type of arguments to formatting function (#27)
Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
gparams.rg_ttype seems to be the only value of the correct type that has connectivity with the callsite.
Copilot Autofix rejected: ResGetDevice(gparams.rg_devloc, /* second argument */);
resis/ResSimple.c
9aa39f82 (2021-05-25 22:41:52 -0400 1039) resDevice *res = ResGetDevice(gparams.rg_devloc);
commit 9aa39f820f (tag: 8.3.169)
Date: Tue May 25 22:41:52 2021 -0400
a transistor's first tile record is a well or substrate type;
normally this is avoided, but if that's the only device terminal
that connects to the node, it will be used. Also changed the
code to not report a failure when space is found under the
device, when space is allowed as a substrate type. Instead it
will print a message that the substrate is not being extracted as
a resistive network. However, note that the correct solution is
to do what the regular "extract" code does, which is to paint the
substrate type in the cell area first, so that there are valid
tile types to use for extracting the substrate network.
non-Manhattan geometry is analyzed for resistance extraction.
This patch merely prevents the crash condition. It does not
solve the root of the problem, which is that split tiles can
belong to two different nets, but the tile can hold extraction
information for at most one of those nets.
a method that failed to work on devices with complex shapes on the
device recognition layer, such as snake-geometry resistors. (2)
The use of contact type "xpc" in the sky130 tech file as its own
contact residue caused the contact tracing in extresist to fail.
I opted to keep the unorthodox contact description in the tech
file and wrote an extension to a routine in extresist to handle
the case.
missing from a netlist generated by ext2spice with the "extresist"
option enabled. The first had to do with some parts of nets being
given alias names for a net, and the second was caused during
"extresist" and would also result in error messages about devices
missing terminals.
different way. Added a routine to remove all layers of a contact
from all planes except the contact's base plane before finding
and processing contacts. This causes ExtFindRegions() to find
and process only one tile on one plane per contact, so there are
no redundant contact entries. Also, any overlapping stacked
contacts are resolved, which avoids the very common error of
contacts not being processed at the correct size because they
are being processed per tile for chopped-up areas.
was made to limit the ExtFindRegions() search to one plane per
contact. Fixed this simply by doubling the resistance per via
so that the final result is correct.
routine that marks resistors in loops to prevent infinite
recursion, but later incorrectly eliminates those resistors.
Also: Changed the "tolerance" command to affect only the R-C
time constant tolerance. Added a "threshold" command option
that limits output of small resistors. This can help reduce
large networks that are otherwise not reducible by the three
methods of reduction (serial, parallel, and delta-wye), but
does affect output values (slightly). This will probably need
to be revisited at some point.
cuts per contact area during parasitic resistance extraction.
Previously, the result was divided by the via pitch twice,
resulting in most contact areas being reported as a single
cut.
command for use with "extract path"; the cellname was being cleared
after generating the filename with the extract path, but was being
used afterward, so it needed to be reverted back to the original
value, not just free'd. Otherwise "extresist" will fail to produce
any results.
".res.ext" file from "extresist" after using "extract do local" (and
probably with "extract path" as well). Fixed this, and also made
sure that "extresist" writes the ".res.ext" file to the same location
as ".ext" always, so that handling is consistent throughout the
full R-C extraction process, across the use of "extract", "ext2sim",
"extresist", and "ext2spice".
encountered an issue where a label in a flattened layout
exceeded 256 characters, ended up in the .sim file, and was
truncated when read back during "extresist". The change to 1024
is a stop-gap measure because ultimately I want to replace the
use of .sim files with .ext files using the routines in extflat/,
which would deprecate everything in ResReadSim.c.
can result in negative resistors due to integer overflow. In all
cases, the target was floating-point and it was only necessary to
recast everything to float first.
causing the SI suffix not to be the expected one. Adjusted the
bounds where each SI suffix is used to keep output in the range of
0.1 to 100, although the boundary is very subjective. Made a
correction to the extresist code to scan through all device records
for a tile type. However, (1) there are cases being missed, and (2)
this should not be necessary since all device types should be able
to be known exactly from the contents of the .sim file. Needs more
work.
222 from Sean Cross. Corrected a few places where the blanket
conversion "Region"->"ExtRegion" picked up some comment lines
that were unrelated to the structure name.
natural sort instead of ASCII-based sorting, so that ports that
are numbered arrays will be indexed properly by count. Also:
Modified the "extresist" handling of substrate to draw the default
substrate type over the entire cell area (less areas of nwell or
other conflicting type). This allows extresist to extract the
entire substrate as a resistive network. The result is ugly and
may warrant some aggressive network simplification, but it should
at least be realistic.
2-terminal devices without complaining. The previous handling
seemed to be technically correct other than spitting out warnings
about missing terminals.
isolate the terminal areas of a device (e.g., source and drain)
and calculate their area and perimeter individually for the
device (in addition to the traditional method of calculating
area and perimeter of each resistance class for the entire node).
Also: Reworked the SPICE syntax output to generate SI values
in the range 1-1000 with the appropriate suffix (e.g., "20u")
instead of defaulting to "u" for lengths and "p" for areas.
This prevents it from producing weird units like "150000u" when
a process definition already includes a scalefactor.
Reworked the "extresist" code to use the device terminal area
and perimeter. This fixes an error in which "extresist" would
lose these values and "ext2spice" with option "extresist on"
would generate a new netlist output with zero terminal areas
and perimeters.
transistor records match between the ".ext" file and the ".res.ext"
file for the number of terminals per device. Previously, the first
device type for the layer type was always being used, and if it had
fewer terminals (e.g., a MOScap), then one terminal would go missing
in the output.
in the input. The name of one was being modified but was being
right-justified into the string, resulting in a name starting with
many space characters. Also: Fixed an issue with extresist where
a label that ends up with an empty string can become a node with
an empty string name in the .res.ext file output.
number of terminals for devices that don't have the usual gate/
source/drain terminals (e.g., diodes, resistors, capacitors) when
writing the devices with re-mapped terminals into the .res.ext
file. Also: Changed the size of the word containing the name
refcount for "equiv" statements, since an accidental shorting
of pins can cause a large number of "equiv" statements in a .ext
file, causing an overrun of the previously 1-byte refcount (this
probably does not make the structure any longer, since it likely
has to fit to a word boundary).
Darryl L. Miles
Tim Edwards
Sean Cross