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]

Re: type based aliasing again


>  In message <19990908202957F.mitchell@codesourcery.com>you write:
>  > I agree that C is reasonable.  But, it is not technically viable at
>  > compile-time; the violation of the rule is a dynamic property.  For
>  > example, consider:
>  > 
>  >   if (0) {
>  >     /* Do illegal aliasing stuff.  */
>  >   }
>  > 
>  > If we do dead-code elimination late, we might ask questions about the
>  > aliasing in the conditional code.  Since that code never executes,
>  > ANSI says there's no violation.  Warning here is sensible, though,
>  > just as warning on `*((int*) 0) = 3' in the conditional code would be
>  > sensible.
>FYI, this kind of code could be deleted at a variety of stages in compilation
>depending on what optimization exposed the unreachable code (terminology
>note, this is unreachable code, not dead code ;-)
[...]

IMO, when you are considering stuff like this, please replace

  if (0)

with

  scanf ("%d", &i);  /* or whatever, i hate scanf anyway, think READ *, I. */
  if (i)

and the programmer's "out-of-band" promise that anytime that that particular
scanf executes, it will always read a 0 (from stdin).

I'm not *sure* about this, but it looks like this discussion is going
in the direction of "we can do something not quite kosher by finding
all cases of suspect code that won't actually be reached in practice".

If that's the case, it's wrong.

BTW, I agree 100% with this contribution from Mark:

>Saying "Don't violate ANSI/ISO aliasing rules, or else use
>-fno-strict-aliasing" is a simple, easy-to-follow rule.  I don't think
>we should muddy that with confusing semantics depending on GCC
>internals.

I also agree a warning where we *can* detect potential aliasing violations
would be nice.  Leave it to the usual "discovery process" to determine
whether it should be the default, the default for -Wall, whatever.

However, it's my impression that the mere printing, even requesting,
of a warning should make *no* difference in the generated code.  Just
like gcc promises for -g, except, here, I mean no difference in
the generated assembler output, not just the code within that.

In that case, it would be wrong to connect to the printing of a warning
(or the user requesting that type of warning) doing something like
turning off alias analysis.  GCC doesn't, upon warning about
a possible uninitialized variable, silently insert an initialization,
does it?  (By which I mean, we don't document that it does that, right?)

Note that falling back to the "let's just generate a warning" position
isn't a panacea:

  #!/bin/sh, or some approximation thereof

  # Compile $1 vis-a-vis gcc's annoying aliasing behavior and options in $2.
  gcc -Walias $2 -c $1 2>diagnostics.out
  status=$?
  if [ $status != 0 ]
  then
    exit $status
  fi

  # See if any alias warnings were issued, and recompile without alias
  # analysis if so.
  grep -q alias diagnostics.out
  if [ $? = 0 ]
  then
    gcc -fno-alias-analysis $2 -c $1
    status = $?
  fi
  rm diagnostics.out
  exit $status

People who think GCC should have done what has been recommended here,
i.e. revert to no alias analysis upon detecting possible violations
(and warning about them), will probably use a script like the above
to get the desired behavior themselves.

And, they will complain just as loudly when it "stops working", which
will mean, to them, either "no longer catches a particular aliasing
violation in my code, leading to hours of my time tracking down this
GCC bug causing a failure to correctly warn" or "now warns about something
that isn't really a problem, leading to hours of my time tracking
down this loss of performance".

(I'm not saying this sort of end-user behavior is to be expected for
all instances of generating warnings about not-strictly-correct code.
But given the huge amount of attention this problem, which has long
had the simple -fno-strict-aliasing workaround, has gotten on this
list during just this year, I think *this* particular warning is
a candidate for this sort of treatment.)

        tq vm, (burley)


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