Discussion:
Possible bug in GCC 5, need help
(too old to reply)
Mike Hommey
2015-08-15 10:30:01 UTC
Permalink
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
Parser<FullParseHandler>::bindLexical(BindData<FullParseHandler>* data,
HandlePropertyName name,
Parser<FullParseHandler>* 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
Stephen Powell
2015-08-21 00:20:02 UTC
Permalink
Post by Mike Hommey
...
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.
...
...
- 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
template <>
/* static */ bool
Parser<FullParseHandler>::bindLexical(BindData<FullParseHandler>* data,
HandlePropertyName name,
Parser<FullParseHandler>* 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 Powell <***@wowway.com>
: :' :
`. `'`
`-
Mike Hommey
2015-08-29 06:50:01 UTC
Permalink
Post by Stephen Powell
Post by Mike Hommey
...
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.
...
...
- 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
template <>
/* static */ bool
Parser<FullParseHandler>::bindLexical(BindData<FullParseHandler>* data,
HandlePropertyName name,
Parser<FullParseHandler>* 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
Andreas Krebbel
2015-08-31 11:20:02 UTC
Permalink
Post by Mike Hommey
Post by Stephen Powell
Post by Mike Hommey
...
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.
...
...
- 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
template <>
/* static */ bool
Parser<FullParseHandler>::bindLexical(BindData<FullParseHandler>* data,
HandlePropertyName name,
Parser<FullParseHandler>* 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.
https://people.debian.org/~glandium/Parser.o.tar.gz
I've bisected the problem. It occurred first with:

commit 90f3e775d6b7bec70e883579beb49b456c135a09
Author: wmi <***@138bc75d-0d04-0410-961f-82ee72b054a4>
Date: Thu Jan 22 17:59:23 2015 +0000

2015-01-22 Wei Mi <***@google.com>

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.

Bye,

-Andreas-
Stephen Powell
2015-08-31 22:40:01 UTC
Permalink
Post by Andreas Krebbel
commit 90f3e775d6b7bec70e883579beb49b456c135a09
Date: Thu Jan 22 17:59:23 2015 +0000
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 <***@wowway.com>
: :' :
`. `'`
`-
Loading...