Bug 61135 - It seems to be not able to call virtual method of literal object in lambda expression
Summary: It seems to be not able to call virtual method of literal object in lambda ex...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 4.8.2
: P3 normal
Target Milestone: 8.0
Assignee: Not yet assigned to anyone
URL:
Keywords: accepts-invalid, c++-lambda
Depends on:
Blocks: lambdas
  Show dependency treegraph
 
Reported: 2014-05-10 04:52 UTC by MamoruOKAMOTO
Modified: 2022-03-11 00:32 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2014-05-10 00:00:00


Attachments
Test code using report (108 bytes, text/x-c++src)
2014-05-10 04:59 UTC, MamoruOKAMOTO
Details

Note You need to log in before you can comment on or make changes to this bug.
Description MamoruOKAMOTO 2014-05-10 04:52:23 UTC
Code is below:

  1 struct Base
  2 {
  3         virtual int b() const{return 1;};
  4 };
  5 
  6 struct Super:Base{};
  7 
  8 int main()
  9 {
 10         constexpr Super s;
 11         []{s.b();}();
 12 }

Compiler message is below:

buggy.cpp: In lambda function:
buggy.cpp:11:10: internal compiler error: in create_tmp_var, at gimplify.c:479
  []{a.b();}();


compile option is below:

g++ buggy.cpp -std=c++0x
or
g++ buggy.cpp -std=c++1y


%uname -a
Linux ZARATH-PC 3.13-1-amd64 #1 SMP Debian 3.13.10-1 (2014-04-15) x86_64 GNU/Linux


%g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.8.2-21' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.2 (Debian 4.8.2-21)
Comment 1 MamoruOKAMOTO 2014-05-10 04:54:06 UTC
g++-4.9.0 returned same message.
Comment 2 MamoruOKAMOTO 2014-05-10 04:59:58 UTC
Created attachment 32772 [details]
Test code using report
Comment 3 Daniel Krügler 2014-05-10 20:32:35 UTC
1) The problem also exists in gcc 4.10 trunk

2) As written, the presented code would be ill-formed anyway. The following transformed example presents valid code that produces the same ICE:

//-----------------------
struct Base
{
  virtual int b() const{return 1;};
};
   
struct Super:Base{};
 
int main()
{
  constexpr Super s = Super();
  [&]{s.b();}();
}
//-----------------------
Comment 4 Dinar Temirbulatov 2015-01-02 02:41:24 UTC
I could not reproduce the error, the output looks correct on trunk
Comment 5 Kai Tietz 2015-01-02 09:36:24 UTC
No, I can still reproduce the ICE in make_decl_rtl, at varasm.c:1297

#2  0x007ae6e2 in make_decl_rtl (decl=decl@entry=0xffe80160)
    at ../../gcc/gcc/varasm.c:1293
#3  0x007fa975 in expand_expr_real_1 (exp=0xffe80160, target=<optimized out>,
    tmode=DImode, modifier=EXPAND_CONST_ADDRESS, alt_rtl=0x0,
    inner_reference_p=false) at ../../gcc/gcc/expr.c:9563
#4  0x008065d5 in expand_expr (modifier=<optimized out>, mode=DImode,
    target=0xfff670a0, exp=0xffe80160) at ../../gcc/gcc/expr.h:299
#5  expand_expr_addr_expr_1 (exp=exp@entry=0xffe80160,
    target=target@entry=0xfff670a0, tmode=tmode@entry=DImode,
    modifier=modifier@entry=EXPAND_NORMAL, as=as@entry=0 '\000')
    at ../../gcc/gcc/expr.c:7704
#6  0x008067f5 in expand_expr_addr_expr_1 (exp=<optimized out>,
    target=target@entry=0xfff670a0, tmode=tmode@entry=DImode,
    modifier=modifier@entry=EXPAND_NORMAL, as=as@entry=0 '\000')
    at ../../gcc/gcc/expr.c:7756
#7  0x007f7222 in expand_expr_addr_expr (modifier=EXPAND_NORMAL,
    tmode=DImode, target=0xfff670a0, exp=0xffe3fd20)
    at ../../gcc/gcc/expr.c:7832
#8  expand_expr_real_1 (exp=0xffe3fd20, target=<optimized out>, tmode=DImode,
    modifier=EXPAND_NORMAL, alt_rtl=0xdeca688, inner_reference_p=false)
    at ../../gcc/gcc/expr.c:10706
#9  0x00807334 in store_expr_with_bounds (exp=exp@entry=0xffe3fd20,
    target=target@entry=0xfff670a0, call_param_p=call_param_p@entry=0,
    nontemporal=nontemporal@entry=false, btarget=btarget@entry=0xffe45ca8)
    at ../../gcc/gcc/expr.c:5368
#10 0x008101f6 in expand_assignment (to=to@entry=0xffe45ca8,
    from=from@entry=0xffe3fd20, nontemporal=false)
    at ../../gcc/gcc/expr.c:5137
#11 0x00ddab15 in expand_gimple_stmt_1 (stmt=0xffdd09f0)
    at ../../gcc/gcc/cfgexpand.c:3351
#12 expand_gimple_stmt (stmt=stmt@entry=0xffdd09f0)
    at ../../gcc/gcc/cfgexpand.c:3447
#13 0x00ddcb6c in expand_gimple_basic_block (bb=0xfff81080,
    disable_tail_calls=disable_tail_calls@entry=false)
    at ../../gcc/gcc/cfgexpand.c:5280
#14 0x00ddeaad in (anonymous namespace)::pass_expand::execute (
    this=0x80056948, fun=0xfff303a8) at ../../gcc/gcc/cfgexpand.c:5889
#15 0x0090d285 in execute_one_pass (pass=pass@entry=0x80056948)
    at ../../gcc/gcc/passes.c:2311
#16 0x0090d714 in execute_pass_list_1 (pass=0x80056948, pass@entry=0x80054848)
...
Comment 6 lc289dafd7ybme05se 2015-04-19 00:13:33 UTC
below also doesn't work
struct A
{
	int funcA(){return 0;}
};
template<class>
struct B:virtual public A{
	void funcB(){
		[a=this->funcA()]{};
	}
};

int main()
{
	B<A> b;
	b.funcB();
	return 0;
}

//g++ 4.9.2
g++ -std=c++14 hd.cpp
hd.cpp: In instantiation of ‘void B< <template-parameter-1-1> >::funcB() [with <template-parameter-1-1> = A]’:
hd.cpp:15:10:   required from here
hd.cpp:9:2: internal compiler error: in cp_genericize_r, at cp/cp-gimplify.c:1175
  }
  ^
Comment 7 lc289dafd7ybme05se 2015-04-19 00:30:06 UTC
仮想継承の時もエラーになるみたいですね。
Comment 8 Uroš Bizjak 2015-04-19 08:10:40 UTC
(In reply to lc289dafd7ybme05se from comment #7)
> 仮想継承の時もエラーになるみたいですね。

To save some clicking, Google translate said:

"It seems to be an error even when the virtual inheritance."
Comment 9 lc289dafd7ybme05se 2015-04-19 08:48:59 UTC
right.
i don't know why, but template<class> is also needed, to invoke the error.
Comment 10 Paolo Carlini 2017-09-13 14:42:31 UTC
Since 5.2.0 we accept the snippet in Comment 3, since 6.1.0 the snippet in Comment 6, thus I'm going to add to the testsuite both anyway. However, we also accept the original snippet, thus I'm keeping the bug open as accepts-invalid.
Comment 11 paolo@gcc.gnu.org 2017-09-13 17:29:08 UTC
Author: paolo
Date: Wed Sep 13 17:28:37 2017
New Revision: 252571

URL: https://gcc.gnu.org/viewcvs?rev=252571&root=gcc&view=rev
Log:
2017-09-13  Paolo Carlini  <paolo.carlini@oracle.com>

	PR c++/61135
	* g++.dg/cpp0x/lambda/lambda-ice18.C: New.
	* g++.dg/cpp1y/lambda-ice2.C: Likewise.

Added:
    trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice18.C
    trunk/gcc/testsuite/g++.dg/cpp1y/lambda-ice2.C
Modified:
    trunk/gcc/testsuite/ChangeLog
Comment 12 paolo@gcc.gnu.org 2018-03-03 00:28:35 UTC
Author: paolo
Date: Sat Mar  3 00:28:03 2018
New Revision: 258165

URL: https://gcc.gnu.org/viewcvs?rev=258165&root=gcc&view=rev
Log:
2018-03-02  Paolo Carlini  <paolo.carlini@oracle.com>

	PR c++/61135
	* g++.dg/cpp0x/lambda/lambda-61135.C: New.

Added:
    trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-61135.C
Modified:
    trunk/gcc/testsuite/ChangeLog
Comment 13 Paolo Carlini 2018-03-03 00:29:19 UTC
Completely fixed in trunk.