This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

aliasing warnings: help



I've been working on aliasing warnings for awhile now.  The sticking
point is the number of spurious warnings you get with any approach,
which makes them nearly useless.

For example, consider the following:

enum alg_code { a, b, c };
struct algorithm
{
  enum alg_code op[32];
};

unsigned int
synth_mult_ok (alg_out)
     struct algorithm *alg_out;
{
  return *alg_out->op;
}

unsigned int
synth_mult_bad (alg_out)
     struct algorithm *alg_out;
{
  return *(enum alg_code *)alg_out;
}

I think we can agree that `synth_mult_ok' should not get a warning and
`synth_mult_bad' should.  However, my current patch
(http://egcs.cygnus.com/ml/gcc/1999-09/msg01050.html) will warn about both:

test.i: In function `synth_mult_ok':
test.i:11: warning: unary * accesses algorithm object as alg_code
test.i: In function `synth_mult_bad':
test.i:18: warning: unary * accesses algorithm object as alg_code

and I believe the problem is that the C front end doesn't adequately
distinguish between the two.  That warning is generated in
build_indirect_ref (in c-typeck.c) and these are the tree structures
which it is being asked to dereference.

synth_mult_ok:
 <nop_expr 0x831f0f8
    type <pointer_type 0x8333acc
        type <enumeral_type 0x8329d2c alg_code
            unsigned permanent type_0 SI
            size <integer_cst 0x8322648 constant permanent 32>
            align 32 symtab 0 alias set 2 precision 32>
        unsigned permanent SI size <integer_cst 0x8322648 32>
        align 32 symtab 0 alias set -1>
    arg 0 <nop_expr 0x831f0e4
        type <pointer_type 0x8334008 type <array_type 0x8333b2c>
            unsigned permanent SI size <integer_cst 0x8322648 32>
            align 32 symtab 0 alias set -1>
        arg 0 <non_lvalue_expr 0x831f0d0 type <pointer_type 0x8333f20>
            arg 0 <parm_decl 0x832009c alg_out>>>>

synth_mult_bad:
 <nop_expr 0x831f0b8
    type <pointer_type 0x8333acc
        type <enumeral_type 0x8329d2c alg_code
            unsigned permanent type_0 SI
            size <integer_cst 0x8322648 constant permanent 32>
            align 32 symtab 0 alias set 2 precision 32>
        unsigned permanent SI size <integer_cst 0x8322648 32>
        align 32 symtab 0 alias set -1>
    arg 0 <parm_decl 0x8320318 alg_out
        type <pointer_type 0x8333f38 type <record_type 0x8333864 algorithm>
            unsigned permanent SI size <integer_cst 0x8322648 32>
            align 32 symtab 0 alias set 1>>>

You can see that modulo a NOP_EXPR the trees are identical.  Maybe
there is some magical way to distinguish them which I'm not aware of,
but if not, to get sane warnings the C front end will have to be
revised to generate 
<component_ref <indirect_ref <parm_decl alg_out>> <field_decl op>> 
here.  Any advice?

zw

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]