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: V3 patch causes EH failures in ILP32 mode


Gabriel Dos Reis wrote:

You Wrote



Well, I added these so that -Weffc++ could be used in CXXFLAGS while
building libstdc++. This was a longstanding issue w/ v3 that was an
annoyance to several C++ maintainers (myself included, naturally!).


Ugh. Do you really think this kind of change is worth it?


I haven't yet seen a reply to my concern that adding copy constructors and/or destructors may have changed the V3 ABI between 3.4.0 and 3.4.1. Has anybody on the V3 side done an audit to make sure that nothing was affected? If nobody has done this audit, then would one of the V3 people please do the audit ASAP?

I'd be very disappointed if the V3 ABI changed between 3.4.0 and 3.4.1.

This audit cannot be done by looking at exported symbols; you have to check all classes that are visible to users. A user might have a function taking a parameter of class type that is affected by this change. If the class now has a copy constructor or destructor and had neither before, then the ABI was broken. Is there someone who will check that, please?

Also, I've now verified that change to add "this != &r" test to "opterator=" in "__upcast_result" results in inferior code; the test is not optimized away by the compiler, but it turns out that the only user of "operator=" the test is true, so we execute the guarded code anyhow. I do not expect that in this particular case there will be any noticable performance degredation, but I think that the V3 maintainers should be aware that this style of change is going to cause the compiler to generate inferior code. If it's decided that these kinds of changes are useful, I would recommend that the test not be included. It cannot be a correctness issue if the code was OK before since the implicit version does not have the test, and it will almost never be a performance advantage; the compiler will eliminate the copies anyhow if it can show that the two sides are the same.

--
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com


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