vanam srihari kumar wrote:
Thanks for the reply
I am using below compiler flags
PFLAGS = -L -w -tc -fnonstd -ftrap=%all -DSOLARIS -DL_SOLARIS -Qoption cpp -C -Qoption cpp -DSOLARIS
Please find below the explanation of unavailable flags in gpc
-fnonstd-fnonstd = The -fnonstd option causes nonstandard initialization of floating-point arithmetic hardware. By default, IEEE 754 floating-point arithmetic is nonstop, and underflows are gradual. (See the Numerical Computation Guide for details.) The -fnonstd option causes hardware traps to be enabled for floating-point overflow, division by zero, and invalid operation exceptions. These hardware traps are converted into SIGFPE signals, and if the program has no SIGFPE handler, it terminates with a memory dump.
There might not be a direct euqivalent. I found something that might be useful at:
http://www.redhat.com/docs/wp/solaris_port/x99.html
Note that GPC works the same as GCC as far as options are concerned. Where they refer to library routines (e.g., fesetenv) or external names (e.g., LIB_VERSION), the usual ways for GPC to access/create external symbols apply (`external name', or `attribute (name = '...')', as well as equivalent type rules).
-fnonstd also causes the math library to be linked in by passing -lm to the linker.
GPC always does this.
-tcTo check for any name conflicts that your program may have with the standard libraries with which it is to be linked, such as libc. The linker allows name conflicts, which may cause erroneous runtime behavior in your program.
GPC always mangles linker names, so such conflicts cannot arise.
To check for possible name conflicts in the various modules of your program. These conflicts arise if you define a routine with the same name in several modules,
Since GPC supports qualified identifiers now, this is explicitly allowed. When a module or program imports several modules that define the same name (without `qualified'), you get an error on import. That's usually sufficient, rather than checking for same names in unrelated modules.
or refer to an external, but undefined, variable. The linker detects these error situations and does not create the executable file.
GPC's linker always detects this situation. (And actually, I'd be surprised if other linkers didn't. What else should they do?)
You didn't state which of the three purposes you need the option for, but probably you just don't need it under GPC.
hostname% {$w-}
-QoptionThe -Qoption passes an option to the program. The option value must be appropriate to that program and can begin with a plus or minus sign. The program value can be either cpp(1), cppas, iropt, ld(1), ild(1), pc0, or pc3. For example, the following command passes the option -R to cpp and allows recursive macros:
hostname% pc -Qoption cpp -R myprog.p
So:
-Qoption cpp -DSOLARIS
would be just `-DSOLARIS' in GPC. (GPC knows to pass preprocessor options to the preprocessor.)
-Qoption cpp -C
You didn't mention what `-C' means to Solaris cpp. On a Solaris system I have access to, I find this:
: -C Pass all comments (except those that appear : on cpp directive lines) through the prepro- : cessor. By default, cpp strips out C-style : comments.
Do you mean this?
Well, GPC has its own preprocessor (gpcpp) which knows about Pascal, not C. So it doesn't touch C comments anyway, but it handles Pascal comments. Not handling Pascal comments would seem pointless as that's what the preprocessor is there for (among other things).
So I suppose you use this option to avoid C comments to be stripped from Pascal code (wrongly). Though I can't easily see where something that looks like a C comment could appear in a valid Pascal program, except within a Pascal comment. Perhaps something like:
{ This is /* a Pascal comment. } WriteLn; { This is */ another Pascal comment. }
A C preprocessor would remove the apparent C comment and leave this (wrong for Pascal):
{ This is another Pascal comment. }
Is this what you're worried about when you use this option? (A bit more context would generally help in your mails.)
Frank