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] |
Jeff writes: > In general, we are going to be doing alias checks across basic blocks in > support of global optimizations. So we can't assume that just because > two memory reerences are in different blocks that we will not ask about the > aliasing relationship between them. This, and Mark's examples, make clear that just because we see two references to the same address that are of different (non-char *) types, we can't conclude automatically that the user has violated the rules. We'd have to know somehow that one of the references represents the true dynamic type and the other represents some other type. This makes things a little trickier. I think we're going to need to try out some patches so that we can do some experimentation. How many false triggers would we get if we followed my original naive approach (perhaps using Mark's alterative B modification: issue the warning but proceed using the ANSI rules)? I don't think it's appropriate for us to throw up our hands and say the problem is too hard. There's a lot of code out there that breaks the rules, and users will need at least some help finding it. Otherwise people will just start putting -fno-strict-aliasing in all their Makefiles, and Mark's work will not benefit users.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |