Re: [PATCH] Backport PR47324 to gcc 4.5 branch

[Jack Howarth <howarth at bromo dot med dot uc dot edu>]

On Wed, Feb 16, 2011 at 05:17:35PM -0500, Jason Merrill wrote:
> On 02/14/2011 06:53 AM, Jack Howarth wrote:
>>     The attached patch backports the missing usage of the DWARF2_FRAME_REG_OUT
>> macro in gcc/dwarf2out.c for gcc 4.5.3. This bug is latent in gcc-4_5-branch
>> to the absence of...
>
> Hmm, since as you say this bug is latent in 4.5, it can't be a  
> regression, and therefore doesn't really seem suitable for that branch.
>
> Jason

Jason,
  I would also point out that historically darwin has been deemed weird because
of the difficulties with its system unwinder under FSF gcc. This can be seen from
the fact that these failures previously existed in gcc trunk until at least r152966.

http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg02532.html
http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg01825.html

after which they went latent for a period. A full regression test reveals that the breakage
fixed by...

Author: iains
Date: Sat Feb 12 16:51:58 2011
New Revision: 170077

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170077
Log:

gcc:
    PR target/47324
    * dwarf2out.c (output_cfa_loc): When required, apply the
    DWARF2_FRAME_REG_OUT macro to adjust register numbers.
    (output_loc_sequence): Likewise.
    (output_loc_operands_raw): Likewise.
    (output_loc_sequence_raw): Likewise.
    (output_cfa_loc): Likewise.
    (output_loc_list): Suppress register number adjustment when
    calling output_loc_sequence()
    (output_die): Likewise.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/dwarf2out.c

was actually triggered in gcc trunk by...

r160124 | hubicka | 2010-06-01 17:55:49 -0400 (Tue, 01 Jun 2010) | 4 lines

        * ipa-pure-const.c (local_pure_const): Do NORETURN discovery.

        * testsuite/gcc.dg/noreturn-8.c: New testcase.

which is not present on gcc-4_5-branch. So we can view this issue two ways.
The first is to claim that because we don't see it failing testcases in gcc-4_5-branch
that no problem can exist. The second is to recognize that the existing code
fixed in gcc trunk also exists in gcc branch and that these failures have a
history of going latent and re-appearing later. Darwin should not be emitting
incorrect registers in its dwarf2 code for eh. Whether we have a test case in
hand to demonstrate this for gcc 4.5.3 is orthogonal to the problem. Given its
history of periodic latency and the limited eh execution testcases in the
gcc testsuite it is cold comfort to assume it won't be triggered in some 
existing code.
               Jack