[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#246319: libcln3: Segfaults in cln::I_to_digits when converting numbers to binary

Richard B. Kreckel writes:
> However, there is nothing wrong with that statement.  It appears to be a
> compiler error introduced in GCC-3.0.0 and finally fixed in GCC-3.4.0.
> It is only triggered when the option -fno-exceptions is turned on when CLN
> is compiled.  Without that option, everything works fine.  I've just
> reproduced this bug with GCC releases 3.1.1, 3.2.3, 3.3.2 and 3.3.3, and
> also with 3.3.4-prerelease from CVS, all vanilla and bootstrapped locally.

thanks for tracking this down.

> Right now, I see four alternative solutions:
> 1) Upload a new Debian package where -fno-exceptions is not turned on.

If you change interfaces, you'll have at least change the package name
and/or soname and recompile dependent packages.

> 2) Fix CLN by playing dirty tricks.  For instance, printing the variable
>    erg's address in src/integer/output/cl_I_print.cc:30 seems to fix the
>    problem.  It should be possible to somehow read that address without
>    any side-effect.

preferred solution, unless

> 3) Fix GCC on the 3.3 branch.  It would probably take me at least a full
>    day to distill a useful testcase, however.  Likely more, if it turns
>    out to be a Heisenbug.  And if this leads to a fix in the GCC 3.3
>    branch is more then doubtful, I guess.

you are able to extract a reduced testcase. yes.

> 4) Use Debian's gcc-3.4 [0], making that a requirment for depending
>    packages, too.

Not really an option because of changes in the C++ ABI and libstdc++.

> Soooo, what are the chances for gcc-3.4 hitting sarge as the default
> compiler?  In my experience, this is a much better compiler than 3.3.3, in
> all respects, including reliability.  The whole 3.3 series seems to be
> having some problems.  In another context, it has already been suggested
> by GCC developers that the 3.3 branch may have taken place too early,
> causing patches not beeing applied properly and so on [1].

IMO no chance as the default compiler. Remember the time needed for
the last C++ transition. Maybe as an option, if the runtime libraries
built by 3.3 and 3.4 are compatible.


Reply to: