Re: [JAVA] Fix bootstrap failure on Tru64

[Roger Sayle <roger at eyesopen dot com>]

On Thu, 22 Apr 2004, Andrew Haley wrote:
>  > 2004-04-12  Roger Sayle  <roger@eyesopen.com>
>  >
>  > 	* resource.c (write_resource_constructor): Guard call to possibly
>  > 	NULL targetm.asm_out.constructor with targetm.have_ctors_dtors.
>
> I'd still like a warning, please.


Why?  It's not an error condition or even an unusual occurrence.  Some
targets use collect2 to organize their constructors and destructors,
and other's don't.  This means that some platforms have to emit special
code for constructors and destructors (via this target hook), whilst
others platforms treat these functions appropriately just from the way
they are named (such as on Tru64).  The available functionality is
completely unaffected, its just how its implemented that differs.  A
typical platform difference.   It would be like issuing a warning "this
target is big endian", or "this target uses dwarf-2 exception handling".

I think the misunderstanding is that "have_ctors_dtors" doesn't state
whether a platform supports constructors or destructors, but instead
whether they need to be treated differently from other functions, for
example, placed in their own section.  If an operating system doesn't
have native support for constructors and destructors, GCC provides the
necessary functionality via collect2.  If a platform really couldn't
implement ctors/dtors, I doubt that we'd even try building g++ or gcj.


The quote the code in target-defs.h

#if defined(TARGET_ASM_CONSTRUCTOR) && defined(TARGET_ASM_DESTRUCTOR)
#define TARGET_HAVE_CTORS_DTORS true
#else
#define TARGET_HAVE_CTORS_DTORS false
#define TARGET_ASM_CONSTRUCTOR NULL
#define TARGET_ASM_DESTRUCTOR NULL
#endif


It's not a backend specific quirk, but the prescribed behaviour of this
interface that you must check TARGET_HAVE_CTORS_DTORS before using the
function pointers TARGET_ASM_CONSTRUCTOR or TARGET_ASM_DESTRUCTOR.
Everywhere else in the Java front-end, for example class.c, checks this
correctly, as do all of the other language front-ends.  The bug
is purely in resource.c.  The problem isn't that the pointer is NULL, by
definition its allowed to be, but that the code isn't checking whether
it is or not.  Similar code that checks have_ctors_dtors exists in
c-decl.c, coverage.c, cp/decl2.c, java/class.c, java/resource.c and
objc/objc-act.c, all of which would need a warning if we were to be
consistent with your request.


Were you to suggest that TARGET_ASM_CONSTRUCTOR and TARGET_ASM_DESTRUCTOR
should probably have default no-op target hooks, I'd agree with you, but
to issue a compile-time warning I feel is completely inappropriate.

Roger
--