Part II: Tru64 C optimisation

From: Gavin Kreuiter <gavin_at_transactive.usko.com>
Date: Mon, 27 Nov 2000 18:54:27 +0200

Thanks to all who have replied so far. I shall summarise the answers to my
original questions once I have solved my compiler issues. I felt it
worthwhile to repeat my question, because I now have further information
(thanks to the suggestions raised so far) that I believe is highly
significant.

My current status:
I compile and build a suite of programs using the generic tru64 C compiler,
with standard options. The main routine runs as a daemon, which spawns
children to handle incoming requests. Certain input files always complete
successfully. Other input files always cause the child to dump core. The
core dump always occurs when returning from a routine that is loaded from a
dynamic library (dlopen() et al.). In essence, a debug statement "Returning
now" is never followed by the statement immediately after the call,
"Returned". The routine is called without arguments, and with a standard
int return value.

Nested about four or five levels down is the C code I have appended. When I
compile this *standalone* routine, and relink the executables, consistent
behaviour is observed, depending on the compiler options. Using the default
(-newc, -O1) options, the core dump is caused by "Program terminated with
signal 11, Segmentation fault". When I compile this routine with
EITHER -oldc or -O0, the child completes successfully.

I have also isolated three other modules (containing a host of routines)
that I have to compile with an explicit -O0 for successful execution.

I installed and compiled with gcc 2.95.2. The default (-O0) performs as
Tru64 C with -O0; setting optimisation levels to 1 or more with gcc - also
*only* on the code I have included - results in the segmentation fault. I
am fairly certain that the (a?) stack is being corrupted somewhere, and that
the cause is a piece (or two) of suspect coding style. The program executes
the included code, as well as a host of other routines *after* this code,
before attempting to return from the dynamically-loaded routine (when it
aborts).

The code:

unsigned char checksum (buf, len)
unsigned char *buf;
int len;
{
    int i, sum;
    unsigned char ret;

    sum = 137;
    for (i = 0; i < len; i++)
        sum += (int) buf[i];

    ret = (unsigned char)sum;
    return ret;
}

Testing sequence summary:

$ cc -o cksum.o -c cksum.c
$ (rebuild: no other compilations)
$ (execute: generates code dump)
$ cc -O0 -o cksum.o -c cksum.c
$ (rebuild: no other compilations)
$ (executes successfully)

Apologies for the detail, but I am now really at a loss, and would
appreciate any further suggestions.

Gavin Kreuiter
Received on Mon Nov 27 2000 - 16:50:30 NZDT

This archive was generated by hypermail 2.4.0 : Wed Nov 08 2023 - 11:53:41 NZDT