RE: Could we use VIEW_CONVERT_EXPR to build ADDR_EXPR ?
>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_addressable. However, address expression containing SSA_NAME is NOT considered as a gimple address. Thanks, Changpeng
RE: Could we use VIEW_CONVERT_EXPR to build ADDR_EXPR ?
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, TREE_CODE ( get_base_address (ref)) == SSA_NAME > > and get_base_address (ref) is is_gimple_addressable. > > However, address expression containing SSA_NAME is NOT considered > as a gimple address. You simply can't take an address of such thing. Look at IVOPTs, it has measures to avoid this stuff. Richard.
Forward declarations and variable alignment weirdness
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 { char* a; char b; };
testcase #1:
struct foo misaligned = { 0, 1 };
struct foo *ptr = &misaligned;
4.4.4: 16
4.5.1: 16
No surprise here.
testcase #2:
struct foo misaligned __attribute__((aligned(2))) = { 0, 1 };
struct foo *ptr = &misaligned;
4.4.4: 2
4.5.1: 2
Also all good.
testcase #3:
struct foo misaligned;
struct foo misaligned __attribute__((aligned(2))) = { 0, 1 };
struct foo *ptr = &misaligned;
4.4.4: 8
4.5.1: 16
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? Also the difference between 4.4.4 and 4.5.1 is
interesting.
--
Best Regards
Piotr Jaroszyński
Add uninitialized attribute?
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.
Re: Add uninitialized attribute?
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 there is a lot less typing with the '= 0' variant. However, there have been several instances (particularly in C++) where providing an initial value is somewhat more convoluted. Diego.
Re: Forward declarations and variable alignment weirdness
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
Re: Add uninitialized attribute?
"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 is reasonable. I also think it might be worth
spending a few minutes thinking about whether we can implement some more
general diagnostic suppression mechanism. E.g.,
int x __attribute__ ((ignore ("-Wuninitialized")));
Ian
Re: Add uninitialized attribute?
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 it is OK for "x" to be uninitialized?
Better to call it "initialized", analogous to attribute used/unused.
> I think the general idea is reasonable. I also think it might be worth
> spending a few minutes thinking about whether we can implement some more
> general diagnostic suppression mechanism. E.g.,
>int x __attribute__ ((ignore ("-Wuninitialized")));
Or this.
Bernd
Re: Add uninitialized attribute?
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
>>>
>>> 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 think the general idea is reasonable. I also think it might be worth
>> spending a few minutes thinking about whether we can implement some more
>> general diagnostic suppression mechanism. E.g.,
>> int x __attribute__ ((ignore ("-Wuninitialized")));
>
> Or this.
>
Another usage for this it to specify a value which we don't care
and must provide when calling a function due to function prototype.
Currently I have to do
foo (NULL);
Instead I can do
void *undef __attribute__ ((uninitialized)); // Or something similar
foo (undef);
Compiler can pass some junk to foo.
--
H.J.
RE: Could we use VIEW_CONVERT_EXPR to build ADDR_EXPR ?
> >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_addressable. > > However, address expression containing SSA_NAME is NOT considered > as a gimple address. >You simply can't take an address of such thing. Look at IVOPTs, >it has measures to avoid this stuff. Thanks, Richard: I have a fix based on this suggestion: http://gcc.gnu.org/ml/gcc-patches/2010-08/msg01625.html Changpeng
Re: Add uninitialized attribute?
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
>> spending a few minutes thinking about whether we can implement some more
>> general diagnostic suppression mechanism. E.g.,
>>int x __attribute__ ((ignore ("-Wuninitialized")));
>
> Or this.
FWIW, I think that's overly ambitious.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
Re: Add uninitialized attribute?
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 undefined value. In C++, a syntax like __undefined__() would be plausible; I'm not sure there's a good C syntax. Perhaps you could do what tgmath does. I guess if you had this, you could use it in place of the attribute; int i = __undefined__(); would serve to indicate that you were knowingly not initializing i. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Forward declarations and variable alignment weirdness
> 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? Also the difference between 4.4.4 and 4.5.1 is > interesting. PR45112. See also http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00283.html Paul
