On Sat, Oct 03, 2015 at 08:58:19PM -0400, David Edelsohn wrote:
> The bug was not x86-specific.  The fix happens to be in
> target-specific code, but that's the luck of the draw.  Numerous other
> GCC developers have fixed bugs or added features that required tweaks
> to all ports.  Not all targets are easily accessible and you certainly
> can ask port maintainers to test a patch.  But writing that you don't
> have the cycles to fix all of the targets is not a collegial answer.
> Why do you believe that target maintainers have more cycles than you?
> I didn't see you tell Uros to fix the bug on x86.  The approach may
> work for your one specific bug, but it does not scale if every GCC
> developer pursues the same process.

I now sort of regret that I ever took up on this PR.

One would think that bringing a bug into the open and fixing at least
one target is preferable to keeping the bug unfixed, but apparently
you think otherwise.

> It's poor form to fix a bug only on x86 that is common to all targets
> and leave the problem "as an exercise for the reader" for all other
> targets -- essentially banishing the other targets to second-class
> status with respect to conformance -- especially when the change is
> mostly mechanical.  I don't expect developers to specifically enable
> and exploit every new feature on every architecture, but had expected
> bug fixes to be distributed to all targets.  "It's just not cricket."
 
The change is not really purely mechanical; if it was, I'd provide
patches for every target.  Yes, it's same in priciple for all targets,
but it needs a bit of debugging anyway -- and I can't debug e.g. MIPS.
Also, I'm not sure if TARGET_EXPRs can be used on every target.

> GCC has thrived for over 25 years -- supporting a huge number of
> targets and languages -- through a general sense of cooperation and
> collaboration to ensure the success of the entire project.  If this is
> going to degrade into a more parochial attitude, then maybe GCC will
> need an explicit policy to counteract that mindset.
 
Again, this wasn't a regression.  If I commit some middle end change that
breaks a target, sure, I should fix it, that is clear (and I've done so
in the past).

And note that I was following Joseph's suggestion (which makes sense to me).

> I am testing the attached patch for PPC.

I'd be surprised if this worked as-is, because you also need to change (some
of) COMPOUND_EXPRs to TARGET_EXPRs, but I don't know which one in particular,
because that's not clear to me by just looking at the code.

        Marek

Reply via email to