Re: [PATCH] 1.8.3 p1 segfault in array.c- bccwin32 - bcc5.5 (free) compiler bug

From: "H.Yamamoto" <ocean@m2.....jp>


> [...]
>
> Honestly, I want Borland to fix this. I found bug tracking system on their site,
> so I think this is the place for letting them know the problem.
> (http://qc.borland.com/wc/qcmain.aspx)
>
> But probably they won't fix this.... because another two years old inline bug report
> is still unfixed. http://qc.borland.com/wc/qcmain.aspx?d=4784
>

Hmm - and that's for C++Builder 6.0

I read that they will only accept bug reports for actively supported products.
- bcc55 (from C++Builder 5.0) is listed as "De-Supported" ...
   (apparently, Borland can invent English words ;)
http://support.borland.com/entry.jspa?externalID=129


> Anyway, we did some workaround already, so there is no reason not to do another
> workaround.
>
> [...]
>       p->value >>= 1; /* SEGV */ /* won't SEGV if p->value = p->value >> 1 */

Unfortunate :(

>
> But I don't like workaround, even on above bug, I propsed not to use __int64 totally.
> So I want to recommend not to use inline.
>
>   make OPTFLAGS="-v- -vi- -O2"

As you imply, all compilers have bugs and/or nuances and any workaround
is likely to be ugly (just knowing it's there).

However, I think that the inlines are an integral part of Ruby's design
and only a single use is affected.

So (in "sort_2"), something like:

  #if __BORLANDC__ == 0x551
      /* Prevent SEGV - bcc optimization bug [ruby-core:xxxxx] */
      if (TYPE(a) == T_STRING) if (TYPE(b) == T_STRING) {
  #else
      if (TYPE(a) == T_STRING && TYPE(b) == T_STRING) {
  #endif

- squashes this bug regardless of options.

>
> # bcc32 port maintainer KONISHI Hiromasa might have a different thought.
>

Good luck with your decisions; I think I'll patch locally, anyway.


daz