This is the mail archive of the gcc@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: gcc 4.2 more strict check for "function called through a non-compatible type"


Ian Lance Taylor writes:
 > Andrew Haley <aph@redhat.com> writes:
 > 
 > > Ian Lance Taylor writes:
 > >  > Yuri Pudgorodsky <yur@ptci.ru> writes:
 > >  > 
 > >  > > Compiling openssl-0.9.8b with gcc-4.2 snapshots, I found gcc 4.2
 > >  > > fortifies its check for function pointer conversion and generates
 > >  > > abort for PEM_read_X509_AUX() and similar wrappers.
 > >  > 
 > >  > Personally speaking, I agree with you that the compiler should issue a
 > >  > warning and then go ahead and compile the call.  I don't think we gain
 > >  > anything useful by compiling a runtime abort in this case.  The spirit
 > >  > of C is to let the user shoot themselves in the foot if they really
 > >  > want to.
 > >  > 
 > >  > Any contrary opinions?
 > > 
 > > The answer is here:
 > > 
 > > keating> Because if you *do* try to inline the call, you will get an ICE.
 > 
 > Yes, I agree that the ICE, if it still exists, would have to be fixed,
 > but to me that seems like a separate issue.

No, it isn't a separate issue.  We generate an abort rather than
ICEing.

 > > We could allow this iff someone fixes the ICE.  But we've
 > > provided a union cast to do the work if it's *really* needed;
 > > insn't that enough?
 > 
 > I don't think gcc should go down the path of inserting trap calls for
 > all undefined code.

That is a pretty outrageous strawman.  Nobody has suggested anything
like that.

 > That is reasonable if there is nothing else that can be done.  But
 > in this case there is something easy to do: compile the function
 > call as directed.

If indeed that's easy to do, yes.  But I'm pretty confident the abort
wouldn't have been inserted if that were the case.

If we're going to guarantee this stuff for the future, we'll have to
fix the bug, make sure it's doesn't destabilize the compiler and write
some test cases.  If we're really serious about it we should make it a
documented extension to C.  I'm not exactly opposed to that, but I do
wonder if it's the best use of people's time.  But this is free
software, and people choose their own priorities.

Andrew.


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