On Wed, Dec 17, 2003 at 09:00:39AM -0500, George Bakos wrote:
> It would appear that this is due to a change in optimize.c, as of the 1.73
> checkin. In opt_peep(b), using a continue statement, rather than a break,
> causes over-optimization in certain cases. It is possible, however I can't
> see when, that the following backout patch may lead to less optimization.
> Comments?
I've been looking at this - there is, I think, an optimizer bug
elsewhere, and his change might merely have exposed that bug. I haven't
tracked it down yet, however. (It's converting the "false" branch of
one jeq to go to the "ret #0" when it shouldn't be. This might also be
the cause of a bug in the libpcap bug database on SourceForge.)
His changes fix some other problems:
Date: Thu, 25 Apr 2002 07:20:47 +0900 (JST)
To: [EMAIL PROTECTED]
Subject: some fixes for complier and optimizer in libpcap
From: YAMAMOTO Takashi <[EMAIL PROTECTED]>
I made patches for libpcap.
it includes:
- make tcpdump "1 > 1" works correctly.
- make things unsigned as in-kernel filter does.
- fix a bug that prevents optimization. (and might cause bad codes)
eg. "1 & len == 1"
- fix wrong optimizations.
eg. "0 >> len == 1", "0 - len == 1"
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]
