Does it crash when:

- clear_to_coloring a memory bitmap?
- clear_to_coloring the screen with the GDI driver?

If the answer is no to both, I suspect the problem to lie in the DirectX driver.

Oh, with a memory bitmap - then it should be driver independent. I'll try it here in linux.

EDIT:

Just to be sure, does the below code crash for you?

#include <allegro.h>

int main(void)
{
    BITMAP *bmp;
    allegro_init ();
    set_color_depth (32);
    bmp = create_bitmap (100, 100);
    clear_to_color (bmp, 0);
    return 0;
}
END_OF_MAIN()

Well, first we should pinpoint down this a bit.. right now it can be anywhere. If the above does crash for Richard - it could be the asm code. If the above does not crash, it may be limited to a different color depth, or, ... well, no point speculating, just let's wait for the result.

Does it crash with clear_bitmap() too?
It shouldn't make a difference, but it's good to know for sure

EDIT: just on the off chance that this changes anything, can you try calling set_gfx_mode() directly after allegro_init() and see if it still crashes?

WTF?!

From the Allegro source code:

/* clear_bitmap:
 *  Clears the bitmap to color 0.
 */
void clear_bitmap(BITMAP *bitmap)
{
   clear_to_color(bitmap, 0);
}

In other words... I don't understand this at all...

Oh, and see my edit above.

Heh, WTF is all I can think as well.. I'd say, either something really weird is going on, or you mixed up the DLL version somehow.

When you compile without any -O option, it doesn't crash, right?

You've removed all the old DLLs and libs, right?

Have you made a clean recompile of your project? When I change allegro versions, I always clean all object files for a project before recompiling. This is nescessary because WIP releases aren't API compatible.

Otherwise, can you reproduce the problems with the test program (allegro/tests/test)?

Possibly. Did you run a make uninstall from the previous version before installing the new one?

I'm wondering why it works without -O. The difference between clear_bitmap and clear_to_color is that with the former, inlining is done within the function in the DLL, while with the latter, inlining to bmp->vtable->clear_to_color is done when you compile.

So another question: Are you sure the headers in %MINGDIR%\include are from 4.1.16? The vtable struct may have changed, therefore bmp->vtable->clear_to_color points to some random memory and it crashes, but only when inlined.

EDIT:

Or, actually, when you executed "make install", did the MINGDIR variable point to the same directory which actually is used by mingw? I.e. if you have mingw in C:\mingw, and in C:\devcpp\mingw.. make sure MINGDIR points to the right one when doing "make install"..

See edit. To manually copy, do this inside the allegro dir:

cp -r include/* MINGDIR/include/

(Sorry, don't know the windows way. But just copy everything in include into the mingdir include..)

That makes me think... shouldn't the definition of clear_to_color() look like

AL_INLINE(void, clear_to_color, (BITMAP *bitmap, int color),
{
   ASSERT(bitmap && bitmap->vtable && bitmap->vtable->clear_to_color);

   bitmap->vtable->clear_to_color(bitmap, color);
})

rather than with only ASSERT(bitmap) as it is now?

Richard: could you try building a debug version of the library (DEBUGMODE=2) and see if you get assertion failures from that anywhere?