Re: VOLATILE problem

[Karim BELABAS <Karim.Belabas@math.u-psud.fr>]

[Igor:]
> I've made a practice of downloading a gcc-2.96 development snapshot
> weekly and compile PARI with it.  About a month ago it started
> complainig about VOLATILE void type for function err().  I  posted
> about it on their mailing list, but, as in 90% times before, have been
> ignored.  So in case this is a compiler feature and not a bug, and
> it'll making it into the official gcc release, I wanted to clarify,
> what does VOLATILE void type mean, why we need it and can we do away
> without it? 

Actually, VOLATILE is a macro expanded to "__volatile__" which is a gcc
specific keyword (volatile belongs to ANSI C but some old compilers don't
know about it, so it's protected within this macro). [ we use "__volatile__"
and not "volatile" because volatile would be rejected by gcc -traditionnal ]

\begin{aside}

Applied to a variable it prevents gcc from stuffing it in a register
without your asking for it and guarantees its value will survive a longjmp
(default behaviour for all variables with -traditionnal flag).

As a function attribute it tells the compiler that the function is not
supposed to return. Supposedly this produces more efficient code (useless
in this case) and more importantly it should prevent some spurious warnings
such as in

  volatile void fatal();

  GEN f(int OK)
  {
    if (OK) return OK;
    fatal();
  }

then the compiler won't issue the usual Warning ("control reaches end of
non-void function"). In this way you don't clutter the screen with useless
Warnings and don't miss the important ones.

Unfortunately, this trick doesn't work at all if you invoke gcc -O3 -Wall
for instance (without -O3, it does work), and the version of lint that I
have doesn't care about it either. So it's not that useful in this guise.

\end{aside}

Anyway, the function err() can now return [if you trap() some exceptions],
and it has long been used to issue Warnings, which do also return. Hence
the __volatile__ qualifier is misattributed here. This is probably what
gcc-2.96 detected. I removed it from the function prototype.

[ one other solution would be to ensure err() _never_ returns, but I don't
see a practical way to retain trap() in this case ]

Cheers,

  Karim.
__
Karim Belabas                    email: Karim.Belabas@math.u-psud.fr
Dep. de Mathematiques, Bat. 425
Universite Paris-Sud             Tel: (00 33) 1 69 15 57 48
F-91405 Orsay (France)           Fax: (00 33) 1 69 15 60 19
--
PARI/GP Home Page: http://www.parigp-home.de/