------- Comment #3 from rguenther at suse dot de 2010-01-24 20:50 ------- Subject: Re: Revisit std::function for aliasing issues
On Sun, 24 Jan 2010, paolo dot carlini at oracle dot com wrote: > ------- Comment #2 from paolo dot carlini at oracle dot com 2010-01-24 18:42 > ------- > Richard, I'm sorry, I realize now that I'm confused about an important point: > does your analysis of function::swap mean that we are *already* miscompiling > it? I did not yet observe miscompilations - it for now is a latent issue only. > Or, are we going to commit patches which will lead to miscompilations in > 4.5? No, I planned to - but after the analysis I decided to postpone them. The issue is the patches only improve RTL analysis - I see nothing that blocks the issue to show up on the tree level, but we seem to be lucky there. On RTL we do instruction scheduling which does include unusual movement of instructions, like sinking loads or hoisting stores - that might be the reason we are lucky on the tree level. > Because otherwise, I don't really think it makes sense to have an interim > version of the code using std::memcpy (at least not for the C+0x version): for > 4.6.0 we could as well move directly to the optimized but correct solution - > in > other terms we didn't really understand each other the last week, and this > issue should not depend on 42834, on your 42845 instead and should be targeted > to 4.6.0. Well - that's up to you. libstdc++ violates aliasing rules, and I expect that sooner or later there will be a testcase that is miscompiled with the existing 4.5 codebase. A fix using memcpy certainly depends on fixing 42834, thus the dependency. It blocks PR42617 whose fixes expose this bug, that bug isn't marked as regression though it is (heh - nobody besides me noticed that). Thus, it is up to you - if you want to fix this for 4.5 then I have to fix PR42834 (because you do not consider a fix not using memcpy). PR42834 isn't a regression either - 4.4 was much less compliant wrt C++ dynamic types. Hope this helps and doesn't add more confusion ;) Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42832
