This is the mail archive of the gcc-patches@gcc.gnu.org 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] PR c++/10031: Exception lists on builtins


At 16:15 12.03.2003, Roger Sayle wrote:

My apologies to everyone.  I thought Michael was investigating
this one, and as I was unable to reproduce the error on any of
my primary development platforms I was waiting to hear the
replies to his request for testers.

Anyway, it turns out that a cross-compiler to powerpc-linux is
able to reproduce the failure.

The problem is that C++ has two different mechanisms for specifying
the "nothrow" property on a function declaration.  The first, shared
with the C front-end, is to set the TREE_NOTHROW field on the
function declaration.  This is used by built-in functions, the
__attribute__ ((nothrow)) and by specifying "throw ()" after the
function declaration.

The second is C++'s native specification that associates with the
type of a function, the list of specific exceptions it throws.  In
this representation unspecified is a NULL_RTX, nothrow is an empty
TREE_LIST, and lists of exceptions are represented as lists of
exceptions.

Unfortunately, both built-ins and __attribute__((nothrow)) only
record their nothrow attribute in TREE_NOTHROW and don't (shouldn't!)
modify their types to set the exception list to an empty TREE_LIST.
The problem is that for builtins (i) these function types are created
in common front-end that doesn't have the notion of exception list
and (ii) may be shared between some functions that throw exceptions
and others that don't.


The one line solution is to avoid comparing exception lists when both functions are marked nothrow...

This has been tested with the cc1plus from my cross-compiler from
i686-pc-linux-gnu to powerpc-linux.  I'm currently bootstrapping
and regression testing on i686-pc-linux-gnu native.

Could someone test this for me on an affected platform where they
can run the testsuite?  Ok for mainline and 3.3 if there are no new
regressions?

Sorry, I'm about to leave for vacation and can't test during the next 2 weeks. I'm curious though, why doesn't this breakage show up on x86-linux? Since the rule for it to happen seems to be big-endian and/or 64-bit platforms, I expected some kind of mem initialization/corruption or a char/int pointertype mismatch problem.


Franz.


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