On Fri, Aug 23, 2019 at 2:15 AM Maxim Kuvyrkov
wrote:
>
> ...
> The other 1/3 will require much more work -- neon intrinsics needs to be
> converted from inline asms to GCC builtins, so that we can attach scheduler
> descriptions to them.
Please do.
I know of at least two libraries that heavil
On Sat, Aug 12, 2017 at 1:27 AM, Michael Zimmermann
wrote:
> That also depends on what you want to use C++ for.
> If you just want to use the convenient syntax and language features
> then you don't need to link against any additional library.
> In that case you'd disable exceptions and rtti and i
On Sun, Jul 30, 2017 at 7:30 PM, Jim Wilson wrote:
> On Sun, Jul 30, 2017 at 1:32 PM, Jeffrey Walton wrote:
>> hikey$ g++ -march=armv8-a test.cxx -c
>> test.cxx: In function ‘poly128_t VMULL_P64(poly64_t, poly64_t)’:
>> test.cxx:10:1: error: unrecognizable insn:
>
>
Hi Everyone,
I'm working on a early LeMaker HiKey with GCC 4.9.2. I believe
everything is fully patched.
I'm using the builtin's because the intrinsics are missing. I lifted
it from https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01976.html.
Any ideas on this issue?
hikey$ g++ -march=armv8-a test
> I don't see any easy solution for you at the moment, you need a
> binutils/gcc upgrade, or you need to put crc code in separate files.
> Or you could force all files to be compiled with -mcpu=generic, and
> then you can use .cpu to add/remove crc support as necessary.
Thanks Jim. This came from
On Wed, Apr 19, 2017 at 9:57 PM, Jim Wilson wrote:
> On Wed, Apr 19, 2017 at 12:38 PM, Jeffrey Walton wrote:
>> According to [1], I can use ".arch_extension" to enable it. According
>> to [2], ".arch_extension" is available in GCC 4.6 and GAS 2.21. My
>>
I'm working on my HiKey. I'm trying to enable CRC extension on ARMv8
in the assembler regardless of the way GCC was built, and regardless
of the user's CFLAGS and CXXFLAGS. I'm encountering an assembler
error: "unknown pseudo-op: `.arch_extension'".
According to [1], I can use ".arch_extension" to
On
> Behalf Of Jeffrey Walton
> Sent: Thursday, January 12, 2017 10:56 PM
> To: Linaro Toolchain Mailman List
> Subject: Does Linaro's GCC 4.9 include Crypto extensions and intrinsics?
>
> Please forgive my ignorance. I'm working on a Pine64 dev-board Pine64
> supp
Please forgive my ignorance. I'm working on a Pine64 dev-board Pine64
supplies Linaro's GCC 4.9.2 toolchain.
I am catching a compile error, and I am trying to determine why.
Does Linaro's GCC 4.9 provide AES and SHA intrinsics?
**
$ uname -a
Linux pine64 3.10.102-2-pine64-longsleep #66
On Sat, Jul 30, 2016 at 12:07 AM, Jim Wilson wrote:
> On Fri, Jul 29, 2016 at 7:55 PM, Jeffrey Walton wrote:
>>> Yes, these *p128* intrinsics are missing from the aarch64 port. I'd
>>> suggest filing a bug report.
>>
>> Please forgive my ignorance. Who
On Thu, Jul 28, 2016 at 12:28 PM, Jim Wilson wrote:
> On Thu, Jul 28, 2016 at 8:36 AM, Jeffrey Walton wrote:
>> I'm having trouble finding vreinterpretq_u64_p128 (and friends) to
>> help convert a polynomial. I can't find it in arm_neon.h or
>> arm_acle.h:
>
Hi Everyone,
I have a HiKey running Linaro. I'm trying to build out a test case
which tests Aarch32 on Aarch64.
When I attempt to build an Aarch32 binary I experience the compile
error below. The GCC folks helped me with the Aarch32 CFLAGS, so I
believe they are correct.
$ gcc -march=armv8-a
Hi Everyone,
I'm having trouble finding vreinterpretq_u64_p128 (and friends) to
help convert a polynomial. I can't find it in arm_neon.h or
arm_acle.h:
$ grep p128 /usr/lib/gcc/aarch64-linux-gnu/4.9/include/arm_acle.h
$ grep p128 /usr/lib/gcc/aarch64-linux-gnu/4.9/include/arm_neon.h
$ grep p64 /u
On Fri, Jul 22, 2016 at 12:19 AM, Jim Wilson wrote:
> On Thu, Jul 21, 2016 at 9:13 PM, Jeffrey Walton wrote:
>> So I guess the question is, what do I use for -mfpu=neon-vfp3 (or
>> -mfpu=neon-vfp3-d32)? Is -mfpu=neon enough?
>
> The -mfpu=neon option is enough. neon i
On Thu, Jul 21, 2016 at 11:30 PM, Jim Wilson wrote:
> On Thu, Jul 21, 2016 at 6:33 PM, Jeffrey Walton wrote:
>> I think vfpd32 cpu flag means I have 32 D-registers. The cpu flags
>> neon and vfpv3 flags means I want something more than -mfpu=neon-fp16,
>> but I'm not s
On Thu, Jul 21, 2016 at 11:30 PM, Jim Wilson wrote:
> On Thu, Jul 21, 2016 at 6:33 PM, Jeffrey Walton wrote:
>> I think vfpd32 cpu flag means I have 32 D-registers. The cpu flags
>> neon and vfpv3 flags means I want something more than -mfpu=neon-fp16,
>> but I'm not s
Hi Everyone,
I'm looking at the features of a BeagleBone Black. Its /proc/cpuinfo is below.
I think vfpd32 cpu flag means I have 32 D-registers. The cpu flags
neon and vfpv3 flags means I want something more than -mfpu=neon-fp16,
but I'm not sure what that is.
My question is, what GCC ARM option
On Wed, Jul 20, 2016 at 5:33 PM, Jim Wilson wrote:
> On Wed, Jul 20, 2016 at 2:14 PM, Jeffrey Walton wrote:
>> I'm having trouble with ARMv8/Aarch64. One is an early Mustang server
>
> ARMv8 implies 32-bit code (aarch32). Aaarch64 implies 64-bit code.
> These are two di
Hi Everyone,
I'm having trouble with ARMv8/Aarch64. One is an early Mustang server
board (without CRC or Crypto), and the other is a LeMaker HiKey (with
CRC and Crypto). Both run Linaro:
apm-mustang: $ cat /proc/cpuinfo
Features: fp asimd evtstrm
And:
hikey: $ cat /proc/cpuinfo
>> Mystery solved... GCC 4.8 does not provide a symbolizer.
>>
>> From a new comment on the GCC bug report
>> (https://bugzilla.redhat.com/show_bug.cgi?id=1250844#c6):
>
> Even with symbolizer you may face some issue with ASAN on ARM.
> Check this llvm bug report [1].
>
> [1] https://llvm.org/bugs/
On Sun, Jun 26, 2016 at 10:33 PM, Jeffrey Walton wrote:
> Hi Everyone,
>
> I have a test script from help that repeatedly builds and runs a
> library under different configurations. The script includes multiple
> Asan tests.
>
> The Asan tests are producing some findings
Hi Maxim,
> Are these full backtraces you got from ASan? If so, do you use stripped
> libraries on your system (on Ubuntu, I guess, you do). Could this issue
> (https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00132.html) be related to to
> your problem?
Maybe part of the intermediate solution is to
>>
>> AddressSanitizer: stack-buffer-overflow on address 0xbec57b18 at pc
>> 0x38c651 bp 0xbec579e0 sp 0xbec579e4
>>
>> AddressSanitizer: stack-buffer-overflow on address 0xbedbae9c at pc
>> 0x6553f bp 0xbedbae68 sp 0xbedbae6c
>>
>> AddressSanitizer: stack-buffer-overflow on address 0xbea67b18 at p
>> The test program is always built with at least -g2, and sometimes
>> built with -g3. However, I am not seeing the symbolication. According
>> to the GCC folks, asan_symbolize is not required for GCC because it
>> uses libbacktrace. Also see
>> http://bugzilla.redhat.com/show_bug.cgi?id=1250844.
Hi Everyone,
I have a test script from help that repeatedly builds and runs a
library under different configurations. The script includes multiple
Asan tests.
The Asan tests are producing some findings under ARM32 as shown below.
Other platforms do not include Asan findings. In addition, Valgrind
25 matches
Mail list logo
