I bootstrap emacs from bzr every two or three days, using whatever
gcc happens to be in my PATH.
The last successful build/install was on March 28th.
However, as far as I can see, the new problem is coming
from the tools I'm using, and not from emacs, since attempting
to build that previously-succ
Eric Botcazou wrote:
>> coverity pointed out the infinite loop below.
>> I guess it is unreachable or at least hard to reach,
>> or it would have been reported/fixed before now:
>
> Would you mind opening a PR with bugzilla?
Not at all:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49262
coverity pointed out the infinite loop below.
I guess it is unreachable or at least hard to reach,
or it would have been reported/fixed before now:
17605 if (index && TREE_CODE (index) == RANGE_EXPR)
17606 {
17607 int count = tree_low_cst (TREE
I did a quick scan for misuse of pointer values after failed
asprintf-style function uses and spotted a few. Here's a patch
for one of them:
[this patch is relative to just-updated "trunk"]
>From 1f71a26ec38860d863ca751aef049d314a4f34b4 Mon Sep 17 00:00:00 2001
From: Jim Meye
When I define a function that is already declared in a system header
file (same signature, of course), all warnings are disabled not only
in that function, but any following function definitions in the same
compilation unit.
For example, with this code,
cat <<'EOF' > k.c
#include
int clearenv (v