LINNDR%VUENGVAX.BITNET@wiscvm.wisc.EDU (04/18/87)
In article <386@sdd.uucp> Daniel Corbett (dc@sdd.uucp) writes: > Why not utilize a #pragma NO_OPTIMIZE & a counter pragma #pragma OPTIMIZE >around code that is to executed as is Perhaps we can even create various >classes of pragmas for different optimizations: #pragma NO_OPTIMIZE LOOPS, >#pragma NO_OPTIMIZE_STRENGTH, etc. Since I don't have the dpANS nor the ready cash to get one, I may be asking a question already answered there. Is there a mechanism for allowing the temporary change of compilation state (presumably with #pragma)? In the context of the statements quoted above, could I turn optimization off around a particular set of statements and then return to the optimization state previously in effect? This is somewhat analogous to lambda-binding in LISP. If my question is unclear, maybe the following example will clarify. Suppose I have a file containing some expressions that should not EVER be optimized in the midst of expressions that might of might not be optimized depending on the command line arguments. I could have ! <stuff 1> ! #pragma NO_OPTIMIZE ! <stuff that should not be optimized> ! #pragma OPTIMIZE ! <stuff 2) If my compiler has a -Ox switch to govern the level of optimization, where x is in the set {1,2,3}, and I say % cc -O2 example.c Is <stuff 2> optimized at the same level (2) as <stuff 1>? I realize the OPTIMIZE may not even be a pragma in a given compiler, but hopefully the more general question can be understood from this example. David Linn BITNET: LINNDR@VUENGVAX InterNet: LINNDR%VUENGVAX.BITNET@WISCVM.WISC.EDU UUCP: ...!psuvax1!vuengvax.bitnet!linndr AT&T (615)322-7924 USPS: P.O. 3241-B, Nashville, TN, 37235
guy%gorodish@Sun.COM (Guy Harris) (04/20/87)
>Since I don't have the dpANS nor the ready cash to get one, I may >be asking a question already answered there. > >Is there a mechanism for allowing the temporary change of compilation >state (presumably with #pragma)? The ANSI draft standard says NOTHING WHATSOEVER about the interpretation of #pragmas, except that: A #pragma preprocessing directive causes the implementation to behave in an implementation-defined manner. Any pragma that is not recognized by an implementation is ignored. (3.8.6 Pragma directive, p. 82, October 1, 1986 draft). I don't think the ANSI standard will ever say anything about turning optimization on or off, especially about turning *specific optimizations* on or off. (At least I sure *hope* it doesn't; it should *not* assume that the only optimization technologies used in compilers will be the ones known to the authors of the standard at the time they write the standard.)
guy%gorodish@Sun.COM (04/21/87)
>Since I don't have the dpANS nor the ready cash to get one, I may >be asking a question already answered there. > >Is there a mechanism for allowing the temporary change of compilation >state (presumably with #pragma)? The ANSI draft standard says NOTHING WHATSOEVER about the interpretation of #pragmas, except that: A #pragma preprocessing directive causes the implementation to behave in an implementation-defined manner. Any pragma that is not recognized by an implementation is ignored. (3.8.6 Pragma directive, p. 82, October 1, 1986 draft). I don't think the ANSI standard will ever say anything about turning optimization on or off, especially about turning *specific optimizations* on or off. (At least I sure *hope* it doesn't; it should *not* assume that the only optimization technologies used in compilers will be the ones known to the authors of the standard at the time they write the standard.)
eager@amd.UUCP (mike eager) (04/23/87)
Daniel Corbett (dc@sdd.uucp) writes: > > Why not utilize a #pragma NO_OPTIMIZE & a counter pragma #pragma OPTIMIZE >around code that is to executed as is Perhaps we can even create various >classes of pragmas for different optimizations: #pragma NO_OPTIMIZE LOOPS, >#pragma NO_OPTIMIZE_STRENGTH, etc. Section 3.8.6 of the ANSI standard states "Any pragma that is not recognized by the implementation is ignored." I might add, that there is no need for the implementation to tell you that it ignored your advice. What this means, is that NO #pragma can be relied upon to control expression evaluation.
jm36#@andrew.cmu.edu.UUCP (04/24/87)
> From: LINNDR%VUENGVAX.BITNET@wiscvm.wisc.EDU > Subject: Use of #pragma > Date: 17 Apr 87 22:51:27 GMT > > I could have > ! <stuff 1> > ! #pragma NO_OPTIMIZE > ! <stuff that should not be optimized> > ! #pragma OPTIMIZE > ! <stuff 2) > I certainly hope you don't try to feed a file like that through the GNU C compiler anytime between 9AM and 5PM on weekdays. From the documentation on the GNU preprocessor: > The `#pragma' command is specified in the ANSI standard to have an > arbitrary implementation-defined effect. In the GNU C preprocessor, > `#pragma' first attempts to run the game `rogue'; if that fails, > it tries to run the game `hack'; if that fails, it tries to run > GNU Emacs displaying the Tower of Hanoi; if that fails, it reports a > fatal error. In any case, preprocessing does not continue. *ANY* C program which contains a "#pragma" is not portable. One compiler could interpret "#pragma OPTIMIZE" as meaning "Turn on the optimizer" and another interpret it as meaning "Deposit the OP(code) called 'TIMIZE' in the object code." _.John
john@viper.UUCP (John Stanley) (04/24/87)
In article <IUXhaCy00V4FwZ00ZD@andrew.cmu.edu> jm36#@andrew.cmu.edu (John Gardiner Myers) writes: > >I certainly hope you don't try to feed a file like that through the >GNU C compiler anytime between 9AM and 5PM on weekdays. > >From the documentation on the GNU preprocessor: >> The `#pragma' command is specified in the ANSI standard to have an >> arbitrary implementation-defined effect. In the GNU C preprocessor, >> `#pragma' first attempts to run the game `rogue'; if that fails, >> it tries to run the game `hack'; if that fails, it tries to run >> GNU Emacs displaying the Tower of Hanoi; if that fails, it reports a >> fatal error. In any case, preprocessing does not continue. (wiping tears from eyes :^) Thanks for that tidbit John, I haven't laughed that hard in -months-! --- John Stanley (john@viper.UUCP) Software Consultant - DynaSoft Systems UUCP: ...{amdahl,ihnp4,rutgers}!{meccts,dayton}!viper!john
gwyn@brl-smoke.ARPA (Doug Gwyn ) (04/26/87)
GNU is probably doing us all a favor by making it blatantly obvious that #pragma MUST NOT BE USED in portable code.
iwm@doc.ic.ac.uk (Ian W Moor) (05/10/87)
It is fairly obvious from the that the use of #pragma as currently specified
is implementation defined, however I think that it should be tied down a
bit more. I have used two Pascal compilers, both of which used the
semi-standard 'comment starting with a $' syntax for directives, but the
directives meant different things: (*$C+*) meant enable runtime checks to
one compiler and use a less strict type compatability check to the other.
Now seems to be the time to prevent this kind of thing. I would like to see
the standard list the pragmas (pragmata ?) that compilers might be expected
to recognise and their syntax - obviously this would not be an exclusive
list. Thus : if a compiler recognises the pragma "no_optimize" it will have
the effect of disabling optimization; conversely if the compiler has a
pragma for disabling optimization it will be of this form. A particular
compiler would be free to support more esoteric #pragma settings; but
porting code might be a little easier.
Wish 2 : compilers should be provided with a command-line option requesting
them to flag unrecognised pragmas, again as an aid to portability.
--
Ian W Moor
UUCP: seismo!mcvax!ukc!icdoc!iwm
ARPA: iwm%icdoc@ucl
Department of Computing Whereat a great and far-off voice was heard, saying,
Imperial College. Poop-poop-poopy, and it was even so; and the days
180 Queensgate of Poopy Panda were long in the land.
London SW7 Uk.