Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 4 product line. The current stable release is 4.9. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 490253

Summary: gcc optimizes away critical frees with -O2 flag set; does not occur with vanilla
Product: Red Hat Enterprise Linux 4 Reporter: Ladar Levison <ladar>
Component: gcc34Assignee: Jakub Jelinek <jakub>
Status: CLOSED WONTFIX QA Contact:
Severity: high Docs Contact:
Priority: low    
Version: 4.7   
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
URL: http://lavabit.com
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-06-20 16:58:03 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
gcc34-rh490253.patch none

Description Ladar Levison 2009-03-14 06:37:11 UTC 
When compiling clamav v0.94.2, and statically linking it to an application, memory is not freed by the cl_free function. It appears to be a bug with the RHEL version of gcc 3.4, as the bug does not occur with gcc 3.4 in debian. See this clamav bug report for a test case:

https://wwws.clamav.net/bugzilla/show_bug.cgi?id=883

I finally managed to get my hands on a RHEL 4 box to test against, and the issue is still present.
Comment 1 Jakub Jelinek 2009-03-16 15:30:59 UTC 
Yeah, reproduceable also with vanilla gcc 3.4.x.  Doesn't reproduce with -mtune=i486, -mtune=i586 or -mtune=i686, so as a workaround just use -mtune=i686, you aren't running on i386 anyway, are you?  Or use unsigned int or unsigned long counter instead of unsigned short.

The bug is in the loop optimizer, where it incorrectly determines in check_dbra_loop that the induction variable is always non-negative, when HImode 0xf808 obivously is negative and so when the loop is reversed and after
HImode subtraction of 1 from 0xf808 (decw) the jns obviously doesn't loop back when it should.

I think this got broken by
http://gcc.gnu.org/ml/gcc-patches/2003-07/msg01355.html
patch, for LTU we should check that the comparison value isn't when considered as signed less than 0.
Comment 2 Jakub Jelinek 2009-03-16 15:56:39 UTC 
Created attachment 335362 [details]
gcc34-rh490253.patch

Untested patch that cures this bug.
Comment 3 Jiri Pallich 2012-06-20 16:58:03 UTC 
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life. 
Please See https://access.redhat.com/support/policy/updates/errata/

If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.