Summary: | [4.0 Regression] ICE with pointer to member function initializer and cast to a different type | ||
---|---|---|---|
Product: | gcc | Reporter: | Donour Sizemore <donour> |
Component: | c++ | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | donour, fang, gcc-bugs |
Priority: | P1 | Keywords: | ice-on-valid-code |
Version: | 4.1.0 | ||
Target Milestone: | 4.1.2 | ||
Host: | Target: | ||
Build: | Known to work: | 3.3 3.4.0 4.1.2 4.2.0 4.3.0 | |
Known to fail: | 4.0.2 4.1.0 4.1.1 | Last reconfirmed: | 2006-06-24 02:03:16 |
Attachments: | demo of reported behavior |
Description
Donour Sizemore
2006-06-23 23:12:59 UTC
Created attachment 11736 [details]
demo of reported behavior
I cannot figure out if this is undefined code or not but it should not at least ICE. Subject: Re: ICE with pointer to member function initializer and cast to a different type pinskia at gcc dot gnu dot org wrote: > ------- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-24 02:03 ------- > I cannot figure out if this is undefined code or not but it should not at least > ICE. > > > That should be legal ISO c++. That type of constuct is used actually pretty common in specific types of applications (OS and embedded apps). thanks donour (In reply to comment #3) > Subject: Re: ICE with pointer to member function initializer > and cast to a different type > That should be legal ISO c++. That type of constuct is used actually > pretty common in specific types of applications (OS and embedded apps). What I mean is that the type of the arguments and return type don't match so if you use __Virtual__foo__Var1 without a cast back, the code would be undefined. This code is not valid ISO C++; there is no conversion from function pointers (including pointers to member functions) from one type to another. I don't know what I was thinking when I proclaimed this invalid code. It's clearly valid; the cast is a reinterpret_cast. Subject: Re: [4.0/4.1/4.2 Regression] ICE with pointer to
member function initializer and cast to a different type
mmitchel at gcc dot gnu dot org wrote:
> ------- Comment #6 from mmitchel at gcc dot gnu dot org 2006-08-03 07:36 -------
> I don't know what I was thinking when I proclaimed this invalid code. It's
> clearly valid; the cast is a reinterpret_cast.
>
>
Ok great. The issue is not really pressing with me anymore, as I've
rewritten the offending code to alleviate the problem. Although I'm sure
you want to get rid of all known ICE bugs.
donour
Subject: Bug 28148 Author: mmitchel Date: Fri Aug 4 04:58:36 2006 New Revision: 115919 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115919 Log: PR c++/28148 * varasm.c (output_constant): Give the front end another chance to expand constants, after stripping NOPs. PR c++/28148 * g++.dg/init/ptrmem3.C: New test. Added: trunk/gcc/testsuite/g++.dg/init/ptrmem3.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/varasm.c Subject: Bug 28148 Author: mmitchel Date: Fri Aug 4 05:00:03 2006 New Revision: 115920 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115920 Log: PR c++/28148 * varasm.c (output_constant): Give the front end another chance to expand constants, after stripping NOPs. PR c++/28148 * g++.dg/init/ptrmem3.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/init/ptrmem3.C Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/varasm.c Fixed in 4.1.2. Fixed in GCC-4.1.2. |