This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Correct thinko (DECL_RTL to DECL_RTL_SET_P) in function.c
- From: "Joseph S. Myers" <jsm at polyomino dot org dot uk>
- To: Waldek Hebisch <hebisch at math dot uni dot wroc dot pl>
- Cc: ebotcazou at libertysurf dot fr, mark at codesourcery dot com, gcc-patches at gcc dot gnu dot org
- Date: Fri, 14 Nov 2003 18:26:31 +0000 (UTC)
- Subject: Re: [PATCH] Correct thinko (DECL_RTL to DECL_RTL_SET_P) in function.c
- References: <E1AKi0y-00033Tfirstname.lastname@example.org>
On Fri, 14 Nov 2003, Waldek Hebisch wrote:
> the diff is a change to set handling. AFAIK it was written by Peter
> Gerwinski and was scheduled for inclusion in GCC 3.0 -- at the moment
> I was unable to find any trace of that patch on GCC mailing lists.
There were some arguments about what the right handling should be in the
context of the Chill front end as well. Since the Chill front end is gone
and there is no sign of the effort being made to reintegrate it, I think
that should no longer be relevant.
> There is about dozen smaller patches -- mostly what I consider
> bug fixes, but some may be controversial.
> My feeling was that all of the patches are proper for consideration
> in 3.4. They are small localised changes each trying to resolve single
> problem. IMHO if a patch fixes bug in GCC the it should be applied, if
> not GPC need to be fixed. To decide I need feedback from GCC developers.
Submit all the patches (in separate messages, each patch independently
regression tested against mainline CVS on a named platform - you could
test on multiple simulator platforms as well if more assurance is wanted,
but this shouldn't be necessary). Submit them in parallel as far as
possible - don't wait for questions about one patch to be resolved before
submitting other patches that don't depend on it. In each submission,
identify if possible a named testcase in the GPC testsuite that this patch
fixes (on a specified platform, if target-specific), or e.g. "building the
GPC runtime library" if that's what the patch is needed for. If any patch
receives no discussion of the merits of that patch for a couple of weeks,
resubmit and keep resubmitting as necessary. This doesn't guarantee that
the patches get reviewed, but repeated resubmission is often necessary
anyway for anyone submitting a patch for any part of the compiler they
Joseph S. Myers