------- Comment #6 from bangerth at dealii dot org 2007-03-14 20:49 ------- (In reply to comment #5) > I know our code is wrong, but my point is that gcc34 generated correct code > and gcc4x is not.
No, it happened to produce code that happened to do what you thought it would. There is no way the compiler can know what you want if you cast the address of a function to a different type and then expect the compiler to figure out after the fact what it referred to. Just don't cast pointer types! > I disagree with marking this bug report as "resolved invalid" but would > accept a deferral because 2 workarounds exists and the code was bad anyways. > Still I'm expecting the compiler to reject bad code if it can't generate > code for it! What is the compiler supposed to do? You take the address of a function and cast it to a different pointer type. That's valid. You just mustn't use this pointer in any other way except casting it back to the original pointer type before you use it. You don't do that in this case, but at the point where the cast is missing, the compiler has no knowledge where the pointer it sees came from, so there's no way it can warn you here. (And the standard in fact recognizes this by saying that what you do invokes "undefined behavior" but that the compiler is not required to diagnose this.) There is really nothing a compiler can do in this situation. The fact that it worked before is by pure chance. Best Wolfgang -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30975
