Compiler-dependent bug with nested lists
Dear GiNaC developers, I noticed a strange bug, which only happens with some compiler versions. In some cases, nested lists collapse into a flat list. Consider the following program:
#include <iostream> #include "ginac/ginac.h"
using namespace GiNaC; int main(int argc, const char** argv) { std::cout << lst{lst{1}} << std::endl; return 0; }
I tested this with GCC 11.4.0 and clang 21.1.0. With those compilers, it correctly prints
{{1}}
But with clang 19.1.7, it instead yields
{1}
I tested some other cases and it seems that the issue occurs whenever a list has a single element which is also a list. Best regards Florian
Dear Florian, Thanks for debugging into this problem! On 2/5/26 10:05 AM, Florian Lorkowski wrote:
I noticed a strange bug, which only happens with some compiler versions. In some cases, nested lists collapse into a flat list. Consider the following program:
#include <iostream> #include "ginac/ginac.h"
using namespace GiNaC; int main(int argc, const char** argv) { std::cout << lst{lst{1}} << std::endl; return 0; }
I tested this with GCC 11.4.0 and clang 21.1.0. With those compilers, it correctly prints
{{1}}
But with clang 19.1.7, it instead yields
{1}
I tested some other cases and it seems that the issue occurs whenever a list has a single element which is also a list.
Of course, it is possible that there is a bug in Clang. We should just try to make sure we haven't triggered some undefined behavior in GiNaC. Testing different compiler versions on godbolt.org on the example discussed here at <https://www.reddit.com/r/cpp/comments/gbntov/bug_in_clang_msvc_regarding_initializer_list/> the problem may be fixed in Clang 20. I can't try out full GiNaC on that compiler. Can you? If there is no easy workaround in GiNaC, then we should require a minimum Clang version which works. To be discussed... All my best, -richy. -- Richard B. Kreckel <https://in.terlu.de/~kreckel/>
Dear Florian, Stefan, Okay, you've hit Clang bug 24186 [1], introduced in Clang 16 and fixed in Clang 20. It seems like the Clang people eagerly implemented core issue CWG1467 [2] which changed the semantics of ctors with initializer lists. It was later clarified and partly reverted in CWG2137 [3]. However, this still wasn't ideal since people wanted to elide ctors in some cases, so it was re-addressed in CWG2311 [4]. My reading is that we can forget about this last core issue because we aren't dealing with a ctor from a prvalue here. I don't see an easy workaround, even when using round parenthesis for ctors of lsts with one element. So, I propose to ignore the problem (and possibly recommend using a very recent compiler instead). On another note, we should try and keep the code formatting uniform throughout the GiNaC library. I hate having to do that, but I hate later quibbling about coding style even more: May I ask you to * write opening { on the same level as closing } when they are not on the same line, in particular those of functions, * avoid tabs unless at beginning of lines, see [5] (mostly done), and * add a space after keywords and the parenthesis following them, i.e. if (cond) instead of if(cond), likewise with 'for', 'while' loops... Everything else looks fine to me! If you feel unsure, please tell me, and I'll do that formatting. One last thing before releasing: Could you write an entry for the NEWS file, please? All my best, -richy. [1] <https://github.com/llvm/llvm-project/issues/24186> [2] <https://wg21.link/CWG1467> [3] <https://wg21.link/CWG2137> [4] <https://wg21.link/CWG2311> [5] <https://www.cebix.net/indentation.html> -- Richard B. Kreckel <https://in.terlu.de/~kreckel/>
Hi Florian, Stefan, There's a bug: The Gt class must override basic::compare_same_type() but it doesn't. Such things can be found by compiling the library with -DDO_GINAC_ASSERT and running the test suite. A repro for this bug is attached. I've reduced it from one of the banana regression tests. On 2/7/26 6:43 PM, Richard B. Kreckel wrote:
* write opening { on the same level as closing } when they are not on the same line, in particular those of functions, Only for those of functions definitions.
All my best, -richy. -- Richard B. Kreckel <https://in.terlu.de/~kreckel/>
Dear Richard, thank you for the feedback. I can confirm that the problem does not occur in LLVM 20.1.0. I sent a patch to Stefan to - adjust code formatting - fix bug in compare_same_type - add NEWS entry Please let me know if you find anything else. Best regards Florian On 2/8/26 16:29, Richard B. Kreckel wrote:
Hi Florian, Stefan,
There's a bug: The Gt class must override basic::compare_same_type() but it doesn't.
Such things can be found by compiling the library with -DDO_GINAC_ASSERT and running the test suite. A repro for this bug is attached. I've reduced it from one of the banana regression tests.
On 2/7/26 6:43 PM, Richard B. Kreckel wrote:
* write opening { on the same level as closing } when they are not on the same line, in particular those of functions, Only for those of functions definitions.
All my best, -richy.
_______________________________________________ GiNaC-devel mailing list -- ginac-devel@ginac.de To unsubscribe send an email to ginac-devel-leave@ginac.de https://lists.ginac.de/mailman3/lists/ginac-devel.ginac.de/
participants (2)
-
Florian Lorkowski
-
Richard B. Kreckel