[Bug d/94623] New: ice for ./gdc.test/compilable/interpret3.d

[Bug d/94623] New: ice for ./gdc.test/compilable/interpret3.d

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94623

            Bug ID: 94623
           Summary: ice for ./gdc.test/compilable/interpret3.d
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: d
          Assignee: ibuclaw at gdcproject dot org
          Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

For the D source code file in the title line, I get

$ /home/dcb/gcc/results/bin/gdc -c ./gdc.test/compilable/interpret3.d 2>&1 |
more
d21: internal compiler error: in chainExceptions, at d/dmd/dinterpret.c:1661
0x8ac29f Interpreter::chainExceptions(ThrownExceptionExp*, ThrownExceptionExp*)
        ../../trunk.git/gcc/d/dmd/dinterpret.c:1661
0x8ac29f Interpreter::visit(TryFinallyStatement*)
        ../../trunk.git/gcc/d/dmd/dinterpret.c:1725
0x8a2f4d interpret
        ../../trunk.git/gcc/d/dmd/dinterpret.c:6205
0x8a2f4d Interpreter::visit(ScopeStatement*)
        ../../trunk.git/gcc/d/dmd/dinterpret.c:1136

on recent gcc trunk.

[Bug d/94623] ice for ./gdc.test/compilable/interpret3.d

[ibuclaw at gdcproject dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94623

--- Comment #1 from Iain Buclaw <ibuclaw at gdcproject dot org> ---
Needs more host/target information.

[Bug d/94623] ice for ./gdc.test/compilable/interpret3.d

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94623

--- Comment #2 from David Binderman <dcb314 at hotmail dot com> ---
Host and target are the same: x86_64-pc-linux-gnu

[Bug d/94623] ice for ./gdc.test/compilable/interpret3.d

[ibuclaw at gdcproject dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94623

--- Comment #3 from Iain Buclaw <ibuclaw at gdcproject dot org> ---
(In reply to David Binderman from comment #2)
> Host and target are the same: x86_64-pc-linux-gnu

Going to really have to need configure flags, host gcc version, glibc version,
etc.

[Bug d/94623] ice for ./gdc.test/compilable/interpret3.d

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94623

--- Comment #4 from David Binderman <dcb314 at hotmail dot com> ---
Configure flags:

../trunk.git/configure --prefix=/home/dcb/gcc/results.20200416 \
    --disable-bootstrap \
    --disable-multilib \
    --disable-werror \
    --enable-checking=df,extra,fold,rtl,yes \
    --enable-languages=ada,c,c++,d,fortran,go

sed 's/-O2/-O3 -march=native/' < Makefile > Makefile.tmp
mv Makefile.tmp Makefile

Host gcc version is 9.3.1 and glibc version is 2.30 on fedora x86_64.

The line that ices is the following:

        assert((*collateral->value->elements)[5]->type->ty == Tclass);

Hopefully that is enough information to be able to attempt to reproduce
the problem.

[Bug d/94623] ice for ./gdc.test/compilable/interpret3.d

[ibuclaw at gdcproject dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94623

--- Comment #5 from Iain Buclaw <ibuclaw at gdcproject dot org> ---
(In reply to David Binderman from comment #4)
> Configure flags:
> 
> ../trunk.git/configure --prefix=/home/dcb/gcc/results.20200416 \
>     --disable-bootstrap \
>     --disable-multilib \
>     --disable-werror \
>     --enable-checking=df,extra,fold,rtl,yes \
>     --enable-languages=ada,c,c++,d,fortran,go
> 
> sed 's/-O2/-O3 -march=native/' < Makefile > Makefile.tmp
> mv Makefile.tmp Makefile
> 
> Host gcc version is 9.3.1 and glibc version is 2.30 on fedora x86_64.
> 
> The line that ices is the following:
> 
>         assert((*collateral->value->elements)[5]->type->ty == Tclass);
> 
> Hopefully that is enough information to be able to attempt to reproduce
> the problem.

g++ host: gcc version 9.3.1 20200419 (GCC) 
glibc: 2.30-0ubuntu2.1 (ubuntu x86_64-linux-gnu)
gdc build: gcc version 10.0.1 20200419 (experimental) (GCC) 
gdc configure: ../configure --disable-bootstrap --disable-multilib
--enable-werror --enable-checking=df,extra,fold,rtl,yes
--enable-languages=c++,d


$ make check-gcc-d RUNTESTFLAGS="compilable.exp=interpret3.d --all"
...
PASS: compilable/interpret3.d   (test for excess errors)
PASS: compilable/interpret3.d   output-exists interpret3.o
PASS: compilable/interpret3.d -finline-functions   (test for excess errors)
PASS: compilable/interpret3.d -finline-functions    output-exists interpret3.o
...


Can't say I can reproduce at all.

IIRC, Fedora has some compiler hardening patches switched on by default.  I'll
try once more with '-O3 -march=native -fstack-protector-strong'

[Bug d/94623] ice for ./gdc.test/compilable/interpret3.d

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94623

--- Comment #6 from David Binderman <dcb314 at hotmail dot com> ---
I removed the sed lines from my configure script and did a build of D
from today's gcc trunk and it's still going wrong:

Configure line is now:

../trunk.git/configure --prefix=/home/dcb/gcc/results.20200420.d \
        --disable-bootstrap \
        --disable-multilib \
        --disable-werror \
        --enable-checking=df,extra,fold,rtl,yes \
        --enable-languages=d

and here is the run:

$ ./results.20200420.d/bin/gdc -c
trunk.git/gcc/testsuite/gdc.test/compilable/interpret3.d
d21: internal compiler error: in chainExceptions, at d/dmd/dinterpret.c:1661

Merely to eliminate the obvious: what happens if you try
to run the D compiler directly from the command line, thus
not using the gcc test infrastructure ?

I'll reduce the checking flags down to "no" and see what happens.

I notice that the D source code file is about 7,700 lines of code.
I wonder if creduce understands D ?

[Bug d/94623] ice for ./gdc.test/compilable/interpret3.d

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94623

--- Comment #7 from David Binderman <dcb314 at hotmail dot com> ---
>I wonder if creduce understands D ?

Yes it does. Reduced D code is

void a() {
  try
    try
      try
        throw new Exception("");
  finally throw new Error("");
  finally {}
  catch {
  }
}
int b() {
  a;
  return 1;
}
static assert(b);

[Bug d/94623] ice for ./gdc.test/compilable/interpret3.d

[ibuclaw at gdcproject dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94623

--- Comment #8 from Iain Buclaw <ibuclaw at gdcproject dot org> ---
(In reply to David Binderman from comment #7)
> >I wonder if creduce understands D ?
> 
> Yes it does. Reduced D code is
> 
> void a() {
>   try
>     try
>       try
>         throw new Exception("");
>   finally throw new Error("");
>   finally {}
>   catch {
>   }
> }
> int b() {
>   a;
>   return 1;
> }
> static assert(b);

Thanks, alternatively, there is dustmite (which is made specifically for D)

https://github.com/CyberShadow/DustMite

Built using: gdc dustmite.d splitter.d polyhash.d -o dustmite

[Bug d/94623] ice for ./gdc.test/compilable/interpret3.d

[ibuclaw at gdcproject dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94623

--- Comment #9 from Iain Buclaw <ibuclaw at gdcproject dot org> ---
(In reply to David Binderman from comment #6)
> I removed the sed lines from my configure script and did a build of D
> from today's gcc trunk and it's still going wrong:
> 
> Configure line is now:
> 
> ../trunk.git/configure --prefix=/home/dcb/gcc/results.20200420.d \
> 	--disable-bootstrap \
> 	--disable-multilib \
> 	--disable-werror \
> 	--enable-checking=df,extra,fold,rtl,yes \
> 	--enable-languages=d
> 
> and here is the run:
> 
> $ ./results.20200420.d/bin/gdc -c
> trunk.git/gcc/testsuite/gdc.test/compilable/interpret3.d
> d21: internal compiler error: in chainExceptions, at d/dmd/dinterpret.c:1661
> 
> Merely to eliminate the obvious: what happens if you try
> to run the D compiler directly from the command line, thus
> not using the gcc test infrastructure ?
> 

Yes, still it is elusive on my end.

Can you try building with --enable-bootstrap?

[Bug d/94623] ice for ./gdc.test/compilable/interpret3.d

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94623

--- Comment #10 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to David Binderman from comment #6)
> I'll reduce the checking flags down to "no" and see what happens.

It works fine. So it looks like one of the checking flags 
(df,extra,fold,rtl,yes) breaks it.

It will take a few hours, but I'll try to find out which one.

[Bug d/94623] ice for ./gdc.test/compilable/interpret3.d

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94623

--- Comment #11 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to David Binderman from comment #10)
> (In reply to David Binderman from comment #6)
> > I'll reduce the checking flags down to "no" and see what happens.
> 
> It works fine. So it looks like one of the checking flags 
> (df,extra,fold,rtl,yes) breaks it.
> 
> It will take a few hours, but I'll try to find out which one.

Checking flag "extra" is the one.

[Bug d/94623] ice for ./gdc.test/compilable/interpret3.d

[ibuclaw at gdcproject dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94623

--- Comment #12 from Iain Buclaw <ibuclaw at gdcproject dot org> ---
(In reply to David Binderman from comment #11)
> (In reply to David Binderman from comment #10)
> > (In reply to David Binderman from comment #6)
> > > I'll reduce the checking flags down to "no" and see what happens.
> > 
> > It works fine. So it looks like one of the checking flags 
> > (df,extra,fold,rtl,yes) breaks it.
> > 
> > It will take a few hours, but I'll try to find out which one.
> 
> Checking flag "extra" is the one.

Without knowing too much about what that checking flag does.  That would be
highly odd if that were the case, as the dmd implementation sits "outside" of
gcc.

The only bridge that is connecting the two is d/d-system.h, which does some
necessary #define's to fix portability and use of gcc_assert.

[Bug d/94623] ice for ./gdc.test/compilable/interpret3.d

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94623

--- Comment #13 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to Iain Buclaw from comment #12)
> (In reply to David Binderman from comment #11)
> > Checking flag "extra" is the one.
> 
> Without knowing too much about what that checking flag does.  That would be
> highly odd if that were the case, as the dmd implementation sits "outside"
> of gcc.
> 
> The only bridge that is connecting the two is d/d-system.h, which does some
> necessary #define's to fix portability and use of gcc_assert.

A possible next step is for you to try a build with checking
flag extra switched on and see what happens.

At least that would confirm or deny what I am seeing here.

I don't think bootstrap is required.

[Bug d/94623] ice for ./gdc.test/compilable/interpret3.d

[ibuclaw at gdcproject dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94623

--- Comment #14 from Iain Buclaw <ibuclaw at gdcproject dot org> ---
(In reply to David Binderman from comment #13)
> (In reply to Iain Buclaw from comment #12)
> > (In reply to David Binderman from comment #11)
> > > Checking flag "extra" is the one.
> > 
> > Without knowing too much about what that checking flag does.  That would be
> > highly odd if that were the case, as the dmd implementation sits "outside"
> > of gcc.
> > 
> > The only bridge that is connecting the two is d/d-system.h, which does some
> > necessary #define's to fix portability and use of gcc_assert.
> 
> A possible next step is for you to try a build with checking
> flag extra switched on and see what happens.
> 
> At least that would confirm or deny what I am seeing here.
> 
> I don't think bootstrap is required.

I can only deny what you are seeing.  It might be possible that the object.d
module being picked up by gdc is not the same version supplied by libphobos.

Do you have another D compiler installed?  Possibly one newer than 2.078?

More specifically, I'm thinking of https://github.com/dlang/dmd/pull/6689

But the related druntime change did not go in till 8 months (and two releases)
later.

[Bug d/94623] ice for ./gdc.test/compilable/interpret3.d

[ibuclaw at gdcproject dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94623

--- Comment #15 from Iain Buclaw <ibuclaw at gdcproject dot org> ---
Created attachment 48316
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48316&action=edit
adjust hardcoded index of Error.bypassException

Can you apply this and see if it goes away?

If this fixes it, then that answer is almost certainly is yes, you do have
another (newer) D compiler installed.

You can also confirm by compiling the test with: gdc -v

That will dump all front-end related information about the imports/semantic
passes (including where a module was found).

[Bug d/94623] ice for ./gdc.test/compilable/interpret3.d

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94623

--- Comment #16 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to Iain Buclaw from comment #15)
> Created attachment 48316 [details]
> adjust hardcoded index of Error.bypassException
> 
> Can you apply this and see if it goes away?

I applied your patch and the problem seems to go away.

> If this fixes it, then that answer is almost certainly is yes, you do have
> another (newer) D compiler installed.
> 
> You can also confirm by compiling the test with: gdc -v

I am struggling to understand what this output means:

binary   
/home/dcb/gcc/results.20200420.d5/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/d21
version   v2.076.1
predefs   GNU D_Version2 LittleEndian GNU_DWARF2_Exceptions GNU_StackGrowsDown
GNU_InlineAsm D_LP64 assert D_ModuleInfo D_Exceptions D_TypeInfo all X86_64
D_HardFloat Posix linux CRuntime_Glibc CppRuntime_Gcc
parse     interpret3
importall interpret3
import    object        (/usr/include/d/object.d)
import    core.internal.hash    (/usr/include/d/core/internal/hash.d)
import    core.internal.traits  (/usr/include/d/core/internal/traits.d)
import    core.internal.convert (/usr/include/d/core/internal/convert.d)
semantic  interpret3
import    core.stdc.string      (/usr/include/d/core/stdc/string.d)
semantic2 interpret3
semantic3 interpret3
code      interpret3
function  interpret3.arrayRetTest
function  interpret3.ice3842
function  interpret3.arrayret2
function  interpret3.dotvar1
function  interpret3.dotvar2
function  interpret3.reffunc1
function  interpret3.reffunc2
function  interpret3.reffunc7
function  interpret3.reffunc3
function  interpret3.RefTestStruct.reffunc4
function  interpret3.RefTestStruct.reffunc6

but which gdc says I have no D compiler installed.

[Bug d/94623] ice for ./gdc.test/compilable/interpret3.d

[ibuclaw at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94623

ibuclaw at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ibuclaw at gcc dot gnu.org

--- Comment #17 from ibuclaw at gcc dot gnu.org ---
(In reply to David Binderman from comment #16)
> 
> I am struggling to understand what this output means:
> 
> binary   
> /home/dcb/gcc/results.20200420.d5/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/d21
> version   v2.076.1
> predefs   GNU D_Version2 LittleEndian GNU_DWARF2_Exceptions
> GNU_StackGrowsDown GNU_InlineAsm D_LP64 assert D_ModuleInfo D_Exceptions
> D_TypeInfo all X86_64 D_HardFloat Posix linux CRuntime_Glibc CppRuntime_Gcc
> parse     interpret3
> importall interpret3
> import    object	(/usr/include/d/object.d)
> import    core.internal.hash	(/usr/include/d/core/internal/hash.d)
> import    core.internal.traits	(/usr/include/d/core/internal/traits.d)
> import    core.internal.convert	(/usr/include/d/core/internal/convert.d)
> semantic  interpret3
> import    core.stdc.string	(/usr/include/d/core/stdc/string.d)


It's picking up the modules from a system location.  These most certainly don't
belong to the gdc compiler.  Which bad package maintainer is installing
compiler-specific modules in a common location? LDC?

[Bug d/94623] ice for ./gdc.test/compilable/interpret3.d

[ibuclaw at gdcproject dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94623

--- Comment #18 from Iain Buclaw <ibuclaw at gdcproject dot org> ---
(In reply to ibuclaw from comment #17)
> It's picking up the modules from a system location.  These most certainly
> don't belong to the gdc compiler.  Which bad package maintainer is
> installing compiler-specific modules in a common location? LDC?

A quick look at ldc on app.fedoraproject.org, and there's a reference to this
bug report.

https://bugzilla.redhat.com/show_bug.cgi?id=1781685

[Bug d/94623] ice for ./gdc.test/compilable/interpret3.d

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94623

--- Comment #19 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to ibuclaw from comment #17)
> (In reply to David Binderman from comment #16)
> > 
> > I am struggling to understand what this output means:
> > 
> It's picking up the modules from a system location.  These most certainly
> don't belong to the gdc compiler.  Which bad package maintainer is
> installing compiler-specific modules in a common location? LDC?

I have package ldc-druntime-devel version 1.15.0 installed, 
so that looks to be the source of the problem.

[Bug d/94623] ice for ./gdc.test/compilable/interpret3.d

[ibuclaw at gdcproject dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94623

--- Comment #20 from Iain Buclaw <ibuclaw at gdcproject dot org> ---
(In reply to David Binderman from comment #19)
> (In reply to ibuclaw from comment #17)
> > (In reply to David Binderman from comment #16)
> > > 
> > > I am struggling to understand what this output means:
> > > 
> > It's picking up the modules from a system location.  These most certainly
> > don't belong to the gdc compiler.  Which bad package maintainer is
> > installing compiler-specific modules in a common location? LDC?
> 
> I have package ldc-druntime-devel version 1.15.0 installed, 
> so that looks to be the source of the problem.

Yes, that would most certainly be the case.

I can apply the patch anyway, as it's good to not ICE.  However it won't
prevent the possibility of linker errors due to mismatches in ldc-druntime-dev
and libgphobos.

[Bug d/94623] ice for ./gdc.test/compilable/interpret3.d

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94623

--- Comment #21 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Iain Buclaw <ibuclaw@gcc.gnu.org>:

https://gcc.gnu.org/g:46cf683bf16491a0bd1d77d8b0cce0e11cf1d46f

commit r10-7839-g46cf683bf16491a0bd1d77d8b0cce0e11cf1d46f
Author: Iain Buclaw <ibuclaw@gdcproject.org>
Date:   Tue Apr 21 08:50:12 2020 +0200

    d/dmd: Merge upstream dmd 62ce36f37

    Adjusts the hardcoded index of Error.bypassException.

    Fixes: PR d/94623

    Reviewed-on: https://github.com/dlang/dmd/pull/11052

[Bug d/94623] ice for ./gdc.test/compilable/interpret3.d

[ibuclaw at gdcproject dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94623

Iain Buclaw <ibuclaw at gdcproject dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://bugzilla.redhat.com
                   |                            |/show_bug.cgi?id=1781685
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |MOVED

--- Comment #22 from Iain Buclaw <ibuclaw at gdcproject dot org> ---
Fix for the immediate ICE has been committed.  The underlying cause is not a
bug in gdc.

[Bug d/94623] ice for ./gdc.test/compilable/interpret3.d

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94623

--- Comment #23 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to Iain Buclaw from comment #20)
> I can apply the patch anyway, as it's good to not ICE.  

Agreed.

> However it won't prevent the possibility of linker errors due to mismatches in
> ldc-druntime-dev and libgphobos.

Worse than that ?

It is silently linking with the wrong set of files and producing run time
errors.

Maybe it would be a good idea to put some code into the linkage process
to make sure linkage only occurs with files the compiler knows about.

[Bug d/94623] ice for ./gdc.test/compilable/interpret3.d

[ibuclaw at gdcproject dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94623

--- Comment #24 from Iain Buclaw <ibuclaw at gdcproject dot org> ---
(In reply to David Binderman from comment #23)
> 
> Worse than that ?
> 
> It is silently linking with the wrong set of files and producing run time
> errors.
> 
> Maybe it would be a good idea to put some code into the linkage process
> to make sure linkage only occurs with files the compiler knows about.

Modules are not pre-compiled (unlike Go/C++/Fortran?).

The only scenario to consider really is the following:

gdc: module std.example; int myfunction(int a) pure nothrow {...}
ldc: module std.example; int myfunction(int a) pure nothrow @safe {...}

If the wrong module is imported, when linking, you'll get a linker error:

  undefined reference to 'myfunction(int) pure nothrow @safe'

As the '@safe' attribute is encoded in the mangled symbol, and that doesn't
exist in gdc's libgphobos.a/so

[Bug d/94623] ice for ./gdc.test/compilable/interpret3.d

[ibuclaw at gdcproject dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94623

--- Comment #25 from Iain Buclaw <ibuclaw at gdcproject dot org> ---
Secondly, the ICE that you managed to catch occurred during CTFE (Compile-time
function evaluation).  Nothing that is done here leaks out to the generated
run-time code.