This is the mail archive of the
mailing list for the GCC project.
Re: BountySource campaign for gcc PR/91851
- From: Segher Boessenkool <segher at kernel dot crashing dot org>
- To: Georg-Johann Lay <gjl at gcc dot gnu dot org>
- Cc: John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin dot de>, Peter Bergner <bergner at linux dot ibm dot com>, gcc at gcc dot gnu dot org
- Date: Thu, 31 Oct 2019 20:06:08 -0500
- Subject: Re: BountySource campaign for gcc PR/91851
- References: <email@example.com> <5DB9E51B.firstname.lastname@example.org> <email@example.com> <5DBB4B51.firstname.lastname@example.org> <email@example.com> <5DBB6443.firstname.lastname@example.org>
On Thu, Oct 31, 2019 at 11:46:27PM +0100, Georg-Johann Lay wrote:
> For AVR -- an other port affected by cc0 removal -- there is a
> LLVM/Clang port. It' not as mature as GCC's avr port, but what counts
> in the end is support / responsiveness from the community and an
> openness for the requirements of deeply embedded targets.
And you think you find that less in GCC? Huh.
> I had gcc
> patches rejected by global maintainers (just a no-op hook for other
> targets) because it appeared they didn't even understand what the patch
> is about (and kept proposing alternative "solutions" that totally missed
> the point).
Please point me to that. In private mail, if you prefer.
> And code quality is deteriorating from version to version. Whatever you
> do in the backend to mitigate it, there's always global changes that
> shreds any improvements...
I don't see that. Things that aren't maintained and have no good tripwire
tests for code quality can (and will) degrade naturally, of course. But
maintained targets do not normally have a hard time keeping up.
> Btw, does GCC support clobbering registers in branches (or
> cbranch<mode>4 for that matter)? This requirement would come up when
> transitioning avr to cc_mode because cbranches would live post reload.
Of course. You cannot have *reloads* on branches, that is all.