http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46916
--- Comment #49 from Iain Sandoe <iains at gcc dot gnu.org> 2010-12-15 00:28:04 UTC --- (In reply to comment #48) > Uh, this is getting confusing. We are really tracking 3 problems iteracting > with each other (and prevosly hidding each other) indeed. > 1) darwin_text_section returns unlikely_text section that leads to infinite > recursion after the patch preventing darwin_function_section to partition > functions with -fno-partition-functions > > This is preferably fixed by making darwin_function_section to return only the > default section, but we do have alternative fix adding unlikely function as > predefined section. well, I think we can consider that variant withdrawn - replaced by... > We also have alternative patch here that scratch the > USE_SELECT_SECTION_FOR_FUNCTIONS hack. That one should test independently with > only problem demonstrated by 2). ... OK, at the moment I have it combined (I thought that was the suggestion @ comment 19 ;-)) > 2) -freorder-blocks-and-partition does not imply -freorder-functions. This > means that -O0 we do not actual partition, since hot and cold section is > forced > by be same by my change to function_section that triggered the PR > > This demonstrate as the partition failure and should be solved by the hunk > enabling reorder functions when -freorder-blocks-and-partition is given. > > I had typo in the original change I pasted here that it enabled > -freorder-blocks instead. Just scratch that vairant. The patch @44 has the correct variant... > 3) the fact that we produce wrong assembly with 2 instead of missing > optimization actually uncovers bigger problem that we seem to screw up when > function partition is enabled but we do not really partition the given > function. In this case we do most of the code pesimization and worse yet, we > tend to mess up EH. we get a lot of "warning: no debug symbols in executable" messages from dsymutil -- that might indicate bad debug info -- or be a latent bug in dsymutil (not clear at the moment). > This should be fixed by the patch I sent to PR but for some reason it breaks > stackalign. Do we have any idea why? I don't think it breaks stackalign on i686-darwin9. > I guess we ought to be able to solve 1) and 2) in parallel and 3) > incrementally. I have no more time today -- tomorrow I'll remove the USE_SELECT_SECTION_FOR_FUNCTIONS change. ===== result from c44 (modified as per 46) i686-darwin9 Running target unix/-m32 [for some reason the prune fails here... ] FAIL: g++.dg/bprob/g++-bprob-2.C compilation, -g -fprofile-use UNRESOLVED: g++.dg/bprob/g++-bprob-2.C execution, -g -fprofile-use FAIL: g++.dg/bprob/g++-bprob-2.C compilation, -O3 -g -fprofile-use UNRESOLVED: g++.dg/bprob/g++-bprob-2.C execution, -O3 -g -fprofile-use ++ warning: no debug symbols in executable (-arch i386) FAIL: g++.dg/debug/dwarf2/pubnames-1.C scan-assembler-times "main.0"[^\\n]*external name 1 FAIL: g++.dg/other/pr22003.C (test for excess errors) as per Comment #28/30: FAIL: g++.dg/pch/system-1.C -g assembly comparison FAIL: g++.dg/pch/system-1.C -O2 -g assembly comparison FAIL: g++.dg/pch/system-1.C -O2 assembly comparison FAIL: g++.dg/pch/system-2.C -g assembly comparison FAIL: g++.dg/pch/system-2.C -O2 -g assembly comparison FAIL: g++.dg/pch/system-2.C -O2 assembly comparison + PR46904 Running target unix/-m64 FAIL: g++.dg/debug/dwarf2/pubnames-1.C scan-assembler-times "main.0"[^\\n]*external name 1 FAIL: g++.dg/other/pr22003.C (test for excess errors) as per Comment #28/30 FAIL: g++.dg/pch/system-1.C -g assembly comparison FAIL: g++.dg/pch/system-1.C -O2 -g assembly comparison FAIL: g++.dg/pch/system-1.C -O2 assembly comparison FAIL: g++.dg/pch/system-2.C -g assembly comparison FAIL: g++.dg/pch/system-2.C -O2 -g assembly comparison FAIL: g++.dg/pch/system-2.C -O2 assembly comparison + PR46904
