You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issues is only reporting arm32 issues. Those are no longer relevant., and the issue is closed.
This one is a nullref in Crossgen2 that was also reproing in other tests and seems to be fixed now but recently we saw failures in the tests due to real diffs:
Most non-determinism has been fixed. There was still a case of non-determinism found in the Linux Arm target, but that issue appears to be rare. We will monitor this.
Not really a Crossgen2 issue per se, it's apparently about the publishing infra.
@hoyosjs filed and has driven this, we need to better understand the severity of the problem and its potential impact on Crossgen2 scenarios (e.g. our current work on composite container publishing).
Crossgen2 fails for assemblies with embedded types.
Not sure if it's still relevant, @davidwrighton should know for sure, in the issue thread he claims to be working on a fix.
That particular customer is no longer in need of the fix, but the issue was still present. This is now fixed with the addition of partial type equivalence support in Crossgen2. The new support should be sufficient such that we only have bugs to fix in the future, and not entire features to implement.
Crossgen2 fails when a Managed C++ file is specified as just a reference.
We need to assess whether it's something that should be fixed in Crossgen2 or just ambient system behavior dictated by WER and the like.
Bruce Forstall confirmed we're no longer seeing these failures in the lab so that they were likely caused by misconfiguration of WER or related settings, the issue is now closed.
getHFAType fails on ARM64 and passes on X64 targeting ARM64.
At one point there was a speculation that the problem is Crossgen2 running under the CORE_ROOT debug build of coreclr and JIT but I haven't managed to observe that when trying to repro locally.
Remove unused AllowEmptyTelemetry task from Crossgen2 usage.
I suspect this is already fixed or partially fixed, we just need to double-check and / or correct the remaining inconsistencies and close this, it should be a 1 day work at most.
We need to identify the balance between further optimizing compiler memory footprint and just stating that there are limitations to code size compilable on 32-bit architectures.
OSX x64 failures in composite GC stress due to "external disassembler not available".
I have made two small fixes to the list - yesterday I missed the generic cycle bug as the open issue has somewhat cryptic title, I have also fixed the link to Mark's PR fixing type initialization ordering, yesterday I pasted the wrong link to a related issue. For commenting on individual issues feel free to use the original issue threads, my expectation is that this issue is only going to be used to prioritize and drive fixing the issues and to track progress of that effort (and possible overflow work to .NET 9 as not all above bullet points are critical for .NET 8 and, as you can see, there's just a lot of stuff).
As this is just an overarching issue summarizing Crossgen2 work and we're close to wrapping up .NET 8, I'm closing this issue for now; I assume that as part of .NET 9 planning we'll consider picking up some of the remaining work for .NET 9.
Real bugs and deficiencies
--compilebubblegenerics
causes live lock at app start (100% CPU usage) #78117X
used as both ValueType and non-ValueType" #61604Static virtual methods
Possible future work
Nice to have
--pdb
does not work when the output PDB is not named the way MSDiaReader expects #78230Individual test bugs
/cc @dotnet/crossgen-contrib
The text was updated successfully, but these errors were encountered: