[Bug c/56620] New: Memcpy optimization may lead to unaligned access on ARM Thumb

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56620 Bug #: 56620 Summary: Memcpy optimization may lead to unaligned access on ARM Thumb Classification: Unclassified Product: gcc Version: unknown Status: UNCON

[Bug c/56620] Memcpy optimization may lead to unaligned access on ARM Thumb

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56620 --- Comment #1 from eleventen at gmail dot com 2013-03-14 18:13:03 UTC --- Created attachment 29669 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29669 Sample source object

[Bug target/56620] Memcpy optimization may lead to unaligned access on ARM Thumb

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56620 --- Comment #3 from Marc Singer 2013-03-14 18:26:02 UTC --- The compiler was built as follows: elf@cerise ~/memcpy-bug > /opt/gcc/arm-none-eabi/bin/gcc -v Using built-in specs. COLLECT_GCC=/opt/gcc/arm-none-eabi/bin/gcc Target: arm-non

[Bug target/56620] Memcpy optimization may lead to unaligned access on ARM Thumb

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56620 Marc Singer changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|

[Bug target/56620] Memcpy optimization may lead to unaligned access on ARM Thumb

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56620 --- Comment #6 from Marc Singer 2013-03-14 21:35:54 UTC --- For the sake of posterity, the Cortex-M3 and M4 do handle unaligned accesses properly in hardware though with the expected performance penalty. It is the fact that I enforced alignment

[Bug inline-asm/56884] New: ARM thumb16 mnemonic lsls not recognized for CPU cortex-m0.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56884 Bug #: 56884 Summary: ARM thumb16 mnemonic lsls not recognized for CPU cortex-m0. Classification: Unclassified Product: gcc Version: unknown Status: UNCONFI

[Bug c++/66173] New: -fno-threadsafe-statics suppresses guard functions but not guard variables

: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: eleventen at gmail dot com Target Milestone: --- Created attachment 35553 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35553&action=edit Source file demonstrati

[Bug c++/66172] New: -fno-threadsafe-statics suppresses guard functions but not guard variables

: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: eleventen at gmail dot com Target Milestone: --- The use of the -fno-threadsafe-statics eliminates the function references to the guard functions, __cxa_guard_acquire

[Bug c++/66173] -fno-threadsafe-statics suppresses guard functions but not guard variables

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66173 --- Comment #1 from Marc Singer --- I neglected to include information about the version of the compiler. This is a 64 bit compiler on amd64. # g++ --version g++ (Debian 4.9.2-10) 4.9.2 Copyright (C) 2014 Free Software Foundation, Inc. This is

[Bug c++/66172] -fno-threadsafe-statics suppresses guard functions but not guard variables

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66172 --- Comment #3 from Marc Singer --- I've come to the same conclusion. My hope was that I could eliminate the guard and force the compiler to initialize block scoped statics at the start of execution. It looks like the standard stands in the way