[Bug libstdc++/58338] Add noexcept to functions with a narrow contract
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58338 --- Comment #12 from Marc Glisse --- (In reply to bredelin from comment #10) > http://cplusplus.github.io/LWG/lwg-active.html#2193 I suggest you open a separate bugzilla PR for this. Before my patch we were already inconsistent about it.
[Bug libgcc/58710] HAVE_GETIPINFO is incorrectly set on Mac OS X 10.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58710 --- Comment #1 from Misty De Meo --- It looks like the check was added in a4a5a77adfc9c28d6963e5ae054c997d57cfc7fa (http://repo.or.cz/w/official-gcc.git/commitdiff/a4a5a77adfc9c28d6963e5ae054c997d57cfc7fa), which didn't touch the existing behaviour that was already doing some definition of whether _Unwind_GetIPInfo was available or not.
[Bug tree-optimization/58686] vect_get_loop_niters() fails for some loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58686
--- Comment #3 from rguenther at suse dot de ---
congh at google dot com wrote:
>http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58686
>
>--- Comment #2 from Cong Hou ---
>I think this issue is more like a missed optimization.
>
>If the iteration number can be calculated as a constant value at
>compile time,
>then the function assert_loop_rolls_lt() won't be called due to an
>early exit
>(specifically in the function number_of_iterations_lt() at the call to
>number_of_iterations_lt_to_ne()). That is why I could not craft a
>testcase
>showing miscompile.
>
>A better test case is shown below:
>
>
>#define N 4
>void foo(int* a, unsigned int i)
>{
> int j = 0;
> do
> {
>a[j++] = 0;
>i -= 4;
> }
> while (i >= N);
>}
>
>
>Compile it with -O3 and the produced result is using __builtin_memset()
>as the
>niter can be calculated. But if the value of N is replaced by others
>like 3 or
>5, GCC won't optimize this loop into __builtin_memset() any more.
Yeah, the issue in general is finding a condition that ensures the loop will
terminate and a formula that computes the number of iterations if that holds
true. In case of wrapping arithmetic this is non-trivial and likely not all
cases are implemented.
Richard.
[Bug c++/58709] [c++11] Bogus? int vs. scoped enum printf warning when -fabi-version >= 6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58709 --- Comment #3 from Andreas Schwab --- The warning is target independent and only depends on the type. You get the same warning for int vs long even if they are the same size.
[Bug libstdc++/58338] Add noexcept to functions with a narrow contract
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58338 --- Comment #13 from Paolo Carlini --- In any case I see that the issue with explicit instantiation is recorded in 2193. Let's see what happens in EWG.
[Bug other/58712] New: [4.9 Regression] issues found by --enable-checking=valgrind
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58712 Bug ID: 58712 Summary: [4.9 Regression] issues found by --enable-checking=valgrind Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: markus at trippelsdorf dot de 1) ==4348== Conditional jump or move depends on uninitialised value(s) ==4348==at 0x5CF50C: cgraph_create_edge_1(cgraph_node*, cgraph_node*, gimple_statement_d*, long, int) (cgraph.c:695) ==4348==by 0x5D005E: cgraph_create_edge(cgraph_node*, cgraph_node*, gimple_statement_d*, long, int) (cgraph.c:890) ==4348==by 0x5D80A1: cgraph_clone_edge(cgraph_edge*, cgraph_node*, gimple_statement_d*, unsigned int, long, int, bool) (cgraphclones.c:135) ==4348==by 0x86C7E4: copy_body(copy_body_data*, long, int, basic_block_def*, basic_block_def*, basic_block_def*) (tree-inline.c:1741) ==4348==by 0x86F94F: optimize_inline_calls(tree_node*) (tree-inline.c:4258) ==4348==by 0xC0029A: (anonymous namespace)::pass_early_inline::execute() (ipa-inline.c:2257) ==4348==by 0x793AA9: execute_one_pass(opt_pass*) (passes.c:2202) ==4348==by 0x793C55: execute_pass_list(opt_pass*) (passes.c:2254) ==4348==by 0x7926C2: do_per_function_toporder(void (*)(void*), void*) (passes.c:1620) ==4348==by 0x7941A6: execute_ipa_pass_list(opt_pass*) (passes.c:2572) ==4348==by 0x5D7721: compile() (cgraphunit.c:1981) ==4348==by 0x5D7E24: finalize_compilation_unit() (cgraphunit.c:2269) ==4348== Probably caused by r201632. 2) ==9588== Use of uninitialised value of size 8 ==9588==at 0x8704C5: pointer_set_lookup(pointer_set_t const*, void const*, unsigned long*) (pointer-set.c:90) ==9588==by 0x870544: pointer_set_insert(pointer_set_t*, void const*) (pointer-set.c:147) ==9588==by 0x6AB402: analyze_functions() (cgraphunit.c:847) ==9588==by 0x6AC415: finalize_compilation_unit() (cgraphunit.c:2260) ==9588==by 0x568435: cp_write_global_declarations() (decl2.c:4421) ==9588==by 0x90095C: compile_file() (toplev.c:560) ==9588==by 0x902499: toplev_main(int, char**) (toplev.c:1893) ==9588==by 0x4ED5A6D: (below main) (in /lib64/libc-2.18.90.so) ==9588== ==9588== Conditional jump or move depends on uninitialised value(s) ==9588==at 0x8704CC: pointer_set_lookup(pointer_set_t const*, void const*, unsigned long*) (pointer-set.c:90) ==9588==by 0x870544: pointer_set_insert(pointer_set_t*, void const*) (pointer-set.c:147) ==9588==by 0x6AB402: analyze_functions() (cgraphunit.c:847) ==9588==by 0x6AC415: finalize_compilation_unit() (cgraphunit.c:2260) ==9588==by 0x568435: cp_write_global_declarations() (decl2.c:4421) ==9588==by 0x90095C: compile_file() (toplev.c:560) ==9588==by 0x902499: toplev_main(int, char**) (toplev.c:1893) ==9588==by 0x4ED5A6D: (below main) (in /lib64/libc-2.18.90.so) Probably caused by r200367. 3) ==1269== Invalid write of size 8 ==1269==at 0x63BDBD: iterative_hash_canonical_type(tree_node*, unsigned int) (gimple.c:3220) ==1269==by 0xC224F1: htab_find_slot (hashtab.c:704) ==1269==by 0x641818: gimple_register_canonical_type(tree_node*) (gimple.c:3488) ==1269==by 0x504AEB: lto_read_decls(lto_file_decl_data*, void const*, vec) (lto.c:2495) ==1269==by 0x505CBB: lto_main() (lto.c:2786) ==1269==by 0x7B3A95: compile_file() (toplev.c:546) ==1269==by 0x7B5619: toplev_main(int, char**) (toplev.c:1893) ==1269==by 0x4ED5A6D: (below main) (in /lib64/libc-2.18.90.so) ==1269== Address 0x40325a0 is not stack'd, malloc'd or (recently) free'd This is an older issue, see PR55358 for more info.
[Bug c++/58713] New: error: cannot bind ‘std::ostream {aka std::basic_ostream}’ lvalue to ‘std::basic_ostream
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58713
Bug ID: 58713
Summary: error: cannot bind ‘std::ostream {aka
std::basic_ostream}’ lvalue to
‘std::basic_ostream&&’
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ali.baharev at gmail dot com
#include
struct A { };
int main() {
A a;
std::cout << a;
}
-
g++ 4.8.1, 64 bit with -std=c++11 gives the correct error message:
main.cpp:7:15: error: no match for ‘operator<<’ (operand types are
‘std::ostream {aka std::basic_ostream}’ and ‘A’)
std::cout << a;
^
However, 4.8.1, 32 bit or 4.7.2, 64 bit gives:
prog.cpp:7:18: error: cannot bind ‘std::ostream {aka std::basic_ostream}’
lvalue to ‘std::basic_ostream&&’
std::cout << a;
^
In file included from /usr/include/c++/4.8/iostream:39:0,
from prog.cpp:1:
/usr/include/c++/4.8/ostream:602:5: error: initializing argument 1 of
‘std::basic_ostream<_CharT, _Traits>&
std::operator<<(std::basic_ostream<_CharT, _Traits>&&, const _Tp&) [with _CharT
= char; _Traits = std::char_traits; _Tp = A]’
operator<<(basic_ostream<_CharT, _Traits>&& __os, const _Tp& __x)
^
Could this rather confusing error message be improved?
Why do the 32 and 64 bit versions behave differently?
[Bug middle-end/58711] Missing "uninitialized" warning in loop condition (when compiling without optimization)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58711 Manuel López-Ibáñez changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||manu at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Manuel López-Ibáñez --- Known issue. *** This bug has been marked as a duplicate of bug 58488 ***
[Bug c/58488] -Wuninitialized is useless for a variable whose address is later taken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58488 Manuel López-Ibáñez changed: What|Removed |Added CC||mimomorin at gmail dot com --- Comment #5 from Manuel López-Ibáñez --- *** Bug 58711 has been marked as a duplicate of this bug. ***
[Bug c++/58714] New: Bogus value category in ternary operator?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58714
Bug ID: 58714
Summary: Bogus value category in ternary operator?
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ali.baharev at gmail dot com
struct X {
X& operator=(const X&) = delete;
X& operator=(X&& ) = default;
};
void f(bool t) {
X a, b;
*(t ? &a : &b) = X();
(t ? a : b) = X();
}
-
The line:
(t ? a : b) = X();
gives:
error: use of deleted function ‘X& X::operator=(const X&)’
The code compiles with clang++ 3.4.
The sections in the Standard relevant here are: [expr.cond]/4 "If the second
and third operands [of the conditional operator] are glvalues of the same value
category and have the same type, the result is of that type and value category"
(text in brackets inserted for clarity).
This code was posted at stackoverflow.com/q/19341908/341970
[Bug libgomp/58691] OpenMP 4: Surprising results with OMP_PLACES=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58691 Tobias Burnus changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Tobias Burnus --- (In reply to Jakub Jelinek from comment #3) > That command line doesn't set explicit OMP_PROC_BIND=false, it sets > OMP_PLACES twice, Ups! > I'll go ahead and commit the patch. Thanks! Looks good to me. As the issue is solved and as OMP_PLACES is new in GCC 4.9, I close this bug as FIXED. > libgomp.texi needs much more updates for OpenMP 4.0 I will create a patch for the run-time library and environment variable parts of the documentation. But I leave the libgomp API update to you.
[Bug c++/58714] Bogus value category in ternary operator?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58714 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Paolo Carlini --- Dup *** This bug has been marked as a duplicate of bug 53000 ***
[Bug c++/53000] Conditional operator does not behave as standardized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53000 Paolo Carlini changed: What|Removed |Added CC||ali.baharev at gmail dot com --- Comment #26 from Paolo Carlini --- *** Bug 58714 has been marked as a duplicate of this bug. ***
[Bug c++/58714] Bogus value category in ternary operator?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58714 --- Comment #2 from Ali Baharev --- OK, sorry for the dupe.
[Bug rtl-optimization/58662] [4.9 Regression] wrong code at -O2 for dumb condition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58662 --- Comment #10 from Eric Botcazou --- Author: ebotcazou Date: Sun Oct 13 13:29:28 2013 New Revision: 203498 URL: http://gcc.gnu.org/viewcvs?rev=203498&root=gcc&view=rev Log: PR rtl-optimization/58662 * combine.c (try_combine): Take into account death nodes on I2 when splitting a PARALLEL of two independent SETs. Fix dump message. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr58662.c Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/58662] [4.9 Regression] wrong code at -O2 for dumb condition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58662 Eric Botcazou changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Eric Botcazou --- Thanks for reporting the problem.
[Bug c/53001] -Wfloat-conversion should be available to warn about floating point errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53001 Joshua Cogliati changed: What|Removed |Added Attachment #30979|0 |1 is obsolete|| --- Comment #24 from Joshua Cogliati --- Created attachment 30994 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30994&action=edit Patch to add -Wfloat-conversion option against trunk with testcases This version modifies a few more testcases.
[Bug c++/58714] Bogus value category in ternary operator?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58714
Marc Glisse changed:
What|Removed |Added
Status|RESOLVED|NEW
Last reconfirmed||2013-10-13
CC||glisse at gcc dot gnu.org
Resolution|DUPLICATE |---
Ever confirmed|0 |1
--- Comment #3 from Marc Glisse ---
The quoted paragraph is implemented in gcc-4.9. However, this still fails. The
strange thing is that both of these versions work:
static_cast(t ? a : b) = X{};
(t ? a : b) = static_cast(X{});
There is special code in cp_build_modify_expr to handle assignment to a
conditional, but it contains this line:
rhs = stabilize_expr (rhs, &preeval);
which apparently loses the prvalue-ness of rhs.
I think we can consider it as a different issue from PR 53000, because
operator?: worked ok, it is the later assignment which failed. By the way, this
C++03 version:
struct X {
private:
X& operator=(const X&);
X& operator=(X& );
};
void f(bool t) {
X a, b;
*(t ? &a : &b) = X();
(t ? a : b) = X();
}
says:
c.cc: In function 'void f(bool)':
c.cc:3:6: error: 'X& X::operator=(const X&)' is private
X& operator=(const X&);
^
c.cc:9:18: error: within this context
*(t ? &a : &b) = X();
^
c.cc:4:6: error: 'X& X::operator=(X&)' is private
X& operator=(X& );
^
c.cc:10:15: error: within this context
(t ? a : b) = X();
^
c.cc:4:6: error: 'X& X::operator=(X&)' is private
X& operator=(X& );
^
c.cc:10:15: error: within this context
(t ? a : b) = X();
^
The fact that it tries to use X::operator=(X&) seems like a bug, which could
easily be turned into wrong-code.
[Bug c++/58709] [c++11] Bogus? int vs. scoped enum printf warning when -fabi-version >= 6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58709 Paul Pluzhnikov changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jdennett at google dot com Resolution|--- |INVALID --- Comment #4 from Paul Pluzhnikov --- James Dennett says: I believe that the code is incorrect, and the warning is valid. For calls via varargs: . If the argument has integral or enumeration type that is subject to the integral promotions (4.5), or a floating point type that is subject to the floating point promotion (4.6), the value of the argument is converted to the promoted type before the call. These promotions are referred to as the default argument promotions. And scoped enumerations are not "subject to the integral promotions"; only unscoped enums are: . The value of an enumerator or an object of an unscoped enumeration type is converted to an integer by integral promotion (4.5). So it (the scoped enumeration value) is not passed as an int, and using va_arg to pull it out as an int is undefined behavior. Well, the full story is even worse; va_arg is defined by the C standard (not the C++ standard) and in particular is defined in terms of "compatible" types. C says that its enums are compatible with some underlying (but unspecified) integral type, but naturally C has nothing to say about scoped enumerations. It would be reasonable for C++ to specify that varargs calls apply the default argument promotions to scoped enumerations also, but that's not how C++ is written today. The intent of scoped enums is that they never implicitly act like integers, from which perspective it's good to require people to convert to the underlying type if they must use varargs.
[Bug tree-optimization/58715] New: Missed loop condition optimization opportunity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58715 Bug ID: 58715 Summary: Missed loop condition optimization opportunity Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ryao at gentoo dot org Created attachment 30995 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30995&action=edit lzjb_decompress code from ZFS Here is a snippet of the lzjb implementation from Open ZFS showing a change that tightens a loop condition in a frequently executed loop: -while (--mlen >= 0 && dst < d_end) +if (mlen > (d_end - dst)) +mlen = d_end - dst; +while (--mlen >= 0) *dst++ = *cpy++; In the original version, dst increments toward d_end while mlen decrements toward 0 on each loop iteration. Eventually, one will reach its termination condition. Nothing else touches mlen, so it is safe to do mlen = MIN(mlen, d_end - dst) before the loop and drop the ` && dst < d_end` part of the condition. Even if it were used elsewhere, a temporary could be used to store the minimum of the two. The assembly generated by GCC 4.8.1 on the original evaluates both conditions on each iteration while the assembly generated for the patched version does not. In addition, loop unrolling is done on the patched version on -O3 while the original sees no unrolling at any optimization level.
[Bug target/58716] New: [PATCH] MSP430X check is inverted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58716
Bug ID: 58716
Summary: [PATCH] MSP430X check is inverted
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: quandary at remstate dot com
CC: dj at redhat dot com, nickc at redhat dot com
Target: msp430-elf
Created attachment 30996
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30996&action=edit
Use !strcasecmp() to detect when a string is matched (instead of strcasecmp())
r203026 added a check for MSP430X arch MCUs based on a complete listing of
supported chips. If a chip is in the list, then the msp430x flag should be set.
The change uses strcasecmp() to accomplish the check, and this function returns
zero on success (match). The "if" statement checking the result of strcasecmp()
is expecting a non-zero value ("true") to trigger the branch.
Fix is to NOT strcasecmp's output. Trivial patch against trunk (head) attached.
Symptom was that code generated for the msp430g2412 chip (non-CPUX) contained
pushm. Verified that the attached patch resolves that issue.
[Bug tree-optimization/58715] Missed loop condition optimization opportunity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58715
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #1 from Andrew Pinski ---
Here is a short testcase:
typedef __SIZE_TYPE__ size_t;
void f(int mlen, unsigned char *dst, size_t d_len, unsigned char *cpy)
{
unsigned char *d_end = dst + d_len;
while (--mlen >= 0 && dst < d_end)
*dst++ = *cpy++;
}
[Bug tree-optimization/58715] Missed loop condition optimization opportunity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58715
--- Comment #2 from Andrew Pinski ---
Here is a testcase which shows we are not doing some other loop opt due to not
changing the loop:
typedef __SIZE_TYPE__ size_t;
void f(int mlen, unsigned char *dst, size_t d_len, unsigned char *cpy)
{
unsigned char *d_end = dst + d_len;
while (--mlen >= 0 && dst < d_end)
*dst++ = 0;
}
This should produce memset but we are not currently.
[Bug c++/58708] string literal operator templates broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58708 --- Comment #1 from Hristo Venev --- Obviously bugzilla doesn't like unicode. U"\x1\x10001\x10002" current: expected:
[Bug c++/58708] string literal operator templates broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58708
--- Comment #2 from Ed Smith-Rowland <3dw4rd at verizon dot net> ---
Hristo,
Thanks for finishing your thought.
So if i have:
template
void
operator""_foo
{
ChatT arr[]{str...};
}
U"\x1\x10001\x10002"_foo;
I should see this right?
[Bug c++/58717] New: Pre-calculation optimization is omitted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58717
Bug ID: 58717
Summary: Pre-calculation optimization is omitted
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: masoud_mxm at yahoo dot com
Created attachment 30997
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30997&action=edit
Two .cpp source code
It seems newer versions of gcc (4.8+) don't pre-calculate functions for
constant inputs (Asked the issue here:
http://stackoverflow.com/q/19350097/952747). Two source codes attached.
unsigned long long s(unsigned long long n)
{
auto s = 0ULL;
for (auto i = 0ULL; i < n; i++)
s += i;
return s;
}
const auto N = 10ULL;
auto x = s(N); // It computes in run-time and dose NOT compute in compile-time!
[Bug c++/58717] Pre-calculation optimization is omitted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58717 --- Comment #1 from masoud_mxm at yahoo dot com --- Comment on attachment 30997 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30997 Two .cpp source code Tests are made in MinGW/32bit.
[Bug c++/58717] Pre-calculation optimization is omitted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58717 Ali Baharev changed: What|Removed |Added CC||ali.baharev at gmail dot com --- Comment #2 from Ali Baharev --- This optimization is still available in 4.7.2. The issue is present on Linux 64 bit, 4.8.1 also. http://coliru.stacked-crooked.com/a/9c22ce6c4b6f1a94
[Bug c++/58713] error: cannot bind ‘std::ostream {aka std::basic_ostream}’ lvalue to ‘std::basic_ostream
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58713 Jonathan Wakely changed: What|Removed |Added Keywords||diagnostic --- Comment #1 from Jonathan Wakely --- (In reply to Ali Baharev from comment #0) > Could this rather confusing error message be improved? I've tried to improve it in the past, but I think there's no easy way to do it. > Why do the 32 and 64 bit versions behave differently? They don't. I think maybe you forgot to use -std=c++11 in the first case?
[Bug c++/58713] error: cannot bind ‘std::ostream {aka std::basic_ostream}’ lvalue to ‘std::basic_ostream
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58713 --- Comment #2 from Ali Baharev --- >> Why do the 32 and 64 bit versions behave differently? > > They don't. I think maybe you forgot to use -std=c++11 in the first case? Yes, that's what happened. Sorry, my mistake.
[Bug sanitizer/58718] New: Invalid check in libsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58718 Bug ID: 58718 Summary: Invalid check in libsanitizer Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: y.gribov at samsung dot com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org Created attachment 30998 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30998&action=edit Repro I've recently tried to run AddressSanitizer with malloc_context_size=0 runtime option to speedup execution of my program. I got nice perf improvements but also an internal abort in asan_allocator2.cc when it tried to report heap overflow warning: 0x6004e004 is located 4 bytes to the right of 16-byte region [0x6004dff0,0x6004e000) ==3488== AddressSanitizer CHECK failed: /home/ygribov/gcc/gcc-master/libsanitizer/asan/asan_allocator2.cc:216 "((id)) != (0)" (0x0, 0x0) If I unset ASAN_OPTIONS, warning is reported correctly. -Y
[Bug sanitizer/58718] Invalid check in libsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58718 --- Comment #1 from Yury Gribov --- Created attachment 30999 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30999&action=edit Proposed patch It seems that this CHECK should be removed to allow disabling malloc tracing. Patch is attached. -Y
[Bug sanitizer/58718] Invalid check in libsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58718 Alexey Samsonov changed: What|Removed |Added CC||samsonov at google dot com --- Comment #2 from Alexey Samsonov --- I've already fixed the problem with crashes caused by small "malloc_context_size" values. I think you should wait till the ASan runtime will be merged from LLVM into GCC.
[Bug c++/58713] error: cannot bind ‘std::ostream {aka std::basic_ostream}’ lvalue to ‘std::basic_ostream
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58713 --- Comment #3 from Daniel Krügler --- (In reply to Jonathan Wakely from comment #1) > I've tried to improve it in the past, but I think there's no easy way to do > it. A possible fix might be to change the Standard ;-) Despite the smiley I seriously consider to make the proposal/open an issue that the "all-eating" signature template basic_ostream& operator<<(basic_ostream&& os, const T& x); should be constrained and should not participate in overload resolution unless the expression os << x would be well-formed (similar for the corresponding extractor). My current guess is that this would also improve the diagnostics in this case, is that right?
[Bug sanitizer/58718] Invalid check in libsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58718 --- Comment #3 from Yury Gribov --- Got it. I wonder whether we should keep the bug opened until we merge or close it now.
[Bug c++/58708] string literal operator templates broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58708
--- Comment #3 from Hristo Venev ---
#include
template
void operator""_foo(){
CharT arr[]{str...};
for(CharT i:arr) std::cout<<(int)i<<' ';
}
int main(){
U"\x1\x10001\x10002"_foo;
}
Current output: "0 0 1 0 1 0 1 0 2 0 1 0 0 0 0 "
Expected output: "65536 65537 65538 "
Without the \0, char32_t's instead of bytes.
The author of the paper intended CharT to be unqualified.
[Bug sanitizer/58718] Invalid check in libsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58718 --- Comment #4 from Kostya Serebryany --- I am currently testing a merge which is before Alexey's changes. There is no harm in keeping this bug open.
[Bug bootstrap/58719] New: libgcc/enable-execute-stack-mprotect.c: bootstrap failure due to missing #include
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58719 Bug ID: 58719 Summary: libgcc/enable-execute-stack-mprotect.c: bootstrap failure due to missing #include Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: skunk at iskunk dot org Host: i686-unknown-freebsd4.8 Target: i686-unknown-freebsd4.8 Build: i686-unknown-freebsd4.8 After patching bug #58274, a bootstrap of GCC 4.8.1 on FreeBSD 4.8 stops with /tmp/gcc-build/./gcc/xgcc -B/tmp/gcc-build/./gcc/ -B/usr/local/i686-unknown-freebsd4.8/bin/ -B/usr/local/i686-unknown-freebsd4.8/lib/ -isystem /usr/local/i686-unknown-freebsd4.8/include -isystem /usr/local/i686-unknown-freebsd4.8/sys-include-g -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fpic -pthread -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fpic -pthread -I. -I. -I../.././gcc -I../../../gcc-4.8.1/libgcc -I../../../gcc-4.8.1/libgcc/. -I../../../gcc-4.8.1/libgcc/../gcc -I../../../gcc-4.8.1/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o enable-execute-stack.o -MT enable-execute-stack.o -MD -MP -MF enable-execute-stack.dep -c enable-execute-stack.c -fvisibility=hidden -DHIDE_EXPORTS In file included from /usr/include/sys/mman.h:135:0, from enable-execute-stack.c:25: /usr/include/sys/mman.h:141:14: error: unknown type name 'mode_t' int shm_open __P((const char *, int, mode_t)); ^ /usr/include/sys/mman.h:144:11: error: unknown type name 'size_t' int mlock __P((const void *, size_t)); ^ /usr/include/sys/mman.h:147:13: error: unknown type name 'size_t' void * mmap __P((void *, size_t, int, int, int, off_t)); ^ /usr/include/sys/mman.h:147:13: error: unknown type name 'off_t' void * mmap __P((void *, size_t, int, int, int, off_t)); ^ /usr/include/sys/mman.h:149:14: error: unknown type name 'size_t' int mprotect __P((const void *, size_t, int)); ^ /usr/include/sys/mman.h:150:11: error: unknown type name 'size_t' int msync __P((void *, size_t, int)); ^ /usr/include/sys/mman.h:151:13: error: unknown type name 'size_t' int munlock __P((const void *, size_t)); ^ /usr/include/sys/mman.h:152:12: error: unknown type name 'size_t' int munmap __P((void *, size_t)); ^ /usr/include/sys/mman.h:154:13: error: unknown type name 'size_t' int madvise __P((void *, size_t, int)); ^ /usr/include/sys/mman.h:155:13: error: unknown type name 'size_t' int mincore __P((const void *, size_t, char *)); ^ /usr/include/sys/mman.h:156:14: error: unknown type name 'size_t' int minherit __P((void *, size_t, int)); ^ enable-execute-stack.c: In function '__enable_execute_stack': enable-execute-stack.c:86:7: warning: implicit declaration of function 'mprotect' [-Wimplicit-function-declaration] if (mprotect (page, end - page, STACK_PROT_RWX) < 0) ^ gmake[3]: *** [enable-execute-stack.o] Error 1 gmake[3]: Leaving directory `/tmp/gcc-build/i686-unknown-freebsd4.8/libgcc' gmake[2]: *** [all-stage1-target-libgcc] Error 2 gmake[2]: Leaving directory `/tmp/gcc-build' gmake[1]: *** [stage1-bubble] Error 2 gmake[1]: Leaving directory `/tmp/gcc-build' gmake: *** [bootstrap] Error 2 $ ls -l /tmp/gcc-build/i686-unknown-freebsd4.8/libgcc/enable-execute-stack.c lrwxr-xr-x 1 cport r&d 57 Oct 14 02:31 /tmp/gcc-build/i686-unknown-freebsd4.8/libgcc/enable-execute-stack.c -> ../../../gcc-4.8.1/libgcc/enable-execute-stack-mprotect.c Adding an '#include ' to libgcc/enable-execute-stack-mprotect.c, right before the sys/mman.h #include, is enough to get the bootstrap going again.
[Bug bootstrap/58720] New: FreeBSD 4.8 bootstrap fails due to missing stdint.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58720 Bug ID: 58720 Summary: FreeBSD 4.8 bootstrap fails due to missing stdint.h Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: skunk at iskunk dot org Host: i686-unknown-freebsd4.8 Target: i686-unknown-freebsd4.8 Build: i686-unknown-freebsd4.8 After addressing bugs #58274 and #58719, a bootstrap of GCC 4.8.1 on FreeBSD 4.8 fails with [...] gmake[5]: Entering directory `/tmp/gcc-build/i686-unknown-freebsd4.8/libstdc++-v3/include' mkdir -p ./i686-unknown-freebsd4.8/bits/stdc++.h.gch /tmp/gcc-build/./gcc/xgcc -shared-libgcc -B/tmp/gcc-build/./gcc -nostdinc++ -L/tmp/gcc-build/i686-unknown-freebsd4.8/libstdc++-v3/src -L/tmp/gcc-build/i686-unknown-freebsd4.8/libstdc++-v3/src/.libs -B/usr/local/i686-unknown-freebsd4.8/bin/ -B/usr/local/i686-unknown-freebsd4.8/lib/ -isystem /usr/local/i686-unknown-freebsd4.8/include -isystem /usr/local/i686-unknown-freebsd4.8/sys-include-x c++-header -nostdinc++ -g -O2 -I/tmp/gcc-build/i686-unknown-freebsd4.8/libstdc++-v3/include/i686-unknown-freebsd4.8 -I/tmp/gcc-build/i686-unknown-freebsd4.8/libstdc++-v3/include -I/tmp/gcc-4.8.1/libstdc++-v3/libsupc++ -O2 -g -std=gnu++0x /tmp/gcc-4.8.1/libstdc++-v3/include/precompiled/stdc++.h \ -o i686-unknown-freebsd4.8/bits/stdc++.h.gch/O2ggnu++0x.gch In file included from /tmp/gcc-build/i686-unknown-freebsd4.8/libstdc++-v3/include/bits/atomic_base.h:37:0, from /tmp/gcc-build/i686-unknown-freebsd4.8/libstdc++-v3/include/atomic:41, from /tmp/gcc-4.8.1/libstdc++-v3/include/precompiled/stdc++.h:99: /tmp/gcc-build/./gcc/include/stdint.h:9:26: fatal error: stdint.h: No such file or directory # include_next ^ compilation terminated. gmake[5]: *** [i686-unknown-freebsd4.8/bits/stdc++.h.gch/O2ggnu++0x.gch] Error 1 gmake[5]: Leaving directory `/tmp/gcc-build/i686-unknown-freebsd4.8/libstdc++-v3/include' gmake[4]: *** [all-recursive] Error 1 gmake[4]: Leaving directory `/tmp/gcc-build/i686-unknown-freebsd4.8/libstdc++-v3' gmake[3]: *** [all] Error 2 gmake[3]: Leaving directory `/tmp/gcc-build/i686-unknown-freebsd4.8/libstdc++-v3' gmake[2]: *** [all-stage1-target-libstdc++-v3] Error 2 gmake[2]: Leaving directory `/tmp/gcc-build' gmake[1]: *** [stage1-bubble] Error 2 gmake[1]: Leaving directory `/tmp/gcc-build' gmake: *** [bootstrap] Error 2 This system has no /usr/include/stdint.h, so GCC should probably not be looking for one.
