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 On Sun, Jul 21, 2019 at 1:58 PM Dr. Jürgen Sauermann < mail@jürgen-sauermann.de> wrote: > 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 > > > > > > > > >
