#3739 fails to build with boost 1.85

[beefdeadbeef]

sdcc-4.4.0 build fails after boost update from 1.84 to 1.85 on linux/x86_64.
namely, freshly built sdcc binary SEGV's at least on hc08, s08 and mos6502 port code.
backtrace of one of failed compiler attempts

gdb -batch -ex r -ex bt --args ../../../src/sdcc -I./../../include -I. --std-c23 -mhc08 --max-allocs-per-node 25000 -c ../_atof.c

attached

[Philipp Klaus Krause]

Do you know if this also affects current trunk or snapshots?

[beefdeadbeef]

just checked -- yes, same.

[beefdeadbeef]

with sdcc-code-r14875-trunk

[Philipp Klaus Krause]

I can reproduce the issue using current trunk on my Debian GNU/Linux testing system.

[Philipp Klaus Krause]

This is not just an SDCC bug, Consider this simple test program:

#include <iostream>
#include <boost/container/flat_map.hpp>

typedef boost::container::flat_multimap<int, short> operand_map_t;

operand_map_t o;

int main(void)
{
    o.insert(std::pair<int, short>(93, 48));
    if (o.find(97) != o.end())
        std::cout << "Boost is broken!\n";
    return 0;
}

I get the "Boost is broken!" when compiling this with g++ 13.2.0 at -O2.

I guess we still need to deal with it in SDCC, though. May by a "#warning" when we detect boost 1.85 with a fallback to a slower container.

P.S.: reported to boost: https://github.com/boostorg/container/issues/281

[beefdeadbeef]

Well, that's quite scary, honestly. I'll probably stick with -01 for a while (which works for me btw) and let's see what boost people thinking. Thanks!

[Janko Stamenović]

Maybe related:

https://github.com/boostorg/container/issues/252

[Philipp Klaus Krause]

Boost has fixed the bug, so the fix will be in their next release. I've added a test in SDCC to make it fail to compile with boost 1.85.0, and report an error explaining the situation.

[beefdeadbeef]

for distributions that usually means: backport boost fix to 1.85.0 and revert/remove such test in sdcc -- just sayin'
Anyway, thanks !