Re: type based aliasing again

[Claus Fischer <claus dot fischer at intel dot com>]

On Thu, 9 Sep 1999, Jeffrey A Law wrote:

:   > A warning in case the user has already chosen an aliasing option
:   > (knowing the ISO rules or knowing (s)he knows nothing about them)
:   > would be an annoyance. A warning in the no-option case, however,
:   > is extremely desirable.
: I think this approach is fundamentally flawed.  In fact, it is this kind of
: approach that has led to so many problems between GCC and the Linux kernel's
: use of certain GCC extensions.

Do you think that (1) the warning approach is flawed, since it warns for
perfectly legal ISO-conformant code, or do you think (2) it is flawed to
disable the warning once the user has chosen an aliasing detection option?

I'm not worried about the linux kernel people; after some groaning they
will clean up the thing and go on. But I see a fundamental gap between
highly technical people (skilled programmers) who are able to understand
aliasing issues, and a lot of C programmers out there who will probably
never understand the aliasing issue.

I've once (in a former job) done a C course for former COBOL programmers
and found that C is a very hard language to explain and train. I'm just
a bit worried that maxing out the standard to the letter might give them
a bad time. There should be a possibility for people who are inexperienced
C programmers to still use GCC somewhat successful, and the aliasing issue
might be one of the stop gaps.

Perhaps it would be feasible to do it the other way around: offer a
prominent warning option -Winexperienced-mode which tells the user
that it will warn when it detects potentially complicated things?
Then this option could switch on the warnings that tell the 
user about aliasing?

I don't have a good solution either.



:   > 4 assume-unaliased

: IMHO This is very very bad.  The problem is while you the programmer may not
: have created any aliases, the compiler might during the translation down to RTL
: and subsequent optimization phases.

Well this option would just tell the compiler that there are no aliases,
guaranteed, on my full responsibility. Like in a function:

   double f(double *x, double *y, long n)
   {
       double a = 0;
       long i;
       for (i = 0; i < n; i++) a += x[i] * y[i];
       return a;
   }

when I the programmer happen to know there can't be an alias (the
memory areas x and y are totally nonoverlapping on the full range)
but the compiler can't detect that since n could have any value.

How far down the translation phase that can be upheld, I cannot say.

I just know that 80% of numerical solver stuff boils down to dot
products of some sort. And the C standard is not very helpful in
that.

Claus



-- 
claus.fischer@intel.com   Intel Corporation SC12-205 ... not speaking
phone   +1-408-765-6808   2200 Mission College Blvd.           for Intel
fax     +1-408-765-9322   Santa Clara, CA 95052-8119