Reduced testcase (why don't we remove the dead code before inlining). void g(void); inline int f(void) { return 1; g(); } int h(void) { return f(); } Note this is reduced from: #include <string> #include <vector> void foo(std::vector<std::string> & matches) { char * buf[10]; matches.insert(matches.end(), buf, buf + 10); } (also why does libstdc++ have dead code in its headers.
I also happens with the C front-end too.
There is zero chance that this will be fixed for 4.0. That's exactly why Ian implemented the minimalistic check that he did in solving PR19583 and related. You may retartget this pr to fixing the silliness in libstdc++, if you want.
Confirmed.
(In reply to comment #2) > You may retartget this pr to fixing the silliness in libstdc++, if you want. Actually it is only silliness as try/catch is changed to be "if (true)"/"if (false)" if we don't have exceptions. There is nothing can be done to the libstdc++ headers to fix this.
*** Bug 21183 has been marked as a duplicate of this bug. ***
*** Bug 21191 has been marked as a duplicate of this bug. ***
*** Bug 21290 has been marked as a duplicate of this bug. ***
*** Bug 21483 has been marked as a duplicate of this bug. ***
*** Bug 21572 has been marked as a duplicate of this bug. ***
*** Bug 21800 has been marked as a duplicate of this bug. ***
Fixed on the mainline by the moving the warning to right after CFG creation which is now done for all functions, even unused ones.
Will the patch be applied to 4.0 branch too?
(In reply to comment #12) > Will the patch be applied to 4.0 branch too? No because it is too big in that it also changes the inliner to be a CFG aware inliner.
(In reply to comment #13) > (In reply to comment #12) > > Will the patch be applied to 4.0 branch too? > No because it is too big in that it also changes the inliner to be a CFG aware inliner. In that case, it should not be marked "RESOLVED" for gcc-4.0 until: 1. either it is marked WONTFIX for gcc-4.0 2. or a new patch is written specifically for the gcc-4.0 branch. From comment #2 I understand that option 2 is out of the question. Does it mean that "gcc-4.0 is dead, long live gcc-4.1" ? This is how I came to this "conclusion": There are new (not very rare) regressions in gcc-4.0 that will never be fixed. These regressions will be fixed only in gcc-4.1. As a result, it sounds like gcc-4.0 is much less maintained than any other (active) branch (or trunk) at the moment. This is very different from any of the previous releases of GCC (up to gcc-2.95) If this is true, then gcc-4.1 schedule should be changed to reflect that.
(In reply to comment #14) > This is how I came to this "conclusion": > There are new (not very rare) regressions in gcc-4.0 that will never > be fixed. These regressions will be fixed only in gcc-4.1. > As a result, it sounds like gcc-4.0 is much less maintained than > any other (active) branch (or trunk) at the moment. This is > very different from any of the previous releases of GCC (up to > gcc-2.95) This is only a diagnostic regression. In fact before this patch which added the warning in the inliner, we had a diagnostic regression. So it is either false postive or false negatives. Take your pick, I rather have the false postives as it means you have to look at your code to double check, if we don't get a diagnostic at all, the person will complain when we get it right again the next major release. Again take your pick.
*** Bug 21951 has been marked as a duplicate of this bug. ***
*** Bug 22435 has been marked as a duplicate of this bug. ***