[Bug sanitizer/60038] New: AddressSanitizer CHECK failed ... "((*tls_addr + *tls_size)) <= ((*stk_addr + *stk_size))" on CentOS 5.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60038 Bug ID: 60038 Summary: AddressSanitizer CHECK failed ... "((*tls_addr + *tls_size)) <= ((*stk_addr + *stk_size))" on CentOS 5.10 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: ubizjak at gmail dot com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org Target: x86_64-linux-gnu Many tests in address sanitizer testsuite fail on CentOS 5.10, on x86_64 64bit target: FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_PthreadExitTest execution test FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_ThreadedStressStackReuseTest execution test FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_ThreadNamesTest execution test FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_ThreadedTest ThreadedTestSpawn() output pattern test FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_ThreadStackReuseTest execution test FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_ManyThreadsTest execution test FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_ThreadedMallocStressTest execution test FAIL: g++.dg/asan/deep-thread-stack-1.C -O0 output pattern test, is ==28946==AddressSanitizer CHECK failed: ../../../../gcc-svn/trunk/libsaniti zer/sanitizer_common/sanitizer_linux_libcdep.cc:260 "((*tls_addr + *tls_size)) <= ((*stk_addr + *stk_size))" (0x2ba95e3ff240, 0x2ba95e3ff000) FAIL: g++.dg/asan/deep-thread-stack-1.C -O1 output pattern test, is ==28972==AddressSanitizer CHECK failed: ../../../../gcc-svn/trunk/libsaniti zer/sanitizer_common/sanitizer_linux_libcdep.cc:260 "((*tls_addr + *tls_size)) <= ((*stk_addr + *stk_size))" (0x2b904ae5e240, 0x2b904ae5e000) FAIL: g++.dg/asan/deep-thread-stack-1.C -O2 output pattern test, is ==28990==AddressSanitizer CHECK failed: ../../../../gcc-svn/trunk/libsaniti zer/sanitizer_common/sanitizer_linux_libcdep.cc:260 "((*tls_addr + *tls_size)) <= ((*stk_addr + *stk_size))" (0x2b7261726240, 0x2b7261726000) FAIL: g++.dg/asan/deep-thread-stack-1.C -O3 -fomit-frame-pointer output pattern test, is ==29015==AddressSanitizer CHECK failed: ../../../../gc c-svn/trunk/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc:260 "((*tls_addr + *tls_size)) <= ((*stk_addr + *stk_size))" (0x2b7f30b2f240 , 0x2b7f30b2f000) FAIL: g++.dg/asan/deep-thread-stack-1.C -O3 -g output pattern test, is ==29038==AddressSanitizer CHECK failed: ../../../../gcc-svn/trunk/libsan itizer/sanitizer_common/sanitizer_linux_libcdep.cc:260 "((*tls_addr + *tls_size)) <= ((*stk_addr + *stk_size))" (0x2ae7a3e97240, 0x2ae7a3e97000) FAIL: g++.dg/asan/deep-thread-stack-1.C -Os output pattern test, is ==29078==AddressSanitizer CHECK failed: ../../../../gcc-svn/trunk/libsaniti zer/sanitizer_common/sanitizer_linux_libcdep.cc:260 "((*tls_addr + *tls_size)) <= ((*stk_addr + *stk_size))" (0x2b8e40e38240, 0x2b8e40e38000) FAIL: g++.dg/asan/deep-thread-stack-1.C -O2 -flto -flto-partition=none output pattern test, is ==29134==AddressSanitizer CHECK failed: ../../.. /../gcc-svn/trunk/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc:260 "((*tls_addr + *tls_size)) <= ((*stk_addr + *stk_size))" (0x2b1d04 5f7240, 0x2b1d045f7000) FAIL: g++.dg/asan/deep-thread-stack-1.C -O2 -flto output pattern test, is ==29196==AddressSanitizer CHECK failed: ../../../../gcc-svn/trunk/lib sanitizer/sanitizer_common/sanitizer_linux_libcdep.cc:260 "((*tls_addr + *tls_size)) <= ((*stk_addr + *stk_size))" (0x2b99bff03240, 0x2b99bff0300 0) All these fail on the same check, in the same way. The same tests also fail on i686 32bit targets, with different addresses, e.g.: FAIL: g++.dg/asan/deep-thread-stack-1.C -O0 output pattern test, is ==2673==AddressSanitizer CHECK failed: ../../../../../gcc-svn/trunk/libsani tizer/sanitizer_common/sanitizer_linux_libcdep.cc:260 "((*tls_addr + *tls_size)) <= ((*stk_addr + *stk_size))" (0xf6592020, 0xf6592000)
[Bug libstdc++/57350] std::align missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57350 --- Comment #8 from Jonathan Wakely --- (In reply to Vladimir Krivopalov from comment #3) > Any chance to get std::align() implementation included in the coming GCC > releases? > What needs to be done for that? It's too late for GCC 4.9 now.
[Bug libstdc++/60020] Considering backport regexp support to 4.8+
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60020 --- Comment #1 from Jonathan Wakely --- No.
[Bug libstdc++/60037] SIGFPE in std::generate_canonical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60037 --- Comment #1 from ppluzhnikov at gcc dot gnu.org --- Author: ppluzhnikov Date: Mon Feb 3 06:48:48 2014 New Revision: 207416 URL: http://gcc.gnu.org/viewcvs?rev=207416&root=gcc&view=rev Log: xfail ext/random/hypergeometric_distribution/operators/values.cc due to PR 60037: SIGFPE when the test is built without optimization. Modified: branches/google/main/contrib/testsuite-management/x86_64-grtev4-linux-gnu.xfail
[Bug libstdc++/60037] New: SIGFPE in std::generate_canonical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60037 Bug ID: 60037 Summary: SIGFPE in std::generate_canonical Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: ppluzhnikov at google dot com When libstdc++-v3/testsuite/ext/random/hypergeometric_distribution/operators/values.cc is built with -O0, I get a crash: Program received signal SIGFPE, Arithmetic exception. 0x00401b07 in std::generate_canonical > (__urng=...) at /build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/random.tcc:3480 3480 return __sum / __tmp; (gdb) bt #0 0x00401b07 in std::generate_canonical > (__urng=...) at /build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/random.tcc:3480 #1 0x004018d9 in std::__detail::_Adaptor, unsigned int>::operator() (this=0x7fff9020) at /build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/random.h:190 #2 0x00401785 in __gnu_cxx::hypergeometric_distribution::operator() > ( this=0x7fffab40, __urng=..., __param=...) at /gcc-svn/libstdc++-v3/include/ext/random.tcc:1328 #3 0x004016fb in __gnu_cxx::hypergeometric_distribution::operator() > ( this=0x7fffab40, __urng=...) at /gcc-svn/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/ext/random:3016 #4 0x00401642 in std::_Bind<__gnu_cxx::hypergeometric_distribution (std::mersenne_twister_engine)>::__call(std::tuple<>&&, std::_Index_tuple<0ul>) (this=0x7fffab40, __args=) at /gcc-svn/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/functional:1264 #5 0x00401578 in std::_Bind<__gnu_cxx::hypergeometric_distribution (std::mersenne_twister_engine)>::operator()<, unsigned int>() (this=0x7fffab40) at /build/x86_64-unknown-linux-gnu/libstdc++-v3/include/functional:1323 #6 0x00400d4c in __gnu_test::testDiscreteDist<100ul, 10ul, std::_Bind<__gnu_cxx::hypergeometric_distribution<>(std::mersenne_twister_engine)>, test01():: >(std::_Bind<__gnu_cxx::hypergeometric_distribution(std::mersenne_twister_engine)> &, ) (f=..., pdf=...) at /gcc-svn/libstdc++-v3/testsuite/util/testsuite_random.h:50 #7 0x00400aa9 in test01 () at /gcc-svn/libstdc++-v3/testsuite/ext/random/hypergeometric_distribution/operators/values.cc:42 #8 0x00400b72 in main () at /gcc-svn/libstdc++-v3/testsuite/ext/random/hypergeometric_distribution/operators/values.cc:58 AFAICT, this is happening because: 3461 template 3463_RealType 3464generate_canonical(_UniformRandomNumberGenerator& __urng) 3465{ 3466 const size_t __b 3467= std::min(static_cast(std::numeric_limits<_RealType>::digits), 3468 __bits); 3469 const long double __r = static_cast(__urng.max()) 3470- static_cast(__urng.min()) + 1.0L; 3471 const size_t __log2r = std::log(__r) / std::log(2.0L); 3472 size_t __k = std::max(1UL, (__b + __log2r - 1UL) / __log2r); 3473 _RealType __sum = _RealType(0); 3474 _RealType __tmp = _RealType(1); 3475 for (; __k != 0; --__k) 3476{ 3477 __sum += _RealType(__urng() - __urng.min()) * __tmp; 3478 __tmp *= __r; 3479} 3480 return __sum / __tmp; 3481} 3482 3483_GLIBCXX_END_NAMESPACE_VERSION 3484} // namespace at line 3475, we have __r=4294967296, __tmp=1, __k=1. On line 3478, __tmp (which is unsigned int) overflows and becomes 0, and on line 3480 we divide by zero and get SIGFPE.
[Bug target/58854] [4.8 regression] "sub sp, fp, #40" hoisted above frame accesses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854 Alexa changed: What|Removed |Added CC||alexa.gerancho at hushmail dot com --- Comment #13 from Alexa --- *** Bug 260998 has been marked as a duplicate of this bug. *** Seen live from the domain http://volichat.com/adult-chat-rooms Marked for reference. Resolved as fixed @bugzilla.
[Bug c/60036] New: Spurious signedness conversion warning with relational operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60036 Bug ID: 60036 Summary: Spurious signedness conversion warning with relational operator Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: chengniansun at gmail dot com Gcc-trunk emits a signedness conversion warning for the statement "f ^= fn1() > a;". However, as the value of "fn1() > a" is either 1 or 0, the warning is not true. Moreover, Gcc-4.8 and 4.7 do not output this warning. And if I change the statement to "f = f ^ (fn1() > a);", gcc-trunk does not emit this warning, either. $: cat conversion-for-boolean.c extern int fn1(); unsigned fn(int a) { unsigned f = 9; f ^= fn1() > a; return f; } $: gcc-trunk -c -Wconversion -std=c11 conversion-for-boolean.c conversion-for-boolean.c: In function ‘fn’: conversion-for-boolean.c:4:5: warning: conversion to ‘unsigned int’ from ‘int’ may change the sign of the result [-Wsign-conversion] f ^= fn1() > a; ^ $: gcc-4.8 -c -Wconversion -std=c11 conversion-for-boolean.c $: gcc-4.7 -c -Wconversion -std=c11 conversion-for-boolean.c $: gcc-trunk --version gcc-trunk (GCC) 4.9.0 20140131 (experimental) Copyright (C) 2014 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 target/60034] "invalid expression as operand" in aarch64 inline asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60034 Andrew Pinski changed: What|Removed |Added Keywords||rejects-valid Host|x86_64-unknown-linux-gnu| Build|x86_64-unknown-linux-gnu| --- Comment #3 from Andrew Pinski --- Here is a reduced testcase: static unsigned long global_max_fast; int __libc_mallopt (int param_number, int value) { __asm__ __volatile__ ("# %[_SDT_A2]" :: [_SDT_A2] "nor" ((global_max_fast))); global_max_fast = 1; }
[Bug libgomp/60035] New: [PATCH] make it possible to use OMP on both sides of a fork (without violating standard)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60035 Bug ID: 60035 Summary: [PATCH] make it possible to use OMP on both sides of a fork (without violating standard) Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: njs at pobox dot com CC: jakub at gcc dot gnu.org Created attachment 32019 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32019&action=edit patch to make openmp -> quiesce -> fork -> openmp work This is a re-open of #52303 and #58378, with more arguments, and a proposed patch that fixes the problem without violating the openmp standard. Background: Almost all scientific/numerical code delegates linear algebra operations to some optimized BLAS library. Currently, the main contenders for this library are: 1) ATLAS: free software, but uses extensive build-time configuration, which means it must be re-compiled from source by every user to achieve competitive performance. 2) MKL: proprietary, but technically excellent. 3) OpenBLAS: free software, but uses OpenMP for threading, which means that any program which does linear algebra and also expects fork() to work is screwed [1], at least when using GCC. This means that for projects like numpy, which are used in a very large range of downstream products, we are pretty much screwed too. Many of our users use fork(), for various good reasons that I can elaborate if desired, so we can't just recommend OpenBLAS in general -- ATLAS or MKL are superior for . But recompiling ATLAS is difficult, so we can't recommend that as a general solution, or provide it in pre-compiled downloads. So what we end up doing is shipping slow, unoptimized BLAS, while all the major "scientific python" distros ship MKL; and we also get constantly pressured by users to either ship binaries with MKL or with OpenBLAS built with icc; and we field a new bug report every week or two from people who use OpenBLAS without realizing it and are experiencing mysterious hangs. (Or sometimes other projects get caught in the crossfire, e.g. [2] which is someone trying to figure out why their web-app can't generate plot graphics when using the celery job queue manager.) Meanwhile people are waiting with bated breath for clang to get an openmp implementation so that they can shift their whole stack over there, solely because of this one bug. Basically the current situation is causing ongoing pain for a wide range of people and makes free software uncompetitive with proprietary software for scientific code using Python in general. But it doesn't have to be this way! In actual practice on real implementations -- regardless of what POSIX says -- it's perfectly safe to use arbitrary POSIX APIs after fork, so long as all threads are in a known, quiescent state when the fork occurs. The attached patch has essentially no impact on compliant OpenMP-using programs; in particular, and unlike the patch in #58378, it has no affect on the behavior of the parent process, and in the child process it does nothing that violates POSIX unless the user has violated POSIX first. But it makes it safe in practice to use OpenMP encapsulated within a serial library API, without mysterious breakage depending on far away parts of the program, and in particular should fix the OpenBLAS issue. Test case included in patch is by Olivier Grisel, from #58378. Patch is against current gcc svn trunk (r206297). [1] https://github.com/xianyi/OpenBLAS/issues/294 [2] https://github.com/celery/celery/issues/1842
[Bug target/60034] "invalid expression as operand" in aarch64 inline asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60034 Kugan changed: What|Removed |Added CC||kuganv at linaro dot org --- Comment #2 from Kugan --- I am sorry that I entered wrong gcc -v (cut and paste error). It is an aarch64 issue and the correct gcc -v is below: aarch64-none-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/home/kugan/work/builds/gcc-fsf-trunk/tools/bin/aarch64-none-linux-gnu-gcc COLLECT_LTO_WRAPPER=/home/kugan/work/builds/gcc-fsf-trunk/tools/libexec/gcc/aarch64-none-linux-gnu/4.9.0/lto-wrapper Target: aarch64-none-linux-gnu Configured with: /home/kugan/work/sources/gcc-fsf/trunk/configure --target=aarch64-none-linux-gnu --prefix=/home/kugan/work/builds/gcc-fsf-trunk/tools --without-headers --with-newlib --disable-shared --disable-threads --disable-libssp --disable-libgomp --disable-libmudflap --disable-libatomic --without-libquadmath --disable-libquadmath --enable-languages=c Thread model: single gcc version 4.9.0 20130922 (experimental) (GCC)
[Bug c++/43407] Specifying visibility attribute of C++0x enum class emits warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43407 Jobst.Ziebell at mailbox dot tu-dresden.de changed: What|Removed |Added CC||Jobst.Ziebell at mailbox dot tu-dr ||esden.de --- Comment #2 from Jobst.Ziebell at mailbox dot tu-dresden.de --- This bug is still present as of 4.8.2... (on x86_64-apple-darwin13.0.0)
[Bug target/60034] New: "invalid expression as operand" in aarch64 inline asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60034 Bug ID: 60034 Summary: "invalid expression as operand" in aarch64 inline asm Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: kuganv at linaro dot org Created attachment 32017 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32017&action=edit pre processed source This issue is originally reported in https://bugs.launchpad.net/gcc-linaro/+bug/1270789 The attached pre-processed source fails with: # aarch64-linux-gnu-gcc -std=gnu99 -fgnu89-inline -O -Wall -Winline -Wwrite-strings -fmerge-all-constants -frounding-math -g -Wstrict-prototypes malloc.i malloc.c: In function ‘__libc_mallopt’: malloc.c:4761:16: error: invalid 'asm': invalid expression as operand Splitting this inline asm out into a smaller testcase does not seem to reproduce the issue. It's possible this is a bug in the source file, but it's not clear from gcc's output what the problem is. Seems to be an issue with alignment calculation in aarch64_classify_address. for rtl of the form (lo_sum:DI (reg/f:DI 132) (symbol_ref:DI ("*.LANCHOR4") [flags 0x182])) we are currently calculating align of 8bits and due to this the following statement returns false. This causes output_addr_const (in gcc/final.c) to fail. return ((INTVAL (offs) & (ref_size - 1)) == 0 && ((align / BITS_PER_UNIT) & (ref_size - 1)) == 0); AFIK, align of 8bits is not correct here. GCC version and config: arm-none-linux-gnueabi-gcc -v Using built-in specs. COLLECT_GCC=/home/kugan/work/builds/gcc-fsf-trunk/tools/bin/arm-none-linux-gnueabi-gcc COLLECT_LTO_WRAPPER=/home/kugan/work/builds/gcc-fsf-trunk/tools/libexec/gcc/arm-none-linux-gnueabi/4.9.0/lto-wrapper Target: arm-none-linux-gnueabi Configured with: /home/kugan/work/sources/gcc-fsf/trunk/configure --target=arm-none-linux-gnueabi --prefix=/home/kugan/work/builds/gcc-fsf-trunk/tools --with-sysroot=/home/kugan/work/builds/gcc-fsf-trunk/sysroot-arm-none-linux-gnueabi --disable-libssp --disable-libgomp --disable-libmudflap --enable-languages=c,c++ --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=softfp --with-thumb Thread model: posix gcc version 4.9.0 20130922 (experimental) (GCC)
[Bug target/60034] "invalid expression as operand" in aarch64 inline asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60034 --- Comment #1 from Kugan --- Created attachment 32018 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32018&action=edit Proposed patch
[Bug fortran/57019] [4.7/4.8/4.9 Regression] Compiler crashes (and make wrong assignments) at some combinations of pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57019 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #6 from Paul Thomas --- I have spent an hour or so looking at this one. I think that I can see how to fix it. The problem is that expr.c(is_subref_array) is triggering the use of pointer arithmetic, using the hidden .span variable, when it should not. The expressions below work fine with array indices. I just have to sit down and figure out a consistent logic. Something for next weekend! Cheers Paul
[Bug c++/37140] type inherited from base class not recognized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37140 fabien at gcc dot gnu.org changed: What|Removed |Added CC||roshan.shariff at gmail dot com --- Comment #14 from fabien at gcc dot gnu.org --- *** Bug 58047 has been marked as a duplicate of this bug. ***
[Bug c++/58047] parse error with typedef introduced from base class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58047 fabien at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from fabien at gcc dot gnu.org --- marked as duplicate *** This bug has been marked as a duplicate of bug 37140 ***
[Bug c++/37140] type inherited from base class not recognized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37140 fabien at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from fabien at gcc dot gnu.org --- Fixed in 4.9. I will backport it to 4.8 and 4.7 if everething goes well.
[Bug c++/37140] type inherited from base class not recognized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37140 --- Comment #12 from fabien at gcc dot gnu.org --- Author: fabien Date: Sun Feb 2 20:02:37 2014 New Revision: 207408 URL: http://gcc.gnu.org/viewcvs?rev=207408&root=gcc&view=rev Log: 2014-02-02 Fabien Chene PR c++/37140 * parser.c (cp_parser_nonclass_name): Call strip_using_decl and move the code handling dependent USING_DECLs... * name-lookup.c (strip_using_decl): ...Here. 2014-02-02 Fabien Chene PR c++/37140 * g++.dg/template/using27.C: New. * g++.dg/template/using28.C: New. * g++.dg/template/using29.C: New. Added: trunk/gcc/testsuite/g++.dg/template/using27.C trunk/gcc/testsuite/g++.dg/template/using28.C trunk/gcc/testsuite/g++.dg/template/using29.C Modified: trunk/gcc/cp/parser.c
[Bug c++/37140] type inherited from base class not recognized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37140 --- Comment #11 from fabien at gcc dot gnu.org --- Author: fabien Date: Sun Feb 2 19:58:06 2014 New Revision: 207407 URL: http://gcc.gnu.org/viewcvs?rev=207407&root=gcc&view=rev Log: 2014-02-02 Fabien Chene PR c++/37140 * parser.c (cp_parser_nonclass_name): Call strip_using_decl and move the code handling dependent USING_DECLs... * name-lookup.c (strip_using_decl): ...Here. 2014-02-02 Fabien Chene PR c++/37140 * g++.dg/template/using27.C: New. * g++.dg/template/using28.C: New. * g++.dg/template/using29.C: New. Modified: trunk/gcc/cp/name-lookup.c
[Bug c++/60033] gcc 4.9.0 20140107: ICE in retrieve_specialization while compiling recursive generic lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60033 --- Comment #1 from Richard Vock --- I know I left a redundant composer c; line in there. Just ignore that...
[Bug c++/60033] New: gcc 4.9.0 20140107: ICE in retrieve_specialization while compiling recursive generic lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60033 Bug ID: 60033 Summary: gcc 4.9.0 20140107: ICE in retrieve_specialization while compiling recursive generic lambda Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: vock at cs dot uni-bonn.de Created attachment 32016 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32016&action=edit Preprocessed output file I got an ICE while compiling the following minimal code example (.ii is attached): //#include #include template struct composer; template struct composer { auto operator()(Func&& f) { return f; } }; template struct composer { auto operator()(Func&& f, Funcs&&... fs) { composer c; return [&] (auto v) { return f(composer()(std::forward(fs)...)(v)); }; } }; template auto compose(Funcs&&... fs) { return composer()(std::forward(fs)...); } int main (int argc, char const* argv[]) { float v = 3.5f; auto func = [] (auto v) { return int(v-0.5); }; auto t = compose([] (auto v) { return v >= 3; }, func)(v); //std::cout << std::boolalpha << t << "\n"; auto f = compose([] (auto v) { return v > 3; }, func)(v); //std::cout << std::boolalpha << f << "\n"; } Compiler output is: > g++-4.9 -std=c++1y -save-temps -Wall -Wextra -fno-strict-aliasing -fwrapv > -fno-aggressive-loop-optimizations main.cpp main.cpp: In instantiation of ‘composer::operator()(Func&&, Funcs&& ...):: [with auto:2 = float; Func = main(int, const char**)::; Funcs = {main(int, const char**)::}]’: main.cpp:33:88: required from here main.cpp:19:41: internal compiler error: in retrieve_specialization, at cp/pt.c:1042 return f(c(std::forward(fs)...)(v)); ^ 0x59c47f retrieve_specialization ./src/gcc/gcc/cp/pt.c:1039 0x5a470c tsubst_pack_expansion ./src/gcc/gcc/cp/pt.c:9563 0x59f404 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ./src/gcc/gcc/cp/pt.c:14461 0x59fa18 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ./src/gcc/gcc/cp/pt.c:14443 0x59f3a0 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ./src/gcc/gcc/cp/pt.c:14456 0x5a31ce tsubst_expr ./src/gcc/gcc/cp/pt.c:13788 0x5a31a4 tsubst_expr ./src/gcc/gcc/cp/pt.c:13205 0x5a316f tsubst_expr ./src/gcc/gcc/cp/pt.c:13400 0x5a2e34 tsubst_expr ./src/gcc/gcc/cp/pt.c:13195 0x5a316f tsubst_expr ./src/gcc/gcc/cp/pt.c:13400 0x5a2038 instantiate_decl(tree_node*, int, bool) ./src/gcc/gcc/cp/pt.c:19656 0x5cfbb9 mark_used(tree_node*, int) ./src/gcc/gcc/cp/decl2.c:4701 0x57760b build_over_call ./src/gcc/gcc/cp/call.c:7127 0x57a301 build_op_call_1 ./src/gcc/gcc/cp/call.c:4161 0x57a301 build_op_call(tree_node*, vec**, int) ./src/gcc/gcc/cp/call.c:4184 0x636cf8 finish_call_expr(tree_node*, vec**, bool, bool, int) ./src/gcc/gcc/cp/semantics.c:2298 0x5ec24b cp_parser_postfix_expression ./src/gcc/gcc/cp/parser.c:6165 0x5ee8b8 cp_parser_unary_expression ./src/gcc/gcc/cp/parser.c:7171 0x5ef48f cp_parser_binary_expression ./src/gcc/gcc/cp/parser.c:7875 0x5ef951 cp_parser_assignment_expression ./src/gcc/gcc/cp/parser.c:8113 A running version compiled using clang++ 3.5 is here: http://coliru.stacked-crooked.com/a/acc691b9a407d6f2 System: Arch Linux Linux xxx 3.12.6-1-ARCH #1 SMP PREEMPT Fri Dec 20 19:39:00 CET 2013 x86_64 GNU/Linux Build Command: g++-4.9 -std=c++1y -save-temps -Wall -Wextra -fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations main.cpp Version: Using built-in specs. COLLECT_GCC=g++-4.9 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ./src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share/gcc-4.9 --with-bugurl='http://aur.archlinux.org/packages.php?ID=16045' --enable-languages=c,c++,lto --enable-shared --enable-threads=posix --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --enable-gnu-unique-object --enable-linker-build-id --enable-cloog-backend=isl --disable-cloog-version-check --enable-lto --enable-gold --enable-ld=default --enable-plugin --with-plugin-ld=ld.gold --with-linker-hash-style=gnu --disable-install-libiberty --disable-multilib --disable-libssp --disable-werror --enable-checking=release --program-suffix=-4.9 --enable-version-specific-runtime-libs Thread model: posix gcc version 4.9.0 20140107 (experimental) (GCC)
[Bug middle-end/60013] [4.9 Regression] Build of 176.gcc from CPU2000 loops in cc1 starting with r207231
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60013 --- Comment #11 from H.J. Lu --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00035.html
[Bug target/60032] [4.9 regression] ICE in reload_cse_simplify_operands, at postreload.c:411
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60032 Andreas Schwab changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug target/60032] New: [4.9 regression] ICE in reload_cse_simplify_operands, at postreload.c:411
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60032 Bug ID: 60032 Summary: [4.9 regression] ICE in reload_cse_simplify_operands, at postreload.c:411 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sch...@linux-m68k.org Target: powerpc-*-* $ ./gcc/xg++ -shared-libgcc -B./gcc -nostdinc++ -Lpowerpc64-linux/32/libstdc++-v3/src -Lpowerpc64-linux/32/libstdc++-v3/src/.libs -Lpowerpc64-linux/32/libstdc++-v3/libsupc++/.libs -B/usr/powerpc64-linux/bin/ -B/usr/powerpc64-linux/lib/ -isystem /usr/powerpc64-linux/include -isystem /usr/powerpc64-linux/sys-include -m32 -BBuild/powerpc64-linux/32/libstdc++-v3/src/.libs -fdiagnostics-color=never -D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -O2 -g -D_GNU_SOURCE -O2 -g -D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++ -Ipowerpc64-linux/32/libstdc++-v3/include/powerpc64-linux -Ipowerpc64-linux/32/libstdc++-v3/include -I../libstdc++-v3/libsupc++ -I../libstdc++-v3/include/backward -I../libstdc++-v3/testsuite/util ../libstdc++-v3/testsuite/decimal/pr54036-1.cc -include bits/stdc++.h powerpc64-linux/libstdc++-v3/testsuite/libtestc++.a -Wl,--gc-sections -lm -m32 -o ./pr54036-1.exe ../libstdc++-v3/testsuite/decimal/pr54036-1.cc: In function ‘int main()’: ../libstdc++-v3/testsuite/decimal/pr54036-1.cc:71:1: error: insn does not satisfy its constraints: } ^ (insn 274 273 172 14 (set (reg:DD 31 31) (mem/c:DD (plus:SI (reg/f:SI 1 1) (const_int 32 [0x20])) [0 S8 A64])) powerpc64-linux/32/libstdc++-v3/include/decimal/decimal.h:298 445 {*movdd_hardfloat32} (nil)) ../libstdc++-v3/testsuite/decimal/pr54036-1.cc:71:1: internal compiler error: in reload_cse_simplify_operands, at postreload.c:411 0x1061c50b _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) ../../gcc/rtl-error.c:109 0x1061c55f _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) ../../gcc/rtl-error.c:120 0x105c7e23 reload_cse_simplify_operands ../../gcc/postreload.c:411 0x105c9f53 reload_cse_simplify ../../gcc/postreload.c:181 0x105c9f53 reload_cse_regs_1 ../../gcc/postreload.c:220 0x105ca537 reload_cse_regs ../../gcc/postreload.c:68 0x105ca537 rest_of_handle_postreload ../../gcc/postreload.c:2332 0x105ca537 execute ../../gcc/postreload.c:2368
[Bug middle-end/60013] [4.9 Regression] Build of 176.gcc from CPU2000 loops in cc1 starting with r207231
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60013 H.J. Lu changed: What|Removed |Added Attachment #32014|0 |1 is obsolete|| --- Comment #10 from H.J. Lu --- Created attachment 32015 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32015&action=edit An updated patch
[Bug testsuite/60031] dg-require-effective-target powerpc_vsx_ok is not enough
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60031 Andreas Schwab changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug testsuite/60031] New: dg-require-effective-target powerpc_vsx_ok is not enough
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60031 Bug ID: 60031 Summary: dg-require-effective-target powerpc_vsx_ok is not enough Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: sch...@linux-m68k.org Target: powerpc*-*-* Runtime tests cannot use dg-require-effective-target powerpc_vsx_ok alone since check_effective_target_powerpc_vsx_ok only checks whether -mvsx works, but not whether the target can execute VSX insns.
[Bug target/60017] [4.7/4.8/4.9 Regression] Struct not returned correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60017 --- Comment #4 from uros at gcc dot gnu.org --- Author: uros Date: Sun Feb 2 15:35:53 2014 New Revision: 207399 URL: http://gcc.gnu.org/viewcvs?rev=207399&root=gcc&view=rev Log: PR target/60017 * config/i386/i386.c (classify_argument): Fix handling of bit_offset when calculating size of integer atomic types. testsuite/ChangeLog: PR target/60017 * gcc.c-torture/execute/pr60017.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr60017.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug target/60017] [4.7/4.8/4.9 Regression] Struct not returned correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60017 Uroš Bizjak changed: What|Removed |Added CC|uros at gcc dot gnu.org| --- Comment #3 from Uroš Bizjak --- Patch at [1]. [1] http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00027.html
[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469 --- Comment #38 from Markus Trippelsdorf --- So maybe the following patch is enough: diff --git a/gcc/lto/lto-symtab.c b/gcc/lto/lto-symtab.c index f5f9d1318ee0..bdb536131707 100644 --- a/gcc/lto/lto-symtab.c +++ b/gcc/lto/lto-symtab.c @@ -57,7 +57,7 @@ lto_cgraph_replace_node (struct cgraph_node *node, } /* Merge node flags. */ - if (node->force_output) + if (node->force_output || node->forced_by_abi) cgraph_mark_force_output_node (prevailing_node); if (node->address_taken) {
[Bug rtl-optimization/60030] New: [4.9 regression] ICE in simplify_subreg, at simplify-rtx.c:5903
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60030 Bug ID: 60030 Summary: [4.9 regression] ICE in simplify_subreg, at simplify-rtx.c:5903 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: sch...@linux-m68k.org Target: powerpc-*-* $ gcc/xgcc -Bgcc/ ../gcc/testsuite/c-c++-common/ubsan/overflow-1.c -Bpowerpc64-linux/32/libsanitizer/ -Bpowerpc64-linux/32/libsanitizer/ubsan/ -Lpowerpc64-linux/32/libsanitizer/ubsan/.libs -fno-diagnostics-show-caret -fdiagnostics-color=never -O0 -fsanitize=signed-integer-overflow -lm -m32 -o ./overflow-1.exe../gcc/testsuite/c-c++-common/ubsan/overflow-1.c: In function ‘main’: ../gcc/testsuite/c-c++-common/ubsan/overflow-1.c:81:40: internal compiler error: in simplify_subreg, at simplify-rtx.c:5903 ../gcc/testsuite/c-c++-common/ubsan/overflow-1.c:12:29: note: in definition of macro ‘CHECK’ ../gcc/testsuite/c-c++-common/ubsan/overflow-1.c:81:10: note: in expansion of macro ‘FN1’ 0x1054b22b simplify_subreg(machine_mode, rtx_def*, machine_mode, unsigned int) ../../gcc/simplify-rtx.c:5902 0x1054b4df simplify_gen_subreg(machine_mode, rtx_def*, machine_mode, unsigned int) ../../gcc/simplify-rtx.c:6123 0x102b9abf operand_subword(rtx_def*, unsigned int, int, machine_mode) ../../gcc/emit-rtl.c:1442 0x102b9cbf operand_subword_force(rtx_def*, unsigned int, machine_mode) ../../gcc/emit-rtl.c:1455 0x1048412b expand_binop(machine_mode, optab_tag, rtx_def*, rtx_def*, rtx_def*, int, optab_methods) ../../gcc/optabs.c:1813 0x102cf023 expand_shift_1 ../../gcc/expmed.c:2287 0x103a5b2f ubsan_expand_si_overflow_mul_check(gimple_statement_base*) ../../gcc/internal-fn.c:649 0x103a659b expand_internal_call(gimple_statement_base*) ../../gcc/internal-fn.c:883 0x101f2667 expand_call_stmt ../../gcc/cfgexpand.c:2188 0x101f2667 expand_gimple_stmt_1 ../../gcc/cfgexpand.c:3157 0x101f2667 expand_gimple_stmt ../../gcc/cfgexpand.c:3309 0x101f351f expand_gimple_basic_block ../../gcc/cfgexpand.c:5149 0x101f58ab gimple_expand_cfg ../../gcc/cfgexpand.c:5715 0x101f58ab execute ../../gcc/cfgexpand.c:5935
[Bug rtl-optimization/60030] [4.9 regression] ICE in simplify_subreg, at simplify-rtx.c:5903
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60030 Andreas Schwab changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug target/60029] [4.9 regression] FAIL: c-c++-common/dfp/convert-bfp.c -std=c++11 execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60029 Andreas Schwab changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug target/60029] New: [4.9 regression] FAIL: c-c++-common/dfp/convert-bfp.c -std=c++11 execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60029 Bug ID: 60029 Summary: [4.9 regression] FAIL: c-c++-common/dfp/convert-bfp.c -std=c++11 execution test Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sch...@linux-m68k.org Target: powerpc-*-* $ gcc/xg++ -Bgcc/ ../gcc/testsuite/c-c++-common/dfp/convert-bfp.c -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++ -Ipowerpc64-linux/32/libstdc++-v3/include/powerpc64-linux -Ipowerpc64-linux/32/libstdc++-v3/include -I../libstdc++-v3/libsupc++ -I../libstdc++-v3/include/backward -I../libstdc++-v3/testsuite/util -fmessage-length=0 -std=c++11 -Lpowerpc64-linux/32/libstdc++-v3/src/.libs -Bpowerpc64-linux/32/libstdc++-v3/src/.libs -Lpowerpc64-linux/32/libstdc++-v3/src/.libs -lm -m32 -o ./convert-bfp.exe $ LD_LIBRARY_PATH=.:powerpc64-linux/32/libstdc++-v3/src/.libs:powerpc64-linux/32/libstdc++-v3/src/.libs:gcc:gcc/32:.:powerpc64-linux/32/libstdc++-v3/src/.libs:powerpc64-linux/32/libstdc++-v3/src/.libs:gcc:gcc/32:powerpc64-linux/libstdc++-v3/src/.libs:powerpc64-linux/libsanitizer/.libs:powerpc64-linux/libssp/.libs:powerpc64-linux/libgomp/.libs:powerpc64-linux/libitm/.libs:powerpc64-linux/libatomic/.libs:./gcc:./prev-gcc ./convert-bfp.exe Segmentation fault >From convert-bfp.c.214r.reload: (insn 666 665 316 30 (set (reg:DD 8 8) (mem/c:DD (plus:SI (reg/f:SI 31 31) (const_int 24 [0x18])) [0 S8 A64])) gcc/testsuite/c-c++-common/dfp/convert-bfp.c:85 445 {*movdd_hardfloat32} (nil)) (insn 316 666 317 30 (set (mem/v/c:SD (lo_sum:SI (reg:SI 9 9 [346]) (symbol_ref:SI ("d32") [flags 0x6] )) [0 d32+0 S4 A32]) (reg:SD 8 8)) gcc/testsuite/c-c++-common/dfp/convert-bfp.c:85 441 {movsd_hardfloat} (nil)) With -m32 insn 666 is split into two insns that clobber both register 8 and 9. (insn 754 665 755 (set (reg:SI 8 8) (mem/c:SI (plus:SI (reg/f:SI 31 31) (const_int 24 [0x18])) [0 S4 A64])) gcc/testsuite/c-c++-common/dfp/convert-bfp.c:85 434 {*movsi_internal1} (nil)) (insn 755 754 316 (set (reg:SI 9 9 [orig:8+4 ] [8]) (mem/c:SI (plus:SI (reg/f:SI 31 31) (const_int 28 [0x1c])) [0 S4 A32])) gcc/testsuite/c-c++-common/dfp/convert-bfp.c:85 434 {*movsi_internal1} (nil))
[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469 --- Comment #37 from Markus Trippelsdorf --- I think the error is that the symbol from the explicit template instantiation in Function.ii (marked with forced_by_abi) gets merged with the symbol in the same COMDAT group from BasicBlock.ii. (This symbol isn't marked with forced_by_abi, but somehow has prevailing_def_ironly_exp) Merging nodes for _ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE21transferNodesFromListERNS_12ilist_traitsIS1_EENS_14ilist_iteratorIS1_EES8_. Candidates: _ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE21transferNodesFromListERNS_12ilist_traitsIS1_EENS_14ilist_iteratorIS1_EES8_/9 (transferNodesFromList) @0x7f4d65008e18 Type: function definition analyzed Visibility: externally_visible prevailing_def_ironly_exp public weak comdat comdat_group:_ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE21transferNodesFromLi stERNS_12ilist_traitsIS1_EENS_14ilist_iteratorIS1_EES8_ one_only next sharing asm name: 22 References: Referring: Read from file: /tmp/ccx3oVJ3.o First run: 0 Function flags: Called by: _ZN4llvm10BasicBlock10moveBeforeEv/1 (1.00 per call) (can throw external) _ZN4llvm10BasicBlock10moveBeforeEv/1 (1.00 per call) (can throw external) Calls: _ZN4llvm14ilist_iteratorINS_10BasicBlockEEneERS2_/16 (11.11 per call) (can throw external) _ZN4llvm14ilist_iteratorINS_10BasicBlockEEppEv/15 (10.11 per call) (can throw external) _ZN4llvm12ilist_traitsINS_10BasicBlockEE9getSymTabEPNS_8FunctionE/14 (1.00 per call) (can throw external) _ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8Fu nctionEE12getListOwnerEv/13 (1.00 per call) (can throw external) _ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE12getListOwnerEv/13 (1.00 per call) (can throw external) _ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE21transferNodesFromListERNS_12ilist_traitsIS1_EENS_14ilist_iteratorIS1_EES8_/22 (transferNodesFromList) @0x7f4d651888f8 Type: function definition analyzed Visibility: forced_by_abi externally_visible preempted_ir public weak comdat_group:_ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE21transferNodesFromListERNS _12ilist_traitsIS1_EENS_14ilist_iteratorIS1_EES8_ one_only previous sharing asm name: 9 References: Referring: Read from file: /tmp/ccZVoWfZ.o First run: 0 Function flags: Called by: Calls:
[Bug middle-end/60013] [4.9 Regression] Build of 176.gcc from CPU2000 loops in cc1 starting with r207231
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60013 --- Comment #9 from H.J. Lu --- Created attachment 32014 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32014&action=edit A patch I am testing this patch.
[Bug target/60017] [4.7/4.8/4.9 Regression] Struct not returned correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60017 Uroš Bizjak changed: What|Removed |Added Target|x86_64-*-darwin*|x86_64 Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com --- Comment #2 from Uroš Bizjak --- I have a patch.
[Bug target/51518] ICE: in expand_call, at calls.c:3421 with -mno-accumulate-outgoing-args and __attribute__ ((ms_abi)) (after sorry)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51518 David Binderman changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #2 from David Binderman --- (In reply to Marek Polacek from comment #1) > Confirmed. Trunk dated 20140201 seems to also have this problem.
[Bug fortran/57033] [4.7/4.8/4.9 Regression] ICE on extended derived type and default initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57033 --- Comment #5 from Mikael Morin --- Author: mikael Date: Sun Feb 2 11:50:28 2014 New Revision: 207396 URL: http://gcc.gnu.org/viewcvs?rev=207396&root=gcc&view=rev Log: fortran/ PR fortran/57033 * primary.c (gfc_convert_to_structure_constructor): Avoid null pointer dereference. testsuite/ PR fortran/57033 * gfortran.dg/default_initialization_7.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/default_initialization_7.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/primary.c trunk/gcc/testsuite/ChangeLog
[Bug target/60028] New: TIC6X: B3 register (return address) is saved on stack when real call is replaced with sibling call in a leaf function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60028 Bug ID: 60028 Summary: TIC6X: B3 register (return address) is saved on stack when real call is replaced with sibling call in a leaf function Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: wojtek.golf at interia dot pl GCC 4.8.2, target tic6x Input source: int e_fun(int arg); extern int e_int; void g_fun(void) { e_fun(e_int); } compiled with a command: -fleading-underscore -march=c674x -O2 -g0 -S main.c gives the following assembler code: _g_fun: sub .d2 B15, 8, B15 stw .d2t2 B3, *+B15(8) b .s1 (_e_fun) || ldw .d2t1 *+B14(_e_int), A4 ldw .d2t2 *+B15(8), B3 || add .s2 8, B15, B15 ;; sibcall to (_e_fun) occurs nop 4 where B3 is saved on the stack even though a branch is taken to _e_fun. Texas Instruments CGTools compiler v7.3.2 (cl6x --gcc -mv6740 --symdebug:none -k -n main.c) gives the following assembler code (CALLRET is an alias to B): _g_fun: CALLRET .S1 _e_fun; |6| LDW .D2T1 *+DP(_e_int),A4 ; |6| NOP 4 $C$RL0:; CALL-RETURN OCCURS {_e_fun} 0 ; |6| where B3 is not saved. Some investigation on my part leads to the function c6x_expand_call in the file gcc/gcc/config/c6x/c6x.c, where we see what may cause B3 being marked as used and hence saved on the stack prior to the branch: if (sibcall) { call_insn = emit_call_insn (call_insn); use_reg (&CALL_INSN_FUNCTION_USAGE (call_insn), gen_rtx_REG (Pmode, REG_B3)); } commenting out use_reg invocation makes gcc to generate the expected listing: _g_fun: b .s1 (_e_fun) || ldw .d2t1 *+B14(_e_int), A4 ;; sibcall to (_e_fun) occurs nop 5 I haven't tested yet whether removal of use_reg invocation causes any regression, but I'd like it to be investigated whether it should be removed altogether or protected with some extra execution condition. With best, Wojciech
[Bug c++/60027] New: Problem with braced-init-lists and explicit ctors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60027 Bug ID: 60027 Summary: Problem with braced-init-lists and explicit ctors Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: joaquin at tid dot es The following code compiled with -std=c++11: struct foo { foo(int){} }; struct bar { explicit bar(int){} }; void f(foo){} void f(bar){} int main() { f({0}); } yields: main.cpp:16:8: error: call of overloaded 'f()' is ambiguous f({0}); ^ main.cpp:16:8: note: candidates are: main.cpp:11:6: note: void f(foo) void f(foo){} ^ main.cpp:12:6: note: void f(bar) void f(bar){} ^ which seems incorrect as bar::bar(int) is explicit. Joaquín M López Muñoz Telefónica Digital