Re: ep9312 Maverick Crunch support

[Petko Manolov <petkan at nucleusys dot com>]

On Thu, 1 Jul 2004, Richard Earnshaw wrote:

> Changes made to 'dot' releases are a trade-off of risks.  The priority
> is in fixing problems where previous releases of the compiler was
> correct but the new one fails (regressions).  Fixing bugs that have
> always existed comes a distinct second to that.  Big changes can be made
> if there is no chance of affecting known working parts of the compiler.
> If a change affects (or potentially affects) working code then the
> likelihood of a change being accepted depends substantially on the size
> of the change and the potential for it to affect existing ports that do
> work.  Larger changes are obviously more likely to be viewed with
> suspicion.

Yep, i do understand the concern.  I am pretty paranoid myself.  However,
in this particular case two things were softening that undesired effect:

	- if no Maverick Crunch related command line switch is specified
	  then ARM code generating path remains unchanged;

	- the patch isn't that big.  its largest part is the Pitre's soft
	  float code modified for Maverick Crunch calling convention.
	  which got placed in separate files;

We constructed the changes so they won't get in the way of the original 
code generating algorithm knowing that if we mess up something the whole 
ARM GCC port goes to hell.

> Regrettably there's nothing we (the GCC developers) can do about all
> this.  The FSF owns the copyright in GCC and insists that, as the
> maintainers of the code, we ensure that all contributions have correct
> assignments in place before incorporating them into the main
> distribution.

Excuse me if my message sounds like i am accusing the GCC developers, i 
didn't mean that.  I was just complaining about the bureaucracy we 
encountered quite unexpectedly.  We wasted more time in vain efforts to 
obtain that assignment than to do the coding.

And it is not like we are trying to release our work under different 
license. :-)


		Petko