Re: How do disable generation of LDRD in ARM
On 12/24/2012 07:53 PM, Roger Cruz wrote:
>
>
> I am compiling this piece of code from an open source project that I
> wish not to have to change. The problem is that when compiled for
> ARM, it generates an LDRD instruction, which when executed, causes a
> bus error since the address in ptr is not doubleword aligned.
Well, that's going to be tough. Your code isn't legal C, and a
compiler is not obligated to generate anything sensible for it. You
can't just convert an arbitrary byte pointer to a UINT64* and expect
working code. If you lie to the compiler it will bite you.
> I know I can change the code but I prefer to leave it intact as
> there may be many more instances of this and I don't wish to
> maintain the code.
There's no point talking about "maintenance" because the code is
already broken.
> 248static DWORD64 dwarf2_get_u8(const unsigned char* ptr)
> 249{
> 250return *(const UINT64*)ptr;
> 251}
This is the right way to do it:
static DWORD64 dwarf2_get_u8(const unsigned char* ptr)
{
UINT64 poo;
memcpy(&poo, ptr, sizeof poo);
return poo;
}
If GCC can detect that ptr is correctly aligned, it will generate an
LDRD or LDM instruction, as appropriate.
> Happy Holidays,
You too! :-)
Andrew.
Re: How do disable generation of LDRD in ARM
Thanks Andrew.
Yes, I recognized that the code was buggy and it works fine on x86 but not for
ARM v7 where alignment was mandatory. I was hoping that there would be an easy
way to cheat by using something like -mfix_cortexm3_ldrd but that didn't work
for me. So I fixed the code with a memcpy which I knew was the right way to do
it. I'll push the changes to the OSS community then.
Roger R. Cruz
On Dec 26, 2012, at 8:00 AM, Andrew Haley wrote:
> On 12/24/2012 07:53 PM, Roger Cruz wrote:
>>
>>
>> I am compiling this piece of code from an open source project that I
>> wish not to have to change. The problem is that when compiled for
>> ARM, it generates an LDRD instruction, which when executed, causes a
>> bus error since the address in ptr is not doubleword aligned.
>
> Well, that's going to be tough. Your code isn't legal C, and a
> compiler is not obligated to generate anything sensible for it. You
> can't just convert an arbitrary byte pointer to a UINT64* and expect
> working code. If you lie to the compiler it will bite you.
>
>> I know I can change the code but I prefer to leave it intact as
>> there may be many more instances of this and I don't wish to
>> maintain the code.
>
> There's no point talking about "maintenance" because the code is
> already broken.
>
>> 248static DWORD64 dwarf2_get_u8(const unsigned char* ptr)
>> 249{
>> 250return *(const UINT64*)ptr;
>> 251}
>
> This is the right way to do it:
>
> static DWORD64 dwarf2_get_u8(const unsigned char* ptr)
> {
> UINT64 poo;
> memcpy(&poo, ptr, sizeof poo);
> return poo;
> }
>
> If GCC can detect that ptr is correctly aligned, it will generate an
> LDRD or LDM instruction, as appropriate.
>
>> Happy Holidays,
>
> You too! :-)
>
> Andrew.
Should G++ reject initializer list narrowing conversions in -std=C++11 -pedantic mode?
Programs that depend on narrowing conversions in initializer lists violate 8.5.4 item 3 of ISO/IEC 14882-2012. Currently these programs are compiled successfully with warnings with and without a "-pedantic" flag in C++ 2011 language mode. Are there any drawbacks to having "-pedantic" mode reject these programs with an error? As it is now, I don't see an easy way for a user to determine if these warnings are due to C++ 2011 non-conformance or just bad programming practices. Thanks, David Ref: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55783 -- David Sankel Stellar Science Ltd Co - Stellar Scientific Software Solutions
