This is the mail archive of the 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] libstdc++/12854

Benjamin Kosnik <> 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

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