[Bug other/59039] New: Undocumented __builtin_longjmp/__builtin_setjmp

[Bug other/59039] New: Undocumented __builtin_longjmp/__builtin_setjmp

[hjl.tools at gmail dot com]

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

            Bug ID: 59039
           Summary: Undocumented __builtin_longjmp/__builtin_setjmp
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: other
          Assignee: unassigned at gcc dot gnu.org
          Reporter: hjl.tools at gmail dot com

cilk_fiber-unix.cpp has

#pragma GCC push_options
#pragma GCC optimize ("-O0")
NORETURN cilk_fiber_sysdep::run()
{

It fails when compiled with any optimization.  This function has
__builtin_setjmp and __builtin_longjmp within the same function.
When __builtin_longjmp is put in a separate function, optimization
works.  But there is no documentation on how __builtin_longjmp
and __builtin_setjmp should be used, like the jump buffer size
and fields as well as any limitation.

If it is true that __builtin_setjmp and __builtin_longjmp can't be
used within the same function, GCC should issue an error, at least
a warning.

[Bug other/59039] Undocumented __builtin_longjmp/__builtin_setjmp

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
__builtin_longjmp/setjmp are just longjmp(3) setjmp(3) with their constraints.
They should not be used directly but <setjmp.h> should be.

The file looks scary.

[Bug other/59039] Undocumented __builtin_longjmp/__builtin_setjmp

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
I suppose

    // alloca() to force generation of frame pointer.  The argument to alloca
    // is contrived to prevent the compiler from optimizing it away.  This
    // code should never actually be executed.
    int* dummy = (int*) alloca((sizeof(int) + (std::size_t) m_start_proc) &
0x1);
    *dummy = 0xface;

is optimized away.  Try using volatile int *.

[Bug other/59039] Undocumented __builtin_longjmp/__builtin_setjmp

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-11-07
     Ever confirmed|0                           |1

--- Comment #3 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Richard Biener from comment #1)
> __builtin_longjmp/setjmp are just longjmp(3) setjmp(3) with their
> constraints.
> They should not be used directly but <setjmp.h> should be.

That was my first impression. But I saw

[hjl@gnu-hsw-1 tmp]$ cat y.c
#include <setjmp.h>

extern jmp_buf buf;

void
foo ()
{
  __builtin_setjmp (buf);
}

void
bar ()
{
  __builtin_longjmp (buf, 1);
}
[hjl@gnu-hsw-1 tmp]$ gcc -S -O2 y.c
[hjl@gnu-hsw-1 tmp]$ cat y.s
    .file    "y.c"
    .text
    .p2align 4,,15
    .globl    foo
    .type    foo, @function
foo:
.LFB0:
    .cfi_startproc
    movq    %rsp, buf(%rip)
    movq    $.L2, buf+8(%rip)
    movq    %rsp, buf+16(%rip)
    ret
.L2:
.L4:
    .cfi_endproc
.LFE0:
    .size    foo, .-foo
    .p2align 4,,15
    .globl    bar
    .type    bar, @function
bar:
.LFB1:
    .cfi_startproc
    pushq    %rbp
    .cfi_def_cfa_offset 16
    .cfi_offset 6, -16
    movq    buf+8(%rip), %rax
    movq    %rsp, %rbp
    .cfi_def_cfa_register 6
    movq    buf(%rip), %rbp
    movq    buf+16(%rip), %rsp
    jmp    *%rax
    .cfi_endproc
.LFE1:
    .size    bar, .-bar

__builtin_longjmp/setjmp only save/restore BP, SP and PC on
x86, x32 and x86-64.

[Bug c/59039] Undocumented __builtin_longjmp/__builtin_setjmp

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
Ah, those are the builtins used for SJLJ and they get lowered to
setjmp_setup,dispatcher and longjmp.

Don't use __builtin_setjmp as I said, use setjmp.

I suppose these shouldn't have been made callable by user code?  Eric?

[Bug c/59039] Undocumented __builtin_longjmp/__builtin_setjmp

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
But it seems cilk depends on implementation details of setjmp/longjmp which
looks bogus anyway.

[Bug c/59039] Undocumented __builtin_longjmp/__builtin_setjmp

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Richard Biener from comment #4)
> Ah, those are the builtins used for SJLJ and they get lowered to
> setjmp_setup,dispatcher and longjmp.
> 
> Don't use __builtin_setjmp as I said, use setjmp.
> 
> I suppose these shouldn't have been made callable by user code?  Eric?

There are a few run-time testcases in gcc/testsuite, which
indicates that they work in user code and may have some
limitations.

[Bug c/59039] Undocumented __builtin_longjmp/__builtin_setjmp

[ebotcazou at gcc dot gnu.org]

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

--- Comment #7 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> Ah, those are the builtins used for SJLJ and they get lowered to
> setjmp_setup,dispatcher and longjmp.

Right, they are the efficient version of setjmp/longjmp.

> I suppose these shouldn't have been made callable by user code?  Eric?

Yes, but it's probably too late to change that.

[Bug c/59039] Undocumented __builtin_longjmp/__builtin_setjmp

[hjl.tools at gmail dot com]

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

--- Comment #8 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Eric Botcazou from comment #7)
> > Ah, those are the builtins used for SJLJ and they get lowered to
> > setjmp_setup,dispatcher and longjmp.
> 
> Right, they are the efficient version of setjmp/longjmp.
>  

What restrictions do they have? Can they be used within the
same function? Can they be used within functions with parameters?

[Bug c/59039] Undocumented __builtin_longjmp/__builtin_setjmp

[ebotcazou at gcc dot gnu.org]

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

--- Comment #9 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> What restrictions do they have? Can they be used within the
> same function? Can they be used within functions with parameters?

The only restriction I know of is that they cannot be in the same function,
it's even enforced by the inliner:

      case BUILT_IN_LONGJMP:
        /* We can't inline functions that call __builtin_longjmp at
           all.  The non-local goto machinery really requires the
           destination be in a different function.  If we allow the
           function calling __builtin_longjmp to be inlined into the
           function calling __builtin_setjmp, Things will Go Awry.  */
        inline_forbidden_reason
          = G_("function %q+F can never be inlined because "
           "it uses setjmp-longjmp exception handling");

[Bug c/59039] Undocumented __builtin_longjmp/__builtin_setjmp

[hjl.tools at gmail dot com]

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

--- Comment #10 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Eric Botcazou from comment #9)
> > What restrictions do they have? Can they be used within the
> > same function? Can they be used within functions with parameters?
> 
> The only restriction I know of is that they cannot be in the same function,
> it's even enforced by the inliner:
> 
> 	  case BUILT_IN_LONGJMP:
> 	    /* We can't inline functions that call __builtin_longjmp at
> 	       all.  The non-local goto machinery really requires the
> 	       destination be in a different function.  If we allow the
> 	       function calling __builtin_longjmp to be inlined into the
> 	       function calling __builtin_setjmp, Things will Go Awry.  */
> 	    inline_forbidden_reason
> 	      = G_("function %q+F can never be inlined because "
> 		   "it uses setjmp-longjmp exception handling");

But gcc doesn't issue anything for this testcase:

[hjl@gnu-hsw-1 tmp]$ cat z.c
#include <setjmp.h>

extern jmp_buf buf;

int
foo (int i)
{
  int j = i + 1;
  if (__builtin_setjmp (buf))
    {
      j += 1;
      __builtin_longjmp (buf, 1);
    }

  return j + i;
}
[hjl@gnu-hsw-1 tmp]$ gcc -S -O2 z.c -Wall
[hjl@gnu-hsw-1 tmp]$ 

For this testcase:

[hjl@gnu-hsw-1 tmp]$ cat i.c
#include <setjmp.h>

extern jmp_buf buf;

int
foo (int i)
{
  int j = i + 1;
  if (!__builtin_setjmp (buf))
    {
      j += 1;
    }

  return j + i;
}
[hjl@gnu-hsw-1 tmp]$ gcc -O2 -S i.c
[hjl@gnu-hsw-1 tmp]$ cat i.s
    .file    "i.c"
    .text
    .p2align 4,,15
    .globl    foo
    .type    foo, @function
foo:
.LFB0:
    .cfi_startproc
.L4:
.L2:
    movq    %rsp, buf(%rip)
    movq    $.L2, buf+8(%rip)
    leal    2(%rdi,%rdi), %eax
    movq    %rsp, buf+16(%rip)
    ret
    .cfi_endproc
.LFE0:
    .size    foo, .-foo

%rdi holds the function parameter 'i'.  But when __builtin_longjmp is
called, %rdi can have some random value.  GCC doesn't save %rdi first.
>From gcc-bugs-return-433868-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Nov 07 16:39:06 2013
Return-Path: <gcc-bugs-return-433868-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 18787 invoked by alias); 7 Nov 2013 16:39:06 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 18743 invoked by uid 48); 7 Nov 2013 16:39:02 -0000
From: "schwab@linux-m68k.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/59039] Undocumented __builtin_longjmp/__builtin_setjmp
Date: Thu, 07 Nov 2013 16:39:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: schwab@linux-m68k.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-59039-4-4vACa5ZH77@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59039-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59039-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-11/txt/msg00645.txt.bz2
Content-length: 210

http://gcc.gnu.org/bugzilla/show_bug.cgi?idY039

--- Comment #11 from Andreas Schwab <schwab@linux-m68k.org> ---
In the latter testcase foo doesn't call a function so there is never a need to
save anything.

[Bug c/59039] Undocumented __builtin_longjmp/__builtin_setjmp

[ebotcazou at gcc dot gnu.org]

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

--- Comment #12 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> %rdi holds the function parameter 'i'.  But when __builtin_longjmp is
> called, %rdi can have some random value.  GCC doesn't save %rdi first.

No, __builtin_longjmp doesn't touch %rdi at all.  Don't worry too much, the
SJLJ mechanism of the C++ and Ada compilers has been piggybacked on this for a
couple of decades, this is quite robust.

[Bug c/59039] Undocumented __builtin_longjmp/__builtin_setjmp

[ebotcazou at gcc dot gnu.org]

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

--- Comment #14 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> This is good to hear.  What is each field?  I assume that
> the first 3 fields are frame address, resume address and
> stack address.  Are the same for all targets?  What are
> the maximum number of fields?

Everything is in the manual I think, otherwise certainly in the sources.

[Bug c/59039] Undocumented __builtin_longjmp/__builtin_setjmp

[hjl.tools at gmail dot com]

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

--- Comment #15 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Eric Botcazou from comment #14)
> > This is good to hear.  What is each field?  I assume that
> > the first 3 fields are frame address, resume address and
> > stack address.  Are the same for all targets?  What are
> > the maximum number of fields?
> 
> Everything is in the manual I think, otherwise certainly in the sources.

I couldn't find anything in GCC manual.

[Bug c/59039] Undocumented __builtin_longjmp/__builtin_setjmp

[rguenth at gcc dot gnu.org]

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

--- Comment #16 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to H.J. Lu from comment #15)
> (In reply to Eric Botcazou from comment #14)
> > > This is good to hear.  What is each field?  I assume that
> > > the first 3 fields are frame address, resume address and
> > > stack address.  Are the same for all targets?  What are
> > > the maximum number of fields?
> > 
> > Everything is in the manual I think, otherwise certainly in the sources.
> 
> I couldn't find anything in GCC manual.

See tm.texi / md.texi.

[Bug c/59039] Undocumented __builtin_longjmp/__builtin_setjmp

[hjl.tools at gmail dot com]

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

--- Comment #17 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Richard Biener from comment #16)
> > I couldn't find anything in GCC manual.
> 
> See tm.texi / md.texi.

This is the only thing I found:

 -- Macro: DONT_USE_BUILTIN_SETJMP
     Define this macro to 1 if the 'setjmp'/'longjmp'-based scheme
     should use the 'setjmp'/'longjmp' functions from the C library
     instead of the '__builtin_setjmp'/'__builtin_longjmp' machinery.

It doesn't say they can't be used in the same
function, the size of the jump buffer, nor what
each field in the jump buffer is used for.

[Bug c/59039] Undocumented __builtin_longjmp/__builtin_setjmp

[ebotcazou at gcc dot gnu.org]

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

--- Comment #18 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> I couldn't find anything in GCC manual.

There are a few documented hooks, but this looks quite light indeed, so the
sources are probably the best references, i.e. builtins.c and except.c:

/* __builtin_longjmp is passed a pointer to an array of five words (not
   all will be used on all machines).  It operates similarly to the C
   library function of the same name, but is more efficient.  Much of
   the code below is copied from the handling of non-local gotos.  */

static void
expand_builtin_longjmp (rtx buf_addr, rtx value)
{
  rtx fp, lab, stack, insn, last;
  enum machine_mode sa_mode = STACK_SAVEAREA_MODE (SAVE_NONLOCAL);


void
init_eh (void)
{
[...]

#ifdef DONT_USE_BUILTIN_SETJMP
#ifdef JMP_BUF_SIZE
      tmp = size_int (JMP_BUF_SIZE - 1);
#else
      /* Should be large enough for most systems, if it is not,
     JMP_BUF_SIZE should be defined with the proper value.  It will
     also tend to be larger than necessary for most systems, a more
     optimal port will define JMP_BUF_SIZE.  */
      tmp = size_int (FIRST_PSEUDO_REGISTER + 2 - 1);
#endif
#else
      /* builtin_setjmp takes a pointer to 5 words.  */
      tmp = size_int (5 * BITS_PER_WORD / POINTER_SIZE - 1);
#endif
      tmp = build_index_type (tmp);
      tmp = build_array_type (ptr_type_node, tmp);
      f_jbuf = build_decl (BUILTINS_LOCATION,
               FIELD_DECL, get_identifier ("__jbuf"), tmp);
#ifdef DONT_USE_BUILTIN_SETJMP
      /* We don't know what the alignment requirements of the
     runtime's jmp_buf has.  Overestimate.  */
      DECL_ALIGN (f_jbuf) = BIGGEST_ALIGNMENT;
      DECL_USER_ALIGN (f_jbuf) = 1;
#endif

[Bug c/59039] Undocumented __builtin_longjmp/__builtin_setjmp

[hjl.tools at gmail dot com]

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

--- Comment #19 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Eric Botcazou from comment #18)
> > I couldn't find anything in GCC manual.
> 
> There are a few documented hooks, but this looks quite light indeed, so the
> sources are probably the best references, i.e. builtins.c and except.c:
> 

Would it be OK to submit it a patch to document
__builtin_longjmp/__builtin_setjmp based on their
sources?

[Bug c/59039] Undocumented __builtin_longjmp/__builtin_setjmp

[schwab@linux-m68k.org]

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

--- Comment #21 from Andreas Schwab <schwab@linux-m68k.org> ---
It's only an error if they use the same jmpbuf.

[Bug c/59039] Undocumented __builtin_longjmp/__builtin_setjmp

[bviyer at gcc dot gnu.org]

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

--- Comment #22 from bviyer at gcc dot gnu.org ---
Author: bviyer
Date: Fri Nov  8 19:52:27 2013
New Revision: 204592

URL: http://gcc.gnu.org/viewcvs?rev=204592&root=gcc&view=rev
Log:
+2013-11-08  Balaji V. Iyer  <balaji.v.iyer@intel.com>
+
+       PR c/59039
+       * runtime/cilk_fiber-unix.cpp: Fixed a crash in run() function
+       when optimization is turned on.
+


Modified:
    trunk/libcilkrts/ChangeLog
    trunk/libcilkrts/runtime/cilk_fiber-unix.cpp

[Bug c/59039] Undocumented __builtin_longjmp/__builtin_setjmp

[hjl.tools at gmail dot com]

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

--- Comment #23 from H.J. Lu <hjl.tools at gmail dot com> ---
Created attachment 31186
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31186&action=edit
A patch to document __builtin_setjmp/__builtin_longjmp

Does it look OK?

[Bug c/59039] Undocumented __builtin_longjmp/__builtin_setjmp

[ebotcazou at gcc dot gnu.org]

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

--- Comment #24 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> Does it look OK?

Mostly, but I wouldn't go into full details about what contains the buffer,
this is machine-specific and not portable.  Maybe something like:

"The @code{setjmp} buffer is an array of five @code{intptr_t}.  The buffer
will generally contain the frame address, the resume address and the stack
address.  The other elements may be used in a machine-specific way."

[Bug c/59039] Undocumented __builtin_longjmp/__builtin_setjmp

[rth at gcc dot gnu.org]

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

Richard Henderson <rth at gcc dot gnu.org> changed:

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

--- Comment #25 from Richard Henderson <rth at gcc dot gnu.org> ---
(In reply to H.J. Lu from comment #23)
> Does it look OK?

I would not say that __builtin_setjmp is more efficient.  It really saves
just as many registers, except that it has help from the containing function's
prologue/epilogue to do so, rather than saving them all within the jmpbuf.

Which means that the set of registers saved is the ISA under which the setjmp
was compiled.  Which makes the builtin less flexible than the libc variant
when it comes to ISA extensions such as we see on ARM and PPC.

I'm not keen on encouraging any user to use these functions.
It's simply not worth it to us as maintainers.

The fact that we've got code in libgcc that uses them means that we must
continue to have these functions callable by some means.  If folks would be
happier if we hid these from users by making them only callable with some
special option like -fbuild-libgcc, I could live with that.

[Bug c/59039] Undocumented __builtin_longjmp/__builtin_setjmp

[ebotcazou at gcc dot gnu.org]

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

--- Comment #26 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> I would not say that __builtin_setjmp is more efficient.  It really saves
> just as many registers, except that it has help from the containing
> function's prologue/epilogue to do so, rather than saving them all within the 
> jmpbuf.

[As well as from the register allocator].  I think it's more efficient though,
for example if you implement an SJLJ exception scheme on top of it.

> I'm not keen on encouraging any user to use these functions.
> It's simply not worth it to us as maintainers.
> 
> The fact that we've got code in libgcc that uses them means that we must
> continue to have these functions callable by some means.  If folks would be
> happier if we hid these from users by making them only callable with some
> special option like -fbuild-libgcc, I could live with that.

IMO it's too late to hide them after 2 decades.  If people are really afraid of
them, then we could keep the status quo.