> I have run into variable alignment issues, which turned out to be
> caused by forward declaration w/o the aligned attribute repeated.
> Could someone explain this please? If it's a bug to not include the
> aligned attribute in the forward declaration, would it be hard to add
> a warning for that
H.J. Lu wrote:
> void *undef __attribute__ ((uninitialized)); // Or something similar
>
> foo (undef);
>
> Compiler can pass some junk to foo.
I don't think that's a very good idea. If we need this, which I doubt,
it should be something like a new __undefined__ keyword, that expands to
an und
Bernd Schmidt wrote:
>>> int x __attribute__ ((uninitialized));
>>>
>>> to tell compiler that it is OK for "x" to be uninitialized?
>
> Better to call it "initialized", analogous to attribute used/unused.
I agree.
>> I think the general idea is reasonable. I also think it might be worth
>> spe
> >No you should not generate addresses for VCEs that contain a SSA_NAME.
> > I think you should check if get_base_address is a
> >is_gimple_addressable inside gather_memory_references_ref.
>
> There, TREE_CODE ( get_base_address (ref)) == SSA_NAME
>
> and get_base_address (ref) is is_gimple_addr
On Fri, Aug 20, 2010 at 1:57 PM, Bernd Schmidt wrote:
> On 08/20/2010 10:51 PM, Ian Lance Taylor wrote:
>> "H.J. Lu" writes:
>>
>>> Sometime I have to do
>>>
>>> int x = 0;
>>>
>>> to silence gcc from uninitialized warnings when I know it is
>>> unnecessary. Is that a good idea to add
>>>
>>> in
On 08/20/2010 10:51 PM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> Sometime I have to do
>>
>> int x = 0;
>>
>> to silence gcc from uninitialized warnings when I know it is
>> unnecessary. Is that a good idea to add
>>
>> int x __attribute__ ((uninitialized));
>>
>> to tell compiler that i
"H.J. Lu" writes:
> Sometime I have to do
>
> int x = 0;
>
> to silence gcc from uninitialized warnings when I know it is
> unnecessary. Is that a good idea to add
>
> int x __attribute__ ((uninitialized));
>
> to tell compiler that it is OK for "x" to be uninitialized?
I think the general idea
2010/8/20 Piotr Jaroszyński :
> Let me walk you through simple testcases showing different alignments
> I see for "misaligned" on gcc 4.4.4 and 4.5.1.
Forgot to mention the results are for x86_64.
--
Best Regards
Piotr Jaroszyński
On 10-08-20 15:42 , H.J. Lu wrote:
Hi,
Sometime I have to do
int x = 0;
to silence gcc from uninitialized warnings when I know it is
unnecessary. Is that a good idea to add
int x __attribute__ ((uninitialized));
to tell compiler that it is OK for "x" to be uninitialized?
Seems to me that
Hi,
Sometime I have to do
int x = 0;
to silence gcc from uninitialized warnings when I know it is
unnecessary. Is that a good idea to add
int x __attribute__ ((uninitialized));
to tell compiler that it is OK for "x" to be uninitialized?
--
H.J.
Hello,
I have run into variable alignment issues, which turned out to be
caused by forward declaration w/o the aligned attribute repeated.
Let me walk you through simple testcases showing different alignments
I see for "misaligned" on gcc 4.4.4 and 4.5.1.
Common type definition:
struct foo { cha
On Fri, 20 Aug 2010, Fang, Changpeng wrote:
>
>
>
>
> >No you should not generate addresses for VCEs that contain a SSA_NAME.
> > I think you should check if get_base_address is a
> >is_gimple_addressable inside gather_memory_references_ref.
>
> There,
>No you should not generate addresses for VCEs that contain a SSA_NAME.
> I think you should check if get_base_address is a
>is_gimple_addressable inside gather_memory_references_ref.
There, TREE_CODE ( get_base_address (ref)) == SSA_NAME
and get_base_
13 matches
Mail list logo
