Fix one more Crossgen2 field layout mismatch with runtime #73978
Conversation
|
/azp run runtime-coreclr crossgen2-composite |
|
Azure Pipelines successfully started running 1 pipeline(s). |
| @@ -545,7 +545,7 @@ protected ComputedInstanceFieldLayout ComputeAutoFieldLayout(MetadataType type, | |||
| // between base type and the current type. | |||
| LayoutInt cumulativeInstanceFieldPos = CalculateFieldBaseOffset(type, requiresAlign8, requiresAlignedBase: false); | |||
| LayoutInt offsetBias = LayoutInt.Zero; | |||
| if (!type.IsValueType && cumulativeInstanceFieldPos != LayoutInt.Zero && type.Context.Target.Architecture == TargetArchitecture.X86) | |||
| if (!type.IsValueType && cumulativeInstanceFieldPos != LayoutInt.Zero && type.Context.Target.Architecture != TargetArchitecture.ARM) | |||
There was a problem hiding this comment.
This function needs a comment describing what's happening here, and we need a test where we have Sequential field layout used for classes as well as just the standard auto layout.
There was a problem hiding this comment.
Thanks David for your feedback. I have improved the code comment and I added a pair of tests exercising the 16-layout with classes using both Auto and Sequential layout. Could you please take another look when you have a chance?
|
There is one test failing in the IL.ClassLayout tests. Given this error looks like the test is expecting a nondeterministic layout:
|
The field offset mismatch in the test JIT/Regression/JitBlue/Runtime_60035/Runtime_60035.csproj specific to Crossgen2 composite mode is due to the recent proliferation of 16-byte alignment specific to Vector across the runtime repo. Previously, the largest supported alignment was 8 and X86 was the only architecture not respecting it. In general the problem is caused by the fact that the native CoreCLR runtime method table builder calculates field offsets without taking the method table pointer into account; in the particular case of the Runtime_60035 test, the class System.Text.Encodings.Web.OptimizedInboxTextEncoder has a field named _allowedAsciiCodePoints that is 16-aligned that exposes this inconsistency. Thanks Tomas
|
/backport to release/7.0-rc1 |
|
Started backporting to release/7.0-rc1: https://github.com/dotnet/runtime/actions/runs/2894813266 |
ghost
locked as resolved and limited conversation to collaborators
The field offset mismatch in the test
JIT/Regression/JitBlue/Runtime_60035/Runtime_60035.csproj
specific to Crossgen2 composite mode is due to the recent
proliferation of 16-byte alignment specific to Vector across
the runtime repo. Previously, the largest supported alignment
was 8 and X86 was the only architecture not respecting it.
In general the problem is caused by the fact that the native
CoreCLR runtime method table builder calculates field offsets
without taking the method table pointer into account; in the
particular case of the Runtime_60035 test, the class
System.Text.Encodings.Web.OptimizedInboxTextEncoder
has a field named _allowedAsciiCodePoints that is 16-aligned
that exposes this inconsistency.
Thanks
Tomas
/cc @dotnet/crossgen-contrib
Fixes #73728