Hi Brian,
thanks. Seems like C++ is getting worse.
My g++ is 4.8.4. and works just fine. Same for 64-bit g++ 7.4.0.
Jürgen
On 7/21/19 7:20 PM, Dr. Brian Callahan
wrote:
Also, for completeness, before trying SVN 1180, I tried 3
different compilers:
1. OpenBSD's default compiler, clang-8.0.0 (this compiler was the
one I was using when I filed the bug report)
2. g++-8.3.0 available in OpenBSD's packages
3. g++-10.0.0 SVN that I auto-build every day
Compilers 1 and 2 both produced an apl that segfaulted. Compiler 3
produced a working apl.
Not sure what if any conclusions we can draw from that, but that's
the data.
~Brian
On 7/21/19 12:51 PM, Brian Callahan
wrote:
Hi Jürgen --
Yes, SVN 1180 fixes things for me. Thank you very much for your
time and help.
~Brian
On 7/21/19 12:36 PM, Dr. Jürgen
Sauermann wrote:
Hi again,
hopefully fixed in SVN 1180. Please let me know if
it works for you.
Best Reards,
Jürgen Sauermann
On 7/21/19 5:40 PM, Dr. Jürgen
Sauermann wrote:
Hi Brian,
that explains it. I am getting this:
++ constructing DynamicObject::all_values
++ constructing DynamicObject::all_index_exprs
++ constructing Workspace::the_workspace
++ constructing StateIndicator::top_level_error
++ constructing Quad_CR::fun
++ constructing Quad_EC::fun
++ constructing Quad_ES::fun
++ constructing Parallel::all_CPUs
++ constructing Macro::all_macros
What happens here is that some macro (actually Macro::Z__LO_RANK_X5_B)
uses
⎕CR before it was initialized. I have hand-crafted
the initialization order according to
my version of the C++ standard in such a way that ⎕CR,
⎕EC, and ⎕ES (the quad functions
that occur in Macros) were explicitly initialized
according to the rules in Chapter 3.6.2
"Initialization of non-local variables" of (my version of)
the C++ standard.
Since I was suspecting an initialization order problem, I
browsed the web about this topic
and learned that different C++ versions differ in the way
they handle the initialization of
static class variables. This is what we see here. The
three Quad_XXX functions are
uninitialized when Macro::all_macros needs them.
There are a number of ways to
deal with this:
1. It could simply be a compiler fault (which one are you
using?). In that case the compiler
should be fixed.
2. The compiler is correct and the problem is caused by
different C++ versions. In that
case you should nail down the C++ version to be used. For
example with (try different
versions, the older the better):
CXXFLAGS=-std
=c++11 ./configure
3. I find a different way to control the initialization
order in a different, C++ version
independent, way. That may take a while though.
The fact that you get a segfault remains disturbing. I
can't quite see how cerr << endl
could fail. However, the reason might be the same (CERR
not initialized before it is used).
I will look into fixing this.
Best Regards,
Jürgen Sauermann
On 7/21/19 4:09 PM, Dr. Brian
Callahan wrote:
Hi Jürgen --
Sure. This is the output:
++ constructing DynamicObject::all_values
++ constructing DynamicObject::all_index_exprs
++ constructing Workspace::the_workspace
++ constructing StateIndicator::top_level_error
++ constructing Parallel::all_CPUs
++ constructing Macro::all_macros
Segmentation fault (core dumped)
~Brian
On 7/21/19 6:45 AM, Dr.
Jürgen Sauermann wrote:
Hi Brian,
thanks for reporting this. It looks like something
goes wrong in the order of initialization
of static class members.
Could you please change line 35 of file src/static_Objects
to read:
bool static_Objects::show_constructors = true;
and recompile and run GNU APL again? It will crash again
but
the output before that is relevant (no stackdump
needed).
The segfault is somewhat obscure because cerr
<< endl fails, but
this happens inside an assertion that should not trigger
in the first place.
Best Regards,
Jürgen
On 7/21/19 3:07 AM, Dr.
Brian Callahan wrote:
Hi
list --
I am in the process of updating the OpenBSD package of
GNU APL to 1.8. It builds ok, but segfaults
immediately upon running the apl binary.
There is a (unfortunately very large) gdb backtrace
attached to this email. It seems to be a problem with
the custom COUT/CERR handling but I'm not well-versed
in GNU APL internals.
Happy to test out any patches.
~Brian