[Bug middle-end/46916] gcc.dg/torture/stackalign/non-local-goto-[1,2].c ICEs compiler due to r167727

["iains at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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