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]

[RFA:] Clarify exceptional path for attribute-noreturn.

Discussion about the message in
trigged the question whether the attribute __noreturn__ affects
the exceptional path.  It doesn't for 3.3 and HEAD of about a
month ago.  Tom Tromey says libgcj depends on this behavior;
that the exceptional path still "works", so maybe it should be
documented before that changes in some large change
*cough*tree-ssa*cough*.  No, I haven't "make info && make
dvi"-tested this patch, but Tom Tromey will. ;-)  Maybe the
wording could need some tweaking; that's fine with me.

	* doc/extend.texi (Function Attributes): Mention the exceptional
	path for noreturn-marked functions.

Index: extend.texi
RCS file: /cvs/gcc/gcc/gcc/doc/extend.texi,v
retrieving revision 1.163
diff -p -c -r1.163 extend.texi
*** extend.texi	4 Oct 2003 10:53:09 -0000	1.163
--- extend.texi	8 Oct 2003 23:19:00 -0000
*************** would happen if @code{fatal} ever did re
*** 2020,2025 ****
--- 2020,2029 ----
  better code.  More importantly, it helps avoid spurious warnings of
  uninitialized variables.

+ The @code{noreturn} keyword does not affect the exceptional path when that
+ applies: a @code{noreturn}-marked function may still return to the caller
+ by throwing an exception.
  Do not assume that registers saved by the calling function are
  restored before calling the @code{noreturn} function.

brgds, H-P

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