On Sat, Apr 27, 2013 at 02:09:22AM -0300, Luiz Angelo Daros de Luca wrote:
> The usage of sign-extension might be cause. The problem is that all these
> variables are sector_t, which as far as I know, is a u64.
> Even if it was using signed variable, all of them are 64bit and using
> values much lo
Hello,
I checked sizeof(sector_t) and it is 8. The assembly code I get is similar
to what Sergey posted.
If it really is a compiler problem, which are the options? Would removing
the inline help?
---
Luiz Angelo Daros de Luca, Me.
luizl...@gmail.com
2013/4/27 Sergey Vlasov
>
On Sat, Apr 27, 2013 at 3:38 PM, Sergey Vlasov wrote:
> On Sat, Apr 27, 2013 at 02:09:22AM -0300, Luiz Angelo Daros de Luca wrote:
>> The usage of sign-extension might be cause. The problem is that all these
>> variables are sector_t, which as far as I know, is a u64.
>> Even if it was using signe
On Sat, Apr 27, 2013 at 07:40:38PM +0200, Jonas Gorski wrote:
> On Sat, Apr 27, 2013 at 3:38 PM, Sergey Vlasov wrote:
[...]
> > The "madd $3,$2" command here is incorrect - it performs sign
> > extension of its arguments; it should be "maddu $3,$2".
>
> I came to the same conclusion after looking
Note that adding an explicit u32 cast avoids the problem even with a buggy
compiler:
static inline u32 get_unaligned_le32(const u8 *p)
{
return (u32)p[0] | p[1] << 8 | p[2] << 16 | p[3] << 24;
}
Generally it's a good idea to write explicit type conversions like in
this example.
Poor p
On Sat, Apr 27, 2013 at 09:24:41PM +0200, Wojciech Kromer wrote:
>
> > Note that adding an explicit u32 cast avoids the problem even with a buggy
> > compiler:
> >
> > static inline u32 get_unaligned_le32(const u8 *p)
> > {
> > return (u32)p[0] | p[1] << 8 | p[2] << 16 | p[3] << 24;
> > }
> >
I was curious about the "undefined". I found the text:
The integer promotions are performed on each of the operands. The type
of the result is
that of the promoted left operand. If the value of the right operand is
negative or is
greater than or equal to the width of the promoted left ope
So, as left operand is 8bit, the right operant must not be over 8.
Does a simple typecast solves it?
return (u32)((u32)p[0] | (u32)p[1] << 8 | (u32)p[2] << 16 | (u32)p[3]
<< 24);
return (u32)p[0] | (u32)p[1] << 8 | (u32)p[2] << 16 | (u32)p[3] << 24;
is correct for all compilers, and this ve
Hello Wojciech,
I'm really no gcc expert and, please, correct if I'm wrong. Maybe the
problem lies when gcc is evaluating the
"| p[2] << 16 | p[3] << 24;" part. As "<<" has precedence over "|", it is
evaluated before.
At that time, the evaluated expression would be "p[3] << 24" and
the left oper
