[Bug c/40879] New: stdarg.h does not define va_copy when building for C89+POSIX
POSIX 2001 specifies that va_copy
(http://www.opengroup.org/onlinepubs/009695399/functions/va_copy.html) is
defined by stdarg.h. However, when compiling with -std=c89
-D_POSIX_C_SOURCE=200112L this does not happen. I've encountered this in 4.3.2,
but a quick peek in svn makes it look this this is current.
I'll attach the source and preprocessed output.
Command line:
gcc -std=c89 -D_POSIX_C_SOURCE=200112L -Wall -c no_va_copy.c -save-temps
no_va_copy.c: In function copy_va_list:
no_va_copy.c:8: warning: implicit declaration of function va_copy
gcc -v:
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.3.2-r3/work/gcc-4.3.2/configure --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.2
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.2
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.2/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.2/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--disable-fixed-point --enable-nls --without-included-gettext
--with-system-zlib --disable-checking --disable-werror --enable-secureplt
--enable-multilib --enable-libmudflap --disable-libssp --enable-libgomp
--disable-libgcj --enable-languages=c,c++,treelang,fortran --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.3.2-r3 p1.6,
pie-10.1.5'
Thread model: posix
gcc version 4.3.2 (Gentoo 4.3.2-r3 p1.6, pie-10.1.5)
--
Summary: stdarg.h does not define va_copy when building for
C89+POSIX
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bmerry at gmail dot com
GCC build triplet: x86_64-pc-linux-gnu
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40879
[Bug c/40880] New: stdarg.h does not define va_copy when building for C89+POSIX
POSIX 2001 specifies that va_copy
(http://www.opengroup.org/onlinepubs/009695399/functions/va_copy.html) is
defined by stdarg.h. However, when compiling with -std=c89
-D_POSIX_C_SOURCE=200112L this does not happen. I've encountered this in 4.3.2,
but a quick peek in svn makes it look this this is current.
I'll attach the source and preprocessed output.
Command line:
gcc -std=c89 -D_POSIX_C_SOURCE=200112L -Wall -c no_va_copy.c -save-temps
no_va_copy.c: In function copy_va_list:
no_va_copy.c:8: warning: implicit declaration of function va_copy
gcc -v:
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.3.2-r3/work/gcc-4.3.2/configure --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.2
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.2
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.2/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.2/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--disable-fixed-point --enable-nls --without-included-gettext
--with-system-zlib --disable-checking --disable-werror --enable-secureplt
--enable-multilib --enable-libmudflap --disable-libssp --enable-libgomp
--disable-libgcj --enable-languages=c,c++,treelang,fortran --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.3.2-r3 p1.6,
pie-10.1.5'
Thread model: posix
gcc version 4.3.2 (Gentoo 4.3.2-r3 p1.6, pie-10.1.5)
--
Summary: stdarg.h does not define va_copy when building for
C89+POSIX
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bmerry at gmail dot com
GCC build triplet: x86_64-pc-linux-gnu
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40880
[Bug c/40880] stdarg.h does not define va_copy when building for C89+POSIX
--- Comment #1 from bmerry at gmail dot com 2009-07-27 19:46 --- Created an attachment (id=18258) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18258&action=view) Source file illustrating the problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40880
[Bug c/40880] stdarg.h does not define va_copy when building for C89+POSIX
--- Comment #2 from bmerry at gmail dot com 2009-07-27 19:47 --- Created an attachment (id=18259) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18259&action=view) Preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40880
[Bug c/40879] stdarg.h does not define va_copy when building for C89+POSIX
--- Comment #1 from bmerry at gmail dot com 2009-07-27 19:48 --- System threw an HTTP error 500 but managed to create a bug, so now there are two copies. Rejecting this one, bug 40880 is the real one. -- bmerry at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40879
[Bug c/40880] stdarg.h does not define va_copy when building for C89+POSIX
--- Comment #5 from bmerry at gmail dot com 2009-07-28 07:28 --- Thanks, I wasn't aware of that. It's slightly annoying that the behaviour is different from glibc (I use -std=c89 so that the compiler keeps me honest, since I'm working on code that has to compile on compilers that still haven't gotten around to C99), but I can live with using __va_copy. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40880
[Bug c++/57728] New: Explicit template instantiation with defaulted method causes missing symbol
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57728 Bug ID: 57728 Summary: Explicit template instantiation with defaulted method causes missing symbol Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: bmerry at gmail dot com Created attachment 30378 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30378&action=edit Minimal test case I don't claim to fully understand all the intricies of C++11, but the following smells fishy to me. I am using a combination of features: 1. The = default syntax to restore implicit constructors/assignments that were otherwise hidden (e.g. default constructor when there are no user-defined constructors), in a templated class. 2. "extern template" in the header to suppress instantiation of a specific instance, with an explicit instantiation in one translation unit. In some cases (I assume depending on compiler eliding) this causes a link-time error for the defaulted constructor. I have attached a minimal test case. I don't know whether there is supposed to be a symbol or whether the compiler is supposed to inline the default implementation, but currently there is a mismatch. System information: Ubuntu 12.04 with gcc version 4.8.1 (Ubuntu 4.8.1-2ubuntu1~12.04) Output (there's a more detailed log in the attachment with -v -save-temps): g++-4.8 -std=c++11 -c defaulted.cpp g++-4.8 -std=c++11 -c impl.cpp g++-4.8 -std=c++11 -o defaulted defaulted.o impl.o defaulted.o: In function `main': defaulted.cpp:(.text+0x10): undefined reference to `A::A()' collect2: error: ld returned 1 exit status make: *** [defaulted] Error 1
[Bug c++/57728] Explicit template instantiation with defaulted method causes missing symbol
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57728 --- Comment #2 from Bruce Merry --- (In reply to Jonathan Wakely from comment #1) > The explicit instantiation declaration suppresses the definition of > A::A() in defaulted.o, but the explicit instantiation definition > doesn't cause that symbol to be emitted in impl.o, so when that constructor > is not inlined there is no definition. That's more or less what I figured was happening. Can you clarify whether you think this a GCC bug or just me misunderstanding the language? Thanks.
[Bug c++/58281] New: Problem with explicit constexpr template functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58281
Bug ID: 58281
Summary: Problem with explicit constexpr template functions
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bmerry at gmail dot com
Created attachment 30730
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30730&action=edit
Minimal broken test case
It seems that in some cases explicit instantiation of a function template fails
to actually instantiate anything. A minimal example (also attached) is
template constexpr bool f(T a)
{
return a == 3;
}
extern template bool f(int);
bool g(int x) { return f(x); }
template bool f(int);
int main() { return g(4); }
for which compilation gives
$ g++-4.8 -std=c++11 -o instantiate instantiate.cpp
/tmp/ccPWHA9d.o: In function `g(int)':
instantiate.cpp:(.text+0x11): undefined reference to `bool f(int)'
collect2: error: ld returned 1 exit status
Obviously in real usage the explicit instantiation declaration would be in a
header and the explicit instantiation definition would be in a .cpp file, but
it's all one translation unit either way.
Some experimentation shows that any of following will compile:
- moving function g to after the explicit instantiation definition
- removing the constexpr qualifier from f
- removing g and main entirely (nm shows the symbol for f in the resulting
.o file)
The only relevant constraints I found in a quick search of the C++11 [draft]
spec were in 14.7.2.11:
"If an entity is the subject of both an explicit instantiation declaration and
an explicit instantiation definition in the same translation unit, the
definition shall follow the declaration. An entity that is the subject of an
explicit instantiation declaration and that is also used in a way that would
otherwise cause an implicit instantiation (14.7.1) in the translation unit
shall be the subject of an explicit instantiation definition somewhere in the
program; otherwise the program is ill-formed, no diagnostic required."
which all seem to be satisfied by the example.
System information: Ubuntu 12.04 on x86_64, running with GCC 4.8.1:
Using built-in specs.
COLLECT_GCC=g++-4.8
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.8.1-2ubuntu1~12.04' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.1 (Ubuntu 4.8.1-2ubuntu1~12.04)
[Bug libstdc++/52764] New: Including after fails to define limit macros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52764 Bug #: 52764 Summary: Including after fails to define limit macros Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: bme...@gmail.com Created attachment 27027 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27027 Preprocessed source from g++ -v -save-temps -std=c++0x gcc-stdint.cpp Both and are implemented by defining __STDC_LIMIT_MACROS, including and then undefining the macro again. However, if has already been included (which may occur indirectly via some third-party C library header) then the limit macros do not get defined. I'm not 100% sure this is a bug because the C and C++ standards seem to contradict each other, but here's my reasoning: Both TR1 and C++11 are explicit that will define the limit macros, and C++11 also says "The macros defined by are provided unconditionally. In particular, the symbols __STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS (mentioned in footnotes 219, 220, and 222 in the C standard) play no role in C++." TR1 also says that "[] behaves as if it includes the header , and provides sufficient using declarations to declare in the global namespace all type names defined in the header ." I've run into this on GCC 4.6.1, but from a quick look at http://gcc.gnu.org/svn/gcc/trunk/libstdc++-v3/include/c_global/cstdint@185951 it looks like this hasn't changed. Command line: g++ -c -std=c++0x gcc-stdint.cpp Output: gcc-stdint.cpp:4:26: error: ‘UINT32_MAX’ was not declared in this scope Output of g++ -v: Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6.1/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.1-9ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3)
[Bug libstdc++/58962] New: Pretty printers use obsolete Python syntax
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58962 Bug ID: 58962 Summary: Pretty printers use obsolete Python syntax Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: bmerry at gmail dot com Created attachment 31135 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31135&action=edit Patch to update raise statements to modern Python syntax The pretty printers shipped with GCC 4.8.1 use the obsolete raise ExceptionClass, argument format for raising exceptions. Modern Python (not sure when it was introduced, but the Python 2.6 docs seems to support it so it has been around for a while) instead uses raise ExceptionClass(arguments...) and the old form is not supported in Python 3. The result is that when I try to load the pretty printers via .gdbinit in Ubuntu 13.10, I get this message: Traceback (most recent call last): File "", line 3, in File "/usr/share/gcc-4.8/python/libstdcxx/v6/printers.py", line 54 raise ValueError, "Cannot find type %s::%s" % (str(orig), name) ^ SyntaxError: invalid syntax /home/bruce/.gdbinit:7: Error in sourced command file: Error while executing Python code. I've attached a patch which changes the raise statements to use the new syntax. It's against the version shipped with Ubuntu 13.10 in libstdc++6-4.8-dbg; I haven't checked whether Ubuntu have added their own patches.
[Bug libstdc++/58962] Pretty printers use obsolete Python syntax
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58962 --- Comment #1 from Bruce Merry --- I've now realised that this is actually just the tip of the iceberg - I suspect that libstdc++'s pretty printers aren't Python 3 ready, while Ubuntu is shipping a gdb linked to libython 3.3. Feel free to close if this is as expected.
[Bug c++/59004] New: ICE generated by __func__
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59004
Bug ID: 59004
Summary: ICE generated by __func__
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bmerry at gmail dot com
Created attachment 31159
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31159&action=edit
Preprocessed source
This minimal example causes GCC to ICE:
template class A {};
template
class B {
public:
static const int y = (x != -1 ? 0 : 0);
template void g(const A &a) {
const char *x = __func__;
}
};
template void B<0>::g<0>(const A<0> &);
Error message when compiling with "g++ -c ice_func.cpp":
ice_func.cpp: In member function ‘void B::g(const A::y>&) [with int z =
0; int x = 0]’:
ice_func.cpp:9:25: internal compiler error: Segmentation fault
const char *x = __func__;
^
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
Preprocessed source stored into /tmp/ccseXGe8.out file, please attach this to
your bugreport.
GCC info:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.8.1-10ubuntu8' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu8)
[Bug libstdc++/59167] New: Add a specialization for std::hash<__gnu_debug::string>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59167 Bug ID: 59167 Summary: Add a specialization for std::hash<__gnu_debug::string> Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: bmerry at gmail dot com I have code for which I am explicitly selecting debug containers from the __gnu_debug namespace (I'm not using -D_GLIBCXX_DEBUG since it breaks the ABI with Boost and I don't want to require people to rebuild Boost to use a debug build of my code). This mostly works, but when I try to use an unordered_map with __gnu_debug::string as the key type I get errors because std::hash hasn't been specialized for it. I can write my own specialization, but it would be nice if the library just provided it. Obviously the other variants (wstring, u16string, u32string should be handled too).
[Bug c++/59213] New: Implicit move constructor created when base class has no move constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59213 Bug ID: 59213 Summary: Implicit move constructor created when base class has no move constructor Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: bmerry at gmail dot com Created attachment 31258 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31258&action=edit Sample case GCC is accepting the attached code, when it should be rejecting it. That's assuming I've correctly interpreted the C++11 spec [the draft - N3242]. Class A has no move constructor because it has a user-declared destructor [12.8.10], and it is not trivially copyable because it has a virtual member function [12.8.13]. Thus, B's move constructor is implicitly deleted [last bullet of 12.8.12]. Class C is a movable but non-copyable class. Thus, B's copy constructor is implicitly deleted [2nd bullet of 12.8.12]. Since B's copy and move constructors are deleted, the expression "return B()" should be a compilation error. The Clang 3.4 snapshot shipped with Ubuntu 13.10 rejects the code. It also rejects the code even if A's destructor is made non-virtual, in which case A is trivially copyable. I think this might be a Clang bug but I may have missed something. Compilation command: $ g++ -Wall -std=c++11 -c move.cpp Build information: $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.8.1-10ubuntu8' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu8) b
[Bug c++/59213] Implicit move constructor created when base class has no move constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59213 Bruce Merry changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Bruce Merry --- (In reply to Jonathan Wakely from comment #1) > I think G++ is implementing the resolution of > http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1402 Thanks, I wasn't aware of this. With the changes in the December 2012 resolution listed there, GCC does seem to be behaving correctly. I'll mark this bug as invalid and update the Clang bug I filed (http://llvm.org/bugs/show_bug.cgi?id=18005).
[Bug c++/86922] New: Invoking templated PTMF on subclass gives false strict-aliasing warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86922
Bug ID: 86922
Summary: Invoking templated PTMF on subclass gives false
strict-aliasing warning
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bmerry at gmail dot com
Target Milestone: ---
When using a pointer-to-member-function which is a template parameter on an
instance of a derived class, I get a warning about type-punned pointers
breaking strict aliasing. Warning message and sample code are below.
This doesn't seem to be a recent regression. I get essentially the same warning
(modulo formatting) from 4.8.5, 7.3.0 and Ubuntu's pre-release 8.0.1 (all on
Ubuntu 18.04, x86-64).
The code:
class A
{
public:
int a;
void foo() const;
};
class B : public A {};
template
class Wrapper
{
public:
void operator()(const B &obj) const
{
return (obj.*Ptr)();
}
};
void call()
{
Wrapper<&B::foo> wrapper;
wrapper(B());
}
Command line:
g++ -c strict.cpp -Wall -O2
Output:
with void (A::* Ptr)() const = &A::foo]’:
strict.cpp:23:16: required from here
strict.cpp:16:26: warning: dereferencing type-punned pointer will break
strict-aliasing rules [-Wstrict-aliasing]
return (obj.*Ptr)();
~~^~
gcc version info:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.3.0-16ubuntu3'
--with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --with-as=/usr/bin/x86_64-linux-gnu-as
--with-ld=/usr/bin/x86_64-linux-gnu-ld --program-suffix=-7
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 7.3.0 (Ubuntu 7.3.0-16ubuntu3)
Alternate version info:
Using built-in specs.
COLLECT_GCC=gcc-8
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
8-20180414-1ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --with-as=/usr/bin/x86_64-linux-gnu-as
--with-ld=/usr/bin/x86_64-linux-gnu-ld --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.0.1 20180414 (experimental) [trunk revision 259383] (Ubuntu
8-20180414-1ubuntu2)
[Bug libstdc++/58962] Pretty printers use obsolete Python syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58962 --- Comment #4 from Bruce Merry --- Incidentally, the workaround I have been using is to just run the script through 2to3. Since Python only tells you things have gone wrong when you execute the code I can't guarantee that this fixes everything, but I've yet to hit any further Python 2 vs 3 issues after doing this.
