[Bug lto/99447] New: [11 Regression] ICE (segfault) in lookup_page_table_entry

[Bug lto/99447] New: [11 Regression] ICE (segfault) in lookup_page_table_entry

[doko at debian dot org]

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

            Bug ID: 99447
           Summary: [11 Regression] ICE (segfault) in
                    lookup_page_table_entry
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
          Assignee: unassigned at gcc dot gnu.org
          Reporter: doko at debian dot org
                CC: marxin at gcc dot gnu.org
  Target Milestone: ---

seen with trunk 20210306 on x86_64-linux-gnu building the guymager package with
LTO.

$ g++ -Wl,-z,relro -ggdb -rdynamic -Wl,-flto -Wl,-z,relro -Wl,-O3 -o guymager
compileinfo.o aaff.o aewf.o config.o device.o dlgabort.o dlgacquire.o
dlgdirsel.o dlgautoexit.o dlgmessage.o dlgwait.o error.o fifo.o file.o hash.o
info.o infofield.o itemdelegate.o main.o mainwindow.o md5.o media.o qtutil.o
runstats.o sha1.o sha256.o table.o thread.o threadcompress.o threadhash.o
threadread.o threadscan.o threadwrite.o util.o moc_devicelistmodel.o
moc_dlgabort.o moc_dlgacquire.o moc_dlgautoexit.o moc_dlgacquire_private.o
moc_dlgdirsel.o moc_dlgdirsel_private.o moc_dlgmessage.o moc_dlgwait.o
moc_info.o moc_infofield.o moc_itemdelegate.o moc_main_private.o
moc_mainwindow.o moc_table.o moc_thread.o moc_threadcompress.o moc_threadhash.o
moc_threadread.o moc_threadscan.o moc_threadwrite.o   -lz -ldl -lguytools -lewf
-lbfio /usr/lib/x86_64-linux-gnu/libQt5Widgets.so
/usr/lib/x86_64-linux-gnu/libQt5Gui.so /usr/lib/x86_64-linux-gnu/libQt5DBus.so
/usr/lib/x86_64-linux-gnu/libQt5Core.so -lGL -lpthread
device.cpp: In member function ‘GetErrorText’:
device.cpp:155:1: internal compiler error: Segmentation fault
  155 | }
      | ^
0xc52c79 crash_signal
        ../../src/gcc/toplev.c:327
0x7f3b6994fd5f ???
        ./signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x11ac4fb lookup_page_table_entry
        ../../src/gcc/ggc-page.c:630
0x11ac4fb ggc_set_mark(void const*)
        ../../src/gcc/ggc-page.c:1544
0x13bdefd gt_ggc_mx_basic_block_def(void*)
        /build/gcc-11-7yDrbQ/gcc-11-11-20210306/build/gcc/gtype-desc.c:1527
0x13bc981 gt_ggc_mx_gimple(void*)
        /build/gcc-11-7yDrbQ/gcc-11-11-20210306/build/gcc/gtype-desc.c:1238
0x11b188e gt_ggc_mx_cgraph_edge(void*)
        /build/gcc-11-7yDrbQ/gcc-11-11-20210306/build/gcc/gtype-desc.c:1403
0x11b15e1 gt_ggc_mx_symtab_node(void*)
        /build/gcc-11-7yDrbQ/gcc-11-11-20210306/build/gcc/gtype-desc.c:1349
0x11a903a gt_ggc_mx_lang_tree_node(void*)
        ./gtype-lto.h:284
0x11a904e gt_ggc_mx_lang_tree_node(void*)
        ./gtype-lto.h:280
0x11a9cde gt_ggc_mx_rtx_def(void*)
        /build/gcc-11-7yDrbQ/gcc-11-11-20210306/build/gcc/gtype-desc.c:722
0x11b435e void gt_ggc_mx<dw_attr_struct>(vec<dw_attr_struct, va_gc, vl_embed>*)
        ../../src/gcc/vec.h:1353
0x11b435e gt_ggc_mx_vec_dw_attr_node_va_gc_(void*)
        ./gt-dwarf2out.h:275
0x11b435e gt_ggc_mx_die_struct(void*)
        ./gt-dwarf2out.h:45
0x11b4433 gt_ggc_mx_die_struct(void*)
        ./gt-dwarf2out.h:27
0x11b4433 gt_ggc_mx_die_struct(void*)
        ./gt-dwarf2out.h:47
0x11b4433 gt_ggc_mx_die_struct(void*)
        ./gt-dwarf2out.h:27
0x11b4433 gt_ggc_mx_die_struct(void*)
        ./gt-dwarf2out.h:47
0x11b4433 gt_ggc_mx_die_struct(void*)
        ./gt-dwarf2out.h:27
0x11b4433 gt_ggc_mx_die_struct(void*)
        ./gt-dwarf2out.h:47
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.

[Bug lto/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry

[doko at debian dot org]

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

--- Comment #1 from Matthias Klose <doko at debian dot org> ---
object files at
https://people.debian.org/~doko/tmp/guymager-tst.tar.xz

[Bug lto/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Looks like a stack overflow while doing gc. To me die_struct GTY could use a
recursive note added to it. That is just by looking at the backtrace.

[Bug lto/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2021-03-08
             Status|UNCONFIRMED                 |WAITING
     Ever confirmed|0                           |1

--- Comment #3 from Martin Liška <marxin at gcc dot gnu.org> ---
Please reduce that, similarly to what I wrote to PR99448.

[Bug lto/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |11.0

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
I also wonder when the GC was triggered, thus whether it's another case of a
live stmt / SSA name where we now forcefully free the CFG.

[Bug lto/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry

[doko at debian dot org]

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

--- Comment #5 from Matthias Klose <doko at debian dot org> ---
I'm able to reduce the amount of object files involved in this ICE. But then
trying to rebuild the package with -save-temps makes the ICE disappear.

[Bug lto/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

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

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
More specifically, likely caused by g:ae99b315ba5b9e1ccc221b3c45de323cbc574400
which did

diff --git a/gcc/cfg.c b/gcc/cfg.c
index 529b6ed2105..e8bd1456c9f 100644
--- a/gcc/cfg.c
+++ b/gcc/cfg.c
@@ -102,8 +102,7 @@ free_block (basic_block bb)
    bb->succs = NULL;
    vec_free (bb->preds);
    bb->preds = NULL;
-   /* Do not free BB itself yet since we leak pointers to dead statements
-      that points to dead basic blocks.  */
+   ggc_free (bb);
 }

 /* Free the memory associated with the CFG in FN.  */

and the backtrace of the crash points at some RTX tree (if gtype-desc from
trunk still matches, it's likely SYMBOL_REF_DECL) refers to a GIMPLE stmt
via the callgraph edge ->call_stmt which refers to the CFG BB it is contained
in.

unfortunately it's not visible what pass/phase this segfault occurs in
(might be WPA function materialization or ltrans compilation).

That said, the ggc_free above looks like a bad idea until we can sort out
these issue.  So - should we simply revert the change again?

[Bug lto/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Matthias Klose from comment #5)
> I'm able to reduce the amount of object files involved in this ICE. But then
> trying to rebuild the package with -save-temps makes the ICE disappear.

I guess always-collect might ease triggering it (--enable-checking=yes,gcac).

[Bug lto/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #6)
> More specifically, likely caused by
> g:ae99b315ba5b9e1ccc221b3c45de323cbc574400 which did
> 
> diff --git a/gcc/cfg.c b/gcc/cfg.c
> index 529b6ed2105..e8bd1456c9f 100644
> --- a/gcc/cfg.c
> +++ b/gcc/cfg.c
> @@ -102,8 +102,7 @@ free_block (basic_block bb)
>     bb->succs = NULL;
>     vec_free (bb->preds);
>     bb->preds = NULL;
> -   /* Do not free BB itself yet since we leak pointers to dead statements
> -      that points to dead basic blocks.  */
> +   ggc_free (bb);
>  }
>  
>  /* Free the memory associated with the CFG in FN.  */
> 
> and the backtrace of the crash points at some RTX tree (if gtype-desc from
> trunk still matches, it's likely SYMBOL_REF_DECL) refers to a GIMPLE stmt
> via the callgraph edge ->call_stmt which refers to the CFG BB it is
> contained in.
> 
> unfortunately it's not visible what pass/phase this segfault occurs in
> (might be WPA function materialization or ltrans compilation).
> 
> That said, the ggc_free above looks like a bad idea until we can sort out
> these issue.  So - should we simply revert the change again?

Note we can't leave cgraph & edge reclaim to GC when we free a function
and at the same time forcefully ggc_free things pointed to (but ultimatively
dead).  That's in principle true for the gimple stmts themselves as well.

It looks like release_function_body simply leaves stmts dangling, it doesn't
remove them from blocks (clearing ->bb).  We've not seen ICEs from that
for unknown reasons.

I'm not sure it's worth all the trouble?

[Bug lto/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
For the ICE in this bug it might be enough to, in cgraph_node::release_body,
walk callees and zap ->call_stmt on the cgraph edges.  But the more general
issue remains - GC will still try to collect the now unreferenced stmts and
follow the link to the ggc_free()ed basic-block.

[Bug lto/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
So like this.

diff --git a/gcc/cgraph.c b/gcc/cgraph.c
index 80140757d16..447d9a920f7 100644
--- a/gcc/cgraph.c
+++ b/gcc/cgraph.c
@@ -1854,6 +1854,9 @@ cgraph_node::release_body (bool keep_arguments)
      needed to emit debug info later.  */
   if (!used_as_abstract_origin && DECL_INITIAL (decl))
     DECL_INITIAL (decl) = error_mark_node;
+  /* Zap references to call stmts of our body.  */
+  for (cgraph_edge *e = callees; e; e = e->next_callee)
+    e->call_stmt = NULL;
   release_function_body (decl);
   if (lto_file_data)
     {

[Bug lto/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry

[hubicka at ucw dot cz]

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

--- Comment #11 from Jan Hubicka <hubicka at ucw dot cz> ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
> 
> --- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
> So like this.
> 
> diff --git a/gcc/cgraph.c b/gcc/cgraph.c
> index 80140757d16..447d9a920f7 100644
> --- a/gcc/cgraph.c
> +++ b/gcc/cgraph.c
> @@ -1854,6 +1854,9 @@ cgraph_node::release_body (bool keep_arguments)
>       needed to emit debug info later.  */
>    if (!used_as_abstract_origin && DECL_INITIAL (decl))
>      DECL_INITIAL (decl) = error_mark_node;
> +  /* Zap references to call stmts of our body.  */
> +  for (cgraph_edge *e = callees; e; e = e->next_callee)
> +    e->call_stmt = NULL;

Looks good but will also need to warlk indirect calls.
However I wonder in what situations it makes sense to release body but
keep cgraph edges?

Honza
>    release_function_body (decl);
>    if (lto_file_data)
>      {
> 
> -- 
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug lto/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry

[marxin at gcc dot gnu.org]

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

--- Comment #12 from Martin Liška <marxin at gcc dot gnu.org> ---
@doko: Can you please reduce objects and then .ii files needed to reproduce the
issue?

[Bug lto/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry

[doko at gcc dot gnu.org]

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

Matthias Klose <doko at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |WORKSFORME
                 CC|                            |doko at gcc dot gnu.org

--- Comment #13 from Matthias Klose <doko at gcc dot gnu.org> ---
rechecked with trunk 20210321, and gcc-10 branch. I can't reproduce this
anymore.

[Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|WORKSFORME                  |---
           Assignee|unassigned at gcc dot gnu.org      |hubicka at gcc dot gnu.org
           Keywords|                            |lto
          Component|lto                         |ipa
           Priority|P3                          |P1
             Status|RESOLVED                    |ASSIGNED

--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Matthias Klose from comment #13)
> rechecked with trunk 20210321, and gcc-10 branch. I can't reproduce this
> anymore.

That's just bad luck.  The issue needs resolving and analysis has identified
two things we can improve (cgraph edges & SSA name def stmts).

[Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry

[hubicka at gcc dot gnu.org]

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

--- Comment #15 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
I also tried to reproduce this locally w/o luck.

Looking at the backtrace in detail, there is no DEF_STMT involved.  It walks
from dwarf dies, to RTL constant pool address that points to tree which has
abstract origin that points to symtab node which points to callgraph edge which
points to dead basic block.

The pointer from cgraph node to edge that should be removed.
I can add code to clear pointers SSA_NAME->def_stmt bit there is no def stmt in
the backtrace, so it would not help here.
W/o reproducer it seem hard to tell what is/was real cause of this issue...

Honza

[Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry

[hubicka at gcc dot gnu.org]

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

--- Comment #16 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
I was trying to reproduce some kind of ICE for a while, trying to also rebuild
with ggc forced on every ggc_collect call, but no luck.

I wonder if you happen to know specific gcc regression that was failing and if
it was patched or not...

[Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry

[rguenth at gcc dot gnu.org]

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

--- Comment #17 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jan Hubicka from comment #15)
> I also tried to reproduce this locally w/o luck.
> 
> Looking at the backtrace in detail, there is no DEF_STMT involved.  It walks
> from dwarf dies, to RTL constant pool address that points to tree which has
> abstract origin that points to symtab node which points to callgraph edge
> which points to dead basic block.
> 
> The pointer from cgraph node to edge that should be removed.
> I can add code to clear pointers SSA_NAME->def_stmt bit there is no def stmt
> in the backtrace, so it would not help here.

We're already doing this it seems:

void
fini_ssanames (struct function *fn)
{
  unsigned i;
  tree name;
  /* Some SSA names leak into global tree data structures so we can't simply
     ggc_free them.  But make sure to clear references to stmts since we now
     ggc_free the CFG itself.  */
  FOR_EACH_VEC_SAFE_ELT (SSANAMES (fn), i, name)
    if (name)
      SSA_NAME_DEF_STMT (name) = NULL;

> W/o reproducer it seem hard to tell what is/was real cause of this issue...

So the backtrace points at

              gt_ggc_m_11symtab_node
((*x).generic.function_decl.common.common.symtab_node);

from LTO 'tree' walk.  To me it's still obvious - we walk a cgraph edge
call_stmt and from there to gimple_bb which was freed.

Looking around the only place (we don't know whether this was WPA or LTRANS)
we'd have a cgraph with edges is during clone materialization which pointed
me at cgraph_node::release_body which frees the body but fails to eventually
zap ->call_stmt references.

Matthias reported this for "trunk 20210306" which I assume is a snapshot
tarball configured the Debian way.

> Honza

[Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry

[hubicka at gcc dot gnu.org]

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

--- Comment #18 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
> Looking around the only place (we don't know whether this was WPA or LTRANS)
> we'd have a cgraph with edges is during clone materialization which pointed
> me at cgraph_node::release_body which frees the body but fails to eventually
> zap ->call_stmt references

This I agree with, but during our last discussion I went through all
release_body calls and found none which would match this scenario - they are
all on paths where we zap cgraph edges to (it is only makes sense to exist in
this case, since we are supposed to keep cgrpah edges in sync with actual body
and after feeing the body this would leave cgaph in inconsistent stage).

I will try to move tree to 20210306 and see if that helps.

I can simply add cgraph edge removal to release_body to make code bit more
robust - while most uses erases edges earlier, it is almost free to check the
pointer for being NULL twice.  Still it is weird that the bug does not
reproduce with allways collect.

[Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry

[hubicka at gcc dot gnu.org]

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

--- Comment #19 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Created attachment 50485
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50485&action=edit
small refactoring

this patch moves the removal to release_body and removes the calls on those
paths where removal is done just after call to it (as opposed to being done
earlier or via reset cal).

But still there is no code path where it should make difference. Pehraps the
assert will catch something interesting. Tests are running.

[Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry

[hubicka at gcc dot gnu.org]

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

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |WAITING

--- Comment #20 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
I re-tried with g:0ad6a2e2f0c667f9916cfcdb81f41f6055f1d0b3
and it builds all fine even with --param ggc-min-expand=0 --param
ggc-min-heapsize=0. It seems that --enable-checking=gcac is now noop.

@doko: perhaps using --param ggc-min-expand=0 --param ggc-min-heapsize=0 on
your setup may trigger the problem again.  There is some chance that i.e. the
qt headers are the cause, but I am tempted to close the bug as WORKSFORME after
committing the refactoring patch.

[Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry

[doko at debian dot org]

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

--- Comment #21 from Matthias Klose <doko at debian dot org> ---
building with trunk 20210330 using these parameters didn't succeed:

make[1]: Entering directory '/packages/tmp/guymager-0.8.12'
g++ -c -pipe -g -O2 -ffile-prefix-map=/packages/tmp/guymager-0.8.12=.
-flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat
-Werror=format-security --param ggc-min-expand=0 ggc-min-heapsize=0
-fmessage-length=0 -fno-strict-aliasing -flto -g
-ffile-prefix-map=/packages/tmp/guymager-0.8.12=. -flto=auto -ffat-lto-objects
-fstack-protector-strong -Wformat -Werror=format-security --param
ggc-min-expand=0 --param ggc-min-heapsize=0 -Wdate-time -D_FORTIFY_SOURCE=2 -O3
-ggdb -std=gnu++1y -Wall -Wextra -D_REENTRANT -fPIC
-DSPLASH_DIR='"/usr/share/guymager"' -DLANGUAGE_DIR='"/usr/share/guymager"'
-DLANGUAGE_DIR_QT='"/usr/share/qt5/translations"' -DQT_NO_DEBUG
-DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_DBUS_LIB -DQT_CORE_LIB -I.
-I/usr/include/libguytools2 -I/usr/include/x86_64-linux-gnu/qt5
-I/usr/include/x86_64-linux-gnu/qt5/QtWidgets
-I/usr/include/x86_64-linux-gnu/qt5/QtGui
-I/usr/include/x86_64-linux-gnu/qt5/QtDBus
-I/usr/include/x86_64-linux-gnu/qt5/QtCore -Imoc
-I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -o aaff.o aaff.cpp
g++: warning: ggc-min-heapsize=0: linker input file unused because linking not
done
g++: error: ggc-min-heapsize=0: linker input file not found: No such file or
directory
make[1]: *** [Makefile:897: aaff.o] Error 1

[Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry

[doko at gcc dot gnu.org]

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

Matthias Klose <doko at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW

[Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry

[doko at gcc dot gnu.org]

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

--- Comment #22 from Matthias Klose <doko at gcc dot gnu.org> ---
this is a compiler configured with --enable-default--pie

[Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry

[hubicka at ucw dot cz]

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

--- Comment #23 from Jan Hubicka <hubicka at ucw dot cz> ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
> 
> --- Comment #21 from Matthias Klose <doko at debian dot org> ---
> building with trunk 20210330 using these parameters didn't succeed:
> 
> make[1]: Entering directory '/packages/tmp/guymager-0.8.12'
> g++ -c -pipe -g -O2 -ffile-prefix-map=/packages/tmp/guymager-0.8.12=.
> -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat
> -Werror=format-security --param ggc-min-expand=0 ggc-min-heapsize=0
                                                   ^^^ missing --param here
(which may be my mistake in earlier comment, sorry for htat)

Honza

[Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry

[cvs-commit at gcc dot gnu.org]

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

--- Comment #24 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jan Hubicka <hubicka@gcc.gnu.org>:

https://gcc.gnu.org/g:d7145b4bb6c8729a1e782373cb6256c06ed60465

commit r11-7926-gd7145b4bb6c8729a1e782373cb6256c06ed60465
Author: Jan Hubicka <jh@suse.cz>
Date:   Wed Mar 31 11:35:29 2021 +0200

    Small refactoring of cgraph_node::release_body

            PR lto/99447
            * cgraph.c (cgraph_node::release_body): Remove all callers and
            references.
            * cgraphclones.c (cgraph_node::materialize_clone): Do not do it
here.
            * cgraphunit.c (cgraph_node::expand): And here.

[Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry

[hubicka at ucw dot cz]

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

--- Comment #25 from Jan Hubicka <hubicka at ucw dot cz> ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
> 
> --- Comment #23 from Jan Hubicka <hubicka at ucw dot cz> ---
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
> > 
> > --- Comment #21 from Matthias Klose <doko at debian dot org> ---
> > building with trunk 20210330 using these parameters didn't succeed:
> > 
> > make[1]: Entering directory '/packages/tmp/guymager-0.8.12'
> > g++ -c -pipe -g -O2 -ffile-prefix-map=/packages/tmp/guymager-0.8.12=.
> > -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat
                ^^^ this is interesting differnce, I will give it a try.
                It did not occured to me you are using fat lto objects
                (which is not very good idea in general since
                nm/ranlib/ar gets confused by it)
Honza
> > -Werror=format-security --param ggc-min-expand=0 ggc-min-heapsize=0
>                                                    ^^^ missing --param here
> (which may be my mistake in earlier comment, sorry for htat)
> 
> Honza
> 
> -- 
> You are receiving this mail because:
> You are the assignee for the bug.
> You are on the CC list for the bug.

[Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry

[cvs-commit at gcc dot gnu.org]

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

--- Comment #26 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jan Hubicka <hubicka@gcc.gnu.org>:

https://gcc.gnu.org/g:23ce9945d5efa77c96161443f68e03664705ada3

commit r11-7933-g23ce9945d5efa77c96161443f68e03664705ada3
Author: Jan Hubicka <jh@suse.cz>
Date:   Wed Mar 31 20:10:31 2021 +0200

    Fix overvactive check in cgraph_node::release_body

    gcc/ChangeLog:

            PR lto/99447
            * cgraph.c (cgraph_node::release_body): Fix overactive check.

[Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry

[hubicka at gcc dot gnu.org]

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

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING

--- Comment #27 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Even with pie and fat LTO the compilation works well. In addition I committed
patch that should make it clear that we to not stale pointers.

Without a reproducer I am not sure what we can do more, so perhaps we can
resolve it as WORKSFORME.

[Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry

[doko at debian dot org]

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

Matthias Klose <doko at debian dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |WORKSFORME
             Status|WAITING                     |RESOLVED

--- Comment #28 from Matthias Klose <doko at debian dot org> ---
also retried with trunk 20210331, and the two extra --param settings. Can't
reproduce it anymore.