Re: [v3] libstdc++/12854

[llewelly at xmission dot com]

Benjamin Kosnik <bkoz@redhat.com> writes:

> >-Weffec++ is awful.  
> 
> -Weffc++ is useful. It's useful for other people, developing with g++,
> who use a more object-orientated style. Remember, C++ is supposed to be
> multi-paradigm....
> 
> It's even useful for libstdc++ maintainers. Had we been able to use if
> for 3.2, we would have found the missing virtual in the io hierarchy.

Why doesn't

#pragma GCC system_header

address this issue?

> 
> Look, I'm not saying that it's perfect (I wish it had finer
> granularity), or even that all the warnings are appropriate for
> libstdc++ (they are not). However, I think that getting this working, or
> closer to working, is something that should be pursued.
> 
> >There is at least one case of the changes that makes me very uneasy
> >because it hurts performance for no perceived benefit: The change to
> >__normal_iterator. 
> >
> >Declaring copy-constructor for __normal_iterator *is* a hurting
> >pessimization: 
> >The compiler is no longer going to treat it as "normal" C-struct and
> >pass it in register on plateforms (like PowerPC) it fits in a
> >register. Instead, return-values or function arguments of that type
> >would unconditionally be pushed on stack. That would be a step to make
> >our std::vector<T>::iterator more inefficient.  It hurts effort
> >like ADDRESSOF, designed precisely to remove the "abstraction penalty"
> >in putting simple data in structs like __normal_iterator.
> 
> I don't this is the case any more. 
> 
> I was under the impression that tree-ssa would scalarize even C++
> objects with 2-8 members. I've asked rth for clarification, but maybe
> jason would know this too.
> 
> >I think, only people who insist on -Weffec++ should pay for that
> >inefficiency.  Usually, they're concerned with a kind of codes where
> >everything is passed by reference.  We cannot not assume that our
> >implementation of STL is going to be used only in those specific
> >cases. 
> 
> Using -Weffc++ with libstdc++ without these patches is pretty much
> impossible.
> 
> If there is indeed an inefficiency, I'll strip that part out.
> 
> -benjamin