This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Repair __builtin_setjmp/__builtin_longjmp

Eric Botcazou wrote:

Proposed changes attached. Tested by building an --enable-sjlj-exceptions compiler on AMD64/Linux.

	* unwind-sjlj.c: Poison setjmp.
	* doc/install.texi (enable-sjlj-exceptions): Use more general wording.
	* doc/tm.texi (DWARF2_UNWIND_INFO): Likewise.

I apologize for disappearing for a while here; I've been traveling, and am digging out of the email pile now.

+/* The setjmp side is dealt with in the except.c file.  */
+#define setjmp setjmp_should_not_be_used_in_this_file

Since <setjmp.h> is sometimes included in this file, you should do "#undef setjmp" before (re)defining setjmp. Please make that change.

With that change, the patch is OK.

As to the issue of documenting built-ins, let's leave it aside for now; you're not making things any worse than they were before.

However, my position remains that we should either define the semantics for builtins or explicitly prohibit their use. I would also accept Kenner's suggestion that we prohibit their use, but then provide a "-fexpose-internal-builtins" option to allow their use in test-cases. But, as Paul Brook and others said, I think that silently allowing the use of magic builtins whose semantics we don't intend to guarantee over time is a bad idea.


Mark Mitchell
(650) 331-3385 x713

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]