[Bug target/21307] internal compiler error: in change_address_1, at emit-rtl.c:1768
--- Comment #5 from leonid at volnitsky dot com 2008-12-13 20:46 --- Created an attachment (id=16905) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16905&action=view) *.ii file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21307
[Bug target/21307] internal compiler error: in change_address_1, at emit-rtl.c:1768
--- Comment #6 from leonid at volnitsky dot com 2008-12-13 20:54 --- I see same error on Gentoo x86_64, with gcc-4.4 and 4.3.2 Project page: http://volnitsky/project/lvvlib Source: http://github.com/lvv/lvvlib b-array.ii.gz attached. -- g++ b-array.cc -o b-array -save-temps -v -Wall -DID='"081213_223226-��g++-4.4.0-OPTIMIZE-adf3993d++M"' -I ~/p/ -I /usr/local/include -DNDEBUG -DGSL_RANGE_CHECK_OFF -DNOCHECK -pipe -Wno-reorder -Wno-sign-compare -O3 -march=native -fwhole-program --combine -fopenmp -fomit-frame-pointer -funsafe-loop-optimizations g++: warning: -pipe ignored because -save-temps specified Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ./configure : (reconfigured) ./configure --disable-bootstrap --enable-languages=c,c++,fortran --enable-multilib Thread model: posix gcc version 4.4.0 20081208 (experimental) (GCC) COLLECT_GCC_OPTIONS='-o' 'b-array' '-save-temps' '-v' '-Wall' '-DID="081213_223226-��g++-4.4.0-OPTIMIZE-adf3993d++M"' '-I' '/home/lvv/p/' '-I' '/usr/local/include' '-DNDEBUG' '-DGSL_RANGE_CHECK_OFF' '-DNOCHECK' '-pipe' '-Wno-reorder' '-Wno-sign-compare' '-O3' '-fwhole-program' '-combine' '-fopenmp' '-fomit-frame-pointer' '-funsafe-loop-optimizations' '-shared-libgcc' '-pthread' /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/cc1plus -E -quiet -v -I /home/lvv/p/ -I /usr/local/include -D_GNU_SOURCE -D_REENTRANT -DID="081213_223226-��g++-4.4.0-OPTIMIZE-adf3993d++M" -DNDEBUG -DGSL_RANGE_CHECK_OFF -DNOCHECK b-array.cc -march=core2 -mcx16 -msahf --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=4096 -mtune=core2 -Wall -Wno-reorder -Wno-sign-compare -fwhole-program -fopenmp -fomit-frame-pointer -funsafe-loop-optimizations -O3 -fpch-preprocess -o b-array.ii ignoring nonexistent directory "/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../../x86_64-unknown-linux-gnu/include" ignoring duplicate directory "/usr/local/include" as it is a non-system directory that duplicates a system directory ignoring duplicate directory "/usr/local/include" as it is a non-system directory that duplicates a system directory #include "..." search starts here: #include <...> search starts here: /home/lvv/p/ /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../../include/c++/4.4.0 /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../../include/c++/4.4.0/x86_64-unknown-linux-gnu /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../../include/c++/4.4.0/backward /usr/local/include /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/include /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/include-fixed /usr/include End of search list. COLLECT_GCC_OPTIONS='-o' 'b-array' '-save-temps' '-v' '-Wall' '-DID="081213_223226-��g++-4.4.0-OPTIMIZE-adf3993d++M"' '-I' '/home/lvv/p/' '-I' '/usr/local/include' '-DNDEBUG' '-DGSL_RANGE_CHECK_OFF' '-DNOCHECK' '-pipe' '-Wno-reorder' '-Wno-sign-compare' '-O3' '-fwhole-program' '-combine' '-fopenmp' '-fomit-frame-pointer' '-funsafe-loop-optimizations' '-shared-libgcc' '-pthread' /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/cc1plus -fpreprocessed b-array.ii -march=core2 -mcx16 -msahf --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=4096 -mtune=core2 -quiet -dumpbase b-array.cc -auxbase b-array -O3 -Wall -Wno-reorder -Wno-sign-compare -version -fwhole-program -fopenmp -fomit-frame-pointer -funsafe-loop-optimizations -o b-array.s GNU C++ (GCC) version 4.4.0 20081208 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.4.0 20081115 (experimental), GMP version 4.2.4, MPFR version 2.3.2. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: f0165b2e8081c04e24b530c99a2b0b81 b-array.cc: In function ‘int main(int, char**)’: b-array.cc:103: internal compiler error: in change_address_1, at emit-rtl.c:1866 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. make: *** [b-array] Error 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21307
[Bug target/21307] internal compiler error: in change_address_1, at emit-rtl.c:1768
--- Comment #7 from leonid at volnitsky dot com 2008-12-13 21:15 --- Found error cause. By changing line: const static unsigned long N = 10; to const static unsigned long N = 1; I was able to compile. I recall that I’ve seen this error in the past too when I had similar const signed variable with negative value when it was used as array declaration for dimension size. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21307
[Bug c++/38525] New: sse2(int16) code fails with -O3
funsafe-loop-optimizations' '-DGCC_BUG' '-O3' '-v' '-Wno-unused-variable' '-shared-libgcc' '-pthread' /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/collect2 --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o u-array /usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/crtbegin.o -L/usr/local/lib/../lib64 -L/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0 -L/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L. -L/usr/local/lib -L/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../.. /tmp/ccO8IZrX.o -lstdc++ -lm -lgomp -lgcc_s -lgcc -lpthread -lc -lgcc_s -lgcc /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/crtend.o /usr/lib/../lib64/crtn.o -- Summary: sse2(int16) code fails with -O3 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: leonid at volnitsky dot com GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38525
[Bug c++/38525] sse2(int16) code fails with -O3
--- Comment #1 from leonid at volnitsky dot com 2008-12-14 16:52 --- Created an attachment (id=16907) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16907&action=view) u-array.ii -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38525
[Bug c++/38525] sse2(int16) code fails with -O3
--- Comment #6 from leonid at volnitsky dot com 2008-12-14 21:00 --- Created an attachment (id=16910) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16910&action=view) Trimmed unit test. Only one, relevant to bug test -- leonid at volnitsky dot com changed: What|Removed |Added Attachment #16907|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38525
[Bug c++/38525] sse2(int16) code fails with -O3
--- Comment #7 from leonid at volnitsky dot com 2008-12-14 22:32 ---
(In reply to comment #2)
> ... please reduce your source to a
> short, self contained runtime testcase (in plain C if possible) that fails
> with
> certain compile flags.
I've tried to do that (see below). But unfortunately it does not exhibit same
behavior. It will fail on any optimized compile with warning about aliasing.
Which is fixable by adding -fno-strict-aliasing. Don't know if this is related
on not.
-
#include
#include
int main(int argc, char *argv[]) {
int16_t volatile A[2000];
for (int i=0; i<(2000-2); i+=2) { A[i]=1; A[i+1]=2; }; A[333] = 3;
#define mk_m128i(x) *(__m128i*)&(x)
__m128i m1 = mk_m128i(A[0]);
__m128i m2 = mk_m128i(A[8]);
for (int i= 16; i < 2000-16; i+=16) { // SSE
m1 = _mm_max_epi16(m1, mk_m128i(A[i]) );
m2 = _mm_max_epi16(m2, mk_m128i(A[i+8]) );
}
m1 = _mm_max_epi16(m1, m2);
int16_t* ip = (int16_t*)&m1;
printf("%hi %hi %hi %hi %hi %hi %hi %hi \n", *ip++, *ip++, *ip++,
*ip++, *ip++, *ip++, *ip++, *ip);
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38525
[Bug c++/38525] sse2(int16) code fails with -O3
--- Comment #9 from leonid at volnitsky dot com 2008-12-16 13:21 --- (In reply to comment #8) >> int16_t* ip = (int16_t*)&m1; > That is violating C/C++ aliasing rules The code that you quote is not part of the reported bug. It was quick and dirty hack. But that was it. Adding -fno-strict-aliasing fixed unit tests. But then there is a question. Full code attached to the bug does not gave any warning about aliasing violation with -Wall and -O3. Is no-warning a bug? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38525
[Bug c++/54111] function return type template deduction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54111
--- Comment #5 from Leonid Volnitsky 2012-08-15
17:34:41 UTC ---
More combinatorics and more test (gcc-trunk, clang-trunk and gcc463). Now
everything in one file.
-
#include
#include
using namespace std;
int& plaint_f( int& x) {return x;};
const int& plaint_f(const int& x) {return x;};
template
R eval (T& x, R& (*f)(T&)) {
return (*f)(x);
};
template
R eval_const (const T& x, const R& (*f)(const T&)) {
return (*f)(x);
};
template
R eval_tuple_int (T& x, R& (*f)(T&)) {
return (*f)(x);
};
template
R eval_tuple_int_const (T& x, const R& (*f)(const T&)) {
return (*f)(x);
};
template
R eval_tuple (tuple& x, R& (*f)(tuple&)) {
return (*f)(x);
};
template
R eval_tuple_int (tuple& x, R& (*f)(tuple&)) {
return (*f)(x);
};
template
R eval_tuple_const (const tuple& x, R& (*f)(const tuple&)) {
return (*f)(x);
};
template
R eval_tuple_const_int (const tuple& x, R& (*f)(const tuple&)) {
return (*f)(x);
};
int main() {
// int i42=42;
// return eval(i42, plaint_f);
// OK
// 20.4.2.6 GET<..>(TUPLE)
//
// template
// typename tuple_element >::type&
get(tuple&) noexcept;
//
// template
// typename tuple_element >::type&&
get(tuple&&) noexcept;
//
// template
// typename tuple_element >::type
const& get(const tuple&) noexcept;
tuple tpl(42,43);
// INT eval..(TUPLE)
// return eval_tuple_int(tpl, get<0,int,int>);
//gcc48-ERROR types ‘tuple<_Elements ...>’ and ‘const pair’
have incompatible cv-qualifiers
//gcc46-OK
//clang-OK
// return eval_tuple_int(tpl, get<0>);
//gcc48-OK
//gcc46-OK
//clang-OK
// return eval_tuple_int_const(tpl, get<0,int,int>);
//gcc48-OK
//gcc46-OK
//clang-OK
// return eval_tuple_int_const(tpl, get<0>);
//gcc48-OK
//gcc46-OK
//clang-OK
// eval(TUPLE)
// return eval(tpl, get<0>);
//gcc48-ERROR couldn't deduce template parameter ‘R’
//gcc46-ERROR
//clang-ERROR couldn't infer template argument 'R'
// return eval(tpl, get<0,int,int>);
//gcc48-ERROR could not resolve address from overloaded function
‘get<0, int, int>’
//gcc46-OK
//clang-ERROR couldn't infer template argument 'R'
// return eval_const(tpl, get<0>);
//gcc48-ERROR couldn't deduce template parameter ‘R’
//gcc46-ERROR
//clang-ERROR couldn't infer template argument 'R'
// return eval_const(tpl, get<0,int,int>);
//gcc48-OK
//gcc46-OK
//clang-ERROR couldn't infer template argument 'R'
// eval_tuple..(TUPLE)
// return eval_tuple(tpl, get<0,int,int>);
//gcc48-ERROR types ‘tuple<_Elements ...>’ and ‘const tuple’ have incompatible cv-qualifiers
//gcc46-OK
//clang-OK
// return eval_tuple_const(tpl, get<0,int,int>);
//gcc48-OK
//gcc46-OK
//clang-OK
// return eval_tuple_const(tpl, get<0>);
//gcc48-ERROR couldn't deduce template parameter ‘R’
//gcc46-ERROR
//clang-ERROR
}
[Bug c++/54425] New: Rvalue/Lvalue overload resolution of templated function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54425
Bug #: 54425
Summary: Rvalue/Lvalue overload resolution of templated
function
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: leo...@volnitsky.com
Code below is rejected by 4.8.0. FWIW - it is accepted by clang32 and latest
VC.
-
template void f(T& t) {};
template void f(T&& t) {};
int main() {
int lv{11};
f(lv); // error: ambigues overload
}
-
[Bug c++/54538] New: Getting assembler messages when compiling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54538
Bug #: 54538
Summary: Getting assembler messages when compiling
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: leo...@volnitsky.com
Created attachment 28157
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28157
scc.ii
I am getting "Assembler Messages" below from gcc-4.8 when compiling my code.
scc.ii file is attached (original code -- https://github.com/lvv/scc ). I can
successfully compile if I will use gcc-3.7.1.
Error Messages:
---
{standard input}: Assembler messages:
{standard input}:12769: Error: symbol
`_ZNK3sto11chain_rangeIT_E12default_predMUlRKiE_clES4_' is already defined
{standard input}:17883: Error: symbol
`_ZSt4moveIRN3sto11chain_rangeIT_E12default_predMUlRKiE_EEONSt16remove_referenceIS2_E4typeEOS2_'
is already defined
{standard input}:17903: Error: symbol
`_ZNSt8functionIFbRKiEEC2IN3sto11chain_rangeIT_E12default_predMUlS1_E_EvEET_'
is already defined
{standard input}:23564: Error: symbol
`_ZNSt14_Function_base13_Base_managerIN3sto11chain_rangeIT_E12default_predMUlRKiE_EE21_M_not_empty_functionIS7_EEbRKT_'
is already defined
{standard input}:23583: Error: symbol
`_ZNSt17_Function_handlerIFbRKiEN3sto11chain_rangeIT_E12default_predMUlS1_E_EE9_M_invokeERKSt9_Any_dataS1_'
is already defined
{standard input}:23617: Error: symbol
`_ZNSt14_Function_base13_Base_managerIN3sto11chain_rangeIT_E12default_predMUlRKiE_EE10_M_managerERSt9_Any_dataRKS9_St18_Manager_operation'
is already defined
{standard input}:23722: Error: symbol
`_ZNSt14_Function_base13_Base_managerIN3sto11chain_rangeIT_E12default_predMUlRKiE_EE15_M_init_functorERSt9_Any_dataOS7_'
is already defined
{standard input}:28014: Error: symbol
`_ZNSt14_Function_base13_Base_managerIN3sto11chain_rangeIT_E12default_predMUlRKiE_EE14_M_get_pointerERKSt9_Any_data'
is already defined
{standard input}:28040: Error: symbol
`_ZNSt9_Any_data9_M_accessIPN3sto11chain_rangeIT_E12default_predMUlRKiE_EEERS3_v'
is already defined
{standard input}:28062: Error: symbol
`_ZNSt14_Function_base13_Base_managerIN3sto11chain_rangeIT_E12default_predMUlRKiE_EE8_M_cloneERSt9_Any_dataRKS9_St17integral_constantIbLb0EE'
is already defined
{standard input}:28096: Error: symbol
`_ZNSt14_Function_base13_Base_managerIN3sto11chain_rangeIT_E12default_predMUlRKiE_EE10_M_destroyERSt9_Any_dataSt17integral_constantIbLb0EE'
is already defined
{standard input}:28121: Error: symbol
`_ZNSt14_Function_base13_Base_managerIN3sto11chain_rangeIT_E12default_predMUlRKiE_EE15_M_init_functorERSt9_Any_dataOS7_St17integral_constantIbLb0EE'
is already defined
{standard input}:31822: Error: symbol
`_ZNKSt9_Any_data9_M_accessIPN3sto11chain_rangeIT_E12default_predMUlRKiE_EEERKS3_v'
is already defined
--
Compiled with:
g++ -std=gnu++11 -Wall -pipe -Wno-sign-compare -I /home/lvv/p/ -include debug.h
-Wno-unused-function -I /home/lvv/p/scc -I /home/lvv/p -include
/home/lvv/p/scc/.scc.h /home/lvv/p/scc/scc.cc -o /tmp/lvv-scc
GCC version:
gcc -v
Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.0-pre/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.0-pre/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.8.0_pre/work/gcc-4.8.0-/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.0-pre
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-pre/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-pre
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-pre/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-pre/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-pre/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--disable-fixed-point --with-ppl --with-cloog --disable-ppl-version-check
--with-cloog-include=/usr/include/cloog-ppl --enable-lto --enable-nls
--without-included-gettext --with-system-zlib --enable-obsolete
--disable-werror --enable-secureplt --enable-multilib
--with-multilib-list=m32,m64 --enable-libmudflap --disable-libssp
--enable-libgomp
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-pre/python
--enable-checking=release --disable-libgcj --enable-languages=c,c++,go,fortran
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --enable-targets=all --with-bugurl=http://bugs.gentoo.org/
--with-pkgversion='Gentoo 4.8.0_pre'
Thread model: posix
gcc version 4.8.0-pre 20120820 (experimental) commit
2bf99680c2012de150798c933642aa4c82a85410 (Gentoo 4.8.0_pre)
[Bug c++/54538] [4.8 Regression] Getting assembler messages when compiling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54538 --- Comment #4 from Leonid Volnitsky 2012-09-10 09:07:23 UTC --- > I can successfully compile if I will use gcc-3.7.1 Incorrect version. It should be 4.7.1
[Bug c++/54538] [4.8 Regression] Getting assembler messages when compiling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54538 --- Comment #6 from Leonid Volnitsky 2012-09-10 14:39:26 UTC --- This code is very alpha and not supposed to be compiled with something not GCC. CLANG probably will be able to compile it when they will fix constexpr bug 11851 ( http://llvm.org/bugs/show_bug.cgi?id=11851). Don't know about ICC or how it supports C++11. Assembler messeges were not from unit test, but from this: scc 1
[Bug c++/54538] [4.8 Regression] Getting assembler messages when compiling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54538 --- Comment #7 from Leonid Volnitsky 2012-09-10 14:43:55 UTC --- It seams that gcc bugzilla substituted text "bug some-number" with erroneous link.
[Bug c++/54648] New: constexpr function rejected as non const
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54648
Bug #: 54648
Summary: constexpr function rejected as non const
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: leo...@volnitsky.com
I am getting from gcc-4.8.0 20120920 for constexpr function:
error: integral expression ‘is_range&>()’ is not constant
With gcc-4.7.1 (and with gcc-4.8 older than a month) it compiles correctly.
This error is generated only in some particular combination of source code. I
was not able to reproduce it in minimal example. File main.ii is attached.
Function is_range is defined as:
--
template
constexpr bool
is_range(){ return is_range_t::value; };
--
Type is_range_t defined as:
-
template
struct is_range_t {
template <
class U,
class I = typename U::const_iterator
>
static int8_t
test(U* u);
template
static int16_t
test(...);
enum { value = sizeof test > (0) == 1 };
};
template struct is_range_t : std::true_type { };
template struct is_range_t : std::true_type {
};
template struct is_range_t > :
std::true_type { };
template constexpr bool is_range() { return is_range_t::value;
};
-
[Bug c++/54648] constexpr function rejected as non const
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54648 --- Comment #1 from Leonid Volnitsky 2012-09-21 00:59:30 UTC --- Created attachment 28241 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28241 main.ii
[Bug c++/54648] constexpr function rejected as non const
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54648 --- Comment #2 from Leonid Volnitsky 2012-09-26 13:16:16 UTC --- Found bad commit. Quick recap: GCC says that expression sizeof()==1 is not constexpr. Commit is about template aliases and they are used in expression. Bad commit (as reported by git): 6423a93273627b3d1ff3a799d23baa7eae6e6cc9 is the first bad commit commit 6423a93273627b3d1ff3a799d23baa7eae6e6cc9 Author: jason Date: Tue Sep 18 03:47:35 2012 + PR c++/54575 * pt.c (instantiate_alias_template): New. (tsubst): Use it. (push_access_scope): Allow TYPE_DECL. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@191412 138bc75d-0d04-0410-961f-82ee72b054a4 :04 04 51d12d90281f31fa13167d674af17c710145c900 0f9f175917aa843c713a0415f542801bc391f0e0 M gcc
[Bug c++/54764] New: In class initialization of non-static lambda member can't be used in class with default template paramer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54764
Bug #: 54764
Summary: In class initialization of non-static lambda member
can't be used in class with default template paramer
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: leo...@volnitsky.com
Clang-3.2 compiles (FWIW), but rejected by GCC 4.7.1 and 4.8:
--
#include
template
struct c{
std::function f = [](int i){return i+i;};
};
int main() {}
---
Error message:
t.cc:6:31: error: default argument for template parameter for class enclosing
‘struct __lambda0’
function f = [](int i){return i+i;};
^
[Bug c++/54853] New: (gcc4.7.2) internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54853 Bug #: 54853 Summary: (gcc4.7.2) internal compiler error: Segmentation fault Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: leo...@volnitsky.com Created attachment 28381 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28381 main.ii.gz I am getting: /home/lvv/p/scc/chain_range.h:246:25: internal compiler error: Segmentation fault Preprocessed source is attached gcc -v Using built-in specs. COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.7.2/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.7.2/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.7.2/work/gcc-4.7.2/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.7.2 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.7.2 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.7.2/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.7.2/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --with-ppl --with-cloog --disable-ppl-version-check --with-cloog-include=/usr/include/cloog-ppl --enable-lto --enable-nls --without-included-gettext --with-system-zlib --enable-obsolete --disable-werror --enable-secureplt --enable-multilib --with-multilib-list=m32,m64 --enable-libmudflap --disable-libssp --enable-libgomp --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.7.2/python --enable-checking=release --disable-libgcj --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-targets=all --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.7.2 p1.0, pie-0.5.3' Thread model: posix gcc version 4.7.2 (Gentoo 4.7.2 p1.0, pie-0.5.3)
[Bug c++/54853] (gcc4.7.2) internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54853
--- Comment #2 from Leonid Volnitsky 2012-10-08
10:54:17 UTC ---
> but there are lots of errors
Below 1-line change commit which caused ICE
(http://github.com/lvv/scc/commit/33d60adcf9ea5307ccaf186f558c338424299a56):
//
diff --git c/chain_range.h w/chain_range.h
index 0d3c140..45f6f5e 100644
--- c/chain_range.h
+++ w/chain_range.h
@@ -242,7 +242,7 @@ struct chain_range : ref_container {
template eIF()> pop_back() {rg.pop_back();}
template eIF()> pop_front() {rg.pop_front();}
- auto operator[] (difference_type n) -> decltype(rg[n]) { return rg[n]; }
+ template R operator[] (difference_type n) {
return rg[n];}
// ADDED RG METHODS
template
//
I can not see were code is invalid. Maybe you can. I am not sure on what
branch the commit you mentioned is, but it is true, this code can not compiled
with gcc-4.8. Because of regression bug 54648 (caused by commit 191412), gcc
can not handle constexpr in this code. I am removing all constexpr code as
result (and clang is even worse in this regard).
[Bug c++/54859] New: constexpr in template aliase rejected as non-constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54859
Bug #: 54859
Summary: constexpr in template aliase rejected as non-constant
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: leo...@volnitsky.com
clang-3.2 and gcc-4.7.2 compiles, gcc-4.8 rejects:
--
// enbale_if
template
struct enable_if { typedef T type; };
template
struct enable_if {};
// template alias
template
using eIF = typename enable_if ::type;
// f - this compiles
template
typename enable_if::type f() { return 20; }
// ff - error: integral expression ‘! B’ is not constant
template
eIF ff() { return 20; }
int main() {}
---
This seams to be related to bug 54648, where I found bad commit to be 191412
[Bug c++/55002] New: trailing return type is rejected in function signature
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55002
Bug #: 55002
Summary: trailing return type is rejected in function signature
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: leo...@volnitsky.com
7.1.6.4 auto specifier [dcl.spec.auto]
note 2: The auto type-specifier may appear with a function declarator
with a trailing-return-type (8.3.5) in any context where such a
declarator is valid
Contrived example:
-
typedef unsigned long size_t;
// overload c-array
template
size_t
size(T (&)[N]) { return N; }
// overload - c-string
template
size_t
size(char (&A)[N]) { size_t i=0; while(A[i++]); return i; }
// APPLY
// this works
template size_t apply (const T (&A)[N], size_t (*f)
(const T (&)[N]))
// this rejected -- error: parameter declared ‘auto’
//template size_t apply (const T (&A)[N], auto (*f) ->
size_t (const T (&)[N]))
{ return f(A); };
int main() {
int A[2];
return apply(A, size);
}
--
Without trailing return type in signature it is impossible to write apply-like
function with can deduce function-type for overloaded functions.
[Bug c++/55002] trailing return type is rejected in function signature
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55002
--- Comment #1 from Leonid Volnitsky 2012-10-20
19:20:00 UTC ---
I've probably overcomplicated my example. Simpler test case:
--
int f(auto (*ff) -> int (int) ) {
return ff(1);
}
--
[Bug c++/54853] internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54853 --- Comment #4 from Leonid Volnitsky --- I can not reproduce this ICE with 4.8.1. It is ok to close this bug.
[Bug c++/53858] New: template aliases used in template parameters default expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53858
Bug #: 53858
Summary: template aliases used in template parameters default
expression
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: leo...@volnitsky.com
gcc-4.8 compile error when template aliases used in template parameters default
expression. There was no error with gcc-4.7.1
---
template struct s0 { typedef T tdef0; };
template struct s1 { typedef T tdef1; };
template using us1 = typename s1::tdef1;
template ::tdef0> struct s2 {};
int main () { return 0; }
--
g++ -std=gnu++11 t.cc
t.cc:4:49: error: expected nested-name-specifier
template ::tdef0> struct s2 {};
^
t.cc:4:49: error: expected ‘>’
gcc -v
Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.0-pre/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.0-pre/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.8.0_pre/work/gcc-4.8.0-/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.0-pre
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-pre/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-pre
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-pre/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-pre/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-pre/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--disable-fixed-point --with-ppl --with-cloog --disable-ppl-version-check
--with-cloog-include=/usr/include/cloog-ppl --enable-lto --enable-nls
--without-included-gettext --with-system-zlib --enable-obsolete
--disable-werror --enable-secureplt --enable-multilib
--with-multilib-list=m32,m64 --enable-libmudflap --disable-libssp
--enable-libgomp
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-pre/python
--enable-checking=release --disable-libgcj --enable-languages=c,c++,go,fortran
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --enable-targets=all --with-bugurl=http://bugs.gentoo.org/
--with-pkgversion='Gentoo 4.8.0_pre'
Thread model: posix
gcc version 4.8.0-pre 20120704 (experimental) commit
3d02dd733723c41be7c56f814a3072cee1b43ecc (Gentoo 4.8.0_pre)
---
[Bug c++/54111] New: function return type template deduction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54111
Bug #: 54111
Summary: function return type template deduction
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: leo...@volnitsky.com
Created attachment 27882
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27882
4 source code files.
Possible regression.
There are 4 version of slightly different versions of below code (file
bug-u2.cc):
-
#include
template
U operator* (T x, U& (*f)(T&) ) {
return (*f)(x);
};
int main() {
std::tuple tpl(42,43);
return tpl * std::get<0,int,int>;
}
These 4 versions are combination of 2 variants:
- if template parameter U or hardcoded type int is used (codes int or u)
- if get<0,int,int> or get<0> is used (codes 2 and 0)
4 version of above code are attached.
For 3 versions of GCC that I have:
453 471 480-pre
--
bug-int0.ccaccpaccpaccp
bug-int2.ccaccprej rej
bug-u0.cc rej rej rej
bug-u2.cc accprej rej
It seems that gcc463 behave the same as 453.
[Bug c++/54111] function return type template deduction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54111 --- Comment #1 from Leonid Volnitsky 2012-08-02 04:02:27 UTC --- I've just tested with gcc-463.It accept/reject exactly the same as gcc-453.
[Bug c++/54111] function return type template deduction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54111 --- Comment #3 from Leonid Volnitsky 2012-08-02 11:13:26 UTC --- if in bug-int2.cc (and only in this file) to replace tuple with pair - it becomes accepted by any gcc version.
[Bug c++/54111] function return type template deduction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54111 --- Comment #4 from Leonid Volnitsky 2012-08-02 13:12:44 UTC --- Please disregard my last message (about std::pair) - it was incorrect.
[Bug c++/51989] New: std::deque::iterator recognised as container
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51989
Bug #: 51989
Summary: std::deque::iterator recognised as container
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: leo...@volnitsky.com
Created attachment 26450
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26450
deque-bug.cc
I need is_container template which would recognize if T is a container.
Code below works as expected. With exception for std::deque::iterator - gcc
can not compile code below:
--
#include
#include
#include
#include
#include
#include
template
struct is_container {
template
static char test(
U* u,
typename U::const_iterator b = ((U*)0)->begin(),
typename U::const_iterator e = ((U*)0)->end()
);
template static long test(...);
enum { value = sizeof test(0) == 1 };
};
int main() {
std::cout << "void\t"<< is_container< void
>::value << '\n';
std::cout << "int\t"<< is_container< int >::value
<< '\n';
std::cout << "int*\t"<< is_container< int*
>::value << '\n';
std::cout << "vector\t"<< is_container< std::vector
>::value << '\n';
std::cout << "deque\t"<< is_container< std::deque
>::value << '\n';
std::cout << "set::iterator\t"<< is_container<
std::set::iterator >::value << '\n';
std::cout << "vector::iterator\t"<< is_container<
std::vector::iterator >::value << '\n';
// gcc error
std::cout << "deque::iterator\t"<< is_container<
std::deque::iterator >::value << '\n';
}
---
Compiling it with GCC (4.7.0-alpha20111203):
gcc -std=gnu++0x -Wall deque-bug.cc -o deque-bug
Produce following error:
deque-bug.cc: In instantiation of ‘struct
is_container >’:
deque-bug.cc:31:84: required from here
deque-bug.cc:18:7: error: ‘struct std::_Deque_iterator’ has no
member named ‘begin’
deque-bug.cc:18:7: error: ‘struct std::_Deque_iterator’ has no
member named ‘end’
Attached are source and -save-temps
[Bug c++/51989] std::deque::iterator recognised as container
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51989 --- Comment #1 from Leonid Volnitsky 2012-01-25 05:03:14 UTC --- Created attachment 26451 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26451 deque-bug.ii
[Bug c++/51989] std::deque::iterator recognised as container
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51989 --- Comment #2 from Leonid Volnitsky 2012-01-25 05:04:00 UTC --- Created attachment 26452 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26452 deque-bug.s
[Bug c++/51989] std::deque::iterator recognised as container
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51989 --- Comment #3 from Leonid Volnitsky 2012-01-25 05:04:56 UTC --- Created attachment 26453 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26453 gcc error
[Bug c++/51989] std::deque::iterator recognised as container
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51989 --- Comment #6 from Leonid Volnitsky 2012-01-25 10:29:29 UTC --- Also, new is_container with decltype, have value == 0 for any, non-void type.
[Bug c++/51989] std::deque::iterator recognised as container
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51989 --- Comment #8 from Leonid Volnitsky 2012-01-25 12:29:22 UTC --- I understand that. And thank you for giving me a hint and code for is_container, it was more than I expected if it was non-bug. I've made the comment only because I've thought that it might help to diagnose the problem, if there is a bug after all.
[Bug c++/55694] New: LD error if 0 is added to int variable.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55694 Bug #: 55694 Summary: LD error if 0 is added to int variable. Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: leo...@volnitsky.com Not sure if this is a bug. It have same behavior with gcc-4.7.2, gcc-4.8.0-20121208 and clang-3.2. I was not able to reproduce this error in minimal example. Attached two files: ld-error.ii and no-error.ii. -- diff *.ii 97125c97125 < out(), is_callable::value; --- > out(), 0+is_callable::value; -- So after adding 0 to integer expression there is no error. This is heavy mataprogramming code. is_callable - metafunction comma - is overloaded out() - some temporary object Error message: --- g++-4.8.0-pre: warning: -pipe ignored because -save-temps specified main.o: In function `main': /tmp/scc-lvv-pts1/snippet.cc:2: undefined reference to `sto::is_callable::value' collect2: error: ld returned 1 exit status ---
[Bug c++/55694] LD error if 0 is added to int variable.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55694 --- Comment #1 from Leonid Volnitsky 2012-12-14 19:34:14 UTC --- Created attachment 28963 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28963 ld-error.ii.gz
[Bug c++/55694] LD error if 0 is added to int variable.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55694 --- Comment #2 from Leonid Volnitsky 2012-12-14 19:35:19 UTC --- Created attachment 28965 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28965 no-error.ii.gz
[Bug c++/55694] LD error if 0 is added to int variable.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55694 --- Comment #5 from Leonid Volnitsky 2012-12-15 06:01:47 UTC --- Thanks Jonathan. I've figured this out. One more reason why enum is better than static const.
[Bug c++/55766] New: temlate alias is not equivalent (const-ness is not recognized)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55766 Bug #: 55766 Summary: temlate alias is not equivalent (const-ness is not recognized) Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: leo...@volnitsky.com Created attachment 29016 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29016 goog.ii I have following alias in my code: template using eIF = typename std::enable_if ::type; I encountered code where alias is not equivalent to direct use of enable_if. Attached are good.ii (with enable_if) which both GCC480-20121220 and CLANG32 can compile, and bad.ii (with alias eIF), which only CLANG can compile. diff good.ii bad.ii 80517c80517 < typename std::enable_if<(sizeof(Arg1),N==1), Arg1>::type --- > eIF<(sizeof(Arg1),N==1), Arg1> 80522c80522 < typename std::enable_if<(sizeof(Arg1),N==2), Arg2>::type --- > eIF<(sizeof(Arg1), N==2), Arg2> Comma op in expression (sizeof(Arg1),N==1) used to makes templated member function depend on Arg1 template argument (to trigger SFINAE). Error message: lambda.h:45:2: error: integral expression ‘(0, false)’ is not constant
[Bug c++/55766] temlate alias is not equivalent (const-ness is not recognized)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55766 --- Comment #1 from Leonid Volnitsky 2012-12-20 18:37:19 UTC --- Created attachment 29017 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29017 bad.ii
[Bug c++/55766] template alias is not equivalent (const-ness is not recognized)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55766 --- Comment #4 from Leonid Volnitsky 2012-12-21 05:32:23 UTC --- And as I just found, dup of bug 54648 too, which I reported on 2012-09 and found bad commit.
[Bug c++/55856] New: ICE on tuple with rvalue ref member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55856
Bug #: 55856
Summary: ICE on tuple with rvalue ref member
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: leo...@volnitsky.com
--
#include
#include
std::tuple A{1}; // ok
std::string&& B{""}; // ok
std::tuple C{""}; // ICE
//int main() {};
---
Code as shown have dangling rval ref to string&& in C.
But if we would build rvalue tuple, this would be valid code (temp string
should live with lifespan of initialization expressions).
Error message:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-pre/include/g++-v4/tuple:135:46:
internal compiler error: in build_data_member_initialization, at
cp/semantics.c:5853
: _M_head_impl(std::forward<_UHead>(__h)) { }
^
Please submit a full bug report,
