This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] PR middle-end/19378: Fix AVR build failures
- From: Paul Schlie <schlie at comcast dot net>
- To: Roger Sayle <roger at eyesopen dot com>
- Cc: <gcc-patches at gcc dot gnu dot org>
- Date: Sun, 16 Jan 2005 11:55:14 -0500
- Subject: Re: [PATCH] PR middle-end/19378: Fix AVR build failures
Roger Sayle wrote:
> The following patch resolves PR middle-end/19378 which is an ICE
> compiling libgcc for AVR, due to an abort in reload.c's find_valid_class.
Yup, can verify the successful build of today's 4.0 cvs version with only
this patch applied for --target=avr.
However note that while attempting to determine the problem earlier, had
noticed a few things which are fragilely implemented in GCC and should be
fixed sooner than later, although not literally required by this PR:
- unwind.h & unwind_pe.h unconditionally define DI mode exception variables,
regardless of whether a target can support them (resulting both in an
otherwise needless requirement for target DI mode support, and general
unwind inefficiency on smaller targets, as DI exception variables are
- libgcc2 in general should likely be cleaned up, as libgcc2.h's logic
which determines built-in default support function modes is minimally
odd, and most likely simply wrong, impeding it's clear, proper, and
correct behavior, impeding new port specification or refinement; (most
existing ports seem to tend to just disable much if it by defining their
own definitions apparently rather than attempting to refine/correct it's
implementation; which should likely be done if for no other reason than
to enable the easier, flexible, and correct definitions of new targets).
How/where would these observations be best recorded/requested, as this PR
will likely close (thereby effectively ironically diminishing the necessity
to remedy the two above issues, which should likely remain important)?
(As presently for example, the avr port must support DI mode although very
inefficient; and needs to "trick" libgcc2.h by having to "lie" about it's
it's true word-size when it's machine specification is included by it.)