RE: [Open64-devel] optimizing extern const

[Mike M. <mm...@nv...>]

I would argue that this is a user error
that leads to undefined behavior.
Because you have inconsistent definitions of x
(const in b.c and not const in c.c).
The gnu linker actually gives an error about
multiple definition of x if you do a static link
of a.o b.o c.o

-----Original Message-----
From: shuxin yang [mailto:shu...@gm...]=20
Sent: Thursday, April 06, 2006 12:00 AM
To: Mike Murphy; ope...@li...
Subject: Re: [Open64-devel] optimizing extern const

It is interesting. The language rule and preempt-rule lead to conflict=20
results.=20
This my example to support my idea.

a.c
=3D=3D=3D
#include <stdio.h>
extern const int x;
extern void foo (void);

int main (int argc, char** argv) {
   fprintf (stderr, "%d\n", x);
   foo ();
   fprintf (stderr, "%d\n", x);
   return 0;
}

b.c
=3D=3D=3D
const int x=3D2000;
c.c
=3D=3D=3D=3D
int x=3D3;
void foo (void) { x =3D 4; }

Now, generate 2 shared objects.
gcc -fpic c.c -c; gcc -shared -o libmyc.so c.o
gcc -fpic b.c -c; gcc -shared -o libmyb.so b.o

Now build the executable:
gcc -L. -lmyb -lmyc a.c; ./a.out

the output is:
2000
4

and if we build the executable in this way
gcc -L. -lmyc -lmyb a.c; ./a.out      # note the libmy{b|c}.so are=20
transposed

the output is
3
4

shuxin yang

Mike Murphy wrote:
> I think the language rules are that "const" means the variable
> is read-only and cannot be assigned to.  A user could cast
> the variable "ec" inside dummy and modify it, but that would then
> be undefined behavior and really a user error to be using "const"
> on the variable.  Similarly if "ec" was not defined const in a
> separate file.  So I think it is legitimate for the compiler
> to optimize this; though it could lead to a user complaint if the
> user code previously relied on this "undefined" behavior.
>
> -----Original Message-----
> From: shuxin yang [mailto:shu...@gm...]=20
> Sent: Thursday, April 06, 2006 5:20 AM
> To: Mike Murphy
> Subject: Re: [Open64-devel] optimizing extern const
>
> I think it is unsafe to do so if we support dynamic link. However, I
am
> not pretty sure.
>
> There may be multiple instances of <ec> across different shared
objects.
> some of <ec>s are indeed constant, other <ec>s are not,
> and those <ec>s referenced in test() may unfortunately bound
> to/preempted by
> a non-constant instance by the dynamic linker.  As luck would have it,
> these non-constant <ec>s referenced by test() are changed inside
> dummy().
>
> shuxin yang
>
> Mike Murphy wrote:
>  =20
>> "extern const" is probably not a common usage,
>> but I ran into it in one of our tests, and discovered
>> that we don't optimize it very well.  E.g. consider the code:
>>
>> extern const int ec;
>> extern void dummy(void);
>>
>> int test (int x, int y)
>> {
>>         if (ec * 3 =3D=3D x)
>>                 return 0;
>>         dummy();
>>         if (ec * 3 =3D=3D y)
>>                 return 1;
>>         return 2;
>> }
>> Ideally we would cse the ec*3,
>> which should be safe since the value of ec
>> will not change across the call.
>> But open64 doesn't do this, because gccfe is only
>> marking initialized constants as ST_is_const_var.
>> This is a case of a const_var with unknown initialization.
>>
>> The fix I came up with is to add to
>> gccfe/tree_symtab.cxx:Create_ST_For_Tree:
>>        if (TREE_CODE(decl_node) =3D=3D VAR_DECL &&=20
>> TREE_READONLY(decl_node)) {
>>                Set_ST_is_const_var(st);
>>        }
>> and then in be/com/be_symtab.cxx:ST_is_const_initialized:
>>    // if is extern const, then is same as unknown const
>>    if (ST_sclass(st) =3D=3D SCLASS_EXTERN)
>>        return FALSE;
>>
>> If anyone sees a problem with this, please let me know.
>>
>>
>>    =20
>
------------------------------------------------------------------------
>  =20
>> This email message is for the sole use of the intended recipient(s)=20
>> and may contain confidential information.  Any unauthorized review,=20
>> use, disclosure or distribution is prohibited.  If you are not the=20
>> intended recipient, please contact the sender by reply email and=20
>> destroy all copies of the original message.
>>
>>    =20
>
------------------------------------------------------------------------
>
>
>  =20