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 for PR c/12373

Ian Lance Taylor wrote:

PR c/12373 is about a crash which happens on sh-elf.  The crash occurs
when the compiler is checking whether an explicit declaration of
vprintf is compatible with the builtin declaration.  The relevant part
of the test case looks like this:

   typedef long __va_greg;
   typedef double __va_freg;

typedef struct {
__va_greg * __va_next_o; __va_greg * __va_next_o_limit; __va_freg * __va_next_fp; __va_freg * __va_next_fp_limit; __va_greg * __va_next_stack; } __gnuc_va_list;

int vprintf (const char *, __gnuc_va_list ) ;

This causes gcc to check whether __gnuc_va_list is the same as the
builtin type held in the variable va_list_type_node.

The C frontend gives va_list_type_node a name: __builtin_va_list.
When it does this, pushdecl() calls clone_underlying_type().
clone_underlying_type() does this:

 if (DECL_SOURCE_LINE (x) == 0)
     if (TYPE_NAME (TREE_TYPE (x)) == 0)

With a non-built-in type, clone_underlying_type() duplicates the type
node.  The above is a special case if the type is a built-in type.  I
guess that this is for efficiency.

The important point here is that the result is that we have a type
with TYPE_NAME set but DECL_ORIGINAL_TYPE not set.  This can only
happen for a built-in type.  It does not appear to be a bug.  The code
has worked this way since the CVS repository was created.

Last year, Geoff added the function tagged_types_tu_compatible_p() as
part of the big intermodule patch.  This function checks whether two
types are compatible.  It does this:

 while (TYPE_NAME (t1) && TREE_CODE (TYPE_NAME (t1)) == TYPE_DECL)

The problem, of course, is that this assumes that if TYPE_NAME is set
that DECL_ORIGINAL_TYPE is set.  As we can see from the above, this is
not the case for a built-in type.

The comment above tagged_types_tu_compatible_p() appears to say that
this sort of case can only arise when compiling multiple translation
units.  This test case shows that the comment is wrong, unless you
consider the builtin declarations to be a separate translation unit.

Anyhow, the fix to the code would seem to be straightforward.

OK for mainline?

This PR is currently targeted at 3.4.0. Mark, let me know if you want
this patch on the 3.4 branch. The patch should never introduce a new
crash. But I suppose it is conceivable that it could introduce a case
where the compiler currently crashes but, after this patch, it
generates bad code. I think that is unlikely in this case.

OK for 3.4.0. Thanks!

Mark Mitchell
CodeSourcery, LLC
(916) 791-8304

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