Bug 164233

Summary: __builtin_object_size result incorrect
Product: [Fedora] Fedora Reporter: Ulrich Drepper <drepper>
Component: gccAssignee: Jakub Jelinek <jakub>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhide   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-07-26 19:17:21 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
test case for wrong bos none

Description Ulrich Drepper 2005-07-26 04:37:49 UTC 
Description of problem:
I'll attach some code where gcc has to work hard to get the correct buffer size.
 Currently the result is wrong.

Version-Release number of selected component (if applicable):
gcc-4.0.1-4.x86_64

How reproducible:
always

Steps to Reproduce:
1.compile the attached code with
gcc -c -g -O -D_FORTIFY_SOURCE u.c -DN=5
2.
3.
  
Actual results:
No warning message.

Expected results:
bos-bug.c: In function âsâ:
bos-bug.c:25: warning: call to __builtin___snprintf_chk will always overflow
destination buffer


Only for N == 17 and higher should the warning disappear.

Additional info:
Comment 1 Ulrich Drepper 2005-07-26 04:37:49 UTC 
Created attachment 117140 [details]
test case for wrong bos
Comment 2 Jakub Jelinek 2005-07-26 19:17:21 UTC 
This is actually quite hard to solve.  The __bos computation pass can't run
too late, as otherwise the builtins aren't properly folded, and unfortunately
all the loop optimizations are run extremely late.  So tree-object-size.c
doesn't see the above as counted loop that is executed exactly 5 times,
but just sees that bb0 (whatever is before loop) falls through into the
loop body, followed by either jump back to the loop body start or fall through
into the last bb (which calls __bos).  As bb0 increments it twice and loop
body 3 times, this means from tree-object-size.c's POV that cp - buf >= 5.

This is certainly not feasible to fix in either 4.0 or 4.1, Diego wants his
new propagator to be used by __bos in 4.2 timeframe and if perhaps that
propagator could be thought about really simple counted loops, then maybe.