Hi Blake,
already done. The current solution (SVN 1180) should work
for all compilers.
Best Regards,
Jürgen
On 7/21/19 9:14 PM, Blake McBride
wrote:
It would be good if a method of initialization
could be developed that doesn't depend on the particular C++
implementation. I'd find it hard to believe that this
couldn't be accomplished.
--blake
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
|