[Bug c++/49260] New: cpp0x/lambda/lambda-eh2.C fails execution

[Bug c++/49260] New: cpp0x/lambda/lambda-eh2.C fails execution

[janis at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49260

           Summary: cpp0x/lambda/lambda-eh2.C fails execution
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: janis@gcc.gnu.org


Test g++.dg/cpp0x/lambda/lambda-eh2.C fails execution on several targets as
shown by archived test results:

  alpha-dec-osf5.1b
  arm-none-linux-gnueabi
  hppa2.0w-hp-hpux11.11
  i686-apple-darwin9
  powerpc-apple-darwin9.8.0
  powerpc64-unknown-linux-gnu
  sh4-unknown-linux-gnu
  sparc-sun-solaris2.8, 2.9, 2.10 (but not 2.11)

It also fails for arm-none-eabi, although the build has failed lately.

Testing on arm-none-linux-gnueabi shows that the test has failed on that target
since it was added on 2011-05-23 for r174076, to go with this fix:

  2011-05-23  Jason Merrill  <jason@redhat.com>

        PR c++/47263
        * decl.c (use_eh_spec_block): Do use an EH spec block for a
        lambda op().

[Bug c++/49260] cpp0x/lambda/lambda-eh2.C fails execution

[janis at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49260

--- Comment #1 from Janis Johnson <janis at gcc dot gnu.org> 2011-06-01 17:31:24 UTC ---
Output when the test runs on QEMU for arm-none-linux-gnueabi:

terminate called after throwing an instance of 'int'

*** EXIT code 4242
FAIL: g++.dg/cpp0x/lambda/lambda-eh2.C execution test

[Bug c++/49260] cpp0x/lambda/lambda-eh2.C fails execution

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49260

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011.06.02 22:40:05
     Ever Confirmed|0                           |1

--- Comment #2 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-06-02 22:40:05 UTC ---
Confirmed on powerpc-apple-darwin9 with -m32 and -m64.

[Bug c++/49260] cpp0x/lambda/lambda-eh2.C fails execution

[ro at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49260

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ro at gcc dot gnu.org

--- Comment #3 from Rainer Orth <ro at gcc dot gnu.org> 2011-06-06 10:08:47 UTC ---
I'm seeing this when using Sun as on Solaris, but not with GNU as 2.21, even
when Sun ld is used in both cases.  I've been able to find the root cause: I
set
a breakpoint in _Unwind_IteratePhdrCallback and checked the pc checked there
on i386-pc-solaris2.11.  For the as/ld combination, I get

   0xfee350d5 <_Unwind_RaiseException+52>:    decl   -0x1577b(%ebp)
   0xfef29500 <__cxa_throw+96>:    decl   0x23e82434(%ecx)
   0x8051019 <operator()+47>:    incl   0x874fffa(%ebx)
   0xfef29500 <__cxa_throw+96>:    decl   0x23e82434(%ecx)
   0x8051019 <operator()+47>:    incl   0x874fffa(%ebx)
   0xfee350d5 <_Unwind_RaiseException+52>:    decl   -0x1577b(%ebp)
   0xfef29500 <__cxa_throw+96>:    decl   0x23e82434(%ecx)
   0x8050fcb <operator()+47>:    call   *-0x75(%ebp)
   0x8050fdd <_FUN+17>:    dec    %ecx

then

terminate called after throwing an instance of 'int'

Obviously, the unwind info for _FUNC is missing.  Here's the disassembly

   0x8050fcc <_FUN>:    push   %ebp
   0x8050fcd <_FUN+1>:    mov    %esp,%ebp
   0x8050fcf <_FUN+3>:    sub    $0x18,%esp
   0x8050fd2 <_FUN+6>:    movl   $0x0,(%esp)
   0x8050fd9 <_FUN+13>:    call   0x8050f9c <operator()>
   0x8050fde <_FUN+18>:    leave  
   0x8050fdf <_FUN+19>:    ret    

Looking at the search table, I find:

> elfdump -u lambda-eh2.exe
[...]
  Binary Search Table:
      InitialLoc    FdeLoc
    0x08050f9c    0x08061328    _ZZ4mainENKUlvE_clEv
                      main::{lambda()#1}::operator()() const
    0x08050fea    0x08061350    _ZZ4mainENKUlvE0_clEv
                      main::{lambda()#2}::operator()() const
    0x0805102f    0x08061378    main

i.e. the address above is really missing.  With gas instead, I find

  Binary Search Table:
      InitialLoc    FdeLoc
    0x08050fac    0x0806130c    _ZZ4mainENKUlvE_clEv
                      main::{lambda()#1}::operator()() const
    0x08050fdc    0x08061328    _ZZ4mainENUlvE_4_FUNEv
                      main::{lambda()#1}::_FUN()
    0x08050ff0    0x08061348    _ZZ4mainENKUlvE_cvPFvvEEv
                      main::{lambda()#1}::operator void (*)()() const
    0x08050ffa    0x08061388    _ZZ4mainENKUlvE0_clEv
                      main::{lambda()#2}::operator()() const
    0x0805103f    0x080613a8    main

[Bug c++/49260] cpp0x/lambda/lambda-eh2.C fails execution

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49260

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot
                   |                            |gnu.org

--- Comment #4 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-06-06 11:18:43 UTC ---
> I'm seeing this when using Sun as on Solaris, but not with GNU as 2.21, even
> when Sun ld is used in both cases.  

I'm seeing it on SPARC/Solaris 8, 9 and 10 with GNU as 2.20.1 and Sun ld.  So
the failure may be predicated on a feature available only in 2.21 or above.

[Bug c++/49260] cpp0x/lambda/lambda-eh2.C fails execution

[ro at CeBiTec dot Uni-Bielefeld.DE]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49260

--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2011-06-20 14:51:07 UTC ---
> --- Comment #4 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-06-06 11:18:43 UTC ---
>> I'm seeing this when using Sun as on Solaris, but not with GNU as 2.21, even
>> when Sun ld is used in both cases.  
>
> I'm seeing it on SPARC/Solaris 8, 9 and 10 with GNU as 2.20.1 and Sun ld.  So
> the failure may be predicated on a feature available only in 2.21 or above.

I've digged somewhat further: with gas 2.20.1, one of the cfi configure
test fails

checking assembler for working cfi advance... no

thus HAVE_GAS_CFI_DIRECTIVE is 0 and gas and Sun as are treated the same.

If I look at the gas 2.20.1 output, I find 3 instances of

    .long   <label>  / FDE initial location

  _ZZ4mainENKUlvE_clEv        -> main::{lambda()#1}::operator()() const
  .LFB32

  _ZZ4mainENKUlvE0_clEv        -> main::{lambda()#2}::operator()() const
  .LFB35

  main
  .LFB31

With gas 2.21 and .cfi_startproc instead, there are 5:

  _ZZ4mainENKUlvE_clEv
  .LFB32

  _ZZ4mainENUlvE_4_FUNEv    -> main::{lambda()#1}::_FUN()
  .LFB33

  _ZZ4mainENKUlvE_cvPFvvEEv    -> main::{lambda()#1}::operator void (*)()()
const
  .LFB34

  _ZZ4mainENKUlvE0_clEv
  .LFB35

  main
  .LFB31

The output of the FDE initial location happens in dwarf2out.c
(output_call_frame_info).  If I step throught that function, I see that
the FDEs are only emitted if fde_needed_for_eh_p (fde).  For the two
missing ones, I see that this function returns false due to this test:

  /* If exceptions are enabled, we have collected nothrow info.  */
  if (flag_exceptions && (fde->all_throwers_are_sibcalls || fde->nothrow))
    return false;

Here, both fde->all_throwers_are_sibcalls and fde->nothrow are 1.

I cannot say if this is wrong or the tests in fde_needed_for_eh_p
needs to be augmented.

Manually returning true from the function caused the FDEs to be emitted
and the testcase to succeed, as expected.

    Rainer

[Bug c++/49260] cpp0x/lambda/lambda-eh2.C fails execution

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49260

--- Comment #6 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-06-20 15:55:38 UTC ---
> The output of the FDE initial location happens in dwarf2out.c
> (output_call_frame_info).  If I step throught that function, I see that
> the FDEs are only emitted if fde_needed_for_eh_p (fde).  For the two
> missing ones, I see that this function returns false due to this test:
> 
>   /* If exceptions are enabled, we have collected nothrow info.  */
>   if (flag_exceptions && (fde->all_throwers_are_sibcalls || fde->nothrow))
>     return false;
> 
> Here, both fde->all_throwers_are_sibcalls and fde->nothrow are 1.
> 
> I cannot say if this is wrong or the tests in fde_needed_for_eh_p
> needs to be augmented.

The former I presume: on the SPARC, in the assembly file, there is a call from
main::{lambda()#1}::_FUN() to main::{lambda()#1}::operator()() const and the
latter calls __cxa_throw.  And this isn't a sibcall (we're at -O0).

Both flags are set to 1 initially in set_nothrow_function_flags but should be
properly computed later in the function.

[Bug c++/49260] cpp0x/lambda/lambda-eh2.C fails execution

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49260

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|unassigned at gcc dot       |jason at gcc dot gnu.org
                   |gnu.org                     |
   Target Milestone|---                         |4.7.0

[Bug c++/49260] cpp0x/lambda/lambda-eh2.C fails execution

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49260

--- Comment #7 from Jason Merrill <jason at gcc dot gnu.org> 2011-06-22 15:55:25 UTC ---
Author: jason
Date: Wed Jun 22 15:55:22 2011
New Revision: 175296

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175296
Log:
    PR c++/49260
    * call.c (build_call_a): Set cp_function_chain->can_throw here.
    (build_cxx_call): Not here.

Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/call.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-eh2.C

[Bug c++/49260] cpp0x/lambda/lambda-eh2.C fails execution

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49260

--- Comment #8 from Jason Merrill <jason at gcc dot gnu.org> 2011-06-22 15:55:59 UTC ---
Should be fixed on trunk now.

[Bug c++/49260] [C++0x] lambda-eh2.C fails execution

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49260

--- Comment #9 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-06-28 07:13:30 UTC ---
> Should be fixed on trunk now.

Yes, it is, thanks.  Do you plan to backport the fix to the 4.6 branch?

[Bug c++/49260] [C++0x] lambda-eh2.C fails execution

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49260

--- Comment #10 from Jason Merrill <jason at gcc dot gnu.org> 2011-08-02 15:35:28 UTC ---
Author: jason
Date: Tue Aug  2 15:35:20 2011
New Revision: 177186

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177186
Log:
    PR c++/49260
    * call.c (build_call_a): Set cp_function_chain->can_throw here.
    (build_cxx_call): Not here.

Modified:
    branches/gcc-4_6-branch/gcc/cp/ChangeLog
    branches/gcc-4_6-branch/gcc/cp/call.c
    branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_6-branch/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-eh2.C

[Bug c++/49260] [C++0x] lambda-eh2.C fails execution

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49260

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|4.7.0                       |4.6.2

--- Comment #11 from Jason Merrill <jason at gcc dot gnu.org> 2011-08-02 18:31:52 UTC ---
Fixed for 4.6.2.