Mailing List Archive

On 1999-11-12 06:46:51 -0800, Pit . wrote:

> >It runs fine on a ALPHA using GNU/Linux and gcc (3 or 4 different
> >versions). So I guess that there is some problem with the
> >optimization. Please try to disable optimization at all (CFLAGS="..."
> >./configure ....).

Sorry that I'm jumping into this thread out of context. But you may
wish to notice that one of the current gcc versions (I think 2.95.1,
does this make sense?) produces bad code when using the -O2
optimization switch on the Alpha. Mutt recently got bitten by this
one.

--
http://www.guug.de/~roessler/

"Pit ." <pit_37@hotmail.com> writes:

> do you mean i should disable any CFLAGS? or should i actually set it to
> "..."? ive tried disabling just about everything with configure.

Well I don't know the way to disable optimization for your compiler;
you have to use thjose flags (or try CFLAGS=" ").

> one of the problems i ran into was any time a preprocessor command was
> indented, the compile bombed. ive fixed a lot of things, and now i only get

Ah. oky. You do not have an Standard C compiler. GnuPG requires a
modern compiler and does not accept old K&R cc with extensions. The
problem here is that Standard C allows

#if foo
#include <bar>
#endif

older compiler only accept

#if foo
# include <bar>
#endif

I won't make any chnages to the code becuase I thing that the modern
form is better readable and we should not stick to ancient syntax
conventions. A small sed script is your friend here.

Because your compiler has problems anyway, you should install gcc on
the machine. It does not make sense to use a compiler which would create
faster code on an Alpha but actually can't compile the source ;-)


--
Werner Koch at guug.de www.gnupg.org keyid 621CC013

> Ah. oky. You do not have an Standard C compiler. GnuPG requires a
> modern compiler and does not accept old K&R cc with extensions. The
> problem here is that Standard C allows
^^^^^^^

Exactly. This is a p_r_o_b_l_e_m_.

> #if foo
> #include <bar>
> #endif
>
> older compiler only accept
>
> #if foo
> # include <bar>
> #endif
>
> I won't make any chnages to the code becuase I thing that the modern
> form is better readable and we should not stick to ancient syntax
> conventions. A small sed script is your friend here.

I think the latter form is more readable, so there you go. The former
obscures the code, and makes it harder to find and separate preprocessor
statements.

If portability comes at such a low cost, I'd recommend the change.

> Because your compiler has problems anyway, you should install gcc on
> the machine. It does not make sense to use a compiler which would create
> faster code on an Alpha but actually can't compile the source ;-)

There is absolutely no point installing gcc on a platform which comes
with a full ANSI C compiler. The cc compiler on Alpha creates better
code than gcc, and has less bugs. It also has very nice diagnostics,
which often surpass gcc's (can't really say one or the other is better,
in general, because both compilers issue a different set of warnings for
the same code :-|)

To put the Alpha C compiler into ANSI mode (with extensions), use
cc -std. This sets __STDC__=0.

To put the Alpha C compiler into strict ANSI mode, use
cc -std1. This sets __STDC__=1.

The compiler can be set at configure time:

$ CC='cc -std' ./configure

Lars Hecking <lhecking@nmrc.ucc.ie> writes:

> I think the latter form is more readable, so there you go. The former
> obscures the code, and makes it harder to find and separate preprocessor
> statements.

I expected such a comment :-)

> To put the Alpha C compiler into ANSI mode (with extensions), use
> cc -std. This sets __STDC__=0.

Right, I remember this from porting some software to VMS.
And now we need to find the autoconf macros which checks this out.


Thanks,

Werner

--
Werner Koch at guug.de www.gnupg.org keyid 621CC013

Werner Koch writes:
> Lars Hecking <lhecking@nmrc.ucc.ie> writes:
>
> > I think the latter form is more readable, so there you go. The former
> > obscures the code, and makes it harder to find and separate preprocessor
> > statements.
>
> I expected such a comment :-)

I hope you take it well :-) And show some good common sense :-))

> > To put the Alpha C compiler into ANSI mode (with extensions), use
> > cc -std. This sets __STDC__=0.
>
> Right, I remember this from porting some software to VMS.
> And now we need to find the autoconf macros which checks this out.

There are none. The closest you can get is AM_PROG_CC_STDC (through
AM_C_PROTOTYPES), but it's of no use in this case. If you run it on
OSF/DecUnix/Tru64, the result is that no extra options are needed
because the decision is based on whether or not the compiler accepts
prototypes (which Dec Unix cc without options does).

The need for more fine grained detection of compiler capabilites/features,
was discussed on the autoconf list, but I don't think any great efforts
went into adding this to the upcoming 2.15 release. Need to check the
CVS, though ...

# @defmac AM_PROG_CC_STDC
# @maindex PROG_CC_STDC
# @ovindex CC
# If the C compiler in not in ANSI C mode by default, try to add an option
# to output variable @code{CC} to make it so. This macro tries various
# options that select ANSI C on some system or another. It considers the
# compiler to be in ANSI C mode if it handles function prototypes correctly.
#
# If you use this macro, you should check after calling it whether the C
# compiler has been set to accept ANSI C; if not, the shell variable
# @code{am_cv_prog_cc_stdc} is set to @samp{no}. If you wrote your source
# code in ANSI C, you can make an un-ANSIfied copy of it by using the
# program @code{ansi2knr}, which comes with Ghostscript.
# @end defmac

Lars Hecking <lhecking@nmrc.ucc.ie> writes:

> OSF/DecUnix/Tru64, the result is that no extra options are needed
> because the decision is based on whether or not the compiler accepts
> prototypes (which Dec Unix cc without options does).

So we have to do yet another test - those configure tests now take
longer that the make run ;-) Adding some documentation might be
easier.

> went into adding this to the upcoming 2.15 release. Need to check the
> CVS, though ...

Can't remember such a think from the commit logs but I may be wrong.


--
Werner Koch at guug.de www.gnupg.org keyid 621CC013