> Note that this issue is in theory pretty serious as in principle
> binary package in the archive could be affected.
Since the abs() is optimized away on miscompilations, searching for
binaries that have the abs() symbol won't find the buggy ones.
The only reliable way to find out what packages could be affected,
is to grep for calls to abs() [I guess too many to hand-review].
Then the list could be filtered by dropping calls to abs() where
parameteres are provably positive numbers (either constants, or
unsigned types). Such a check could be implemented in static
analysis tools, like CIL, but trying to compile the entire archive
with CIL can be a challenge by itself.
How do you intend to handle this bug for stable?
Obviously updating all packages that call abs() is not a solution
A quicker way to find out could be to compile all the archive with
current gcc version. Then apply the patch that fixes the bug,
recompile the entire archive, and see which .o,.so,.a, and
executable files differ between the two. Is there a tool to automate
such a task?
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact email@example.com