Opened 12 months ago

Last modified 11 months ago

#193 new defect

Monomorphization Failures outside of Functions

Reported by: ajbeach Owned by:
Priority: major Component: cfa-cc
Version: 1.0 Keywords:
Cc:

Description (last modified by ajbeach)

There are certainly multiple bugs here but currently it is unclear exactly how many there are or where the dividing lines are. Currently all of the bugs can be produced with the following set-up:

forall(dtype T) 
void poly0(T &) {}

forall(dtype T | sized(T))
void poly1(T &) {}

forall(otype T)
void poly2(T &) {}

struct wrapper {
    void (*mono)(int &);
};

The first group complain about incompatable pointer assignment inside __global_init__. It appears to be coming from C code. Note for the first case it is just a int * to void * difference but in the other cases the number of parameters is different, likely the hidden polymorphic parameters.

void (*mono0)(int &) = poly0;
void (*mono1)(int &) = poly1;
void (*mono2)(int &) = poly2;

The error messages also change if you attempt to do this for a field of a structure instead of a stand alone function pointer.

The following case produces an invalid thunk, the sizeof and alignof symbols are not defined inside of it but are used.

struct wrapper mono_wrapper1 = { poly1 };

Here there is a resolution failure as it cannot resolve a constructor. The constructor call appears to be on some generated code. I have not yet pinned down what that generated code is though.

struct wrapper mono_wrapper2 = { poly2 };

The last one compiles but I got runtime errors every time I tried to call it, an illegal operation at a very strange location.

struct wrapper mono_wrapper0 = { poly0 };

Switching from = to @= currently fixes the issue. So it seems that trying to insert a constructor call might be the source of the problem. Either because that makes the system forget the function must be monomorphized or it is monomorphized improperly in the new context.

Change History (2)

comment:1 Changed 12 months ago by ajbeach

I made a change to the compiler. I believe it fixes the C-style cases and doesn't change any of the others. Specializations were inserted into the code at the statement level which doesn't work outside of functions (so the generated thunk would be silently dropped). Now they can be added internally or at the global level.

comment:2 Changed 11 months ago by ajbeach

Description: modified (diff)

Updated the description now that the @= cases are working.

Note: See TracTickets for help on using tickets.