Test failure JIT\\HardwareIntrinsics\\Arm\\AdvSimd.Arm64\\AdvSimd.Arm64_Part2_r\\AdvSimd.Arm64_Part2_r.cmd #65281
Assignees
Labels
arch-arm64
area-crossgen2-coreclr
blocking-outerloop
Blocking the 'runtime-coreclr outerloop' and 'runtime-libraries-coreclr outerloop' runs
disabled-test
The test is disabled in source code against the issue
os-linux
Linux OS (any supported distro)
os-windows
Milestone
Comments
VincentBu
added
arch-arm64
os-linux
dotnet-issue-labeler
bot
added
area-crossgen2-coreclr
untriaged
|
Here is a simplest program I managed to create to reproduce the issue (also pushed it to my clone of the repo - 14bce9a) // Licensed to the .NET Foundation under one or more agreements.
// The .NET Foundation licenses this file to you under the MIT license.
using System.Runtime.InteropServices;
using System.Runtime.Intrinsics;
class Runtime_63856
{
[StructLayout(LayoutKind.Auto)]
struct int8x16x2
{
Vector128<byte> _0;
Vector128<byte> _1;
}
struct Wrapper
{
int8x16x2 fld;
}
static int Main()
{
var val = default(Wrapper);
return 100;
}
}Note that When running on Arm64 with this will fail the following way |
echesakov
added
the
disabled-test
echesakov
added a commit
to echesakov/runtime
that referenced
this issue
Feb 14, 2022
|
@AaronRobinsonMSFT @davidwrighton if this is a new failure is it related to the ref fields work? |
|
@davidwrighton is this something you could look into since its related to intrinsics? |
|
This isn't intrinsics, this is struct layout, but fortunately enough while this failure is enough to break the test, it shouldn't actually break customers. However, lack of testing of the intrinsics is a problem so it does need to be fixed. |
|
Ok, this is actually a general purpose AutoLayout bug impacting the alignment calculations for structures. We were improperly computing a the wrong alignment in a number of scenarios. (Sometimes too high, sometimes too low.). Given the general lack of autolayout structures, this probably isn't a terribly impacting bug, but it likely does reduce the set of functions that can be used out of an R2R image if ValueTuple is used, and for applications which hold ValueTuple within the version bubble of the app, larger problems may arise. (Also its a problem if ValueTuple starts being used in CoreLib.) |
davidwrighton
added a commit
to davidwrighton/runtime
that referenced
this issue
Aug 11, 2022
- In particular: 1. The alignment requirement imposed by of a non-primitive, non-enum valuetype field is the alignment of that field 2. The alignment requirement imposed by a primitive is the pointer size of the target platform, unless running on Arm32, in which case if the primitive or enum is 8 bytes in size, the alignment requirement is 8. - The previous implementation produced an alignment of pointer size, unless running on Arm32 and one of the fields had an alignment requirement of 8 (in which case the alignment requirement computed for the structure would be 8) In addition, add a test which verifies that the instance field layout test types are actually producing R2R compatible results at runtime. - This test shows that we have some issues around explicit layout, so I was forced to disable that portion of the test for now. Fixes dotnet#65281
ghost
added
the
in-pr
davidwrighton
added a commit
that referenced
this issue
Aug 17, 2022
…73738) * New test * Fix auto layout algorithm to compute structure alignment correctly - In particular: 1. The alignment requirement imposed by of a non-primitive, non-enum valuetype field is the alignment of that field 2. The alignment requirement imposed by a primitive is the pointer size of the target platform, unless running on Arm32, in which case if the primitive or enum is 8 bytes in size, the alignment requirement is 8. - The previous implementation produced an alignment of pointer size, unless running on Arm32 and one of the fields had an alignment requirement of 8 (in which case the alignment requirement computed for the structure would be 8) In addition, add a test which verifies that the instance field layout test types are actually producing R2R compatible results at runtime. - This test shows that we have some issues around explicit layout, so I was forced to disable that portion of the test for now. Fixes #65281 Co-authored-by: Tomas Rylek <trylek@microsoft.com>
ghost
removed
the
in-pr
github-actions bot
pushed a commit
that referenced
this issue
Aug 17, 2022
…In particular: 1. The alignment requirement imposed by of a non-primitive, non-enum valuetype field is the alignment of that field 2. The alignment requirement imposed by a primitive is the pointer size of the target platform, unless running on Arm32, in which case if the primitive or enum is 8 bytes in size, the alignment requirement is 8. - The previous implementation produced an alignment of pointer size, unless running on Arm32 and one of the fields had an alignment requirement of 8 (in which case the alignment requirement computed for the structure would be 8) In addition, add a test which verifies that the instance field layout test types are actually producing R2R compatible results at runtime. - This test shows that we have some issues around explicit layout, so I was forced to disable that portion of the test for now. Fixes #65281
carlossanlop
pushed a commit
that referenced
this issue
Aug 18, 2022
…nment correctly (#74091) * New test * Fix auto layout algorithm to compute structure alignment correctly - In particular: 1. The alignment requirement imposed by of a non-primitive, non-enum valuetype field is the alignment of that field 2. The alignment requirement imposed by a primitive is the pointer size of the target platform, unless running on Arm32, in which case if the primitive or enum is 8 bytes in size, the alignment requirement is 8. - The previous implementation produced an alignment of pointer size, unless running on Arm32 and one of the fields had an alignment requirement of 8 (in which case the alignment requirement computed for the structure would be 8) In addition, add a test which verifies that the instance field layout test types are actually producing R2R compatible results at runtime. - This test shows that we have some issues around explicit layout, so I was forced to disable that portion of the test for now. Fixes #65281 * Re-enable disabled test * Remove file that shouldn't be added as part of the new test * Make a few test types public to silence unassigned field errors * Update comments and add more testing Co-authored-by: David Wrighton <davidwr@microsoft.com> Co-authored-by: Tomas Rylek <trylek@microsoft.com>
ghost
locked as resolved and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Run: runtime-coreclr outerloop 20220213.2
Failed test:
Error message:
NOTE:
AdvSimd.Arm64\AdvSimd.Arm64_Part2_randAdvSimd.Arm64\AdvSimd.Arm64_Part2_roare disabled by #65227.Please re-enable these tests when the issue is fixed!
The text was updated successfully, but these errors were encountered: