🚀 go-pugleaf

Help!!

I'm running on a sun sparc (IPC) with SunOS 4.1.1.  I've configured gcc-2.2.2 as

    ./configure --target=sparc-sun-sunos4.1

The compiler was built successfully - including the self recompile/compare
steps.  The trouble seems to have to do with doubles in structs.  I have a
struct that looks something like this:

    typedef struct
    {
        enum ExprTokenType type;
        union
        {
    		unsigned ui;
    		int i;
    		char *str;
    		double f;
    		enum Operator oper;
            PTR p;
        } u;
    } ExprToken;

When I assign to u.f The program crashes.  Why?

    token->u.f = (double)cnv_atof(str);

cnv_atof() is a function that converts a string to a double.  This program
works fine using the standard sun C compiler.  Not the new unbundled
compiler, but the old one as shipped with 4.1.1.

As an experiment I replaced double f with float f in the union.  This seemed
to work but the program crashed elsewhere where I was assigning to a double
in a struct.  Here's the context of the second failure:

    void TaskInsert(module_name, when, id, name, args)
        char *module_name;
        double when;
        TaskId id;
        char *name;
        FLL *args;
    {
        TaskInvocation *ti;
    
        ti = (TaskInvocation*)allocate(Lsizeof(TaskInvocation));
        task->module_name(ti) = module_name;
        task->time(ti)   = when;
        task->id(ti)     = id;
        task->task(ti)   = name;
        task->args(ti)   = args;
            .
            .
            .

Here is the TaskInvocation struct

    typedef struct
    {
        double time;
        char *module_name;
        TaskId id;
        char *task;
        FLL *args;
    } TaskInvocation;
 

I have two suspects.  Doubles are not aligned properly within dynamically
allocated structures.  Or, doubles are not passed in and out of functions
correctly.  Does anyone have any ideas?  Are there any known bugs relating
to this area? Do I have the thing configured correctly?  These code
fragments are from a rather large program.  If these problems do not ring a
bell then I can work on producing a small test case - just let me know.

Thanks in advance for any light you can shed on this problem.


Mark Glasser
------------------------------------------------------------------------
markg@nextwave.com                            Nextwave Design Automation
                                                450 San Antonio Road #27
                                                     Palo Alto, CA 94306
                                                    (voice) 415.855.9795
                                                      (fax) 415.855.9792
------------------------------------------------------------------------