Re: Test GCC conversion with reposurgeon available
On 06/01/2020 22:09, Loren James Rittle wrote: On Fri, 3 Jan 2020, Joseph Myers wrote: git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-7a.git git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-7b.git I have not had a substantial commit to gcc [or, likely, post to this list] in a decade THUS a warm howdy to anyone still around from 1999-2009. Every "git log" entry for my commits looked fine. There were two odd cases, but both now make sense to me. My first commit's Author line (1999) contains a physical machine name (but it correctly matches the contemporary Changelog entry). The second odd case took more time to understand: In gcc-reposurgeon-7a, commit hash 16fc918929 ; I corrected a prior Changelog (for 89903bf801). I would not expect any version control system translation process to look ahead for such textual changes to a side-maintained ChangeLog file but I was somewhat stumped on why the ChangeLog text did not match the "git log" text. Regards, Loren We can add a correction so that the git 'Author' field will be fixed, if you would like; but the ChangeLog and commit message will remain as is. R.
Status of gcc 10.0.0 on x86_64-w64-mingw32
First status of gcc 10.0.0 on x86_64-w64-mingw32 for the new year. Test results: https://gcc.gnu.org/ml/gcc-testresults/2020-01/msg00355.html Complete logs: https://cloud.emrich-ebersheim.de/index.php/s/g9D245XdCW6GD5W?path=%2F10.0.0-rev.279895 signature.asc Description: OpenPGP digital signature
Re: -fpatchable-function-entry should set SHF_WRITE and create one __patchable_function_entries per function
On 07/01/2020 07:25, Fangrui Song wrote: > On 2020-01-06, Fangrui Song wrote: >> The addresses of NOPs are collected in a section named >> __patchable_function_entries. >> A __patchable_function_entries entry is relocated by a symbolic relocation >> (e.g. R_X86_64_64, R_AARCH64_ABS64, R_PPC64_ADDR64). >> In -shared or -pie mode, the linker will create a dynamic relocation >> (non-preemptible: relative relocation (e.g. R_X86_64_RELATIVE); >> preemptible: symbolic relocation (e.g. R_X86_64_64)). >> >> In either case, the section contents will be modified at runtime. >> Thus, the section should have the SHF_WRITE flag to avoid text relocations >> (DF_TEXTREL). pie/pic should either imply writable __patchable_function_entries, or __patchable_function_entries should be documented to be offsets from some base address in the module: the users of it have to modify .text and do lowlevel hacks so they should be able to handle such arithmetics. i think it's worth opening a gcc bug report. >> When -ffunction-sections is used, ideally GCC should emit one >> __patchable_function_entries (SHF_LINK_ORDER) per .text.foo . >> If the corresponding .text.foo is discarded (--gc-sections, COMDAT, >> /DISCARD/), the linker can discard the associated >> __patchable_function_entries. This can be seen as a lightweight COMDAT >> section group. (A section group adds an extra section and costs 3 words) >> Currently lld (LLVM linker) has implemented such SHF_LINK_ORDER collecting >> features. GNU ld and gold don't have the features. >> >> I have summarized the feature requests in this post >> https://sourceware.org/ml/binutils/2019-11/msg00266.html >> >> gcc -fpatchable-function-entry=2 -ffunction-sections -c a.c >> >> [ 4] .text.f0 PROGBITS 40 09 00 >> AX 0 0 1 >> ### No W flag >> ### One __patchable_function_entries instead of 3. >> [ 5] __patchable_function_entries PROGBITS 49 >> 18 00 A 0 0 1 >> [ 6] .rela__patchable_function_entries RELA >> 000280 48 18 I 13 5 8 >> [ 7] .text.f1 PROGBITS 61 09 00 >> AX 0 0 1 >> [ 8] .text.f2 PROGBITS 6a 09 00 >> AX 0 0 1 > > Emitting a __patchable_function_entries for each function may waste > object file sizes (64 bytes per function on ELF64). If zeros are > allowed, emitting a single __patchable_function_entries should be fine. > > If we do want to emit unique sections, the condition should be either > -ffunction-sections or COMDAT is used. again it's worth raising a gcc bug i think. there is another known issue: aarch64 -mbranch-protect=bti (and presumably x86_64 -fcf-protection=branch) has to add landing pad at the begining of each indirectly called function so the patchable nops can only come after that. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92424 no matter how this gets resolved i think this will require documentation changes too.
Re: Support Library Requirements for GCC 10
On Sun, Jan 5, 2020 at 9:28 PM Bruno Haible wrote: > > Hi, > > The minimum support library version of MPC for building GCC 10 is not > correct. > > After downloading gcc-10-20191229.tar.xz and > $ cd gcc-10-20191229/gcc/doc > $ ./install.texi2html > $ xdg-open HTML/prerequisites.html > I installed > - gmp 4.3.2 - works, > - mpfr 3.1.0 - works, > - mpc 0.8.1 - fails! > > The failure has been reported already in [1]. The fix is to use > > - mpc 1.0.3 - works. Indeed. I checked 0.8.2 and it doesn't work, I checked 1.0.1 and that does so I adjusted it to 1.0.1 or later. Richard. > This wastes some time for everyone who attempts to install GCC 10 from > scratch. > > In [2] it was suggested to look in the contrib/download_prerequisites script. > This script indeed contains > > mpc='mpc-1.0.3.tar.gz' > > Additionally, the mpc-0.8.1 release is so old that it is not (or no longer) > on ftp.gnu.org [3]. > > Therefore I would suggest > 1) to change the documentation (HTML/prerequisites.html) in the GCC 10 > snapshots to mention mpc-1.0.3 instead of mpc-0.8.1, > 2) likewise, change https://gcc.gnu.org/install/prerequisites.html > to mention mpc-1.0.3 instead of mpc-0.8.1. > > Bruno > > [1] https://gcc.gnu.org/ml/gcc/2017-05/msg00022.html > [2] https://gcc.gnu.org/ml/gcc/2017-05/msg00024.html > [3] https://ftp.gnu.org/gnu/mpc/ > p Description: Binary data
Re: Support Library Requirements for GCC 10
On Tue, Jan 7, 2020 at 1:38 PM Richard Biener wrote: > > On Sun, Jan 5, 2020 at 9:28 PM Bruno Haible wrote: > > > > Hi, > > > > The minimum support library version of MPC for building GCC 10 is not > > correct. > > > > After downloading gcc-10-20191229.tar.xz and > > $ cd gcc-10-20191229/gcc/doc > > $ ./install.texi2html > > $ xdg-open HTML/prerequisites.html > > I installed > > - gmp 4.3.2 - works, > > - mpfr 3.1.0 - works, > > - mpc 0.8.1 - fails! > > > > The failure has been reported already in [1]. The fix is to use > > > > - mpc 1.0.3 - works. > > Indeed. I checked 0.8.2 and it doesn't work, I checked 1.0.1 and that does > so I adjusted it to 1.0.1 or later. Note that in-tree builds are only supported for exactly the versions that ./download_prerequesites download but the minimal documented versions are those that are known to work when the library is compiled and installed separately. Richard. > Richard. > > > This wastes some time for everyone who attempts to install GCC 10 from > > scratch. > > > > In [2] it was suggested to look in the contrib/download_prerequisites > > script. > > This script indeed contains > > > > mpc='mpc-1.0.3.tar.gz' > > > > Additionally, the mpc-0.8.1 release is so old that it is not (or no longer) > > on ftp.gnu.org [3]. > > > > Therefore I would suggest > > 1) to change the documentation (HTML/prerequisites.html) in the GCC 10 > > snapshots to mention mpc-1.0.3 instead of mpc-0.8.1, > > 2) likewise, change https://gcc.gnu.org/install/prerequisites.html > > to mention mpc-1.0.3 instead of mpc-0.8.1. > > > > Bruno > > > > [1] https://gcc.gnu.org/ml/gcc/2017-05/msg00022.html > > [2] https://gcc.gnu.org/ml/gcc/2017-05/msg00024.html > > [3] https://ftp.gnu.org/gnu/mpc/ > >
Re: Question about sizeof after struct change
On Mon, Jan 6, 2020 at 12:03 PM Jonathan Wakely wrote:
>
> On Fri, 3 Jan 2020 at 16:09, Erick Ochoa wrote:
> > Do you mean something like taking the address of a struct and adding an
> > offset
> > to access a field?
>
> Yes, the following code is valid:
>
> struct S { int unused; int used; };
> static_assert( sizeof(S) == 8 );
> S s[4];
> int* s2_used = (int*)((char*)s + 20);
>
> Accessing the field doesn't refer to S::used or S::unused directly,
> and doesn't use sizeof(S) or sizeof(int) explicitly.
>
> So if your pass removes S::unused, then you'd need to analyse
> ((char*)s + 20) to determine that it accesses s[2].used and then
> adjust it to ((char*)s + 8) instead.
Also GCC, at its own discretion, might decide to change
s[1].used to MEM[&s + 8] because semantically they are
the same.
Richard.
Re: Frontend access to target-related options
On Thu, Jan 2, 2020 at 5:54 PM Nathan Sidwell wrote: > > On 1/1/20 4:31 AM, The Other wrote: > > Hi, > > I'm currently working on a Rust frontend for GCC. Rust has some > > language-level conditional compilation features based on the presence or > > lack of features in the target architecture (e.g. SSE, AVX, a static C > > runtime) as well as the target CPU architecture itself, target OS, and > > various other target-related information (such as pointer width and > > endianness). > > > > As such, the frontend parser requires this target-related option > > information to be available to it. I was wondering if there was an > > architecture-neutral way of accessing this data (if it is even stored). > > I've looked into options.h but I cannot figure out how to use it in an > > architecture-neutral way. > > Um, AVX and such are arch-specific. It sounds like you need some kind > of (new?) langhook that targets can register? You mean target hook. Depending on the actual piece of info such hook might already exist though. Richard. > nathan > > -- > Nathan Sidwell
Re: Need sanity check on DSE vs expander issue
On Fri, Dec 20, 2019 at 12:08 PM Richard Biener
wrote:
>
> On December 20, 2019 8:25:18 AM GMT+01:00, Jeff Law wrote:
> >On Fri, 2019-12-20 at 08:09 +0100, Richard Biener wrote:
> >> On December 20, 2019 3:20:40 AM GMT+01:00, Jeff Law
> >wrote:
> >> > I need a sanity check here.
> >> >
> >> > Given this code:
> >> >
> >> > > typedef union { long double value; unsigned int word[4]; }
> >> > memory_long_double;
> >> > > static unsigned int ored_words[4];
> >> > > static void add_to_ored_words (long double x)
> >> > > {
> >> > > memory_long_double m;
> >> > > size_t i;
> >> > > memset (&m, 0, sizeof (m));
> >> > > m.value = x;
> >> > > for (i = 0; i < 4; i++)
> >> > > {
> >> > > ored_words[i] |= m.word[i];
> >> > > }
> >> > > }
> >> > >
> >> >
> >> > DSE is removing the memset as it thinks the assignment to m.value
> >is
> >> > going to set the entire union.
> >> >
> >> > But when we translate that into RTL we use XFmode:
> >> >
> >> > > ;; m.value ={v} x_6(D);
> >> > >
> >> > > (insn 7 6 0 (set (mem/v/j/c:XF (plus:DI (reg/f:DI 77
> >> > virtual-stack-vars)
> >> > > (const_int -16 [0xfff0])) [2
> >m.value+0
> >> > S16 A128])
> >> > > (reg/v:XF 86 [ x ])) "j.c":13:11 -1
> >> > > (nil))
> >> > >
> >> >
> >> > That (of course) only writes 80 bits of data because of XFmode,
> >leaving
> >> > 48 bits uninitialized. We then read those bits, or-ing the
> >> > uninitialized data into ored_words and all hell breaks loose later.
> >> >
> >> > Am I losing my mind? ISTM that dse and the expander have to agree
> >on
> >> > how much data is written by the store to m.value.
> >>
> >> It looks like MEM_SIZE is wrong here, so you need to figure how we
> >arrive at this (I guess TYPE_SIZE vs. MODE_SIZE mismatch is biting us
> >here?)
> >>
> >> That is, either the MEM should have BLKmode or the mode size should
> >match
> >> MEM_SIZE. Maybe DSE can avoid looking at MEM_SIZE for non-BLKmode
> >MEMs?
> >It's gimple DSE that removes the memset, so it shouldn't be mucking
> >around with modes at all. stmt_kills_ref_p seems to think the
> >assignment to m.value sets all of m.
> >
> >The ao_ref for memset looks reasonable:
> >
> >> (gdb) p *ref
> >> $14 = {ref = 0x0, base = 0x77ffbea0, offset = { >long>> = {coeffs = {0}}, },
> >> size = {> = {coeffs = {128}}, >fields>}, max_size = {> = {
> >> coeffs = {128}}, }, ref_alias_set = 0,
> >base_alias_set = 0, volatile_p = false}
> >>
> >128 bits with a base of VAR_DECL m.
> >
> >We looking to see if this statement will kill the ref:
> >
> >> (gdb) p debug_gimple_stmt (stmt)
> >> # .MEM_8 = VDEF <.MEM_6>
> >> m.value ={v} x_7(D);
> >> $21 = void
> >> (gdb) p debug_tree (lhs)
> >> >> type >volatile XF
> >> size
> >> unit-size
> >> align:128 warn_if_not_align:0 symtab:0 alias-set -1
> >canonical-type 0x7fffea988690 precision:80>
> >> side-effects volatile
> >> arg:0 >> type >sizes-gimplified volatile type_0 BLK size >128> unit-size
> >> align:128 warn_if_not_align:0 symtab:0 alias-set -1
> >canonical-type 0x7fffea988348 fields
> >context
> >> pointer_to_this >
> >> side-effects addressable volatile used read BLK j.c:10:31
> >size unit-size >0x7fffea7f3d38 16>
> >> align:128 warn_if_not_align:0 context >0x7fffea97bd00 add_to_ored_words>
> >> chain >0x7fffea9430a8 size_t>
> >> used unsigned read DI j.c:11:10
> >> size
> >> unit-size
> >> align:64 warn_if_not_align:0 context >0x7fffea97bd00 add_to_ored_words>>>
> >> arg:1 >> type >XF size unit-size >0x7fffea7f3d38 16>
> >> align:128 warn_if_not_align:0 symtab:0 alias-set -1
> >canonical-type 0x7fffea8133f0 precision:80
> >> pointer_to_this >
> >> XF j.c:6:29 size unit-size
> >
> >> align:128 warn_if_not_align:0 offset_align 128
> >> offset
> >> bit-offset context
> >
> >> chain >0x7fffea981f18>
> >> TI j.c:6:49 size
> >unit-size
> >> align:32 warn_if_not_align:0 offset_align 128 offset
> > bit-offset >0> context >>
> >> j.c:13:4 start: j.c:13:3 finish: j.c:13:9>
> >> $22 = void
> >>
> >
> >stmt_kills_ref_p calls get_ref_base_and_extent on that LHS object. THe
> >returned base is the same as ref->base. The returned offset is zero
> >with size/max_size of 128 bits. So according to
> >get_ref_base_and_extent the assignment is going to write 128 bits and
> >thus kills the memset.
> >
> >One might argue that's where the problems start -- somewhere in
> >get_ref_base_and_extent.
> >
> >I'm largely offline the next couple weeks...
> >
> >I don't have any "real" failures I'm tracking because of this, but it
> >does cause some configure generated tests to give the wrong result.
> >Thankfully the inconsistency just doesn't matter for any of the
> >packages that are affected.
>
> It's certainly somethi
Re: Test GCC conversion with reposurgeon available
Richard, Thanks for the offer, but no need. Just wanted to confirm with some detail that I reviewed aspects of the svn-git conversion and LGTM. BTW, I too saw the issue (in 14 out of 261 master commits) reported by Andrew where (in my case) "ljrit...@gcc.gnu.org" was used in Author line(s) rather than the expected e-mail. In every one of my cases, it appears because no exact Changelog text was related to the commit rather than, as in Andrew's analysis of case mismatches. Regards, Loren On Tue, Jan 7, 2020 at 3:41 AM Richard Earnshaw (lists) wrote: > > On 06/01/2020 22:09, Loren James Rittle wrote: > > On Fri, 3 Jan 2020, Joseph Myers wrote: > > > >> git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-7a.git > >> git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-7b.git > > > > I have not had a substantial commit to gcc [or, likely, post to this > > list] in a decade THUS a warm howdy to anyone still around from > > 1999-2009. Every "git log" entry for my commits looked fine. There > > were two odd cases, but both now make sense to me. My first commit's > > Author line (1999) contains a physical machine name (but it correctly > > matches the contemporary Changelog entry). The second odd case took > > more time to understand: > > > > In gcc-reposurgeon-7a, commit hash 16fc918929 ; I corrected a prior > > Changelog (for 89903bf801). I would not expect any version control > > system translation process to look ahead for such textual changes to a > > side-maintained ChangeLog file but I was somewhat stumped on why the > > ChangeLog text did not match the "git log" text. > > > > Regards, > > Loren > > > > We can add a correction so that the git 'Author' field will be fixed, if > you would like; but the ChangeLog and commit message will remain as is. > > R.
[ARM] LLVM's -arm-assume-misaligned-load-store equivalent in GCC?
Hi,
I've received a support request where GCC generates strd/ldrd which
require aligned memory addresses, while the user code actually
provides sub-aligned pointers.
The sample code is derived from CMSIS:
#define __SIMD32_TYPE int
#define __SIMD32(addr) (*(__SIMD32_TYPE **) & (addr))
void foo(short *pDst, int in1, int in2) {
*__SIMD32(pDst)++ = in1;
*__SIMD32(pDst)++ = in2;
}
compiled with arm-none-eabi-gcc -mcpu=cortex-m7 CMSIS.c -S -O2
generates:
foo:
strdr1, r2, [r0]
bx lr
Using -mno-unaligned-access of course makes no change, since the code
is lying to the compiler by casting short* to int*.
However, LLVM has -arm-assume-misaligned-load-store which disables
generation of ldrd/strd in such cases:
https://reviews.llvm.org/D17015?id=48020
Would some equivalent be acceptable in GCC? I have a small patch that
seems to work.
Thanks,
Christophe
Re: [ARM] LLVM's -arm-assume-misaligned-load-store equivalent in GCC?
On 07/01/2020 15:57, Christophe Lyon wrote:
Hi,
I've received a support request where GCC generates strd/ldrd which
require aligned memory addresses, while the user code actually
provides sub-aligned pointers.
The sample code is derived from CMSIS:
#define __SIMD32_TYPE int
#define __SIMD32(addr) (*(__SIMD32_TYPE **) & (addr))
void foo(short *pDst, int in1, int in2) {
*__SIMD32(pDst)++ = in1;
*__SIMD32(pDst)++ = in2;
}
compiled with arm-none-eabi-gcc -mcpu=cortex-m7 CMSIS.c -S -O2
generates:
foo:
strdr1, r2, [r0]
bx lr
Using -mno-unaligned-access of course makes no change, since the code
is lying to the compiler by casting short* to int*.
However, LLVM has -arm-assume-misaligned-load-store which disables
generation of ldrd/strd in such cases:
https://reviews.llvm.org/D17015?id=48020
Would some equivalent be acceptable in GCC? I have a small patch that
seems to work.
Thanks,
Christophe
It sounds ill-conceived to me. Why just this case (ldrd/strd)? What
about cases where we use ldm/stm which also can't tolerate misaligned
accesses?
Unless the conditions for the option are well-defined, I don't think we
should be doing things like this. In the long term it just leads to
more bugs being reported when the user is bitten by their own wrong code.
R.
Re: [ARM] LLVM's -arm-assume-misaligned-load-store equivalent in GCC?
On Tue, 7 Jan 2020, Christophe Lyon wrote:
I've received a support request where GCC generates strd/ldrd which
require aligned memory addresses, while the user code actually
provides sub-aligned pointers.
The sample code is derived from CMSIS:
#define __SIMD32_TYPE int
#define __SIMD32(addr) (*(__SIMD32_TYPE **) & (addr))
void foo(short *pDst, int in1, int in2) {
*__SIMD32(pDst)++ = in1;
*__SIMD32(pDst)++ = in2;
}
compiled with arm-none-eabi-gcc -mcpu=cortex-m7 CMSIS.c -S -O2
generates:
foo:
strdr1, r2, [r0]
bx lr
Using -mno-unaligned-access of course makes no change, since the code
is lying to the compiler by casting short* to int*.
If the issue is as well isolated as this, can't they just edit the code?
typedef int __SIMD32_TYPE __attribute__((aligned(1)));
gets
str r1, [r0]@ unaligned
str r2, [r0, #4]@ unaligned
instead of
strdr1, r2, [r0]
--
Marc Glisse
Re: [ARM] LLVM's -arm-assume-misaligned-load-store equivalent in GCC?
On Tue, 7 Jan 2020 at 17:06, Richard Earnshaw (lists)
wrote:
>
> On 07/01/2020 15:57, Christophe Lyon wrote:
> > Hi,
> >
> > I've received a support request where GCC generates strd/ldrd which
> > require aligned memory addresses, while the user code actually
> > provides sub-aligned pointers.
> >
> > The sample code is derived from CMSIS:
> > #define __SIMD32_TYPE int
> > #define __SIMD32(addr) (*(__SIMD32_TYPE **) & (addr))
> >
> > void foo(short *pDst, int in1, int in2) {
> > *__SIMD32(pDst)++ = in1;
> > *__SIMD32(pDst)++ = in2;
> > }
> >
> > compiled with arm-none-eabi-gcc -mcpu=cortex-m7 CMSIS.c -S -O2
> > generates:
> > foo:
> > strdr1, r2, [r0]
> > bx lr
> >
> > Using -mno-unaligned-access of course makes no change, since the code
> > is lying to the compiler by casting short* to int*.
> >
> > However, LLVM has -arm-assume-misaligned-load-store which disables
> > generation of ldrd/strd in such cases:
> > https://reviews.llvm.org/D17015?id=48020
> >
> > Would some equivalent be acceptable in GCC? I have a small patch that
> > seems to work.
> >
> > Thanks,
> >
> > Christophe
> >
>
> It sounds ill-conceived to me. Why just this case (ldrd/strd)? What
> about cases where we use ldm/stm which also can't tolerate misaligned
> accesses?
Sorry, I over-simplified. That would avoid generating ldrd/strd/ldm/stm.
>
> Unless the conditions for the option are well-defined, I don't think we
> should be doing things like this. In the long term it just leads to
> more bugs being reported when the user is bitten by their own wrong code.
>
Indeed.
The thing (as usual) is that users report that "it works with other
compilers"
> R.
Re: [ARM] LLVM's -arm-assume-misaligned-load-store equivalent in GCC?
On Tue, 7 Jan 2020 at 17:18, Marc Glisse wrote:
>
> On Tue, 7 Jan 2020, Christophe Lyon wrote:
>
> > I've received a support request where GCC generates strd/ldrd which
> > require aligned memory addresses, while the user code actually
> > provides sub-aligned pointers.
> >
> > The sample code is derived from CMSIS:
> > #define __SIMD32_TYPE int
> > #define __SIMD32(addr) (*(__SIMD32_TYPE **) & (addr))
> >
> > void foo(short *pDst, int in1, int in2) {
> > *__SIMD32(pDst)++ = in1;
> > *__SIMD32(pDst)++ = in2;
> > }
> >
> > compiled with arm-none-eabi-gcc -mcpu=cortex-m7 CMSIS.c -S -O2
> > generates:
> > foo:
> >strdr1, r2, [r0]
> >bx lr
> >
> > Using -mno-unaligned-access of course makes no change, since the code
> > is lying to the compiler by casting short* to int*.
>
> If the issue is as well isolated as this, can't they just edit the code?
>
> typedef int __SIMD32_TYPE __attribute__((aligned(1)));
>
That type is defined by a macro in CMSIS's arm_math.h.
I think users don't want to play tricks with such libraries,
but I could try to check with them if something around these lines
would be acceptable.
> gets
>
> str r1, [r0]@ unaligned
> str r2, [r0, #4]@ unaligned
>
> instead of
>
> strdr1, r2, [r0]
>
> --
> Marc Glisse
Re: [ARM] LLVM's -arm-assume-misaligned-load-store equivalent in GCC?
On Tue, Jan 7, 2020 at 7:58 AM Christophe Lyon
wrote:
>
> Hi,
>
> I've received a support request where GCC generates strd/ldrd which
> require aligned memory addresses, while the user code actually
> provides sub-aligned pointers.
>
> The sample code is derived from CMSIS:
> #define __SIMD32_TYPE int
> #define __SIMD32(addr) (*(__SIMD32_TYPE **) & (addr))
>
> void foo(short *pDst, int in1, int in2) {
>*__SIMD32(pDst)++ = in1;
>*__SIMD32(pDst)++ = in2;
> }
>
> compiled with arm-none-eabi-gcc -mcpu=cortex-m7 CMSIS.c -S -O2
> generates:
> foo:
> strdr1, r2, [r0]
> bx lr
>
> Using -mno-unaligned-access of course makes no change, since the code
> is lying to the compiler by casting short* to int*.
>
> However, LLVM has -arm-assume-misaligned-load-store which disables
> generation of ldrd/strd in such cases:
> https://reviews.llvm.org/D17015?id=48020
>
> Would some equivalent be acceptable in GCC? I have a small patch that
> seems to work.
Violating C standard option, -fno-strict-alignment. GCC uses the
alignment of int across many places, more than target specific parts.
It seems like you just want to disable one part of the assumition but
not the rest. This seems broken and very fragile.
What they want is the following:
#define int __attribute__((aligned(1) )) int
Which might not work for unsigned int or short int.
Thanks,
Andrew Pinski
>
> Thanks,
>
> Christophe
