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:
Created attachment 117140 [details] test case for wrong bos
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.