I guess I can imagine that macro expansion might result in some
cases where strict-aliasing is of benefit. Most people fail to use a
temporary in a macro, probably because __typeof__ is gcc-only.
I can probably fit 20 lines of code on a readable slide. Ideas?
In C++, this:
f (vector &vec)
{
Richard Kenner wrote:
Since humans have to do a bit of alias analysis when maintaining
or writing code, the extra clarity of pulling things into temporary
variables isn't wasted.
Sorry, I don't follow. Why should we want to do "a bit of alias analysis"
when maintaining or writing code? It wou
> Since humans have to do a bit of alias analysis when maintaining
> or writing code, the extra clarity of pulling things into temporary
> variables isn't wasted.
Sorry, I don't follow. Why should we want to do "a bit of alias analysis"
when maintaining or writing code? It would seem a far bette
On 11/29/06, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
>> int f(int *a, float *b)
>> {
>> *a = 1;
>> *b = 2.0;
>> return *a == 2;
>> }
>>
>
> Problem: people don't write code that way. (well I hope not)
> People declare a few local variables, load them with data via
> the pointers, do stuff
> > > I think there are 3 aliasing possibilities here:
> > > 1. known to alias
> > > 2. known to not alias
> > > 3. may alias
> >
> > Actually there is only 2, it may alias or not.
>
> Actually, he's right (and both you and Richard are wrong).
>
> The standard taxonomy of classifications for two
Paolo Bonzini wrote:
for(i = 0;i<*t;i++)
*f += 1.0;
This one is pretty realistic, especially if you consider C++ and inlining:
Don't you think that a convincing argument here has to be based
on actual timings with and without strict aliasing. It would
be interesting to see cases where that
for(i = 0;i<*t;i++)
*f += 1.0;
This one is pretty realistic, especially if you consider C++ and inlining:
struct s {
int size;
float *data;
};
void f(struct s *d, struct s *s)
{
int i;
for (i = 0; i < s->size; i++)
int f(int *a, float *b)
{
*a = 1;
*b = 2.0;
return *a == 2;
}
Problem: people don't write code that way. (well I hope not)
People declare a few local variables, load them with data via
the pointers, do stuff with the local variables, then save back
the results via the pointers.
So that
> I think there are 3 aliasing possibilities here:
> 1. known to alias
> 2. known to not alias
> 3. may alias
Actually there is only 2, it may alias or not.
Actually, he's right (and both you and Richard are wrong).
The standard taxonomy of classifications for two memory accesses is:
Must-ali
> base+offset really only helps in cases like:
>
> int t[100];
> int t2[100];
> t[20] =1;
> t2[30] = 2;
> if (t[20] != 1)
> abort ();
In the more general case, base plus offset helps in the Fortran style where
everything is done with arrays (Ada is like this too in typical usage).
So if you ha
>
> On 11/28/06, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> > > I often need to convince people that gcc is not just
> > > defective for doing random nonsense to code which
> > > violates the C and C++ aliasing rules. Not that I'm
> > > real sure myself actually, given that gcc is able to
> > > ge
> It doesn't help that the standards are only available for $$$ or
> as contraband.
It's an unfortunate cultural issue that C programmers traditionally don't
use the standard on a regular basis. There are other languages where
a programmer would never think of writing code without a language re
On 11/28/06, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> I often need to convince people that gcc is not just
> defective for doing random nonsense to code which
> violates the C and C++ aliasing rules. Not that I'm
> real sure myself actually, given that gcc is able to
> generate warnings for all
> The best examples would involve optimizations which
> could not be performed if gcc did what people normally
> expect from a simple pointer cast and wrong-type access.
> I doubt such examples exist, but I hope they do.
Simple examples exist and I see that later in this thread you were sent
one o
> I often need to convince people that gcc is not just
> defective for doing random nonsense to code which
> violates the C and C++ aliasing rules. Not that I'm
> real sure myself actually, given that gcc is able to
> generate warnings for all the normal cases, but anyway...
> I'm up against the id
I often need to convince people that gcc is not just
defective for doing random nonsense to code which
violates the C and C++ aliasing rules. Not that I'm
real sure myself actually, given that gcc is able to
generate warnings for all the normal cases, but anyway...
I'm up against the idea that Vis
16 matches
Mail list logo
