Re: Possible bug in GCC 5, need help

[Stephen Powell]

On Mon, 31 Aug 2015 07:12:10 -0400 (EDT), Andreas Krebbel wrote:
> 
> I've bisected the problem. It occurred first with:
> 
> commit 90f3e775d6b7bec70e883579beb49b456c135a09
> Author: wmi 
> Date:   Thu Jan 22 17:59:23 2015 +
> 
> 2015-01-22  Wei Mi  
> 
> PR rtl-optimization/64557
> * dse.c (record_store): Call get_addr for mem_addr.
> (check_mem_read_rtx): Likewise.
> 
> With this patch an stc (store character) is dropped by the DSE pass
> (dead store elimination).  I'm currently auto-reducing the testcase
> to start debugging.  I'll open a GCC BZ with the reduced testcase.

You beat me to it.  Thanks, Andreas

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-

Re: Possible bug in GCC 5, need help

[Mike Hommey]

On Thu, Aug 20, 2015 at 08:17:27PM -0400, Stephen Powell wrote:
 On Sat, 15 Aug 2015 05:44:42 -0400 (EDT), Mike Hommey wrote:
  ...
  The current version of Iceweasel in unstable fails to build because of
  an internal error in the javascript engine which looks like it could be
  caused by some miscompilation.
  ...
  I was able to narrow it down as follows:
  ...
  - Building js/src/Parser.o with a #pragma GCC optimize(O0) at the
beginning fixes it.
  - Then I was able to go down at the function level, whereby moving the
following function at the end of the file and preceding it with the
pragma above fixes it:
  template 
  /* static */ bool
  ParserFullParseHandler::bindLexical(BindDataFullParseHandler* data,
HandlePropertyName name,
ParserFullParseHandler* parser)
  
(somehow, adding a #pragma GCC optimize(O3) after a O0 one doesn't
 raise optimization level for the rest of the file, what's why I
 double checked by moving the function)
  
  Could someone with s390x assembly knowledge look at the assembly for
  that function and narrow it down further, possibly filing a GCC bug?
 
 If you will produce a compiler listing that shows the generated machine
 language and pseudo-assembly language for the problem piece of code,
 both for the good case and the failing case, and send me a link to it,
 I'll take a look at it.  I can't promise you success, but I'll look at it.

Sorry, I missed the answer because I'm not subscribed and forgot to check
the ML.

I'm not sure how useful this is going to be, but here you are:
https://people.debian.org/~glandium/Parser.o.tar.gz

Mike

Re: Possible bug in GCC 5, need help

[Stephen Powell]

On Sat, 15 Aug 2015 05:44:42 -0400 (EDT), Mike Hommey wrote:
 ...
 The current version of Iceweasel in unstable fails to build because of
 an internal error in the javascript engine which looks like it could be
 caused by some miscompilation.
 ...
 I was able to narrow it down as follows:
 ...
 - Building js/src/Parser.o with a #pragma GCC optimize(O0) at the
   beginning fixes it.
 - Then I was able to go down at the function level, whereby moving the
   following function at the end of the file and preceding it with the
   pragma above fixes it:
 template 
 /* static */ bool
 ParserFullParseHandler::bindLexical(BindDataFullParseHandler* data,
   HandlePropertyName name,
   ParserFullParseHandler* parser)
 
   (somehow, adding a #pragma GCC optimize(O3) after a O0 one doesn't
raise optimization level for the rest of the file, what's why I
double checked by moving the function)
 
 Could someone with s390x assembly knowledge look at the assembly for
 that function and narrow it down further, possibly filing a GCC bug?

If you will produce a compiler listing that shows the generated machine
language and pseudo-assembly language for the problem piece of code,
both for the good case and the failing case, and send me a link to it,
I'll take a look at it.  I can't promise you success, but I'll look at it.

-- 
  .''`. Stephen Powellzlinux...@wowway.com
 : :'  :
 `. `'`
   `-

Possible bug in GCC 5, need help

[Mike Hommey]

Hi,

The current version of Iceweasel in unstable fails to build because of
an internal error in the javascript engine which looks like it could be
caused by some miscompilation. The same Iceweasel version doesn't
exhibit the problem when compiled on stretch.

An easier way to reproduce than to build iceweasel entirely is:
- install autotools-dev and python
- create a directory
- in that directory, run:
  /path/to/iceweasel-source/js/src/configure --without-intl-api
  make
- then run:
  dist/bin/js

Normally, you'd get a js prompt. On a broken build, you see:

self-hosted:16:0 InternalError: function nested too deeply:
self-hosted:16:0 }
self-hosted:16:0 ^

I was able to narrow it down as follows:
- Building js/src/Parser.o only with GCC 4.9 and all the rest with GCC
  5 fixes it.
- Building js/src/Parser.o with a #pragma GCC optimize(O0) at the
  beginning fixes it.
- Then I was able to go down at the function level, whereby moving the
  following function at the end of the file and preceding it with the
  pragma above fixes it:
template 
/* static */ bool
ParserFullParseHandler::bindLexical(BindDataFullParseHandler* data,
  HandlePropertyName name,
  ParserFullParseHandler* parser)

  (somehow, adding a #pragma GCC optimize(O3) after a O0 one doesn't
   raise optimization level for the rest of the file, what's why I
   double checked by moving the function)

Could someone with s390x assembly knowledge look at the assembly for
that function and narrow it down further, possibly filing a GCC bug?

Thanks,

Mike