Wdeprecated-copy on system type
#include
#include
#include
using srange = boost::sub_range;
void func(srange) // by value
{}
int main()
{
std::string kitty{"meow"};
srange hello{kitty};
srange const& helref = hello;
func(hello);
func(helref); // line 17
return 0;
}
$ g++ -v
gcc version 9.0.0 20180626 (experimental) (GCC)
$ g++ -Wall -pedantic -Wextra -Werror -save-temps subra.cpp
subra.cpp: In function ‘int main()’:
subra.cpp:17:13: error: implicitly-declared ‘constexpr
boost::sub_range
>::sub_range(const boost::sub_range >&)’ is deprecated
[-Werror=deprecated-copy]
func(helref);
^
In file included from subra.cpp:1:
/usr/include/boost/range/sub_range.hpp:259:20: note: because
‘boost::sub_range >’ has
user-provided ‘boost::sub_range&
boost::sub_range::operator=(const
boost::sub_range&) [with ForwardRange = const
std::__cxx11::basic_string]’
sub_range& operator=( const sub_range& r )
^~~~
subra.cpp:7:6: note: initializing argument 1 of ‘void func(srange)’
void func(srange) // by value
^~~~
I have two questions:
1. Why is a warning emitted only for the const srange?
2. Shouldn't boost be exempt from this warning, given that it's
included from a system directory (/usr/include) ?
Shouldn't the "implicitly declared copy constructor" error be located
at the class definition (boost header), rather than where it's being
called (the call which does pass-by-value) ?
Boost is version 1.62.0.1 packaged by Ubuntu 17.10, so I can't change that.
Csaba
Please CC me, I'm not subscribed to the list.
--
You can get very substantial performance improvements
by not doing the right thing. - Scott Meyers, An Effective C++11/14 Sampler
So if you're looking for a completely portable, 100% standards-conformat way
to get the wrong information: this is what you want. - Scott Meyers (C++TDaWYK)
Re: Wdeprecated-copy on system type
On Wed, Jun 27, 2018 at 1:28 PM, Jonathan Wakely wrote:
> Your mail is off-topic on this list, it would be appropriate on the
> gcc-help list, or in Bugzilla if you want to report a bug.
>
>
> On Wed, 27 Jun 2018 at 11:27, Csaba Raduly wrote:
(snip)
>> 1. Why is a warning emitted only for the const srange?
>
> Because line 16 doesn't use the sub_range copy constructor, it calls
> this instead:
>
> template< class ForwardRange2 >
> sub_range(
> ForwardRange2& r,
> BOOST_DEDUCED_TYPENAME ::boost::enable_if<
> is_compatible_range
> >::type* = 0
> )
> : base(impl::adl_begin(r), impl::adl_end(r))
> {
> }
>
> This might be a Boost bug, albeit a harmless one. IMHO the template
> constructor should be constrained so it isn't used for copying
> non-const lvalues.
So the fact that there's no warning for the non-const version is in
fact a bug in Boost, right?
(It's still like that in latest, not yet released Boost 1.68).
This sounds like a "greedy template" you spoke about at ACCUcon 2018.
>
>
>> 2. Shouldn't boost be exempt from this warning, given that it's
>> included from a system directory (/usr/include) ?
>
> Yes, it probably should, but see below.
>
>> Shouldn't the "implicitly declared copy constructor" error be located
>> at the class definition (boost header), rather than where it's being
>> called (the call which does pass-by-value) ?
>
> The warning is only issued at the point where the implicit definition
> is needed, to avoid issuing warnings when the object is never copied.
> It's needed at the call site in your code, not in the system header
> (well, it might also be needed in the boost headers, but those
> warnings are probably suppressed).
Of course the warning should only be emitted when such a
constructor/assignment is used.
Still, in my naive opinion, such a constructor is declared
(implicitly) in the class (sub_range).
The message at the point of use should be something similar to the
"instantiated from" message when there's an error inside a template.
Something like:
/usr/include/boost/range/sub_range.hpp:???: implicitly-declared ‘constexpr
boost::sub_range>::sub_range(const
boost::sub_range >&)’ is
deprecated
[-Werror=deprecated-copy]
/usr/include/boost/range/sub_range.hpp:259:20: note: because REASONS
subra.cpp:7:6: note: used when initializing argument 1 of ‘void func(srange)’
>
> But I agree that if the class is defined in a system header you can't
> change the code, so the warning is not very helpful. Please report a
> bug, https://gcc.gnu.org/bugs/
Csaba
--
You can get very substantial performance improvements
by not doing the right thing. - Scott Meyers, An Effective C++11/14 Sampler
So if you're looking for a completely portable, 100% standards-conformat way
to get the wrong information: this is what you want. - Scott Meyers (C++TDaWYK)
GCC bootstrap mismatch on OS X 10.4
Hi all, I'm trying to build GCC (r170071) on powerpc-apple-darwin8.11.0 (a G4 Mac Mini with OS X 10.4.11). I built and installed gmp-5.0.1, mpc-0.8.2 and mpfr-3.0.0, then ran ../gcc/configure --enable-languages=c,c++ make bootstrap This failed with: libtool: link: /Users/useruser/GCC/build/./gcc/xgcc -B/Users/useruser/GCC/build/./gcc/ -B/usr/local/powerpc-apple-darwin8.11.0/bin/ -B/usr/local/powerpc-apple-darwin8.11.0/lib/ -isystem /usr/local/powerpc-apple-darwin8.11.0/include -isystem /usr/local/powerpc-apple-darwin8.11.0/sys-include -m64 -dynamiclib -Wl,-fl libtool: link: dsymutil .libs/libgomp.1.dylib || : warning: no debug map in executable (-arch ppc64) libtool: link: (cd ".libs" && rm -f "libgomp.dylib" && ln -s "libgomp.1.dylib" "libgomp.dylib") libtool: link: ar rc .libs/libgomp.a alloc.o barrier.o critical.o env.o error.o iter.o iter_ull.o loop.o loop_ull.o ordered.o parallel.o sections.o single.o task.o team.o work.o lock.o mutex.o proc.o sem.o bar.o ptrlock.o time.o fortran.o affinity.o libtool: link: ranlib -c .libs/libgomp.a libtool: link: ( cd ".libs" && rm -f "libgomp.la" && ln -s "../libgomp.la" "libgomp.la" ) true DO=all multi-do # make make "DESTDIR=" "RPATH_ENVVAR=DYLD_LIBRARY_PATH" "TARGET_SUBDIR=powerpc-apple-darwin8.11.0" "bindir=/usr/local/bin" "datadir=/usr/local/share" "exec_prefix=/usr/local" "includedir=/usr/local/include" "datarootdir=/usr/local/share" "docdir=/usr/local/share/doc/" "infodir=/usr/local/share/info" "pdfdir=/usr/local/sha rm -f stage_current Comparing stages 2 and 3 warning: gcc/cc1-checksum.o differs warning: gcc/cc1plus-checksum.o differs Bootstrap comparison failure! gcc/cp/typeck.o differs gcc/haifa-sched.o differs gcc/real.o differs gcc/tree-vectorizer.o differs make[2]: *** [compare] Error 1 make[1]: *** [stage3-bubble] Error 2 make: *** [bootstrap] Error 2 real579m36.885s - overnight delivery :) user271m44.136s sys 26m22.824s Any idea what could be the problem and how to fix it? Should I just run a simple "make"? Csaba Please CC me because I'm not subscribed to the mailing list. Thanks. -- GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++ Life is complex, with real and imaginary parts. "Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds "People disagree with me. I just ignore them." -- Linus Torvalds
Re: GCC bootstrap mismatch on OS X 10.4
On Mon, Feb 14, 2011 at 7:57 PM, David Fang wrote: > >> >> I suspect his problems will be solved by adding --with-dwarf2 to the >> configure options. We don't seem to have a specific PR for this but I > > This PR seems to match: :) > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45248 > One user has reported that --with-dwarf2 was enough to fix bootstrap. Thank you Jack Howarth and David Fang. Adding --with-dwarf2 did indeed fix the bootstrap. Csaba -- GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++ Life is complex, with real and imaginary parts. "Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds "People disagree with me. I just ignore them." -- Linus Torvalds
