| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
* Implement instantiating and unboxing through portable stublinker code
- Handle only the cases with register to register moves
- Shares abi processing logic with delegate shuffle thunk creation
- Architecture specific logic is relatively simple
- Do not permit use of HELPERREG in computed instantiating stubs
- Fix GetArgLoc such that it works on all architectures and OS combinations
Add a JIT stress test case for testing all of the various combinations
- Use the same calling convention test architecture that was used as part of tail call work
Rename secure delegates to wrapper delegates
- Secure delegates are no longer a feature of the runtime
- But the wrapper delegate lives on as a workaround for a weird detail of the ARM32 abi
|
|
- Can remove a machine instruction which adds vtable offset
|
|
* Fix PIE options
We were missing passing the -pie linker option. That means that while we
were compiling our code as position independent, the executables
(not shared libraries) were not marked as position independent and
ASLR was not applied to them. They were always loaded to fixed addresses.
This change adds the missing -pie option and also replaces all the individual
settings of -fPIE / -fPIC on the targets we build by a centralized setting
of CMAKE_POSITION_INDEPENDENT_CODE variable that causes cmake to add the
appropriate compiler options everywhere.
* Fix native parts of coreclr tests build
The native parts of the tests are not built using the root CMakeLists.txt
so I am moving enabling the position independent code to configurecompiler.cmake
Change-Id: Ieafff8984ec23e5fdb00fb0c2fb017e53afbce88
|
|
Check for `lvLRACandidate` instead of `!lvDoNotEnregister` when checking whether `this` may be enregistered and has an Interval.
|
|
|
|
* Fail to explicitly tail call on x86 unix.
* Correctly return 100
* Correct return value
* Add noway assert in morphTailCall to avoid morphing slow tail calls on unix.
* Address feedback
|
|
This is the fix for #27924. This is a GC hole bug that was found externally, #27590.
The cause is that the JIT was using the target type of the subtract when it needed
to make a copy of the source, but it needs to use the source type.
## Customer Impact
Corruption of state that is non-deterministic and hard to track down.
## Regression?
Not a recent regression, but exposed by Unsafe.ByteOffset.
## Testing
The fix has been verified in the runtime repo.
## Risk
Low: The fix is straightfoward and only impacts 3 lines of code.
|
|
|
|
* Port PR #258 to 3.1
* Fix test proj file
|
|
* Port the 5.0 fix for issue #1104 3.1
- Pull Request Runtime\#1734
- This change corrects a cut-and paste typo with a previous commit.
- Includes test case Runtime_1104.cs
* Updated the csproj to use 3.1 syntax
|
|
* [release/3.1] Port fix for JIT silent bad code
Release/3.1 port of https://github.com/dotnet/runtime/pull/797.
Fixes https://github.com/dotnet/runtime/issues/764
The jit might incorrectly order a read from a struct field with an operation
that modifies the field, so that the read returns the wrong value.
Silent bad code; program behaves incorrectly.
Yes, introduced in the 3.0 cycle.
Verified the user's test case now passes; no diffs seen in any existing framework
or test code.
**Low**: the jit is now spilling the eval stack entries to temps in cases where it
did not before; this should be conservatively safe.
cc: @brucefo
____
If we're appending an assignment whose LHS is is a location within a local
struct, we need to spill all references to that struct from the eval stack.
Update the existing logic for this to handle the case where the LHS is a field
of a local struct, and the field is updated by unusual means (here, `initobj`).
Fixes dotnet/runtime#764.
* Fix test
|
|
Fix for #27923
The jit might fail to locate a class handle for a ref class, leading to an
unexpected crash while jitting.
## Customer Impact
Unexpected and hard to diagnose crash/exception
## Regression?
Yes, introduced during the development 3.0 cycle. 2.x behaves correctly.
## Testing
Verified the user's test case now passes; no diffs seen in any existing
framework or test code.
## Risk
**Low**: the jit will now fall back to using the handle for System.Object if no
better option can be found.
cc @BruceForstall
____
In some cases we may end up in lvaSetClass without a valid ref class handle
from either the IR or the stack. Use the handle for object as a conservative
fallback.
|
|
vararg methods (#27963)
* This is a point fix for not allowing fast tail calls on windows arm64
This only affects windows arm and arm64.
* Fix build break
|
|
* Correctly handle variable argument SIMDScalar
Fix #26286
|
|
that the intrinsic and managed form are deterministic. (#26017)
* Updating Math.Round and MathF.Round to be IEEE compliant so that the intrinsic and managed form are deterministic. (#25901)
* Updating Math.Round and MathF.Round to be IEEE compliant so that the intrinsic and managed form are deterministic.
* Fixing the Math.Round and MathF.Round handling for values greater than 0.5 and less than 1.0
* Applying formatting patch.
* Adding a comment about only having the roundToNearestTiesToEven code path
|
|
before the SIMDScalar handling. (#25905) (#25987)
* Ensure that we check for implicit ivals for single argument intrinsics before the SIMDScalar handling.
* Adding test template entries for the unary overloads of the Sse41.Round functions
* Regenerating the hardware intrinsic test templates.
|
|
* Do not fast tail call if caller has multislot structs
* apply patch
* Address offline feedback
|
|
* Fix GS cookie check on ARM in functions with stackalloc
The GC cookie check was failing during GC stack walking on ARM for frames
of functions using stackalloc and pinvoke. The InlinedCallFrame stores
only the SP after the stackalloc adjustment and unwinder needs R9
that contains SP before the stackalloc to be able to unwind the frame
to get caller SP. The caller SP is used as a base for getting the GS
cookie address. We were incorrectly setting the R9 in the CONTEXT
to the same value as SP and so the unwinding was getting an incorrect
caller SP.
The fix is to store R9 in the InlinedCallFrame for ARM.
|
|
Fix #25433
|
|
On x86 we can always reach any IAT_PVALUE entry via a 32 bit indirect
jump, and proper handling of jmp epilogs depends on this. So check if the
target address is reachable in 32 bits, and if so, use the jmp [addr] form
on x86, and the jmp [rip + disp] form for x64.
Fixes #25345
Fixes #25346
Undoes the assertion change from #25302
Fixes #25286
|
|
CoreRT has an [actual field](https://github.com/dotnet/corert/blob/ba3ba929c88bd80ec5d4dd9cf6917471ad8fa180/src/System.Private.CoreLib/src/System/Object.CoreRT.cs#L30) for the method table table pointer in `System.Object`. CoreCLR does shenanigans when laying out `System.Object` to leave a pointer-sized hole instead.
I think the zero-offset field is triggering these asserts.
|
|
|
|
Fix Issue #25134 - AssertionProp incorrectly removes cast from uint
|
|
* WorkAround for #25050.
A temporary workaround to push the milestone for this issue to 3.next.
* Response review.
|
|
With the advent of #25251 we can now see the epilog exit sequence on x86 vary
by as much as 6 bytes. Update the assert accordingly.
Fixes #25301.
|
|
If we are jumping to another method via an indirection cell, the cell address
may be too far from the jump to address via a RIP-relative indirection. So
instead, load the target address into RAX and jump register indirect.
Fixes #22342.
|
|
* Restrict copyprop if address-taken
Fix #25231
|
|
Add additional check for the GT_UNSIGNED flag
+ Ran clang-format
+ Code review feedback, use IsUnsigned()
|
|
* Fix contained LEA handling
This adds an LEA case to both `LinearScan::BuildOperandUses` and `CodeGen::genConsumeRegs`.
Fix #25039
|
|
* Add comments for _idCodeSize and a few asserts.
* Delete emitSizeOfJump.
* Delete emitInstCodeSz.
* Response review.
|
|
(#20900)
Fix an issue that is reproduced when:
1) a method requires GSSecurityCookie (e.g. when allocating unsafe buffer using localloc) and
2) one of the method parameters is "vulnerable" and requires a shadow variable to be created and used instead of the original parameter variable and
3) the method parameter has small signed integer type (i.e. int8 or int16) and
4) the value of the parameter is converted to unsigned type (e.g. uint8 or uint16).
|
|
Fix #25133
|
|
* SuperPMI: Fix `getFieldType`
The `structType` out parameter is optional (i.e. it may be null), but it's not used as a key, so we need to update the map if we've saved a null but encounter a non-null.
|
|
If a call site fails tail call stress validation, don't consider it for
implicit tail calling either.
In normal jitting we defer this level of validation until impImportCall
to avoid duplicating work.
This avoids an assert when we have invalid IL.
Fixes #25027.
|
|
Compile JIT sources with /W4
|
|
A blr instruction may have a result that is not a pointer size, but its target register is always EA_PTRSIZE.
Fix #24940
|
|
* Marking Vector128<T>.Count and Vector256<T>.Count as [Intrinsic]
* Fixing NI_Vector128_Count and NI_Vector256_Count to use clsHnd when getting the simdSize and baseType
* Applying the formatting patch.
* Changing some comments to just be "vector element count".
* Fixing impBaseIntrinsic to set the baseType so Vector128_Count and Vector256_Count don't return nullptr
|
|
csc.exe ourselves. (#24342)
* Use CMake's C# support to build DacTableGen instead of manually invoking csc.exe ourselves.
* Fix x86 failures.
* Disable DAC generation when building with NMake Makefiles and issue an error since the CMake C# support is VS-only. We don't actually support building with NMake (only configure) so this is ok.
* Clean up rest of the macro=1's
PR Feedback.
* Fix Visual Studio generator matching.
* Explicitly specify anycpu32bitpreferred for DacTableGen so the ARM64 build doesn't accidentally make it 64-bit
* Fix bad merge
|
|
Fix an issue that is reproduced when
1) a register is used in the prolog for initializing GSSecurityCookie (i.e. the register contains a random non-zero value) and
2) the same register holds a must-init GC variable in the next basic block and
3) the variable is live at the beginning of this basic block.
The register was not zeroed at the end of the prolog and this was causing segmentation fault during GC.Collect().
|
|
* Cleanup block stores and test for 24846
Fix zero-length assert/bad codegen for initblk.
Remove redundant assertions in codegen and those that don't directly relate to codegen requirements.
Eliminate redundant LEA that was being generated by `genCodeForCpBlk`.
Rename `genCodeFor[Cp|Init]Blk` to `genCodeFor[Cp|Init]BlkHelper` to parallel the other forms.
Fix the test case for #24846.
|
|
* Convert C++ standard settings and warning options from CMAKE_<LANG>_FLAGS to Modern CMake isms.
* More $<COMPILE_LANGUAGE> generator expressions instead of CMAKE_CXX_FLAGS.
* Use $<COMPILE_LANGUAGE:CXX> for all -fpermissive usage
* Fix generator expression that generates multiple flags
* Fix invalid use of CMAKE_CXX_FLAGS instead of CMAKE_C_FLAGS.
* Treat AppleClang as though it is Clang (match pre-3.0 behavior).
* Update our build system to understand that AppleClang is distinct from Clang and remove CMP0025 policy setting.
* PR Feedback.
|
|
* Fix MEASURE_NODE_SIZE and naming mistakes.
* The additional fields were deleted in #14582 (~1.5 years ago).
* Fix GT_INDEX_ADDR def.
We created them as `new (this, GT_INDEX_ADDR) GenTreeIndexAddr` but used smaller `GenTreeIndex` as nessecary size.
* Use LargeOpOpcode instead of GT_CALL.
|
|
the Sse41 class (#24886)
* Removing the TestAllOnes, TestAllZeros, and TestMixOnesZeros methods from the Sse41 class
* Removing JIT support for the SSE41_TestAllOnes, SSE41_TestAllZeros, and SSE41_TestMixOnesZeros intrinsics
* Removing tests for the Sse41.TestAllOnes, Sse41.TestAllZeros, and Sse41.TestMixOnesZeros methods
|
|
|
|
Fix #24846
|
|
Fixes for building the Desktop JIT in CodegenMirror
|
|
|
|
Synchronized methods show up when `Console` is used and the missing helper mapping would cause us not to AOT compile them.
|
|
* fix compilation with gcc7.x
In file included from src/inc/sstring.h:1029:0,
from src/inc/ex.h:19,
from src/inc/stgpool.h:28,
from src/inc/../md/inc/metamodel.h:18,
from src/inc/../md/inc/metamodelro.h:19,
from src/inc/metadata.h:17,
from src/inc/corpriv.h:21,
from src/md/compiler/stdafx.h:20,
from src/md/compiler/mdutil.cpp:12:
src/inc/sstring.inl: In member function ‘const WCHAR* SString::GetUnicode() const’:
src/inc/sstring.inl:650:5: error: nonnull argument ‘this’ compared to NULL [-Werror=nonnull-compare]
if (this == NULL)
^~
add version check
* Use the abstracted version of __nodebug__
* cc1: warning: command line option ‘-fpermissive’ is valid for C++/ObjC++ but not for C
|
|
* Avoid using ins_Load/ins_Store with constant type
* Use ldr to load array lengths/lower bounds
genCodeForArrIndex and genCodeForArrOffset emit a ldrsw on ARM64 but that's not necessary. Array lengths are always positive. Lower bounds are signed but then the subsequent subtract is anyway EA_4BYTE so sign extension isn't actually needed. Just use ldr on both ARM32 and ARM64.
* Use ldr to load array length (part 2)
genCodeForIndexAddr's range check generation is messed up:
- It uses ldrsw to load array length on ARM64. Not needed, the length is positive.
- It uses sxtw to sign etxend the array length if the index is native int. But it was already extended by the load.
- It creates IND and LEA nodes out of thin air. Just call the appropiate emitter functions.
- It always generates a TYP_I_IMPL cmp, even when the index is TYP_INT. Well, that's just bogus.
* Stop the using the instruction size for immediate scaling on ARM32
The scaling of immediate operands is a property of the instruction and its encoding. It doesnt' make sense to throw the instruction size (emitAttr) into the mix, that's a codegen/emitter specific concept. On ARM32 it's also almost meaningless, at least in the case of integer types - all instructions are really EA_4BYTE, even ldrb, ldrh etc.
The ARM64 emitter already extracts the scaling factor from the instruction. It can't use the instruction size as on ARM64 the size is used to select between 32 bit and 64 bit instructions so it's never EA_1BYTE/EA_2BYTE.
* Stop using ldrsw for TYP_INT loads
ARM64's ins_Load returns INS_ldrsw for TYP_INT but there's nothing in the JIT type system that requires sign extending TYP_INT values on load. The fact that an indir node has TYP_INT doesn't even imply that the value to load is signed, it may be unsigned and indir nodes will never have type TYP_UINT nor have the GTF_UNSIGNED flag set.
XARCH uses a mov (rather than movsxd, the equivalent of ldrsw) so it zero extends. There's no reason for ARM64 to behave differently and doing so makes it more difficult to share codegen logic between XARCH and ARM64
Other ARM64 compilers also use ldr rather than ldrsw.
This requires patching up emitInsAdjustLoadStoreAttr so EA_4BYTE loads don't end up using EA_8BYTE, which ldrsw requires.
* Cleanup genCodeForIndir/genCodeForStoreInd
In particular, cleanup selection of acquire/release instructions. The existing code starts by selecting a "normal" instruction, only to throw it away and redo the type/size logic in the volatile case. And get it wrong in the process, it required that "targetType" be TYP_UINT or TYP_LONG to use ldar. But there are no TYP_UINT indirs.
Also rename "targetType" to "type", using "target" is misleading. The real target type would be genActualType(tree->TypeGet()).
* Remove ARM32/64 load/store instruction size inconsistencies
- Require EA_4BYTE for byte/halfword instructions on ARM32.
- Remove emitInsAdjustLoadStoreAttr on ARM64. Getting the correct instruction size simply requires using emitActualTypeSize, that will provide the correct size on both ARM32 and ARM64.
- Replace emitTypeSize with emitActualTypeSize as needed.
* Remove unnecessary insUnscaleImm parameter
|
