[Bug target/51921] New: [4.7 regression] EH unwinding support is broken on Solaris 11

[Bug target/51921] New: [4.7 regression] EH unwinding support is broken on Solaris 11

[ro at gcc dot gnu.org]

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

             Bug #: 51921
           Summary: [4.7 regression] EH unwinding support is broken on
                    Solaris 11
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: critical
          Priority: P3
         Component: target
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: ro@gcc.gnu.org
                CC: ebotcazou@gcc.gnu.org
              Host: sparc-sun-solaris2.11
            Target: sparc-sun-solaris2.11
             Build: sparc-sun-solaris2.11


The recent changes to libgcc/config/sparc/sol2-unwind.h have completely broken
Solaris 11 support, leading to many ada and java testsuite failues.  This is a
regression from 4.6.  There's still no real justification for reverting to the
old 4.5 code.

  Rainer

[Bug target/51921] [4.6/4.7 regression] EH unwinding support is broken

[ebotcazou at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-01-20
   Target Milestone|---                         |4.6.3
            Summary|[4.7 regression] EH         |[4.6/4.7 regression] EH
                   |unwinding support is broken |unwinding support is broken
                   |on Solaris 11               |
     Ever Confirmed|0                           |1

--- Comment #1 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2012-01-20 19:15:14 UTC ---
With this line of reasoning, there was no real justification for rewriting it
from scratch either...  This code is used in Ada (I don't count Java here, as
nobody uses GCJ on SPARC/Solaris) and the emphasis in Ada is robustness; we
cannot afford introducing gratuitous regressions (and I certainly don't want to
maintain a separate code for AdaCore's compiler) so we need to find a modus
vivendi.

[Bug target/51921] [4.6/4.7 regression] EH unwinding support is broken

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING

--- Comment #2 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-02-07 15:37:54 UTC ---
Only sparc-sun-solaris2.10 is a primary target at the moment.  Rainer, you
say "regression from 4.6" but the summary says 4.6/4.7 regression, not 4.7
regression.  No known-to-work/known-to-fail field.  Does this only affect Ada?

Please clarify.

[Bug target/51921] [4.6/4.7 regression] EH unwinding support is broken

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2012-02-07 16:59:32 UTC ---
> --- Comment #2 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-02-07 15:37:54 UTC ---
> Only sparc-sun-solaris2.10 is a primary target at the moment.  Rainer, you
> say "regression from 4.6" but the summary says 4.6/4.7 regression, not 4.7
> regression.  No known-to-work/known-to-fail field.  Does this only affect Ada?
>
> Please clarify.

I'd only noticed the breakage on mainline at first, but Eric reverted
the patch to support Solaris 11 on both mainline and the 4.6 branch, so
it indeed regressed on both branches.

It doesn't affect only Ada, but Java, too, which chooses to ignore.

I'm quite upset about this because the only reason for that reversion
he's given so far is a failure (I wouldn't call it regression) on a
7-year-old Solaris 10 beta release (or rather, one of many two-weekly
builds).  AFAICT, no released version is affected by my rewrite of
sparc/sol2-unwind.h, which introduced Solaris 11 support before 4.6.0,
which is now completely broken.

I don't buy his compatibility argument for several reasons:

* Even Sun/Oracle makes no compatibility guarantee of any sort for
  betas, and can break it if need we.  I don't see us making stronger
  guarantees in FSF GCC, especially to keep prehistoric betas working at
  the expense of the latest shipping release.

* Such versions are completely untestable: I've been in the Solaris 10
  Express and Platinum Beta programs myself, and ran practically every
  single one of those bi-weekly builds (that's what s10_72 is) on my
  machines, but didn't keep the ISO images for space reasons.

* If some AdaCore customer couldn't be bothered to upgrade to a release
  (I'm talking about any release here, not supported or latest) version
  of Solaris in 7 years, but needs to run bleeding-edge versions of GCC,
  I declare that AdaCore's problem, not mine.  If the only ill effect of
  a patch of mine is to break such ancient beta versions (not
  intentionally or lightly), so be it.  I'm not jumping through hoops to
  fix that.

I'm sort of tempted to revert Eric's reversion to restore working
Solaris 11 support in 4.6 and mainline, but would only do that as a very
last resort.

    Rainer

[Bug target/51921] [4.6/4.7 regression] EH unwinding support is broken

[ebotcazou at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW

--- Comment #4 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2012-02-07 17:12:26 UTC ---
> I'm quite upset about this because the only reason for that reversion
> he's given so far is a failure (I wouldn't call it regression) on a
> 7-year-old Solaris 10 beta release (or rather, one of many two-weekly
> builds).  AFAICT, no released version is affected by my rewrite of
> sparc/sol2-unwind.h, which introduced Solaris 11 support before 4.6.0,
> which is now completely broken.

If you give me a proof that no released version whatsoever, from the very first
Solaris 8 to the very latest Solaris 10, can be affected by a regression due to
the rewrite of the pattern matching code, then I'd (reluctantly) accept the
breakage for the Solaris 10 beta.  

> * If some AdaCore customer couldn't be bothered to upgrade to a release
>   (I'm talking about any release here, not supported or latest) version
>   of Solaris in 7 years, but needs to run bleeding-edge versions of GCC,
>   I declare that AdaCore's problem, not mine.  If the only ill effect of
>   a patch of mine is to break such ancient beta versions (not
>   intentionally or lightly), so be it.  I'm not jumping through hoops to
>   fix that.

Let's not misrepresent things, please.  Enhancing the existing pattern matching
code is trivial: you find the first differing frame in the stack, and you add a
new 'else if' somewhere.

Again, this pattern matching code is at least one decade old and went through
many Solaris versions, so rewriting it from scratch was a wrong decision.

[Bug target/51921] [4.6/4.7 regression] EH unwinding support is broken

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2012-02-07 17:29:37 UTC ---
> --- Comment #4 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2012-02-07 17:12:26 UTC ---
>> I'm quite upset about this because the only reason for that reversion
>> he's given so far is a failure (I wouldn't call it regression) on a
>> 7-year-old Solaris 10 beta release (or rather, one of many two-weekly
>> builds).  AFAICT, no released version is affected by my rewrite of
>> sparc/sol2-unwind.h, which introduced Solaris 11 support before 4.6.0,
>> which is now completely broken.
>
> If you give me a proof that no released version whatsoever, from the very first
> Solaris 8 to the very latest Solaris 10, can be affected by a regression due to
> the rewrite of the pattern matching code, then I'd (reluctantly) accept the
> breakage for the Solaris 10 beta.  

You know perfectly well that such a proof is practically impossible:
that would mean updating a machine through every single Solaris 8/9/10
kernel/libc/libthread patch ever released.  The other way round, I'd
claim that you cannot prove that the old code works for every since such
combination either.

>> * If some AdaCore customer couldn't be bothered to upgrade to a release
>>   (I'm talking about any release here, not supported or latest) version
>>   of Solaris in 7 years, but needs to run bleeding-edge versions of GCC,
>>   I declare that AdaCore's problem, not mine.  If the only ill effect of
>>   a patch of mine is to break such ancient beta versions (not
>>   intentionally or lightly), so be it.  I'm not jumping through hoops to
>>   fix that.
>
> Let's not misrepresent things, please.  Enhancing the existing pattern matching
> code is trivial: you find the first differing frame in the stack, and you add a
> new 'else if' somewhere.

You claimed that before, and that's what I tried at first to make
Solaris 11 work, but failed completely.

> Again, this pattern matching code is at least one decade old and went through
> many Solaris versions, so rewriting it from scratch was a wrong decision.

Why didn't you object then when it was submitted *and accepted*, has
been in for almost a year, been shipped with a release, and revert it
shortly before the next release?

    Rainer

[Bug target/51921] [4.6/4.7 regression] EH unwinding support is broken

[ebotcazou at gcc dot gnu.org]

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

--- Comment #6 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2012-02-07 17:54:18 UTC ---
> You know perfectly well that such a proof is practically impossible:
> that would mean updating a machine through every single Solaris 8/9/10
> kernel/libc/libthread patch ever released.  The other way round, I'd
> claim that you cannot prove that the old code works for every since such
> combination either.

I cannot indeed, but we now have a case where the old code used to work and the
new code fails. Granted, this isn't an official release, but it's annoying and
casts a legitimate doubt on the robustness of the new code.

> You claimed that before, and that's what I tried at first to make
> Solaris 11 work, but failed completely.

OK, do you know of a Solaris 11 machine to which I could have access?  AdaCore
doesn't have one for the time being.

> Why didn't you object then when it was submitted *and accepted*, has
> been in for almost a year, been shipped with a release, and revert it
> shortly before the next release?

I already managed to block a backport to the 4.5 branch. :-)  As for the
shortly, I wrote a first message on 11/28, got no answers, then applied the
change on 01/09, that is to say about 3 months before the planned shipping
date.

[Bug target/51921] [4.6/4.7 regression] EH unwinding support is broken

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING
                 CC|                            |rguenth at gcc dot gnu.org

--- Comment #7 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-02-08 10:44:51 UTC ---
Please fill out known-to-work and known-to-fail fields.  Was it "working"
in any 4.6.x release?  Especially was it "working" in 4.6.0?  If so regressing
on the branch is very bad.

Did the revert fix any regression that was reported as a bug and has gotten
a testcase?  If not, then the proper way to address this new regression is
to revert the revert especially as it appearantly happened during stage4(?)

[Bug target/51921] [4.6/4.7 regression] EH unwinding support is broken

[ro at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
      Known to work|                            |4.6.2
      Known to fail|                            |4.6.3, 4.7.0

[Bug target/51921] [4.6/4.7 regression] EH unwinding support is broken

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2012-02-08 18:10:31 UTC ---
> --- Comment #7 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-02-08 10:44:51 UTC ---
> Please fill out known-to-work and known-to-fail fields.  Was it "working"

Done.

> in any 4.6.x release?  Especially was it "working" in 4.6.0?  If so regressing
> on the branch is very bad.

It was working on the 4.6 branch from 4.6.0 to 4.6.2.

> Did the revert fix any regression that was reported as a bug and has gotten
> a testcase?  If not, then the proper way to address this new regression is
> to revert the revert especially as it appearantly happened during stage4(?)

You probably won't need a separate testcase since the failure of the
sparc/sol2-unwind.h code manifests itself as lots testsuite failures in
ACATS, gnat.dg, and libjava.

The only report I know of is Eric's mail about the failure on s10_72, an
ancient Solaris 10 bi-weekly beta build, something almost nobody outside
Sun/Oracle will be able to test/verify since the corresponding ISO
images are no longer available.

    Rainer

[Bug target/51921] [4.6/4.7 regression] EH unwinding support is broken

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ian at airs dot com

--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-02-10 23:34:28 UTC ---
*** Bug 52205 has been marked as a duplicate of this bug. ***

[Bug target/51921] [4.6/4.7 regression] EH unwinding support is broken

[pinskia at gcc dot gnu.org]

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

--- Comment #10 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-02-10 23:35:15 UTC ---
Here is a C++ example (which comes from PR 52205 which I marked as a dup of
this bug):
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

void
die(const char* msg)
{
  perror(msg);
  exit(EXIT_FAILURE);
}

void
handler(int signo, siginfo_t* info, void *context)
{
  printf("in handler signal %d\n", signo);
  throw signo;
}

int
main(int, const char**)
{
  struct sigaction act;
  memset(&act, 0, sizeof act);
  act.sa_sigaction = handler;
  sigfillset(&act.sa_mask);
  act.sa_flags = SA_SIGINFO;
  if (sigaction(SIGSEGV, &act, NULL) != 0)
    die("sigaction");

  try
    {
      *reinterpret_cast<char*>(0) = 1;
    }
  catch (int signo)
    {
      printf("caught signal %d\n", signo);
      exit(EXIT_SUCCESS);
    }

  printf("did not catch\n");
  exit(EXIT_FAILURE);
}

[Bug target/51921] [4.6/4.7 regression] EH unwinding support is broken

[ian at airs dot com]

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

--- Comment #11 from Ian Lance Taylor <ian at airs dot com> 2012-02-11 00:10:13 UTC ---
Note that the C++ example must be compiled -fnon-call-exceptions.

[Bug target/51921] [4.6/4.7 regression] EH unwinding support is broken

[ebotcazou at gcc dot gnu.org]

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

--- Comment #12 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2012-02-11 10:50:53 UTC ---
> Did the revert fix any regression that was reported as a bug and has gotten
> a testcase?  If not, then the proper way to address this new regression is
> to revert the revert especially as it appearantly happened during stage4(?)

Yes, the revert fixes a regression (6 ACATS tests + 4 gnat.dg tests) and no, it
didn't happen during stage4.  Let's try to do something under PR target/52205.

[Bug target/51921] [4.6/4.7 regression] EH unwinding support is broken

[ebotcazou at gcc dot gnu.org]

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

--- Comment #14 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2012-02-15 08:13:29 UTC ---
Author: ebotcazou
Date: Wed Feb 15 08:13:22 2012
New Revision: 184256

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184256
Log:
    PR target/51921
    PR target/52205
    * config/sparc/sol2-unwind.h (sparc64_is_sighandler): Add support for
    Solaris 11 and slightly reformat.
    (sparc_is_sighandler): Likewise.

Modified:
    branches/gcc-4_6-branch/gcc/ChangeLog
    branches/gcc-4_6-branch/gcc/config/sparc/sol2-unwind.h

[Bug target/51921] [4.6/4.7 regression] EH unwinding support is broken

[ebotcazou at gcc dot gnu.org]

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

--- Comment #13 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2012-02-15 08:13:20 UTC ---
Author: ebotcazou
Date: Wed Feb 15 08:13:09 2012
New Revision: 184255

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184255
Log:
    PR target/51921
    PR target/52205
    * config/sparc/sol2-unwind.h (sparc64_is_sighandler): Add support for
    Solaris 11 and slightly reformat.
    (sparc_is_sighandler): Likewise.

Modified:
    trunk/libgcc/ChangeLog
    trunk/libgcc/config/sparc/sol2-unwind.h

[Bug target/51921] [4.6/4.7 regression] EH unwinding support is broken

[ebotcazou at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #15 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2012-02-15 08:14:23 UTC ---
.