[Bug fortran/58557] New: [OOP] Issues with CLASS/TYPE functions in array constructors: reject valid, memory leaks, invalid free
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58557 Bug ID: 58557 Summary: [OOP] Issues with CLASS/TYPE functions in array constructors: reject valid, memory leaks, invalid free Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: rejects-valid, wrong-code Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org The following test case shows that functions which return derived-types/polymorphic arrays are mishandled. Failures: * For many: Error: Can't convert REAL(4) to TYPE(t) * For instance: *(atmp[0].data) = *f_type() ! ups null pointer deref * Memory not freed for funcs returning allocatable memory. Note: One problem is that the functions can occur in nested constructors, ac-do loops, having unknown ac-do loop bounds array sizes. program main implicit none type t end type t interface function f_type() import :: t type(t), allocatable :: f_type end function f_type function f_type_na() import :: t type(t) :: f_type end function f_type_na function f_type_array() import :: t type(t), allocatable :: f_type(:) end function f_type_array function f_type_array_na() import :: t type(t) :: f_type(5) end function f_type_array_na function f_class(i) import :: t class(t), allocatable :: f_class integer :: i end function f_class function f_class_array() import :: t class(t), allocatable :: f_class integer :: i end function f_class_array subroutine sub_type2(x) import :: t type(t) :: x(:) end subroutine sub_type2 subroutine sub_class2(x) import :: t class(t) :: x(:) end subroutine sub_class2 end interface type(t) :: b(1) integer :: i b = [ f_type() ] b = [ f_type_na() ] b = [ f_type_array() ] b = [ f_type_array_na() ] b = [ f_class_array(1) ] call sub_type2([f_class(1)]) call sub_type2([f_class_array(1)]) call sub_type2([(f_class(i),i=1,5)]) call sub_type2([(f_class_array(i),i=1,5)]) call sub_class2([f_class(1)]) call sub_class2([f_class_array(1)]) call sub_class2([(f_class(i),i=1,5)]) call sub_class2([(f_class_array(i),i=1,5)]) end program main
[Bug fortran/58557] [OOP] Issues with CLASS/TYPE functions in array constructors: reject valid, memory leaks, invalid free
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58557 --- Comment #1 from Tobias Burnus --- Also the following fails: call sub_class2(f_type_array())
For Service in the Former Yugoslavia.
Tim Jones ran unopposed again in November, 2010 to win his third term in the Missouri House. EMT Madrid bus service use CNG motors in 351 regular buses.
Location of Sheridan within the U.
A deleted scene on the DVD eventually solved this mystery. June 19, 2008 after a delay of 4 days.
[Bug target/10901] non-local goto's don't work on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10901 --- Comment #27 from Iain Sandoe --- patch posted. http://gcc.gnu.org/ml/gcc-patches/2013-09/msg02066.html
[Bug c++/58555] Floating point exception in want_inline_self_recursive_call_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58555 Paolo Carlini changed: What|Removed |Added CC||hubicka at ucw dot cz --- Comment #2 from Paolo Carlini --- I think this is for Honza
[Bug c++/58555] Floating point exception in want_inline_self_recursive_call_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58555 --- Comment #3 from Markus Trippelsdorf --- (In reply to Paolo Carlini from comment #2) > I think this is for Honza Yes. Started with r202185 .
[Bug c++/58558] New: [Regression] ICE when building mednafen with -O2 on mips and mipsel on gcc 4.8.1 and 4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58558 Bug ID: 58558 Summary: [Regression] ICE when building mednafen with -O2 on mips and mipsel on gcc 4.8.1 and 4.9.0 Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: steve at sk2 dot org Created attachment 30922 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30922&action=edit Source code causing the ICE Hi, The attached pre-processed source fails to build on gcc 4.8.1 and gcc 4.9.0 on mips and mipsel, when -O2 is enabled. The command-line used to reproduce the ICE is simply g++ -O2 cc8t9QXW.i The versions on which the ICE occurs are Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/mipsel-linux-gnu/4.8/lto-wrapper Target: mipsel-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.8.1-10' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libitm --disable-libsanitizer --disable-libquadmath --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-mipsel/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-mipsel --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-mipsel --with-arch-directory=mips --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-multiarch --with-arch-32=mips2 --with-tune-32=mips32 --enable-targets=all --with-arch-64=mips3 --with-tune-64=mips64 --enable-checking=release --build=mipsel-linux-gnu --host=mipsel-linux-gnu --target=mipsel-linux-gnu Thread model: posix gcc version 4.8.1 (Debian 4.8.1-10) and Using built-in specs. COLLECT_GCC=/usr/lib/gcc-snapshot/bin/g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc-snapshot/libexec/gcc/mipsel-linux-gnu/4.9.0/lto-wrapper Target: mipsel-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 20130731-1' --with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs --enable-languages=c,ada,c++,java,go,fortran,objc,obj-c++ --prefix=/usr/lib/gcc-snapshot --enable-shared --enable-linker-build-id --disable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libitm --disable-libsanitizer --disable-libquadmath --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-snap-mipsel/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-snap-mipsel --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-snap-mipsel --with-arch-directory=mips --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-multiarch --with-arch-32=mips2 --with-tune-32=mips32 --enable-targets=all --with-arch-64=mips3 --with-tune-64=mips64 --disable-werror --enable-checking=yes --build=mipsel-linux-gnu --host=mipsel-linux-gnu --target=mipsel-linux-gnu Thread model: posix gcc version 4.9.0 20130731 (experimental) [trunk revision 201378] (Debian 20130731-1) The error message is In file included from src/chip/cx4/cx4.cpp:17:0: src/chip/cx4/oam.cpp: In member function 'void bSNES_v059::Cx4::op00_00()': src/chip/cx4/oam.cpp:77:1: internal compiler error: in do_SUBST, at combine.c:711 Please submit a full bug report, with preprocessed source if appropriate. See for instructions.
[Bug c++/58558] [Regression] ICE when building mednafen with -O2 on mips and mipsel on gcc 4.8.1 and 4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58558 --- Comment #1 from Mikael Pettersson --- I can reproduce the ICE with gcc-4.8-20130926 configured as a cross to mips64-linux. Backporting the PR58079 fix in r201609 fixes the ICE. Thus, please close this one as a duplicate of PR58079.
[Bug c++/51048] Class template inheritance doesn't work well with function-local types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51048 --- Comment #3 from Cameron --- Created attachment 30923 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30923&action=edit Self contained test case to reproduce bug 51048
[Bug c++/51048] Class template inheritance doesn't work well with function-local types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51048 --- Comment #4 from Cameron --- Comment on attachment 30923 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30923 Self contained test case to reproduce bug 51048 Tested with g++ 4.8.1. g++ -v yields: Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.1/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-isl=/builddir/build/BUILD/gcc-4.8.1-20130603/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.1-20130603/obj-x86_64-redhat-linux/cloog-install --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 4.8.1 20130603 (Red Hat 4.8.1-1) (GCC)
[Bug rtl-optimization/58079] internal compiler error: in do_SUBST, at combine.c:711
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58079 Stephen Kitt changed: What|Removed |Added CC||steve at sk2 dot org --- Comment #8 from Stephen Kitt --- *** Bug 58558 has been marked as a duplicate of this bug. ***
[Bug c++/58558] [Regression] ICE when building mednafen with -O2 on mips and mipsel on gcc 4.8.1 and 4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58558 Stephen Kitt changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Stephen Kitt --- Thanks for the info! *** This bug has been marked as a duplicate of bug 58079 ***
[Bug c++/58559] New: Underlying type of enum is hybrid of int and unsigned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58559
Bug ID: 58559
Summary: Underlying type of enum is hybrid of int and unsigned
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: cyp561 at gmail dot com
An enum with no values outside the range 0..INT_MAX seems to be treated as an
int in all cases, with the exception that casting to long or long long does not
sign extend. As far as I understand, the compiler is free to decide to use
either int or unsigned to represent an enum, but not some hybrid.
Assuming e is an enum represented by an int, I think the comparison "((long
long)e < 0" should not be always false. If e is an enum represented by an
unsigned, the warning would be valid, but "e < 0" should then also be always
false.
Compiling as plain C or adding a value larger than INT_MAX, enums seem to be
consistently unsigned. Adding a negative value, enums seem to be consistently
signed.
The same thing happens in all versions: 3.4.6 4.1.2 4.2.4 4.3.6 4.4.7 4.5.4
4.6.4 4.7.3
{{{
/* { dg-do run } */
/* { dg-options "-fno-strict-enums -Wtype-limits" } */
extern "C" void abort();
enum E {A, B};
long long f(int x) { return x; }
long long f(unsigned x) { return x; }
int main()
{
E e = (E)-1;
if (sizeof(e) >= sizeof(long long)) // First check that test makes sense.
return 0;
if (((long long)e < 0) != (e < 0)) /* { dg-bogus "comparison is always
false" } */
abort();
if (((long long)e < 0) != (f(e) < 0)) /* { dg-bogus "comparison is always
false" } */
abort();
}
}}}
[Bug c++/58560] New: [4.7/4.8/4.9 Regression] ICE with auto in typedef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58560
Bug ID: 58560
Summary: [4.7/4.8/4.9 Regression] ICE with auto in typedef
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following code snippet (compiled with "-std=c++0x") triggers an ICE since
GCC 4.7.0:
typedef auto T;
void foo() { T(); }
bug.cc:1:14: error: typedef declared 'auto'
typedef auto T;
^
bug.cc: In function 'void foo()':
bug.cc:3:16: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in build_value_init_noctor, at cp/init.c:377
void foo() { T(); }
^
0xcdbad9 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/gcc/tree.c:9225
0x6940e6 tree_class_check
../../gcc/gcc/tree.h:2731
0x6940e6 build_value_init_noctor(tree_node*, int)
../../gcc/gcc/cp/init.c:377
0x5e4cf1 build_functional_cast(tree_node*, tree_node*, int)
../../gcc/gcc/cp/typeck2.c:1817
0x649859 cp_parser_functional_cast
../../gcc/gcc/cp/parser.c:22734
0x64429d cp_parser_postfix_expression
../../gcc/gcc/cp/parser.c:5741
0x646acd cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:7009
0x6476af cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:7701
0x647b6f cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:7937
0x6499d3 cp_parser_expression
../../gcc/gcc/cp/parser.c:8099
0x64a1ce cp_parser_expression
../../gcc/gcc/cp/parser.c:8138
0x64a1ce cp_parser_expression_statement
../../gcc/gcc/cp/parser.c:9429
0x63faf7 cp_parser_statement
../../gcc/gcc/cp/parser.c:9280
0x640dde cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:9552
0x640f26 cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:9506
0x6522db cp_parser_function_body
../../gcc/gcc/cp/parser.c:18318
0x6522db cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:18354
0x65331f cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:22338
0x654027 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:22259
0x654027 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:16347
Please submit a full bug report, [etc.]
[Bug c++/58561] New: [c++0x] ICE using declaration of function with auto in return type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58561
Bug ID: 58561
Summary: [c++0x] ICE using declaration of function with auto in
return type
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following (valid?) code snippet (compiled with "-std=c++0x -g") triggers an
ICE since GCC 4.8.0:
=
auto foo();
namespace N
{
using ::foo;
}
=
bug.cc:1:10: warning: 'foo' function uses 'auto' type specifier without
trailing return type [enabled by default]
auto foo();
^
bug.cc:5:11: internal compiler error: in is_base_type, at dwarf2out.c:10146
using ::foo;
^
0x86a0f6 is_base_type
../../gcc/gcc/dwarf2out.c:10146
0x86a0f6 modified_type_die
../../gcc/gcc/dwarf2out.c:10337
0x86b58a add_type_attribute
../../gcc/gcc/dwarf2out.c:16702
0x861250 gen_subprogram_die
../../gcc/gcc/dwarf2out.c:17895
0x86a42a force_decl_die
../../gcc/gcc/dwarf2out.c:19955
0x87b0e2 dwarf2out_imported_module_or_decl_1
../../gcc/gcc/dwarf2out.c:20398
0x70bcf6 cp_emit_debug_info_for_using(tree_node*, tree_node*)
../../gcc/gcc/cp/name-lookup.c:6206
0x70be53 do_toplevel_using_decl(tree_node*, tree_node*, tree_node*)
../../gcc/gcc/cp/name-lookup.c:3939
0x655204 cp_parser_using_declaration
../../gcc/gcc/cp/parser.c:15771
0x6559ec cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:10848
0x65e7fe cp_parser_declaration
../../gcc/gcc/cp/parser.c:10764
0x65d55d cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:10650
0x65d770 cp_parser_namespace_body
../../gcc/gcc/cp/parser.c:15568
0x65d770 cp_parser_namespace_definition
../../gcc/gcc/cp/parser.c:15549
0x65e8f1 cp_parser_declaration
../../gcc/gcc/cp/parser.c:10752
0x65d55d cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:10650
0x65ee46 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:3939
0x65ee46 c_parse_file()
../../gcc/gcc/cp/parser.c:28898
0x772524 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1046
Please submit a full bug report, [etc.]
[Bug middle-end/58547] [4.9 Regression] rtlanal.c:5482:19: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58547 John David Anglin changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from John David Anglin --- Fixed.
[Bug libstdc++/58562] New: std::sort fails with -D_GLIBCXX_DEBUG enabled, whose bug?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58562
Bug ID: 58562
Summary: std::sort fails with -D_GLIBCXX_DEBUG enabled, whose
bug?
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: jpritikin at pobox dot com
Host: x86_64-linux-gnu
Target: x86_64-linux-gnu
Build: x86_64-linux-gnu
Objects involved in the operation:
iterator "__first" @ 0x0x7fffa370 {
type =
N11__gnu_debug14_Safe_iteratorIN9__gnu_cxx17__normal_iteratorIP20matrixVectorProdTermNSt9__cxx19986vectorIS3_SaIS3_ENSt7__debug6vectorIS3_S7_
(mutable iterator);
state = dereferenceable (start-of-sequence);
references sequence with type
`NSt7__debug6vectorI20matrixVectorProdTermSaIS1_EEE' @ 0x0x7fffa370
}
iterator "__last" @ 0x0x7fffa3a0 {
type =
N11__gnu_debug14_Safe_iteratorIN9__gnu_cxx17__normal_iteratorIP20matrixVectorProdTermNSt9__cxx19986vectorIS3_SaIS3_ENSt7__debug6vectorIS3_S7_
(mutable iterator);
state = dereferenceable;
references sequence with type
`NSt7__debug6vectorI20matrixVectorProdTermSaIS1_EEE' @ 0x0x7fffa3a0
}
Program received signal SIGABRT, Aborted.
0x7732a037 in __GI_raise (sig=sig@entry=6)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) where
#0 0x7732a037 in __GI_raise (sig=sig@entry=6)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x7732d698 in __GI_abort () at abort.c:90
#2 0x71cbf5cd in __gnu_debug::_Error_formatter::_M_error() const ()
from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3 0x71f7addd in
std::sort_heap<__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator > >,
std::__debug::vector
> > > (__first=..., __last=...)
at /usr/include/c++/4.7/bits/stl_heap.h:468
#4 0x71f7936f in
std::partial_sort<__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator > >,
std::__debug::vector
> > > (__first=...,
__middle=..., __last=...) at /usr/include/c++/4.7/bits/stl_algo.h:5325
#5 0x71f77a74 in
std::__introsort_loop<__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator > >,
std::__debug::vector
> >, long> (
__first=..., __last=..., __depth_limit=0)
at /usr/include/c++/4.7/bits/stl_algo.h:2335
#6 0x71f76772 in
std::sort<__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator > >,
std::__debug::vector
> > > (__first=..., __last=...)
at /usr/include/c++/4.7/bits/stl_algo.h:5476
#7 0x71fb9194 in buildItemParamMap (oo=0x20a72d0, fc=0x1dd8240)
at omxFitFunctionBA81.cpp:211
The code at omxFitFunctionBA81.cpp:211 is:
std::sort(state->hgProd.begin(), state->hgProd.end());
If I turn off -D_GLIBCXX_DEBUG then the code works fine.
[Bug c++/58563] New: [c++0x] ICE calling invalid destructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58563
Bug ID: 58563
Summary: [c++0x] ICE calling invalid destructor
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following code snippet (compiled with "-std=c++0x") triggers an ICE since
GCC 4.4.0:
==
template void foo()
{
enum E {};
E().E::~T();
}
==
bug.cc: In function 'void foo()':
bug.cc:4:11: error: 'enum foo()::E' is not a class
E().E::~T();
^
bug.cc:4:11: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in cp_parser_lookup_name, at cp/parser.c:21759
0xcda4a9 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/gcc/tree.c:9227
0x6322f5 tree_class_check
../../gcc/gcc/tree.h:2732
0x6322f5 cp_parser_lookup_name
../../gcc/gcc/cp/parser.c:21759
0x64f3a0 cp_parser_class_name
../../gcc/gcc/cp/parser.c:18736
0x64abb4 cp_parser_unqualified_id
../../gcc/gcc/cp/parser.c:4883
0x64b3f3 cp_parser_id_expression
../../gcc/gcc/cp/parser.c:4647
0x65b8de cp_parser_postfix_dot_deref_expression
../../gcc/gcc/cp/parser.c:6368
0x643569 cp_parser_postfix_expression
../../gcc/gcc/cp/parser.c:6031
0x64615d cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:7009
0x646d3f cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:7701
0x6471ff cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:7937
0x649063 cp_parser_expression
../../gcc/gcc/cp/parser.c:8099
0x64985e cp_parser_expression
../../gcc/gcc/cp/parser.c:8138
0x64985e cp_parser_expression_statement
../../gcc/gcc/cp/parser.c:9429
0x63f187 cp_parser_statement
../../gcc/gcc/cp/parser.c:9280
0x64046e cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:9552
0x6405b6 cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:9506
0x65196b cp_parser_function_body
../../gcc/gcc/cp/parser.c:18318
0x65196b cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:18354
0x6529af cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:22338
Please submit a full bug report, [etc.]
[Bug c/58564] New: possible wrong code bug at -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58564
Bug ID: 58564
Summary: possible wrong code bug at -O0
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: regehr at cs dot utah.edu
regehr@john-home ~ $ clang -O0 -w small.c ; ./a.out
0
regehr@john-home ~ $ gcc-4.4 -O0 -w small.c ; ./a.out
0
regehr@john-home ~ $ gcc-4.6 -O0 -w small.c ; ./a.out
0
regehr@john-home ~ $ gcc-4.7 -O0 -w small.c ; ./a.out
1
regehr@john-home ~ $ gcc -O0 -w small.c ; ./a.out
1
regehr@john-home ~ $ cat small.c
int printf(const char *, ...);
int a, b;
short *c;
short **d = &c;
int main() {
b = (0, 0 > ((&c == d) & (1 && a ^ 1))) | 0U;
printf("%d\n", b);
return 0;
}
regehr@john-home ~ $ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/regehr/z/compiler-install/gcc-r203005-install/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/regehr/z/compiler-source/gcc/configure
--prefix=/home/regehr/z/compiler-install/gcc-r203005-install
--enable-languages=c,c++ --disable-multilib
Thread model: posix
gcc version 4.9.0 20130928 (experimental) (GCC)
[Bug c++/58563] [c++11] ICE calling invalid destructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58563 Paolo Carlini changed: What|Removed |Added Summary|[c++0x] ICE calling invalid |[c++11] ICE calling invalid |destructor |destructor --- Comment #1 from Paolo Carlini --- Please don't refer anymore to c++0x/C++0x, by now it's legacy.
[Bug libstdc++/58562] std::sort fails with -D_GLIBCXX_DEBUG enabled, whose bug?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58562 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-09-28 Ever confirmed|0 |1 --- Comment #1 from Paolo Carlini --- For sure we need a (minimized, please) self-contained testcase to tell.
[Bug tree-optimization/58483] missing optimization opportunity for const std::vector compared to std::array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58483 --- Comment #4 from dennis luehring --- rechecked with latest clang 3.3(3.4) on http://gcc.godbolt.org/ reduces both cases std::array and std::vector down to return 160
[Bug c++/58565] New: [c++0x] ICE with label in statement expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58565
Bug ID: 58565
Summary: [c++0x] ICE with label in statement expression
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following invalid code snippet triggers an ICE since GCC 4.6.0 when
compiled with "-std=c++0x":
===
void foo()
{
int i = ({ L: ; });
}
===
bug.cc: In function 'void foo()':
bug.cc:3:20: sorry, unimplemented: unexpected AST of kind label_expr
int i = ({ L: ; });
^
bug.cc:3:20: internal compiler error: in potential_constant_expression_1, at
cp/semantics.c:8958
0x6ca0f4 potential_constant_expression_1
../../gcc/gcc/cp/semantics.c:8958
0x647673 cp_parser_constant_expression
../../gcc/gcc/cp/parser.c:8208
0x65332e cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:16520
0x65396f cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:10986
0x6557d0 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:10867
0x6568c0 cp_parser_declaration_statement
../../gcc/gcc/cp/parser.c:10514
0x63f167 cp_parser_statement
../../gcc/gcc/cp/parser.c:9274
0x64046e cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:9552
0x6405b6 cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:9506
0x65196b cp_parser_function_body
../../gcc/gcc/cp/parser.c:18318
0x65196b cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:18354
0x6529af cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:22338
0x6536b7 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:22259
0x6536b7 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:16347
0x65396f cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:10986
0x6557d0 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:10867
0x65e7fe cp_parser_declaration
../../gcc/gcc/cp/parser.c:10764
0x65d55d cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:10650
0x65ee46 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:3939
0x65ee46 c_parse_file()
../../gcc/gcc/cp/parser.c:28898
Please submit a full bug report, [etc.]
Without "-std=c++0x" the code is rejected correctly:
bug.cc: In function 'void foo()':
bug.cc:3:20: error: void value not ignored as it ought to be
int i = ({ L: ; });
^
[Bug c++/58566] New: [c++0x] ICE with invalid expression in lambda body
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58566
Bug ID: 58566
Summary: [c++0x] ICE with invalid expression in lambda body
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following invalid code snippet (compiled with "-std=c++0x") triggers an ICE
since GCC 4.8.0:
=
struct A
{
int foo()
{
[this]{ return foo; };
}
};
=
bug.cc: In lambda function:
bug.cc:5:25: error: invalid use of member function (did you forget the '()' ?)
[this]{ return foo; };
^
bug.cc:5:25: internal compiler error: in check_return_expr, at cp/typeck.c:8159
0x64d09a check_return_expr(tree_node*, bool*)
../../gcc-4.8.0/gcc/cp/typeck.c:8159
0x68856e finish_return_stmt(tree_node*)
../../gcc-4.8.0/gcc/cp/semantics.c:782
0x61a92c cp_parser_lambda_body
../../gcc-4.8.0/gcc/cp/parser.c:8643
0x61a92c cp_parser_lambda_expression
../../gcc-4.8.0/gcc/cp/parser.c:8194
0x61a92c cp_parser_primary_expression
../../gcc-4.8.0/gcc/cp/parser.c:4085
0x61b82a cp_parser_postfix_expression
../../gcc-4.8.0/gcc/cp/parser.c:5629
0x61dd3a cp_parser_unary_expression
../../gcc-4.8.0/gcc/cp/parser.c:6685
0x61e8d7 cp_parser_binary_expression
../../gcc-4.8.0/gcc/cp/parser.c:7365
0x61ed65 cp_parser_assignment_expression
../../gcc-4.8.0/gcc/cp/parser.c:7590
0x620b82 cp_parser_expression
../../gcc-4.8.0/gcc/cp/parser.c:7741
0x62124a cp_parser_expression_statement
../../gcc-4.8.0/gcc/cp/parser.c:9021
0x6172e7 cp_parser_statement
../../gcc-4.8.0/gcc/cp/parser.c:8873
0x61856e cp_parser_statement_seq_opt
../../gcc-4.8.0/gcc/cp/parser.c:9139
0x6186b6 cp_parser_compound_statement
../../gcc-4.8.0/gcc/cp/parser.c:9093
0x6297e3 cp_parser_function_body
../../gcc-4.8.0/gcc/cp/parser.c:17680
0x6297e3 cp_parser_ctor_initializer_opt_and_function_body
../../gcc-4.8.0/gcc/cp/parser.c:17716
0x62a86f cp_parser_function_definition_after_declarator
../../gcc-4.8.0/gcc/cp/parser.c:21691
0x6112dc cp_parser_late_parsing_for_member
../../gcc-4.8.0/gcc/cp/parser.c:22332
0x6112dc cp_parser_class_specifier_1
../../gcc-4.8.0/gcc/cp/parser.c:18439
0x6112dc cp_parser_class_specifier
../../gcc-4.8.0/gcc/cp/parser.c:18463
Please submit a full bug report, [etc.]
[Bug c++/58566] [c++11] ICE with invalid expression in lambda body
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58566 Paolo Carlini changed: What|Removed |Added Summary|[c++0x] ICE with invalid|[c++11] ICE with invalid |expression in lambda body |expression in lambda body --- Comment #1 from Paolo Carlini --- Please don't refer anymore to c++0x/C++0x, by now it's legacy.
[Bug c++/58565] [c++11] ICE with label in statement expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58565 Paolo Carlini changed: What|Removed |Added Summary|[c++0x] ICE with label in |[c++11] ICE with label in |statement expression|statement expression --- Comment #1 from Paolo Carlini --- Please don't refer anymore to c++0x/C++0x, by now it's legacy.
[Bug c++/58567] New: [4.8/4.9 Regression] ICE with invalid loop variable in template using openmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58567
Bug ID: 58567
Summary: [4.8/4.9 Regression] ICE with invalid loop variable in
template using openmp
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following invalid code snippet (compiled with "-fopenmp") triggers an ICE
since GCC 4.8.0:
template void foo()
{
#pragma omp parallel for
for (typename T::X i = 0; i < 100; ++i)
;
}
void bar()
{
foo();
}
bug.cc: In instantiation of 'void foo() [with T = int]':
bug.cc:10:12: required from here
bug.cc:4:22: error: 'int' is not a class, struct, or union type
for (typename T::X i = 0; i < 100; ++i)
^
bug.cc:4:3: internal compiler error: tree check: expected tree that contains
'decl common' structure, have 'error_mark' in tsubst_omp_for_iterator, at
cp/pt.c:12938
for (typename T::X i = 0; i < 100; ++i)
^
0xcdaef7 tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
../../gcc/gcc/tree.c:9348
0x5aa6b1 contains_struct_check
../../gcc/gcc/tree.h:2723
0x5aa6b1 tsubst_omp_for_iterator
../../gcc/gcc/cp/pt.c:12938
0x5a55ee tsubst_expr
../../gcc/gcc/cp/pt.c:13481
0x5a43d8 tsubst_expr
../../gcc/gcc/cp/pt.c:13446
0x5a4451 tsubst_expr
../../gcc/gcc/cp/pt.c:13284
0x5a1dcf instantiate_decl(tree_node*, int, bool)
../../gcc/gcc/cp/pt.c:19391
0x5de71f instantiate_pending_templates(int)
../../gcc/gcc/cp/pt.c:19492
0x6198c7 cp_write_global_declarations()
../../gcc/gcc/cp/decl2.c:4060
Please submit a full bug report, [etc.]
[Bug c++/58568] New: [4.8/4.9 Regression] ICE with lambda in invalid template variable definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58568
Bug ID: 58568
Summary: [4.8/4.9 Regression] ICE with lambda in invalid
template variable definition
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following invalid code snippet (compiled with "-std=c++0x") triggers an ICE
since GCC 4.8.1:
==
template struct A
{
static const int i;
template const int A::i = []{ return 0; }();
};
==
bug.cc:4:40: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in begin_lambda_type, at cp/lambda.c:144
template const int A::i = []{ return 0; }();
^
0xcda4a9 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/gcc/tree.c:9227
0x722a3a tree_class_check
../../gcc/gcc/tree.h:2732
0x722a3a begin_lambda_type(tree_node*)
../../gcc/gcc/cp/lambda.c:144
0x641630 cp_parser_lambda_expression
../../gcc/gcc/cp/parser.c:8542
0x641630 cp_parser_primary_expression
../../gcc/gcc/cp/parser.c:4230
0x643970 cp_parser_postfix_expression
../../gcc/gcc/cp/parser.c:5814
0x64615d cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:7009
0x646d3f cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:7701
0x6471ff cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:7937
0x647656 cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:7987
0x647656 cp_parser_constant_expression
../../gcc/gcc/cp/parser.c:8197
0x653601 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:16520
0x653fb4 cp_parser_single_declaration
../../gcc/gcc/cp/parser.c:22652
0x656b80 cp_parser_template_declaration_after_export
../../gcc/gcc/cp/parser.c:22454
0x636882 cp_parser_member_declaration
../../gcc/gcc/cp/parser.c:19703
0x63787e cp_parser_member_specification_opt
../../gcc/gcc/cp/parser.c:19630
0x63787e cp_parser_class_specifier_1
../../gcc/gcc/cp/parser.c:18885
0x63a220 cp_parser_class_specifier
../../gcc/gcc/cp/parser.c:19101
0x63a220 cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:14080
0x64f739 cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:11328
Please submit a full bug report, [etc.]
[Bug c++/58569] New: Compilation error when copying class which contains multiple std::function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58569
Bug ID: 58569
Summary: Compilation error when copying class which contains
multiple std::function
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pierre.krieger1708 at gmail dot com
Created attachment 30924
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30924&action=edit
The preprocessed file
This simple code snippet fails to compile:
#include
struct foo {
std::function x;
std::function y;
};
int main(int argc, char const* argv[]) {
foo a;
return 0;
}
The problem happens if a class contains at least two std::function of different
type which return the class itself.
If you remove the "int" from "foo (int)", it works. If you remove either member
"x" or "y", it works.
With g++4.8.1 and flag -std=c++11:
In file included from test.cpp:1:0:
/usr/include/c++/4.8/functional: In instantiation of ‘struct
std::function::_CheckResult’:
/usr/include/c++/4.8/functional:2192:63: required by substitution of
‘template template
using _Requires = typename std::enable_if<_Cond:: value, _Tp>::type [with _Cond
= std::function::_CheckResult; _Tp = void; _Res = foo;
_ArgTypes = {}]’
/usr/include/c++/4.8/functional:2254:9: required by substitution of
‘template static decltype
((__test_aux<_To1>(declval<_From1>()), std::__sfinae_types::__one()))
std::__is_convertible_helper<_From, _To, false>::__test(int) [with _From1 =
_From1; _To1 = _To1; _From = foo; _To = foo] [with _From1 = foo; _To1 = foo]’
/usr/include/c++/4.8/type_traits:1312:50: required from ‘constexpr const bool
std::__is_convertible_helper::value’
/usr/include/c++/4.8/type_traits:1317:12: required from ‘struct
std::is_convertible’
/usr/include/c++/4.8/functional:2181:9: required from ‘struct
std::function::_CheckResult’
/usr/include/c++/4.8/functional:2192:63: required by substitution of
‘template template
using _Requires = typename std::enable_if<_Cond:: value, _Tp>::type [with _Cond
= std::function::_CheckResult; _Tp = void; _Res = foo;
_ArgTypes = {int}]’
/usr/include/c++/4.8/functional:2254:9: required from here
/usr/include/c++/4.8/functional:2181:9: error: invalid use of incomplete type
‘struct std::is_convertible’
struct _CheckResult
^
In file included from /usr/include/c++/4.8/bits/move.h:57:0,
from /usr/include/c++/4.8/bits/stl_pair.h:59,
from /usr/include/c++/4.8/utility:70,
from /usr/include/c++/4.8/tuple:38,
from /usr/include/c++/4.8/functional:55,
from test.cpp:1:
/usr/include/c++/4.8/type_traits:1317:12: error: declaration of ‘struct
std::is_convertible’
struct is_convertible
^
/usr/include/c++/4.8/type_traits: In substitution of ‘template static decltype ((__test_aux<_To1>(declval<_From1>()),
std::__sfinae_types::__one())) std::__is_convertible_helper<_From, _To,
false>::__test(int) [with _From1 = _From1; _To1 = _To1; _From = foo; _To = foo]
[with _From1 = foo; _To1 = foo]’:
/usr/include/c++/4.8/type_traits:1312:50: required from ‘constexpr const bool
std::__is_convertible_helper::value’
/usr/include/c++/4.8/type_traits:1317:12: required from ‘struct
std::is_convertible’
/usr/include/c++/4.8/functional:2181:9: required from ‘struct
std::function::_CheckResult’
/usr/include/c++/4.8/functional:2192:63: required by substitution of
‘template template
using _Requires = typename std::enable_if<_Cond:: value, _Tp>::type [with _Cond
= std::function::_CheckResult; _Tp = void; _Res = foo;
_ArgTypes = {int}]’
/usr/include/c++/4.8/functional:2254:9: required from here
/usr/include/c++/4.8/type_traits:1302:21: error: initializing argument 1 of
‘static void std::__is_convertible_helper<_From, _To, false>::__test_aux(_To1)
[with _To1 = foo; _From = foo; _To = foo]’
static void __test_aux(_To1);
[Bug c++/58500] [C++1y] Crash with auto in function parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58500 Volker Reichelt changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.9.0 Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #3 from Volker Reichelt --- Fixed by Adam's patch.
[Bug c++/58568] [4.8/4.9 Regression] [c++11] ICE with lambda in invalid template variable definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58568 Paolo Carlini changed: What|Removed |Added Summary|[4.8/4.9 Regression]|[4.8/4.9 Regression] |[c++0x] ICE with lambda in |[c++11] ICE with lambda in |invalid template variable |invalid template variable |definition |definition --- Comment #1 from Paolo Carlini --- Please don't refer anymore to c++0x/C++0x, by now it's legacy.
[Bug tree-optimization/58570] New: wrong code at -Os and above on x86_64-linux-gnu (both 32-bit and 64-bit modes)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58570
Bug ID: 58570
Summary: wrong code at -Os and above on x86_64-linux-gnu (both
32-bit and 64-bit modes)
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk mis-compiles the following code on x86_64-linux at -Os
and above in both 32-bit and 64-bit modes.
This is a regression from 4.8.x.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure
--enable-languages=c,c++,objc,obj-c++,fortran,lto --disable-werror
--enable-checking=release --with-gmp=/usr/local/gcc-trunk
--with-mpfr=/usr/local/gcc-trunk --with-mpc=/usr/local/gcc-trunk
--with-cloog=/usr/local/gcc-trunk --prefix=/usr/local/gcc-trunk
Thread model: posix
gcc version 4.9.0 20130928 (experimental) [trunk revision 203003] (GCC)
$
$ gcc-trunk -O1 small.c
$ a.out
1
$ gcc-4.8 -O3 small.c
$ a.out
1
$ gcc-trunk -O3 small.c
$ a.out
0
$ gcc-trunk -O2 small.c
$ a.out
0
$ gcc-trunk -Os small.c
$ a.out
0
$
int printf (const char *, ...);
#pragma pack(1)
struct S
{
int f0:15;
int f1:29;
};
int a, b, c, e = 1, g;
static struct S d[6];
long long f;
static short
foo (int p)
{
for (b = 0; b < 1; b++)
{
g |= 1;
for (; a < 1; a++)
{
int i;
if (p < c - 1)
return 4;
if (p)
for (i = 0; i < 6; i++)
{
struct S j = {1, 1};
d[i] = j;
}
continue;
}
}
return 0;
}
int
main ()
{
if (e)
foo (!f);
printf ("%d\n", d[0].f1);
return 0;
}
[Bug c/58564] possible wrong code bug at -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58564 Mikael Pettersson changed: What|Removed |Added CC||ktietz at gcc dot gnu.org, ||mikpelinux at gmail dot com --- Comment #1 from Mikael Pettersson --- 4.6 works, 4.7 to trunk don't, started with Kai's r176563.
[Bug c/58564] possible wrong code bug at -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58564 Kai Tietz changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Kai Tietz --- This sample is invalid. And before 4.7 there seems to be wrong result. You missed the following here in your expression 0 > ((&c == d) & (1 && a ^ 1)) The term (1 && a ^ 1) is not the same as (1 & (a ^ 1)) instead it means in fact (1 != 0 && (a ^ 1) != 0. By this term reduces correct to: a ^ 1 != 0 and this is indentical to a != 1. by this we see 0 > (&c == d) & (a != 1). And this is exactly that what AST generates (see here -fdump-tree-original). So error is invalid. But indeed this testcase demonstrate, that we seem to have still pointer-arthimetic optimization issues, due the term (&c == d) was resolved ...
[Bug c++/58569] Compilation error when a class contains multiple std::function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58569 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-28 Ever confirmed|0 |1
[Bug libstdc++/58562] std::sort fails with -D_GLIBCXX_DEBUG enabled, whose bug?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58562 --- Comment #2 from Jonathan Wakely --- > If I turn off -D_GLIBCXX_DEBUG then the code works fine. That usually means "your code is buggy" That's the point of debug mode, it will abort instead of silently ignoring your buggy code. Please provide testcase code to reproduce the problem if you think the bug is in GCC not your code.
[Bug libstdc++/58562] std::sort fails with -D_GLIBCXX_DEBUG enabled, whose bug?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58562 --- Comment #3 from Joshua N Pritikin --- Created attachment 30925 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30925&action=edit C++ source code to reproduce problem With -D_GLIBCXX_DEBUG, fails with: /usr/include/c++/4.7/bits/stl_heap.h:468:error: elements in iterator range [ __first, __last) do not form a heap.
[Bug libstdc++/58562] std::sort fails with -D_GLIBCXX_DEBUG enabled, whose bug?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58562 --- Comment #4 from Joshua N Pritikin --- (In reply to Jonathan Wakely from comment #2) > That usually means "your code is buggy" > > That's the point of debug mode, it will abort instead of silently ignoring > your buggy code. Rockstar programmers assume that the bug is in the compiler/stdlib/kernel/etc. The bug is never in code that I wrote. ;-)
[Bug c/58564] possible wrong code bug at -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58564
--- Comment #3 from John Regehr ---
Kai, this is a real bug, please reopen it.
Here is what I get out of -fdump-tree-original:
b = (int) (d == &c && a != 1);
This is wrong.
One way to illustrate the problem is to remove the useless comma operator from
the test case, which now looks like this (I've also added parens around the ^):
int printf(const char *, ...);
int a, b;
short *c;
short **d = &c;
int main() {
b = (0 > ((&c == d) & (1 && (a ^ 1 | 0U;
printf("%d\n", b);
return 0;
}
Now -fdump-tree-original does a better job:
b = (int) (d == &c && a != 1) < 0;
And now all compilers agree on the output:
[regehr@imp r102]$ gcc-4.4 small2.c ; ./a.out
0
[regehr@imp r102]$ gcc-4.5 small2.c ; ./a.out
0
[regehr@imp r102]$ gcc-4.6 small2.c ; ./a.out
0
[regehr@imp r102]$ gcc small2.c ; ./a.out
0
[regehr@imp r102]$ clang small2.c ; ./a.out
0
