Bug 83764 - internal compiler error: in gimple_get_virt_method_for_vtable
Summary: internal compiler error: in gimple_get_virt_method_for_vtable
Status: RESOLVED DUPLICATE of bug 81702
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 7.2.1
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-01-10 07:15 UTC by Leslie Zhai
Modified: 2018-01-10 09:53 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Leslie Zhai 2018-01-10 07:15:53 UTC
Hi GCC developers,

When I use Linaro GCC 7.2-2017.11 arm-linux-gnueabihf cross-compile toolchain[1] to build L4Re and L4Linux[2] 

Toolchain thrown such error: /data/project/xiangzhai/l4re/l4/pkg/io/io/server/src/virt/vmsi.cc:28:1: internal compiler error: in gimple_get_virt_method_for_vtable, at gimple-fold.c:6467
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.


l4re/l4/pkg/io/io/server/src/virt/vmsi.cc:28 define a static variable in an anonymous namespace[3]

26 namespace {                                                                     
27   static Vi::Resource_factory_t<Vi::Msi_resource, Hw::Msi_resource> __vmsifactory;
28 }


Linaro gcc-7.2.1/gcc/gimple-fold.c:6467 call gcc_assert[4]

6460   /* The virtual tables should always be born with constructors                 
6461      and we always should assume that they are avaialble for                    
6462      folding.  At the moment we do not stream them in all cases,                
6463      but it should never happen that ctor seem unreachable.  */                 
6464   gcc_assert (init);                                                            
6465   if (init == error_mark_node)                                                  
6466     {                                                                           
6467       gcc_assert (in_lto_p);                                                    
6468       /* Pass down that we lost track of the target.  */                        
6469       if (can_refer)                                                            
6470     *can_refer = false;                                                         
6471       return NULL_TREE;                                                         
6472     }

I have no idea why `in_lto_p` is NULL?
Please give me some suggestion, thanks a lot!

[1] https://releases.linaro.org/components/toolchain/binaries/latest/arm-linux-gnueabihf/gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabihf.tar.xz
[2] http://os.inf.tu-dresden.de/pipermail/l4-hackers/2018/008189.html
[3] https://svn.l4re.org/repos/oc/l4re/trunk/l4/pkg/io/io/server/src/virt/vmsi.cc
[4] https://releases.linaro.org/components/toolchain/gcc-linaro/latest/gcc-linaro-7.2-2017.11.tar.xz

Regards,
Leslie Zhai
Comment 1 Leslie Zhai 2018-01-10 07:40:10 UTC
Typo:
- I have no idea why `in_lto_p` is NULL?
+ I have no idea why `in_lto_p` is false?
Comment 2 Leslie Zhai 2018-01-10 07:49:35 UTC
And GCC 8.x workaround just remove the assert:

6751   /* The virtual tables should always be born with constructors                 
6752      and we always should assume that they are avaialble for                    
6753      folding.  At the moment we do not stream them in all cases,                
6754      but it should never happen that ctor seem unreachable.  */                 
6755   gcc_assert (init);                                                            
6756   if (init == error_mark_node)                                                  
6757     {                                                                           
6758       /* Pass down that we lost track of the target.  */                        
6759       if (can_refer)                                                            
6760     *can_refer = false;                                                         
6761       return NULL_TREE;                                                         
6762     }
Comment 3 Adam Lackorzynski 2018-01-10 09:51:57 UTC
This is a duplicate of #81702, which has already been fixed.
Comment 4 Richard Biener 2018-01-10 09:53:37 UTC
dup.

*** This bug has been marked as a duplicate of bug 81702 ***