jackklein@spamcop.net (Jack Klein) writes:

| Yes, misuse of the restrict qualifier invokes undefined behavior.
| That makes it no different than the other two qualifiers, const and
| volatile.

And I'm not convinced that I want undefined behaviour expansion.
This is a case where the camel nose makes me unsympathetic to seeing
the rest.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Gabriel Dos Reis <dosreis@cmla.ens-cachan.fr> wrote:
+ jackklein@spamcop.net (Jack Klein) writes:
+
+ | Yes, misuse of the restrict qualifier invokes undefined behavior.
+ | That makes it no different than the other two qualifiers, const and
+ | volatile.
+
+ And I'm not convinced that I want undefined behaviour expansion.
+ This is a case where the camel nose makes me unsympathetic to seeing
+ the rest.

If I understand correctly, using the restrict qualifier gives
conforming implementations permission to generate more aggressively
optimized code, specifically, code that otherwise might not conform in
cases in the presence of aliasing.

It seems to me that this camel had his nose under the tent when
undefined behavior was attached to situations where, between one
sequence point at the next, either:

  - an object gets modified more than once, or

  - an object gets modified and the old value gets used other
    than for computing the new value.

AFAIK, this loophole serves no useful purpose except in cases where
unanticipated aliasing might occur.

Tom Payne

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Would it be possible to realize a facility that offers a way to
differentiate between aliased and non-aliased objects at compile time?

If for example the compiler knows that two pointers point to the same
object, then it should call a function which is written for that case.
Otherwise it should call a potentially faster function. This might be
realized with some form of overloading or specialization.

It might be useful to differentiate between three cases:

 1) There is no aliasing
 2) There is aliasing
 3) It cannot be deduced at compile time
    if there is aliasing or not

How hard would it be to realize something like that if it should work
for more than the most trivial cases, in other words, how likely would
case 3) be?


Michael

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Wed, 17 Dec 2003 00:41:27 +0000 (UTC), c141592653589@hotmail.com
(MJ) wrote in comp.std.c++:

> Would it be possible to realize a facility that offers a way to
> differentiate between aliased and non-aliased objects at compile time?
>
> If for example the compiler knows that two pointers point to the same
> object, then it should call a function which is written for that case.
> Otherwise it should call a potentially faster function. This might be
> realized with some form of overloading or specialization.
>
> It might be useful to differentiate between three cases:
>
>  1) There is no aliasing
>  2) There is aliasing
>  3) It cannot be deduced at compile time
>     if there is aliasing or not
>
> How hard would it be to realize something like that if it should work
> for more than the most trivial cases, in other words, how likely would
> case 3) be?
>
>
> Michael

The 1999 C language standard update added the keyword "restrict" to
that language.  Syntactically it is a qualifier like "const" and
"volatile".  It allows the programmer to specify to the compiler which
objects are not aliased.

I do not remember seeing any discussion here as to whether the C++
committee has considered adopting the restrict keyword in a future
version of the C++ standard.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

jackklein@spamcop.net (Jack Klein) wrote in message news:<2irvtvktt66tu62gf15fo3jhs63mnosgig@4ax.com>...
> On Wed, 17 Dec 2003 00:41:27 +0000 (UTC), c141592653589@hotmail.com
> (MJ) wrote in comp.std.c++:
>
> > Would it be possible to realize a facility that offers a way to
> > differentiate between aliased and non-aliased objects at compile time?
> >
> > If for example the compiler knows that two pointers point to the same
> > object, then it should call a function which is written for that case.
> > Otherwise it should call a potentially faster function. This might be
> > realized with some form of overloading or specialization.
> >
> > It might be useful to differentiate between three cases:
> >
> >  1) There is no aliasing
> >  2) There is aliasing
> >  3) It cannot be deduced at compile time
> >     if there is aliasing or not
> >
> > How hard would it be to realize something like that if it should work
> > for more than the most trivial cases, in other words, how likely would
> > case 3) be?

I expect that case 3) would be far more common than one might wish due
to the separate translation unit model of compilation.  Without
inter-translation-unit analysis there would be little way for the
compiler to detect aliasing.  There are certainly other code analysis
tools that do whole-program analysis and could more reliably detect
aliasing, but the compiler is more restricted in what it looks at.

> >
> >
> > Michael
>
> The 1999 C language standard update added the keyword "restrict" to
> that language.  Syntactically it is a qualifier like "const" and
> "volatile".  It allows the programmer to specify to the compiler which
> objects are not aliased.

The "restrict" keyword allows the programmer to specify to the
compiler which pointers the programmer believes are not aliased.
Unless I misread, Section 6.7.3.1 of the "C" standard indicates that
the responsibililty for ensuring that this belief is correct lies with
the programmer, and not with the compiler.  Given that, I see
"restrict" as an optimization hint to the compiler, but one with
potentially disastrous consequences if the programmer is incorrect.

Randy.

>
> I do not remember seeing any discussion here as to whether the C++
> committee has considered adopting the restrict keyword in a future
> version of the C++ standard.
>
> --
> Jack Klein
> Home: http://JK-Technology.Com
> FAQs for
> comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
> comp.lang.c++ http://www.parashift.com/c++-faq-lite/
> alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq
>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Wed, 17 Dec 2003 21:48:26 +0000 (UTC), rmaddox@isicns.com (Randy
Maddox) wrote in comp.std.c++:

> jackklein@spamcop.net (Jack Klein) wrote in message news:<2irvtvktt66tu62gf15fo3jhs63mnosgig@4ax.com>...
> > On Wed, 17 Dec 2003 00:41:27 +0000 (UTC), c141592653589@hotmail.com
> > (MJ) wrote in comp.std.c++:
> >
> > > Would it be possible to realize a facility that offers a way to
> > > differentiate between aliased and non-aliased objects at compile time?
> > >
> > > If for example the compiler knows that two pointers point to the same
> > > object, then it should call a function which is written for that case.
> > > Otherwise it should call a potentially faster function. This might be
> > > realized with some form of overloading or specialization.
> > >
> > > It might be useful to differentiate between three cases:
> > >
> > >  1) There is no aliasing
> > >  2) There is aliasing
> > >  3) It cannot be deduced at compile time
> > >     if there is aliasing or not
> > >
> > > How hard would it be to realize something like that if it should work
> > > for more than the most trivial cases, in other words, how likely would
> > > case 3) be?
>
> I expect that case 3) would be far more common than one might wish due
> to the separate translation unit model of compilation.  Without
> inter-translation-unit analysis there would be little way for the
> compiler to detect aliasing.  There are certainly other code analysis
> tools that do whole-program analysis and could more reliably detect
> aliasing, but the compiler is more restricted in what it looks at.
>
> > >
> > >
> > > Michael
> >
> > The 1999 C language standard update added the keyword "restrict" to
> > that language.  Syntactically it is a qualifier like "const" and
> > "volatile".  It allows the programmer to specify to the compiler which
> > objects are not aliased.
>
> The "restrict" keyword allows the programmer to specify to the
> compiler which pointers the programmer believes are not aliased.
> Unless I misread, Section 6.7.3.1 of the "C" standard indicates that
> the responsibililty for ensuring that this belief is correct lies with
> the programmer, and not with the compiler.  Given that, I see
> "restrict" as an optimization hint to the compiler, but one with
> potentially disastrous consequences if the programmer is incorrect.
>
> Randy.
>
> >
> > I do not remember seeing any discussion here as to whether the C++
> > committee has considered adopting the restrict keyword in a future
> > version of the C++ standard.

Yes, misuse of the restrict qualifier invokes undefined behavior.
That makes it no different than the other two qualifiers, const and
volatile.

It is no more than a hint.  The C standard specifically states that
proper use of the restrict qualifier will have absolutely no effect on
the output of a strictly conforming compiler, so just like the inline
keyword it is a hint that the compiler can completely ignore at all
times.

Compilers can already do the analysis the OP wants in certain cases,
and certainly some do when all the objects are in scope.

But as you pointed out, C and C++ have a separate compilation model,
and these cases tend to be rather few and far between.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]