Open iarspider opened 1 year ago
assign l1
New categories assigned: l1
@epalencia,@aloeliger,@cecilecaillol you have been requested to review this Pull request/Issue and eventually sign? Thanks
A new Issue was created by @iarspider .
@Dr15Jones, @perrotta, @dpiparo, @rappoccio, @makortel, @smuzaffar can you please review it and eventually sign/assign? Thanks.
cms-bot commands are listed here
2. False-positive warnings about modelResult not being initialized in
L1TCaloSummary::produce
(as far as I understand, it is filled later, so maybe silence the warning for that block?)
Poking around the code of https://github.com/Xilinx/HLS_arbitrary_Precision_Types.git I think the warning is technically correct. All(?) the ap_*
types use ap_private
underneath. The ap_private
version for storing less than 64 bits (as is the case here, AFAICT) has a member variable VAL
that is one of the fundamental integer types (as defined here and here). The default constructor does not initialize the VAL
but only calls the clearUnusedBits()
member function. The clearUnusedBits()
indeed reads from VAL
before assigning into it, that strictly speaking leads to undefined behavior (irrespective of the variable being written into later).
@vshang, @hftsoi, I don't suppose Wisconsin has either of you as the emulator maintainer for CaloL1? If this is one of you, could you take a look at these warnings (if not let me know, I'll do what I can). L1TCaloSummary is my issue, I'll take a look at that when I am back from US CMS.
@aloeliger gentle ping on this
@iarspider Thanks for bringing this back to my attention. I can try to take a look at this tomorrow unless it is more urgent?
@hftsoi I also want to make one more attempt to ping you to see if there is a Wisconsin maintainer of L1TCaloLayer1
. If not I will take a look into fixing it myself..
For reference: build log with the issue.
@aloeliger this is not urgent.
@hftsoi I also want to make one more attempt to ping you to see if there is a Wisconsin maintainer of
L1TCaloLayer1
. If not I will take a look into fixing it myself..
sorry I missed your earlier tag somehow. As far as I know there is no active emulator maintainer for CaloL1, people come and go making modification whenever their development depends on it.
GCC 12 is emitting compilation warnings about maybe-uninitialized variables in L1TCaloLayer1 code:
L1TCaloLayer1::costruct
:L1TCaloSummary::produce
(as far as I understand, it is filled later, so maybe silence the warning for that block?)L1TCaloLayer1FetchLUTs(...)
:(here I would suggest moving
eLUT.push_back(phiLUT);
after the code that fillsphiLUT
)