[Bug c++/53620] Compiler segfaults when compiling Digikam
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53620
--- Comment #6 from Markus Trippelsdorf markus at trippelsdorf dot de
2012-06-11 06:27:16 UTC ---
The attached testcase crashes in determine_visibility.
4.8 is also affected.
Here is an ugly testcase:
markus@x4 /tmp % cat test.ii
templatetypenameclass H;
templatetypename _CharT, typename = int, typename = H_CharT class A;
templatetypename _Iteratorstruct B {
B(const _Iterator);
};
templatetypename _Tpstruct C {
typedef _Tp *const_pointer;
templatetypenamestruct D
{
typedef C other;
};
};
templatetypename _Tpclass H : public C_Tp{};
templatetypename _CharT, typename _Traits, typename _Allocclass A {
typedef typename _Alloc::template D_CharT::other _CharT_alloc_type;
public:
typedef typename _CharT_alloc_type::const_pointer const_pointer;
typedef Bconst_pointer const_iterator;
};
int blank;
templatetypename Iterator, typename Expr, typename Skipper,
typename Attrbool phrase_parse(Iterator, Expr, Skipper, Attr)
{
struct error_invalid_expression;
typedef struct
{
int *error_invalid_expression::*assert_arg;
}
mpl_assert_arg156;
enum
{
mpl_assertion_in_line_156 = mpl_assert_arg156::assert_arg
};
}
class F {
bool parseFile();
struct G;
};
struct F::G
{
static int ptoParser;
};
bool
F::parseFile()
{
Aint::const_iterator iter = 0, last = 0;
bool result = phrase_parse(iter, last, G::ptoParser, blank);
return result;
}
markus@x4 /tmp % g++ test.ii
test.ii: In instantiation of ‘struct phrase_parse(Iterator, Expr, Skipper,
Attr) [with Iterator = Bint*; Expr = Bint*; Skipper = int; Attr =
int]::mpl_assert_arg156’:
test.ii:33:3: required from ‘bool phrase_parse(Iterator, Expr, Skipper,
Attr) [with Iterator = Bint*; Expr = Bint*; Skipper = int; Attr = int]’
test.ii:47:77: required from here
test.ii:27:37: internal compiler error: Segmentation fault
int *error_invalid_expression::*assert_arg;
^
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug c++/53627] perfect forwarding for static int member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53627 --- Comment #8 from Daniel Krügler daniel.kruegler at googlemail dot com 2012-06-11 06:47:42 UTC --- (In reply to comment #7) (In reply to comment #4) because that was fixed with C++11 due to http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#712 This situation should no longer require a definition for S::a or S::b. Unless I'm mistaken DR 712 was not fixed in time for C++11, I don't see it in N3290 Agreed, DR 712 is a post-C11 resolution.
[Bug c++/53627] perfect forwarding for static int member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53627 --- Comment #8 from Daniel Krügler daniel.kruegler at googlemail dot com 2012-06-11 06:47:42 UTC --- (In reply to comment #7) (In reply to comment #4) because that was fixed with C++11 due to http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#712 This situation should no longer require a definition for S::a or S::b. Unless I'm mistaken DR 712 was not fixed in time for C++11, I don't see it in N3290 Agreed, DR 712 is a post-C11 resolution. --- Comment #9 from Daniel Krügler daniel.kruegler at googlemail dot com 2012-06-11 06:48:13 UTC --- (In reply to comment #7) (In reply to comment #4) because that was fixed with C++11 due to http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#712 This situation should no longer require a definition for S::a or S::b. Unless I'm mistaken DR 712 was not fixed in time for C++11, I don't see it in N3290 Agreed, DR 712 is a post-C++11 resolution.
[Bug c++/53629] New: [c++11] spurious uninitialized warning in case of non-static data member initializers.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53629
Bug #: 53629
Summary: [c++11] spurious uninitialized warning in case of
non-static data member initializers.
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vincenzo.innoce...@cern.ch
in case of non-static data member initializers. such as
struct MyConfig_Foo {
const int i=3;
const float f=4.14f;
};
one gets
c++ -O2 -std=gnu++11 Config11.cpp -Wall
Config11.cpp:21:15: warning: non-static const member ‘const int
MyConfig_Foo::i’ in class without a constructor [-Wuninitialized]
const int i=3;
^
Config11.cpp:22:17: warning: non-static const member ‘const float
MyConfig_Foo::f’ in class without a constructor [-Wuninitialized]
const float f=4.14f;
^
which I find incorrect.
[Bug c++/53629] [c++11] spurious uninitialized warning in case of non-static data member initializers.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53629 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-06-11 07:57:31 UTC --- Dup of bug 53594. *** This bug has been marked as a duplicate of bug 53594 ***
[Bug c++/53594] [C++11] Spurious -Wuninitialized warning for member with NSDMI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53594 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC||vincenzo.innocente at cern ||dot ch --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2012-06-11 07:57:31 UTC --- *** Bug 53629 has been marked as a duplicate of this bug. ***
[Bug c++/53594] [C++11] Spurious -Wuninitialized warning for member with NSDMI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53594 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-06-11 Ever Confirmed|0 |1 --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org 2012-06-11 07:59:02 UTC --- Confirmed.
[Bug libstdc++/53630] New: C+11 regex compiler produces SIGSEGV
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53630
Bug #: 53630
Summary: C+11 regex compiler produces SIGSEGV
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bisq...@iki.fi
This simple code produces a segmentation fault. Tested in GCC 4.7.0, GCC 4.6.3,
and Clang 3.1 (where the latter uses libstdc++ from GCC 4.7).
#include regex
int main()
{
std::regex r((go |)((n(orth|))|(s(outh|))|(w(est|))|(e(ast|))),
std::regex::extended);
return 0;
}
Omitting the std::regex::extended option does not make a difference.
Replacing all of the |) with ) makes it compile, but obviously with a
completely different expression. As of now, libstdc++ does not yet support the
'?' operator, so the expression cannot be rewritten as (go
)?((n(orth)?)|(s(outh)?)|(w(est)?)|(e(ast)?)). There is also no non-capturing
grouping operator, so writing e.g. (n(?:orth|)) is not an option.
A minimal regexp that duplicates the crash is: ((a(b|))|x). Simple
reorderings such as ((a(|b))|x) or (x|(a(|b))) do not make a difference.
GDB backtrace below:
(gdb) bt
#0 0x7732cdbd in malloc_consolidate (av=0x77639e60) at
malloc.c:5169
#1 0x7732f2a4 in _int_malloc (av=0x77639e60, bytes=1280) at
malloc.c:4373
#2 0x77331960 in *__GI___libc_malloc (bytes=1280) at malloc.c:3660
#3 0x77b39e6d in operator new(unsigned long) () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4 0x00404ce4 in
__gnu_cxx::new_allocatorstd::__regex::_State::allocate (this=0x7fffe980,
__n=16)
at
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.7/../../../../include/c++/4.7/ext/new_allocator.h:94
#5 0x004046b0 in std::_Vector_basestd::__regex::_State,
std::allocatorstd::__regex::_State ::_M_allocate (this=0x7fffe980,
__n=16)
at
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.7/../../../../include/c++/4.7/bits/stl_vector.h:169
#6 0x00404338 in
_ZNSt6vectorINSt7__regex6_StateESaIS1_EE19_M_emplace_back_auxIJS1_EEEvDpOT_
(this=0x7fffe980, __args=0x7fffe010)
at
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.7/../../../../include/c++/4.7/bits/vector.tcc:402
#7 0x00404270 in
_ZNSt6vectorINSt7__regex6_StateESaIS1_EE12emplace_backIJS1_EEEvDpOT_
(this=0x7fffe980, __args=0x7fffe010)
at
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.7/../../../../include/c++/4.7/bits/vector.tcc:102
#8 0x00403690 in std::vectorstd::__regex::_State,
std::allocatorstd::__regex::_State ::push_back(std::__regex::_State) (
this=0x7fffe980, __x=0x7fffe010) at
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.7/../../../../include/c++/4.7/bits/stl_vector.h:900
#9 0x00403052 in
std::__regex::_Nfa::_M_insert_subexpr_begin(std::functionvoid
(std::__regex::_PatternCursor const, std::__regex::_Results) const)
(this=0x7fffe978, __t=...) at
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.7/../../../../include/c++/4.7/bits/regex_nfa.h:312
#10 0x0040848f in std::__regex::_Compilerchar const*,
std::regex_traitschar ::_M_atom (this=0x7fffe928)
at
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.7/../../../../include/c++/4.7/bits/regex_compiler.h:943
#11 0x00407b98 in std::__regex::_Compilerchar const*,
std::regex_traitschar ::_M_term (this=0x7fffe928)
at
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.7/../../../../include/c++/4.7/bits/regex_compiler.h:793
#12 0x00405be9 in std::__regex::_Compilerchar const*,
std::regex_traitschar ::_M_alternative (this=0x7fffe928)
at
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.7/../../../../include/c++/4.7/bits/regex_compiler.h:771
#13 0x00403119 in std::__regex::_Compilerchar const*,
std::regex_traitschar ::_M_disjunction (this=0x7fffe928)
at
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.7/../../../../include/c++/4.7/bits/regex_compiler.h:756
#14 0x004084d5 in std::__regex::_Compilerchar const*,
std::regex_traitschar ::_M_atom (this=0x7fffe928)
at
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.7/../../../../include/c++/4.7/bits/regex_compiler.h:945
#15 0x00407b98 in std::__regex::_Compilerchar const*,
std::regex_traitschar ::_M_term (this=0x7fffe928)
at
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.7/../../../../include/c++/4.7/bits/regex_compiler.h:793
#16 0x00405be9 in std::__regex::_Compilerchar const*,
std::regex_traitschar ::_M_alternative (this=0x7fffe928)
at
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.7/../../../../include/c++/4.7/bits/regex_compiler.h:771
#17 0x00405c2f in std::__regex::_Compilerchar const*,
std::regex_traitschar ::_M_alternative (this=0x7fffe928)
at
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.7/../../../../include/c++/4.7/bits/regex_compiler.h:774
#18 0x00403119 in std::__regex::_Compilerchar const*,
std::regex_traitschar ::_M_disjunction
[Bug libstdc++/53630] C+11 regex compiler produces SIGSEGV
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53630 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-11 08:29:50 UTC --- Documented as missing in http://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2011 The whole of Clause 28 is partially supported or not supported at all. i.e. regex DOESN'T WORK! There's really no point reporting bugs against unimplemented functionality.
[Bug libstdc++/53631] New: [C++11] regex is unimplemented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53631 Bug #: 53631 Summary: [C++11] regex is unimplemented Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org This is a placeholder bug for the missing regex functionality. It's documented as missing in http://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2011 The whole of Clause 28 is partially supported or not supported at all. Until someone works on it there is really no point reporting bugs against individual features.
[Bug libstdc++/53630] C+11 regex compiler produces SIGSEGV
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53630 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-11 08:36:29 UTC --- . *** This bug has been marked as a duplicate of bug 53631 ***
[Bug libstdc++/52719] C++11 std::regex is broken compiling simple regular expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52719 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-11 08:36:34 UTC --- . *** This bug has been marked as a duplicate of bug 53631 ***
[Bug libstdc++/53622] C++11 regex captures extra characters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53622 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-11 08:36:39 UTC --- . *** This bug has been marked as a duplicate of bug 53631 ***
[Bug libstdc++/49870] regex_match vs. ^
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49870 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-11 08:36:51 UTC --- . *** This bug has been marked as a duplicate of bug 53631 ***
[Bug libstdc++/53631] [C++11] regex is unimplemented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53631 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||bisqwit at iki dot fi CC||rleigh at debian dot org CC||whatmannerofburgeristhis at ||gmail dot com CC||bkoz at gcc dot gnu.org --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-11 08:36:29 UTC --- *** Bug 53630 has been marked as a duplicate of this bug. *** --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-11 08:36:34 UTC --- *** Bug 52719 has been marked as a duplicate of this bug. *** --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-11 08:36:40 UTC --- *** Bug 53622 has been marked as a duplicate of this bug. *** --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-11 08:36:51 UTC --- *** Bug 49870 has been marked as a duplicate of this bug. ***
[Bug libstdc++/53631] [C++11] regex is unimplemented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53631 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||bisqwit at iki dot fi CC||rleigh at debian dot org CC||whatmannerofburgeristhis at ||gmail dot com CC||bkoz at gcc dot gnu.org --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-11 08:36:29 UTC --- *** Bug 53630 has been marked as a duplicate of this bug. *** --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-11 08:36:34 UTC --- *** Bug 52719 has been marked as a duplicate of this bug. *** --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-11 08:36:40 UTC --- *** Bug 53622 has been marked as a duplicate of this bug. *** --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-11 08:36:51 UTC --- *** Bug 49870 has been marked as a duplicate of this bug. ***
[Bug libstdc++/53631] [C++11] regex is unimplemented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53631 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||bisqwit at iki dot fi CC||rleigh at debian dot org CC||whatmannerofburgeristhis at ||gmail dot com CC||bkoz at gcc dot gnu.org --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-11 08:36:29 UTC --- *** Bug 53630 has been marked as a duplicate of this bug. *** --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-11 08:36:34 UTC --- *** Bug 52719 has been marked as a duplicate of this bug. *** --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-11 08:36:40 UTC --- *** Bug 53622 has been marked as a duplicate of this bug. *** --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-11 08:36:51 UTC --- *** Bug 49870 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/32629] missing CSE for constant in registers / inefficient memset
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32629 --- Comment #3 from rguenther at suse dot de rguenther at suse dot de 2012-06-11 08:39:45 UTC --- On Sat, 9 Jun 2012, hubicka at ucw dot cz wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32629 --- Comment #2 from Jan Hubicka hubicka at ucw dot cz 2012-06-09 22:17:07 UTC --- I suppose doing the $0x0 optimization should be done post-reload. I was wondering how to implement this nice for some years already I don't see how this can be done without specialized pass, really, and the interface is probably going to be bit weird, since it is very weird property of x86 instruction set that there are no stores with short immediate... I wonder if we can use a peephole2 and DF information (and update it on-the-fly). Thus, when seeing mov $0, ... mov $0, ... transform it incrementally to xor %eax, %eax mov %eax, ... mov $0, ... and then have a 2nd peephole2 with higher priority that looks for a register with zero content (eh ... that's the interesting part ;)) and do xor %eax, %eax mov %eax, ... mov %eax, ... I suppose we have the first peephole already - though we'd end up with xor %eax, %eax mov %eax, ... xor %eax, %eax mov %eax, ... and rely on postreload-cse to clean that up (which isn't run after the peephole2 in postreload queue ...) Richard.
[Bug c++/53594] [C++11] Spurious -Wuninitialized warning for member with NSDMI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53594 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2012-06-11 08:57:57 UTC --- Created attachment 27602 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27602 gcc48-pr53594.patch Untested fix.
[Bug bootstrap/51969] [4.6 regression] trunk gcc unable to build gcc 4.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51969 --- Comment #8 from jye2 at gcc dot gnu.org 2012-06-11 09:10:17 UTC --- Author: jye2 Date: Mon Jun 11 09:10:07 2012 New Revision: 188381 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188381 Log: 2012-06-11 Joey Ye joey...@arm.com Backport r184089,184180 from mainline 2012-02-10 Jan Hubicka j...@suse.cz PR middle-end/48600 * predict.c (predict_paths_for_bb): Prevent looping. (predict_paths_leading_to_edge, predict_paths_leading_to): Update. 2012-02-13 Jan Hubicka j...@suse.cz PR middle-end/52214 * predict.c (predict_paths_for_bb): Fix thinko in prevoius patch. Backport partly r181172 from mainline 2011-11-08 Michael Matz m...@suse.de PR bootstrap/51969 * gengtype.c (write_field_root): Avoid out-of-scope access of newv. testsuite: Backport r184089 from mainline 2012-02-10 Jan Hubicka j...@suse.cz PR middle-end/48600 * g++.dg/torture/pr48600.C: New testcase. Added: branches/ARM/embedded-4_6-branch/gcc/testsuite/c-c++-common/pr52181.c branches/ARM/embedded-4_6-branch/gcc/testsuite/g++.dg/torture/pr48600.C Modified: branches/ARM/embedded-4_6-branch/gcc/ChangeLog.arm branches/ARM/embedded-4_6-branch/gcc/gengtype.c branches/ARM/embedded-4_6-branch/gcc/predict.c branches/ARM/embedded-4_6-branch/gcc/testsuite/ChangeLog.arm
[Bug middle-end/52214] [4.7 Regression] FAIL: g++.dg/tree-ssa/pr44706.C -std=gnu++* scan-tree-dump-not fnsplit Splitting function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52214 --- Comment #5 from jye2 at gcc dot gnu.org 2012-06-11 09:10:16 UTC --- Author: jye2 Date: Mon Jun 11 09:10:07 2012 New Revision: 188381 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188381 Log: 2012-06-11 Joey Ye joey...@arm.com Backport r184089,184180 from mainline 2012-02-10 Jan Hubicka j...@suse.cz PR middle-end/48600 * predict.c (predict_paths_for_bb): Prevent looping. (predict_paths_leading_to_edge, predict_paths_leading_to): Update. 2012-02-13 Jan Hubicka j...@suse.cz PR middle-end/52214 * predict.c (predict_paths_for_bb): Fix thinko in prevoius patch. Backport partly r181172 from mainline 2011-11-08 Michael Matz m...@suse.de PR bootstrap/51969 * gengtype.c (write_field_root): Avoid out-of-scope access of newv. testsuite: Backport r184089 from mainline 2012-02-10 Jan Hubicka j...@suse.cz PR middle-end/48600 * g++.dg/torture/pr48600.C: New testcase. Added: branches/ARM/embedded-4_6-branch/gcc/testsuite/c-c++-common/pr52181.c branches/ARM/embedded-4_6-branch/gcc/testsuite/g++.dg/torture/pr48600.C Modified: branches/ARM/embedded-4_6-branch/gcc/ChangeLog.arm branches/ARM/embedded-4_6-branch/gcc/gengtype.c branches/ARM/embedded-4_6-branch/gcc/predict.c branches/ARM/embedded-4_6-branch/gcc/testsuite/ChangeLog.arm
[Bug middle-end/48600] [4.6 Regression] ICE when using cold attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48600 --- Comment #22 from jye2 at gcc dot gnu.org 2012-06-11 09:10:14 UTC --- Author: jye2 Date: Mon Jun 11 09:10:07 2012 New Revision: 188381 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188381 Log: 2012-06-11 Joey Ye joey...@arm.com Backport r184089,184180 from mainline 2012-02-10 Jan Hubicka j...@suse.cz PR middle-end/48600 * predict.c (predict_paths_for_bb): Prevent looping. (predict_paths_leading_to_edge, predict_paths_leading_to): Update. 2012-02-13 Jan Hubicka j...@suse.cz PR middle-end/52214 * predict.c (predict_paths_for_bb): Fix thinko in prevoius patch. Backport partly r181172 from mainline 2011-11-08 Michael Matz m...@suse.de PR bootstrap/51969 * gengtype.c (write_field_root): Avoid out-of-scope access of newv. testsuite: Backport r184089 from mainline 2012-02-10 Jan Hubicka j...@suse.cz PR middle-end/48600 * g++.dg/torture/pr48600.C: New testcase. Added: branches/ARM/embedded-4_6-branch/gcc/testsuite/c-c++-common/pr52181.c branches/ARM/embedded-4_6-branch/gcc/testsuite/g++.dg/torture/pr48600.C Modified: branches/ARM/embedded-4_6-branch/gcc/ChangeLog.arm branches/ARM/embedded-4_6-branch/gcc/gengtype.c branches/ARM/embedded-4_6-branch/gcc/predict.c branches/ARM/embedded-4_6-branch/gcc/testsuite/ChangeLog.arm
[Bug c++/53620] Compiler segfaults when compiling Digikam
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53620 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||DUPLICATE --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2012-06-11 09:14:46 UTC --- Sounds like dup of PR53599. *** This bug has been marked as a duplicate of bug 53599 ***
[Bug c++/53599] [4.7/4.8 Regression] gcc-4.7.1_rc20120606 segfaults compiling boost.karma
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53599 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||rohangarg at ubuntu dot com --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2012-06-11 09:14:46 UTC --- *** Bug 53620 has been marked as a duplicate of this bug. ***
[Bug c++/53594] [C++11] Spurious -Wuninitialized warning for member with NSDMI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53594 --- Comment #6 from vincenzo Innocente vincenzo.innocente at cern dot ch 2012-06-11 09:28:49 UTC --- the patch compiles and fixes my test case, I've not tested any possible side effects
[Bug web/53632] New: [bugzilla] Bugzilla being very slow to submit changes, sending duplicate emails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53632 Bug #: 53632 Summary: [bugzilla] Bugzilla being very slow to submit changes, sending duplicate emails Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: web AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org CC: lpso...@netscape.net For the past week or two Bugzilla has been very slow to submit updates or new bugs, and when several changes happen to a PR in quick succession the emails contain multiple updates and so duplicate information. Here there are three emails each containing the same three changes: http://gcc.gnu.org/ml/gcc-bugs/2012-06/msg00561.html http://gcc.gnu.org/ml/gcc-bugs/2012-06/msg00563.html http://gcc.gnu.org/ml/gcc-bugs/2012-06/msg00564.html Here there are three emails for two changes: http://gcc.gnu.org/ml/gcc-bugs/2012-06/msg5.html http://gcc.gnu.org/ml/gcc-bugs/2012-06/msg6.html http://gcc.gnu.org/ml/gcc-bugs/2012-06/msg7.html
[Bug middle-end/53623] [4.7/4.8 Regression] sign extension is effectively split into two x86-64 instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53623
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Depends on||50176
Target Milestone|--- |4.7.2
--- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2012-06-11
09:47:15 UTC ---
Forwprop does
--- t.c.024t.ccp1 2012-06-11 11:32:13.791164397 +0200
+++ t.c.025t.forwprop1 2012-06-11 11:32:13.792164397 +0200
@@ -11,7 +11,7 @@
bb 2:
D.1751_2 = code[rdx_1(D)];
rdx_3 = (int64_t) D.1751_2;
- inst_4 = (uint8_t) rdx_3;
+ inst_4 = (uint8_t) D.1751_2;
rdx_5 = rdx_3 8;
D.1752_6 = (int) inst_4;
D.1753_7 = dispatch[D.1752_6];
making D.1751_2 no longer single-use and thus no longer triggering combine.
Indeed looks related to 50176.
But while we certainly can teach forwprop to only consider single-use
chains (to never possibly cause this issue) it isn't a good solution.
In fact for properly optimizing this we need to know whether cheap
sub-reg like accesses are possible (combining (int) (uint8_t) (int64_t)
code[rdx_1] to simply extending the lower part of (int64_t) code[rdx_1]
without explicit truncation). This seems more fit for an RTL optimization
pass than for a tree pass if consider the forwprop optimization be done
in source like
#include stdint.h
typedef (*inst_t)(int64_t rdi, int64_t rsi, int64_t rdx);
int16_t code[256];
inst_t dispatch[256];
void an_inst(int64_t rdi, int64_t rsi, int64_t rdx) {
uint8_t inst;
inst = (uint8_t) code[rdx];
rdx = code[rdx];
rdx = 8;
dispatch[inst](rdi, rsi, rdx);
}
int main(void) {
return 0;
}
which you could easily get from some level of abstraction.
[Bug middle-end/53616] [4.8 Regression] 416.gamess in SPEC CPU 2006 miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53616 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-06-11 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-06-11 09:48:04 UTC --- Mine.
[Bug c++/53605] [4.7/4.8 Regression] Compiler ICEs in size_binop_loc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53605 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-06-11 09:49:04 UTC --- Mine.
[Bug tree-optimization/51466] [4.7 Regression] ICE in gimple_rhs_has_side_effects,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51466 --- Comment #7 from xuepeng guo xguo at gcc dot gnu.org 2012-06-11 09:51:11 UTC --- Author: xguo Date: Mon Jun 11 09:51:05 2012 New Revision: 188383 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188383 Log: 2012-06-11 Terry Guo terry@arm.com Backport from mainline 2011-12-08 Jakub Jelinek ja...@redhat.com PR tree-optimization/51466 * tree-ssa-forwprop.c (forward_propagate_addr_expr_1): Also copy TREE_SIDE_EFFECTS. 2011-11-28 Jakub Jelinek ja...@redhat.com PR tree-optimization/50078 * tree-ssa-forwprop.c (forward_propagate_addr_expr_1): Copy over TREE_THIS_VOLATILE also from the old to new lhs resp. rhs. Added: branches/ARM/embedded-4_6-branch/gcc/testsuite/gcc.c-torture/execute/pr51466.c branches/ARM/embedded-4_6-branch/gcc/testsuite/gcc.dg/pr50078.c Modified: branches/ARM/embedded-4_6-branch/gcc/ChangeLog.arm branches/ARM/embedded-4_6-branch/gcc/testsuite/ChangeLog.arm branches/ARM/embedded-4_6-branch/gcc/tree-ssa-forwprop.c
[Bug tree-optimization/50078] [4.6 Regression] combine wrong code: volatile accesses optimized out
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50078 --- Comment #16 from xuepeng guo xguo at gcc dot gnu.org 2012-06-11 09:51:12 UTC --- Author: xguo Date: Mon Jun 11 09:51:05 2012 New Revision: 188383 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188383 Log: 2012-06-11 Terry Guo terry@arm.com Backport from mainline 2011-12-08 Jakub Jelinek ja...@redhat.com PR tree-optimization/51466 * tree-ssa-forwprop.c (forward_propagate_addr_expr_1): Also copy TREE_SIDE_EFFECTS. 2011-11-28 Jakub Jelinek ja...@redhat.com PR tree-optimization/50078 * tree-ssa-forwprop.c (forward_propagate_addr_expr_1): Copy over TREE_THIS_VOLATILE also from the old to new lhs resp. rhs. Added: branches/ARM/embedded-4_6-branch/gcc/testsuite/gcc.c-torture/execute/pr51466.c branches/ARM/embedded-4_6-branch/gcc/testsuite/gcc.dg/pr50078.c Modified: branches/ARM/embedded-4_6-branch/gcc/ChangeLog.arm branches/ARM/embedded-4_6-branch/gcc/testsuite/ChangeLog.arm branches/ARM/embedded-4_6-branch/gcc/tree-ssa-forwprop.c
[Bug ada/53590] new compiler generates both SISD and SIMD instructions for parallel operations of a pure function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53590 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-06-11 Ever Confirmed|0 |1
[Bug ada/53590] new compiler generates both SISD and SIMD instructions for parallel operations of a pure function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53590 --- Comment #3 from Georg georggcc at googlemail dot com 2012-06-11 10:09:18 UTC --- (In reply to comment #2) Other versions of the Ada compiler, and the C compiler, and the C++ compiler of the same version produce 1 DIVPD instruction, as expected. Which other versions of the Ada compiler exactly? For example, GNAT GPL 2011 on Mac OS X 10.7.4; I get (that's the version of the source text with none of the pragmas in effect) $ gnatchop -r -w ../autovect.ada gnatmake -gnatwa -W -O3 -fno-inline -fomit-frame-pointer -msse3 -march=core2 -gnatp -gnata -v -mfpmath=sse -f autovect.adb splitting ../autovect.ada into: autovect.ads autovect.adb GNATMAKE GPL 2011 (20110419) Copyright (C) 1995-2011, Free Software Foundatio machine_attribute n, Inc. gcc -c -gnatwa -W -O3 -fno-inline -fomit-frame-pointer -msse3 -march=core2 -gnatp -gnata -mfpmath=sse autovect.adb End of compilation $ otool -tv autovect.o autovect.o: (__TEXT,__text) section _autovect__TvecBIP: ret 0001nop 0002nopl0x(%rax) 0009nopl0x(%rax) _autovect__f: 0010unpcklpd%xmm1,%xmm0 0014unpcklpd%xmm3,%xmm2 0018divpd%xmm2,%xmm0 001cmovapd%xmm0,0xe8(%rsp) 0022movsd0xe8(%rsp),%xmm0 0028movsd0xf0(%rsp),%xmm1 002eret 002fnop _autovect___elabs: 0030subq$0x18,%rsp 0034leaq0x0015(%rip),%rdi 003bleaq0x001e(%rip),%rsi 0042movq%rdi,(%rsp) 0046movq%rsi,0x08(%rsp) 004bcallq0x0050 $ sysctl machdep.cpu ... machdep.cpu.brand_string: Intel(R) Core(TM)2 Duo CPU E8135 @ 2.40GHz machdep.cpu.features: FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM PBE SSE3 DTES64 MON DSCPL VMX EST TM2 SSSE3 CX16 TPR PDCM SSE4.1 machdep.cpu.extfeatures: SYSCALL XD EM64T LAHF I'll double check more running on an Intel Core i7 tonight.
[Bug ada/53592] ICE when hitting assigment to component of SSE vector_type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53592
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-06-11
CC||rguenth at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-06-11
10:15:22 UTC ---
The gimplifier marks 'result' as DECL_GIMPLE_REG_P here:
/* Gimplify a BIND_EXPR. Just voidify and recurse. */
static enum gimplify_status
gimplify_bind_expr (tree *expr_p, gimple_seq *pre_p)
{
...
/* Preliminarily mark non-addressed complex variables as eligible
for promotion to gimple registers. We'll transform their uses
as we find them. */
if ((TREE_CODE (TREE_TYPE (t)) == COMPLEX_TYPE
|| TREE_CODE (TREE_TYPE (t)) == VECTOR_TYPE)
!TREE_THIS_VOLATILE (t)
(TREE_CODE (t) == VAR_DECL !DECL_HARD_REGISTER (t))
!needs_to_live_in_memory (t))
DECL_GIMPLE_REG_P (t) = 1;
which means it expects the Frontends to have marked 'result' as
TREE_ADDRESSABLE
if they assign to it in this way. GENERIC from the frontend looks like
Ssa_View.Test_View_Ssa_Lhs (const ssa_view__fpt x0, const ssa_view__fpt x1)
{
ssa_view__vec result;
ssa_view__vec result;
VIEW_CONVERT_EXPRssa_view__fpt[2](result)[0] = (ssa_view__fpt) x0;
return result;
}
another possibility is, as the comment explains, that this is supposed to
be done for COMPLEX_TYPE only, as only component-accesses to those are
transformed properly. But note that an access like the above, via
a VIEW_CONVERTed type are not necessarily handled.
Well. Confirmed.
[Bug c++/53613] Cannot override a inline = default virtual destructor.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53613 --- Comment #3 from Kirby Zhou kirbyz...@sogou-inc.com 2012-06-11 10:15:58 UTC --- (In reply to comment #1) Fixed on trunk by patch for PR 50043 Did this patch apply to 4.7 branch? I retested with 4.7 branch 20120610, The bug is still exist.
[Bug c++/53613] Cannot override a inline = default virtual destructor.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53613 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-11 10:28:40 UTC --- (In reply to comment #3) (In reply to comment #1) Fixed on trunk by patch for PR 50043 Did this patch apply to 4.7 branch? PR 50043 shows a single commit to trunk and has Target Milestone 4.8.0, so no, it's only fixed on trunk. I retested with 4.7 branch 20120610, The bug is still exist. Yes, and it probably won't be fixed on the release branch as it's not a regression. New features are not usually added to released versions. In any case, there's a simple workaround of adding explicit 'noexcept' specifiers, which will still work with 4.8 I'm marking this as a dup of PR 50043 as the failure to compile is a direct consequence of not implementing DR 1123 *** This bug has been marked as a duplicate of bug 50043 ***
[Bug c++/50043] [C++0x] Implement core/1123
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50043 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||kirbyz...@sogou-inc.com --- Comment #12 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-11 10:28:40 UTC --- *** Bug 53613 has been marked as a duplicate of this bug. ***
[Bug ada/53590] new compiler generates both SISD and SIMD instructions for parallel operations of a pure function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53590 --- Comment #4 from Georg georggcc at googlemail dot com 2012-06-11 10:31:00 UTC --- (In reply to comment #3) (In reply to comment #2) Other versions of the Ada compiler, and the C compiler, and the C++ compiler of the same version produce 1 DIVPD instruction, as expected. Which other versions of the Ada compiler exactly? For example, GNAT GPL 2011 on Mac OS X 10.7.4; Small note: Same sequence of instructions from GNAT GPL 2011 running on x86_64 Linux/GNU: 0010 autovect__f: 10:66 0f 14 c1 unpcklpd %xmm1,%xmm0 14:66 0f 14 d3 unpcklpd %xmm3,%xmm2 18:66 0f 5e c2 divpd %xmm2,%xmm0 1c:66 0f 29 44 24 e8movapd %xmm0,-0x18(%rsp) 22:f2 0f 10 44 24 e8movsd -0x18(%rsp),%xmm0 28:f2 0f 10 4c 24 f0movsd -0x10(%rsp),%xmm1 2e:c3 retq 2f:90 nop Intel(R) Xeon(R) CPU E5645 @ 2.40GHz
[Bug c++/53605] [4.7/4.8 Regression] Compiler ICEs in size_binop_loc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53605
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-06-11
10:37:50 UTC ---
Empty arrays have a signed domain with [0, -1] range. So write_array_type
has to be adjusted to
Index: gcc/cp/mangle.c
===
--- gcc/cp/mangle.c (revision 188384)
+++ gcc/cp/mangle.c (working copy)
@@ -3119,7 +3119,8 @@ write_array_type (const tree type)
{
/* The ABI specifies that we should mangle the number of
elements in the array, not the largest allowed index. */
- max = size_binop (PLUS_EXPR, max, size_one_node);
+ max = size_binop (PLUS_EXPR, max,
+ build_int_cst (TREE_TYPE (max), 1));
write_unsigned_number (tree_low_cst (max, 1));
}
else
or
Index: gcc/cp/mangle.c
===
--- gcc/cp/mangle.c (revision 188384)
+++ gcc/cp/mangle.c (working copy)
@@ -3119,8 +3119,10 @@ write_array_type (const tree type)
{
/* The ABI specifies that we should mangle the number of
elements in the array, not the largest allowed index. */
- max = size_binop (PLUS_EXPR, max, size_one_node);
- write_unsigned_number (tree_low_cst (max, 1));
+ double_int dmax
+ = double_int_add (tree_to_double_int (max), double_int_one);
+ gcc_assert (double_int_fits_in_uhwi_p (dmax));
+ write_unsigned_number (dmax.low);
}
else
{
but I wonder about the inconsistency between the max == INTEGER_CST and
!INTEGER_CST case where we do _not_ add one to the expression to be mangled.
I'll give the double-int variant testing.
[Bug ada/53590] compiler fails to generate SIMD instruction for FP division
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53590 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |UNCONFIRMED Summary|new compiler generates both |compiler fails to generate |SISD and SIMD instructions |SIMD instruction for FP |for parallel operations of |division |a pure function | Ever Confirmed|1 |0 --- Comment #5 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-06-11 10:39:38 UTC --- Small note: Same sequence of instructions from GNAT GPL 2011 running on x86_64 Linux/GNU: You're comparing apples with oranges though, that isn't the same compiler.
[Bug tree-optimization/36602] memset should be optimized into an empty CONSTRUCTOR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36602 --- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2012-06-11 10:58:41 UTC --- Ok. I suppose I need to fix gcc.target/x86_64/abi/test_struct_returning.c somehow then ... :/
[Bug ada/53590] compiler fails to generate SIMD instruction for FP division
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53590 --- Comment #6 from Georg georggcc at googlemail dot com 2012-06-11 10:59:41 UTC --- (In reply to comment #5) Small note: Same sequence of instructions from GNAT GPL 2011 running on x86_64 Linux/GNU: You're comparing apples with oranges though, that isn't the same compiler. OK. Although, this supports even more what I said, Other versions of the Ada compiler... ;-) That wasn't particularly clear; the C compiler and the C++ compiler used for comparing things on the machine are form the very same build (4.8.0 20120525), though.
[Bug web/53632] [bugzilla] Bugzilla being very slow to submit changes, sending duplicate emails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53632 --- Comment #1 from Frédéric Buclin LpSolit at netscape dot net 2012-06-11 11:04:57 UTC --- I did no changes to the Bugzilla code for almost two months, so I guess the problem is external to Bugzilla. Based on duplicated comments in emails, I suspect the mail server is slow these days, and so subsequent changes to bugs happen before all emails had the time to be sent. In that case, Bugzilla assumes all emails should be resent to avoid some email loss. Is there some problem with the SMTP server these days (e.g. heavy load)? This would explain it.
[Bug web/53632] [bugzilla] Bugzilla being very slow to submit changes, sending duplicate emails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53632 --- Comment #2 from Frédéric Buclin LpSolit at netscape dot net 2012-06-11 11:06:57 UTC --- Wow, Bugzilla is indeed very slow, even when sending two emails only.
[Bug middle-end/53433] [4.8 Regression] ICE in int_mode_for_mode, at stor-layout.c:424 during lto-bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53433 --- Comment #17 from Richard Guenther rguenth at gcc dot gnu.org 2012-06-11 11:09:17 UTC --- I can reproduce it on SLE11-SP2, glibc-2.11.3, with plain ./configure --with-build-config=bootstrap-lto. Honza? I suppose we have spurious DECL_EXTERNAL somewhere? extern inline fns maybe?
[Bug web/53632] [bugzilla] Bugzilla being very slow to submit changes, sending duplicate emails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53632 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-11 11:16:38 UTC --- Yeah :-) It's got _really_ slow. I don't remember which day it happened, but it was a very noticeable sudden change from reasonably responsive to very slow. After updating bugzilla in one browser tab/window if you hit refresh on the gcc-bugs list archive (http://gcc.gnu.org/ml/gcc-bugs/current/) in another tab/window you can see the mail from bugzilla arrive fairly quickly, but it takes much longer for the bugzilla page to finish submitting (in fact I believe it has finished submitting but is still waiting for something before reloading the next page.) I don't have access to the GCC server to see where the delay or load is, but it could be similar to the wiki-slowness described at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53257 which is related to delays sending emails.
[Bug web/53632] [bugzilla] Bugzilla being very slow to submit changes, sending duplicate emails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53632 Frédéric Buclin LpSolit at netscape dot net changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-06-11 Ever Confirmed|0 |1 --- Comment #4 from Frédéric Buclin LpSolit at netscape dot net 2012-06-11 11:25:17 UTC --- (In reply to comment #3) After updating bugzilla in one browser tab/window if you hit refresh on the gcc-bugs list archive (http://gcc.gnu.org/ml/gcc-bugs/current/) in another tab/window you can see the mail from bugzilla arrive fairly quickly, but it takes much longer for the bugzilla page to finish submitting Ah, that's very interesting. I could try to debug this problem, but this means I would have to spam this bug a bit to see where the slowness comes from. Is that acceptable?
[Bug web/53632] [bugzilla] Bugzilla being very slow to submit changes, sending duplicate emails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53632 --- Comment #5 from Frédéric Buclin LpSolit at netscape dot net 2012-06-11 11:36:20 UTC --- fche told me on IRC that jobqueue has been disabled two weeks ago, which is exactly when the slowness started to appear. So it may still be mail-related. But a SMTP server shouldn't need more than a few seconds to send only 2 emails. fche also told me that the SMTP server is doing some spam checks for outgoing emails. I wonder if that could be the reason. Still investigating...
[Bug web/53632] [bugzilla] Bugzilla being very slow to submit changes, sending duplicate emails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53632 --- Comment #6 from Frédéric Buclin LpSolit at netscape dot net 2012-06-11 11:46:26 UTC --- He just told me that the checks for outgoing emails take between 2 and 10 seconds *per email*! I think we found the culprit. Either the scan must be optimized (e.g. whitelist GCC Bugzilla to not scan emails sent by it) or jobqueue must be re-enabled. In both cases, I cannot do anything myself.
[Bug c/53633] New: __attribute__((naked)) should disable -Wreturn-type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53633
Bug #: 53633
Summary: __attribute__((naked)) should disable -Wreturn-type
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bernhard.rosenkran...@linaro.org
This code:
__attribute__((naked))
int test() {
asm(mov r0, #1);
}
triggers a control reaches end of non-void function warning (or error, if
-Werror is used).
IMO this warning should be omitted, given __attribute__((naked)) is meant to
tell the compiler that asm code inside takes care of everything.
[Bug web/53632] [bugzilla] Bugzilla being very slow to submit changes, sending duplicate emails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53632 --- Comment #7 from Frédéric Buclin LpSolit at netscape dot net 2012-06-11 12:03:19 UTC --- fche says that some spammers create a Bugzilla account to send spam, which is why these spam checks are enabled for outgoing emails. So to mitigate the problem till jobqueue is re-enabled, one alternative could be to whitelist emails sent by @gcc.gnu.org users, as those users are trusted people. We could even extend this whitelist to all users having editbugs privs, as you need to be a trusted user to get such privileges. This way, only user accounts with no privileges would see the slowness due to these checks, including spammers. From a technical point of view, the email server should look at the X-Bugzilla-Who header, which contains the email address of the user responsible for the email to be sent. If it's a trusted user, just send the email without scanning it. This header cannot be abused by spammers.
[Bug middle-end/53623] [4.7/4.8 Regression] sign extension is effectively split into two x86-64 instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53623 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2012-06-11 12:20:45 UTC --- This is different from PR50176, at least the incomplete patch there wouldn't do anything for this testcase (the PR50176 problem is QImode and 32-bit IA-32 code with the unavailability of %sil/%dil/%bpl registers). The problem in this PR (at least that we don't generate the same code as 4.6 did) is that the REE pass doesn't do anything here, because of the REGNO (dest) == REGNO (XEXP (src, 0)) check in add_removable_extension. We have (set (reg:HI %ax) (mem:HI (whatever))) (set (reg:DI %rdx) (sign_extend:DI (reg:HI %ax)) (set (reg:DI %rax) (zero_extend:DI (reg:QI %al)) and when processing the sign_extend, we give up because of that failed REGNO == REGNO check, and while we queue the zero_extend, that alone can't be optimized, both as it is a MEM:HI load, not QImode load, and because changing it into movzbl would make the sign extension wrong. Perhaps we could extend the REE pass for this slightly, by allowing REGNO != REGNO, if there is just a single reaching def and the REGNO != REGNO extension is the first use of that reg (i.e. all other uses are dominated by the extension being considered). Then perhaps we could attempt to change the load from loading into reg:HI %ax into sign extending load from HI to reg:DI %rdx, followed by either adding there a (set (reg:DI %rax) (reg:DI %rdx)) move where the sign extension currently is (and hoping some further pass will propagate that into all other uses), or changing all uses (from ax/al to dx/dl) right away.
[Bug debug/53470] [4.8 Regression] ICE when linking with -g in splice_child_die, at dwarf2out.c:4264
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53470
--- Comment #11 from Richard Guenther rguenth at gcc dot gnu.org 2012-06-11
12:38:06 UTC ---
Removing the whole
if (debug_info_level DINFO_LEVEL_TERSE
|| (TYPE_CONTEXT (type)
TREE_CODE (TYPE_CONTEXT (type)) != FUNCTION_DECL
TREE_CODE (TYPE_CONTEXT (type)) != NAMESPACE_DECL))
TYPE_CONTEXT (type) = NULL_TREE;
block causes us to ICE for gcc.c-torture/execute/20111208-1.c and
gcc.c-torture/execute/pr42833.c
Even though I think that would be the correct thing to do.
Reduced testcase for that ICE:
int main ()
{
{
union { } v;
}
}
works with
int main ()
{
union { } v;
}
[Bug debug/53470] [4.8 Regression] ICE when linking with -g in splice_child_die, at dwarf2out.c:4264
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53470
--- Comment #12 from Richard Guenther rguenth at gcc dot gnu.org 2012-06-11
12:54:50 UTC ---
It seems we never come along with a DECL_CONTEXT that is a BLOCK (nor does
the C++ frontend do that ...). Replacing the TYPE_CONTEXT clearing with
if (TYPE_CONTEXT (type)
TREE_CODE (TYPE_CONTEXT (type)) == BLOCK)
{
tree ctx = TYPE_CONTEXT (type);
do
{
ctx = BLOCK_SUPERCONTEXT (ctx);
}
while (ctx TREE_CODE (ctx) == BLOCK);
TYPE_CONTEXT (type) = ctx;
}
thus, replace a BLOCK context with the first non-BLOCK context, works.
[Bug web/53632] [bugzilla] Bugzilla being very slow to submit changes, sending duplicate emails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53632 --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-11 13:03:46 UTC --- (In reply to comment #7) fche says that some spammers create a Bugzilla account to send spam, Yes, we've had a few attacks recently. Thanks for identifying the problem so quickly!
[Bug debug/53470] [4.8 Regression] ICE when linking with -g in splice_child_die, at dwarf2out.c:4264
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53470 --- Comment #13 from Jason Merrill jason at gcc dot gnu.org 2012-06-11 13:37:27 UTC --- (In reply to comment #12) thus, replace a BLOCK context with the first non-BLOCK context, works. That sounds good.
[Bug c++/53605] [4.7/4.8 Regression] Compiler ICEs in size_binop_loc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53605 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org 2012-06-11 13:41:20 UTC --- (In reply to comment #3) but I wonder about the inconsistency between the max == INTEGER_CST and !INTEGER_CST case where we do _not_ add one to the expression to be mangled. Yep, that's what the ABI says. I don't remember why we chose to add one in the constant case.
[Bug target/53621] [SH] Frame pointers not generated with -fno-omit-frame-pointer on GCC 4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53621 chrbr at gcc dot gnu.org changed: What|Removed |Added CC||chrbr at gcc dot gnu.org --- Comment #5 from chrbr at gcc dot gnu.org 2012-06-11 13:48:50 UTC --- I think this used to work, but the option initialization mechanism has changed recently indeed. Disabling it could break some supports for gprof or some old fashioned unwinders that need a frame pointer looking at the configure, it looks like there is no sh target using a different setting for DWARF2_DEBUG. So this line could probably just be removed from here. If an hypothetical target doesn't use DWARF2_DEBUG then maybe it should define SUBTARGET_FRAME_POINTER_REQUIRED to force it. I suspect that a definition like could be needed. #undef SUBTARGET_FRAME_POINTER_REQUIRED #define SUBTARGET_FRAME_POINTER_REQUIRED crtl-profile We need to check in which extend the current gprof is broken without a frame pointer.
[Bug c++/53634] New: Segmentation fault on nested lambda + template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53634
Bug #: 53634
Summary: Segmentation fault on nested lambda + template
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mail+...@tzik.jp
Hi.
I encountered a segmentation fault when I compile following code on gcc-4.5.3
and gcc-4.6.3:
templatetypename T
void hoge(T) {
}
int main(int, char**) {
hoge([](){return [](){};}());
return 0;
}
[Bug middle-end/53616] [4.8 Regression] 416.gamess in SPEC CPU 2006 miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53616 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-06-11 13:58:38 UTC --- Author: rguenth Date: Mon Jun 11 13:58:29 2012 New Revision: 188386 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188386 Log: 2012-06-11 Richard Guenther rguent...@suse.de PR c++/53616 * mangle.c (write_array_type): Use double-ints for array domain arithmetic. * g++.dg/ext/pr53605.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/ext/pr53605.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/mangle.c trunk/gcc/testsuite/ChangeLog
[Bug c++/53605] [4.7 Regression] Compiler ICEs in size_binop_loc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53605 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.8.0 Summary|[4.7/4.8 Regression]|[4.7 Regression] Compiler |Compiler ICEs in|ICEs in size_binop_loc |size_binop_loc | --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2012-06-11 14:10:59 UTC --- Fixed on trunk sofar.
[Bug debug/53470] [4.8 Regression] ICE when linking with -g in splice_child_die, at dwarf2out.c:4264
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53470 --- Comment #14 from Richard Guenther rguenth at gcc dot gnu.org 2012-06-11 14:14:15 UTC --- Author: rguenth Date: Mon Jun 11 14:14:09 2012 New Revision: 188387 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188387 Log: 2012-06-11 Richard Guenther rguent...@suse.de PR middle-end/53470 * tree.c (free_lang_data_in_type): Do not clear TYPE_CONTEXT but replace it with the first non-BLOCK context. * g++.dg/lto/pr53470_0.C: New testcase. * gcc.dg/lto/pr53470_0.c: Likewise. Added: trunk/gcc/testsuite/g++.dg/lto/pr53470_0.C trunk/gcc/testsuite/gcc.dg/lto/pr53470_0.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.c
[Bug debug/53470] [4.8 Regression] ICE when linking with -g in splice_child_die, at dwarf2out.c:4264
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53470 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #15 from Richard Guenther rguenth at gcc dot gnu.org 2012-06-11 14:16:22 UTC --- Fixed.
[Bug c++/53605] [4.7 Regression] Compiler ICEs in size_binop_loc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53605 --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2012-06-11 14:22:41 UTC --- Bah, commit (I fixed up the ChangeLog already): Author: rguenth Date: Mon Jun 11 13:58:29 2012 New Revision: 188386 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188386 Log: 2012-06-11 Richard Guenther rguent...@suse.de PR c++/53616 * mangle.c (write_array_type): Use double-ints for array domain arithmetic. * g++.dg/ext/pr53605.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/ext/pr53605.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/mangle.c trunk/gcc/testsuite/ChangeLog
[Bug c++/52014] [c++0x] g++: Segfault When `decltype` Used in Nested Lambda Function Defined in Class Member Function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52014 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-06-11 Ever Confirmed|0 |1 Known to fail||4.7.0, 4.8.0 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-11 14:45:39 UTC --- Confirmed. Is helper::type supposed to be public?
[Bug c++/53634] Segmentation fault on nested lambda + template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53634 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-11 14:47:55 UTC --- Fixed on trunk, probably a dup of PR 47687 (Please search for existing bugs and if possible try a newer release, especially when there are several existing nested lambda bugs which are fixed in 4.7.0)
[Bug bootstrap/53635] New: --enable-build-with-cxx: stage1-gcc shrinks from 1.1 GiB to 0.4 GiB
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53635 Bug #: 53635 Summary: --enable-build-with-cxx: stage1-gcc shrinks from 1.1 GiB to 0.4 GiB Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: tschwi...@gcc.gnu.org Blocks: 44433 Host: i686-pc-linux-gnu Target: i686-pc-linux-gnu Build: i686-pc-linux-gnu As reported in http://gcc.gnu.org/ml/gcc/2012-06/msg00107.html: when --enable-build-with-cxx is enabled, the size of the build directory stage1-gcc shrinks (!) from 1.1 GiB to 0.4 GiB, such that the whole build tree then occupies 2.6 GiB instead of 3.2 GiB. I did notice that the C build uses -fkeep-inline-functions, and the C++ build doesn't (my logs, and confirmed in the top-level configure.ac), but don't know if that is the (sole) reason; I have not looked at this in more detail -- but 0.6 GiB or 60 % less is quite a bit. This may be a non-issue, but someone should declare it so.
[Bug c++/53602] [4.7/4.8 Regression] Libre Office causes an internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53602 --- Comment #14 from Andrew Benton andy at benton dot eu.com 2012-06-11 15:00:41 UTC --- Many thanks, Libre Office now compiles as expected. Should this bug be marked as fixed?
[Bug libstdc++/53263] priority_queue is very slow if -D_GLIBCXX_DEBUG is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53263 --- Comment #14 from dominik.stras...@onespin-solutions.com 2012-06-11 15:05:43 UTC --- Is there a chance to get this into 4.7.1 ?
[Bug libstdc++/53324] Crash when mixing _GLIBCXX_DEBUG and non-_GLIBCXX_DEBUG std::deque
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53324 --- Comment #3 from dominik.stras...@onespin-solutions.com 2012-06-11 15:10:49 UTC --- I get the point. However, I could imagine that it is a quite common scenario to have a binary contributed C++ lib. Mixing debug/non-debug is impossible due to name mangling, however you can get random behavior if debug-enabled containers are returned. It took me quite a while to find out what was going wrong. Maybe some annotation for the linker could help here. I see that there's a general problem with overloading on function return values, but usually this is under the control of the user.
[Bug c++/53602] [4.7 Regression] Libre Office causes an internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53602 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Summary|[4.7/4.8 Regression] Libre |[4.7 Regression] Libre |Office causes an internal |Office causes an internal |compiler error |compiler error --- Comment #15 from Jakub Jelinek jakub at gcc dot gnu.org 2012-06-11 15:14:54 UTC --- Not yet, because it hasn't been fixed on the 4.7 branch yet.
[Bug c++/53602] [4.7 Regression] Libre Office causes an internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53602 Richard Henderson rth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #16 from Richard Henderson rth at gcc dot gnu.org 2012-06-11 15:18:37 UTC --- Yes it is fixed on the 4.7 branch.
[Bug c++/53602] [4.7 Regression] Libre Office causes an internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53602 --- Comment #17 from Jakub Jelinek jakub at gcc dot gnu.org 2012-06-11 15:22:10 UTC --- Oops, right you are.
[Bug libstdc++/53263] priority_queue is very slow if -D_GLIBCXX_DEBUG is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53263 --- Comment #15 from Paolo Carlini paolo.carlini at oracle dot com 2012-06-11 15:27:17 UTC --- Too late for 4.7.1. Francois, can you please apply the patch to 4_7-branch as soon as 4.7.1 is out, thus for 4.7.2? Thanks!
[Bug libstdc++/53324] Crash when mixing _GLIBCXX_DEBUG and non-_GLIBCXX_DEBUG std::deque
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53324 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-11 15:34:49 UTC --- (In reply to comment #3) Maybe some annotation for the linker could help here. Suggestions welcome. I don't see any way to do anything here. The docs say you need to recompile everything when defining _GLIBCXX_DEBUG. If you have a binary lib you can't recompile everything, so don't define _GLIBCXX_DEBUG. You can still use __gnu_debug::deque in specific places to get checking for individual containers, rather than defining the macro. That's how I use the Debug Mode containers when I can't recompile everything.
[Bug c++/51222] [C++11][SFINAE] Unevaluated combined delete new expression completely broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51222 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2012-06-11 16:02:40 UTC --- Last posted version: http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00157.html
[Bug lto/53604] ld reports errors using lto after upgrading from gcc-4.6.2 to gcc-4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53604
Yuri Gribov tetra2005 at gmail dot com changed:
What|Removed |Added
CC||tetra2005 at gmail dot com
--- Comment #3 from Yuri Gribov tetra2005 at gmail dot com 2012-06-11
17:04:42 UTC ---
Paul,
I changed to
static inline bool
varpool_can_remove_if_no_refs (struct varpool_node *node)
{
return (!node-force_output !node-used_from_other_partition
(flag_toplevel_reorder || DECL_COMDAT (node-decl)
|| DECL_ARTIFICIAL (node-decl))
((DECL_COMDAT (node-decl) !varpool_used_from_object_file_p
(node)) || !node-externally_visible));
}
and it helped.
[Bug tree-optimization/53636] New: SLP may create invalid unaligned memory accesses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53636
Bug #: 53636
Summary: SLP may create invalid unaligned memory accesses
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: uweig...@gcc.gnu.org
The following test case:
void test (unsigned char *dst)
{
short tmp[11 * 8], *tptr;
int i;
fill (tmp);
tptr = tmp;
for (i = 0; i 8; i++)
{
dst[0] = (-tptr[0] + 9 * tptr[0 + 1] + 9 * tptr[0 + 2] - tptr[0 + 3])
7;
dst[1] = (-tptr[1] + 9 * tptr[1 + 1] + 9 * tptr[1 + 2] - tptr[1 + 3])
7;
dst[2] = (-tptr[2] + 9 * tptr[2 + 1] + 9 * tptr[2 + 2] - tptr[2 + 3])
7;
dst[3] = (-tptr[3] + 9 * tptr[3 + 1] + 9 * tptr[3 + 2] - tptr[3 + 3])
7;
dst[4] = (-tptr[4] + 9 * tptr[4 + 1] + 9 * tptr[4 + 2] - tptr[4 + 3])
7;
dst[5] = (-tptr[5] + 9 * tptr[5 + 1] + 9 * tptr[5 + 2] - tptr[5 + 3])
7;
dst[6] = (-tptr[6] + 9 * tptr[6 + 1] + 9 * tptr[6 + 2] - tptr[6 + 3])
7;
dst[7] = (-tptr[7] + 9 * tptr[7 + 1] + 9 * tptr[7 + 2] - tptr[7 + 3])
7;
dst += 8;
tptr += 11;
}
}
when built on ARM with -mcpu=cortex-a9 -mfpu=neon -mfloat-abi=softfp -O
-ftree-vectorize creates code that uses a VLDR instruction to access unaligned
memory, which causes a Bus error at runtime.
The problem seems to be that the check in vect_compute_data_ref_alignment is
not enough for SLP. Even though SLP only considers a basic blokc, the data-ref
analysis still looks at innermost loops to compute scalar evolutions. This
results in concluding that the access tptr[0] is based on tmp, which is
aligned to 8 bytes, using a step of 22 bytes.
The alignment check now only verified that the *base* is aligned. This is OK
if we're actually vectorizing the loop. But in the SLP case, we really need to
verify instead that the access is aligned on *every* iteration through the loop
...
[Bug tree-optimization/53636] SLP may create invalid unaligned memory accesses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53636 Ulrich Weigand uweigand at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-06-11 AssignedTo|unassigned at gcc dot |uweigand at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug c++/53540] C++11: using fails to be equivalent to typedef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53540 --- Comment #2 from Akim Demaille akim.demaille at gmail dot com 2012-06-11 17:27:13 UTC --- (In reply to comment #1) I think it's valid, CC'ing Dodji for confirmation. Any news?
[Bug target/53633] __attribute__((naked)) should disable -Wreturn-type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53633 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Target||arm*-*-* Component|c |target --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-06-11 18:23:04 UTC --- I think it was a bad idea we even added the attribute naked in the first place.
[Bug target/53511] SH Target: Add support for fma patterns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53511 --- Comment #12 from Oleg Endo olegendo at gcc dot gnu.org 2012-06-11 19:24:24 UTC --- Author: olegendo Date: Mon Jun 11 19:24:20 2012 New Revision: 188396 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188396 Log: PR target/53511 * config/sh/sh.md (fmasf4): New expander. (*macsf3): Rename to fmasf4_i. Adapt to fma pattern. (mac_media): Rename to fmasf4_media. Adapt to fma pattern. * config/sh/sh.opt (mfused-madd): Remove. * config/sh/sh.c (sh_option_override): Remove mfused-madd handling. (builtin_description bdesc): Remove __builtin_sh_media_FMAC_S. * config.gcc (sh[123456789lbe]*-*-* | sh-*-*): Add fused-madd.opt as extra options. * doc/invoke.texi (SH Options): Update mfused-madd and mno-fused-madd descriptions. PR target/53511 * gcc.target/sh/pr53511-1.c: New. Added: trunk/gcc/testsuite/gcc.target/sh/pr53511-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config.gcc trunk/gcc/config/sh/sh.c trunk/gcc/config/sh/sh.md trunk/gcc/config/sh/sh.opt trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog
[Bug c++/53637] New: NRVO not applied in branches when it could be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53637
Bug #: 53637
Summary: NRVO not applied in branches when it could be
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ken...@google.com
In the example below it should be possible to apply NRVO. This situation is
similar to, but more complicated than, the one reported in PR51571.
Note that while this is just a missed optimization, NRVO can affect the way
interfaces are designed, so aggressively covering all possible cases seems more
important than with most optimizations.
$ cat nrvo.cc
class Foo {
public:
Foo() {}
// Declare but don't define so that if NRVO doesn't kick in we
// get a linker error.
Foo(const Foo other);
};
Foo bar(int i) {
if (i 1) {
Foo result;
return result;
} else {
Foo result;
return result;
}
}
int main(int argc, char* argv[]) {
Foo f = bar(argc);
}
$ g++-4.7 -O2 nrvo.cc
/tmp/ccRlHce1.o: In function `bar(int)':
nrvo.cc:(.text+0xe): undefined reference to `Foo::Foo(Foo const)'
collect2: error: ld returned 1 exit status
$ g++-4.7 --version
g++-4.7 (Ubuntu/Linaro 4.7.0-7ubuntu3) 4.7.0
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug middle-end/53533] [4.7 regression] loop unrolling as measured by Adobe's C++Benchmark is twice as slow versus 4.4-4.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533 --- Comment #3 from Matt Hargett matt at use dot net 2012-06-11 19:56:14 UTC --- Created attachment 27603 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27603 ZIP with pre-processed shorter example, callgrind output, and smaller binaries
[Bug middle-end/53533] [4.7 regression] loop unrolling as measured by Adobe's C++Benchmark is twice as slow versus 4.4-4.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533 --- Comment #4 from Matt Hargett matt at use dot net 2012-06-11 19:57:12 UTC --- Created attachment 27604 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27604 shorter source example, ~150 lines w/o comments
[Bug middle-end/53533] [4.7 regression] loop unrolling as measured by Adobe's C++Benchmark is twice as slow versus 4.4-4.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533 --- Comment #5 from Matt Hargett matt at use dot net 2012-06-11 20:02:41 UTC --- Got rid of graphite options, it made no difference. I reduced the original test from the suite and attached it's source, preprocessor output from 4.6 and 4.7 (no major difference), and callgrind output. To keep things simple, I'm just using -O3 and -fwhole-program. According to callgrind, 4.7's instruction references went up by 60% and D1 misses went up by 15% at -O3 versus 4.6 at -O3. Let me know if you need any more information to continue triaging. Thanks!
[Bug target/53568] SH Target: Add support for bswap built-ins
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53568 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-06-11 Ever Confirmed|0 |1
[Bug c++/53638] New: static_assert handling behavior ignores template specializations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53638
Bug #: 53638
Summary: static_assert handling behavior ignores template
specializations
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sbrae...@knights.ucf.edu
The current behavior of static_assert when inside a template definition is to
detect and attempt to evaluate the assert during the parser stage, before any
instantiations. (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52809)
A static_assert declaration that does not depend on template parameters will
be
detected and reported while parsing the template, before any instantiation.
This is OK because such a template would have no valid instantiation, which
immediately renders the program ill-formed.
It is my opinion that this is not true. It is possible that the template might
have valid specializations that occur later on in the compilation unit, making
it impossible to determine whether or not it is possible to construct an
instantiation of the template when parsing.
The relevant part of the standard says this Refer to 14.6p8 in the spec
If no valid specialization can be generated for a template definition, and that
template is not instantiated, the template definition is ill-formed, no
diagnostic required.
This seems at first to imply that the current behavior is legal. However, the
current behavior evaluates the static_assert and emits a message EVEN if valid
specializations CAN still be generated for a template definition.
Consider this code:
templatebool a
struct s {
static_assert(0, uhoh);
};
template
struct sfalse {
};
s false q;
This should compile, because sfalse is a valid specialization of s, meaning
that sa does not get instantiated. However, on gcc 4.5.1 and gcc 4.7, we get
prog.cpp:3:5: error: static assertion failed: uhoh
Strangely, because of this behavior, we can 'fix' it by making the constant
expression dependent on a, even if we know it will always be false
templatebool a
struct s {
static_assert(a!=a, uhoh );
};
template
struct sfalse {
};
Compiles.
The current behavior of GCC in this case MAY be conformant with spec, but it
seems to go against the intent of the spec even if it doesn't go against the
letter. It also makes it difficult to use static_assert in certain
metaprogramming applications(like the example above, which could be used to
evaluate if a metafunction returned true). Also, as bug 52809 demonstrates, it
is confusing to users.
[Bug c++/53638] static_assert handling behavior ignores template specializations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53638
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-11
21:14:25 UTC ---
(In reply to comment #0)
It is my opinion that this is not true.
It is true.
It is possible that the template might
have valid specializations that occur later on in the compilation unit, making
it impossible to determine whether or not it is possible to construct an
instantiation of the template when parsing.
No it isn't. You can generate valid instantiations from a *different* template
definition, but the wording is in terms of template definitions, not templates.
The relevant part of the standard says this Refer to 14.6p8 in the spec
If no valid specialization can be generated for a template definition, and
that
template is not instantiated, the template definition is ill-formed, no
diagnostic required.
It specifically says for a definition. The primary definition of a template
is a definition, an explicit specialization provides a different definition.
If a valid instantiation can be generated from the second definition that
doesn't change the fact that if no valid instantiation can be generated for the
primary definition then that primary definition is ill-formed.
This seems at first to imply that the current behavior is legal. However, the
current behavior evaluates the static_assert and emits a message EVEN if valid
specializations CAN still be generated for a template definition.
Consider this code:
templatebool a
struct s {
static_assert(0, uhoh);
};
template
struct sfalse {
};
s false q;
This should compile, because sfalse is a valid specialization of s, meaning
that sa does not get instantiated.
No, the primary template is a template definition but no valid specialization
can be generated from it. The explicit specialization is a second definition,
its existence doesn't change the fact the primary definition cannot ever be
used (also the explicit specialization hasn't even been seen when the primary
definition is first parsed.)
However, on gcc 4.5.1 and gcc 4.7, we get
prog.cpp:3:5: error: static assertion failed: uhoh
And also on clang++ and EDG.
Strangely, because of this behavior, we can 'fix' it by making the constant
expression dependent on a, even if we know it will always be false
templatebool a
struct s {
static_assert(a!=a, uhoh );
};
That is a bit strange at first sight, but actually that doesn't fix anything,
that definition is still ill-formed because no valid instantiation can be
generated from it. It would be conforming for a compiler to reject that
program, but it's not required to (it's ill-formed, no diagnostic required.)
The solution is to not write it like that.
A more sensible definition would be:
templatebool a
struct s {
static_assert(!a, uhoh);
};
Or even just
templatebool a struct s;
(Though the static assertion does give the option of a nicer message.)
template
struct sfalse {
};
Compiles.
The current behavior of GCC in this case MAY be conformant with spec, but it
It definitely is. Read 14.6p8 again. It doesn't matter if the template is
never instantiated, it's ill-formed.
seems to go against the intent of the spec even if it doesn't go against the
letter.
I don't see how it goes against the intent -- the standard clearly says a
template definition from which no valid specialisation can be generated is
ill-formed.
Your primary template is such a definition. So it's ill-formed.
It also makes it difficult to use static_assert in certain
metaprogramming applications(like the example above, which could be used to
evaluate if a metafunction returned true).
So make it dependent, or leave the primary template undefined.
The alternative is to change three major compilers to accommodate a highly
questionable style of metaprogramming that the standard says is ill-formed.
Don't do it.
Also, as bug 52809 demonstrates, it
is confusing to users.
It doesn't demonstrate that at all, it just asserts it.
[Bug target/53639] New: x86_64: redundant 64-bit operations on 32-bit integers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53639
Bug #: 53639
Summary: x86_64: redundant 64-bit operations on 32-bit integers
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mi...@it.uu.se
Created attachment 27605
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27605
test case
cat redundant-64-bit-ops.c
struct tlb_entry {
unsigned int tag;
unsigned int va_pa_off;
};
struct core {
struct tlb_entry tlb[1 10];
unsigned char *hmem;
};
unsigned char read_byte_slow(struct core *core, unsigned int va);
static inline unsigned char read_byte(struct core *core, unsigned int va)
{
unsigned int vpn;
struct tlb_entry *te;
vpn = va 12;
te = core-tlb[vpn ((1 10) - 1)];
if (__builtin_expect(te-tag != vpn, 0))
return read_byte_slow(core, va);
return *(core-hmem + va + te-va_pa_off);
}
unsigned char foo(struct core *core, unsigned int *q)
{
return read_byte(core, *q);
}
/tmp/objdir/gcc/xgcc -B/tmp/objdir/gcc -O3 -S redundant-64-bit-ops.c
cat redundant-64-bit-ops.s
.file redundant-64-bit-ops.c
.text
.p2align 4,,15
.globl foo
.type foo, @function
foo:
.LFB1:
.cfi_startproc
movl(%rsi), %esi (G)
movl%esi, %edx
shrl$12, %edx (C)
movq%rdx, %rcx (A)
andl$1023, %ecx (B)
leaq(%rdi,%rcx,8), %rcx
cmpl(%rcx), %edx
jne .L4
movl%esi, %eax (D)
movl4(%rcx), %edx
addq8192(%rdi), %rax (E)
movzbl (%rax,%rdx), %eax (F)
ret
.L4:
jmp read_byte_slow
.cfi_endproc
.LFE1:
.size foo, .-foo
.ident GCC: (GNU) 4.8.0 20120610 (experimental)
.section.note.GNU-stack,,@progbits
1. Instruction (A) does a 64-bit move, however instruction (B) shows that only
the low 32 bits of the destination are live, and instruction (C) shows that the
source is already in zero-extended form. Therefore instruction (A) should just
be a 32-bit 'movl %edx, %ecx'.
2. Instruction (D) is either a zero-extension, or a redundant move due to poor
register allocation. The destination does need to be in zero-extended form to
work in instructions (E) and (F), but the source is already in zero-extended
form since instruction (G), so %rax should have been replaced with %rsi in (E)
and (F), and (D) should have been deleted.
The above was with gcc-4.8-20120610, but gcc-4.7-20120605 has the same problem.
gcc-4.6.3 has the first problem but not the second, so the likely path is one
instruction shorter there. Unfortunately gcc-4.6.3 chose %eax as the
destination for the first load from %rsi, forcing it to insert a compensation
move back to %esi before the tailcall in the unlikely path.
[Bug tree-optimization/53640] New: Missed cmove with stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53640
Bug #: 53640
Summary: Missed cmove with stores
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pins...@gcc.gnu.org
Take:
int f(int a, int *b)
{
if (a = 2)
*b = 1;
else
*b = 0;
return *b;
}
int f1(int a, int *b)
{
int t;
if (a = 2)
t = 1;
else
t = 0;
*b = t;
return *b;
}
CUT
Both of these are the same. f1 will produce better code.
[Bug tree-optimization/53640] Missed cmove with stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53640 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Blocks||26163 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-06-11 23:08:50 UTC --- Shows up in gobmk in spec 2006: else if (distance[pos] == -1) under_control[pos] = 0; else under_control[pos] = 1;
[Bug target/53621] [SH] Frame pointers not generated with -fno-omit-frame-pointer on GCC 4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53621 --- Comment #6 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-06-12 00:05:05 UTC --- I thought that -pg and -fomit-frame-pointer are always incompatible. Agree with the possible issues for old unwinders. I've forgotten that sh coff targets went away. Then, removing that line might be enough. I'd like to approve any patches for this PR :-) It should be backported to the release branches, because this is a 4.6/4.7/4.8 regression from 4.5, AFAIK.
[Bug c++/53634] Segmentation fault on nested lambda + template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53634 --- Comment #2 from Taiju Tsuiki mail+gcc at tzik dot jp 2012-06-12 01:20:49 UTC --- Oh, sorry. I might search in wrong way.
[Bug tree-optimization/50472] Volatile qualification in data is not enough to avoid optimization over pointer to data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50472 --- Comment #8 from amker at gcc dot gnu.org 2012-06-12 02:33:29 UTC --- Author: amker Date: Tue Jun 12 02:33:23 2012 New Revision: 188414 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188414 Log: Backport r179200 from GCC-4.6 branch 2011-09-26 Richard Guenther rguent...@suse.de PR tree-optimization/50472 * tree-ssa-ccp.c (fold_const_aggregate_ref): Do not fold volatile references. PR tree-optimization/50472 * gcc.dg/torture/pr50472.c: New testcase. Added: branches/ARM/embedded-4_6-branch/gcc/testsuite/gcc.dg/torture/pr50472.c Modified: branches/ARM/embedded-4_6-branch/gcc/ChangeLog.arm branches/ARM/embedded-4_6-branch/gcc/testsuite/ChangeLog.arm branches/ARM/embedded-4_6-branch/gcc/tree-ssa-ccp.c
[Bug c++/53613] Cannot override a inline = default virtual destructor.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53613 --- Comment #5 from Kirby Zhou kirbyz...@sogou-inc.com 2012-06-12 02:39:44 UTC --- It is a BAD NEWS about no fix on the 4.7.X branch, and it's not a regression. The bug breaks a lot of already exist oode which is workable with GCC-4.4.X release. (In reply to comment #4) (In reply to comment #3) (In reply to comment #1) Fixed on trunk by patch for PR 50043 Did this patch apply to 4.7 branch? PR 50043 shows a single commit to trunk and has Target Milestone 4.8.0, so no, it's only fixed on trunk. I retested with 4.7 branch 20120610, The bug is still exist. Yes, and it probably won't be fixed on the release branch as it's not a regression. New features are not usually added to released versions. In any case, there's a simple workaround of adding explicit 'noexcept' specifiers, which will still work with 4.8 I'm marking this as a dup of PR 50043 as the failure to compile is a direct consequence of not implementing DR 1123 *** This bug has been marked as a duplicate of bug 50043 ***
[Bug inline-asm/50571] [4.6/4.7 Regression] Undesirable folding in m constrained asm operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50571 --- Comment #5 from amker at gcc dot gnu.org 2012-06-12 02:45:27 UTC --- Author: amker Date: Tue Jun 12 02:45:23 2012 New Revision: 188415 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188415 Log: Backport r179389 from mainline 2011-09-30 Jakub Jelinek ja...@redhat.com PR inline-asm/50571 * gimple-fold.c (fold_stmt_1) case GIMPLE_ASM: If input constraints allow mem and not reg, pass true instead of false as second argument to maybe_fold_reference. * gcc.dg/pr50571.c: New test. Added: branches/ARM/embedded-4_6-branch/gcc/testsuite/gcc.dg/pr50571.c Modified: branches/ARM/embedded-4_6-branch/gcc/ChangeLog.arm branches/ARM/embedded-4_6-branch/gcc/gimple-fold.c branches/ARM/embedded-4_6-branch/gcc/testsuite/ChangeLog.arm
[Bug target/50106] [ARM] Wrong code with -march=armv5t -mthumb -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50106 --- Comment #12 from amker at gcc dot gnu.org 2012-06-12 02:50:37 UTC --- Author: amker Date: Tue Jun 12 02:50:34 2012 New Revision: 188416 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188416 Log: Backport r180240 from mainline 2011-10-20 Ramana Radhakrishnan ramana.radhakrish...@linaro.org PR target/50106 * config/arm/arm.c (thumb_unexpanded_epilogue): Handle return reg size from 1-3. Modified: branches/ARM/embedded-4_6-branch/gcc/ChangeLog.arm branches/ARM/embedded-4_6-branch/gcc/config/arm/arm.c
[Bug c++/50608] [4.6/4.7 regression] cannot apply 'offsetof' to a non-constant address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50608 --- Comment #9 from amker at gcc dot gnu.org 2012-06-12 03:11:03 UTC --- Author: amker Date: Tue Jun 12 03:10:55 2012 New Revision: 188418 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188418 Log: Backport r180986 from mainline 2011-11-04 Eric Botcazou ebotca...@adacore.com PR c++/50608 * c-common.c (c_fully_fold_internal) ADDR_EXPR: Call fold_offsetof_1. (fold_offsetof_1): Make global. Remove STOP_REF argument and adjust. INDIRECT_REF: Return the argument. ARRAY_REF: Remove special code for negative offset. Call fold_build_pointer_plus instead of size_binop. (fold_offsetof): Remove STOP_REF argument and adjust. * c-common.h (fold_offsetof_1): Declare. (fold_offsetof): Remove STOP_REF argument. PR c++/50608 * c-parser.c (c_parser_postfix_expression) RID_OFFSETOF: Adjust call to fold_offsetof. * c-typeck.c (build_unary_op) ADDR_EXPR: Call fold_offsetof_1. * g++.dg/other/offsetof7.C: New test. PR c++/50608 * semantics.c (finish_offsetof): Adjust call to fold_offsetof. * typeck.c (cp_build_addr_expr_1): Call fold_offsetof_1. Added: branches/ARM/embedded-4_6-branch/gcc/c-family/ChangeLog.arm branches/ARM/embedded-4_6-branch/gcc/cp/ChangeLog.arm branches/ARM/embedded-4_6-branch/gcc/testsuite/g++.dg/other/offsetof7.C Modified: branches/ARM/embedded-4_6-branch/gcc/ChangeLog.arm branches/ARM/embedded-4_6-branch/gcc/c-family/c-common.c branches/ARM/embedded-4_6-branch/gcc/c-family/c-common.h branches/ARM/embedded-4_6-branch/gcc/c-parser.c branches/ARM/embedded-4_6-branch/gcc/c-typeck.c branches/ARM/embedded-4_6-branch/gcc/cp/semantics.c branches/ARM/embedded-4_6-branch/gcc/cp/typeck.c branches/ARM/embedded-4_6-branch/gcc/testsuite/ChangeLog.arm
[Bug middle-end/51768] [4.5 Regression] ICE with invalid asm goto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51768 --- Comment #7 from jye2 at gcc dot gnu.org 2012-06-12 03:49:37 UTC --- Author: jye2 Date: Tue Jun 12 03:49:33 2012 New Revision: 188419 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188419 Log: 2012-06-12 Joey Ye joey...@arm.com Backport r182921 from mainline 2012-01-05 Jakub Jelinek ja...@redhat.com PR middle-end/51768 * stmt.c (check_unique_operand_names): Don't ICE during error reporting if i is from labels chain. testsuite: Backport r182921 from mainline 2012-01-05 Jakub Jelinek ja...@redhat.com PR middle-end/51768 * c-c++-common/pr51768.c: New test. Added: branches/ARM/embedded-4_6-branch/gcc/testsuite/c-c++-common/pr51768.c Modified: branches/ARM/embedded-4_6-branch/gcc/ChangeLog.arm branches/ARM/embedded-4_6-branch/gcc/stmt.c branches/ARM/embedded-4_6-branch/gcc/testsuite/ChangeLog.arm
