[Bug ipa/62015] [4.8/4.9/5 Regression] ipa-cp-clone uses a clone that is too specialized for the call context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62015 Mikael Pettersson changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #1 from Mikael Pettersson --- I can reproduce this wrong-code on x86_64-linux with gcc 5-20140824, 4.9-20140827, and 4.8-20140828. 4.7-20140607 works.
[Bug bootstrap/62304] [5 regression] ICE in follow_jumps, find_dead_or_set_registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62304 --- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #5 from Dave Malcolm --- > Created attachment 33416 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33416&action=edit > Candidate patch. Bootstrapped on x86_64; seems to work on stage1 cris and > sparc With this patch, sparc-sun-solaris2.11 bootstrap completed successfully. Compared to the last one of a week ago, there are two testsuite regressions, but I assume they are unrelated: FAIL: gcc.dg/20111227-2.c scan-rtl-dump ree "Elimination opportunities = 3 realized = 3" FAIL: gcc.dg/vect/vect-33.c scan-tree-dump-times vect "Alignment of access forced using versioning" 1 Rainer
[Bug bootstrap/62304] [5 regression] ICE in follow_jumps, find_dead_or_set_registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62304 --- Comment #8 from dmalcolm at gcc dot gnu.org --- Author: dmalcolm Date: Sat Aug 30 14:34:02 2014 New Revision: 214752 URL: https://gcc.gnu.org/viewcvs?rev=214752&root=gcc&view=rev Log: PR bootstrap/62304 * gcc/reorg.c (skip_consecutive_labels): Convert return type and param back from rtx_insn * to rtx. Rename param from "label" to "label_or_return", reintroducing "label" as an rtx_insn * after we've ensured it's not a RETURN. (first_active_target_insn): Likewise for return type and param; add a checked cast to rtx_insn * once we've ensured "insn" is not a RETURN. (steal_delay_list_from_target): Convert param "pnew_thread" back from rtx_insn ** to rtx *. Replace use of JUMP_LABEL_AS_INSN with JUMP_LABEL. (own_thread_p): Convert param "thread" back from an rtx_insn * to an rtx. Introduce local rtx_insn * "thread_insn" with a checked cast once we've established we're not dealing with a RETURN, renaming subsequent uses of "thread" to "thread_insn". (fill_simple_delay_slots): Convert uses of JUMP_LABEL_AS_INSN back to JUMP_LABEL. (follow_jumps): Convert return type and param "label" from rtx_insn * back to rtx. Move initialization of "value" to after the handling for ANY_RETURN_P, adding a checked cast there to rtx_insn *. Convert local rtx_insn * "this_label" to an rtx and rename to "this_label_or_return", reintroducing "this_label" as an rtx_insn * once we've handled the case where it could be an ANY_RETURN_P. (fill_slots_from_thread): Rename param "thread" to "thread_or_return", converting from an rtx_insn * back to an rtx. Reintroduce name "thread" as an rtx_insn * local with a checked cast once we've handled the case of it being an ANY_RETURN_P. Convert local "new_thread" from an rtx_insn * back to an rtx. Add a checked cast when assigning to "trial" from "new_thread". Convert use of JUMP_LABEL_AS_INSN back to JUMP_LABEL. Add a checked cast to rtx_insn * from "new_thread" when invoking get_label_before. (fill_eager_delay_slots): Convert locals "target_label", "insn_at_target" from rtx_insn * back to rtx. Convert uses of JUMP_LABEL_AS_INSN back to JUMP_LABEL. (relax_delay_slots): Convert locals "trial", "target_label" from rtx_insn * back to rtx. Convert uses of JUMP_LABEL_AS_INSN back to JUMP_LABEL. Add a checked cast to rtx_insn * on "trial" when invoking update_block. (dbr_schedule): Convert use of JUMP_LABEL_AS_INSN back to JUMP_LABEL; this removes all JUMP_LABEL_AS_INSN from reorg.c. * resource.h (mark_target_live_regs): Undo erroneous conversion of second param of r214693, converting it back from rtx_insn * to rtx, since it could be a RETURN. * resource.c (find_dead_or_set_registers): Similarly, convert param "jump_target" back from an rtx_insn ** to an rtx *, as we could be writing back a RETURN. Rename local rtx_insn * "next" to "next_insn", and introduce "lab_or_return" as a local rtx, handling the case where JUMP_LABEL (this_jump_insn) is a RETURN. (mark_target_live_regs): Undo erroneous conversion of second param of r214693, converting it back from rtx_insn * to rtx, since it could be a RETURN. Rename it from "target" to "target_maybe_return", reintroducing the name "target" as a local rtx_insn * with a checked cast, after we've handled the case of ANY_RETURN_P. Modified: trunk/gcc/ChangeLog trunk/gcc/reorg.c trunk/gcc/resource.c trunk/gcc/resource.h
[Bug libstdc++/62313] New: Data race in debug iterators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62313
Bug ID: 62313
Summary: Data race in debug iterators
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: dvyukov at google dot com
$ g++ -v
gcc version 5.0.0 20140830 (experimental) (GCC)
The program is:
===
#include
#include
#include
std::list::iterator iter, iter2;
void *thread(void *arg)
{
for (int i = 0; i < 100; i++) {
std::list::iterator it(iter);
iter2 = it;
}
return 0;
}
int main()
{
std::list li;
li.push_back(0);
iter = li.begin();
pthread_t th;
pthread_create(&th, 0, thread, 0);
for (int i = 0; i < 100; i++) {
li.push_back(1);
std::list::iterator it = li.begin();
it++;
li.erase(it);
}
pthread_join(th, 0);
}
=
Build it as:
$ g++ test.cc -Wall -lpthread -fsanitize=thread -pie -fPIE -D_GLIBCXX_DEBUG -g
-O2
Run the program. Output is:
WARNING: ThreadSanitizer: data race (pid=17058)
Read of size 8 at 0x7faedc637b00 by main thread (mutexes: write M2):
#0 void __gnu_debug::_Safe_sequence >
>::_M_invalidate_if<__gnu_debug::_Equal_to
> >(__gnu_debug::_Equal_to >)
/foo/include/c++/5.0.0/debug/safe_sequence.tcc:48 (a.out+0x2a61)
#1 std::__debug::list
>::_M_erase(std::__cxx1998::_List_iterator)
/foo/include/c++/5.0.0/debug/list:464 (a.out+0x1e21)
#2 std::__debug::list
>::erase(__gnu_debug::_Safe_iterator,
std::__debug::list > >)
/foo/include/c++/5.0.0/debug/list:477 (a.out+0x1e21)
#3 main test.cc:27 (a.out+0x1e21)
Previous write of size 8 at 0x7faedc637b00 by thread T1:
#0 __gnu_debug::_Safe_iterator,
std::__debug::list >
>::operator=(__gnu_debug::_Safe_iterator,
std::__debug::list > > const&)
/foo/include/c++/5.0.0/debug/safe_iterator.h:223 (a.out+0x2460)
#1 thread(void*) test.cc:11 (a.out+0x2460)
Location is global 'iter2' of size 40 at 0x7faedc637ae0
(a.out+0x00203b00)
Mutex M2 (0x7faedb100698) created at:
#0 pthread_mutex_lock
../../.././libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:2686
(libtsan.so.0+0x000368a6)
#1 __gthread_mutex_lock
/ssd/src/gcc_trunk/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu/bits/gthr-default.h:748
(libstdc++.so.6+0x000b284b)
#2 __gnu_cxx::__mutex::lock()
/ssd/src/gcc_trunk/x86_64-unknown-linux-gnu/libstdc++-v3/include/ext/concurrence.h:152
(libstdc++.so.6+0x000b284b)
#3 __gnu_cxx::__scoped_lock::__scoped_lock(__gnu_cxx::__mutex&)
/ssd/src/gcc_trunk/x86_64-unknown-linux-gnu/libstdc++-v3/include/ext/concurrence.h:244
(libstdc++.so.6+0x000b284b)
#4
__gnu_debug::_Safe_sequence_base::_M_attach(__gnu_debug::_Safe_iterator_base*,
bool) ../../../.././libstdc++-v3/src/c++11/debug.cc:268
(libstdc++.so.6+0x000b284b)
#5 __libc_start_main :0 (libc.so.6+0x00021ec4)
Thread T1 (tid=17060, running) created by main thread at:
#0 pthread_create ../../.././libsanitizer/tsan/tsan_interceptors.cc:853
(libtsan.so.0+0x00026eb4)
#1 main test.cc:22 (a.out+0x1aad)
As far as I see the safe iterator first attaches itself to the sequence in
_Safe_iterator_base ctor:
_Safe_iterator(const _Safe_iterator& __x)
: _Safe_iterator_base(__x, _M_constant()), _M_current(__x._M_current)
After that point it's accessible from other threads (in particular that
invalidate other iterators).
Only then it sets _M_current.
But _M_current is already read from another thread that invalidates a different
iterator.
There can be a similar race in dtor. They usually come together.
It can make sense to run some extensive test suite (if one exists) for debug
iterators with -fsanitize=thread -O{0,1,2}.
[Bug libstdc++/62313] Data race in debug iterators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62313 --- Comment #1 from Andrew Pinski --- You don't protect either the iterators or the list when touching it so I don't think this is a bug. If they truly independent lists and that was causing issues, then yes there would be an issue.
[Bug libstdc++/62313] Data race in debug iterators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62313 --- Comment #2 from Dmitry Vyukov --- The additional thread only touches iter, and the main thread does not touch iter nor invalidate it. So there is nothing to protect here. The program does not contain data races per se.
[Bug c++/62314] New: Fix-it Hints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62314
Bug ID: 62314
Summary: Fix-it Hints
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: manu at gcc dot gnu.org
Created attachment 33421
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33421&action=edit
fixit-hints draft implementation
Quoting from http://clang.llvm.org/diagnostics.html
"Fix-it" hints provide advice for fixing small, localized problems in source
code. When Clang produces a diagnostic about a particular problem that it can
work around (e.g., non-standard or redundant syntax, missing keywords, common
mistakes, etc.), it may also provide specific guidance in the form of a code
transformation to correct the problem.
$ clang t.cpp
t.cpp:9:3: error: template specialization requires 'template<>'
struct iterator_traits {
^
template<>
The attached patch implements the same behavior for GCC when given
-fdiagnostic-show-caret. When the caret is disabled, it gives:
t.cpp:9:3: error: template specialization requires 'template<>'
t.cpp:9:3: fixit: template<>
so an IDE might parse the "fixit:" diagnostic and use the message to edit the
text directly.
This is work in progress I have not even tried to build gcc using this patch.
[Bug c++/62314] Fix-it Hints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62314 --- Comment #1 from Manuel López-Ibáñez --- There are other examples here: http://clang.llvm.org/docs/InternalsManual.html#fix-it-hints
[Bug fortran/62278] gfc_check_dependency should also check for TARGET attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62278 --- Comment #3 from Tobias Burnus --- Author: burnus Date: Sat Aug 30 18:47:04 2014 New Revision: 214757 URL: https://gcc.gnu.org/viewcvs?rev=214757&root=gcc&view=rev Log: 2014-08-30 Tobias Burnus PR fortran/62278 PR fortran/44735 PR fortran/60593 * dependency.c (gfc_check_dependency): Allow for optimizations in the pointer-alias check. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dependency.c
[Bug fortran/44735] ICE on FORALL with character array pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44735 --- Comment #6 from Tobias Burnus --- Author: burnus Date: Sat Aug 30 18:47:04 2014 New Revision: 214757 URL: https://gcc.gnu.org/viewcvs?rev=214757&root=gcc&view=rev Log: 2014-08-30 Tobias Burnus PR fortran/62278 PR fortran/44735 PR fortran/60593 * dependency.c (gfc_check_dependency): Allow for optimizations in the pointer-alias check. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dependency.c
[Bug fortran/60593] ICE with deferred length variable in FORALL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60593 --- Comment #6 from Tobias Burnus --- Author: burnus Date: Sat Aug 30 18:47:04 2014 New Revision: 214757 URL: https://gcc.gnu.org/viewcvs?rev=214757&root=gcc&view=rev Log: 2014-08-30 Tobias Burnus PR fortran/62278 PR fortran/44735 PR fortran/60593 * dependency.c (gfc_check_dependency): Allow for optimizations in the pointer-alias check. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dependency.c
[Bug c++/62315] New: do not print typename in diagnostic if the original code does not have it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62315
Bug ID: 62315
Summary: do not print typename in diagnostic if the original
code does not have it
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: manu at gcc dot gnu.org
/home/manuel/test2/src/gcc/testsuite/g++.dg/parse/typedef2.C:2:42: error: need
‘typename’ before ‘typename B::X::Y’ because ‘typename B::X’ is a
dependent scope
template struct A { typedef B::X::Y Z; }; // { dg-error "" }
^
It is confusing to say that typename is needed before 'typename B::X::Y'.
[Bug c++/61341] ICE for variadic templates: tsubst at cp/pt.c:11313, tree check: expected class ‘expression’, have ‘type’ (integer_type)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61341 Gerald Pfeifer changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-08-30 CC||gerald at pfeifer dot com Summary|internal compiler error: in |ICE for variadic templates: |tsubst, at cp/pt.c:11313|tsubst at cp/pt.c:11313, ||tree check: expected class ||‘expression’, have ‘type’ ||(integer_type) Ever confirmed|0 |1 Known to fail||4.8.2, 4.9.2, 5.0 --- Comment #3 from Gerald Pfeifer --- On mainline as of today (which has more checking enabled) I get :37:52: internal compiler error: tree check: expected class ‘expression’, have ‘type’ (integer_type) in tree_operand_check, at tree.h:3186 Y, X >::value>::value;
[Bug c++/62316] New: poor location for missing braces warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62316
Bug ID: 62316
Summary: poor location for missing braces warning
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: manu at gcc dot gnu.org
~/test3/214756M/build/gcc/cc1plus
/home/manuel/test2/src/gcc/testsuite/g++.dg/warn/Wbraces1.C -Wmissing-braces
/home/manuel/test2/src/gcc/testsuite/g++.dg/warn/Wbraces1.C:3:29: warning:
missing braces around initializer for ‘int [2]’ [-Wmissing-braces]
int a[2][2] = { 0, 1 , 2, 3 }; // { dg-warning "" }
^
/home/manuel/test2/src/gcc/testsuite/g++.dg/warn/Wbraces1.C:3:29: warning:
missing braces around initializer for ‘int [2]’ [-Wmissing-braces]
Since the location info is so poor, it looks as if the warning is duplicated
but probably they refer to two different locations.
Clang++:
/home/manuel/test2/src/gcc/testsuite/g++.dg/warn/Wbraces1.C:3:17: warning:
suggest braces around initialization of subobject [-Wmissing-braces]
int a[2][2] = { 0, 1 , 2, 3 }; // { dg-warning "" }
^~~~
{ }
/home/manuel/test2/src/gcc/testsuite/g++.dg/warn/Wbraces1.C:3:24: warning:
suggest braces around initialization of subobject [-Wmissing-braces]
int a[2][2] = { 0, 1 , 2, 3 }; // { dg-warning "" }
^~~~
{ }
The poor location also prevents adding accurate fixit hints.
[Bug c++/52282] [C++0x] rejects-valid issues with decltype/constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52282 Paolo Carlini changed: What|Removed |Added CC|paolo.carlini at oracle dot com| --- Comment #8 from Paolo Carlini --- With the fix for c++/52892 we are down to the 4 fails mentioned in Comment #6. I also committed the first testcase here as g++.dg/cpp0x/constexpr-52282-1.C
[Bug libstdc++/62317] New: optimization of string searches using Nigel Horspool's Boyer-Moore-Horpool algorithm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62317 Bug ID: 62317 Summary: optimization of string searches using Nigel Horspool's Boyer-Moore-Horpool algorithm Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: jmichae3 at yahoo dot com optimization of string searches using Nigel Horspool's Boyer-Moore-Horpool algorithm is what I would like to see. right now it's just a plain old, slow O(n) loop. this could be sped WAY up using this algorithm. google Nigrel Horspool and see if you can get permission to use his algorithm. this could apply to 's std::find(), std::string.find() and you would not need to change the function signature. there are probably other uses for this algorithm I am not thinking of right now, but if you put your thinking cap on to see where this could fit, I am sure you could find some choice places for it. "1980 Practical Fast Searching in Strings" under Publications http://webhome.cs.uvic.ca/~nigelh/
[Bug libstdc++/62318] New: optimization of string searches using Nigel Horspool's Boyer-Moore-Horpool algorithm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62318 Bug ID: 62318 Summary: optimization of string searches using Nigel Horspool's Boyer-Moore-Horpool algorithm Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: jmichae3 at yahoo dot com optimization of string searches using Nigel Horspool's Boyer-Moore-Horpool algorithm is what I would like to see. right now it's just a plain old, slow O(n) loop. in just about any OS, at least half of the funcrtions are string functions. the C library should be modified as well, so should the same in objc and objc++ and whatever compiler in GNU compiler set you can put it in. in C libraries I typically see simple while loops. this can be done much better with only a little more code, the algorithm is very short. this could be sped WAY up using this algorithm. google Nigel Horspool and see if you can get permission to use his algorithm. this could apply to 's std::find(), std::string.find() and you would not need to change the function signature. there are probably other uses for this algorithm I am not thinking of right now, but if you put your thinking cap on to see where this could fit, I am sure you could find some choice places for it. "1980 Practical Fast Searching in Strings" under Publications http://webhome.cs.uvic.ca/~nigelh/ if you are compiling an OS or OS kernel with this, I would suspect you would see at least a 2-3x+ general performance improvement, maybe a lot more (though I have done no testing) due to the fact that most every OS API call has some sort of string parameter in it. Donald Knuth's The Art Of Computer Programming volumes 1-5 has quite an array of algorithms, and it's (as far as I know) a well known set that's been around for years.
[Bug libstdc++/62318] optimization of string searches using Nigel Horspool's Boyer-Moore-Horpool algorithm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62318 Jim Michaels changed: What|Removed |Added URL||http://webhome.cs.uvic.ca/~ ||nigelh/pubs.html --- Comment #1 from Jim Michaels --- added URL for his publications which include the string searching algorithm.
