This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fix warnings and errors building libiberty with pcc on vax-dec-ultrix4.3


> The vax CPP behaves the same.  So, the md5.c code is ok and the gcc
> warning is bogus because it comes in the ISO preprocesor which
> pre-expands arguments.
> 
> On a slightly different subject, I noticed in reworking the PA
> backend to use TARGET_OS_CPP_BUILTINS and TARGET_CPU_CPP_BUILTINS,
> that builtin_define_std still adds a traditional predefine when
> -ansi is not specified.
> 
> The HP C compiler on hpux has three levels: classic, ansi-extended
> and ansi.  The PA backend has traditionally provided a namespace
> similar to the HP class namespace except that __CLASSIC_C__ is
> not defined and __STDC_EXT__ is defined.  GCC also adds some
> extra ansified symbols that aren't in the namespace of the HP
> compiler.  Thus, in effect, we have a standard C compiler using
> a traditional namespace.
> 
> I am tempted to change the namespace under hpux 10.X and 11 to
> make it closer to the ansi-extended namespace.  This would entail
> not defining hppa, unix and various PWB symbols.
> 
> I tried just defining the traditional symbols when the option
> -traditional-cpp was given but the struct cpp_reader is incomplete
> in c-common.c where the above TARGET macros are expanded.
> 
> Any thoughts on what to do about traditional predefines?

You've lost me completely I'm afraid.  What's a "traditional predefine"?

Neil.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]