forum.alglib.net

i have just download the newest cpp version(3.0).
it looks like a very solid build.

my first try is to build the test_c and test_i files.
i got test_c running without any problem, but failed on test_i.

here is the error msg:
Compiling test_i.cpp
test_i.cpp: In function `int main()':
test_i.cpp:323: error: `_alloc_counter' is not a member of `alglib_impl'
test_i.cpp:3989: error: `_alloc_counter' is not a member of `alglib_impl'
make: *** [test_i.o] Error 1

and here is the make file i used:
TARGET = alglib_test

CFLAGS = -O3 -I ~/proj/alglib/src -Wall

LFLAGS =

CC = g++

SRC = test_i.cpp
SRC += ~/proj/alglib/src/ap.cpp
SRC += ~/proj/alglib/src/alglibinternal.cpp
SRC += ~/proj/alglib/src/alglibmisc.cpp
SRC += ~/proj/alglib/src/dataanalysis.cpp
SRC += ~/proj/alglib/src/diffequations.cpp
SRC += ~/proj/alglib/src/fasttransforms.cpp
SRC += ~/proj/alglib/src/integration.cpp
SRC += ~/proj/alglib/src/interpolation.cpp
SRC += ~/proj/alglib/src/linalg.cpp
SRC += ~/proj/alglib/src/optimization.cpp
SRC += ~/proj/alglib/src/solvers.cpp
SRC += ~/proj/alglib/src/specialfunctions.cpp
SRC += ~/proj/alglib/src/statistics.cpp

TMP = $(SRC:.cpp=.o)
OBJ = $(TMP:.c=.o)

$(TARGET): $(OBJ)
@echo Linking $@
@$(CC) $(LFLAGS) $(OBJ) -o $@
@echo Build Complete

.cpp.o: $<
@echo Compiling $<
@$(CC) -c $(CFLAGS) $< -o $@

clean:
@rm -f $(OBJ) $(TARGET)
@echo All object files and binaries removed

any insight as to why test_i failed?
thanks,

rhine

You've forgot to define AE_USE_ALLOC_COUNTER at the global level as indicated in manual.

I think that in the next release definition of this symbol will become optional, but currently it is needed to compile test_i

thanks for the suggestion.
any insight on why that after successfully compiled it,
when run test_i.cpp, the program hang after this output:
C++ tests. Please wait...
0/66
matinv_d_r1 FAILED
matinv_d_c1 FAILED
matinv_d_spd1 FAILED
matinv_d_hpd1 FAILED

from double checking the code, it is hang on
TEST matinv_t_r1

thanks a lot,
rhine

Can you post here:
* version of GCC (it was GCC, right?) you used
* OS version
* CPU type and mode (32-bit? 64-bit?)
* optimization settings (were -O3, right?)

If you have time, can you replace


in the beginning of test_i.cpp by



any try to compile/execute test one more time. Did it still outputs "matinv_d_r1 FAILED"? (matinv_d_r1, not matinv_c_r1; former may disappear, while latter will remain).

_spoil_scenario variable is an index of crash test applied to the function being investigated. -1 means than we just try to calculate result without crash tests, values from 0 to 6 denote different ways of spoiling inputs with NAN/INF or resizing arguments. I suspect that there is a bug in handling of exceptional situations, but normal execution should be OK.

I also suspect that it can be GCC's bug, because recently I've discovered one which was related to the same topic - handling of complex conversions between doubles, pointers, ints, which were needed to detect NAN/INF in efficient and portable manner. For example, following code was working under -O0 and -O1 (and under MSVC with any king of optimization settings), but failed under GCC with -Os:



This bug was fixed in ALGLIB 3.0.0 (code was rewritten to avoid triggering it), but maybe there are another possibilities to step into it.

thanks a lot for quick feedback.

info on my environment:
g++: gcc version 3.4.6
os: redhat
cpu: x86_64
optimization: -O3

by replacing scenario limit from 7 to 0,
the output becomes:
C++ tests. Please wait...
0/66
matinv_d_c1 FAILED
matinv_d_spd1 FAILED
matinv_d_hpd1 FAILED

so matinv_d_r1 disappeared,

i'm running ALGLIB 3.0.0
thanks,
colin.

i'm pretty sure it's an optimization problem.
if i remove -O3 to compile in debug mode,
test passes through with the output as:
C++ tests. Please wait...
0/66
50/66
66/66

any idea why -O3 failed?
thanks,
rhine.

it's interesting that when compiled in debug mode:
hardware: little-endian

whereas: when compiled with -O3
hardware: mixed-endian

if not -O3, any other optimization flag you suggest?
thanks,
rhine

Looks like it is bug in detection of NAN's and/or INF's. And with 95% probability it is GCC bug - 3.4 was very buggy release, and even GCC 4.4.1 was prone to some errors (like generation of incorrect code for accessing parts of double variable by converting double* to int*).

I'll install GCC 3.4.6 on some separate location and will try to reproduce this bug. Don't know, however, when I'll issue a fix - in the end of a month (along with ALGLIB 3.1) or earlier. However, if you want, I can send you development snapshot as soon as it will be ready.

The main suspect is GCC, as I told before :)

While working on another bug, I've spend several hours examining assembly output and trying to understand why my Intel Core 2 suddenly became "mixed endian hardware". And finally I've found that it is just GCC bug - assembly output contained clearly incorrect operations.

I think that you can try to test ALGLIB with -O1 or -O2. If all tests are passed, it works. Alternatively you can upgrade to the newer version of GCC. Or wait until I'll make another release which avoids triggering this bug.

-O1 works while -O2 doesn't.
I'll be looking forward to your next release.
again, thanks a lot for your quick response.
rhine.