--- Comment #8 from jonathan dot leffler at gmail dot com 2008-03-11 06:55
---
CVS tree of v6.8 collected from "cvs -d
:pserver:[EMAIL PROTECTED]:/cvs/src co -r gdb_6_8-branch gdb" shows that
the current code does indeed include *exact_match = 0; early in the
find_l
--- Comment #6 from jonathan dot leffler at gmail dot com 2008-03-11 04:23
---
(In reply to comment #4)
> So looking at the code, I see that we have a loop that might return the loop
> variant. Now we should be able to prove this loop variant is greater than or
> equal 0 but
--- Comment #5 from jonathan dot leffler at gmail dot com 2008-03-11 04:04
---
After a 'mid-air collision':
The code for find_line_common() is in the same file, later on, but declared
static, so GCC can analyze it -- and then it is correct to complain:
--- Comment #2 from jonathan dot leffler at gmail dot com 2008-03-11 03:48
---
I tried the following close-to-minimal reproduction - using the same compile
command as for the original symtab.c problem - and did not get the error.
struct symtab;
struct linetable;
extern int
--- Comment #1 from jonathan dot leffler at gmail dot com 2008-03-11 03:39
---
Created an attachment (id=15294)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15294&action=view)
bzip2-compressed version of symtab.i (pre-processed code that triggered the bug
report)
This
.3.0 on Solaris 10
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jonathan dot leffler at gmail dot com
GCC build triplet: sparc-sun-so
