[Info-vax] Beyond Open Source

[johnwallace4 at yahoo.co.uk]

On Monday, 11 May 2015 17:29:41 UTC+1, Stephen Hoffman  wrote:
> On 2015-05-11 15:59:45 +0000, David Froble said:
> 
> > John Reagan wrote:
> >> On Monday, May 11, 2015 at 7:51:26 AM UTC-4, Neil Rieck wrote:
> >> 
> >>> I heard (third hand) about problems using Linux on multi-CPU x86-64 
> >>> where one cpu will occasionally "get locked into a tight loop" and no 
> >>> one knows how to fix it. The customer who continually experiences the 
> >>> problem contacted "the curator" only to be told that the problem might 
> >>> have something to do with the quality of the code generated by the gcc 
> >>> compiler. Huh?
> >> 
> >> That feels more like a system spinlock problem or somebody decided to 
> >> "write their own".  gcc doesn't know from spinlocks.  ...
> > 
> > It doesn't really matter how wide-spread a problem is, if it is YOUR problem.
> > ...
> 
> So far, we have an unsubstantiated third-hand report of an unspecified 
> looping issue, involving unspecified x86-64 hardware, with no 
> attribution, no bug number, and potentially questionable allegations of 
> gcc code-generation involvement?
> 
> If nothing else, this does make a decent case for improved error 
> reporting and better diagnostics, irrespective of the identity of "the 
> curator" or of the particular application or system platform.    Also 
> that outsourcing the risk and the blame can sometimes still blow up on 
> you.
> 
> ps: if you think OpenVMS hasn't had a few of these weird 
> instruction-level locking bugs, you've probably not recently 
> contemplated on the origin of the the SRM_CHECK tool.   Yes, that did 
> get fixed.   As for the above report, I'm *certain* we'll learn what 
> happened with the unattributed bug in the unspecified application with 
> the unknown issue and the unidentified customer and the mystery support 
> and reputedly with the involvement of the gcc compiler, of course.
> 
> 
> 
> 
> -- 
> Pure Personal Opinion | HoffmanLabs LLC

I remember SRM_CHECK, vaguely.

Non-DEC: I'm also aware of a gcc/gas situation where the
compiler is expected to workaround a misfeature in the hardware
which if not properly handled leads to unexpected results. 

This will not be the one Roland's been referencing (well, it's
almost infinitely improbable that it will) because it's a rather
obscure target and it's highly unlikely anyone here has ever
heard of it, let alone programmed for it. Unless you're a close
follower of gcc cauldron and/or Adacore.

I wasn't a compiler developer or hardware developer but colleagues
were. I'm not in a position to post details here, however, ask
nicely and you might get email (which won't be very exciting).

That doesn't tell us anything about Roland's issue, but this one
is certainly genuine, and it would be a surprise if issues similar
weren't hiding away somewhere on other more complex and more
widely deployed targets.