Looks like you forgot to test-compile before committing :-)

#### Making dynamic: post_modules/CritBit Compiling post_modules/CritBit/tree_block_alloc.c In file included from /tmp/pike/src/post_modules/CritBit/ptr_key.h:7:0, from /tmp/pike/src/post_modules/CritBit/tree_block_alloc.c:9: /tmp/pike/src/post_modules/CritBit/bitvector.h:36:6: error: missing ')' in expression

Line 36 is

#if !(defined(PIKE_BYTEORDER)

which obviously has unbalanced parentheses...

Thanks. Two more problems:

1) The Makefile.in contains no rules for creating the c files from cmod. I had too add these lines:

tree.c : tree.cmod

inttree.c : inttree.cmod

floattree.c : floattree.cmod

2) After that, inttree.c was generated, but did not compile:

Compiling inttree.c /tmp/pike/src/post_modules/CritBit/inttree.cmod:41:10: error: expected '=', ',', ';', 'asm' or '__attribute__' before string constant

This is the generated code:

[...] static int IntTree_program_fun_num=-1; #line 41 "/tmp/pike/src/post_modules/CritBit/inttree.cmod" SET_TVAR "iterator_class" "Iterator"; SET_TVAR "tree_class" "IntTree"; SET_TVAR "OBJ2_TREE" "OBJ2_INTTREE"; [...]

It looks like a definition of "SET_TVAR" is missing somewhere...

Unfortunately the Pike build process uses the installed Pike and thus it's precompile.pike.

Yes. This seems to be due to commit 28b72d4e. It wasn't like that before, and should probably be fixed.

On Thu, Jan 27, 2011 at 2:55 PM, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum 10353@lyskom.lysator.liu.se wrote:

Simply removing the lines of code introduced by that commit seems to solve the problem, but I do not know the purpose for which they were added (the commit message wasn't terribly helpful), so I can't say if that is indeed the correct fix...

This was, as far as I know, a "fix" to support cross compilation...

In that case, I might've misattributed the commit. In any case, I've now heard several things about the Pike crosscompilation:

* System Pike will be used * System Pike will be used, but newly installed Pike for post_modules * ...what you just said

and then of course, experienced Pike to just use the system Pike (and precompile.pike). We're a little lost here, but without changes to precompile.pike our project doesn't make sense (tree code is used multiple times and at multiple levels, for example the trees exported to Pike use a block allocator itself using trees again to manage the memory. Without source code reuse, it would blow up and become an unmaintainable mess. :) ).

On Wed, Jan 26, 2011 at 4:45 PM, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum 10353@lyskom.lysator.liu.se wrote:

Hi.  This code seems to depend on Linux-specific header files:

We have worked on that and got it to compile under a virtual FreeBSD 8.1 on a amd64 machine. During this process, we discovered an imcompatibility with GCC 4.2 and resolved that, too. The code is pushed to http://fortranland.com/git/pike.

Unfortunately, the Pike build as a whole does not work on FreeBSD - but this does not depend on whether post_modules/CritBit is in the source tree or not. The CritBits compile without any error or warning. Pike fails to build with the following issue there:

Compiling module.c /usr/home/dev/hash/pike/build/freebsd-8.1-release-amd64/smartlink gcc -DPIKE_SRC_ROOT="/usr/home/dev/hash/pike" -I. -I/usr/home/dev/hash/pike/src -I/usr/home/dev/hash/pike/build/freebsd-8.1-release-amd64/bundles/include -I/usr/local/include -DPIKE_CORE -g -ggdb3 -pthread -O3 -pipe -W -Wall -Wno-unused -Wcomment -Wformat -Wimplicit-function-declaration -Wmultichar -Wswitch -Wuninitialized -Wpointer-arith -Wchar-subscripts -Wno-long-long -Wdeclaration-after-statement -L/usr/home/dev/hash/pike/build/freebsd-8.1-release-amd64/bundles/lib64 -L/usr/home/dev/hash/pike/build/freebsd-8.1-release-amd64/bundles/lib/64 -L/usr/home/dev/hash/pike/build/freebsd-8.1-release-amd64/bundles/lib/. -L/usr/local/lib -R/usr/local/lib -pthread -rdynamic main.o language.o security.o bignum.o pike_cpulib.o interpret.o constants.o cpp.o fdlib.o cyclic.o array.o backend.o callback.o encode.o docode.o dynamic_buffer.o dynamic_load.o error.o fd_control.o fsort.o gc.o hashtable.o lex.o multiset.o signal_handler.o pike_search.o pike_types.o pike_embed.o mapping.o pike_memory.o module_support.o pikecode.o object.o opcodes.o operators.o pike_float.o port.o program.o rbtree.o rusage.o sscanf.o stralloc.o stuff.o threads.o version.o queue.o builtin.o iterators.o facetgroup.o svalue.o las.o builtin_functions.o peep.o module.o `cat modules/linker_options post_modules/linker_options` -lrt -lm -lcrypt -o pike /usr/home/dev/hash/pike/src/object.c:695: Fatal error: Couldn't load master object. No stack - no backtrace. *** Signal 6

Pike from /usr/ports/lang/pike78 compiled fine. More analysis on the Pike build issue is not available as of now, unfortunately.

Thanks!

On Thu, Jan 27, 2011 at 3:50 PM, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum 10353@lyskom.lysator.liu.se wrote:

There is a MINIMUM() macro in pike_macros.h you can use if you like.

I have replaced all occurences of MIN and MAX accordingly and pushed to the GIT on fortranland.com. Additionally I have testcompiled the CritBits with the code changed so that big endian code was used. Compile was fine, but result the result would of course be unusable.

On Thu, Jan 27, 2011 at 6:10 PM, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum 10353@lyskom.lysator.liu.se wrote:

Well, I'll have to inspect this closer in a debugger later...

Not to discourage you, but the error might not be where the crash occurs. The backtrace might help a little, though. In my lack of big endian machines, I've tried emulating some with qemu, but no OS I tried really got on with the virtual machine even that much that I could have completed the installation procedure. Does anyone happen to have a spare login on a big endian machine?

On Fri, Jan 28, 2011 at 4:30 PM, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum 10353@lyskom.lysator.liu.se wrote:

So the bug is that CB_NODE_ALLOC() does not provide enough alignment for an object of type "struct cb_node" in the pointer it returns.

I seem to have less time available this weekend than I thought beforehand, so I have for now simply disabled the block allocator on big endian machines. Could you probably check if at least the tree logic is correct?

Thanks,

tobias

Well, there are still alignment bugs:

Program received signal SIGSEGV, Segmentation fault. 0xffffffff5dc1cd18 in ?? ()

The offending instruction is

0xffffffff5dc1cd18: ld [ %g4 + %l0 ], %g3

%g4 is 0x100a001e0, but %l0 is 0x1, so together they form an odd address. The code comes from line 79 in widestring.h, which says

PREFIX(32);

The definition of PREFIX contains

uint ##n ##_t x = ((*((uint ##n ##_t *)(p1+j)) ^ *((uint ##n ##_t *) (p2+j))));

which will be instantiated to

uint32_t x = ((*((uint32_t *)(p1+j)) ^ *((uint32_t *) (p2+j))));

It seems like "j" is odd (1) which will of course not work for an uint32_t.

Well, it's not terribly complicated. What it all boils down to is this: Any primitive object (i.e. scalar, floating point or pointer) needs to reside at an address which is a multiple of the size of said object. The C compiler will normally take care of this for you, but by performing pointer arithmetic on type-punned pointers it is possible to shoot oneself in the foot.

Hm, I'm unable to fetch your HEAD:

error: Unable to find ce8ecbed625b14643e67e114c904e58320907579 under http://fortranland.com/git/pike Cannot obtain needed object ce8ecbed625b14643e67e114c904e58320907579

Did you forget to run "git update-server-info"?

The thing is that your refs/heads/critbit says that ce8ecbed625b14643e67e114c904e58320907579 is the head, but apparently no such commit object can be found in objects/?

And no, fetch still isn't working. Making a new clone seems to work though, and gets this object. Very weird. Well, that allows me to work around the problem at least (by fetching from the new clone first)...

12 tests are failing, please see http://mc.pp.se/critbit_verify.txt for details.

We have finally gotten hold of a big endian machine and resolved these issues. The code is pushed to the fortranland git repository.

Its rather that we removed something which we should have kept. Its only used in the unused block_alloc code. but that one is still in OBJS and being compiled. I readded the defines, thanks.

arne

On Tue, 22 Feb 2011, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:

Hm, did you commit everything?

Compiling floattree.c In file included from /tmp/pike/src/post_modules/CritBit/floattree.cmod:28:0: /tmp/pike/src/post_modules/CritBit/floattree.h:15:9: warning: #pragma pack(push[, id], <n>) is not supported on this target /tmp/pike/src/post_modules/CritBit/floattree.h:20:9: warning: #pragma pack(pop[, id], <n>) is not supported on this target Compiling post_modules/CritBit/tree_block_alloc.c /tmp/pike/src/post_modules/CritBit/tree_block_alloc.c: In function �free_item�: /tmp/pike/src/post_modules/CritBit/tree_block_alloc.c:93:6: warning: implicit declaration of function �LBITN� /tmp/pike/src/post_modules/CritBit/tree_block_alloc.c:93:17: error: expected expression before �unsigned� {...]

I can't find any declaration of "LBITN" anywhere in the CritBit sources...

We have tried to address all those. We have a set of fallbacks and tests for builtins for the compilers we could think of. One unrelated problem we ran into was that a pike compiled with icc segfaults when compiled with default --with-machine-code. Without that everything seems to be fine. We did not try to compile on windows, however we will give that a try aswell.

arne

On Tue, 22 Feb 2011, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:

Right:

| Begin tests at Tue Feb 22 11:44:41 2011 (pid 5107) | Doing tests in post_modules/CritBit/testsuite (704 tests) | Total tests: 704 (0 tests skipped) | Finished tests at Tue Feb 22 11:44:49 2011

So, the following issues remain then:

• Makefile.in needs to be fixed, see 9a3d000 in the main repository

for reference.

• #pragmas should be removed

• Use of __attribute should be removed, or at least made conditional

on gcc (including version)

• __bultin_X must be tested for, and portable alternatives used if

they do not exist (looks like you did this for __builtin_expect already, so that leaves __builtin_clz, __builtin_clzl, __builtin_clzll, __builtin_bswap32, and __builtin_bswap64)

Great!  Is everything pushed to fortranland?

It is.