Complete.Org: Mailing Lists: Archives: freeciv-dev: September 2002:
[Freeciv-Dev] Re: compile errors on bitvector code with Sun cc (PR#2046)
Home

[Freeciv-Dev] Re: compile errors on bitvector code with Sun cc (PR#2046)

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: freeciv-dev@xxxxxxxxxxx
Cc: bugs@xxxxxxxxxxxxxxxxxxx
Subject: [Freeciv-Dev] Re: compile errors on bitvector code with Sun cc (PR#2046)
From: Jason Short <jdorje@xxxxxxxxxxxxxxxxxxxxx>
Date: Fri, 27 Sep 2002 23:55:18 -0700 (PDT)

Per I. Mathisen wrote:
On Fri, 27 Sep 2002, Gregory Berkolaiko wrote:

The aitools.h problem is much bigger, and probably comes up in many
places in the code.Does anyone know how this can be avoided?  Is there
a more "proper" way to do variable-argument macros, or is that just
impossible in Sun CC?

I don't know anything about it but I notice that freelog (common/log.h) is
implemented as a function rather than macro for non-gnu compilers, with
the comment:

/* For GCC we use a variadic macro; for others we take
the performance hit of a function to get variadic args:
*/

Thanks, Gregory.

Eeek. We can't have doubles for each of the aitools.h macros, and there
will probably be more of them.

The best alternative I can see is to make them functions, but leave them
in the header file for inlining. We could even slap an __inline__ on them
to encourage it...

To cover the whole background for those just tuning in...

The problem is Sun CC, at least, doesn't support variadic macros (variable options in macros). For freelog there's an "#ifdef __GNUC__" check, with a static function declared in the header for other compilers.

Now, this is inelegant since the check is made for __GNUC__ instead of having a proper configure.in check for HAVE_VARIADIC_MACROS. But in many cases this won't matter, since a good compiler can optimize the static function to be inline anyway (gcc will do this with -O3, or if "inline" is specified). So in most cases (i.e. freeciv in a distribution, compiled with -O3) this should not make a difference.

As I understand it, the reason it's important to have this code be macros/inlined is that there are a LOT of freelog calls throughout the code, and most of them can be optimized away, either at compile time (for LOG_DEBUG when DEBUG is not specified) or easily at runtime without the need for any actual function call.

The problem with just labelling the function "static" and putting it in the header file is that gcc will generate all sorts of "aitools.h:61: warning: `unit_log' defined but not used" errors, since in most files the function isn't used. These errors will not be reported (under gcc) if the function is labeled "inline", but then that brings up the inline issue again, which we probably don't want to address before the release (?).

jason




[Prev in Thread] Current Thread [Next in Thread]