Bug 14230 - [3.3 Regression] ICE in cp_expr_size
Summary: [3.3 Regression] ICE in cp_expr_size
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 3.4.0
: P2 critical
Target Milestone: 3.3.4
Assignee: Not yet assigned to anyone
URL:
Keywords: rejects-valid
: 14464 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-02-21 00:16 UTC by Jakub Jelinek
Modified: 2004-10-07 03:31 UTC (History)
3 users (show)

See Also:
Host: x86_64-redhat-linux
Target: x86_64-redhat-linux
Build: x86_64-redhat-linux
Known to work: 3.2.3 3.4.0 4.0.0
Known to fail: 3.3.3
Last reconfirmed: 2004-02-23 00:59:24


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jakub Jelinek 2004-02-21 00:16:20 UTC
struct A
{
  A ();
  A (const A&);
  A& operator= (const A&);
};

template<class T>
struct B
{
  struct C
  {
    T y;
    T f () { return y; }
  };

  T f () const
  {
    C c;
    return c.f ();
  }
};

struct D
{
  A a;
};

void foo (B<D> &x)
{
  const A& z = x.f().a;
}

causes ICE on all platforms I've tried, 3.3.3 and 3.4.
It doesn't cause ICE in 2.96-RH, so looks like regression.
Comment 1 Jakub Jelinek 2004-02-21 00:21:00 UTC
Actually, it doesn't ICE in 3.2.3 either, so definitely a regression.
Comment 2 Jakub Jelinek 2004-02-21 00:41:00 UTC
This is related to http://gcc.gnu.org/ml/gcc-patches/2002-08/msg00174.html
patch.
Comment 3 Giovanni Bajo 2004-02-23 00:59:24 UTC
Confirmed, and reduced thus:

------------------------------------------------
struct A {
  A ();
  A (const A&);
  A& operator= (const A&);
};

struct D {
  A a;
};

const A& z = D().a;
------------------------------------------------
pr14230.cc:11: internal compiler error: in cp_expr_size, at cp/cp-lang.c:345
Comment 4 Mark Mitchell 2004-03-01 20:37:47 UTC
Jason, this looks to be another problem with your exception-handling
optimization stuff.  Would you please take a look at that?
Comment 5 Jason Merrill 2004-03-01 21:50:10 UTC
Subject: Re:  [3.3/3.4/3.5 Regression] ICE in cp_expr_size

On 1 Mar 2004 20:37:48 -0000, "mmitchel at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> wrote:

> Jason, this looks to be another problem with your exception-handling
> optimization stuff.  Would you please take a look at that?

For the record, cp_expr_size is not related to the EH optimization code;
aborts in cp_expr_size indicate places where the compiler would otherwise
silently generate a bitwise copy of a class with a constructor.

But yes, I'm looking at this and the other bugs you mentioned.

Jason
Comment 6 Mark Mitchell 2004-03-01 22:04:29 UTC
Subject: Re:  [3.3/3.4/3.5 Regression] ICE in cp_expr_size

Jason Merrill wrote:

>On 1 Mar 2004 20:37:48 -0000, "mmitchel at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> wrote:
>
>  
>
>>Jason, this looks to be another problem with your exception-handling
>>optimization stuff.  Would you please take a look at that?
>>    
>>
>
>For the record, cp_expr_size is not related to the EH optimization code;
>aborts in cp_expr_size indicate places where the compiler would otherwise
>silently generate a bitwise copy of a class with a constructor.
>
>  
>
Yes -- but I thought that the root cause in this case was the 
exception-optimization code generating code that resulted in an extra 
copy.   Sorry if that was a bum steer!

>But yes, I'm looking at this and the other bugs you mentioned.
>
Thanks!

Comment 7 Jason Merrill 2004-03-02 21:05:44 UTC
Subject: Re:  [3.3/3.4/3.5 Regression] ICE in cp_expr_size

Actually, this seems to be a problem with Mark's fix for 11041; using an
INIT_EXPR to initialize a temporary variable from a non-lvalue only elides
the copy if the non-lvalue is a TARGET_EXPR.  In this case, it's a
COMPONENT_REF of a TARGET_EXPR, so the INIT_EXPR becomes a bitwise copy, so
cp_expr_size aborts.

Jason
Comment 8 Andrew Pinski 2004-03-06 23:38:21 UTC
*** Bug 14464 has been marked as a duplicate of this bug. ***
Comment 9 Jason Merrill 2004-03-08 20:55:08 UTC
I've reassigned this to Mark since I don't understand his reasoning for moving
away from cp_finish_decl, which I would expect to generate a copy constructor
call for this case, which would be one correct solution.  Another would be to
preserve the D temporary so that we can refer to the A subobject, though that
might not be desirable in cases where the subobject is only a small part of the
temporary.
Comment 10 GCC Commits 2004-03-09 10:07:40 UTC
Subject: Bug 14230

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-3_4-branch
Changes by:	mmitchel@gcc.gnu.org	2004-03-09 10:07:31

Modified files:
	gcc/cp         : ChangeLog call.c 
	gcc/testsuite  : ChangeLog 
Added files:
	gcc/testsuite/g++.dg/init: ref11.C 

Log message:
	PR c++/14230
	* call.c (initialize_reference): Handle initializers that are
	class-member access expressions applies to rvalues.
	
	PR c++/14230
	* g++.dg/init/ref11.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3892.2.74&r2=1.3892.2.75
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/call.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.452.2.9&r2=1.452.2.10
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3389.2.133&r2=1.3389.2.134
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/init/ref11.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.2.1

Comment 11 GCC Commits 2004-03-09 10:08:51 UTC
Subject: Bug 14230

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	mmitchel@gcc.gnu.org	2004-03-09 10:08:40

Modified files:
	gcc/cp         : ChangeLog call.c 
	gcc/testsuite  : ChangeLog 
Added files:
	gcc/testsuite/g++.dg/init: ref11.C 

Log message:
	PR c++/14230
	* call.c (initialize_reference): Handle initializers that are
	class-member access expressions applies to rvalues.
	
	PR c++/14230
	* g++.dg/init/ref11.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.3989&r2=1.3990
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/call.c.diff?cvsroot=gcc&r1=1.464&r2=1.465
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.3585&r2=1.3586
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/init/ref11.C.diff?cvsroot=gcc&r1=1.1&r2=1.2

Comment 12 Mark Mitchell 2004-03-09 10:10:25 UTC
Fixed in GCC 3.4 and GCC 3.5.
Comment 13 GCC Commits 2004-03-13 02:01:15 UTC
Subject: Bug 14230

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-3_3-branch
Changes by:	gdr@gcc.gnu.org	2004-03-13 02:00:59

Modified files:
	gcc/cp         : ChangeLog call.c 
Added files:
	gcc/testsuite/g++.dg/init: ref11.C 

Log message:
	Backport:
	2004-03-09  Mark Mitchell  <mark@codesourcery.com>
	PR c++/14230
	* call.c (initialize_reference): Handle initializers that are
	class-member access expressions applies to rvalues.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.3076.2.260&r2=1.3076.2.261
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/call.c.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.341.2.40&r2=1.341.2.41
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/init/ref11.C.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=NONE&r2=1.2.2.1

Comment 14 Gabriel Dos Reis 2004-03-13 02:01:53 UTC
http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01089.html
Comment 15 GCC Commits 2004-03-27 16:20:43 UTC
Subject: Bug 14230

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-3_3-rhl-branch
Changes by:	jakub@gcc.gnu.org	2004-03-27 16:20:38

Modified files:
	gcc/testsuite  : ChangeLog 
Added files:
	gcc/testsuite/g++.dg/init: ref11.C 

Log message:
	2004-03-09  Mark Mitchell  <mark@codesourcery.com>
	
	PR c++/14230
	* g++.dg/init/ref11.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_3-rhl-branch&r1=1.2261.2.170.2.51&r2=1.2261.2.170.2.52
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/init/ref11.C.diff?cvsroot=gcc&only_with_tag=gcc-3_3-rhl-branch&r1=NONE&r2=1.2.6.1