This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [C++ RFC/Patch] PR 34938


Hi again,

On 08/23/2014 09:16 AM, Paolo Carlini wrote:
.. on the other hand, the below is a case which my patchlet, which simply tracks pointers, does *not* handle correctly:

struct B { };
template <class T> struct A { };
A<void(B::*)()const>*p = 42;

should be fixable by complicating a bit the tracking, telling apart member pointers.
Thus I finished testing the below. I separated to a new pr34938-2.C all the cases which 4.9 is already getting right and on which we don't want to regress.

As you can see, in order to handle correctly snippets like the above in pr34938-2.C, I added to the pointer check a check TREE_CODE (t) == FUNCTION_TYPE, close to the original idea... For a while that made me a little nervous because I was afraid that we would not print the attribute for member function pointers when we should, but in fact, as we ignore it for typedefs of such types (as I reported a couple of messages ago), we also appear to drop to the floor when no typedefs are involved, thus, eg we simply accept:

struct A { template<int> void foo(); };

template<void (A::*)() __attribute((noreturn))> void bar();

fptr f1 = bar< &A::foo<0> >;

and if we butcher it a little bit to force an error message (eg, we change A::foo to be const) there is no trace of the attribute in the error message anyway. Thus I *think* that given our current status elsewhere at least, we are fine.

Thanks,
Paolo.

////////////////////////

Attachment: patch_34938_3
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]