[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug-glpk] [Fwd: Glpk bugs]

From: Andrew Makhorin
Subject: [Bug-glpk] [Fwd: Glpk bugs]
Date: Mon, 29 Jul 2013 05:32:04 +0400

-------- Forwarded Message --------
From: Charles Brixko <address@hidden>
To: address@hidden
Subject: Glpk bugs
Date: Mon, 29 Jul 2013 02:28:28 +0200

I tested glpk-4.52.1 on Fedora 19 64 bits on AMD 8350.
1) The "-march=bdver2" option has an influence on the treatement of the
gmu-35-40.mps from MIPLIB2010.
make CFLAGS="-O2"  will terminate the proximity search and generate a
lot of "Warning: numerical instability (dual simplex, phase II)"
make CFLAGS="-O2 -march=bdver2"   will block :
glpsol --fpump --proxy --cuts  gmu-35-40.mps
stops the trace after the line :
>>>>> it:  18:   mip = -2.341785e+06;   elapsed time 6.4 sec.s
It goes on running more than one hour after that line.
It is the only one showing this behaviour I saw.
The situation might have to be transmitted to gcc.
2) The use of NDEBUG which is standardised by C ANSI for assert()
control, has a consequence in symphony-5.5.0 compilation :
The glpk (4.48) installable from the Fedora repository is not installed.
The following is the symphony-5.5.0 installation :
cd SYMPHONY-5.5.0/ThirdParty/Glpk
./get.Glpk (to install the 4.48 version, chosen by Symphony-5.5.0)
cd ../.. (to SYMPHONY-5.5.0)
export ADD_CFLAGS="-march=bdver2 -Wno-conversion
-Wno-unused-but-set-variable -Wno-maybe-uninitialized
export ADD_CXXFLAGS="$ADD_CFLAGS -Wno-reorder"
./configure --with-gmpl --prefix=...
make 2>fileWithErrorsAndWarnings
I get the "make" following warnings :
In file included from glpk/src/amd/amd_1.c:28:0:
glpk/src/amd/amd_internal.h:10:0: warning: "NDEBUG" redefined [enabled
by default]
#define NDEBUG
<command-line>:0:0: note: this is the location of the previous
and the same for each *.c file in ThirdParty/Glpk/glpk/src/amd and
There is not such warning when compiling Glpk 4.52.1 alone (neither glpk
The use of a more "private" variable name (ex.: GLPKAMDDEBUG instead of
NDEBUG) solved this problem (I tried).
Thank you for your reading
Charles Brixko

reply via email to

[Prev in Thread] Current Thread [Next in Thread]