[Bug libstdc++/58605] atomicT::atomic() disobeys [atomics.types.operations.req]p4 for types with user-defined default constructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58605 --- Comment #2 from Jeffrey Yasskin jyasskin at gcc dot gnu.org --- Thanks, Daniel. I think it would be totally reasonable to call this a bug in C++ rather than a bug in libstdc++.
[Bug libstdc++/58605] New: atomicT::atomic() disobeys [atomics.types.operations.req]p4 for types with user-defined default constructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58605
Bug ID: 58605
Summary: atomicT::atomic() disobeys
[atomics.types.operations.req]p4 for types with
user-defined default constructors
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: jyasskin at gcc dot gnu.org
[atomics.types.operations.req]p4 says:
A::A() noexcept = default;
Effects: leaves the atomic object in an uninitialized state. [ Note: These
semantics ensure compatibility
with C. — end note ]
http://gcc.gnu.org/viewcvs/gcc/trunk/libstdc%2B%2B-v3/include/std/atomic?revision=201315view=markup#l160
includes:
templatetypename _Tp
struct atomic
{
private:
_Tp _M_i;
If _Tp has a non-trivial default constructor, this will cause atomic_Tp's
default constructor to initialize the member. Using a bare member also adds
requirements on the signature of _Tp::_Tp(), in particular that it must now be
noexcept.
libc++ handles this by defining a mutable _Atomic(_Tp) member instead:
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/atomic?revision=180945view=markup#l558
[Bug c++/52119] [C++11] overflow in signed left shift isn't diagnosed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52119 --- Comment #12 from Jeffrey Yasskin jyasskin at gcc dot gnu.org --- http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3675.html#1457 changed this between C++11 and C++14.
[Bug c++/52119] [C++11] overflow in signed left shift isn't diagnosed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52119 --- Comment #14 from Jeffrey Yasskin jyasskin at gcc dot gnu.org --- Whoops, I missed your comment 7 where you already knew the history. Sorry.
[Bug rtl-optimization/56511] New: memcpy misses chance to use AVX instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56511
Bug #: 56511
Summary: memcpy misses chance to use AVX instructions
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jyass...@gcc.gnu.org
When operating on sufficiently aligned storage, memcpy should be able to use
vector instructions.
$ cat test.c
#include string.h
typedef float vec __attribute__((vector_size(32)));
typedef struct S {
vec v;
char __attribute__((aligned(__alignof__(vec c[sizeof(vec)];
} S;
void assign_vec(S* s, const vec* v) { s-v = *v; }
void memcpy_vec(S* s, const vec* v) { memcpy(s-v, v, sizeof(vec)); }
void memcpy_char(S* s, const vec* v) { memcpy(s-c, v, sizeof(vec)); }
$ gcc -mavx -S test.c -O2 -Wall -o -
.file test.c
.text
.p2align 4,,15
.globl assign_vec
.type assign_vec, @function
assign_vec:
.LFB12:
.cfi_startproc
vmovaps (%rsi), %ymm0
vmovaps %ymm0, (%rdi)
vzeroupper
ret
.cfi_endproc
.LFE12:
.size assign_vec, .-assign_vec
.p2align 4,,15
.globl memcpy_vec
.type memcpy_vec, @function
memcpy_vec:
.LFB13:
.cfi_startproc
movq(%rsi), %rax
movq%rax, (%rdi)
movq8(%rsi), %rax
movq%rax, 8(%rdi)
movq16(%rsi), %rax
movq%rax, 16(%rdi)
movq24(%rsi), %rax
movq%rax, 24(%rdi)
ret
.cfi_endproc
.LFE13:
.size memcpy_vec, .-memcpy_vec
.p2align 4,,15
.globl memcpy_char
.type memcpy_char, @function
memcpy_char:
.LFB14:
.cfi_startproc
movq(%rsi), %rdx
movq%rdx, 32(%rdi)
movq8(%rsi), %rdx
movq%rdx, 40(%rdi)
movq16(%rsi), %rdx
movq%rdx, 48(%rdi)
movq24(%rsi), %rdx
movq%rdx, 56(%rdi)
ret
.cfi_endproc
.LFE14:
.size memcpy_char, .-memcpy_char
I don't have a gcc-4.8 around to test with, but I believe it's also missing
this optimization.
[Bug rtl-optimization/56511] memcpy misses chance to use AVX instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56511 --- Comment #1 from Jeffrey Yasskin jyasskin at gcc dot gnu.org 2013-03-03 06:19:57 UTC --- LLVM catches this optimization.
[Bug c++/53524] [4.7/4.8 Regression] Bogus and unsupressable enum comparison warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53524 Jeffrey Yasskin jyasskin at gcc dot gnu.org changed: What|Removed |Added CC||jyasskin at gcc dot gnu.org --- Comment #2 from Jeffrey Yasskin jyasskin at gcc dot gnu.org 2012-05-30 02:25:26 UTC --- I think Paul's arguing that you shouldn't warn on test ? anon_enum_1 : anon_enum_2. The result is defined by [expr.cond]p6 to be the common type of the two enum types (often 'int'), and if the pattern is widely used, then it's probably not a good idea to warn about it by default. And, of course, it's always a bad idea to have a warning that users can't turn off. I haven't investigated what types PT1BitsAv and PT2BitsAv are supposed to have before the enum is closed, but if they're the same as their initializers, then the above argument holds.
[Bug libstdc++/53429] libstdc++ should guarantee not to expose complex::{imag,real} so it supports both C++98 and C++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53429
Jeffrey Yasskin jyasskin at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|NEW
Last reconfirmed||2012-05-22
CC||gdr at gcc dot gnu.org
Resolution|INVALID |
Summary|complex::{imag,real} should |libstdc++ should guarantee
|be marked alwaysinline to |not to expose
|guarantee libstdc++ binary |complex::{imag,real} so it
|compatibility between C++98 |supports both C++98 and
|and C++11 |C++11
Ever Confirmed|0 |1
--- Comment #5 from Jeffrey Yasskin jyasskin at gcc dot gnu.org 2012-05-22
12:58:14 UTC ---
Specializing operator sounds fine too. Adding Gaby for his opinion, and
reopening since I'm not sure Richard understood the request.
[Bug libstdc++/53429] complex::{imag,real} should be marked alwaysinline to guarantee libstdc++ binary compatibility between C++98 and C++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53429 --- Comment #3 from Jeffrey Yasskin jyasskin at gcc dot gnu.org 2012-05-21 15:30:45 UTC --- Richard, I'm not asking that it be possible to link together code compiled in C++98 and C++11 mode. I'm asking that gcc be able to build in C++11 mode at all. If libstdc++.so exposed the c++98 version of complex::real(), then all C++11 programs that used complex would be potentially broken. Another way to fix this would, of course, be to either expose a configuration option to build libstdc++.so in C++11 mode or to install two different .so files in parallel, but doing that seems unnecessarily hostile to users when it would be pretty easy to guarantee that the one .so works for both versions of the language.
[Bug libstdc++/53429] New: complex::{imag,real} should be marked alwaysinline to guarantee libstdc++ binary compatibility between C++98 and C++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53429
Bug #: 53429
Summary: complex::{imag,real} should be marked alwaysinline to
guarantee libstdc++ binary compatibility between C++98
and C++11
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jyass...@gcc.gnu.org
The non-const overloads of std::complex::real and std::complex::imag go from
returning _Tp to _Tp in C++98 vs C++11:
http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/include/std/complex?view=markup.
libstdc++ includes explicit instantiations of operator and operator with
complex arguments:
http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/src/c%2B%2B98/complex_io.cc?view=markup.
These operator and operator overloads call complex::real() and
complex::imag(). If those calls are inlined (which is likely), so that no weak
definition of real() and imag() is exposed to users of the library, then I
believe all is well. However, if the compiler decides not to inline them, then
people linking libstdc++ from the other version of the language may wind up
with two conflicting weak definitions of the symbols.
I think marking them as alwaysinline would guarantee compatibility.
[Bug libstdc++/53429] complex::{imag,real} should be marked alwaysinline to guarantee libstdc++ binary compatibility between C++98 and C++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53429
--- Comment #1 from Jeffrey Yasskin jyasskin at gcc dot gnu.org 2012-05-21
04:03:26 UTC ---
So far, this is purely a theoretical incompatibility. I haven't actually seen a
compiled libstdc++.so that exposes a version-specific complex::{imag,real}.
[Bug c/37743] Bogus printf format warning with __builtin_bswap32.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37743
Jeffrey Yasskin jyasskin at gcc dot gnu.org changed:
What|Removed |Added
CC||jyasskin at gcc dot gnu.org
--- Comment #7 from Jeffrey Yasskin jyasskin at gcc dot gnu.org 2012-05-01
20:45:33 UTC ---
This also causes the result of __builtin_bswap32 to fail overload resolution:
$ cat test.cc
void foo(unsigned int x);
void foo(int x);
void bar(long long x) {
foo(__builtin_bswap32(x));
}
$ g++-4.8pre -c test.cc
test.cc: In function ‘void bar(long long int)’:
test.cc:5:27: error: call of overloaded ‘foo(unsigned int)’ is ambiguous
test.cc:5:27: note: candidates are:
test.cc:1:6: note: void foo(unsigned int)
test.cc:2:6: note: void foo(int)
$ g++-4.8pre --version
g++-4.8pre (GCC) 4.8.0 20120330 (experimental)
It's not terribly important to me: a wrapper can easily cast to the expected
type.
[Bug c/37743] Bogus printf format warning with __builtin_bswap32.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37743 --- Comment #8 from Jeffrey Yasskin jyasskin at gcc dot gnu.org 2012-05-01 20:47:00 UTC --- Arguably, the bad diagnostic (reporting unsigned int!=unsigned int) is more serious than the bswap bug, since it may show up for other functions.
[Bug c++/52538] Extend C++11 UDLs to be compatible with inttypes.h macros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52538 --- Comment #4 from Jeffrey Yasskin jyasskin at gcc dot gnu.org 2012-04-27 17:47:30 UTC --- Is this ok for gcc-4_7-branch too? The other bug reports Jonathan mentioned won't be helped by a fix that skips 4.7.
[Bug c++/52145] [C++11] [DR 903] zero-valued integer constant expression should prefer conversion to pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52145 Jeffrey Yasskin jyasskin at gcc dot gnu.org changed: What|Removed |Added Status|SUSPENDED |NEW CC||jyasskin at gcc dot gnu.org --- Comment #3 from Jeffrey Yasskin jyasskin at gcc dot gnu.org 2012-04-26 19:42:19 UTC --- A simpler test case is: $ cat test.cc const long kNullPtr = 0; const long* ptr = kNullPtr; $ g++-4.7pre -c test.cc -std=gnu++11 test.cc:2:19: error: invalid conversion from ‘long int’ to ‘const long int*’ [-fpermissive] $ g++-4.7pre --version g++-4.7pre (GCC) 4.7.1 20120412 (prerelease) I'm going to unsuspend this because DR903 is ready, and gcc-4.7's behavior doesn't match either the proposed wording or the current definition of C++11. The proposed wording discusses a change to C++17 rather than to C++11 (we can tell because it adds a C.3 C++ and ISO C++ 2011 section), so the new error should only show up under -std=gnu++17, and be a warning in -std=gnu++11.
[Bug c++/52145] [C++11] [DR 903] zero-valued integer constant expression should prefer conversion to pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52145 --- Comment #5 from Jeffrey Yasskin jyasskin at gcc dot gnu.org 2012-04-26 23:06:05 UTC --- 17 was the rough consensus at Kona for the target for the next standard. You could use -std=c++1y or c++1x or whatever instead.
[Bug c++/53132] New: Missing top level in diagnostic's instantiation stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53132
Bug #: 53132
Summary: Missing top level in diagnostic's instantiation stack
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jyass...@gcc.gnu.org
gcc-4.7's diagnostic about a private copy constructor skips some levels in the
template instantiation stack:
$ cat test.cc
#include utility
class Uncopyable { // 2
public:
Uncopyable() = default;
private:
Uncopyable(const Uncopyable); // 6
};
class ContainsUncopyable {
std::pairUncopyable, int pv; // 9
};
void foo() {
ContainsUncopyable c; // 12
}
$ g++-4.7pre -c -std=c++11 test.cc
.../include/c++/4.7.1/type_traits: In substitution of ‘templateclass _From1,
class _To1 static decltype ((__test_aux_To1(declval_From1()),
std::__sfinae_types::__one())) std::__is_convertible_helper_From, _To,
false::__test(int) [with _From1 = _From1; _To1 = _To1; _From = const
Uncopyable; _To = Uncopyable] [with _From1 = const Uncopyable; _To1 =
Uncopyable]’:
.../include/c++/4.7.1/type_traits:1258:70: required from ‘constexpr const
bool std::__is_convertible_helperconst Uncopyable, Uncopyable, false::value’
.../include/c++/4.7.1/type_traits:1263:12: required from ‘struct
std::is_convertibleconst Uncopyable, Uncopyable’
.../include/c++/4.7.1/type_traits:116:12: required from ‘struct
std::__and_std::is_convertibleconst Uncopyable, Uncopyable,
std::is_convertibleconst int, int ’
.../include/c++/4.7.1/bits/stl_pair.h:113:38: required from here
test.cc:6:3: error: ‘Uncopyable::Uncopyable(const Uncopyable)’ is private
In file included from .../include/c++/4.7.1/bits/move.h:57:0,
from .../include/c++/4.7.1/bits/stl_pair.h:61,
from .../include/c++/4.7.1/utility:72,
from test.cc:1:
.../include/c++/4.7.1/type_traits:1252:2: error: within this context
# 3 more similar errors omitted
This diagnostic is less readable than it should be because it omits the code I
wrote at test.cc:9 or test.cc:12, which caused the template at stl_pair.h:113
to be instantiated.
I've only seen this in C++11 mode because the std::pair enable_if is only
present there.
$ g++-4.7pre --version
g++-4.7pre (GCC) 4.7.1 20120412 (prerelease)
[Bug c++/52145] [C++11] [DR 903] zero-valued integer constant expression should prefer conversion to pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52145 --- Comment #7 from Jeffrey Yasskin jyasskin at gcc dot gnu.org 2012-04-26 23:56:22 UTC --- Oops, I didn't actually realize you'd allocated an option for that in 4.8, and was just making one up. Sorry for the distraction.
[Bug c++/51213] [C++11][DR 1170] Access control checking has to be done under SFINAE conditions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51213
--- Comment #3 from Jeffrey Yasskin jyasskin at gcc dot gnu.org 2012-04-27
01:31:49 UTC ---
This looks like the root cause. along with r174464, of a regression in C++11
mode from 4.6-4.7 on the following program:
$ cat test.cc
#include utility
class Uncopyable { // 2
Uncopyable(const Uncopyable); // 3
public:
Uncopyable() = default;
};
struct ContainsUncopyable {
std::pairUncopyable, int pv; // 8
};
void foo() {
ContainsUncopyable c; // 11
}
$ ~/gcc-4.6-svn/bin/g++-4.6pre --version
g++-4.6pre (GCC) 4.6.4 20120412 (prerelease)
$ g++-4.6pre -c -std=c++0x test.cc
$ ~/gcc-4.7-svn/bin/g++-4.7pre --version
g++-4.7pre (GCC) 4.7.1 20120412 (prerelease)
$ g++-4.7pre -c -std=c++11 test.cc
.../include/c++/4.7.1/type_traits: In substitution of ‘templateclass _From1,
class _To1 static decltype ((__test_aux_To1(declval_From1()), std::__s
finae_types::__one())) std::__is_convertible_helper_From, _To,
false::__test(int) [with _From1 = _From1; _To1 = _To1; _From = const
Uncopyable; _To = Uncopyable] [with _From1 = const Uncopyable; _To1 =
Uncopyable]’:
.../include/c++/4.7.1/type_traits:1258:70: required from ‘constexpr const
bool std::__is_convertible_helperconst Uncopyable, Uncopyable, false::valu
e’
.../include/c++/4.7.1/type_traits:1263:12: required from ‘struct
std::is_convertibleconst Uncopyable, Uncopyable’
.../include/c++/4.7.1/type_traits:116:12: required from ‘struct
std::__and_std::is_convertibleconst Uncopyable, Uncopyable,
std::is_convertiblecon
st int, int ’
.../include/c++/4.7.1/bits/stl_pair.h:113:38: required from here
test.cc:3:3: error: ‘Uncopyable::Uncopyable(const Uncopyable)’ is private
In file included from .../include/c++/4.7.1/bits/move.h:57:0,
from .../include/c++/4.7.1/bits/stl_pair.h:61,
from .../include/c++/4.7.1/utility:72,
from test.cc:1:
.../include/c++/4.7.1/type_traits:1252:2: error: within this context
...
The workaround is to use =delete instead of access control to create
non-copyable classes in C++11 mode.
[Bug libstdc++/52822] [C++11] stable_partition destroys sequence due to inappropriate self-move-assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52822 --- Comment #9 from Jeffrey Yasskin jyasskin at gcc dot gnu.org 2012-04-12 20:59:14 UTC --- Author: jyasskin Date: Thu Apr 12 20:59:09 2012 New Revision: 186391 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186391 Log: Fix PR52822 (stable_partition move-assigns object to itself) by scanning for the first value that doesn't match the predicate before starting to rearrange values. 2012-04-03 Jeffrey Yasskin jyass...@google.com PR libstdc++/52822 * include/bits/stl_algo.h (__find_if_not): Expose in C++98 mode. (__find_if_not_n): Like __find_if_not, but works on and updates a counted range instead of a bounded range. (stable_partition): Guarantee !__pred(*__first) in call to __stable_partition_adaptive() or __inplace_stable_partition(). (__stable_partition_adaptive): Use new precondition to avoid moving/copying objects onto themselves. Guarantee new precondition to recursive calls. (__inplace_stable_partition): Use new precondition to simplify base case, remove __last parameter. Guarantee new precondition to recursive calls. * testsuite/25_algorithms/stable_partition/moveable.cc (test02): Test a sequence that starts with a value matching the predicate. * testsuite/25_algorithms/stable_partition/pr52822.cc: Test vectors, which have a destructive self-move-assignment. Added: trunk/libstdc++-v3/testsuite/25_algorithms/stable_partition/pr52822.cc - copied, changed from r186389, trunk/libstdc++-v3/testsuite/25_algorithms/stable_partition/moveable.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_algo.h trunk/libstdc++-v3/testsuite/25_algorithms/stable_partition/moveable.cc
[Bug libstdc++/52822] [C++11] stable_partition destroys sequence due to inappropriate self-move-assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52822
--- Comment #10 from Jeffrey Yasskin jyasskin at gcc dot gnu.org 2012-04-12
21:42:00 UTC ---
Author: jyasskin
Date: Thu Apr 12 21:41:55 2012
New Revision: 186394
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186394
Log:
Fix PR52822 (stable_partition move-assigns object to itself) by
scanning for the first value that doesn't match the predicate before
starting to rearrange values.
2012-04-03 Jeffrey Yasskin jyass...@google.com
PR libstdc++/52822
* include/bits/stl_algo.h (__find_if_not): Expose in
C++98 mode.
(__find_if_not_n): Like __find_if_not, but works on and updates a
counted range instead of a bounded range.
(stable_partition): Guarantee !__pred(*__first) in call to
__stable_partition_adaptive() or __inplace_stable_partition().
(__stable_partition_adaptive): Use new precondition to avoid
moving/copying objects onto themselves. Guarantee new
precondition to recursive calls.
(__inplace_stable_partition): Use new precondition to simplify
base case, remove __last parameter. Guarantee new precondition to
recursive calls.
* testsuite/25_algorithms/stable_partition/moveable.cc (test02):
Test a sequence that starts with a value matching the predicate.
* testsuite/25_algorithms/stable_partition/pr52822.cc:
Test vectors, which have a destructive self-move-assignment.
Added:
branches/gcc-4_7-branch/libstdc++-v3/testsuite/25_algorithms/stable_partition/pr52822.cc
- copied unchanged from r186391,
trunk/libstdc++-v3/testsuite/25_algorithms/stable_partition/pr52822.cc
Modified:
branches/gcc-4_7-branch/ (props changed)
branches/gcc-4_7-branch/libstdc++-v3/ChangeLog
branches/gcc-4_7-branch/libstdc++-v3/include/bits/stl_algo.h
branches/gcc-4_7-branch/libstdc++-v3/testsuite/25_algorithms/stable_partition/moveable.cc
Propchange: branches/gcc-4_7-branch/
('svn:mergeinfo' added)
[Bug libstdc++/52822] [C++11] stable_partition destroys sequence due to inappropriate self-move-assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52822 --- Comment #11 from Jeffrey Yasskin jyasskin at gcc dot gnu.org 2012-04-12 22:26:08 UTC --- Author: jyasskin Date: Thu Apr 12 22:26:02 2012 New Revision: 186396 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186396 Log: Fix PR52822 by explicitly checking for object identity before move-assigning. This is a simpler fix than was committed to 4.7 and 4.8. 2012-04-12 Jeffrey Yasskin jyass...@google.com PR libstdc++/52822 * include/bits/stl_algo.h (__stable_partition_adaptive): Avoid move-assigning an object to itself by explicitly testing for identity. * testsuite/25_algorithms/stable_partition/pr52822.cc: Test vectors, which have a destructive self-move-assignment. * testsuite/25_algorithms/stable_partition/moveable.cc (test02): Test with rvalstruct, which explicitly checks self-move-assignment. Added: branches/gcc-4_6-branch/libstdc++-v3/testsuite/25_algorithms/stable_partition/pr52822.cc Modified: branches/gcc-4_6-branch/libstdc++-v3/ChangeLog branches/gcc-4_6-branch/libstdc++-v3/include/bits/stl_algo.h branches/gcc-4_6-branch/libstdc++-v3/testsuite/25_algorithms/stable_partition/moveable.cc
[Bug libstdc++/52822] [C++11] stable_partition destroys sequence due to inappropriate self-move-assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52822 Jeffrey Yasskin jyasskin at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #12 from Jeffrey Yasskin jyasskin at gcc dot gnu.org 2012-04-12 22:30:13 UTC --- Fixed for 4.6.4, 4.7.1 and 4.8. Sorry for the delay.
[Bug libstdc++/52822] [C++11] stable_partition destroys sequence due to inappropriate self-move-assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52822 --- Comment #7 from Jeffrey Yasskin jyasskin at gcc dot gnu.org 2012-04-02 16:41:41 UTC --- Sounds good. Will send the patches to the list, probably tomorrow. Thanks!
[Bug libstdc++/52822] New: [C++11] stable_partition destroys sequence due to inappropriate self-move-assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52822
Bug #: 52822
Summary: [C++11] stable_partition destroys sequence due to
inappropriate self-move-assignment
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jyass...@gcc.gnu.org
The following test program should print 1 twice, since stable_partition is
only supposed to rearrange values, not modify them.
$ cat test.cc
#include vector
#include utility
#include algorithm
#include iostream
using namespace std;
bool pred(const vectorint) { return true; }
int main() {
vectorvectorint v(1);
v[0].push_back(7);
cout v[0].size() '\n';
stable_partition(v.begin(), v.end(), pred);
cout v[0].size() '\n';
}
$ g++-4.6pre --version
g++-4.6pre (GCC) 4.6.4 20120330 (prerelease)
$ g++-4.6pre -std=c++98 -g3 test.cc -o test ./test
1
1
$ g++-4.6pre -std=c++0x -g3 test.cc -o test ./test
1
0
$ g++-4.7pre --version
g++-4.7pre (GCC) 4.7.1 20120330 (prerelease)
$ g++-4.7pre -std=c++0x -g3 test.cc -o test ./test
1
0
$ g++-4.8pre --version
g++-4.8pre (GCC) 4.8.0 20120330 (experimental)
$ g++-4.8pre -std=c++0x -g3 test.cc -o test ./test
1
0
I believe this happens because
http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/include/bits/stl_algo.h?revision=184997view=markup#l1827
move-assigns *__result1 from *__first even when those are the same object,
which violates
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1204.
I haven't audited the rest of the library to look for more instances of this
mistake. I'm planning to switch the default compilation mode to c++0x and run
the gcc-4.6 test suite to look for more problems, but I'm not currently
planning to do the same for 4.7 or trunk.
[Bug libstdc++/52822] [C++11] stable_partition destroys sequence due to inappropriate self-move-assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52822 --- Comment #1 from Jeffrey Yasskin jyasskin at gcc dot gnu.org 2012-04-01 20:41:43 UTC --- Running the 4.6 testsuite with -std=c++0x as the default was unsuccessful, in that it found only one error in an execution test, which was already known, and didn't find the stable_partition bug. Manual inspection it is. :(
[Bug libstdc++/52822] [C++11] stable_partition destroys sequence due to inappropriate self-move-assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52822 --- Comment #5 from Jeffrey Yasskin jyasskin at gcc dot gnu.org 2012-04-02 02:15:24 UTC --- Created attachment 27058 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27058 Fix by skipping past true-predicate values Here's an algorithmic fix that passes check-c++. As a side-effect, it makes __find_if_not available outside C++11 mode. Look good for trunk? Would you want the simpler __result1!=__first fix for 4.6 and/or 4.7, or is this approach good for them too?
[Bug c++/52796] New: [4.6/4.7 C++11] Initialization of primitive object with 0-length parameter pack fails to value-initialize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52796
Bug #: 52796
Summary: [4.6/4.7 C++11] Initialization of primitive object
with 0-length parameter pack fails to value-initialize
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jyass...@gcc.gnu.org
The following program attempts to initialize a 'char' member using a variadic
parameter pack. With length 0, the initialization doesn't happen, leaving the
original value of the memory in the field. I originally noticed this in gcc-4.6
when std::listchar(3) failed to initialize the list elements.
$ cat test.cc
#include memory.h
#include iostream
templatetypename T
class Wrapper {
public:
#if WORK
Wrapper()
: t() {
}
#endif
templatetypename ...Args
Wrapper(Args... args)
: t(args...) {
}
T t;
};
int main() {
__attribute__(aligned(alignof(Wrapperchar))) char
space[sizeof(Wrapperchar)];
memset(space, '\xab', sizeof(space));
Wrapperchar*w = new(space) Wrapperchar;
std::cout (int)w-t '\n';
w-~Wrapperchar();
memset(space, '\xab', sizeof(space));
w = new(space) Wrapperchar();
std::cout (int)w-t '\n';
w-~Wrapperchar();
memset(space, '\xab', sizeof(space));
w = new(space) Wrapperchar((int)'y');
std::cout (int)w-t '\n';
w-~Wrapperchar();
}
$ g++-4.7pre --version
g++-4.7pre (GCC) 4.7.1 20120330 (prerelease)
...
$ g++-4.7pre -Wall -std=c++11 test.cc -g3 -o test ./test
-85
0
121
Disassembling with gdb shows:
Dump of assembler code for function Wrapperchar::Wrapper():
0x00400a70 +0: push %rbp
0x00400a71 +1: mov%rsp,%rbp
0x00400a74 +4: mov%rdi,-0x8(%rbp)
= 0x00400a78 +8: pop%rbp
0x00400a79 +9: retq
[Bug c++/52796] [4.6/4.7 C++11] Initialization of primitive object with 0-length parameter pack fails to value-initialize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52796 --- Comment #1 from Jeffrey Yasskin jyasskin at gcc dot gnu.org 2012-03-30 21:18:09 UTC --- Created attachment 27050 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27050 Test file demonstrating improvement from 4.6-4.7 The attached 46_vs_47.cc shows that gcc-4.7 calls the default constructor for pack uses like new Type(args...), while gcc-4.6 didn't. So 4.7 doesn't have the std::list bug. I tested this with valgrind-3.6.0: $ g++-4.6.x --version g++-4.6.x (GCC) 4.6.4 20120330 (prerelease) $ g++-4.6.x -Wall -std=c++0x 46_vs_47.cc -g3 -o test /usr/bin/valgrind ./test ... ==15840== Conditional jump or move depends on uninitialised value(s) ==15840==at 0x4EB8074: std::ostreambuf_iteratorchar, std::char_traitschar std::num_putchar, std::ostreambuf_iteratorchar, std::char_traitschar ::_M_insert_intlong(std::ostreambuf_iteratorchar, std::char_traitschar , std::ios_base, char, long) const (locale_facets.tcc:872) ==15840==by 0x4EB8395: std::num_putchar, std::ostreambuf_iteratorchar, std::char_traitschar ::do_put(std::ostreambuf_iteratorchar, std::char_traitschar , std::ios_base, char, long) const (locale_facets.h:2475) ==15840==by 0x4EC33CC: std::ostream std::ostream::_M_insertlong(long) (locale_facets.h:2336) ==15840==by 0x400BF7: void check_init() (46_vs_47.cc:19) ==15840==by 0x400AC1: main (46_vs_47.cc:24) ... 0 3 ==15840== Conditional jump or move depends on uninitialised value(s) ==15840==at 0x4EB8074: std::ostreambuf_iteratorchar, std::char_traitschar std::num_putchar, std::ostreambuf_iteratorchar, std::char_traitschar ::_M_insert_intlong(std::ostreambuf_iteratorchar, std::char_traitschar , std::ios_base, char, long) const (locale_facets.tcc:872) ==15840==by 0x4EB8395: std::num_putchar, std::ostreambuf_iteratorchar, std::char_traitschar ::do_put(std::ostreambuf_iteratorchar, std::char_traitschar , std::ios_base, char, long) const (locale_facets.h:2475) ==15840==by 0x4EC33CC: std::ostream std::ostream::_M_insertlong(long) (locale_facets.h:2336) ==15840==by 0x400B03: main (46_vs_47.cc:27) ... 0 $ g++-4.7pre --version g++-4.7pre (GCC) 4.7.1 20120330 (prerelease) $ g++-4.7pre -Wall -std=c++11 test.cc -g3 -o test /usr/bin/valgrind ./test ==8931== Memcheck, a memory error detector ==8931== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==8931== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info ==8931== Command: ./test ==8931== 0 3 0
[Bug c++/52796] [4.6/4.7/4.8 C++11] Initialization of primitive object with 0-length parameter pack fails to value-initialize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52796 Jeffrey Yasskin jyasskin at gcc dot gnu.org changed: What|Removed |Added Summary|[4.6/4.7 C++11] |[4.6/4.7/4.8 C++11] |Initialization of primitive |Initialization of primitive |object with 0-length|object with 0-length |parameter pack fails to |parameter pack fails to |value-initialize|value-initialize --- Comment #2 from Jeffrey Yasskin jyasskin at gcc dot gnu.org 2012-03-30 21:22:30 UTC --- And 4.8.0 20120330 matches 4.7's behavior for both test cases.
[Bug libstdc++/52799] New: deque::emplace(iterator, ...) tries to call push_front(...), which doesn't exist
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52799
Bug #: 52799
Summary: deque::emplace(iterator, ...) tries to call
push_front(...), which doesn't exist
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jyass...@gcc.gnu.org
$ cat emplace.cc
#include deque
int main() {
std::dequeint d;
d.emplace(d.begin());
}
$ g++-4.8pre --version
g++-4.8pre (GCC) 4.8.0 20120330 (experimental)
$ g++-4.8pre -std=c++11 emplace.cc -c -o /dev/null
In file included from .../include/c++/4.8.0/deque:67:0,
from emplace.cc:1:
.../include/c++/4.8.0/bits/deque.tcc: In instantiation of ‘std::deque_Tp,
_Alloc::iterator std::deque_Tp, _Alloc::emplace(std::deque_Tp,
_Alloc::iterator, _Args ...) [with _Args = {}; _Tp = int; _Alloc =
std::allocatorint; std::deque_Tp, _Alloc::iterator =
std::_Deque_iteratorint, int, int*]’:
emplace.cc:5:22: required from here
.../include/c++/4.8.0/bits/deque.tcc:178:6: error: no matching function for
call to ‘std::dequeint::push_front()’
.../include/c++/4.8.0/bits/deque.tcc:178:6: note: candidates are:
In file included from .../include/c++/4.8.0/deque:65:0,
from emplace.cc:1:
.../include/c++/4.8.0/bits/stl_deque.h:1357:7: note: void std::deque_Tp,
_Alloc::push_front(const value_type) [with _Tp = int; _Alloc =
std::allocatorint; std::deque_Tp, _Alloc::value_type = int]
.../include/c++/4.8.0/bits/stl_deque.h:1357:7: note: candidate expects 1
argument, 0 provided
.../include/c++/4.8.0/bits/stl_deque.h:1370:7: note: void std::deque_Tp,
_Alloc::push_front(std::deque_Tp, _Alloc::value_type) [with _Tp = int;
_Alloc = std::allocatorint; std::deque_Tp, _Alloc::value_type = int]
.../include/c++/4.8.0/bits/stl_deque.h:1370:7: note: candidate expects 1
argument, 0 provided
...
The problem is that deque::emplace(iterator __position, _Args... __args)
tries to forward to push_front(std::forward_Args(__args)...) instead of
emplace_front(std::forward_Args(__args)...), and similarly for *_back().
I haven't checked the other containers for similar problems.
[Bug c++/52538] New: Extend C++11 UDLs to be compatible with inttypes.h macros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52538
Bug #: 52538
Summary: Extend C++11 UDLs to be compatible with inttypes.h
macros
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jyass...@gcc.gnu.org
C++11 defines user-defined literals in a way that breaks compatibility with
some code that uses the formatting macros from inttypes.h:
$ cat test.cc
#define __STDC_FORMAT_MACROS
#include inttypes.h
#include stdio.h
int main() {
int64_t i64 = 123;
printf(My int64: %PRId64\n, i64);
}
$ install_gcc46/bin/g++ -Wall test.cc -o test ./test
My int64: 123
$ install_gcc46/bin/g++ -std=c++0x -Wall test.cc -o test ./test
My int64: 123
$ install_gcc47/bin/g++-4.7pre -Wall test.cc -o test ./test
My int64: 123
$ install_gcc47/bin/g++-4.7pre -Wall -Wc++11-compat test.cc -o test ./test
My int64: 123
$ install_gcc47/bin/g++-4.7pre -std=c++0x -Wall test.cc -o test ./test
test.cc: In function ‘int main()’:
test.cc:7:29: error: unable to find string literal operator ‘operator PRId64’
Clang is working around this by interpreting literal suffixes that don't start
with underscores as separate tokens, which allows them to expand as macros:
http://llvm.org/viewvc/llvm-project?view=revrevision=152287
According to [lex.ext]p10 and [usrlit.suffix], these suffixes are ill-formed,
no diagnostic required, so allowing them to expand as macros is a conforming
extension.
It would also be possible to fix the code by inserting a space between the
and the macro name, but in Google's codebase, this cleanup would be 3-4x as
large as the narrowing conversion cleanup, which you have already made
optional.
[Bug libstdc++/52486] New: money_put/money_get/moneypunct interpreting localeconv() result incorrectly and inserting/requiring an extra space
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52486 Bug #: 52486 Summary: money_put/money_get/moneypunct interpreting localeconv() result incorrectly and inserting/requiring an extra space Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: jyass...@gcc.gnu.org Created attachment 26829 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26829 Test program to show monetary formatting results The attached test program produces the following output with trunk gcc and Ubuntu EGLIBC 2.13-20ubuntu5. Note that reading and writing values in the US locale requires two spaces between USD and the currency value, and writes an extra space when showbase is false (meaning the currency symbol should be omitted). In the French locale, we're getting an extra space at the very end of the output string. I believe glibc is setting the locale data correctly for C11, and it matches the example table in paragraph 10 of 7.11.2.1 The localeconv function. In C99 I think the normative wording was ambiguous, but the example table showed the opposite value for int_*_sep_by_space. $ ~/src/gcc/install/bin/g++-4.8svn -Wall test.cc -o test ./test en_US.UTF-8 Set locale to 'en_US.UTF-8' lc-currency_symbol == '$' lc-p_sep_by_space == 0 lc-n_sep_by_space == 0 lc-int_curr_symbol == 'USD ' lc-int_p_sep_by_space == 1 lc-int_n_sep_by_space == 1 '1.23' reads as: '0' And advances the iterator from 0x227c028 to 0x227c028. And leaves the stream in state failbit. 'USD 1.23' reads as: '0' And advances the iterator from 0x227c028 to 0x227c02c. And leaves the stream in state failbit. 'USD 1.23' reads as: '123' And advances the iterator from 0x227c028 to 0x227c031. And leaves the stream in state eofbit. Testing 123: !showbase: ' 1.23'; showbase: 'USD 1.23' strfmon writes it/100 as: no-symbol: '1.23'; symbol: 'USD 1.23' Testing -1: !showbase: '- .01'; showbase: '-USD .01' strfmon writes it/100 as: no-symbol: '-0.01'; symbol: '-USD 0.01' $ ~/src/gcc/install/bin/g++-4.8svn -Wall test.cc -o test ./test fr_FR.UTF-8 Set locale to 'fr_FR.UTF-8' lc-currency_symbol == '€' lc-p_sep_by_space == 1 lc-n_sep_by_space == 1 lc-int_curr_symbol == 'EUR ' lc-int_p_sep_by_space == 1 lc-int_n_sep_by_space == 1 '1.23' reads as: '0' And advances the iterator from 0x1c8f028 to 0x1c8f029. And leaves the stream in state failbit. 'USD 1.23' reads as: '0' And advances the iterator from 0x1c8f028 to 0x1c8f028. And leaves the stream in state failbit. 'USD 1.23' reads as: '0' And advances the iterator from 0x1c8f028 to 0x1c8f028. And leaves the stream in state failbit. Testing 123: !showbase: '1,23 '; showbase: '1,23 EUR ' strfmon writes it/100 as: no-symbol: '1,23'; symbol: '1,23 EUR' Testing -1: !showbase: '-,01 '; showbase: '-,01 EUR ' strfmon writes it/100 as: no-symbol: '-0,01'; symbol: '-0,01 EUR' jyasskin@abzu:~/tmp$
[Bug c/46596] misbehavior when mixing always_inline and alias attributes in the same compilation unit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46596
Jeffrey Yasskin jyasskin at gcc dot gnu.org changed:
What|Removed |Added
CC||jyasskin at gcc dot gnu.org
--- Comment #4 from Jeffrey Yasskin jyasskin at gcc dot gnu.org 2012-02-29
09:41:05 UTC ---
glibc runs into the sorry, unimplemented part of the issue, with
delta-reduced code like:
$ cat test.i
typedef __builtin_va_list __gnuc_va_list;
extern __inline __attribute__ ((__always_inline__)) __attribute__
((__artificial__)) void syslog (int __pri, const char *__fmt, ...) {
};
typedef __gnuc_va_list va_list;
void __syslog(int pri, const char *fmt, ...) {
}
extern __typeof (__syslog) syslog __attribute__ ((alias (__syslog)));
void __vsyslog_chk(int pri, int flag, const char *fmt, va_list ap) {
if (pri ~(0x07|0x03f8)) {
syslog(3|0x02|0x20|0x01,
syslog: unknown facility/priority: %x, pri);
}
}
$ gcc -c -O2 -Winline test.i
test.i: In function ‘__vsyslog_chk’:
test.i:7:28: sorry, unimplemented: inlining failed in call to ‘syslog’:
function body not available
test.i:10:11: sorry, unimplemented: called from here
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6.1/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.6.1-9ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin
--enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3)
I haven't yet built a gcc from head to make sure the behavior is there without
Ubuntu's patches. The glibc problem was described at
http://plash.beasts.org/wiki/GlibcBuildIssues#head-b9149fbab065967691cf1bade23d84325c05e9b0
and reported at http://sourceware.org/bugzilla/show_bug.cgi?id=10375, but it
looks like a gcc problem to me.
[Bug libstdc++/43813] [DR1234] vectorT*(3, NULL) fails to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43813 Jeffrey Yasskin jyasskin at gcc dot gnu.org changed: What|Removed |Added Status|SUSPENDED |NEW CC||jyasskin at gcc dot gnu.org Version|4.5.0 |4.7.0 --- Comment #10 from Jeffrey Yasskin jyasskin at gcc dot gnu.org 2012-02-22 23:38:02 UTC --- -NEW since the issue was adopted for C++11: http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1234. Clearly I didn't find time to write the patch, and I'm not likely to before gcc-4.7
[Bug libstdc++/52119] numeric_limits::min() is not a constant expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52119 --- Comment #4 from Jeffrey Yasskin jyasskin at gcc dot gnu.org 2012-02-05 02:04:00 UTC --- I hadn't tested #define __glibcxx_min(T) \ (__glibcxx_signed (T) ? -__glibcxx_max(T) - 1 : (T)0) but now I have, and it works with clang.
[Bug libstdc++/52119] New: numeric_limits::min() is not a constant expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52119
Bug #: 52119
Summary: numeric_limits::min() is not a constant expression
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jyass...@gcc.gnu.org
numeric_limitsT::min() is defined as (__glibcxx_signed (T) ? (T)1
__glibcxx_digits (T) : (T)0). Unfortunately, shifting into the sign bit is
undefined behavior (C++11[expr.shift]p2), and undefined behavior makes an
expression non-constant.
clang as of (their) r149727 diagnoses this as:
$ echo '#include limits' | clang++ -nostdinc++
-Igcc-4.7-svn/include/c++/4.7.0/{,x86_64-unknown-linux-gnu} -std=c++11
-Wsystem-headers -fsyntax-only -x c++ -
gcc-4.7-svn/include/c++/4.7.0/limits:654:7: error: constexpr function never
produces a constant expression
min() _GLIBCXX_USE_NOEXCEPT { return __glibcxx_min (wchar_t); }
^
gcc-4.7-svn/include/c++/4.7.0/limits:654:44: note: value 2147483648 is
outside the range of representable values of type 'int'
min() _GLIBCXX_USE_NOEXCEPT { return __glibcxx_min (wchar_t); }
^
gcc-4.7-svn/include/c++/4.7.0/limits:131:32: note: expanded from macro
'__glibcxx_min'
(__glibcxx_signed (T) ? (T)1 __glibcxx_digits (T) : (T)0)
^
gcc-4.7-svn/include/c++/4.7.0/limits:784:31: warning: shift count = width
of type [-Wshift-count-overflow]
min() noexcept { return __glibcxx_min (char32_t); }
^~~~
A better definition might be -__glibcxx_max(T)-1.
This bug is also in 4.6.2. 4.5.0 didn't declare min() as constexpr.
[Bug libstdc++/51558] New: Declaration of unspecialized std::hash_Tp::operator()(_Tp) turns compile-time errors into link-time errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51558
Bug #: 51558
Summary: Declaration of unspecialized
std::hash_Tp::operator()(_Tp) turns compile-time
errors into link-time errors
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jyass...@gcc.gnu.org
Created attachment 26090
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26090
Declare std::hashT instead of defining it.
libstdc++'s current definition of the unspecialized std::hash template gives
bad error messages when a user forgets to define a hash function for their
type. Specifically, providing a declaration but no definition of operator()
moves the error from compile to link time:
$ cat test.cc
#include unordered_set
struct MyStruct {
int i;
};
bool operator==(const MyStruct lhs, const MyStruct rhs) {
return lhs.i == rhs.i;
}
int main() {
std::unordered_setMyStruct s;
s.insert(MyStruct{3});
}
$ g++ -g -std=c++11 test.cc -o test
/tmp/cclzhwaU.o: In function `std::__detail::_Hash_code_baseMyStruct,
MyStruct, std::_IdentityMyStruct, std::equal_toMyStruct,
std::hashMyStruct, std::__detail::_Mod_range_hashing,
std::__detail::_Default_ranged_hash, true::_M_hash_code(MyStruct const)
const':
.../include/c++/4.7.0/bits/hashtable_policy.h:702: undefined reference to
`std::hashMyStruct::operator()(MyStruct) const'
collect2: error: ld returned 1 exit status
With the attached patch, the error is much more informative, if not exactly
concise:
$ g++ -g -std=c++11 test.cc -o test
In file included from .../include/c++/4.7.0/bits/hashtable.h:35:0,
from .../include/c++/4.7.0/unordered_set:45,
from test.cc:1:
.../include/c++/4.7.0/bits/hashtable_policy.h: In instantiation of ‘struct
std::__detail::_Hash_code_baseMyStruct, MyStruct, std::_IdentityMyStruct,
std::equal_toMyStruct, std::hashMyStruct,
std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, true’:
.../include/c++/4.7.0/bits/hashtable.h:149:11: required from ‘class
std::_HashtableMyStruct, MyStruct, std::allocatorMyStruct,
std::_IdentityMyStruct, std::equal_toMyStruct, std::hashMyStruct,
std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash,
std::__detail::_Prime_rehash_policy, true, true, true’
.../include/c++/4.7.0/bits/unordered_set.h:46:11: required from ‘class
std::__unordered_setMyStruct, std::hashMyStruct, std::equal_toMyStruct,
std::allocatorMyStruct, true’
.../include/c++/4.7.0/bits/unordered_set.h:277:11: required from ‘class
std::unordered_setMyStruct’
test.cc:9:32: required from here
.../include/c++/4.7.0/bits/hashtable_policy.h:740:20: error:
‘std::__detail::_Hash_code_base_Key, _Value, _ExtractKey, _Equal, _H1, _H2,
std::__detail::_Default_ranged_hash, true::_M_h1’ has incomplete type
...
In particular, the required from here line points at the actual source
location that needs to be able to find the definition.
I believe the patch is allowed by C++11 since I can't find a specification of
the contents of the unspecialized template, and libc++ uses basically the same
technique:
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__functional_base?view=markup.
Another way to accomplish something similar would be to delete the operator()
declaration from the std::hashT definition. I believe that's not as good
because it produces error messages saying that std::hash lacks an operator()
rather than that the template has incomplete type. Better yet would be finding
a way to include please specialize me in the error message.
[Bug c++/51150] New: [C++11][4.6 Regression] ICE when result of - initializes const variable of different type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51150
Bug #: 51150
Summary: [C++11][4.6 Regression] ICE when result of -
initializes const variable of different type
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jyass...@gcc.gnu.org
Using gcc-4_6-branch@181398, the following program ICEs:
$ cat test.ii
class Clock {
double Now();
};
template class T static void Foo(Clock* clock) {
const int now = clock-Now();
}
$ g++ -std=c++0x -fsyntax-only test.ii
test.ii: In function ‘void Foo(Clock*)’:
test.ii:5:30: internal compiler error: unexpected expression ‘clock-’ of kind
arrow_expr
Please submit a full bug report,
[Bug c++/51150] [C++11][4.6/4.7 Regression] ICE when result of - initializes const variable of different type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51150 Jeffrey Yasskin jyasskin at gcc dot gnu.org changed: What|Removed |Added Summary|[C++11][4.6 Regression] ICE |[C++11][4.6/4.7 Regression] |when result of - |ICE when result of - |initializes const variable |initializes const variable |of different type |of different type --- Comment #1 from Jeffrey Yasskin jyasskin at gcc dot gnu.org 2011-11-16 05:17:28 UTC --- This ICE didn't happen with 4.6.1, and it does happen with trunk@181400.
[Bug c++/51150] [C++11][4.6/4.7 Regression] ICE when result of - initializes const variable of different type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51150
--- Comment #2 from Jeffrey Yasskin jyasskin at gcc dot gnu.org 2011-11-16
05:30:12 UTC ---
And here's a similar test case using static_cast instead of -:
$ cat test.ii
template class T void Foo(int val) {
const int now = static_castfloat(val);
}
$ g++ -std=c++0x test.ii -fsyntax-only
test.ii: In function ‘void Foo(int)’:
test.ii:2:41: internal compiler error: unexpected expression
‘static_castfloat(val)’ of kind static_cast_expr
Please submit a full bug report,
[Bug libstdc++/51013] New: complex::{imag,real}() should maintain lvalue-returning extension in C++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51013
Bug #: 51013
Summary: complex::{imag,real}() should maintain
lvalue-returning extension in C++11
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jyass...@gcc.gnu.org
In C++98, libstdc++ has an extension to return T from complexT::real() and
::imag() (introduced in r75680). Paolo removed this extension for C++11 in
r135878 citing
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387. However, the
point of DR387 was to increase the amount of access complex provides to its
internals, not to remove existing extensions providing such access.
Removing this extension affects code that passes references to the real or
imaginary parts of a complex number to other routines. While such code can
generally be rewritten in a straightforward way, it seems like an unnecessary
hurdle that should be avoided given all the other changes needed for C++11
compatibility.
The DR387-provided reinterpret_cast way of getting access to the addresses
would work if we were migrating to C++11 atomically, but that's impossible in a
large codebase. I believe the reinterpret_cast produces undefined behavior in
C++98 because of the aliasing violation, so we can't use it in code that needs
to be correct in both versions of the language.
So I think the extension should be reinstated.
[Bug c++/50491] New: [C++0x] unexpected ast of kind using_decl on call to using'ed grandparent member function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50491
Bug #: 50491
Summary: [C++0x] unexpected ast of kind using_decl on call to
using'ed grandparent member function
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jyass...@gcc.gnu.org
CC: a...@google.com
$ cat test.ii
struct GrandParent {
void *get();
};
templateclass OBJ
struct Parent : public GrandParent{
};
templatetypename T
struct Child : public ParentT {
using GrandParent::get;
void Foo() {
void* ex = get();
}
};
$ clang++ -std=gnu++0x -fsyntax-only test.ii
$ g++-4.6 --version
g++-4.6 (GCC) 4.6.1
$ g++-4.6 -std=gnu++0x -fsyntax-only test.ii
test.ii: In member function 'void ChildT::Foo()':
test.ii:13:20: sorry, unimplemented: unexpected ast of kind using_decl
test.ii:13: confused by earlier errors, bailing out
$ g++-4.7svn --version
g++-4.7svn (GCC) 4.7.0 20110911 (experimental)
$ g++-4.7svn -std=gnu++0x -fsyntax-only test.ii
test.ii: In member function ‘void ChildT::Foo()’:
test.ii:13:20: sorry, unimplemented: unexpected ast of kind using_decl
test.ii:13:20: internal compiler error: in potential_constant_expression_1, at
cp/semantics.c:8226
If I change the get() line to (void)get();, g++-4.6.1 succeeds, but g++-4.7
still fails with the same error. Making GrandParent non-dependent by passing a
concrete type to Parent makes both versions succeed.
[Bug c++/50491] [C++0x] unexpected ast of kind using_decl on call to using'ed grandparent member function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50491 --- Comment #1 from Jeffrey Yasskin jyasskin at gcc dot gnu.org 2011-09-22 23:14:35 UTC --- Both g++ versions also succeed when passed -std=c++98.
[Bug c++/50280] New: Incorrect type deduced for T when passed a const bitfield
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50280
Bug #: 50280
Summary: Incorrect type deduced for T when passed a const
bitfield
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jyass...@gcc.gnu.org
$ cat test.cc
struct S { int bf : 3; };
templateclass _T1
void make_pair(_T1 __x) {}
void foo() {
const S s = S();
make_pair(s.bf);
}
$ g++-4.6 -c test.cc
test.cc: In function 'void foo()':
test.cc:8:17: error: cannot bind bitfield 's.S::bf' to 'int'
$ clang++ -c test.cc
$
It looks like gcc is deducing the parameter type from the base type of the
bitfield rather than its type modified by qualifiers on the containing object.
This seems related to PR43663, but isn't the same issue because using const
_T1 in make_pair makes this compile.
This showed up when compiling a make_pair(val, bitfield) call in C++0x mode
that worked in C++98 mode, but the underlying issue is present in C++98 too.
[Bug c++/50258] New: -std=gnu++0x should allow in-class initialization of static const floating types without constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50258
Bug #: 50258
Summary: -std=gnu++0x should allow in-class initialization of
static const floating types without constexpr
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jyass...@gcc.gnu.org
In c++98 mode, gcc accepts in-class initialization of static const floating
members as an extension. This extension have been removed in C++0x mode, even
when gnu extensions are specifically requested with -std=gnu++0x. It would be
nice to keep the extension, especially since the C++0x draft was only changed
to disallow it in the FDIS.
$ gcc-4.6 --version
gcc-4.6 (GCC) 4.6.1
$ cat test.cc
struct Foo {
static const double d = 3.14;
};
const double Foo::d;
$ gcc-4.6 -c -Wall test.cc
$ gcc-4.6 -c -Wall -std=gnu++0x test.cc
test.cc:2:27: error: 'constexpr' needed for in-class initialization of static
data member 'd' of non-integral type
test.cc:4:19: error: 'const double Foo::d' is not a static member of 'struct
Foo'
test.cc:4:14: error: uninitialized const 'Foo::d' [-fpermissive]
$
[Bug c++/48859] [4.6/4.7 Regression] incorrect uninitialized const member error on new without new-initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48859 --- Comment #8 from Jeffrey Yasskin jyasskin at gcc dot gnu.org 2011-05-10 15:42:54 UTC --- Thanks! Is this patch ok for the 4.6 branch too? If you don't have time to backport it, I can.
[Bug c++/48859] New: Regression: incorrect uninitialized const member error on new without new-initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48859
Summary: Regression: incorrect uninitialized const member
error on new without new-initializer
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jyass...@gcc.gnu.org
$ cat test.cc
struct HasConstructor {
HasConstructor() {}
};
class ConstMember {
const HasConstructor empty_;
};
void foo() {
new ConstMember;
}
$ g++-mp-4.5 -c test.cc
$ g++-mp-4.6 -c test.cc
test.cc: In function 'void foo()':
test.cc:10:7: error: uninitialized const member in 'class ConstMember' using
'new' without new-initializer
test.cc:6:24: note: 'ConstMember::empty_' should be initialized
$
[expr.new]p15 says, If the new-initializer is omitted: If T is a (possibly
cv-qualified) non-POD class type (or array thereof), the object is
default-initialized (8.5) If T is a const-qualified type, the underlying class
type shall have a user-declared default constructor.
T is ConstMember and is not const-qualified, so the object is
default-initialized.
[dcl.init]p5 says, To default-initialize an object of type T means: if T is a
non-POD class type (clause 9), the default constructor for T is called (and the
initialization is ill-formed if T has no accessible default constructor);
[class.ctor]p7 says, The implicitly-defined default constructor performs the
set of initializations of the class that would be performed by a user-written
default constructor for that class with an empty mem- initializer-list (12.6.2)
and an empty function body. If that user-written default constructor would be
ill- formed, the program is ill-formed.
The empty user-written default constructor for ConstMember is well-formed, and
I don't see any other wording saying that const members prevent the creation of
a default constructor. Further, a local variable with no initializer
successfully compiles. So I believe gcc-4.6 is wrong here and gcc-4.5 was
right.
I don't see anything in the C++0x draft that would change the right behavior
here.
The workaround, of course, is to define the empty default constructor in
ConstMember. (In C++0x mode, =default does not work around the problem.)
[Bug c++/48748] New: Undocumented type traits used in libstdc++-4.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48748 Summary: Undocumented type traits used in libstdc++-4.6 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: documentation Severity: minor Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: jyass...@gcc.gnu.org At least __is_standard_layout(), __is_literal_type(), and __is_trivial() are used in the libstdc++-4.6 implementation, but they're not documented on http://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/Type-Traits.html. They should be added to the documentation.
[Bug c++/48518] New: Inconsistent instantiation behavior depending on operator overloading
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48518
Summary: Inconsistent instantiation behavior depending on
operator overloading
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jyass...@gcc.gnu.org
The following program instantiates wrapUndefined, but a very similar program
that doesn't call an overloaded operator doesn't:
$ cat test.ii
template class C struct scoped_ptr {
C operator*() const {
return *ptr_;
}
C* ptr_;
};
templateclass T struct wrap {
T must_be_complete;
};
class Undefined;
struct S {
wrapUndefined content() const {
return *content_;
}
scoped_ptrwrapUndefined content_;
};
$ trunk/g++ -c test.ii
test.ii: In instantiation of ‘wrapUndefined’:
test.ii:13:13: instantiated from here
test.ii:8:5: error: ‘wrapT::must_be_complete’ has incomplete type
test.ii:10:7: error: forward declaration of ‘struct Undefined’
$
However:
$ cat test_works.ii
template class C struct scoped_ptr {
C get() const {
return *ptr_;
}
C* ptr_;
};
templateclass T struct wrap {
T must_be_complete;
};
class Undefined;
struct S {
wrapUndefined content() const {
return content_.get();
}
scoped_ptrwrapUndefined content_;
};
$ ~/opensource/gcc/git/install/bin/g++ -c test_works.ii
$
This was a change from gcc-4.4 to gcc-4.5. Comeau agrees with gcc here, but
clang disagrees.
This is confusing because the operator that makes a difference is on
scoped_ptrwrapUndefined, not on wrapUndefined.
[Bug c++/48500] New: Regression: Failing to convert template argument to concrete type, in C++0x mode.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48500
Summary: Regression: Failing to convert template argument to
concrete type, in C++0x mode.
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jyass...@gcc.gnu.org
CC: ja...@gcc.gnu.org
This shows up in template functions that try to pass a value whose type is a
template argument to a function that expects one or more concrete types. The
code compiles in gcc-4.5, produces an error in 4.6.0 and gcc-4_6-branch, and
produces an ICE in trunk. All of them succeed in C++98 mode.
$ cat test.cc
struct linked_ptr {
};
template typename T linked_ptr make_linked_ptr(T* ptr);
struct Concrete;
struct NewedClass {
NewedClass(const Concrete req){}
};
templatetypename ArgT void AddObjToChange(const ArgT req) {
linked_ptr p = make_linked_ptr(new NewedClass(req));
}
$ g++-mp-4.5 -c test.cc -std=gnu++0x
$ g++-mp-4.6 -c test.cc -std=gnu++0x # Or gcc-4_6-branch at r172074
test.cc: In function 'void AddObjToChange(const ArgT)':
test.cc:9:53: error: no matching function for call to
'NewedClass::NewedClass(const ArgT)'
test.cc:9:53: note: candidates are:
test.cc:6:3: note: NewedClass::NewedClass(const Concrete)
test.cc:6:3: note: no known conversion for argument 1 from 'const ArgT' to
'const Concrete'
test.cc:5:8: note: constexpr NewedClass::NewedClass(const NewedClass)
test.cc:5:8: note: no known conversion for argument 1 from 'const ArgT' to
'const NewedClass'
test.cc:5:8: note: constexpr NewedClass::NewedClass(NewedClass)
test.cc:5:8: note: no known conversion for argument 1 from 'const ArgT' to
'NewedClass'
$ trunk-r172073/g++ -std=gnu++0x -c test.cc
test.cc: In function ‘void AddObjToChange(const ArgT)’:
test.cc:9:53: internal compiler error: tree check: expected record_type or
union_type or qual_union_type, have template_type_parm in lookup_base, at
cp/search.c:212
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
$
An error in similar code went away with the fix to PR48319.
[Bug c++/48420] New: Missed -Wconversion-null warning when passing const bool to T*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48420
Summary: Missed -Wconversion-null warning when passing const
bool to T*
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jyass...@gcc.gnu.org
$ g++-mp-4.6 -Wconversion-null -c test.cc
dhcp-172-19-248-71:~/tmp$ cat test.cc
void foo(int* p);
void bar() {
const bool kDebugMode = false; // NULL pointer constant.
foo(kDebugMode); // But no warning!
}
$ g++-mp-4.6 -Wconversion-null -c test.cc
$
Changing the kDebugMode to 'false' or a false expression involving an enum
triggers the warning.
[Bug libstdc++/48406] New: algorithm #undefs isfinite() from math.h in C++0x mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48406
Summary: algorithm #undefs isfinite() from math.h in C++0x
mode
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jyass...@gcc.gnu.org
$ cat test.cc
#include math.h
#include algorithm
bool foo(double d) {
return isfinite(d);
}
$ ~/opensource/gcc/git/install/bin/g++ -c test.cc
$ ~/opensource/gcc/git/install/bin/g++ -c test.cc -std=gnu++0x
test.cc: In function ‘bool foo(double)’:
test.cc:5:20: error: ‘isfinite’ was not declared in this scope
test.cc:5:20: note: suggested alternative:
.../include/c++/4.7.0/cmath:528:21: note: ‘std::isfinite’
$
This is a regression since gcc-4.4:
$ g++-4.4 -c test.cc -std=gnu++0x
$
It happens because stl_algo.h includes random in C++0x mode only, and
random includes cmath, which #undefs all the C99 math functions that
math.h defined, without 'using' the std functions back into the global
namespace.
As far as I can tell, [depr.c.headers] says that math.h puts the cmath
names into the global namespace, and it doesn't allow a later include of
cmath to take them back out. [depr.c.headers] also allows cmath to
unconditionally put its declarations and definitions into the global namespace,
which is what I'd propose as a fix.
[Bug libstdc++/48406] algorithm #undefs isfinite() from math.h in C++0x mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48406 --- Comment #1 from Jeffrey Yasskin jyasskin at gcc dot gnu.org 2011-04-02 05:52:12 UTC --- FWIW, the path from algorithm-cmath appears to have been introduced in gcc-4.5.
[Bug c++/48372] New: Missed error for redundant default argument on template.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48372
Summary: Missed error for redundant default argument on
template.
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jyass...@gcc.gnu.org
Using a trunk gcc:
$ cat test.cc
templatetypename _Ex
void
__throw_with_nested(const _Ex, const int* = 0)
__attribute__ ((__noreturn__));
templatetypename _Ex
inline void
__throw_with_nested(const _Ex __ex, const int* = 0)
{ throw __ex; }
void foo() {
__throw_with_nested(3);
}
$ g++ -c test.cc
$
However, if I make them non-templates:
$ cat test.cc
void
__throw_with_nested(const int, const int* = 0)
__attribute__ ((__noreturn__));
inline void
__throw_with_nested(const int __ex, const int* = 0)
{ throw __ex; }
void foo() {
__throw_with_nested(3);
}
$ g++ -c test.cc
test.cc: In function ‘void __throw_with_nested(const int, const int*)’:
test.cc:6:52: error: default argument given for parameter 2 of ‘void
__throw_with_nested(const int, const int*)’ [-fpermissive]
test.cc:2:1: error: after previous specification in ‘void
__throw_with_nested(const int, const int*)’ [-fpermissive]
$
[Bug other/42540] c++ error message [vtable undefined] is unhelpful
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42540 Jeffrey Yasskin jyasskin at gcc dot gnu.org changed: What|Removed |Added CC||jyasskin at gcc dot gnu.org --- Comment #10 from Jeffrey Yasskin jyasskin at gcc dot gnu.org 2011-03-17 16:16:50 UTC --- Mark asked for a different implementation in http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00367.html, and I may not get a chance to do what he asked for 4.7. Someone else is welcome to pick this up if they have time.
[Bug target/48139] __builtin_lrintf() becomes a library call, not an cvtss2si instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48139 --- Comment #5 from Jeffrey Yasskin jyasskin at gcc dot gnu.org 2011-03-16 17:21:57 UTC --- According to C99, lrint does not produce domain errors. It may only produce range errors (and isn't required to): The lrint and llrint functions round their argument to the nearest integer value, rounding according to the current rounding direction. If the rounded value is outside the range of the return type, the numeric result is unspecified. A range error may occur if the magnitude of x is too large. —7.12.9.5 The C1x draft changes that to allow, but not require, domain errors: The lrint and llrint functions round their argument to the nearest integer value, rounding according to the current rounding direction. If the rounded value is outside the range of the return type, the numeric result is unspecified and a domain error or range error may occur. In the case of a range error, 7.12.1 (oddly) actually forbids these functions from setting ERANGE: … Similarly, a range error occurs if the mathematical result of the function cannot be represented in an object of the specified type, due to extreme magnitude. … A floating result overflows … The result underflows if the magnitude of the mathematical result is so small that the mathematical result cannot be represented, without extraordinary roundoff error, in an object of the specified type. (basically unchanged in C1x) lrint does not return a floating result, and it can't underflow, so there's no wording saying it can set ERANGE. So, there's no glibc bug, but I don't think this makes a compelling case for any particular gcc behavior. The implementation is gcc+glibc, so gcc could say that its implementation of lrint never sets errno, and all would be conforming. Or gcc could say that users will pick a libc based on whether they want errno to be set, and so it should emit the call. Or gcc could optimize lrint in C99 (where errno-setting is forbidden) but not in C1x (where it's allowed). One local workaround is to set __attribute__((optimize(no-math-errno))) on the functions whose assembly contains the undesired call, but that's a bit fragile in the face of changing inlining decisions.
[Bug target/48139] __builtin_lrintf() becomes a library call, not an cvtss2si instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48139 --- Comment #8 from Jeffrey Yasskin jyasskin at gcc dot gnu.org 2011-03-17 01:09:38 UTC --- Ah, I didn't check Posix, specifically http://pubs.opengroup.org/onlinepubs/9699919799/functions/lrint.html. I now agree that gcc can't optimize this without -fno-math-errno.
[Bug c++/48138] New: __attribute__((aligned)) should give an error when applied to a typedef or template parameter, at least in C++0x mode.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48138
Summary: __attribute__((aligned)) should give an error when
applied to a typedef or template parameter, at least
in C++0x mode.
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jyass...@gcc.gnu.org
In the C++0x draft, [dcl.align] says:
An alignment-specifier may be applied to a variable or to a class
data member, but it shall not be applied to a bit-field, a function
parameter, the formal parameter of a catch clause (15.3), or a
variable declared with the register storage class specifier. An
alignment-specifier may also be applied to the declaration of a class
or enumeration type.
This does not allow its use on a typedef or next to a typename template
parameter. It might make sense for gcc to support that as an extension, but
gcc's current behavior is not what people expect that extension to do:
$ cat test.cc
#include iostream
#define ALIGNED(x) __attribute__((aligned(x)))
struct Char15 {
char x[15];
} ALIGNED(8);
templatetypename T
void print_type_alignment(const T) {
struct { char c; T t; } s;
std::cout sizeof(T) ' ' ((char*)s.t - (char*)s.c) '\n';
}
int main() {
typedef char unaligned[15];
typedef char aligned[15] ALIGNED(8);
unaligned x[10];
aligned y[10];
Char15 c15[10];
std::cout sizeof(unaligned) ' ' sizeof(x) '\n';
std::cout sizeof(aligned) ' ' sizeof(y) '\n';
std::cout sizeof(Char15) ' ' sizeof(c15) '\n';
aligned z ALIGNED(8);
print_type_alignmentunaligned ALIGNED(8)(z);
}
$ g++-mp-4.6 -std=gnu++0x test.cc ./a.out
15 150
15 152
16 160
15 1
Note that the alignment on the typedef applies to the final variable, not the
defined type, which means that interior members of arrays of the defined type
have an unexpected alignment. This has been reported several times before
(PR43798, PR47557, PR12742, PR42098), but the core problem seems to be that
alignments on typedefs aren't supported.
__attribute__((aligned)) on template arguments seems to have no effect at all.
$ g++-mp-4.6 -v
Using built-in specs.
COLLECT_GCC=g++-mp-4.6
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin10/4.6.0/lto-wrapper
Target: x86_64-apple-darwin10
Configured with: ../gcc-4.6-20110305/configure --prefix=/opt/local
--build=x86_64-apple-darwin10 --enable-languages=c,c++,objc,obj-c++
--libdir=/opt/local/lib/gcc46 --includedir=/opt/local/include/gcc46
--infodir=/opt/local/share/info --mandir=/opt/local/share/man
--datarootdir=/opt/local/share/gcc-4.6 --with-local-prefix=/opt/local
--with-system-zlib --disable-nls --program-suffix=-mp-4.6
--with-gxx-include-dir=/opt/local/include/gcc46/c++/ --with-gmp=/opt/local
--with-mpfr=/opt/local --with-mpc=/opt/local --enable-stage1-checking
--disable-multilib --enable-fully-dynamic-string
Thread model: posix
gcc version 4.6.0 20110305 (experimental) (GCC)
[Bug c/47557] Effect of aligned attribute on arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47557
Jeffrey Yasskin jyasskin at gcc dot gnu.org changed:
What|Removed |Added
CC||jyasskin at gcc dot gnu.org
--- Comment #3 from Jeffrey Yasskin jyasskin at gcc dot gnu.org 2011-03-15
18:18:06 UTC ---
Alignments on typedefs behave very strangely (PR48138). What you want is:
typedef struct __attribute__((aligned(2))) {
char a[3];
} T;
unsigned x1 = sizeof(T);// sizeof is 4
unsigned x2 = sizeof(T[1]); // sizeof is 4
unsigned x3 = sizeof(T[2]); // sizeof is 8
unsigned x4 = sizeof(T[2][1]); // sizeof is 8
unsigned x5 = sizeof(T[1][2]); // sizeof is 8
Moving the attribute makes it apply to the struct instead of the typedef, which
fixes everything. C1x and C++0x don't allow alignments on typedefs either.
[Bug libstdc++/47709] New: is_heap(standard iterator) becomes ambiguous in C++0x mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47709
Summary: is_heap(standard iterator) becomes ambiguous in C++0x
mode
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jyass...@gcc.gnu.org
$ cat test.cc
#include ext/algorithm
#include vector
void foo() {
std::vectorint v;
is_heap(v.begin(), v.end());
}
$ g++-4.6svn -c test.cc
$ g++-4.6svn -c test.cc -std=c++0x
test.cc: In function ‘void foo()’:
test.cc:6:29: error: call of overloaded ‘is_heap(std::vectorint::iterator,
std::vectorint::iterator)’ is ambiguous
test.cc:6:29: note: candidates are:
include/c++/4.6.0/ext/algorithm:436:5: note: bool
__gnu_cxx::is_heap(_RandomAccessIterator, _RandomAccessIterator) [with
_RandomAccessIterator = __gnu_cxx::__normal_iteratorint*, std::vectorint ]
include/c++/4.6.0/bits/stl_heap.h:560:72: note: bool std::is_heap(_RAIter,
_RAIter) [with _RAIter = __gnu_cxx::__normal_iteratorint*, std::vectorint ]
I believe the fix is to using std::is_heap into __gnu_cxx in C++0x mode
rather than redefining it there. Another possible fix would be to move
__normal_iterator out of __gnu_cxx to avoid ADL finding that is_heap, but that
wouldn't help people who have already using __gnu_cxx::is_heap into their
global namespaces.
[Bug c++/47671] New: Missed optimization on empty virtual destructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47671
Summary: Missed optimization on empty virtual destructors
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jyass...@gcc.gnu.org
At the beginning of each virtual destructor gcc writes the address of the
current class's vtable into the object's vptr. However, if the destructor is
empty, it doesn't need to do this, since after the return or delete call, the
object is dead, and any read of the vptr is undefined behavior..
Given:
$ cat test.cc
struct Base {
virtual ~Base() {}
};
struct Derived : Base {
~Derived();
};
Derived::~Derived() {}
gcc-4.6 produces:
$ gcc-4.6svn -O3 -S -fverbose-asm test.cc -o -
...
.globl _ZN7DerivedD2Ev
.type _ZN7DerivedD2Ev, @function
_ZN7DerivedD2Ev:
movq$_ZTV4Base+16, (%rdi) #, MEM[(struct Base
*)this_1(D)]._vptr.Base
ret
...
.globl _ZN7DerivedD0Ev
.type _ZN7DerivedD0Ev, @function
_ZN7DerivedD0Ev:
movq$_ZTV4Base+16, (%rdi) #, MEM[(struct Base
*)this_1(D)]._vptr.Base
jmp _ZdlPv #
In PIC mode, this is 3 instructions instead of one:
$ gcc-4.6svn -fPIC -O3 -S -fverbose-asm test.cc -o -
...
_ZN7DerivedD2Ev:
movq_ZTV4Base@GOTPCREL(%rip), %rax #, tmp63
addq$16, %rax #, tmp62
movq%rax, (%rdi)# tmp62, MEM[(struct Base
*)this_1(D)]._vptr.Base
ret
[Bug c++/46527] Member of template class gets wrong debug location when template (but not member) is used before member is defined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46527 Jeffrey Yasskin jyasskin at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Jeffrey Yasskin jyasskin at gcc dot gnu.org 2010-11-24 22:57:08 UTC --- Fixed by r167104.
[Bug c++/46527] Member of template class gets wrong debug location when template (but not member) is used before member is defined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46527 --- Comment #2 from Jeffrey Yasskin jyasskin at gcc dot gnu.org 2010-11-24 00:25:01 UTC --- Author: jyasskin Date: Wed Nov 24 00:24:54 2010 New Revision: 167104 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=167104 Log: Propagate the source location from a template function's definition to any already-instantiated declarations. PR c++/46527 * gcc/cp/pt.c (instantiate_decl): Propagate the template's location to its instance. * gcc/testsuite/g++.dg/debug/dwarf2/pr46527.C: New test. Added: trunk/gcc/testsuite/g++.dg/debug/dwarf2/pr46527.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug c++/46527] Member of template class gets wrong debug location when template (but not member) is used before member is defined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46527 Jeffrey Yasskin jyasskin at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2010.11.20 00:57:42 AssignedTo|unassigned at gcc dot |jyasskin at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Jeffrey Yasskin jyasskin at gcc dot gnu.org 2010-11-20 00:57:42 UTC --- Created attachment 22465 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22465 Possible fix Here's a possible patch. I'll add a test and run the test suite and then send it to gcc-patches. Corrections are welcome in the mean time.
[Bug c++/46527] New: Member of template class gets wrong debug location when template (but not member) is used before member is defined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46527
Summary: Member of template class gets wrong debug location
when template (but not member) is used before member
is defined
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jyass...@gcc.gnu.org
The debug information should locate Vector4double::defined_later() at its
definition (in good.h), not its declaration (in bad.h). This causes problems
for Gold's --detect-odr-violations flag.
Test case:
$ cat test.cc
template typename VType struct Vector4 {
# 1 bad.h 1
double defined_later();
# 42 good.h
};
struct WrapperStruct {
Vector4double ClassInstantiated;
};
template typename VType double Vector4VType::defined_later() {
return 1;
}
void InstantiateMethod() {
Vector4double().defined_later();
}
$ ~/gcc/trunk/install/bin/g++ -c -g test.cc -o test.o
$ objdump -dCl test.o
...
Vector4double::defined_later():
_ZN7Vector4IdE13defined_laterEv():
/home/jyasskin/tmp/bad.h:1
0: 55 push %rbp
1: 48 89 e5mov%rsp,%rbp
4: 48 89 7d f8 mov%rdi,-0x8(%rbp)
/home/jyasskin/tmp/good.h:47
8: 48 b8 00 00 00 00 00mov$0x3ff0,%rax
f: 00 f0 3f
12: 48 89 45 f0 mov%rax,-0x10(%rbp)
16: f2 0f 10 45 f0 movsd -0x10(%rbp),%xmm0
/home/jyasskin/tmp/good.h:48
1b: 5d pop%rbp
1c: c3 retq
