This repository has been archived by the owner on Jan 23, 2023. It is now read-only.
Fix mscorlib warnings. #20
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
PinnableBufferCache uses some of the declaritive CAS attributes which don't mean anything on CoreCLR. We had disabled this warning internally, but this copy of the file is specific to open source and we didn't disable it in this file. This simply ports the change to disable this warning to mscorlib's copy of the file.
|
LGTM |
leemgs
added a commit
to leemgs/coreclr
that referenced
this pull request
Jul 9, 2016
…ccess on O3 This patch is to resolve bus errors in case of the O3 of clang (issue #5844). When we enable the -O2/-O3 optimization levels of the clang language (from clang 3.5 to latest version that was released on Jun-13-2016), we have got the +3000 BUS Errors from the coreCLR's unit tests. We can easily monitor SIGBUS signals (e.g., "misaligned memory access") with /proc/cpu/alignment facility of kernel-space. Using "echo 2 > /proc/cpu/alignment" makes Linux kernel fixes theproblems but the performance of the application will be degraded. * source: http://lxr.free-electrons.com/source/Documentation/arm/mem_alignment According to ARM information center(infocenter.arm.com), By default, the ARM compiler expects normal C and C++ pointers to point to an aligned word in memory. A type qualifier __packed is provided to enable unaligned pointer access. If you want to define a pointer to a word that can be at any address (that is, that can be at a non-natural alignment), you must specify this using the __packed qualifier when defining the pointer: __packed int *pi; // pointer to unaligned int However, clang/llvm does not support the __packed qualifier such as __attribute__((packed)) or __attribute__((packed, aligned(4))) In -O0 (debugging) the innermost block is emitted as the following assembly, which works properly: ldr r1, [r0, dotnet#24] ldr r2, [r0, dotnet#20] In -O2 (release) however the compiler realizes these fields are adjacent and generates this assembly: ldrdeq r2, r3, [r0, dotnet#20] Unfortunately ldrdb instruction always generates an alignment fault (in practice). It seems that clang uses ldrb instructions algthough Gcc uses ldr because armv7 supports unalign ldr instruction. Basically, RISC-based ARM architecture requires aligned access with 4byte reads. So, let's use memcpy(2) in into a properly aligned buffer instead of the packing attribute. Note: If architecture (e.g., linux/arm emulator) does not support unaligned ldr, this issue will be not generated with -O2/-O3 optimization levels. * source: Indicating unaligned access to Clang for ARM compatibility http://stackoverflow.com/questions/9185811/indicating-unaligned-access-to-clang-for-arm-compatibility * source: How does the ARM Compiler support unaligned accesses? http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka15414.html Signed-off-by: Geunsik Lim <geunsik.lim@samsung.com>
leemgs
added a commit
to leemgs/coreclr
that referenced
this pull request
Jul 11, 2016
This patch is to resolve bus errors in case of the O3 of clang (issue #5844). Note that we cannot use malloc library call "clib deprecates" of ./src/inc/clrhost.h. When we enable the -O2/-O3 optimization levels of the clang language (from clang 3.5 to latest version that was released on Jun-13-2016), we have got the +3000 BUS Errors from the coreCLR's unit tests. We can easily monitor SIGBUS signals (e.g., "misaligned memory access") with /proc/cpu/alignment facility of kernel-space. Using "echo 2 > /proc/cpu/alignment" makes Linux kernel fixes theproblems but the performance of the application will be degraded. * source: http://lxr.free-electrons.com/source/Documentation/arm/mem_alignment According to ARM information center(infocenter.arm.com), By default, the ARM compiler expects normal C and C++ pointers to point to an aligned word in memory. A type qualifier __packed is provided to enable unaligned pointer access. If you want to define a pointer to a word that can be at any address (that is, that can be at a non-natural alignment), you must specify this using the __packed qualifier when defining the pointer: __packed int *pi; // pointer to unaligned int However, clang/llvm does not support the __packed qualifier such as __attribute__((packed)) or __attribute__((packed, aligned(4))) In -O0 (debugging) the innermost block is emitted as the following assembly, which works properly: ldr r1, [r0, dotnet#24] ldr r2, [r0, dotnet#20] In -O2 (release) however the compiler realizes these fields are adjacent and generates this assembly: ldrdeq r2, r3, [r0, dotnet#20] Unfortunately ldrdb instruction always generates an alignment fault (in practice). It seems that clang uses ldrb instructions algthough Gcc uses ldr because armv7 supports unalign ldr instruction. Basically, RISC-based ARM architecture requires aligned access with 4byte reads. So, let's use memcpy(2) in into a properly aligned buffer instead of the packing attribute. Note: If architecture (e.g., linux/arm emulator) does not support unaligned ldr, this issue will be not generated with -O2/-O3 optimization levels. * source: Indicating unaligned access to Clang for ARM compatibility http://stackoverflow.com/questions/9185811/indicating-unaligned-access-to-clang-for-arm-compatibility * source: How does the ARM Compiler support unaligned accesses? http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka15414.html Signed-off-by: Geunsik Lim <geunsik.lim@samsung.com>
leemgs
added a commit
to leemgs/coreclr
that referenced
this pull request
Jul 13, 2016
…on O3 This patch is to resolve bus errors in case of the O3 of clang (issue # 5 8 4 4). When we enable the -O2/-O3 optimization levels of the clang language (from clang 3.5 to latest version that was released on Jun-13-2016), we have got the +3000 BUS Errors from the coreCLR's unit tests. We can easily monitor SIGBUS signals (e.g., "misaligned memory access") with /proc/cpu/alignment facility of kernel-space. Using "echo 2 > /proc/cpu/alignment" makes Linux kernel fixes the problems but the performance of the application will be degraded. * source: http://lxr.free-electrons.com/source/Documentation/arm/mem_alignment According to ARM information center(infocenter.arm.com), By default, the ARM compiler expects normal C and C++ pointers to point to an aligned word in memory. A type qualifier __packed is provided to enable unaligned pointer access. If you want to define a pointer to a word that can be at any address (that is, that can be at a non-natural alignment), you must specify this using the __packed qualifier when defining the pointer: __packed int *pi; // pointer to unaligned int However, clang/llvm does not support the __packed qualifier such as __attribute__((packed)) or __attribute__((packed, aligned(4))) In -O0 (debugging) the innermost block is emitted as the following assembly, which works properly: ldr r1, [r0, dotnet#24] ldr r2, [r0, dotnet#20] In -O2 (release) however the compiler realizes these fields are adjacent and generates this assembly: ldrdeq r2, r3, [r0, dotnet#20] Unfortunately ldrdb instruction always generates an alignment fault (in practice). It seems that clang uses ldrb instructions although Gcc uses ldr because armv7 supports unalign ldr instruction. Basically, RISC-based ARM architecture requires aligned access with 4byte reads. So, let's use memcpy(2) in into a properly aligned buffer instead of the packing attribute. Note: If architecture (e.g., Linux/ARM Emulator) does not support unaligned ldr, this issue will be not generated with -O2/-O3 optimization levels. * source: Indicating unaligned access to Clang for ARM compatibility http://stackoverflow.com/questions/9185811/indicating-unaligned-access-to-clang-for-arm-compatibility * source: How does the ARM Compiler support unaligned accesses? http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka15414.html Signed-off-by: Geunsik Lim <geunsik.lim@samsung.com>
leemgs
added a commit
to leemgs/coreclr
that referenced
this pull request
Jul 13, 2016
This patch is to resolve 3800+ bus errors with attribute keyword in case of the O3 optimization level of clang (issue # 5 8 4 4 ). When we enable the -O3 optimization level of the clang version(from clang 3.5 to clang 3.9(snapshot)), we have always got the +3000 BUS Errors from the coreCLR's unit tests. We can easily monitor SIGBUS signals (e.g., "misaligned memory access") with /proc/cpu/alignment facility in kernel-space. Using "echo 2 > /proc/cpu/alignment" makes Linux kernel fixes the problems but the performance of the application will be degraded. * source: http://lxr.free-electrons.com/source/Documentation/arm/mem_alignment According to ARM information center(infocenter.arm.com), By default, the ARM compiler expects normal C and C++ pointers to point to an aligned word in memory. A type qualifier __packed is provided to enable unaligned pointer access. If you want to define a pointer to a word that can be at any address (that is, that can be at a non-natural alignment), you must specify this using the __packed qualifier when defining the pointer: __packed int *pi; // pointer to unaligned int However, clang/llvm does not support the __packed qualifier such as __attribute__((packed)) or __attribute__((packed, aligned(4))) In -O0 (debugging) the innermost block is emitted as the following assembly, which works properly: ldr r1, [r0, dotnet#24] ldr r2, [r0, dotnet#20] In -O3 (release) however the compiler realizes these fields are adjacent and generates this assembly: ldrdeq r2, r3, [r0, dotnet#20] Unfortunately vldr/ldrdb instructions always generate an alignment fault (in practice). It seems that clang uses ldrb instruction although GCC uses ldr instruction because armv7 supports unaligned ldr instruction. Basically, RISC-based ARM architecture requires aligned access with 4byte reads. So,in order to enable aggressive optimization level such as O3, let's use attribute keword using aligned()of 1 byte instead of using memcpy(2) in into a properly aligned buffer or the packing attribute. Note: If arm architecture (e.g., Linux/ARM Emulator) does not support unaligned ldr, this issue will not be generated with -O3 optimization level. * source: How does the ARM Compiler support unaligned accesses? http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka15414.html Signed-off-by: Geunsik Lim <geunsik.lim@samsung.com>
leemgs
added a commit
to leemgs/coreclr
that referenced
this pull request
Jul 19, 2016
**PROBLEM** This patch is to resolve +3000 bus errors that are generated whenever we use the aggressive optimization levels of clang (issue # 5 8 4 4 ). When we enable the -O3 optimization level of the clang version(from clang 3.5 to clang 3.9(snapshot)), we have always got the lots of bus errors from the coreCLR's unit tests. Actually, we can easily monitor SIGBUS signals (e.g., "misaligned memory access") with /proc/cpu/alignment facility in kernel space. Using "echo 2 > /proc/cpu/alignment" makes Linux kernel fixes the problems but the performance of the application will be degraded. .source: http://lxr.free-electrons.com/source/Documentation/arm/mem_alignment **VERSION 2** .Add UNALIGNED_ARM macro for handling ARM core specific optimisation levels. .Add RISC-based ARM core handling into the existing infra-structure of the platform adaptation layer (PAL) for aggressive optimization cases on Linux/ARM. **VERSION 1** Basically, RISC-based ARM architecture requires aligned access with 4byte reads. In order to support aggressive optimization levels such as O2/O3, let's use attribute keyword of aligned(1) instead of using memcpy(2) in into a properly aligned buffer or the packing attribute. **BACKGROUND** According to ARM information center(infocenter.arm.com), By default, the ARM compiler expects normal C and C++ pointers to point to an aligned word in memory. A type qualifier __packed is provided to enable unaligned pointer access. If you want to define a pointer to a word that can be at any address (that is, that can be at a non-natural alignment), you must specify this using the __packed qualifier when defining the pointer: __packed int *pi; // pointer to unaligned int However, clang/llvm does not support the __packed qualifier such as __attribute__((packed)) or __attribute__((packed, aligned(4))) In -O0 (debug build) the innermost block is emitted as the following assembly, which works properly: ldr r1, [r0, dotnet#24] ldr r2, [r0, dotnet#20] In -O3 (release build) however the compiler realizes these fields are adjacent and generates this assembly: ldrdeq r2, r3, [r0, dotnet#20] Unfortunately, vldr/ldrdb instructions always generate an alignment fault (in practice). It seems that clang uses ldrb instruction although GCC uses ldr instruction because armv7 supports unaligned ldr instruction. Note: If some arm architectures (e.g., Linux/ARM Emulator) does not support unaligned ldr, this issue is not generated with aggressive optimization levels (e.g., -O2 and -O3). * source: How does the ARM Compiler support unaligned accesses? http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka15414.html Signed-off-by: Geunsik Lim <geunsik.lim@samsung.com>
leemgs
added a commit
to leemgs/coreclr
that referenced
this pull request
Jul 21, 2016
This patch is to resolve bus errors in case of the O3 of clang (issue # 5 8 4 4). When we enable the -O2/-O3 optimization levels of the clang language (from clang 3.5 to latest version that was released on Jun-13-2016), we have got the +3000 BUS Errors from the coreCLR's unit tests. We can easily monitor SIGBUS signals (e.g., "misaligned memory access") with /proc/cpu/alignment facility of kernel-space. Using "echo 2 > /proc/cpu/alignment" makes Linux kernel fixes the problems but the performance of the application will be degraded. * source: http://lxr.free-electrons.com/source/Documentation/arm/mem_alignment According to ARM information center(infocenter.arm.com), By default, the ARM compiler expects normal C and C++ pointers to point to an aligned word in memory. A type qualifier __packed is provided to enable unaligned pointer access. If you want to define a pointer to a word that can be at any address (that is, that can be at a non-natural alignment), you must specify this using the __packed qualifier when defining the pointer: __packed int *pi; // pointer to unaligned int However, clang/llvm does not support the __packed qualifier such as __attribute__((packed)) or __attribute__((packed, aligned(4))) In -O0 (debugging) the innermost block is emitted as the following assembly, which works properly: ldr r1, [r0, dotnet#24] ldr r2, [r0, dotnet#20] In -O2 (release) however the compiler realizes these fields are adjacent and generates this assembly: ldrdeq r2, r3, [r0, dotnet#20] Unfortunately ldrdb instruction always generates an alignment fault (in practice). It seems that clang uses ldrb instructions although Gcc uses ldr because armv7 supports unalign ldr instruction. Basically, RISC-based ARM architecture requires aligned access with 4byte reads. So, let's use memcpy(2) in into a properly aligned buffer instead of the packing attribute. Note: If architecture (e.g., Linux/ARM Emulator) does not support unaligned ldr, this issue will be not generated with -O2/-O3 optimization levels. * source: Indicating unaligned access to Clang for ARM compatibility http://stackoverflow.com/questions/9185811/indicating-unaligned-access-to-clang-for-arm-compatibility * source: How does the ARM Compiler support unaligned accesses? http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka15414.html Signed-off-by: Geunsik Lim <geunsik.lim@samsung.com>
leemgs
added a commit
to leemgs/coreclr
that referenced
this pull request
Jul 21, 2016
**PROBLEM** This patch is to resolve +3000 bus errors that are generated whenever we use the aggressive optimization levels of clang (issue #5844 ). When we enable the -O3 optimization level of the clang version(from clang 3.5 to clang 3.9(snapshot)), we have always got the lots of bus errors from the coreCLR's unit tests. Actually, we can easily monitor SIGBUS signals (e.g., "misaligned memory access") with /proc/cpu/alignment facility in kernel space. Using "echo 2 > /proc/cpu/alignment" makes Linux kernel fixes the problems but the performance of the application will be degraded. .source: http://lxr.free-electrons.com/source/Documentation/arm/mem_alignment **VERSION 2** .Add UNALIGNED_ARM macro for handling ARM core specific optimisation levels. .Add RISC-based ARM core handling into the existing infra-structure of the platform adaptation layer (PAL) for aggressive optimization cases on Linux/ARM. **VERSION 1** Basically, RISC-based ARM architecture requires aligned access with 4byte reads. In order to support aggressive optimization levels such as O2/O3, let's use attribute keyword of aligned(1) instead of using memcpy(2) in into a properly aligned buffer or the packing attribute. **BACKGROUND** According to ARM information center(infocenter.arm.com), By default, the ARM compiler expects normal C and C++ pointers to point to an aligned word in memory. A type qualifier __packed is provided to enable unaligned pointer access. If you want to define a pointer to a word that can be at any address (that is, that can be at a non-natural alignment), you must specify this using the __packed qualifier when defining the pointer: __packed int *pi; // pointer to unaligned int However, clang/llvm does not support the __packed qualifier such as __attribute__((packed)) or __attribute__((packed, aligned(4))) In -O0 (debug build) the innermost block is emitted as the following assembly, which works properly: ldr r1, [r0, dotnet#24] ldr r2, [r0, dotnet#20] In -O3 (release build) however the compiler realizes these fields are adjacent and generates this assembly: ldrdeq r2, r3, [r0, dotnet#20] Unfortunately, vldr/ldrdb instructions always generate an alignment fault (in practice). It seems that clang uses ldrb instruction although GCC uses ldr instruction because armv7 supports unaligned ldr instruction. Note: If some arm architectures (e.g., Linux/ARM Emulator) does not support unaligned ldr, this issue is not generated with aggressive optimization levels (e.g., -O2 and -O3). * source: How does the ARM Compiler support unaligned accesses? http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka15414.html Signed-off-by: Geunsik Lim <geunsik.lim@samsung.com>
leemgs
added a commit
to leemgs/coreclr
that referenced
this pull request
Jul 21, 2016
**PROBLEM** This patch is to resolve +3000 bus errors that are generated whenever we use the aggressive optimization levels of clang (issue #5844 ). When we enable the -O3 optimization level of the clang version(from clang 3.5 to clang 3.9(snapshot)), we have always got the lots of bus errors from the coreCLR's unit tests. Actually, we can easily monitor SIGBUS signals (e.g., "misaligned memory access") with /proc/cpu/alignment facility in kernel space. Using "echo 2 > /proc/cpu/alignment" makes Linux kernel fixes the problems but the performance of the application will be degraded. .source: http://lxr.free-electrons.com/source/Documentation/arm/mem_alignment **VERSION 2** .Add UNALIGNED_ARM macro for handling ARM core specific optimisation levels. .Add RISC-based ARM core handling into the existing infra-structure of the platform adaptation layer (PAL) for aggressive optimization cases on Linux/ARM. **VERSION 1** Basically, RISC-based ARM architecture requires aligned access with 4byte reads. In order to support aggressive optimization levels such as O2/O3, let's use attribute keyword of aligned(1) instead of using memcpy(2) in into a properly aligned buffer or the packing attribute. **BACKGROUND** According to ARM information center(infocenter.arm.com), By default, the ARM compiler expects normal C and C++ pointers to point to an aligned word in memory. A type qualifier __packed is provided to enable unaligned pointer access. If you want to define a pointer to a word that can be at any address (that is, that can be at a non-natural alignment), you must specify this using the __packed qualifier when defining the pointer: __packed int *pi; // pointer to unaligned int However, clang/llvm does not support the __packed qualifier such as __attribute__((packed)) or __attribute__((packed, aligned(4))) In -O0 (debug build) the innermost block is emitted as the following assembly, which works properly: ldr r1, [r0, dotnet#24] ldr r2, [r0, dotnet#20] In -O3 (release build) however the compiler realizes these fields are adjacent and generates this assembly: ldrdeq r2, r3, [r0, dotnet#20] Unfortunately, vldr/ldrdb instructions always generate an alignment fault (in practice). It seems that clang uses ldrb instruction although GCC uses ldr instruction because armv7 supports unaligned ldr instruction. Note: If some arm architectures (e.g., Linux/ARM Emulator) does not support unaligned ldr, this issue is not generated with aggressive optimization levels (e.g., -O2 and -O3). * source: How does the ARM Compiler support unaligned accesses? http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka15414.html Signed-off-by: Geunsik Lim <geunsik.lim@samsung.com>
leemgs
added a commit
to leemgs/coreclr
that referenced
this pull request
Jul 21, 2016
This patch is to resolve bus errors in case of the O3 of clang (issue # 5 8 4 4). When we enable the -O2/-O3 optimization levels of the clang language (from clang 3.5 to latest version that was released on Jun-13-2016), we have got the +3000 BUS Errors from the coreCLR's unit tests. We can easily monitor SIGBUS signals (e.g., "misaligned memory access") with /proc/cpu/alignment facility of kernel-space. Using "echo 2 > /proc/cpu/alignment" makes Linux kernel fixes the problems but the performance of the application will be degraded. * source: http://lxr.free-electrons.com/source/Documentation/arm/mem_alignment According to ARM information center(infocenter.arm.com), By default, the ARM compiler expects normal C and C++ pointers to point to an aligned word in memory. A type qualifier __packed is provided to enable unaligned pointer access. If you want to define a pointer to a word that can be at any address (that is, that can be at a non-natural alignment), you must specify this using the __packed qualifier when defining the pointer: __packed int *pi; // pointer to unaligned int However, clang/llvm does not support the __packed qualifier such as __attribute__((packed)) or __attribute__((packed, aligned(4))) In -O0 (debugging) the innermost block is emitted as the following assembly, which works properly: ldr r1, [r0, dotnet#24] ldr r2, [r0, dotnet#20] In -O2 (release) however the compiler realizes these fields are adjacent and generates this assembly: ldrdeq r2, r3, [r0, dotnet#20] Unfortunately ldrdb instruction always generates an alignment fault (in practice). It seems that clang uses ldrb instructions although Gcc uses ldr because armv7 supports unalign ldr instruction. Basically, RISC-based ARM architecture requires aligned access with 4byte reads. So, let's use memcpy(2) in into a properly aligned buffer instead of the packing attribute. Note: If architecture (e.g., Linux/ARM Emulator) does not support unaligned ldr, this issue will be not generated with -O2/-O3 optimization levels. * Case study: How does the ARM Compiler support unaligned accesses? http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka15414.html * Case study: Indicating unaligned access to Clang for ARM compatibility http://stackoverflow.com/questions/9185811/indicating-unaligned-access-to-clang-for-arm-compatibility * Case study: Chromium source for UnalignedLoad32() on ARM https://github.com/nwjs/chromium.src/blob/nw15/third_party/cld/base/basictypes.h#L302 Signed-off-by: Geunsik Lim <geunsik.lim@samsung.com>
leemgs
added a commit
to leemgs/coreclr
that referenced
this pull request
Jul 22, 2016
**PROBLEM** This patch is to resolve +3000 bus errors that are generated whenever we use the aggressive optimization levels of clang (issue #5844 ). When we enable the -O3 optimization level of the clang version(from clang 3.5 to clang 3.9(snapshot)), we have always got the lots of bus errors from the coreCLR's unit tests. Actually, we can easily monitor SIGBUS signals (e.g., "misaligned memory access") with /proc/cpu/alignment facility in kernel space. Using "echo 2 > /proc/cpu/alignment" makes Linux kernel fixes the problems but the performance of the application will be degraded. .source: http://lxr.free-electrons.com/source/Documentation/arm/mem_alignment **VERSION 3** .Apply this PR on only Linux/ARM for different system environment (Windows). Here is .NET CI Report on Windows: Compile Error error C2146: syntax error: missing ';' before identifier '__unaligned_int32' (compiling source file D:\j\workspace\checked_windo---f6dc6fe4\src\jit\alloc.cpp) [D:\j\workspace\checked_windo---f6dc6fe4\bin\obj\Windows_NT.x64.Checked\src\jit\crossgen\clrjit_crossgen.vcxproj] Indication 1 **VERSION 2** .Add UNALIGNED_ARM macro for handling ARM core specific optimisation levels. .Add RISC-based ARM core handling into the existing infra-structure of the platform adaptation layer (PAL) for aggressive optimization cases on Linux/ARM. **VERSION 1** Basically, RISC-based ARM architecture requires aligned access with 4byte reads. In order to support aggressive optimization levels such as O2/O3, let's use attribute keyword of aligned(1) instead of using memcpy(2) in into a properly aligned buffer or the packing attribute. **BACKGROUND** According to ARM information center(infocenter.arm.com), By default, the ARM compiler expects normal C and C++ pointers to point to an aligned word in memory. A type qualifier __packed is provided to enable unaligned pointer access. If you want to define a pointer to a word that can be at any address (that is, that can be at a non-natural alignment), you must specify this using the __packed qualifier when defining the pointer: __packed int *pi; // pointer to unaligned int However, clang/llvm does not support the __packed qualifier such as __attribute__((packed)) or __attribute__((packed, aligned(4))) In -O0 (debug build) the innermost block is emitted as the following assembly, which works properly: ldr r1, [r0, dotnet#24] ldr r2, [r0, dotnet#20] In -O3 (release build) however the compiler realizes these fields are adjacent and generates this assembly: ldrdeq r2, r3, [r0, dotnet#20] Unfortunately, vldr/ldrdb instructions always generate an alignment fault (in practice). It seems that clang uses ldrb instruction although GCC uses ldr instruction because armv7 supports unaligned ldr instruction. Note: If some arm architectures (e.g., Linux/ARM Emulator) does not support unaligned ldr, this issue is not generated with aggressive optimization levels (e.g., -O2 and -O3). * source: How does the ARM Compiler support unaligned accesses? http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka15414.html Signed-off-by: Geunsik Lim <geunsik.lim@samsung.com>
leemgs
added a commit
to leemgs/coreclr
that referenced
this pull request
Jul 22, 2016
**PROBLEM** This patch is to resolve +3000 bus errors that are generated whenever we use the aggressive optimization levels of clang (issue #5844 ). When we enable the -O3 optimization level of the clang version(from clang 3.5 to clang 3.9(snapshot)), we have always got the lots of bus errors from the coreCLR's unit tests. Actually, we can easily monitor SIGBUS signals (e.g., "misaligned memory access") with /proc/cpu/alignment facility in kernel space. Using "echo 2 > /proc/cpu/alignment" makes Linux kernel fixes the problems but the performance of the application will be degraded. .source: http://lxr.free-electrons.com/source/Documentation/arm/mem_alignment **VERSION 3** .Apply this PR on only Linux/ARM for different system environment (Windows). Here is .NET CI Report on Windows: Compile Error error C2146: syntax error: missing ';' before identifier '__unaligned_int32' (compiling source file D:\j\workspace\checked_windo---f6dc6fe4\src\jit\alloc.cpp) [D:\j\workspace\checked_windo---f6dc6fe4\bin\obj\Windows_NT.x64.Checked\src\jit\ crossgen\clrjit_crossgen.vcxproj] Indication 1 **VERSION 2** .Add UNALIGNED_ARM macro for handling ARM core specific optimisation levels. .Add RISC-based ARM core handling into the existing infra-structure of the platform adaptation layer (PAL) for aggressive optimization cases on Linux/ARM. **VERSION 1** Basically, RISC-based ARM architecture requires aligned access with 4byte reads. In order to support aggressive optimization levels such as O2/O3, let's use attribute keyword of aligned(1) instead of using memcpy(2) in into a properly aligned buffer or the packing attribute. **BACKGROUND** According to ARM information center(infocenter.arm.com), By default, the ARM compiler expects normal C and C++ pointers to point to an aligned word in memory. A type qualifier __packed is provided to enable unaligned pointer access. If you want to define a pointer to a word that can be at any address (that is, that can be at a non-natural alignment), you must specify this using the __packed qualifier when defining the pointer: __packed int *pi; // pointer to unaligned int However, clang/llvm does not support the __packed qualifier such as __attribute__((packed)) or __attribute__((packed, aligned(4))) In -O0 (debug build) the innermost block is emitted as the following assembly, which works properly: ldr r1, [r0, dotnet#24] ldr r2, [r0, dotnet#20] In -O3 (release build) however the compiler realizes these fields are adjacent and generates this assembly: ldrdeq r2, r3, [r0, dotnet#20] Unfortunately, vldr/ldrdb instructions always generate an alignment fault (in practice). It seems that clang uses ldrb instruction although GCC uses ldr instruction because armv7 supports unaligned ldr instruction. Note: If some arm architectures (e.g., Linux/ARM Emulator) does not support unaligned ldr, this issue is not generated with aggressive optimization levels (e.g., -O2 and -O3). * source: How does the ARM Compiler support unaligned accesses? http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka15414.html Signed-off-by: Geunsik Lim <geunsik.lim@samsung.com>
leemgs
added a commit
to leemgs/coreclr
that referenced
this pull request
Jul 25, 2016
**PROBLEM** This patch is to resolve +3000 bus errors that are generated whenever we use the aggressive optimization levels of clang (issue #5844 ). When we enable the -O3 optimization level of the clang version(from clang 3.5 to clang 3.9(snapshot)), we have always got the lots of bus errors from the coreCLR's unit tests. Actually, we can easily monitor SIGBUS signals (e.g., "misaligned memory access") with /proc/cpu/alignment facility in kernel space. Using "echo 2 > /proc/cpu/alignment" makes Linux kernel fixes the problems but the performance of the application will be degraded. .source: http://lxr.free-electrons.com/source/Documentation/arm/mem_alignment **VERSION 4:** . Use 'GET_UNALIGNED_VALXXX' macros in the CoreClr infra-structure without any need for ifdefs. **VERSION 3:** .Apply this PR on only Linux/ARM for different system environment (Windows). Here is .NET CI Report on Windows: Compile Error error C2146: syntax error: missing ';' before identifier '__unaligned_int32' (compiling source file D:\j\workspace\checked_windo---f6dc6fe4\src\jit\alloc.cpp) [D:\j\workspace\checked_windo---f6dc6fe4\bin\obj\Windows_NT.x64.Checked\src\jit\ crossgen\clrjit_crossgen.vcxproj] Indication 1 **VERSION 2:** .Add UNALIGNED_ARM macro for handling ARM core specific optimisation levels. .Add RISC-based ARM core handling into the existing infra-structure of the platform adaptation layer (PAL) for aggressive optimization cases on Linux/ARM. **VERSION 1:** Basically, RISC-based ARM architecture requires aligned access with 4byte reads. In order to support aggressive optimization levels such as O2/O3, let's use attribute keyword of aligned(1) instead of using memcpy(2) in into a properly aligned buffer or the packing attribute. **BACKGROUND** According to ARM information center(infocenter.arm.com), By default, the ARM compiler expects normal C and C++ pointers to point to an aligned word in memory. A type qualifier __packed is provided to enable unaligned pointer access. If you want to define a pointer to a word that can be at any address (that is, that can be at a non-natural alignment), you must specify this using the __packed qualifier when defining the pointer: __packed int *pi; // pointer to unaligned int However, clang/llvm does not support the __packed qualifier such as __attribute__((packed)) or __attribute__((packed, aligned(4))) In -O0 (debug build) the innermost block is emitted as the following assembly, which works properly: ldr r1, [r0, dotnet#24] ldr r2, [r0, dotnet#20] In -O3 (release build) however the compiler realizes these fields are adjacent and generates this assembly: ldrdeq r2, r3, [r0, dotnet#20] Unfortunately, vldr/ldrdb instructions always generate an alignment fault (in practice). It seems that clang uses ldrb instruction although GCC uses ldr instruction because armv7 supports unaligned ldr instruction. Note: If some arm architectures (e.g., Linux/ARM Emulator) does not support unaligned ldr, this issue is not generated with aggressive optimization levels (e.g., -O2 and -O3). * Case study: How does the ARM Compiler support unaligned accesses? http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka15414.html * Case study: Indicating unaligned access to Clang for ARM compatibility http://stackoverflow.com/questions/9185811/indicating-unaligned-access-to-clang-for-arm-compatibility * Case study: Chromium source for UnalignedLoad32() on ARM https://github.com/nwjs/chromium.src/blob/nw15/third_party/cld/base/basictypes.h#L302 Signed-off-by: Geunsik Lim <geunsik.lim@samsung.com>
leemgs
added a commit
to leemgs/coreclr
that referenced
this pull request
Jul 25, 2016
**PROBLEM** This patch is to resolve +3000 bus errors that are generated whenever we use the aggressive optimization levels of clang (issue #5844 ). When we enable the -O3 optimization level of the clang version(from clang 3.5 to clang 3.9(snapshot)), we have always got the lots of bus errors from the coreCLR's unit tests. Actually, we can easily monitor SIGBUS signals (e.g., "misaligned memory access") with /proc/cpu/alignment facility in kernel space. Using "echo 2 > /proc/cpu/alignment" makes Linux kernel fixes the problems but the performance of the application will be degraded. .source: http://lxr.free-electrons.com/source/Documentation/arm/mem_alignment **VERSION 4** . Use 'GET_UNALIGNED_VALXXX' macros in the CoreClr infra-structure without any need for ifdefs. **VERSION 3** .Apply this PR on only Linux/ARM for different system environment (Windows). Here is .NET CI Report on Windows: Compile Error error C2146: syntax error: missing ';' before identifier '__unaligned_int32' (compiling source file D:\j\workspace\checked_windo---f6dc6fe4\src\jit\alloc.cpp) [D:\j\workspace\checked_windo---f6dc6fe4\bin\obj\Windows_NT.x64.Checked\src\jit\ crossgen\clrjit_crossgen.vcxproj] Indication 1 **VERSION 2** .Add UNALIGNED_ARM macro for handling ARM core specific optimisation levels. .Add RISC-based ARM core handling into the existing infra-structure of the platform adaptation layer (PAL) for aggressive optimization cases on Linux/ARM. **VERSION 1** Basically, RISC-based ARM architecture requires aligned access with 4byte reads. In order to support aggressive optimization levels such as O2/O3, let's use attribute keyword of aligned(1) instead of using memcpy(2) in into a properly aligned buffer or the packing attribute. **BACKGROUND** According to ARM information center(infocenter.arm.com), By default, the ARM compiler expects normal C and C++ pointers to point to an aligned word in memory. A type qualifier __packed is provided to enable unaligned pointer access. If you want to define a pointer to a word that can be at any address (that is, that can be at a non-natural alignment), you must specify this using the __packed qualifier when defining the pointer: __packed int *pi; // pointer to unaligned int However, clang/llvm does not support the __packed qualifier such as __attribute__((packed)) or __attribute__((packed, aligned(4))) In -O0 (debug build) the innermost block is emitted as the following assembly, which works properly: ldr r1, [r0, dotnet#24] ldr r2, [r0, dotnet#20] In -O3 (release build) however the compiler realizes these fields are adjacent and generates this assembly: ldrdeq r2, r3, [r0, dotnet#20] Unfortunately, vldr/ldrdb instructions always generate an alignment fault (in practice). It seems that clang uses ldrb instruction although GCC uses ldr instruction because armv7 supports unaligned ldr instruction. Note: If some arm architectures (e.g., Linux/ARM Emulator) does not support unaligned ldr, this issue is not generated with aggressive optimization levels (e.g., -O2 and -O3). * Case study: How does the ARM Compiler support unaligned accesses? http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka15414.html * Case study: Indicating unaligned access to Clang for ARM compatibility http://stackoverflow.com/questions/9185811/indicating-unaligned-access-to-clang-for-arm-compatibility * Case study: Chromium source for UnalignedLoad32() on ARM https://github.com/nwjs/chromium.src/blob/nw15/third_party/cld/base/basictypes.h#L302 Signed-off-by: Geunsik Lim <geunsik.lim@samsung.com>
leemgs
added a commit
to leemgs/coreclr
that referenced
this pull request
Jul 25, 2016
**PROBLEM** This patch is to resolve +3000 bus errors that are generated whenever we use the aggressive optimization levels of clang (issue #5844 ). When we enable the -O3 optimization level of the clang version(from clang 3.5 to clang 3.9(snapshot)), we have always got the lots of bus errors from the coreCLR's unit tests. Actually, we can easily monitor SIGBUS signals (e.g., "misaligned memory access") with /proc/cpu/alignment facility in kernel space. Using "echo 2 > /proc/cpu/alignment" makes Linux kernel fixes the problems but the performance of the application will be degraded. .source: http://lxr.free-electrons.com/source/Documentation/arm/mem_alignment **VERSION 4** . Use 'GET_UNALIGNED_VALXXX' macros in the CoreClr infra-structure without any need for ifdefs. **VERSION 3** .Apply this PR on only Linux/ARM for different system environment (Windows). Here is .NET CI Report on Windows: Compile Error error C2146: syntax error: missing ';' before identifier '__unaligned_int32' (compiling source file D:\j\workspace\checked_windo---f6dc6fe4\src\jit\alloc.cpp) [D:\j\workspace\checked_windo---f6dc6fe4\bin\obj\Windows_NT.x64.Checked\src\jit\ crossgen\clrjit_crossgen.vcxproj] Indication 1 **VERSION 2** .Add UNALIGNED_ARM macro for handling ARM core specific optimization levels. .Add RISC-based ARM core handling into the existing infra-structure of the platform adaptation layer (PAL) for aggressive optimization cases on Linux/ARM. **VERSION 1** Basically, RISC-based ARM architecture requires aligned access with 4byte reads. In order to support aggressive optimization levels such as O2/O3, let's use attribute keyword of aligned(1) instead of using memcpy(2) in into a properly aligned buffer or the packing attribute. **BACKGROUND** According to ARM information center(infocenter.arm.com), By default, the ARM compiler expects normal C and C++ pointers to point to an aligned word in memory. A type qualifier __packed is provided to enable unaligned pointer access. If you want to define a pointer to a word that can be at any address (that is, that can be at a non-natural alignment), you must specify this using the __packed qualifier when defining the pointer: __packed int *pi; // pointer to unaligned int However, clang/llvm does not support the __packed qualifier such as __attribute__((packed)) or __attribute__((packed, aligned(4))) In -O0 (debug build) the innermost block is emitted as the following assembly, which works properly: ldr r1, [r0, dotnet#24] ldr r2, [r0, dotnet#20] In -O3 (release build) however the compiler realizes these fields are adjacent and generates this assembly: ldrdeq r2, r3, [r0, dotnet#20] Unfortunately, vldr/ldrdb instructions always generate an alignment fault (in practice). It seems that clang uses ldrb instruction although GCC uses ldr instruction because armv7 supports unaligned ldr instruction. Note: If some arm architectures (e.g., Linux/ARM Emulator) does not support unaligned ldr, this issue is not generated with aggressive optimization levels (e.g., -O2 and -O3). * Case study: How does the ARM Compiler support unaligned accesses? http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka15414.html * Case study: Indicating unaligned access to Clang for ARM compatibility http://stackoverflow.com/questions/9185811/indicating-unaligned-access-to-clang-for-arm-compatibility * Case study: Chromium source for UnalignedLoad32() on ARM https://github.com/nwjs/chromium.src/blob/nw15/third_party/cld/base/basictypes.h#L302 Signed-off-by: Geunsik Lim <geunsik.lim@samsung.com>
leemgs
added a commit
to leemgs/coreclr
that referenced
this pull request
Jul 25, 2016
**PROBLEM** This patch is to resolve +3000 bus errors that are generated whenever we use the aggressive optimization levels of clang (issue #5844 ). When we enable the -O3 optimization level of the clang version(from clang 3.5 to clang 3.9(snapshot)), we have always got the lots of bus errors from the coreCLR's unit tests. Actually, we can easily monitor SIGBUS signals (e.g., "misaligned memory access") with /proc/cpu/alignment facility in kernel space. Using "echo 2 > /proc/cpu/alignment" makes Linux kernel fixes the problems but the performance of the application will be degraded. .source: http://lxr.free-electrons.com/source/Documentation/arm/mem_alignment **VERSION 4** . Use 'GET_UNALIGNED_VALXXX' macros in the CoreClr infra-structure without any need for ifdefs. **VERSION 3** .Apply this PR on only Linux/ARM for different system environment (Windows). Here is .NET CI Report on Windows: Compile Error error C2146: syntax error: missing ';' before identifier '__unaligned_int32' (compiling source file D:\j\workspace\checked_windo---f6dc6fe4\src\jit\alloc.cpp) [D:\j\workspace\checked_windo---f6dc6fe4\bin\obj\Windows_NT.x64.Checked\src\jit\ crossgen\clrjit_crossgen.vcxproj] Indication 1 **VERSION 2** .Add UNALIGNED_ARM macro for handling ARM core specific optimization levels. .Add RISC-based ARM core handling into the existing infra-structure of the platform adaptation layer (PAL) for aggressive optimization cases on Linux/ARM. **VERSION 1** Basically, RISC-based ARM architecture requires aligned access with 4byte reads. In order to support aggressive optimization levels such as O2/O3, let's use attribute keyword of aligned(1) instead of using memcpy(2) in into a properly aligned buffer or the packing attribute. **BACKGROUND** According to ARM information center(infocenter.arm.com), By default, the ARM compiler expects normal C and C++ pointers to point to an aligned word in memory. A type qualifier __packed is provided to enable unaligned pointer access. If you want to define a pointer to a word that can be at any address (that is, that can be at a non-natural alignment), you must specify this using the __packed qualifier when defining the pointer: __packed int *pi; // pointer to unaligned int However, clang/llvm does not support the __packed qualifier such as __attribute__((packed)) or __attribute__((packed, aligned(4))) In -O0 (debug build) the innermost block is emitted as the following assembly, which works properly: ldr r1, [r0, dotnet#24] ldr r2, [r0, dotnet#20] In -O3 (release build) however the compiler realizes these fields are adjacent and generates this assembly: ldrdeq r2, r3, [r0, dotnet#20] Unfortunately, vldr/ldrdb instructions always generate an alignment fault (in practice). It seems that clang uses ldrb instruction although GCC uses ldr instruction because armv7 supports unaligned ldr instruction. Note: If some arm architectures (e.g., Linux/ARM Emulator) does not support unaligned ldr, this issue is not generated with aggressive optimization levels (e.g., -O2 and -O3). * Case study: How does the ARM Compiler support unaligned accesses? http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka15414.html * Case study: Indicating unaligned access to Clang for ARM compatibility http://stackoverflow.com/questions/9185811/indicating-unaligned-access-to-clang-for-arm-compatibility * Case study: Chromium source for UnalignedLoad32() on ARM https://github.com/nwjs/chromium.src/blob/nw15/third_party/cld/base/basictypes.h#L302 Signed-off-by: Geunsik Lim <geunsik.lim@samsung.com>
jkotas
pushed a commit
that referenced
this pull request
Jul 26, 2016
…6379) **PROBLEM** This patch is to resolve +3000 bus errors that are generated whenever we use the aggressive optimization levels of clang (issue #5844 ). When we enable the -O3 optimization level of the clang version(from clang 3.5 to clang 3.9(snapshot)), we have always got the lots of bus errors from the coreCLR's unit tests. Actually, we can easily monitor SIGBUS signals (e.g., "misaligned memory access") with /proc/cpu/alignment facility in kernel space. Using "echo 2 > /proc/cpu/alignment" makes Linux kernel fixes the problems but the performance of the application will be degraded. .source: http://lxr.free-electrons.com/source/Documentation/arm/mem_alignment **VERSION 4** . Use 'GET_UNALIGNED_VALXXX' macros in the CoreClr infra-structure without any need for ifdefs. **VERSION 3** .Apply this PR on only Linux/ARM for different system environment (Windows). Here is .NET CI Report on Windows: Compile Error error C2146: syntax error: missing ';' before identifier '__unaligned_int32' (compiling source file D:\j\workspace\checked_windo---f6dc6fe4\src\jit\alloc.cpp) [D:\j\workspace\checked_windo---f6dc6fe4\bin\obj\Windows_NT.x64.Checked\src\jit\ crossgen\clrjit_crossgen.vcxproj] Indication 1 **VERSION 2** .Add UNALIGNED_ARM macro for handling ARM core specific optimization levels. .Add RISC-based ARM core handling into the existing infra-structure of the platform adaptation layer (PAL) for aggressive optimization cases on Linux/ARM. **VERSION 1** Basically, RISC-based ARM architecture requires aligned access with 4byte reads. In order to support aggressive optimization levels such as O2/O3, let's use attribute keyword of aligned(1) instead of using memcpy(2) in into a properly aligned buffer or the packing attribute. **BACKGROUND** According to ARM information center(infocenter.arm.com), By default, the ARM compiler expects normal C and C++ pointers to point to an aligned word in memory. A type qualifier __packed is provided to enable unaligned pointer access. If you want to define a pointer to a word that can be at any address (that is, that can be at a non-natural alignment), you must specify this using the __packed qualifier when defining the pointer: __packed int *pi; // pointer to unaligned int However, clang/llvm does not support the __packed qualifier such as __attribute__((packed)) or __attribute__((packed, aligned(4))) In -O0 (debug build) the innermost block is emitted as the following assembly, which works properly: ldr r1, [r0, #24] ldr r2, [r0, #20] In -O3 (release build) however the compiler realizes these fields are adjacent and generates this assembly: ldrdeq r2, r3, [r0, #20] Unfortunately, vldr/ldrdb instructions always generate an alignment fault (in practice). It seems that clang uses ldrb instruction although GCC uses ldr instruction because armv7 supports unaligned ldr instruction. Note: If some arm architectures (e.g., Linux/ARM Emulator) does not support unaligned ldr, this issue is not generated with aggressive optimization levels (e.g., -O2 and -O3). * Case study: How does the ARM Compiler support unaligned accesses? http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka15414.html * Case study: Indicating unaligned access to Clang for ARM compatibility http://stackoverflow.com/questions/9185811/indicating-unaligned-access-to-clang-for-arm-compatibility * Case study: Chromium source for UnalignedLoad32() on ARM https://github.com/nwjs/chromium.src/blob/nw15/third_party/cld/base/basictypes.h#L302 Signed-off-by: Geunsik Lim <geunsik.lim@samsung.com>
BruceForstall
pushed a commit
to BruceForstall/coreclr
that referenced
this pull request
Aug 9, 2016
Fix ARM build
This was referenced Jan 31, 2020
picenka21
pushed a commit
to picenka21/runtime
that referenced
this pull request
Feb 18, 2022
…otnet/coreclr#6379) **PROBLEM** This patch is to resolve +3000 bus errors that are generated whenever we use the aggressive optimization levels of clang (issue dotnet/coreclr#5844 ). When we enable the -O3 optimization level of the clang version(from clang 3.5 to clang 3.9(snapshot)), we have always got the lots of bus errors from the coreCLR's unit tests. Actually, we can easily monitor SIGBUS signals (e.g., "misaligned memory access") with /proc/cpu/alignment facility in kernel space. Using "echo 2 > /proc/cpu/alignment" makes Linux kernel fixes the problems but the performance of the application will be degraded. .source: http://lxr.free-electrons.com/source/Documentation/arm/mem_alignment **VERSION 4** . Use 'GET_UNALIGNED_VALXXX' macros in the CoreClr infra-structure without any need for ifdefs. **VERSION 3** .Apply this PR on only Linux/ARM for different system environment (Windows). Here is .NET CI Report on Windows: Compile Error error C2146: syntax error: missing ';' before identifier '__unaligned_int32' (compiling source file D:\j\workspace\checked_windo---f6dc6fe4\src\jit\alloc.cpp) [D:\j\workspace\checked_windo---f6dc6fe4\bin\obj\Windows_NT.x64.Checked\src\jit\ crossgen\clrjit_crossgen.vcxproj] Indication 1 **VERSION 2** .Add UNALIGNED_ARM macro for handling ARM core specific optimization levels. .Add RISC-based ARM core handling into the existing infra-structure of the platform adaptation layer (PAL) for aggressive optimization cases on Linux/ARM. **VERSION 1** Basically, RISC-based ARM architecture requires aligned access with 4byte reads. In order to support aggressive optimization levels such as O2/O3, let's use attribute keyword of aligned(1) instead of using memcpy(2) in into a properly aligned buffer or the packing attribute. **BACKGROUND** According to ARM information center(infocenter.arm.com), By default, the ARM compiler expects normal C and C++ pointers to point to an aligned word in memory. A type qualifier __packed is provided to enable unaligned pointer access. If you want to define a pointer to a word that can be at any address (that is, that can be at a non-natural alignment), you must specify this using the __packed qualifier when defining the pointer: __packed int *pi; // pointer to unaligned int However, clang/llvm does not support the __packed qualifier such as __attribute__((packed)) or __attribute__((packed, aligned(4))) In -O0 (debug build) the innermost block is emitted as the following assembly, which works properly: ldr r1, [r0, dotnet/coreclr#24] ldr r2, [r0, dotnet/coreclr#20] In -O3 (release build) however the compiler realizes these fields are adjacent and generates this assembly: ldrdeq r2, r3, [r0, dotnet/coreclr#20] Unfortunately, vldr/ldrdb instructions always generate an alignment fault (in practice). It seems that clang uses ldrb instruction although GCC uses ldr instruction because armv7 supports unaligned ldr instruction. Note: If some arm architectures (e.g., Linux/ARM Emulator) does not support unaligned ldr, this issue is not generated with aggressive optimization levels (e.g., -O2 and -O3). * Case study: How does the ARM Compiler support unaligned accesses? http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka15414.html * Case study: Indicating unaligned access to Clang for ARM compatibility http://stackoverflow.com/questions/9185811/indicating-unaligned-access-to-clang-for-arm-compatibility * Case study: Chromium source for UnalignedLoad32() on ARM https://github.com/nwjs/chromium.src/blob/nw15/third_party/cld/base/basictypes.h#L302 Signed-off-by: Geunsik Lim <geunsik.lim@samsung.com> Commit migrated from dotnet/coreclr@561b64d
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
PinnableBufferCache uses some of the declaritive CAS attributes which
don't mean anything on CoreCLR. We had disabled this warning
internally, but this copy of the file is specific to open source and
we didn't disable it in this file.
This simply ports the change to disable this warning to mscorlib's
copy of the file.