[GCC Bugzilla] Your account gcc-bugs@gcc.gnu.org is being impersonated
Frédéric Buclin has used the 'sudo' feature to access GCC Bugzilla using your account. Frédéric Buclin provided the following reason for doing this: Checking email preferences for the mailing-list. Ignore this message. If you feel that this action was inappropriate, please contact overse...@gcc.gnu.org. For more information on this feature, visit <http://gcc.gnu.org/bugzilla/page.cgi?id=sudo.html>.
[Bug libstdc++/24595] std::tr1::get_deleter not declared
--- Comment #6 from gcc-bugzilla at kayari dot org 2005-11-12 14:12 --- Created an attachment (id=10227) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10227&action=view) alternative fix This is a fixed version of the previous patch that passes tests on linux-x86_64. This patch makes all specialisations of get_deleter friends, not just the ones where _Tp == _Tp1 ... but that's probably not a big deal. -- gcc-bugzilla at kayari dot org changed: What|Removed |Added Attachment #10194|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24595
[Bug c++/25137] Warning "missing braces around initializer" causing problems with tr1::array
--- Comment #9 from gcc-bugzilla at kayari dot org 2005-12-06 13:07 ---
I've often found this warning to be a nuisance, because it's correct and
well-defined to omit some braces from the initializer.
There are many cases where the warning is useful, e.g. with aggregates that
have several members (which may be aggregates themselves), but when the type
contains a single member (possibly of array type) then the extra braces are
often just clutter.
Pff the top of my head, I would like a way to disable the warning iff the
aggregate has a single member and iff the initializer contains exactly the
right number of elements to initialize that single member. e.g.
struct S { int s[3]; };
S s1 = { 1, 1, 1 }; // OK - missing braces but correct number
S s2 = { 1, 1 }; // WARN - no initializer for s2.s[2]
S s3 = { { 1, 1 } }; // OK - braces correct but missing init
I don't think this would be useful only for tr1::array, but for lots of similar
code. Obvious and closely-related examples are the block and carray templates
in Austern and Josuttis's books.
--
gcc-bugzilla at kayari dot org changed:
What|Removed |Added
CC| |gcc-bugzilla at kayari dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25137
[Bug c++/13590] [DR39] Non-existing ambiguity when inhering through virtuals two identical using declarations.
--- Comment #19 from gcc-bugzilla at kayari dot org 2005-12-10 13:17 --- would the summary be clarified by changing "Non-existing ambiguity when inhering through virtuals two identical using declarations" to "Ambiguity due to two using declarations for same member of virtual base" ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13590
[Bug c++/2316] g++ fails to overload on language linkage
--- Comment #13 from gcc-bugzilla at kayari dot org 2006-10-15 03:24 --- If this ever gets fixed (which I hope it does) then maybe it should depend on -std=c++98 so this continues to work by default, or it will break a lot of code that incorrectly passes extern "C++" functions to e.g. pthread_create and sigaction. That's a lot of code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
[Bug preprocessor/30808] New: It would probably make sense to abort immediately after a file-not-found.
One of the most common problems I face in compiling programs with many
dependancies is that, if a dependency is missing, the resulting error messages
almost invariably scroll off the screen instantly, and even apart from the
scrolling, the single relevant error ("Cannot open : No such file or
directory" or whatever) is buried under hundreds upon hundreds of lines of
errors about variables not declared in scope, syntax errors in declarations,
and so on.
In general, error cascades are virtually impossible to prevent.
However, it seems clear that, any time an include file is missing, we *know*
that the build is doomed to failure. I think it would be a nice option (and
possibly a very good default) for gcc to simply abort immediately after any
file-not-found message, on the grounds that, if you are missing a header file,
there is simply no point in telling you that, without that header, your program
doesn't work.
--
Summary: It would probably make sense to abort immediately after
a file-not-found.
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at seebs dot net
GCC build triplet: N/A
GCC host triplet: N/A
GCC target triplet: N/A
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30808
[Bug c++/33046] New: ICE on explicit/partial template static member specialization mix-up
g++ 4 will ICE when provided the explicit template specialization of a static
class member with an extra template argument (like for a partial spec):
template
struct S { static int v; };
template // instead of template<>
int S::v;
g++ 3.3.6 and 3.4.6 compile this without complaining. g++ 4.1.3, 4.2.1 and
yesterday's SVN (r127350) produce an ICE:
$ bin/g++ -c /tmp/t.cpp
/tmp/t.cpp:4: internal compiler error: in import_export_decl, at
cp/decl2.c:1965
Please submit...
Expected output:
template parameters not used in partial specialization: T
--
Summary: ICE on explicit/partial template static member
specialization mix-up
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at waba dot be
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33046
[Bug c++/33047] New: "extern template" GNU extension makes static data member definition a declaration
Using the GNU extension for forward declaration of explicit instantiations
("extern template...") seems to make static member definitions fall under the
rules of declarations:
$ cat /tmp/t.cpp
struct C {};
template
struct S { static T v; };
template
T S::v = T();
extern template class S;
C c = S::v;
$ bin/g++ -c /tmp/t.cpp
/tmp/t.cpp: In instantiation of C S::v:
/tmp/t.cpp:11: instantiated from here
/tmp/t.cpp:7: error: S::v cannot be initialized by a non-constant
expression when being declared
$ bin/g++ -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/M/src/inst --enable-languages=c++
--disable-bootstrap --disable-multilib
Thread model: posix
gcc version 4.3.0 20070810 (experimental)
Known workarounds for this issue are:
1. using g++ 3.x rather than the 4.1.3, 4.2.1 or trunk (r127350) that I tried
2. removing the "extern template" line
3. changing the order of the structure declaration, data member definition and
forward declaration lines
4. providing an explicit specialization of the static data members for the
forward-declared instantiations
--
Summary: "extern template" GNU extension makes static data member
definition a declaration
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at waba dot be
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33047
[Bug c++/94409] New: std::regexp (std::collate?) with GCC 7.3.1 on AIX, Japanese
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94409
Bug ID: 94409
Summary: std::regexp (std::collate?) with GCC 7.3.1 on AIX,
Japanese
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at vlasiu dot net
Target Milestone: ---
std::regexp constructor fail on AIX (Japanese). Works fine for English,
Spanish, Italian, French and German languages.
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/opt/freeware/libexec/gcc/powerpc-ibm-aix7.1.0.0/7.3.1/lto-wrapper
Target: powerpc-ibm-aix7.1.0.0
Configured with: ../gcc-7.3.1-20180303/configure --with-as=/usr/bin/as
--with-ld=/usr/bin/ld --enable-languages=c,c++,fortran --prefix=/opt/freeware
--mandir=/opt/freeware/man --infodir=/opt/freeware/info
--enable-version-specific-runtime-libs
--disable-nls --enable-decimal-float=dpd --enable-bootstrap
--build=powerpc-ibm-aix7.1.0.0
Thread model: aix
gcc version 7.3.1 20180303 (GCC)
The code:
#include
#include
#include
using namespace std;
int main()
{
char* pLocale = setlocale(LC_ALL, NULL);
std::cout << "setlocale(): " << pLocale << std::endl;
const std::regex r1("^(\\s+)?(.*?)(\\s+)?=(\\s+)?(.*?)(\\s+)?");
std::cout << "std::regex r1: OK" << std::endl;
setlocale(LC_ALL, "Ja_JP");
pLocale = setlocale(LC_ALL, NULL);
std::cout << "setlocale(): " << pLocale << std::endl;
const std::regex r2("asdf");
std::cout << "std::regex r2: OK" << std::endl;
// const std::regex r3("^(\\s+)?(.*?)(\\s+)?=(\\s+)?(.*?)(\\s+)?");
const std::regex r3("\\s+");
std::cout << "std::regex r3: OK" << std::endl;
return 0;
}
The output:
$ ./a.out
setlocale(): C C C C C C
std::regex r1: OK
setlocale(): Ja_JP Ja_JP Ja_JP Ja_JP Ja_JP Ja_JP
std::regex r2: OK
terminate called after throwing an instance of 'std::length_error'
what(): basic_string::append
IOT/Abort trap (core dumped)
$
$ gdb -c ./core ./a.out
...
(gdb) backtrace
#0 0x0957ff14 in pthread_kill () from
/usr/lib/libpthreads.a(shr_xpg5_64.o)
#1 0x0957f768 in _p_raise () from
/usr/lib/libpthreads.a(shr_xpg5_64.o)
#2 0x0903956c in raise () from /usr/lib/threads/libc.a(shr_64.o)
#3 0x09055f68 in abort () from /usr/lib/threads/libc.a(shr_64.o)
#4 0x090001c91740 in __gnu_cxx::__verbose_terminate_handler() () from
/usr/lpp/pd/lib64/libstdc++.a(libstdc++.so.6)
#5 0x090001ca0a4c in __cxxabiv1::__terminate(void (*)()) () from
/usr/lpp/pd/lib64/libstdc++.a(libstdc++.so.6)
#6 0x090001c91530 in std::terminate() () from
/usr/lpp/pd/lib64/libstdc++.a(libstdc++.so.6)
#7 0x090001c9fc90 in __cxa_rethrow () from
/usr/lpp/pd/lib64/libstdc++.a(libstdc++.so.6)
#8 0x090001cdbc50 in std::__cxx11::collate::do_transform () from
/usr/lpp/pd/lib64/libstdc++.a(libstdc++.so.6)
#9 0x090001cfea54 in std::__cxx11::collate::transform () from
/usr/lpp/pd/lib64/libstdc++.a(libstdc++.so.6)
#10 0x00010002dba0 in std::__cxx11::basic_string, std::allocator >
std::__cxx11::regex_traits::transform(char*, char*) const ()
#11 0x00010002c6c0 in std::__cxx11::basic_string, std::allocator >
std::__cxx11::regex_traits::transform_primary(char const*,
char const*) const ()
#12 0x00010002ae60 in
std::__detail::_BracketMatcher, false,
false>::_M_apply(char, std::integral_constant)
const::{lambda()#1}::operator()() const ()
#13 0x00010002ab2c in
std::__detail::_BracketMatcher, false,
false>::_M_apply(char, std::integral_constant) const ()
#14 0x00010002a6f8 in
std::__detail::_BracketMatcher, false,
false>::_M_make_cache(std::integral_constant) ()
#15 0x000100026294 in
std::__detail::_BracketMatcher, false,
false>::_M_ready() ()
#16 0x000100022600 in void
std::__detail::_Compiler
>::_M_insert_character_class_matcher() ()
#17 0x000100013208 in
std::__detail::_Compiler >::_M_atom() ()
#18 0x0001000101d8 in
std::__detail::_Compiler >::_M_term() ()
#19 0x000100010028 in
std::__detail::_Compiler >::_M_alternative()
()
#20 0x0001fe48 in
std::__detail::_Compiler >::_M_disjunction()
()#21 0x00012460 in
std::__detail::_Compiler >::_Compiler(char
const*, char const*, std::locale
const&, std::regex_constants::syntax_option_type) ()
#22 0x0001206c in
std::enable_if::value,
std::shared_ptr > const>
>::type std::__detail::__compile_nfa >(char const*, char const*,
std::__cxx11::regex_traits::locale_type const&,
std::regex_constants::syntax_option_type) ()
#23 0x00011e70 in std::__cxx11::basic_regex >::basic_regex(char const*, char
const*, std::locale, std::regex_constants::syn
[Bug libstdc++/94409] std::regexp (std::collate?) with GCC 7.3.1 on AIX, Japanese
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94409 --- Comment #2 from gcc-bugzilla at vlasiu dot net --- (In reply to Jonathan Wakely from comment #1) > N.B. GCC 7 is no longer supported and will not be fixed (but the bug is also > present in supported releases). We are going to switch soon to GCC 8.3.1 or 9.1.1. It would be nice to have a patch for any of those versions. Thank you.
[Bug libstdc++/94409] std::regexp (std::collate?) with GCC 7.3.1 on AIX, Japanese
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94409 --- Comment #4 from gcc-bugzilla at vlasiu dot net --- That's really bad news for us. Well, we'll wait for a patch and maybe we are going to backport-it. If it's going to be too complicated we are probably going to switch to one of the supported versions (we kind of need to be in sync with RHEL SCL version of GCC). Thank you.
[Bug c++/96299] New: Defaulted operator <=> implicitly deleted when a member has operator < and operator == and return type is specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96299
Bug ID: 96299
Summary: Defaulted operator <=> implicitly deleted when a
member has operator < and operator == and return type
is specified
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at mysko dot org
Target Milestone: ---
The following sample fails to compile with GCC 10.1 and with trunk as of
2020-07-22.
===
#include
struct Legacy
{
bool operator==(Legacy const&) const;
bool operator<(Legacy const&) const;
};
struct A
{
std::strong_ordering operator <=> (A const& other) const = default;
Legacy l;
};
int main()
{
A a, b;
return a < b;
}
===
With the following error:
: In function 'int main()':
:19:14: error: use of deleted function 'constexpr std::strong_ordering
A::operator<=>(const A&) const'
19 | return a < b;
| ^
:11:24: note: 'constexpr std::strong_ordering A::operator<=>(const A&)
const' is implicitly deleted because the default definition would be
ill-formed:
11 | std::strong_ordering operator <=> (A const& other) const = default;
|^~~~
:11:24: error: no match for 'operator<=>' (operand types are 'Legacy'
and 'Legacy')
>From my understanding of p1186r3
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1186r3.html) the code
should be accepted. The GCC standards support table lists p1186r3 as
implemented in GCC 10. According to p1186r3, the defaulted operator <=> should
use the member's < and == operators if the return type is specified
(strong/weak/partial), and should not require a <=> operator for the member.
[Bug c/96606] New: Shift operator not working correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96606 Bug ID: 96606 Summary: Shift operator not working correctly Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: gcc-bugzilla at ryuar dot in Target Milestone: --- Created attachment 49058 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49058&action=edit source code. Hello. The shift operator doesn't work correctly in some situations. Please check the attached file. after compiling with `gcc KISA_SEED_ECB.c`, The output below is shown. 9292920F 73870FC4 05D1ED04 182F3919 A = 9292920F >> 8 = C4929292 B = 73870FC4 >> 8 = 0F73870F I think the correct operation result is 9292920F 73870FC4 05D1ED04 182F3919 A = 9292920F >> 8 = 00929292 B = 73870FC4 >> 8 = 0073870F There seems to be a problem between line 353 and line 453. Please let me know if you think I'm mistaken.
[Bug c/96606] Shift operator not working correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96606 --- Comment #1 from RyuaNerin --- Created attachment 49059 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49059&action=edit msvc vs gcc
[Bug c/96606] Shift operator not working correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96606 RyuaNerin changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from RyuaNerin --- Unsigned long int is 64bit integer in x64.
[Bug c++/92143] New: std::pmr::polymorphic_allocator throws bad_alloc on macOS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92143
Bug ID: 92143
Summary: std::pmr::polymorphic_allocator throws bad_alloc
on macOS
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at daryl dot haresign.com
Target Milestone: ---
The following code throws a std::bad_alloc on macOS (seen via GCC 9.2 installed
with Homebrew, on macOS Catalina 10.15):
#include
#include
int main()
{
std::pmr::string s { "0123456789abcdef" };
}
16 characters is required to get it to overflow SSO.
The same issue can be seen with the following code:
#include
int main()
{
std::pmr::polymorphic_allocator alloc {
std::pmr::new_delete_resource()
};
alloc.allocate(1);
}
Changing the type from char to short, and char to int, yields the same error.
Once you get to long, it starts working.
Presumably power-of-two alignments less than sizeof(void *) are not supported
(that's certainly what posix_memalign says).
Looking through the wording, it's all down to a question of whether
[mem.res.private] p2 allows for your memory resources to force the alignment to
be at least alignof(void *). I would say the answer is probably yes.
http://eel.is/c++draft/mem.res#private-2
[Bug libstdc++/92143] std::pmr::polymorphic_allocator throws bad_alloc on macOS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92143 --- Comment #3 from Daryl Haresign --- $ g++-9 -E -dM test.cc | grep ALIGNED #define _GLIBCXX_HAVE_ALIGNED_ALLOC 1
[Bug libstdc++/92143] std::pmr::polymorphic_allocator throws bad_alloc on macOS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92143 --- Comment #4 from Daryl Haresign --- As for conformance, the latest C draft says: The aligned_alloc function allocates space for an object whose alignment is specified by alignment, whose size is specified by size, and whose value is indeterminate. If the value of alignment is not a valid alignment supported by the implementation the function shall fail by returning a null pointer. C11 said: The aligned_alloc function allocates space for an object whose alignment is specified by alignment, whose size is specified by size, and whose value is indeterminate. The value of alignment shall be a valid alignment supported by the implementation and the value of size shall be an integral multiple of alignment. So it seems macOS and AIX's implementations are technically conformant. Perhaps GCC should determine whether the platform supports alignments less than sizeof(void*) when GCC is built, and put a new macro in c++config.h (assuming that's how that file is constructed)?
[Bug libstdc++/92143] std::pmr::polymorphic_allocator throws bad_alloc on macOS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92143 --- Comment #8 from Daryl Haresign --- (In reply to Jonathan Wakely from comment #5) > C11 6.2.8 says "Valid alignments > include only those values returned by an _Alignof expression for fundamental > types, plus an additional implementation-defined set of values, which may be > empty. Every valid alignment shall be a nonnegative integral power of two." > > _Alignof(char) and _Alignof(short) and _Alignof(int) are valid alignments > supported by the implementation, and so aligned_alloc is wrong to reject > them. Read together I agree it does sound that way. (In reply to Jonathan Wakely from comment #7) > Fixed on trunk so far, but I'll backport it too. Great, thanks!
[Bug middle-end/56759] New: result of __builtin_constant_p( ) is not constant enough for __builtin_choose_expr( )
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56759
Bug #: 56759
Summary: result of __builtin_constant_p( ) is not constant
enough for __builtin_choose_expr( )
Classification: Unclassified
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gcc-bugzi...@codyps.com
Testcase:
---
static inline int x(int y)
{
return __builtin_choose_expr(__builtin_constant_p(y), 1, 0);
}
int foo(void)
{
return x(3);
}
---
$ i386-linux-gcc constant_not_constant.c -O3 -c
constant_not_constant.c: In function 'x':
constant_not_constant.c:4:9: error: first argument to '__builtin_choose_expr'
not a constant
return __builtin_choose_expr(__builtin_constant_p(y), 1, 0);
^
$ i386-linux-gcc -v
Using built-in specs.
COLLECT_GCC=i386-linux-gcc
COLLECT_LTO_WRAPPER=/home/cody/x-buildall/libexec/gcc/i386-linux/4.8.1/lto-wrapper
Target: i386-linux
Configured with: /home/cody/g/gcc/configure --target=i386-linux
--enable-targets=all --prefix=/home/cody/x-buildall --enable-languages=c
--without-headers --enable-sjlj-exceptions --with-system-libunwind
--disable-nls --disable-threads --disable-shared --disable-libmudflap
--disable-libssp --disable-libgomp --disable-decimal-float
--disable-libquadmath --enable-checking=release --disable-libatomic :
(reconfigured) /home/cody/g/gcc/configure --target=i386-linux
--enable-targets=all --prefix=/home/cody/x-buildall --enable-languages=c
--without-headers --enable-sjlj-exceptions --with-system-libunwind
--disable-nls --disable-threads --disable-shared --disable-libmudflap
--disable-libssp --disable-libgomp --disable-decimal-float
--disable-libquadmath --enable-checking=release --disable-libatomic :
(reconfigured) /home/cody/g/gcc/configure --target=i386-linux
--enable-targets=all --prefix=/home/cody/x-buildall --enable-languages=c
--without-headers --enable-sjlj-exceptions --with-system-libunwind
--disable-nls --disable-threads --disable-shared --disable-libmudflap
--disable-libssp --disable-libgomp --disable-decimal-float
--disable-libquadmath --enable-checking=release --disable-libatomic :
(reconfigured) /home/cody/g/gcc/configure --target=i386-linux
--enable-targets=all --prefix=/home/cody/x-buildall --enable-languages=c
--without-headers --enable-sjlj-exceptions --with-system-libunwind
--disable-nls --disable-threads --disable-shared --disable-libmudflap
--disable-libssp --disable-libgomp --disable-decimal-float
--disable-libquadmath --enable-checking=release --disable-libatomic
Thread model: single
gcc version 4.8.1 20130328 (prerelease) (GCC)
[Bug middle-end/56759] result of __builtin_constant_p( ) is not constant enough for __builtin_choose_expr( )
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56759 --- Comment #1 from Cody P Schafer 2013-03-28 00:56:11 UTC --- This also affects my ubuntu gcc install: $ gcc constant_not_constant.c -O3 -c constant_not_constant.c: In function ‘x’: constant_not_constant.c:4:31: error: first argument to ‘__builtin_choose_expr’ not a constant $ gcc -v Using built-in specs. COLLECT_GCC=/usr/bin/gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --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-gnu-unique-object --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.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
[Bug c++/11701] Typeof problems in detecting whether its argument is a type or an expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11701 --- Comment #2 from Eelis 2012-03-22 21:56:17 UTC --- For what it's worth: as the original reporter, I no longer care about this bug (or typeof in general), because we now have C++11 with decltype. :)
[Bug libstdc++/59611] New: std::copy performs worse than naive implementation when copying a single known byte
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59611 Bug ID: 59611 Summary: std::copy performs worse than naive implementation when copying a single known byte Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: gcc-bugzilla at contacts dot eelis.net Created attachment 31524 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31524&action=edit Testcase The attached testcase shows how using a naive implementation (mycopy) causes gcc to generate better code than using std::copy. (Clang /does/ generate optimal code when using std::copy in this case.)
[Bug libstdc++/59611] std::copy performs worse than naive implementation when copying a single known byte
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59611 --- Comment #1 from Eelis --- (With -O3)
[Bug c++/51665] New: undefined reference when passing static const int member to template method
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51665
Bug #: 51665
Summary: undefined reference when passing static const int
member to template method
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gcc-bugzi...@bluespirit.la
Created attachment 26172
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26172
sources, save-temps, command line
Calling the template method qMax(T,T) with a constant (static const int) as
first parameter, I get an undefined reference. When saving this constant to a
local constant and using this for as template parameter, everything works fine.
Using Debian testing with Gcc 4.6.2-7 on Linux 3.1.0.1-686-pae.
Command line: g++ *.cpp
ld --version: GNU ld (GNU Binutils for Debian) 2.22
g++ --version: g++ (Debian 4.6.2-7) 4.6.2
template
inline const T &qMax(const T &a, const T &b) { if (a < b) return b; return a; }
class MyClass
{
public:
void doSomething();
private:
static const int M_SOME_CONSTANT = 24;
};
//
// NOT WORKING
//
void MyClass::doSomething()
{
int iValue = 77 + M_SOME_CONSTANT;
iValue += qMax( M_SOME_CONSTANT, 12 );
}
//
// WORKING
//
void MyClass::doSomething()
{
int iValue = 77 + M_SOME_CONSTANT;
const int iTmp = M_SOME_CONSTANT;
iValue += qMax( iTmp , 12 );
}
[Bug c++/51665] undefined reference when passing static const int member to template method
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51665 --- Comment #1 from Karl Krach 2011-12-23 13:38:22 UTC --- g++ *.cpp --save-temps MyClass.o:MyClass.cpp:function MyClass::doSomething(): error: undefined reference to 'MyClass::M_SOME_CONSTANT' collect2: ld returned 1 exit status
[Bug c++/107466] New: [12 Regression] invalid -Wnarrowing error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107466 Bug ID: 107466 Summary: [12 Regression] invalid -Wnarrowing error Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: littlefox+gcc-bugzi...@lf-net.org Target Milestone: --- Created attachment 53797 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53797&action=edit Code triggering the error Hi, the attached code (and Godbolt[1]) fails in gcc 12+ with an -Wnarrowing error in a stdlibc++ template instantiated with an uint16_t and apparently trying to work with a 2^31: /opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/bits/random.tcc:545:9: error: narrowing conversion of '2147483563' from 'unsigned int' to 'short unsigned int' [-Wnarrowing] 545 | __lcg(__value == 0u ? default_seed : __value); The code works fine in 11.3 and clang (14) and since it also works in clang using libstdc++ 12.2, this error is probably in gcc itself and not in libstdc++. Tested this on my machine (debian testing), where it broke after a some system updates where installed - including a gcc update. Then tested this in Godbolt to check compiler versions and other configurations and asked in libera.chat/#c++ for others to verify if my code makes sense - which it seems to do. Best, Mara [1] Godbolt link: https://godbolt.org/z/sj18Mv5j9
[Bug c++/107466] [12/13 Regression] invalid -Wnarrowing error with std::subtract_with_carry_engine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107466 --- Comment #3 from Mara Sophie Grosch --- Standard explicitly allows using unsigned short though: https://en.cppreference.com/w/cpp/numeric/random/subtract_with_carry_engine
[Bug c/85696] New: OpenMP with variably modified and default(none) won't compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85696
Bug ID: 85696
Summary: OpenMP with variably modified and default(none) won't
compile
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at zulan dot net
Target Milestone: ---
Created attachment 44085
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44085&action=edit
gcc -v (Archlinux)
The following trivial code
void foo(int n, int a[][n])
{
#pragma omp parallel shared(a) default(none)
a[23][0] = 42;
}
fails to compile:
$ gcc -c -fopenmp minimal.c
minimal.c: In function ‘foo’:
minimal.c:3:6: error: ‘n.0’ not specified in enclosing ‘parallel’
a[23][0] = 42;
^
minimal.c:2:9: error: enclosing ‘parallel’
#pragma omp parallel shared(a) default(none)
^~~
It appears that there is an internal copy n.0 of n to compute the index to any
further access to a. This internal copy is not handled properly in the
default(none) parallel region.
Interestingly in the 004t.gimple pass, it is actually listed as shared(n.0):
#pragma omp parallel default(none) shared(a) shared(n.0)
The bug exists at least since 4.8 and was first reported at
https://stackoverflow.com/q/47081274/620382
[Bug c/85696] OpenMP with variably modified and default(none) won't compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85696 gcc-bugzilla at zulan dot net changed: What|Removed |Added Attachment #44085|0 |1 is obsolete|| --- Comment #1 from gcc-bugzilla at zulan dot net --- Created attachment 44086 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44086&action=edit pologies, wrong gcc version. The error of 8.1.0 is exactly the same though.
[Bug c/85696] OpenMP with variably modified and default(none) won't compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85696 --- Comment #2 from gcc-bugzilla at zulan dot net --- Created attachment 44087 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44087&action=edit minimal example
[Bug c++/91387] New: Segfault using -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91387 Bug ID: 91387 Summary: Segfault using -flto Product: gcc Version: 8.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: gcc-bugzilla at tobias dot goedderz.info Target Milestone: --- Created attachment 46684 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46684&action=edit Preprocessed source code Hi, I'm experiencing g++ segfaults during compilation. This is a "minimal" example in terms of command line parameters, using the preprocessed source (which is not minimal): > $ /usr/bin/g++-8 -std=c++14 -O2 -flto -fno-devirtualize -c > ShapeContainerTest.ii > during IPA pass: cp > /home/tobias/Documents/ArangoDB/arangodb/arangodb/tests/Geo/ShapeContainerTest.cpp: > In function ‘arangodb::velocypack::Builder::openCompoundValue(unsigned char) > [clone .part.119]’: > /home/tobias/Documents/ArangoDB/arangodb/arangodb/tests/Geo/ShapeContainerTest.cpp:427:2: > internal compiler error: Segmentation fault > }} > ^ > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. This is with g++ (Ubuntu 8.3.0-6ubuntu1~18.04.1) 8.3.0. I have two other files exhibiting a similar error, if it's of interest. The one referenced above is attached. Please tell me if and how I can be of further help. Best regards, Tobias
[Bug lto/91988] New: Inlining fails with LTO enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91988
Bug ID: 91988
Summary: Inlining fails with LTO enabled
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at tobias dot goedderz.info
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Inlining fails with LTO when there is an argument with a destructor. This seems
unintentional to me, given the following behaviour.
Given the following example files:
==> main.cpp <==
#include "lib.h"
int main() {
return fun(A{});
}
==> lib.h <==
#ifndef LIB_H
#define LIB_H
class A { public: ~A() {} };
__attribute__((always_inline))
int fun(A);
#endif // LIB_H
==> lib.cpp <==
#include "lib.h"
__attribute__((always_inline))
int fun(A a) { return 0; }
and compiling with
/usr/bin/g++-8 -g -Wall -pedantic -O3 -std=c++14 -flto -c lib.cpp
/usr/bin/g++-8 -g -Wall -pedantic -O3 -std=c++14 -flto -c main.cpp
/usr/bin/g++-8 -g -Wall -pedantic -O3 -std=c++14 -flto -o main-gcc main.o lib.o
fails with
error: inlining failed in call to always_inline ‘fun(A)’: mismatched
arguments
in the last step.
Removing "__attribute__((always_inline))" and inspecting the deassembled output
confirms that the function isn't inlined.
If the body is moved to the header file (and the "inline" specifier added), the
function is inlined.
If the destructor of "A" is removed, or changed to "~A() = default", the
function is inlined.
If the argument to "fun" is changed to a "const&", the function is inlined.
[Bug lto/91988] Inlining fails with LTO enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91988 --- Comment #1 from Tobias Gödderz --- Happens with GCC 9.1.0 as well.
[Bug c++/84222] New: [[deprecated]] class complains about internal class usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84222
Bug ID: 84222
Summary: [[deprecated]] class complains about internal class
usage
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at daryl dot haresign.com
Target Milestone: ---
If I mark a class with the [[deprecated]] annotation, it complains when the
class uses its own name in the implementation:
class [[deprecated]] C {
public:
C() {}
C(const C&) = default; // emits a deprecation warning
C(C&&) = delete;// also emits a warning
};
[Bug c++/84222] [[deprecated]] class complains about internal class usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84222
--- Comment #1 from Daryl Haresign ---
Additionally, any external use of a static method of a deprecated class should
probably (but does not currently) emit a warning (Clang emits a warning).
class [[deprecated]] C {
public:
void fn() {}
};
int main()
{
C::fn(); // does not emit a deprecation warning
}
[Bug c++/84222] [[deprecated]] class complains about internal class usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84222 --- Comment #2 from Daryl Haresign --- See also bug 79817.
[Bug other/89635] More ANSI SGR codes in diagnostics?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89635 Lucas Werkmeister changed: What|Removed |Added CC||gcc-bugzilla@lucaswerkmeist ||er.de --- Comment #1 from Lucas Werkmeister --- Note that not all terminals support underlining – systemd had some issues with this, compare https://github.com/systemd/systemd/pull/6778 and linked issues.
[Bug c++/78511] New: ICE on using concept name as a "requires" parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78511
Bug ID: 78511
Summary: ICE on using concept name as a "requires" parameter
Product: gcc
Version: c++-concepts
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at minijackson dot 33mail.com
Target Milestone: ---
GCC version and system:
gcc (Gentoo 6.2.0-r1 p1.1) 6.2.0
Compilation options:
-altivec -awt -cilk cxx -debug -doc -fixed-point fortran gcj -go -graphite
-hardened -jit -libssp -mpx multilib nls nptl -objc -objc++ -objc-gc openmp pch
-pie -regression-test sanitize -ssp -vanilla vtv
Example program (test.cpp):
template
concept bool A = true;
template
concept bool B = requires(A a) {
a;
}
Command line:
g++ -fconcepts -std=c++1z test.cpp
Error:
test.cpp:5:27: internal compiler error: in synthesize_implicit_template_parm,
at cp/parser.c:37866
concept bool B = requires(A a) {
^
test.ii generated file:
# 1 "test.cpp"
# 1 ""
# 1 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 1 "" 2
# 1 "test.cpp"
template
concept bool A = true;
template
concept bool B = requires(A a) {
a;
}
[Bug c++/78966] New: Unjustified variadic template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78966
Bug ID: 78966
Summary: Unjustified variadic template instantiation
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at contacts dot eelis.net
Target Milestone: ---
Consider:
template
struct vari
{
static_assert(sizeof...(TT) != 0, "bleh");
};
template struct X {};
void f(void(*)(X));
template void f(vari);
// if this line is commented out, code compiles fine
template void g(X);
void h() { f(g); }
When compiled with gcc 7.0.0 20161219, the static assert triggers:
prog.cc: In instantiation of 'struct vari<>':
prog.cc:16:15: required from here
prog.cc:4:3: error: static assertion failed: bleh
static_assert(sizeof...(TT) != 0, "bleh");
But there's no reason for vari to be instantiated without arguments here, is
there?
[Bug c++/78966] Unjustified variadic template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78966
--- Comment #2 from Eelis ---
The testcase was a minimized version of the (imho innocuous looking):
#include
#include
template
std::ostream & operator<<(std::ostream &, std::variant const &);
int main() { std::cout << std::endl; }
This gives:
error: invalid use of incomplete type ‘struct std::variant_alternative<0,
std::variant<> >’
I'd be curious to know the rule that makes this ill-formed. Anybody happen to
know it, or the number of the DR (if there is one)?
In any case, feel free to close the ticket if GCC is really correct here. In
that case, sorry for the noise. :)
[Bug c++/78966] Unjustified variadic template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78966 Eelis changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #6 from Eelis --- Ah, thanks for the explanation! That makes sense. I guess that to avoid this problem, one should adhere to a rule along the lines of: "If you're about to write a function like template R f(X); then if f is potentially overloaded, and X cannot be instantiated with an empty pack, you better write f as: template R f(X) because otherwise calls to those other fs may end up requiring X to be instantiable with an empty pack." I now use this workaround for my operator<< for std::variant. Closing.
[Bug libstdc++/79254] New: basic_string::operator= isn't exception safe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79254 Bug ID: 79254 Summary: basic_string::operator= isn't exception safe Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: gcc-bugzilla at daryl dot haresign.com Target Milestone: --- Assigning one string to another, where they have non-equal propagate-on-copy-assignment allocators, does a `_M_destroy()`, followed by an `assign()`. The `assign()` may throw, which leaves the string in a cleared state. This seems to violate the requirement specified here: http://eel.is/c++draft/basic.string#string.require-2 A contrived example to show this: http://coliru.stacked-crooked.com/a/1891a2678a9589d3
[Bug libstdc++/79254] [5/6/7 Regression] basic_string::operator= isn't exception safe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79254 --- Comment #6 from Daryl Haresign --- I guess you don't want _M_copy_assign to be public, either.
[Bug libstdc++/79254] [5/6/7 Regression] basic_string::operator= isn't exception safe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79254
--- Comment #7 from Daryl Haresign ---
I would also be inclined to reverse your Guard: have it take 'this', have an
'activate' method which swaps in the new values, have a 'deactivate' method
which releases the memory, and have its destructor swap back the old values.
Something like this (formatting and naming aside):
void
_M_copy_assign(const basic_string& __str, true_type)
{
struct _Guard {
_Guard(basic_string *__s)
: _M_self(__s)
, _M_alloc(_M_self->_M_get_allocator())
{
}
~_Guard() {
if (_M_ptr)
{
_M_self->_M_data(_m_ptr);
_M_self->_M_set_length(_M_size)
_M_self->_M_get_allocator() = _M_alloc;
}
}
void _M_activate() {
_M_ptr = _M_self->_M_data();
_M_size = _M_self->_M_allocated_capacity;
_M_self->_M_data(_M_local_data());
_M_self->_M_set_length(0);
}
void _M_deactivate() {
if (_M_ptr)
{
_Alloc_traits::deallocate(_M_alloc, _M_ptr, _M_size + 1);
_M_ptr = nullptr;
}
}
basic_string *_M_self;
allocator_type _M_alloc;
pointer _M_ptr = nullptr;
size_type _M_size = 0;
};
_Guard __guard(this);
if (!_Alloc_traits::_S_always_equal() && !_M_is_local()
&& _M_get_allocator() != __str._M_get_allocator())
{
// Replacement allocator cannot free existing storage.
__guard._M_activate();
}
_M_get_allocator() = __str._M_get_allocator();
this->_M_assign(__str);
__guard._M_deactivate();
}
[Bug c++/33952] -Wfatal-errors truncates multi-line error messages.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33952 --- Comment #5 from Eelis --- (In reply to David Malcolm from comment #4) > Eelis: FWIW, gcc has a -fmax-errors=n option; I wonder if setting that to 1 > might be a better fit for geordi? (just thinking aloud here). It also truncates the error in the testcase.
[Bug libstdc++/77994] New: std::sample uses incorrect integer types internally
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77994 Bug ID: 77994 Summary: std::sample uses incorrect integer types internally Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: gcc-bugzilla at contacts dot eelis.net Target Milestone: --- Both the reservoir sampling and the selection sampling implementations use a uniform_int_distribution<_Size> to generate integers distributed over the population size, but _Size is merely the type of the user-supplied argument specifying the desired selection size, and that type may not be large enough to represent integers distributed over the population size. The selection sampling implementation also uses _Size for __unsampled_sz, which is incorrect for the same reason.
[Bug c++/10619] Error message for no matching function calls does not list explicitly-specified template arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10619 Eelis changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Eelis --- GCC now emits additional diagnostics explaining why the candidate f could not be used, which is exactly what I wanted. Thanks!
[Bug c++/42490] using-directive in namespace doesn't work properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42490 Eelis changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Eelis --- Seems to be fixed, thanks!
[Bug libstdc++/56785] std::tuple of two elements does not apply empty base class optimization when one of its elements is a std::tuple with two elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56785 Eelis changed: What|Removed |Added CC||gcc-bugzilla at contacts dot eelis ||.net --- Comment #2 from Eelis --- Another manifestation of this is that sizeof(pair,pair>) == 4 while sizeof(tuple,tuple>) == 5 (!!). I think that at the moment, GCC users are best advised to avoid using stdlib tuples if efficiency is a concern.
[Bug libstdc++/56785] std::tuple of two elements does not apply empty base class optimization when one of its elements is a std::tuple with two elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56785 --- Comment #6 from Eelis --- Clang's libc++ (which gives the expected result) might be another source of inspiration.
[Bug libstdc++/56785] std::tuple of two elements does not apply empty base class optimization when one of its elements is a std::tuple with two elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56785
--- Comment #8 from Eelis ---
With Clang 3.5, given
struct X: std::tuple<> { char c; };
I get sizeof(X)==1. Is that not what you mean?
[Bug libstdc++/56785] std::tuple of two elements does not apply empty base class optimization when one of its elements is a std::tuple with two elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56785 --- Comment #10 from Eelis --- I see what you mean! And while stuff with empty types and EBO is IMHO not nearly as serious as random superfluous bytes that are inserted when you use tuples of a bread and butter type like char, I agree it would be good to file a ticket in http://llvm.org/bugs/ if there isn't one already. :)
[Bug libstdc++/56785] std::tuple of two elements does not apply empty base class optimization when one of its elements is a std::tuple with two elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56785 --- Comment #12 from Eelis --- Ooh, very nice! Thanks!
[Bug rtl-optimization/65371] arm loop with volatile variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65371
--- Comment #2 from Stuart ---
I compiled it for x86_64 and thought it was fine, however, after your comment I
tried compiling it with clang/llvm and can see the difference (I'm not
particularly familiar with the full instruction set)...
I've found another case which could also be improved:
func.c:
#include
#define PERIPH_BASE0x4000
#define PERIPH ((PERIPH_TypeDef *) PERIPH_BASE)
typedef struct
{
volatile uint32_t REG1;
} PERIPH_TypeDef;
void func(uint16_t a)
{
uint32_t t = PERIPH->REG1;
while ((uint16_t) (PERIPH->REG1 - t) < a) { }
}
gives:
:
0: f04f 4380 mov.w r3, #1073741824 ; 0x4000
4: 461amov r2, r3
6: 6819ldr r1, [r3, #0]
8: 6813ldr r3, [r2, #0]
a: 1a5bsubsr3, r3, r1
c: b29buxthr3, r3
e: 4283cmp r3, r0
10: d3fabcc.n 8
12: 4770bx lr
For some reason r3 is moved in to r2 and then value at the address in r2 is
loaded in to r3 for the loop!
I would expect the following:
:
0: f04f 4180 mov.w r1, #1073741824 ; 0x4000
4: 680aldr r2, [r1, #0]
6: 680bldr r3, [r1, #0]
8: 1a9bsubsr3, r3, r2
a: b29buxthr3, r3
c: 4283cmp r3, r0
e: d3fabcc.n 6
10: 4770bx lr
[Bug c++/68003] New: Variable declared in condition in for loop is destroyed too soon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68003
Bug ID: 68003
Summary: Variable declared in condition in for loop is
destroyed too soon
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at contacts dot eelis.net
Target Milestone: ---
Consider:
#include
#include
struct X
{
bool alive = true;
~X() { alive = false; }
explicit operator bool() const { return true; }
} ;
int main()
{
for(int i = 0; X x = X(); assert(x.alive))
if (++i == 3)
break;
else
std::cout << i << std::endl;
}
When compiled with gcc trunk, the program outputs:
1
a.out: t.cpp:14: int main(): Assertion `x.alive' failed.
When compiled with clang trunk, the program outputs:
1
2
[Bug c++/64450] New: Optimize 0>=p-q to q>=p for char*p,*q;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64450 Bug ID: 64450 Summary: Optimize 0>=p-q to q>=p for char*p,*q; Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: gcc-bugzilla at contacts dot eelis.net Created attachment 34365 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34365&action=edit Testcase It was noticed that Boost's iterator_facade incurred a performance penalty (while it should ideally be zero-overhead), which results from the fact that GCC does not optimize 0>=p-q to q>=p for char*p,*q;. See attachment. This probably applies to > and < and <= as well.
[Bug c++/59354] Unexpected result in g++ when casting int to char from an stl vector to an array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59354
Eelis changed:
What|Removed |Added
CC||gcc-bugzilla at contacts dot
eelis
||.net
--- Comment #1 from Eelis ---
This is not specific to std::vector and not specific to C++.
C testcase:
#include
#include
int main()
{
uint32_t a[256] = {};
uint8_t b[1000] = {};
for(int i = 0; i != 256; ++i)
a[i] = i % 5;
for (int z = 0 ; z < 16; z++)
for (int y = 0 ; y < 4; y++)
for (int x = 0 ; x < 4; x++)
b[y * 64 + z*4 + x] = a[z * 16 + y * 4 + x];
printf("%d\n", b[4]);
return 0;
}
Prints '4' without -mno-sse, prints '1' with -mno-sse.
[Bug libstdc++/64476] New: std::uninitialized_copy tests assignability the wrong way, resulting in performance pessimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64476 Bug ID: 64476 Summary: std::uninitialized_copy tests assignability the wrong way, resulting in performance pessimization Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: gcc-bugzilla at contacts dot eelis.net It does: typedef typename iterator_traits<_InputIterator>::reference _RefType; const bool __assignable = is_assignable<_ValueType1, _RefType>::value; but should do: typedef typename iterator_traits<_ForwardIterator>::reference _RefType; const bool __assignable = is_assignable<_RefType, _ValueType1>::value;
[Bug c++/57971] Improve copy elision when returning structs by value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57971
Eelis changed:
What|Removed |Added
CC||gcc-bugzilla at contacts dot
eelis
||.net
--- Comment #1 from Eelis ---
struct foo { foo(); foo(foo const &); };
foo bar();
foo fast(bool b) {
if (b) return foo();
return bar();
}
/* produces (with -O3):
_Z4fastb:
.LFB0:
testb%sil, %sil
pushq%rbx
movq%rdi, %rbx
jne.L6
call_Z3barv
movq%rbx, %rax
popq%rbx
ret
.p2align 4,,10
.p2align 3
.L6:
call_ZN3fooC1Ev
movq%rbx, %rax
popq%rbx
ret
*/
foo slow(bool b) {
if (b) return foo();
foo f = bar();
return f;
}
/* produces (with -O3):
_Z4slowb:
.LFB1:
pushq%rbx
movq%rdi, %rbx
subq$16, %rsp
testb%sil, %sil
jne.L11
leaq15(%rsp), %rdi
call_Z3barv
leaq15(%rsp), %rsi
movq%rbx, %rdi
call_ZN3fooC1ERKS_
addq$16, %rsp
movq%rbx, %rax
popq%rbx
ret
.p2align 4,,10
.p2align 3
.L11:
call_ZN3fooC1Ev
addq$16, %rsp
movq%rbx, %rax
popq%rbx
ret
*/
[Bug c++/65221] typedef-name identifier not resolved in static member instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65221 --- Comment #1 from Philipp Ittershagen --- $ g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.1-19' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify --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.9-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --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.9.1 (Debian 4.9.1-19)
[Bug target/65371] New: arm loop with volatile variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65371
Bug ID: 65371
Summary: arm loop with volatile variable
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at enginuities dot com
Target: arm-none-eabi (Cortex-M3)
I've found this behaviour with gcc 4.8.4, 4.9.2, and 5.0.0 (20150308) (all
compiled with the same flags) on Arch Linux (3.18.2-2-ARCH x86_64).
I've also had the same behaviour using the precompiled gcc-arm-embedded
toolchain from Launchpad (gcc-arm-none-eabi-4_9-2014q4).
Compiling func.c:
#define PERIPH_BASE0x4001000
#define PERIPH ((PERIPH_TypeDef *) PERIPH_BASE)
typedef struct
{
volatile unsigned long REG1;
} PERIPH_TypeDef;
void func()
{
PERIPH->REG1 |= 0x0001;
while (!(PERIPH->REG1 & 0x0002)) { }
PERIPH->REG1 |= 0x0100;
}
With:
arm-none-eabi-gcc -mthumb -mcpu=cortex-m3 -Os -c func.c
Results in the following disassembly of func.o:
:
0: 4b06ldr r3, [pc, #24] ; (1c )
2: 681aldr r2, [r3, #0]
4: f442 3280 orr.w r2, r2, #65536 ; 0x1
8: 601astr r2, [r3, #0]
a: 6819ldr r1, [r3, #0]
c: 4a03ldr r2, [pc, #12] ; (1c )
e: 0389lslsr1, r1, #14
10: d5fbbpl.n a
12: 6813ldr r3, [r2, #0]
14: f043 7380 orr.w r3, r3, #16777216 ; 0x100
18: 6013str r3, [r2, #0]
1a: 4770bx lr
1c: 04001000streq r1, [r0], #-0
The last line in func.c (PERIPH->REG1 |= 0x0100;) causes the compiled code
to load the address of PERIPH->REG1 in to r2 during the loop at
(ldr r2, [pc, #12]) and then use r2 after the loop even though the address
contained in r2 was loaded in to r3 at (ldr r3, [pc, #24]) and
doesn't change.
As such I would expect something like this disassembly of func.o:
:
0: 4b06ldr r3, [pc, #24] ; (1c )
2: 681aldr r2, [r3, #0]
4: f442 3280 orr.w r2, r2, #65536 ; 0x1
8: 601astr r2, [r3, #0]
a: 681aldr r2, [r3, #0]
c: 0392lslsr2, r2, #14
e: d5fcbpl.n a
10: 681aldr r2, [r3, #0]
12: f042 7280 orr.w r2, r2, #16777216 ; 0x100
16: 601astr r2, [r3, #0]
18: 4770bx lr
1a: bf00nop
1c: 04001000streq r1, [r0], #-0
arm-none-eabi-gcc -v:
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/home/test_user/toolchain/libexec/gcc/arm-none-eabi/5.0.0/lto-wrapper
Target: arm-none-eabi
Configured with: /home/test_user/temp/gcc-5-20150308/gcc-5-20150308/configure
--disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap
--disable-libquadmath --disable-libssp --disable-libstdcxx-pch --disable-nls
--disable-shared --disable-threads --disable-tls --enable-languages=c,c++
--prefix=/home/test_user/toolchain --target=arm-none-eabi
--with-gmp=/home/test_user/toolchain --with-gnu-as --with-gnu-ld
--with-mpc=/home/test_user/toolchain --with-mpfr=/home/test_user/toolchain
--with-newlib --without-headers
Thread model: single
gcc version 5.0.0 20150308 (experimental) (GCC)
[Bug c++/63728] New: Memory exhaustion using constexpr constructors for classes with large array members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63728
Bug ID: 63728
Summary: Memory exhaustion using constexpr constructors for
classes with large array members
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at bmevers dot de
Having a constexpr constructor on a class with a large array member will result
in excessive memory usage. For example, I wasn't able to compile the following
program using -std=c++11 on a machine with 4GiB of RAM:
#include
int main() {
std::bitset<2147483648> bs;
}
This happens because the constructor of bitset is constexpr, so it will try to
initialize the large member array at compile time, which will create at least
one ast tree node for every element in the array. (gcc/cp/constexpr.c:1874)
[Bug middle-end/12086] memcmp(i,j,4) should use word (SI) subtraction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12086
Eelis changed:
What|Removed |Added
CC||gcc-bugzilla at contacts dot
eelis
||.net
--- Comment #11 from Eelis ---
This bug means that for
struct X { char a[8]; };
bool f(X x, X y) { return __builtin_memcmp(x.a, y.a, 8); }
gcc emits:
subq$40, %rsp
.cfi_def_cfa_offset 48
movl$8, %edx
movq%rdi, 16(%rsp)
leaq16(%rsp), %rdi
movq%rsi, (%rsp)
movq%rsp, %rsi
callmemcmp
testl %eax, %eax
setne %al
addq$40, %rsp
.cfi_def_cfa_offset 8
ret
while clang emits:
movq%rdi, -8(%rsp)
movq%rsi, -16(%rsp)
cmpq%rsi, -8(%rsp)
setne%al
retq
(which is still suboptimal due to llvm bug #20673).
[Bug c++/63904] New: ICE when acessing array member of constexpr struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63904
Bug ID: 63904
Summary: ICE when acessing array member of constexpr struct
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at bmevers dot de
Created attachment 33994
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33994&action=edit
Preprocessed source
The following code causes an internal compiler error:
template
struct foo {
constexpr foo() : a() {}
int a[N];
};
int main() {
foo< (foo<1>{}).a[0] > f;
}
constexpr-initalization.cpp:7:25: in constexpr expansion of
‘f.foo::foo<0>()’
constexpr-initalization.cpp:7:25: internal compiler error: in tree_low_cst, at
tree.h:4849
foo< (foo<1>{}).a[0] > f;
[Bug libstdc++/64128] New: Let vector take advantage of malloc_usable_size for malloc-using allocators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64128 Bug ID: 64128 Summary: Let vector take advantage of malloc_usable_size for malloc-using allocators Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: gcc-bugzilla at contacts dot eelis.net Created attachment 34150 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34150&action=edit testcase Changing this->_M_impl._M_end_of_storage = __new_start + __len; to this->_M_impl._M_end_of_storage = __new_start + malloc_usable_size(__new_start) / sizeof(value_type); in vector.tcc makes the runtime of the attached program drop from 0.35 seconds to 0.24 seconds on my machine, a 31% reduction. This shows there is low hanging fruit for a very common operation (vector::push_back). A proper implementation would of course only do this for allocators that are known to be malloc frontends. :)
[Bug libstdc++/64128] Let vector take advantage of malloc_usable_size for malloc-using allocators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64128 --- Comment #1 from Eelis --- Hmm, std::allocator::allocate calls ::operator new, which may be user-defined, so maybe there is no practical way to detect whether it is really using malloc. :(
[Bug libstdc++/64128] Let vector take advantage of malloc_usable_size for malloc-using allocators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64128 --- Comment #4 from Eelis --- Yeah, I noticed that tcmalloc is also way faster, and since tcmalloc barely over-allocates for the sizes requested by vector, there is no benefit to using malloc_usable_size (which it also supports) there. So I think the bottom line is indeed: just don't use glibc malloc, because it's very slow.
[Bug middle-end/12086] memcmp(i,j,4) should use word (SI) subtraction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12086 --- Comment #13 from Eelis --- It's also worth noting that this affects operator== for std::array. :(
[Bug rtl-optimization/65371] arm loop with volatile variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65371 --- Comment #4 from Stuart --- The assembly generated from Comment #1 looks good. However, the assembly generated from Comment #3 hasn't improved, it still contains the unnecessary mov instruction on line 2 (mov r2, r3). The first instruction movs the address in to r3 and the second movs r3 in to r2. The instruction at label .L2 loads data in to r3 from the address in r2, overwriting r3 and making the instruction on line 2 unnecessary... I would have expected to see: func: @ args = 0, pretend = 0, frame = 0 @ frame_needed = 0, uses_anonymous_args = 0 @ link register save eliminated. mov r2, #1073741824 ldr r1, [r2] .L2: ldr r3, [r2] subsr3, r3, r1 uxthr3, r3 cmp r3, r0 bcc .L2 bx lr
[Bug bootstrap/42176] bootstrap fails while building libstdc++-v3 on debian sarge (related to cstdio and similar to #30915)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42176 --- Comment #2 from gcc-bugzilla at gehrels dot info 2010-10-02 16:20:01 UTC --- I can confirm this bug using gentoo linux: uname -a Linux vadmin631 2.6.26-2-xen-amd64 #1 SMP Tue Aug 31 11:17:26 UTC 2010 x86_64 Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz GenuineIntel GNU/Linux emerge --info (shortened) Portage 2.1.8.3 (default/linux/amd64/10.0/server, gcc-4.1.2, glibc-2.6.1-r0, 2.6.26-2-xen-amd64 x86_64) = System uname: linux-2.6.26-2-xen-amd64-x86_64-intel-r-_core-tm-2_quad_cpu_q66...@_2.40ghz-with-gentoo-1.12.13 Timestamp of tree: Sun, 26 Sep 2010 23:30:01 + app-shells/bash: 4.0_p37 dev-lang/python: 2.6.5-r3, 3.1.2-r4 sys-apps/baselayout: 1.12.13 sys-apps/sandbox:1.6-r2 sys-devel/autoconf: 2.65-r1 sys-devel/automake: 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc: 4.1.2 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6b sys-devel/make: 3.81-r2 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe" CHOST="x86_64-pc-linux-gnu" CXXFLAGS="-O2 -pipe" LDFLAGS="-Wl,-O1 -Wl,--as-needed" I tried to attach a build.log, but it is too large to be attached, so please contact me (or leave a note here), i will then send it by email.
[Bug bootstrap/42176] bootstrap fails while building libstdc++-v3 on debian sarge (related to cstdio and similar to #30915)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42176 --- Comment #3 from gcc-bugzilla at gehrels dot info 2010-10-02 16:22:48 UTC --- Oh, and, btw: The Version i was trying to compile was gcc-4.4.3
[Bug libstdc++/46332] New: __cxa_demangle yields excess parentheses for function types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46332
Summary: __cxa_demangle yields excess parentheses for function
types
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gcc-bugzi...@contacts.eelis.net
Consider:
#include
#include
#include
int main()
{
std::cout <<
abi::__cxa_demangle(typeid( void() ).name(), 0, 0, 0) << '\n';
}
The output is "void ()()", but it should really just be "void ()". If "void
()()" had any meaning at all, it would denote the type of a function returning
a function, but of course that's not valid C++.
The same problem can also be seen by trying to compile and link the following
program:
template void f();
int main() { f(); }
This produces:
undefined reference to `void f()'
Here, too, "void ()()" is wrong and should just be "void ()".
[Bug other/46332] __cxa_demangle yields excess parentheses for function types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46332 --- Comment #3 from Eelis 2010-11-09 17:26:40 UTC --- (In reply to comment #2) > I'm pretty sure to have seen this behavior mentioned already... You may be thinking of bug #36002. That one was about errors emitted during compilation, and has been fixed. This time it's about errors emitted during linking (and demangling explicitly). :)
[Bug c++/46466] New: [C++0X] ICE when using constexpr with -fno-elide-constructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46466
Summary: [C++0X] ICE when using constexpr with
-fno-elide-constructors
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gcc-bugzi...@contacts.eelis.net
Compiling
struct S { bool b; };
constexpr S f() { return S{true}; }
static_assert(f().b, "");
with
g++ -std=c++0x -fno-elide-constructors
results in
t.cpp:3:26: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
Omitting -fno-elide-constructors makes the problem go away.
I'm using GCC svn r166710.
[Bug c++/59832] [c++11] ICE in reshape_init_class with initializer list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59832
gcc-bugzilla at zulan dot net changed:
What|Removed |Added
CC||gcc-bugzilla at zulan dot net
--- Comment #12 from gcc-bugzilla at zulan dot net ---
This shows the same error (tested with gcc 6.1.1):
#include
template
void foo(T bar) {
constexpr auto baz = std::array{{1}};
}
int main() {
foo(13);
}
[Bug c++/71173] [6/7 regression] Qualified name lookup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71173 --- Comment #6 from gcc-bugzilla at zulan dot net --- As far as I can tell it is fixed. Tested with Archlinux "6.1.1" which seems to be git/1bbd3999).
[Bug libstdc++/71945] New: Integer overflow in use counter of shared pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71945
Bug ID: 71945
Summary: Integer overflow in use counter of shared pointers
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at chwress dot at
Target Milestone: ---
Created attachment 38942
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38942&action=edit
A small program demonstrating the issue
We (Fabian Yamaguchi, Christian Wressnegger, and Alwin Maier) would like
to report an integer overflow of the use counter in the `share_pointer`
object of the Standard C++ Libraries version 5.4, 6.1 and before.
Exploiting the flaw requires some very specific prerequisites to be met,
a successful attempt however allows an attacker to execute code.
Consequently, this might be worth addressing.
The following conditions must hold true in order to trigger the
overflow:
(1) The target is compiled and runs on an architecture where
sizeof(size_t) is larger than sizeof(int), e.g. 64 bit systems with the
LP64 (Linux/ BSD) or LLP64 (Windows) data model in order to allocate
more UINT_MAX Objects.
(2) The attacker is capable of triggering the creation of a multitude of
shared objects.
(3) The attacker can make one of these shared pointers go out of scope,
e.g., by instructing the system to remove a state object.
The following short program (shared_ptr_overflow.cpp) demonstrates the
bug: First, we create a shared pointer referencing a minimal class
`MyClass`. Second, 0x more references are created which results
in the use counter to flip over to 0 again. Finally, we add one more
reference (use counter is incremented to 1) and make one of the shared
pointers go out of scope. As a result the use counter is decremented to
0 and the contained object is freed, leaving 0x shared pointer
object behind, that still reference that memory region.
Subsequently, an attacker may allocate memory containing arbitrary data
such as executable code to take the place of the freed object and make
all references left behind point to that piece of data.
--- snip (shared_ptr_overflow.cpp)
//#define HAS_ENOUGH_MEMORY
int main()
{
std::cout << "1) Create an object and pass it over to a shared pointer..."
<< std::endl;
// We initialize the object on the heap and set x to 10.
shared_ptr ptr(new MyClass(10));
std::cout << " ptr.use_count() -> " << ptr.use_count() << std::endl;
// use-count is 1
const size_t numPtrs = (size_t) 0x;
#ifdef HAS_ENOUGH_MEMORY
std::cout << "2) Create 0x" << std::hex << numPtrs << " more references to
that object..." << std::endl;
std::vector> v(numPtrs);
for (size_t i = 0; i < numPtrs; i++)
{
v[i] = ptr;
}
std::cout << " ptr.use_count() -> " << ptr.use_count() << std::endl;
// use-count is 0
std::cout << "3) Create one more reference..." << std::endl;
{
shared_ptr ptr2 = ptr;
std::cout << " ptr.use_count() -> " << ptr.use_count() << std::endl;
// use-count is 1
std::cout << "4) That last reference goes out of scope again now..." <<
std::endl;
}
#else
{
std::cout << "2) Create an extra reference to that object..." <<
std::endl;
shared_ptr ptr2 = ptr;
std::cout << " ptr.use_count() -> " << ptr.use_count() << std::endl;
// use-count is 2
std::cout << "3) Emulate 0x" << std::hex << numPtrs << " more
references to that object..." << std::endl;
for(size_t i = 0; i < numPtrs; i++){
memset(&ptr, '\0', sizeof(shared_ptr));
ptr = ptr2;
}
std::cout << " ptr.use_count() -> " << ptr.use_count() << std::endl;
// use-count is 1
std::cout << "4) One reference goes out of scope again now..." <<
std::endl;
}
#endif
std::cout << " ptr.use_count() -> " << ptr.use_count() << std::endl;
// use-count is 0
std::cout << "5) We now spray the heap with 'A's to overwrite the freed
memory" << std::endl;
for(int i = 0; i < 1000; i++){
char *foo = new char[4];
memset(foo, 'A', 4);
}
// The address stored in ptr is still that of the free'd object
std::cout << " ptr: " << (void *) ptr.get() << std::endl;
// ptr->x is now 0x41414141
std::cout << " value:
[Bug c/77436] New: Incorrect constant result for summing loop inserted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77436 Bug ID: 77436 Summary: Incorrect constant result for summing loop inserted Product: gcc Version: 6.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: gcc-bugzilla at lucaswerkmeister dot de Target Milestone: --- Created attachment 39529 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39529&action=edit Preprocessed version of a small C program that sums up all integers from -(INT_MAX-1) to INT_MAX-1 (including both limits). The attached program computes the sum of all integers from -(INT_MAX-1) and INT_MAX-1. Since the lower limit is the additive inverse of the upper limit, all summands must cancel each other out and the result must be zero (this is still true with overflow). When compiled with -O0, that result is indeed printed. With -O1 and -O2, gcc optimizes the constant calculation and fills in the printf() call with the known result (though the loop is only removed on -O2); however, the inserted result is incorrect: instead of 0x, it is 0x8000 – the highest bit has been flipped. The bug appears to depend on the width of the summation window. Starting at INT_MIN + 32768 + 8192 + 4096 + 1024 + 256 + 2 and summing up to INT_MAX - 1 still exhibits the same bug; starting one later (+ 1) no longer does. Subtracting the same constant value from start and end does not change the result (provided the “shift” doesn’t cause overflow at the start). Output of gcc -v -save-temps -O1 gcc-bug.c: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /build/gcc-multilib/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --enable-libmpx --with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib --disable-werror --enable-checking=release Thread model: posix gcc version 6.1.1 20160802 (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/cc1 -E -quiet -v gcc-bug.c -mtune=generic -march=x86-64 -O1 -fpch-preprocess -o gcc-bug.i ignoring nonexistent directory "/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../x86_64-pc-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/include /usr/local/include /usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/include-fixed /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/cc1 -fpreprocessed gcc-bug.i -quiet -dumpbase gcc-bug.c -mtune=generic -march=x86-64 -auxbase gcc-bug -O1 -version -o gcc-bug.s GNU C11 (GCC) version 6.1.1 20160802 (x86_64-pc-linux-gnu) compiled by GNU C version 6.1.1 20160802, GMP version 6.1.1, MPFR version 3.1.4-p1, MPC version 1.0.3, isl version 0.15 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C11 (GCC) version 6.1.1 20160802 (x86_64-pc-linux-gnu) compiled by GNU C version 6.1.1 20160802, GMP version 6.1.1, MPFR version 3.1.4-p1, MPC version 1.0.3, isl version 0.15 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 0344da0e3652e90e95fdb0223debdba9 COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-mtune=generic' '-march=x86-64' as -v --64 -o gcc-bug.o gcc-bug.s GNU assembler version 2.27 (x86_64-pc-linux-gnu) using BFD version (GNU Binutils) 2.27 COMPILER_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/ LIBRARY_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/collect2 -plugin /usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/liblto_plugin.so -plugin-opt=/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/lto
[Bug c/77436] Incorrect constant result for summing loop inserted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77436 --- Comment #3 from Lucas Werkmeister --- Sorry, I wasn’t aware that wrapping is defined but overflow isn’t. The bug also happens if the summand type is changed to long (or, precisely, int64_t), where overflow shouldn’t happen (we’re adding at most 2^31 integers with the same sign, each of which doesn’t exceed 2^31 in magnitude, so 2^63 should be enough for the sum).
[Bug c++/30111] New: Value-initialization of POD base class doesn't initialize members
#include
int main()
{
struct pod {
int i;
};
struct inherit : pod {
inherit() : pod() {}
};
struct compose {
compose() : p() {}
pod p;
};
inherit i;
compose c;
std::cout << i.i << std::endl;
std::cout << c.p.i << std::endl;
}
In both cases the pod object is explicitly value-initialized, which according
to 8.5para5 means that "every non-static data member ... is value-initialized"
compose::pod::i is value-initialised, inherit::i is not. This can be seen from
the values printed out for i.i and by using Purify.
Same result with GCC 4.1.1, 3.4.3, 3.3.4 on Solaris 9, GCC 3.4.3 on AIX 5/3
Valgrind is being weird so I can't test it on Linux, butI don't think it's
platform-dependent.
--
Summary: Value-initialization of POD base class doesn't
initialize members
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at kayari dot org
GCC target triplet: sparc-sun-solaris2.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30111
[Bug c++/30111] Value-initialization of POD base class doesn't initialize members
--- Comment #1 from gcc-bugzilla at kayari dot org 2006-12-07 18:03 --- Values printed out confirm it on Linux for 3.3.5 20050117 (prerelease) (SUSE Linux), and official FSF 3.4.3, 4.0.1, 4.0.2, 4.1.1 N.B. I meant AIX 5.3, not 5/3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30111
[Bug c++/30111] Value-initialization of POD base class doesn't initialize members
--- Comment #4 from gcc-bugzilla at kayari dot org 2006-12-08 10:36 --- Richard, there's no difference between pod() and p() in this case, both are value-initialisations of a POD class, therefore all non-static data members should be value-initialised. I cited 8.5p5 for good reason :) Sun CC 6.1 and 8 and IBM xlC 6 get this right. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30111
[Bug target/28146] -O2 produces invalid code on s390-linux-gnu: gcc-4.1.2 20060608
--- Comment #2 from list+gcc-bugzilla at meyering dot net 2006-06-23 19:58 --- Created an attachment (id=11734) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11734&action=view) preprocessed input Here's the same j.i file, as an attachment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28146
[Bug target/28146] -O2 produces invalid code on s390-linux-gnu: gcc-4.1.2 20060608
--- Comment #4 from list+gcc-bugzilla at meyering dot net 2006-06-23 20:26 --- Created an attachment (id=11735) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11735&action=view) Here's the output of running gcc -I.. -I. -g -O2 ~/j.c -v Here's the output of running gcc -I.. -I. -g -O2 ~/j.c -v -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28146
[Bug c++/35099] New: [OpenMP] ICE in remove_unreachable_regions with -O -fopenmp
g++ on the trunk (revision 132140) produces ICE when compiling the attached
test1.ii. I tried to reduce the code but I couldn't.
$ g++-4.3 -E test.cpp -o test1.ii
$ g++-4.3 -O -fopenmp test1.ii
hoge.cpp: In function 'void
_Z15test_learnervecP15EnvironmentBaseRSt6vectorIP11LearnerBaseSaIS3_EEiSs.omp_fn.0(void*)':
hoge.cpp:85: internal compiler error: in remove_unreachable_regions, at
except.c:693
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
[EMAIL PROTECTED]:~/src/tdn$ g++-4.3 -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --prefix=/home/mak/local --program-suffix=-4.3 :
(reconfigured) ../configure --prefix=/home/mak/local --program-suffix=-4.3
CPPFLAGS=-I/home/mak/local/include LDFLAGS=-L/home/mak/local/lib
--enable-languages=c,c++,fortran,java,objc --no-create --no-recursion
Thread model: posix
gcc version 4.3.0 20080206 (experimental) (GCC)
--
Summary: [OpenMP] ICE in remove_unreachable_regions with -O -
fopenmp
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: t-gcc-bugzilla at snowelm dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35099
[Bug c++/35099] [OpenMP] ICE in remove_unreachable_regions with -O -fopenmp
--- Comment #1 from t-gcc-bugzilla at snowelm dot com 2008-02-06 08:03 --- Created an attachment (id=15103) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15103&action=view) Testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35099
[Bug c++/35370] New: Visibility of member of base template class lacking in derived template class
Please forgive me if in fact this is standards-compliant behavior.
Code:
template class B
{
protected:
int f;
};
template class D : public B
{
public:
void a() { this->f = 0; } // OK
void b() { f = 0; } // `f' was not declared in this scope
};
Compiled with command (gcc 4.2.1 as distributed on Ubuntu):
gcc-4.2 -c foo.cc
Produces error:
foo.cc: In member function void D::b():
foo.cc:11: error: f was not declared in this scope
Expected behavior:
Successful compilation (or, if this is in fact not legal, perhaps a more
specific diagnostic message)
--
Summary: Visibility of member of base template class lacking in
derived template class
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at meta-dynamic dot com
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35370
[Bug target/94504] New: On powerpc, -ffunction-sections -fdata-sections is not as effective as expected for PIE executables.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94504
Bug ID: 94504
Summary: On powerpc, -ffunction-sections -fdata-sections is not
as effective as expected for PIE executables.
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at mkarcher dot dialup.fu-berlin.de
Target Milestone: ---
I try to compile the following test program using
gcc -ffunction-sections -fdata-sections -pie -Wl,--gc-sections input.c
The linking step fails, because g is not defined. On most architectures except
powerpc (32 bit), the garbage collection is able to discard both fptr and f,
and so the reference to g vanishes. This is not the case on powerpc, where f is
referencing fptr through a GOT entry in the .got2 section.
This issue (I don't dare to call it "bug" yet) is the cause of of
https://bugs.debian.org/955845. The librsvg build process is quirky and
building the tests only works if garbage collection is able to collect a hughe
amount of dead code. Garbage collection is able to do that on all architectures
Debian tried it on except for powerpc (and possibly ppc64, see
https://bugs.debian.org/895723). The attached example program does compile fine
on ppc64, though.
/* dead code */
extern void g(int x, ...);
extern void (*fptr)();
void f()
{
/* using fptr creates a GOT entry for fptr */
g(0, fptr);
}
/* fptr is reference from the GOT. Let's reference f from fptr */
void (*fptr)() = f;
/* Non-dead code */
int x = 5;
int main(void)
{
/* using x goes through the GOT. This prevents the GC to kill it */
return x;
}
[Bug target/94504] On powerpc, -ffunction-sections -fdata-sections is not as effective as expected for PIE executables.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94504 --- Comment #3 from Michael Karcher --- (In reply to Richard Biener from comment #2) > Huh, looking at the assembly & the object file this seems to be fully a linker > issue who seems to be responsible for building the GOT. I suggest to move > this over to sourceware. Alan? I'm not so sure about this. I think it might actually be a limitation of ELF on ppc32: If I compare the code generated by gcc on ppc32, gcc does output a GOT fragment in the .got2 section that references all globals that are used in the current object: $ objdump -r -j .got2 bla32.o bla32.o: file format elf32-powerpc RELOCATION RECORDS FOR [.got2]: OFFSET TYPE VALUE R_PPC_ADDR32 fptr 0004 R_PPC_ADDR32 x This section can not be elided, because it is referenced from main: $ objdump -r -j .text.main bla32.o bla32.o: file format elf32-powerpc RELOCATION RECORDS FOR [.text.main]: OFFSET TYPE VALUE 0022 R_PPC_REL16_HA.got2+0x8006 0026 R_PPC_REL16_LO.got2+0x800a The linker has no obvious way to detect which GOT slots are actually used inside main, because the offset(s) of the slot(s) inside .got2 used by main are hardcoded inside main. On the other hand, on ppc64, there is no GOT fragment generated by the compiler, but instead the compiler just asks the linker to create a GOT slot and fill in the necessary information: $ objdump -r -j .text.main bla64.o bla64.o: file format elf64-powerpc RELOCATION RECORDS FOR [.text.main]: OFFSET TYPE VALUE 000e R_PPC64_TOC16_HA x 0012 R_PPC64_TOC16_LO x
[Bug target/94504] On powerpc, -ffunction-sections -fdata-sections is not as effective as expected for non-PIE executables.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94504 --- Comment #5 from Michael Karcher --- I got the command line of gcc wrong. "-pie" just sets the linker flags for PIE linking, but it does *not* compile source code as PIE. If I use "-fpie", garbage collection does what it is supposed to do. As I found out, the acutal problem I have is completely unrelated to gcc (sorry for the noise here), because it concerns object files created by rustc (which has an llvm backend) linked by binutil's ld tool. At the moment I was able to reproduce the same symptom I have with those rust objects with a ten-line C program, I considered fixing the problem (if possible) for C first a good idea. As it stands now, the issue in gcc (no effective garbage collection for non-PIE executables with function pointers in global data structures) still stands, so I am not closing the bug right away.
[Bug analyzer/95152] New: internal compiler error: in get_or_create_mem_ref, at analyzer/region-model.cc:6938
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95152 Bug ID: 95152 Summary: internal compiler error: in get_or_create_mem_ref, at analyzer/region-model.cc:6938 Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: pieter+gcc-bugzilla at plexis dot eu Target Milestone: --- Created attachment 48545 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48545&action=edit The pre-processed source While compiling dnsdist[1] from git with '-fanalyzer', GCC 10.1.0 has an internal compiler error: during IPA pass: analyzer In file included from dnsdist.hh:24, from dnsdist-lua-bindings.cc:23: ext/luawrapper/include/LuaContext.hpp: In lambda function: ext/luawrapper/include/LuaContext.hpp:1241:27: internal compiler error: in get_or_create_mem_ref, at analyzer/region-model.cc:6938 1241 | writeFunction_(*object, value); | ~~^~~~ Please submit a full bug report, with preprocessed source if appropriate. The full commandline is as follows: g++ -DHAVE_CONFIG_H -I. -I. -I. -pthread -I/usr/include/luajit-2.0 -I/usr/include/editline-I./ext/yahttp -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -DNETSNMP_ENABLE_IPV6 -fno-strict-aliasing -DNETSNMP_REMOVE_U64 -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -Ulinux -Dlinux=linux -D_REENTRANT -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -I/usr/lib/perl5/5.30/core_perl/CORE -I/usr/include/libnl3 -D_FORTIFY_SOURCE=2 -I. -I/usr/include -DSYSCONFDIR=\"/usr/local/etc\" -fPIE -DPIE -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 --param ssp-buffer-size=4 -fstack-protector -g -O3 -Wall -Wextra -Wshadow -Wno-unused-parameter -Wmissing-declarations -Wredundant-decls -fanalyzer -MT dnsdist-lua-bindings.o -MD -MP -MF $depbase.Tpo -c -o dnsdist-lua-bindings.o dnsdist-lua-bindings.cc This is a ArchLinux system, where 'g++ -v' shows this: Using built-in specs. COLLECT_GCC=/usr/bin/g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl --with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit --enable-cet=auto --enable-checking=release --enable-clocale=gnu --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch --disable-libunwind-exceptions --disable-werror gdc_include_dir=/usr/include/dlang/gdc Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 10.1.0 (GCC) The triggering line is in the LuaWrapper[2], a project that can wrap C++ objects and to Lua. I have attached the pre-processed source. If you need more information, let me know! 1 - https://dnsdist.org 2 - https://github.com/PowerDNS/pdns/blob/134755f54093a595610e035d01a07f125df3ab13/ext/luawrapper/include/LuaContext.hpp#L1241
[Bug c++/56215] New: Cannot create constexpr struct with unnamed unions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56215
Bug #: 56215
Summary: Cannot create constexpr struct with unnamed unions
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: t-gcc-bugzi...@snowelm.com
Similar to PR c++/51675, but the trunk GCC fails to compile the following code:
--
struct foo {
union
{
int x;
short y;
};
constexpr foo() : x( 0 ) { }
};
--
$ g++ --std=c++11 hoge.cpp
hoge.cpp: In constructor ‘constexpr foo::foo()’:
hoge.cpp:7:33: error: uninitialized member ‘foo::’ in ‘constexpr’
constructor
constexpr foo() : x( 0 ) { }
^
What I actually want to do is a specialization of std::pair to provide
efficient comparison. Since this requires an unnamed struct within an unnamed
union, and
the bug seems very sensitive to details like that, I put the code too.
GCC trunk also fails compiling the following.
--
#include
#include
namespace std {
template <>
struct pair< uint32_t, uint32_t > {
union
{
struct {
uint32_t first;
uint32_t second;
};
uint64_t paired;
};
constexpr pair() : paired( ) { }
constexpr pair(uint32_t a, uint32_t b) : first(a), second(b) { }
};
constexpr bool operator==
( pair a, pair b )
{
return a.paired == b.paired;
}
constexpr bool operator<
( pair a, pair b )
{ // only for little endian
return ((a.paired<<32)|(a.paired>>32)) < ((b.paired<<32)|(b.paired>>32));
}
} // namespace
std::pair x(1, 2);
--
[Bug c++/56323] New: [C++11] cannot compile inherited constructor for typedef'ed base class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56323
Bug #: 56323
Summary: [C++11] cannot compile inherited constructor for
typedef'ed base class
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: t-gcc-bugzi...@snowelm.com
Consider the following code that uses inherited constructor from a typedef'ed
type:
struct A {
A(int i);
};
typedef A B;
struct C : B {
using B::B; // compile error by gcc
};
struct D : B {
using B::A; // this is compiled as inherited constructor
};
C c(0);
D d(0);
I believe that C should be valid, while D should be reported as invalid.
However I cannot find anything about this problem in the C++11 standard...
In template programming, using inherited constructor is sometimes virtually
impossible, as in the following example.
struct A {
A(int i);
};
template
struct E {
typedef T type;
};
template
struct F : E::type {
using E::type::type; // error: E::type is a typedef
};
F f(0);
[Bug sanitizer/56393] New: SIGSEGV when -fsanitize=address and dynamic lib with global objects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56393
Bug #: 56393
Summary: SIGSEGV when -fsanitize=address and dynamic lib with
global objects
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: t-gcc-bugzi...@snowelm.com
CC: do...@gcc.gnu.org, dvyu...@gcc.gnu.org,
ja...@gcc.gnu.org, k...@gcc.gnu.org
Created attachment 29493
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29493
gdb session log
When linked with a dynamic library with a globally initialized class object, a
compiled code with address sanitizer dies with SIGSEGV. I think this is a
typical usecase...
Test case:
(boost 1.53 was installed with --build-type=complete.
tested by libs compiled with g++ 4.7.2 as well as libs compiled with head gcc)
-
#include
#include
int main() {
printf("hello\n");
boost::upgrade_mutex m;
}
--
$ g++ -g -fsanitize=address -I/usr/local/include hoge2.cpp -o a.out
-lboost_thread -lboost_system
$ ./a.out
Segmentation fault (core dumped)
The segfault is before the printf.
Without -fsanitize=address it runs normally. If the program is linked with
static libs (-lboost_thread-mt-s -lboost_system-mt-s), it runs normally.
Note that the libraries are compiled without -fsanitize=address.
I investigated the situation by gdb (with -lboost_thread-mt-d
-lboost_system-mt-d). Please see the attached log.
For me it seems that some initializer in the shared lib kicks sanitized code of
some object constructor before the sanitizer gets ready.
[Bug sanitizer/56393] SIGSEGV when -fsanitize=address and dynamic lib with global objects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56393 --- Comment #2 from Takaki Makino 2013-02-19 14:02:13 UTC --- Thanks Kostya. Unfortunately -static-libasan didn't help: $ g++ -g -fsanitize=address -I/usr/local/include hoge2.cpp -o a.out -lboost_thread-mt-d -lboost_system-mt-d -static-libasan $ ./a.out Segmentation fault (core dumped
[Bug sanitizer/56393] SIGSEGV when -fsanitize=address and dynamic lib with global objects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56393 --- Comment #4 from Takaki Makino 2013-02-19 15:22:38 UTC --- Created attachment 29499 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29499 reduced testcase I tried to made a fairly reduced testcase from boost. Attached please find the tarball. make CXX=/your/head/gcc two programs are built and run. The statically linked one, a.out.static, runs happily, while a.out.dynamic, the dynamically linked one, fails with SIGSEGV. Tested on linux x86_64.
[Bug sanitizer/56393] SIGSEGV when -fsanitize=address and dynamic lib with global objects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56393 --- Comment #5 from Takaki Makino 2013-02-19 15:26:41 UTC --- To reply Kostya's comment, As shown in the reduced testcase, the program crashes before ASAN_OPTIONS=verbosity=1 takes effect.
[Bug sanitizer/56393] SIGSEGV when -fsanitize=address and dynamic lib with global objects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56393 --- Comment #17 from Takaki Makino 2013-02-22 06:38:33 UTC --- (In reply to comment #15) > r196201 landed the fresh asan run-time into gcc. > -static-libasan should work well now, please try. It works for me, thank you very much for your efforts. Why don't you set -static-libasan as default? Because I still don't understand in which case dynamic libasan is useful...
[Bug sanitizer/56393] SIGSEGV when -fsanitize=address and dynamic lib with global objects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56393 --- Comment #20 from Takaki Makino 2013-02-22 09:01:30 UTC --- I understand why dynamic libasan is important. Still it seems for me -static-libasan can be default, except when -shared is given. (just because I have no idea how the shared case could be solved...)
