5.0 beta 2 - bug? (get_rule and x64-issues)

[aj]

Thanks for a great new release Pelle!!  Bra jobbat!!

I've tried to compile a project that compiled fine on 4.50.113 with the 5.0 beta 2.

I'm getting a "fatal error: Internal error: get_rule()." on a definition line using FREE(x).

Code: [Select]

#define FREE(x)    my_free((void **)&(x))
The argument, x, to the macro, FREE(x), is a pointer sent as a parameter to the function. Example which doesn't compile on 5.0.

Code: [Select]

int my_func(void *ptr) {
        /* does something with ptr */
        FREE(ptr);
        return 0;
}This will result in the get_rule-error on the line containing "FREE(ptr)".

The strange thing is that this compiles perfectly well under the 4.5 and works very good. It's used in multiple places throughout my program and used so often and on so big structures that it'd notice if the FREE(x) didn't really free the memory.



Another strange thing with this is that the x64-version of the EXACT same code WILL compile BUT the resulting executable makes Windows show a MessageBox giving an error-code (0xC000007B = STATUS_INVALID_IMAGE_FORMAT). Nothing at all about the "get_rule"-thing above...
Just a crash!


Also the "Find in files"-Find button doesn't get enabled when entering text in the "Find what"-edit.

EDIT:
Forgot to say that it was the "setup64.exe"-version running on Vista x64. And that the macro-definition is located in a separate header (protected with "#ifndef header_h"), and included from mulitple source files).
...and I haven't been able to reconstruct it when only using one header-file, but will look into that.

[Pelle]

The get_rule() is used during code generation. It's possible to get an error with the X86 generator, but not the X64 generator. I will try to recreate the problem, but if it's possible for you to create a small compilable sample that demonstrates this bug, I'm sure it would help me...

Find-in-files needs a search string (Find what), a search file pattern (In types), and a folder (In folder). Are you sure all of them are filled in? The 'In types' field is usually empty after a fresh setup. I will look some more at this, but I can't reproduce it right now...

[aj]

The error only occurs when setting "Calling conv" -> fastcall in the "Compiler-settings". But that shouldn't be a reason for this to happen?

So I checked it and this is a short piece of code that can reproduce the error.

Code: [Select]

#include <windows.h>

#define FREE(x) my_free((void **)&(x))

void my_free(void** ptr)
{
return;
}

static LRESULT when_free(WPARAM wp)
{
FREE(wp);
return 0;
}I guess this happens since wp is in a register and not in memory/on stack in fastcall-mode.
The 4.5-version will also produce an error if in fastcall-mode ("same" code):

(3d4f9b8->op=LOADP4 at X:\Path\To\PellesC\Projects\project\somefile.c(line number) is corrupt.)
X:\Path\To\PellesC\Projects\project\somefile.c(line number): fatal error: Internal error: function _kids: Bad rule number 0

What's even more annoying is why I still get the 0xC000007B error on the x64 version. But I'll look into that, and return when I know more about it. Still... it looks like there's something wrong with the x64-linker.

[aj]

Tested the beta 4 today, and there's some issues when switching tabs in the "Project > Project Options..."-dialog. If you change to and from the "Assembler"-tab the commandline changes from "Gd" ->"Gz" -> "Gr", which I guess isn't right. At the same time it says "ASFLAGS = -AAMD64#" in the *.ppj.

It also seems that it ignores whatever settings you make to the "Machine Type" the next time you switch back to the "Assembler"-tab.

I'd also like to request a way to convert a 32-bit project into a 64-bit project - that'd be really helpful!

After making a completely new project and adding the *.c and *.h files by hand I'm not getting the 0xC000007B, which might have something to do with the assembler-flags changing and me trying to convert a 32-bit project into a 64-bit one.

[Pelle]

I will look at the 'Assembler' tab thing, and see if there is something I can fix for the release version.

Converting a 32-bit project to a 64-bit project is discussed in another thread, and there will probably be something more automatic in the next release. It's too late in the 'cycle' to add this to version 5 (too much work, too many changes).