Hi,

After noticing my build script all of the sudden stopped working, I tried to backtrack the issue and came to the conclusion that the following commands...

=== commands ===
[svn checkout in a clean directory]
make clean
make CPU_TARGET="x86_64" all
=== end of commands===

... produce an unusable ppcx64 on my OS X 10.6.8 system.

This only happens for revisions >= 26223 (revisions 26220 -> 26222 don't compile).

What I mean by `unusable`:
- Sometimes crashes with a segfault
- Ignores command line parameters, except for the file to compile. If I give this last parameter though, the compiler never returns and starts eating up a lot of CPU usage.
- I know it is rather vague...

Please note that the generated ppcrossx64 *appears* to work.

Anybody got some hints/suggestions on this? Some extra options to pass on to make? Some way to track the issue down to something concrete?

That is the one I mean. It could also be 26220, 26221 or 26222, but those I could not check because these don't compile (26223 is the first after this series that compiles).

It indeed looks unproblematic. That is basically the reason I ask.

Do you really mean 26223? It looks quiet unproblematic?

What exactly do you mean by "don't compile"? 26223 doesn't fix any potential compilation problems (as in "syntax errors") that previous revisions might have introduced.

It indeed looks unproblematic. That is basically the reason I ask.

The only recent problem I know of with darwin/x86-64 was introduced in r26519 and was fixed in 26618.

Jonas

Jonas Maebe wrote

What exactly do you mean by "don't compile"? 26223 doesn't fix any potential compilation problems (as in "syntax errors") that previous revisions might have introduced.

All three fail with: cthreads.pp(360,27) Error: Identifier not found "pthread_attr_destroy".

Which is fixed in r26223, according to the log.

> It indeed looks unproblematic. That is basically the reason I ask. The only recent problem I know of with darwin/x86-64 was introduced in r26519 and was fixed in 26618.

Hmmm. Then the possibilities are:
- Something wrong with certain utilities? (like ar, ....?)
- Wrong starting compiler? (although unlikely, since the makefile would complain. I use 2.6.2)

Jonas Maebe wrote

What exactly do you mean by "don't compile"? 26223 doesn't fix any potential compilation problems (as in "syntax errors") that previous revisions might have introduced.

Nevermind, it does. I don't see anything in r26220 - r26222 that could cause problems for darwin/x86-64 though.

Jonas

Could you please try a compiler from revision r26223 (the first one of which you said compiles again) whereby you *revert* the changes done in r26222 (the revision has x86_64 related changes, so this *could* be the problem) and report back your findings?

Regards,
Sven

You can always try compiling those previous revisions with r26223 applied to further narrow things down.

Jonas

Here you go: r26221 with the changes from r26223 compiles and runs fine.

So it appears that r26222 is the culprit.

Ewald wrote

Here you go: r26221 with the changes from r26223 compiles and runs fine. So it appears that r26222 is the culprit.

The code changed in that revision only gets activated when targeting win64, as far as I can tell.

Jonas

That might be the case. My honesty obliges me to admit that my knowledge of the compiler is zip. Perhaps the two minor changes the log message talks about can shed some light on this new development?

Anyway, if I can provide anything else, just ask.

Just to be sure: your working copy is clean?

I can reproduce it. The problem does not happen when starting the make all with an x86-64 compiler, nor when disabling optimizations. So it seems like it's a bug in the i386 code generator or optimizer that causes a bug in the x86-64 cross-compiler, which in turn causes the generated native x86-64 compiler to be buggy. I guess the change in r26222 somehow manages to trigger that bug... These are some of the worst kind of things to debug :/

Jonas

Florian Klämpfl wrote

Just to be sure: your working copy is clean?

It is clean. To be shure I first removed the entire svn tree and then checked out r26221.

It might be worth to diff the assembler generated by the cross compiler and ppc2? Maybe I should get once a Mac for testing as well :)

Yes, I got the same idea :) It seems the cross-compiled compiler is in fact assuming that it's generating Win64 SEH code for Darwin/x86-64 after that change:

--- compiler.s 2014-02-01 23:32:11.000000000 +0100 +++ ../snew/compiler.s 2014-02-01 23:34:31.000000000 +0100 @@ -118,11 +118,11 @@
.align 3
.globl _COMPILER_$$_COMPILE$ANSISTRING$$LONGINT
_COMPILER_$$_COMPILE$ANSISTRING$$LONGINT:
...
-# [240] try
- leaq 232(%rsp),%rdx
- leaq 256(%rsp),%rsi
- movl $1,%edi
- call FPC_PUSHEXCEPTADDR
- movq %rax,%rdi
- call FPC_SETJMP
- movq %rax,320(%rsp)
- testl %eax,%eax
- jne Lj37
# [241] ExceptionMask:=GetExceptionMask;
...
movq $0,%rdx
movl $1023,%edi
call _VERBOSE_$$_MESSAGE1$LONGINT$ANSISTRING$TMSGQUEUEEVENT -Lj346:
-Lj133:
-Lj37:
- call FPC_POPADDRSTACK
-# [294] DoneCompiler;
- call _COMPILER_$$_DONECOMPILER
-# [296] SetExceptionMask(ExceptionMask);
- movl 120(%rsp),%edi
- call _MATH_$$_SETEXCEPTIONMASK$TFPUEXCEPTIONMASK$$TFPUEXCEPTIONMASK
- movq 320(%rsp),%rax
- testq %rax,%rax
- je Lj38
- call FPC_RERAISE
-Lj38:
+Lj343:
+Lj130:
# [298] DoneVerbose;

Maybe I should get once a Mac for testing as well :)

Maybe Karl-Michael Schindler can give you remote access to his iMac?

Jonas

Ewald wrote

Anyway, if I can provide anything else, just ask.

FWIW, until this is fixed you can still get a working x86-64 compiler by building it like this:

make CPU_TARGET="x86_64" FPC=ppcx64 CPU_SOURCE=x86_64 all

Jonas

Thanks for the pointer!

Would it be correct to always build the compiler like this for 64-bit targets if a native ppcx64 is available?

Yes, taking into account one minor nitpick: the globally installed ppcx64 on Mac OS X is an i386->x86-64 cross-compiler rather than a native x86-64 compiler. That's why the CPU_SOURCE=x86_64 is required, otherwise the makefiles get confused.

Jonas

Florian Klämpfl wrote

It might be worth to diff the assembler generated by the cross compiler and ppc2? Maybe I should get once a Mac for testing as well :)

It can be "fixed" by removing the uses of "exit" from tx64tryfinallynode.create() and tx64tryfinallynode.create_implicit(), or by compiling without regvars. I'll look further at it tomorrow.

It also happens if the cross-compiler is compiled directly with 2.6.2, so all exit-statements in constructors have to be removed from the compiler even once the bug is fixed (since we have to support bootstrapping with 2.6.2 and can't risk mis-compilations, and it's unlikely I'll feel comfortable to merge the eventual fix to 2.6.4).

Jonas

Fixed in r26650/26651.

Jonas

So... does that mean that one shouldn't use "exit" inside a constructor for the 2.6.x series? If so then we should put up a warning somewhere...

Regards,
Sven

Sven Barth wrote

So... does that mean that one shouldn't use "exit" inside a constructor for the 2.6.x series?

Not in combination with regvars. Note that this combination is not guaranteed to go wrong (in fact, it's quite unlikely), it just can go wrong.

If so then we should put up a warning somewhere...

Then we should also warn not to use peephole optimizations on i386 in 2.6.x (http://bugs.freepascal.org/view.php?id=23431 ), and probably about many more things. I don't mind version-specific "FPC known issues" pages on the wiki, but I don't feel like creating and maintaining them myself.

Jonas