[Bug tree-optimization/58627] [4.9 Regression] crash during compilation of boost testsuite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58627 --- Comment #1 from Markus Trippelsdorf --- Created attachment 30957 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30957&action=edit testcase
[Bug tree-optimization/58627] New: [4.9 Regression] crash during compilation of boost testsuite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58627 Bug ID: 58627 Summary: [4.9 Regression] crash during compilation of boost testsuite Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: markus at trippelsdorf dot de Crash happened during compilation of the boost testsuite. It's hard to reduce the testcase, because it appears to be a bug in the garbage-collector. [With --enable-checking=release] % g++ -O0 -std=c++11 -c test.ii test.ii: In member function ‘boost::chrono::duration& boost::chrono::duration::operator--() [with Rep = double; Period = boost::ratio<1l>]’: test.ii:3207:286: internal compiler error: Segmentation fault [gcc-4.8.1 is fine] % /usr/x86_64-pc-linux-gnu/gcc-bin/4.8.1/g++ -O2 -std=c++11 -c test.i % [Backtrace with --enable-checking] % gdb --args /var/tmp/gcc_test/usr/local/bin/g++ -w -O0 -std=c++11 -Wfatal-errors -c test.ii -pipe -o /dev/null Reading symbols from /var/tmp/gcc_test/usr/local/bin/g++...done. (gdb) run Starting program: /var/tmp/gcc_test/usr/local/bin/g++ -w -O0 -std=c++11 -Wfatal-errors -c test.ii -pipe -o /dev/null [New process 20470] process 20470 is executing new program: /var/tmp/gcc_test/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/cc1plus Program received signal SIGSEGV, Segmentation fault. [Switching to process 20470] 0x00c8e9f8 in tree_class_check_failed (node=, cl=, file=0xff512d "../../gcc/gcc/c-family/c-common.h", line=1063, function=0xff514f "c_tree_chain_next") at ../../gcc/gcc/tree.c:9223 9223../../gcc/gcc/tree.c: No such file or directory. (gdb) bt #0 0x00c8e9f8 in tree_class_check_failed (node=, cl=, file=0xff512d "../../gcc/gcc/c-family/c-common.h", line=1063, function=0xff514f "c_tree_chain_next") at ../../gcc/gcc/tree.c:9223 #1 0x006807f1 in tree_class_check (__class=, __f=, __l=, __g=, __t=, __class=, __f=, __l=, __g=) at ../../gcc/gcc/tree.h:2732 #2 c_tree_chain_next (t=) at ../../gcc/gcc/c-family/c-common.h:1063 #3 gt_ggc_mx_lang_tree_node (x_p=) at ./gt-cp-tree.h:158 #4 0x0067f79a in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-cp-tree.h:706 #5 0x00680ba3 in gt_ggc_mx_tinst_level (x_p=) at ./gt-cp-tree.h:124 #6 0x0057b363 in gt_ggc_mx_pending_template (x_p=) at ./gt-cp-pt.h:44 #7 0x008dfa6b in ggc_mark_root_tab (rt=) at ../../gcc/gcc/ggc-common.c:133 #8 ggc_mark_roots () at ../../gcc/gcc/ggc-common.c:152 #9 0x0072d91b in ggc_collect () at ../../gcc/gcc/ggc-page.c:2077 #10 0x0079f9c3 in cgraph_finalize_function (decl=, no_collect=) at ../../gcc/gcc/cgraphunit.c:456 #11 0x0065c3fc in expand_or_defer_fn (fn=0x7fffeeb57500) at ../../gcc/gcc/cp/semantics.c:3949 #12 0x00574935 in instantiate_decl (d=0x7fffeeb57500, defer_ok=, expl_inst_class_mem_p=) at ../../gcc/gcc/cp/pt.c:19406 #13 0x00577738 in instantiate_pending_templates (retries=) at ../../gcc/gcc/cp/pt.c:19493 #14 0x005b9454 in cp_write_global_declarations () at ../../gcc/gcc/cp/decl2.c:4065 #15 0x00aa2196 in compile_file () at ../../gcc/gcc/toplev.c:560 #16 0x00aa1f67 in do_compile () at ../../gcc/gcc/toplev.c:1893 #17 toplev_main (argc=16, argv=0x7fffe028) at ../../gcc/gcc/toplev.c:1969 #18 0x774d3a6e in __libc_start_main () from /lib/libc.so.6 #19 0x004e090d in _start ()
[Bug libstdc++/58625] std::signbit always converts to double
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58625
--- Comment #4 from Oleg Endo ---
(In reply to Paolo Carlini from comment #1)
> Weird that nobody noticed for so much time.
Probably not everybody is practicing the neurotic habit of checking the asm
output for every bit and piece ;)
(In reply to Paolo Carlini from comment #2)
> Well, now I see this can be certainly a correctness issue, for eg very small
> negative long doubles. Thus I think we should certainly do the change anyway
> for 4.9. For c_std I'm afraid we have to add overloads (I think, essentially
> copy over the corresponding bits of c_global without constexpr). Can you
> send a patch to the libstdc++-v3 mailing list? And, please, double check
> isnan and isinf. Thanks!
Yes, I can do that. But how to check this in a target independent way? Tree
dump and check whether the correct builtin names appear?
There's another place in file libstdc++-v3/include/c_std/cmath:
template
inline typename __gnu_cxx::__enable_if<__is_arithmetic<_Tp>::__value,
int>::__type
signbit(_Tp __f)
{
typedef typename __gnu_cxx::__promote<_Tp>::__type __type;
return __builtin_signbit(__type(__f));
}
I guess that this is supposed to be used when C++ code pulls in and
uses the C macro signbit instead of std::signbit. It doesn't happen on my SH /
newlib cross config -- I get something like ((sizeof(x) == sizeof(float)) ?
__signbitf(x) : __signbitd(x)). But if on some config it does happen, then the
problem would be the same, thus requiring signbit (and friends) overloads as
it's done for sqrt etc in the same file, right?
[Bug libstdc++/58625] std::signbit always converts to double
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58625
--- Comment #5 from Jakub Jelinek ---
Some builtins are type generic, meaning that you can use just the non-{l,f}
suffixed variant always, but __builtin_signbit isn't among them.
Grep shows that these builtins have "type generic" attribute:
DEF_GCC_BUILTIN(BUILT_IN_FPCLASSIFY, "fpclassify",
BT_FN_INT_INT_INT_INT_INT_INT_VAR, ATTR_CONST_NOTHROW_TYPEGENERIC_LEAF)
DEF_GCC_BUILTIN(BUILT_IN_ISFINITE, "isfinite", BT_FN_INT_VAR,
ATTR_CONST_NOTHROW_TYPEGENERIC_LEAF)
DEF_GCC_BUILTIN(BUILT_IN_ISINF_SIGN, "isinf_sign", BT_FN_INT_VAR,
ATTR_CONST_NOTHROW_TYPEGENERIC_LEAF)
DEF_C99_C90RES_BUILTIN (BUILT_IN_ISINF, "isinf", BT_FN_INT_VAR,
ATTR_CONST_NOTHROW_TYPEGENERIC)
DEF_C99_C90RES_BUILTIN (BUILT_IN_ISNAN, "isnan", BT_FN_INT_VAR,
ATTR_CONST_NOTHROW_TYPEGENERIC_LEAF)
DEF_GCC_BUILTIN(BUILT_IN_ISNORMAL, "isnormal", BT_FN_INT_VAR,
ATTR_CONST_NOTHROW_TYPEGENERIC_LEAF)
DEF_GCC_BUILTIN(BUILT_IN_ISGREATER, "isgreater", BT_FN_INT_VAR,
ATTR_CONST_NOTHROW_TYPEGENERIC_LEAF)
DEF_GCC_BUILTIN(BUILT_IN_ISGREATEREQUAL, "isgreaterequal",
BT_FN_INT_VAR, ATTR_CONST_NOTHROW_TYPEGENERIC_LEAF)
DEF_GCC_BUILTIN(BUILT_IN_ISLESS, "isless", BT_FN_INT_VAR,
ATTR_CONST_NOTHROW_TYPEGENERIC_LEAF)
DEF_GCC_BUILTIN(BUILT_IN_ISLESSEQUAL, "islessequal", BT_FN_INT_VAR,
ATTR_CONST_NOTHROW_TYPEGENERIC_LEAF)
DEF_GCC_BUILTIN(BUILT_IN_ISLESSGREATER, "islessgreater", BT_FN_INT_VAR,
ATTR_CONST_NOTHROW_TYPEGENERIC_LEAF)
DEF_GCC_BUILTIN(BUILT_IN_ISUNORDERED, "isunordered", BT_FN_INT_VAR,
ATTR_CONST_NOTHROW_TYPEGENERIC_LEAF)
[Bug regression/58603] [4.9 Regression] hash-table.h:962: error: anachronistic old-style base class initia
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58603 --- Comment #6 from rsandifo at gcc dot gnu.org --- (In reply to dave.anglin from comment #5) > KDE added a trailing underscore to work around this issue. Seems easier just to #undef m_slot for hpux in system.h.
[Bug libstdc++/58628] New: Incorrect std::isalpha results with UTF-8 locale on illumos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58628 Bug ID: 58628 Summary: Incorrect std::isalpha results with UTF-8 locale on illumos Product: gcc Version: 4.4.7 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: alp at rsu dot ru The following example when compiled with gcc 3.4,4.7 or 4.4 and launched with en_US.UTF-8 locale on illumos says that char with 196 code is alphabetic, however it's not a correct UTF-8 symbol. $ env LANG=en_US.UTF-8 ./test_ctype "�" letter is � (int)letter is 196 std::use_facet:true If this program is compiled with Sun Studio Compiler (CC) results are: $ env LANG=en_US.UTF-8 ./test_ctype_CC "�" letter is � (int)letter is 196 std::use_facet:false if I compile this program on Linux / FreeBSD , results are correct. Related OpenIndiana bug report: https://www.illumos.org/issues/4173 Discussion on illumos-dev: http://comments.gmane.org/gmane.os.illumos.devel/14193
[Bug libstdc++/58628] Incorrect std::isalpha results with UTF-8 locale on illumos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58628 --- Comment #1 from Alexander Pyhalov --- Created attachment 30958 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30958&action=edit ctype test
[Bug libstdc++/58625] std::signbit always converts to double
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58625
--- Comment #6 from Oleg Endo ---
(In reply to Jakub Jelinek from comment #5)
> Some builtins are type generic, meaning that you can use just the non-{l,f}
> suffixed variant always, but __builtin_signbit isn't among them.
Yep. So libstdc++-v3/include/c_std/cmath (signbit) would require a fix, too in
this case, right? Or maybe rather make the signbit builtin type generic?
[Bug target/56993] power gcc built 416.gamess generates wrong result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56993 --- Comment #2 from Mikael Pettersson --- Can you provide a reduced test case?
[Bug target/58621] With -fsection-anchors, a superfluous 'add' is performed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58621 Richard Earnshaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Richard Earnshaw --- Your suggested optimization would be invalid if .LANCHOR0 had the address 0x?FFC, whereupon adding 4 would wrap the offset component but not the base component in x0.
[Bug c++/56746] [4.8 regression] increased memory usage when compiling C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56746 ofv at wanadoo dot es changed: What|Removed |Added CC||ofv at wanadoo dot es --- Comment #13 from ofv at wanadoo dot es --- My case is similar to the one described by Mathias Gaunard, but with a difference of 3x memory usage when -ftrack-macro-expansion=0 is not added to the command line. I use Boost Preprocessor plus a number of macros to define and instantiate lots of templates. That's the case that requires 3x more memory (low estimate) with some TUs requiring way more than 1GB to compile (on a 32 bit machine, which means that parallel builds usually ends with massive swapping and the compile jobs killed due to memory starvation.) I have a version of the same code base that uses variadic templates instead of Boost Preprocessor, although the macros for instantiating the templates are still there. That requires about 1.5x more memory.
[Bug fortran/58618] ICE with character substring and ASSOCIATE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58618 Tobias Burnus changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2013-10-05 CC||burnus at gcc dot gnu.org Summary|ICE with character array|ICE with character |and ASSOCIATE |substring and ASSOCIATE Ever confirmed|0 |1 Known to fail||4.8.1, 4.9.0 --- Comment #1 from Tobias Burnus --- The ICE occurs in resolve_fl_variable 10795 e = sym->ts.u.cl->length; Here, sym is "x" and ts.u.cl == NULL. Without the substring, ts.u.cl matches "s"'s ts.u.cl (same pointer address). The variable is set in parse.c's parse_associate: 3404 sym->ts = a->target->ts; If the RHS is not a substring, it works. If it is, a->target->ts.u.cl is NULL and the length is only in the REF_SUBSTRING expression at a->target->ref->next->u.ss.length->length
[Bug libstdc++/58625] std::signbit always converts to double
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58625 --- Comment #7 from Jakub Jelinek --- I don't think it is a good idea to extend the number of type generic builtins unless strictly necessary, the overloading in C is quite ugly hack.
[Bug libstdc++/58625] std::signbit always converts to double
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58625 --- Comment #8 from Jakub Jelinek --- That said, I'd say that every conversion to double that would change the sign looks wrong to me, no matter of what the rounding mode is, except perhaps for NaN canonicalization and that sNaN could be signalled. So IMHO this is mostly an optimization thing, not correctness.
[Bug c/58626] possible array wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58626 --- Comment #1 from Mikael Pettersson --- Started with r202775, still occurs with today's trunk.
[Bug c++/58629] New: Do not implicit move instance for throw operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58629
Bug ID: 58629
Summary: Do not implicit move instance for throw operator
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dmitriy-hshg at mail dot ru
Created attachment 30959
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30959&action=edit
Example
It is good idea to use move semantics for throw operator:
std::runtime_error error("message");
...
throw error; // execution of this block ends => we can implicit move
'error'.
but it may be used only for instances (variables) defined in try {} block. For
other instances a copy semantics must be applied:
std::runtime_error error("message");
...
try {
...
throw error; // we can return to outside block and get access to
'error' again => we must copy 'error'
} catch (std::runtime_error &e) {
std::cout << error.what(); // It must be OK!
}
I have attached an example of code. In GCC instance is always implicity moved.
Expected result:
'error' must be valid in catch(){} block
Actual result:
'error' is invalid in catch(){} block because it is moved in throw error;
[Bug libstdc++/58625] std::signbit always converts to double
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58625 --- Comment #9 from Paolo Carlini --- Ok, thanks a lot for the comments. Thus, Oleg, given in particular the last comment from Jakub, let's just apply to mainline your initial proposed change, let's leave for now include/c_std alone. Just test the change, send it to the mailing lists as preapproved. Please also add a short comment before the code, explaining that a type generic signbit builtin isn't available. Thanks!
[Bug c++/58629] Do not implicit move instance for throw operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58629 --- Comment #1 from Paolo Carlini --- Did you search bugzilla before filing the bug? I'm asking because I'm pretty sure we already have something closely related.
[Bug libstdc++/58625] std::signbit always converts to double
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58625
--- Comment #10 from Daniel Krügler ---
(In reply to Oleg Endo from comment #4)
> There's another place in file libstdc++-v3/include/c_std/cmath:
>
> template
> inline typename __gnu_cxx::__enable_if<__is_arithmetic<_Tp>::__value,
> int>::__type
> signbit(_Tp __f)
> {
> typedef typename __gnu_cxx::__promote<_Tp>::__type __type;
> return __builtin_signbit(__type(__f));
> }
I think this template should no longer exist after resolution of
http://cplusplus.github.io/LWG/lwg-defects.html#1327
(The P/R doesn't become very clear in the quoted reference. In essence it
replaced the previous template by the three overloads mentioned above, see
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3289.pdf
)
[Bug c++/58629] Do not implicit move instance for throw operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58629 --- Comment #2 from Paolo Carlini --- Please compare c++/57533
[Bug c++/57533] When throwing local variable, it's being move-constructed even if not going out of scope.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57533 Dmitry changed: What|Removed |Added CC||dmitriy-hshg at mail dot ru --- Comment #2 from Dmitry --- *** Bug 58629 has been marked as a duplicate of this bug. ***
[Bug c++/58629] Do not implicit move instance for throw operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58629 Dmitry changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Dmitry --- Thank you! *** This bug has been marked as a duplicate of bug 57533 ***
[Bug libstdc++/58625] std::signbit always converts to double
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58625 --- Comment #11 from Paolo Carlini --- At some point, as we discussed already a bit, we should even try to remove completely the c_std version. For now as I said, let's just leave it alone.
[Bug bootstrap/39968] Should plugins use shared library?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39968 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #12 from Dominique d'Humieres --- > Any point to keep this four year old PR open? No answer since two months, closing as fixed. Please open a new PR for plugin problems.
[Bug rtl-optimization/38711] ira should not be using df-lr except at -O1.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38711 Bug 38711 depends on bug 54961, which changed state. Bug 54961 Summary: FAIL: gfortran.dg/pr48757.f -O (internal compiler error) after revision 192440 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54961 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug middle-end/54961] FAIL: gfortran.dg/pr48757.f -O (internal compiler error) after revision 192440
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54961 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #10 from Dominique d'Humieres --- > This PR disappeared from my tests between revisions 192878 and 193318. > Was it fixed or hidden? No answer since two months, closing as fixed.
[Bug ipa/58398] [4.9 Regression] gcc.dg/attr-ifunc-4.c runfail regression after r202111
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58398 --- Comment #8 from Bernd Edlinger --- How can I set this PR to "FIXED"?
[Bug c++/53756] [C++1y] ICE: in gen_type_die_with_usage, at dwarf2out.c:18774 with -g and operator auto ()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53756
tim blechmann changed:
What|Removed |Added
CC||tim at klingt dot org
--- Comment #5 from tim blechmann ---
i think i experienced the same issue, but with a different line number:
internal compiler error: in gen_type_die_with_usage, at dwarf2out.c:19486
g++-4.8 -std=c++1y -g -x c++
code:
struct
{
auto a1 ();
}
g++-4.8 -v
Using built-in specs.
COLLECT_GCC=/usr/bin/g++-4.8.real
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.8.1-2ubuntu1~13.04' --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 --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-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.1 (Ubuntu 4.8.1-2ubuntu1~13.04)
[Bug c/52991] attribute packed broken on mingw32?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52991 --- Comment #14 from Mikael Pettersson --- Ping -- there's been a patch for this bug for almost 10 months now...
[Bug target/58630] New: [4.9 Regression] Revision 203171 breaks several MS-ABI tests
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58630
Bug ID: 58630
Summary: [4.9 Regression] Revision 203171 breaks several MS-ABI
tests
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dominiq at lps dot ens.fr
CC: hjl.tools at gmail dot com, iains at gcc dot gnu.org, jh at
suse dot cz,
ktietz at gcc dot gnu.org
Target: i?86-*-* x86_64-*-*
Revision 203171 breaks several MS-ABI tests:
FAIL: gcc.target/i386/pr43662.c (internal compiler error)
FAIL: gcc.target/i386/pr43662.c (test for excess errors)
FAIL: gcc.target/i386/pr43869.c (internal compiler error)
FAIL: gcc.target/i386/pr43869.c (test for excess errors)
FAIL: gcc.target/i386/pr57003.c (internal compiler error)
FAIL: gcc.target/i386/pr57003.c (test for excess errors)
FAIL: gcc.target/i386/pr9771-1.c (test for excess errors)
FAIL: gcc.target/x86_64/abi/callabi/func-1.c (test for excess errors)
FAIL: gcc.target/x86_64/abi/callabi/func-2a.c (test for excess errors)
FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2a.c (internal compiler
error)
FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2a.c (test for excess errors)
FAIL: gcc.target/x86_64/abi/callabi/func-indirect.c (test for excess errors)
FAIL: gcc.target/x86_64/abi/callabi/vaarg-1.c (test for excess errors)
FAIL: gcc.target/x86_64/abi/callabi/vaarg-2.c (test for excess errors)
FAIL: gcc.target/x86_64/abi/callabi/vaarg-3.c (test for excess errors)
FAIL: gcc.target/x86_64/abi/callabi/vaarg-4a.c (test for excess errors)
FAIL: gcc.target/x86_64/abi/callabi/vaarg-5a.c (test for excess errors)
(see http://gcc.gnu.org/ml/gcc-regression/2013-10/msg00026.html or
http://gcc.gnu.org/ml/gcc-testresults/2013-10/msg00388.html ).
The failure for gcc.target/i386/pr9771-1.c is
[macbook] f90/bug% gfc -O2 -fomit-frame-pointer -ffixed-ebp
/opt/gcc/work/gcc/testsuite/gcc.target/i386/pr9771-1.c -m32
/opt/gcc/work/gcc/testsuite/gcc.target/i386/pr9771-1.c: In function 'test':
/opt/gcc/work/gcc/testsuite/gcc.target/i386/pr9771-1.c:46:1: error: bp cannot
be used in asm here
}
and the others are of the kind
sorry, unimplemented: ms_abi attribute requires -maccumulate-outgoing-args or
subtarget optimization implying it
Notes:
(1) Compiling the failing gcc.target/i386/pr4* and
gcc.target/x86_64/abi/callabi/func-indirect-2a.c gives an ICE:
/opt/gcc/work/gcc/testsuite/gcc.target/i386/pr43662.c:20:9: internal compiler
error: in expand_call, at calls.c:3153
or
internal compiler error: in expand_call, at calls.c:3453
for the others.
(2) Some tests are restricted to Linux but can be run on Darwin without
failure.
(3) The following patch fixes the failures related to
-maccumulate-outgoing-args
diff -up ../_clean/gcc/testsuite/gcc.target/i386/pr43662.c
gcc/testsuite/gcc.target/i386/pr43662.c
--- ../_clean/gcc/testsuite/gcc.target/i386/pr43662.c2011-08-01
14:36:41.0 +0200
+++ gcc/testsuite/gcc.target/i386/pr43662.c2013-10-05 16:51:56.0
+0200
@@ -1,5 +1,5 @@
/* { dg-do compile { target lp64 } } */
-/* { dg-options "-O2" } */
+/* { dg-options "-O2 -maccumulate-outgoing-args" } */
void __attribute__ ((ms_abi)) foo (void)
{
diff -up ../_clean/gcc/testsuite/gcc.target/i386/pr43869.c
gcc/testsuite/gcc.target/i386/pr43869.c
--- ../_clean/gcc/testsuite/gcc.target/i386/pr43869.c2011-08-01
14:36:41.0 +0200
+++ gcc/testsuite/gcc.target/i386/pr43869.c2013-10-05 16:53:09.0
+0200
@@ -1,4 +1,5 @@
/* { dg-do compile { target lp64 } } */
+/* { dg-options "-maccumulate-outgoing-args" } */
int __attribute__((__noinline__))
bugged(float f1, float f2, float f3, float f4,
diff -up ../_clean/gcc/testsuite/gcc.target/i386/pr57003.c
gcc/testsuite/gcc.target/i386/pr57003.c
--- ../_clean/gcc/testsuite/gcc.target/i386/pr57003.c2013-04-26
11:07:25.0 +0200
+++ gcc/testsuite/gcc.target/i386/pr57003.c2013-10-05 16:53:52.0
+0200
@@ -1,6 +1,6 @@
/* PR rtl-optimization/57003 */
/* { dg-do run } */
-/* { dg-options "-O2" } */
+/* { dg-options "-O2 -maccumulate-outgoing-args" } */
#define N 2001
unsigned short *b, *c, *d;
diff -up ../_clean/gcc/testsuite/gcc.target/x86_64/abi/callabi/func-1.c
gcc/testsuite/gcc.target/x86_64/abi/callabi/func-1.c
--- ../_clean/gcc/testsuite/gcc.target/x86_64/abi/callabi/func-1.c
2009-11-25 18:14:50.0 +0100
+++ gcc/testsuite/gcc.target/x86_64/abi/callabi/func-1.c2013-10-05
16:45:39.0 +0200
@@ -2,7 +2,7 @@
*/
/* Origin: Kai Tietz */
/* { dg-do run } */
-/* { dg-options "-std=gnu99 -ffast-math" } */
+/* { dg-options "-std=gnu99 -ffast-math -maccumulate-outgoing-args" } */
#include "callabi.h"
extern void abort (void);
diff -up ../_clean/gcc/testsuite/gcc.target/x86_64/abi/callabi/func-2a.c
gcc/testsuite/gcc.target/x86_64/abi/callabi/func-2a.c
[Bug c++/58631] New: Internal compiler error: Error reporting routines re-entered.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58631 Bug ID: 58631 Summary: Internal compiler error: Error reporting routines re-entered. Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: bsamim at yahoo dot com Created attachment 30960 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30960&action=edit Preprocessed source stored into /tmp/cc1xZWpN.out file, please attach this to your bugreport. g++ -I/usr/include -I/usr/local/include -std=c++11 -pthread -ggdb -g3 -Wall -c Deck.cpp -o Deck.o ‘ Internal compiler error: Error reporting routines re-entered. Please submit a full bug report, with preprocessed source if appropriate. See for instructions. Preprocessed source stored into /tmp/cc1xZWpN.out file, please attach this to your bugreport. make: *** [Deck.o] Error 1
[Bug c++/58631] Internal compiler error: Error reporting routines re-entered.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58631
--- Comment #1 from bsamim at yahoo dot com ---
It seems this happens in the following code when the copy constructor for is
set as Card(Card& ) = delete;It will crash the compiler on this as I
believe it is because the vector is expecting it to be copyable even though it
is doing a move. After changing the code a bit and putting it as private I was
able to get the following output but it still crashed the compiler at the end.
Card.h:28:5: error: ‘Card::Card(const Card&)’ is private
In file included from /usr/include/c++/4.7/bits/move.h:57:0,
from /usr/include/c++/4.7/bits/stl_pair.h:61,
from /usr/include/c++/4.7/bits/stl_algobase.h:65,
from /usr/include/c++/4.7/vector:61,
from Card.h:4,
from Deck.h:4,
from Deck.cpp:1:
/usr/include/c++/4.7/type_traits:762:43: error: within this context
In file included from Deck.h:4:0,
from Deck.cpp:1:
/usr/include/c++/4.7/type_traits: In instantiation of ‘struct
std::__is_nt_constructible_impl’:
/usr/include/c++/4.7/type_traits:116:12: required from ‘struct
std::__and_,
std::__is_nt_constructible_impl >’
/usr/include/c++/4.7/type_traits:1002:12: required from ‘struct
std::is_nothrow_constructible’
/usr/include/c++/4.7/type_traits:1033:12: required from ‘struct
std::__is_nothrow_move_constructible_impl’
/usr/include/c++/4.7/type_traits:1039:12: required from ‘struct
std::is_nothrow_move_constructible’
/usr/include/c++/4.7/type_traits:126:12: required from ‘struct
std::__not_ >’
/usr/include/c++/4.7/type_traits:116:12: required from ‘struct
std::__and_ >,
std::is_copy_constructible >’
/usr/include/c++/4.7/bits/move.h:107:12: required from ‘struct
std::__move_if_noexcept_cond’
/usr/include/c++/4.7/bits/stl_iterator.h:1129:32: required from
‘_ForwardIterator std::__uninitialized_move_if_noexcept_a(_InputIterator,
_InputIterator, _ForwardIterator, _Allocator&) [with _InputIterator = Card*;
_ForwardIterator = Card*; _Allocator = std::allocator]’
/usr/include/c++/4.7/bits/vector.tcc:413:6: required from ‘void
std::vector<_Tp, _Alloc>::_M_emplace_back_aux(_Args&& ...) [with _Args =
{Card}; _Tp = Card; _Alloc = std::allocator]’
/usr/include/c++/4.7/bits/vector.tcc:102:4: required from ‘void
std::vector<_Tp, _Alloc>::emplace_back(_Args&& ...) [with _Args = {Card}; _Tp =
Card; _Alloc = std::allocator]’
[Bug c++/58631] Internal compiler error: Error reporting routines re-entered.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58631 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Paolo Carlini --- Dup *** This bug has been marked as a duplicate of bug 57086 ***
[Bug c++/57086] Internal compiler error: Error reporting routines re-entered.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57086 Paolo Carlini changed: What|Removed |Added CC||bsamim at yahoo dot com --- Comment #11 from Paolo Carlini --- *** Bug 58631 has been marked as a duplicate of this bug. ***
[Bug c++/58632] New: [4.8/4.9 Regression] ICE reusing template parameter name as class name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58632
Bug ID: 58632
Summary: [4.8/4.9 Regression] ICE reusing template parameter
name as class name
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 line of code triggers an ICE since GCC 4.8.0:
=
template class A> class A {};
=
bug.cc:1:39: internal compiler error: tree check: expected record_type or
union_type or qual_union_type, have template_template_parm in xref_basetypes,
at cp/decl.c:12220
template class A> class A {};
^
0xcd860a tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.c:9176
0x560941 tree_check3
../../gcc/gcc/tree.h:2649
0x560941 xref_basetypes(tree_node*, tree_node*)
../../gcc/gcc/cp/decl.c:12220
0x63776f cp_parser_class_head
../../gcc/gcc/cp/parser.c:19541
0x63776f cp_parser_class_specifier_1
../../gcc/gcc/cp/parser.c:18842
0x638230 cp_parser_class_specifier
../../gcc/gcc/cp/parser.c:19111
0x638230 cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:14090
0x64d739 cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:11337
0x651dc3 cp_parser_single_declaration
../../gcc/gcc/cp/parser.c:22591
0x654be8 cp_parser_template_declaration_after_export
../../gcc/gcc/cp/parser.c:22467
0x65c9d9 cp_parser_declaration
../../gcc/gcc/cp/parser.c:10737
0x65b5aa cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:10659
0x65ce76 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:3939
0x65ce76 c_parse_file()
../../gcc/gcc/cp/parser.c:28911
0x7708b3 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1046
Please submit a full bug report, [etc.]
[Bug c++/58633] New: [4.7/4.8/4.9 Regression] ICE with decltype of destructor call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58633
Bug ID: 58633
Summary: [4.7/4.8/4.9 Regression] ICE with decltype of
destructor call
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") triggers an ICE
since GCC 4.7.0:
void foo(int i)
{
typedef int I;
__decltype(i.I::~I())* p;
}
bug.cc: In function 'void foo(int)':
bug.cc:4:22: internal compiler error: in cp_parser_abort_tentative_parse, at
cp/parser.c:24356
__decltype(i.I::~I())* p;
^
0x62fa03 cp_parser_abort_tentative_parse
../../gcc/gcc/cp/parser.c:24355
0x64270c cp_parser_decltype_expr
../../gcc/gcc/cp/parser.c:11708
0x64270c cp_parser_decltype
../../gcc/gcc/cp/parser.c:11791
0x65a192 cp_parser_simple_type_specifier
../../gcc/gcc/cp/parser.c:14298
0x637ea5 cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:14168
0x64d739 cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:11337
0x6517e9 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:10927
0x653810 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:10876
0x654930 cp_parser_declaration_statement
../../gcc/gcc/cp/parser.c:10523
0x63d147 cp_parser_statement
../../gcc/gcc/cp/parser.c:9274
0x63e452 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:9552
0x63e596 cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:9506
0x64f95b cp_parser_function_body
../../gcc/gcc/cp/parser.c:18328
0x64f95b cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:18364
0x6509af cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:22351
0x6516d5 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:22272
0x6516d5 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:16357
0x65198f cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:10995
0x653810 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:10876
0x65c83e cp_parser_declaration
../../gcc/gcc/cp/parser.c:10773
Please submit a full bug report, [etc.]
[Bug rtl-optimization/58517] icvt (after combine) puts ccreg clobbering insn between ccset insn and cc use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58517
Oleg Endo changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-10-05
Component|target |rtl-optimization
Summary|[SH] wrong code with subc |icvt (after combine) puts
|and movsicc |ccreg clobbering insn
|(-mpretend-cmove) after ce2 |between ccset insn and cc
||use
Ever confirmed|0 |1
--- Comment #1 from Oleg Endo ---
This seems to be a bug in ifcvt.c
Reduced test cases:
int
test_subc (int q, int read, int end)
{
return q < read ? (read - q - 1) : (end - q);
}
int
test_addc (int q, int read, int end)
{
return q < read ? (read + q + 1) : (end + q);
}
compiled with -O2 -m4 -mpretend-cmove:
_test_subc:
sett
mov r5,r0
sub r4,r6
subcr4,r0 ! 36*subc
bf 0f ! 34*movsicc_t_true/1
mov r6,r0
0:
rts
nop
_test_addc:
sett
mov r4,r0
add r4,r6
addcr5,r0 ! 34*addc
bf 0f ! 32*movsicc_t_true/1
mov r6,r0
0:
rts
nop
In both above cases the comparison 'q < read' is eliminated, because ifcvt
moves the T_REG clobbering subc/addc insn between the 'q < read' comparison
(sets T_REG) and the conditional branch (uses T_REG).
[Bug c++/58634] New: [c++11] ICE initializing static class member via an anonymous class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58634
Bug ID: 58634
Summary: [c++11] ICE initializing static class member via an
anonymous class
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") triggers an ICE
on trunk (since at least 4.9.0 20130920):
===
struct A
{
static const int i;
};
const int A::i = (struct { int j=0; }){}.j;
===
bug.cc:6:26: internal compiler error: in nested_anon_class_index, at
cp/mangle.c:1403
const int A::i = (struct { int j=0; }){}.j;
^
0x6eca7e nested_anon_class_index
../../gcc/gcc/cp/mangle.c:1403
0x6eca7e write_unnamed_type_name
../../gcc/gcc/cp/mangle.c:1417
0x6eca7e write_unqualified_name
../../gcc/gcc/cp/mangle.c:1277
0x6f5937 write_prefix
../../gcc/gcc/cp/mangle.c:1059
0x6ed0c6 write_nested_name
../../gcc/gcc/cp/mangle.c:963
0x6ed6fc write_name
../../gcc/gcc/cp/mangle.c:864
0x6edd7f write_encoding
../../gcc/gcc/cp/mangle.c:719
0x6ee10d write_mangled_name
../../gcc/gcc/cp/mangle.c:689
0x6f6ac5 mangle_decl_string
../../gcc/gcc/cp/mangle.c:3446
0x6f6cf8 get_mangled_id
../../gcc/gcc/cp/mangle.c:3468
0x6f6cf8 mangle_decl(tree_node*)
../../gcc/gcc/cp/mangle.c:3491
0xcda6d0 decl_assembler_name(tree_node*)
../../gcc/gcc/tree.c:546
0x60ff4f comdat_linkage(tree_node*)
../../gcc/gcc/cp/decl2.c:1636
0x6b7a25 expand_or_defer_fn_1(tree_node*)
../../gcc/gcc/cp/semantics.c:3911
0x6b7f68 expand_or_defer_fn(tree_node*)
../../gcc/gcc/cp/semantics.c:3944
0x6e65c7 maybe_clone_body(tree_node*)
../../gcc/gcc/cp/optimize.c:428
0x6b798f expand_or_defer_fn_1(tree_node*)
../../gcc/gcc/cp/semantics.c:3874
0x6b7f68 expand_or_defer_fn(tree_node*)
../../gcc/gcc/cp/semantics.c:3944
0x69e8a1 synthesize_method(tree_node*)
../../gcc/gcc/cp/method.c:809
0x615789 mark_used(tree_node*, int)
../../gcc/gcc/cp/decl2.c:4719
Please submit a full bug report, [etc.]
[Bug c++/58624] gcc internal compiler error: Segmentaion fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58624 --- Comment #2 from Paolo Carlini --- Doesn't look like a C++ front-end issue.
[Bug rtl-optimization/58517] icvt (after combine) puts ccreg clobbering insn between ccset insn and ccreg use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58517 --- Comment #2 from Oleg Endo --- The problem also happens on 4.8.
[Bug c++/58635] New: [c++11] ICE with __transaction_atomic and noexcept(false)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58635
Bug ID: 58635
Summary: [c++11] ICE with __transaction_atomic and
noexcept(false)
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 three code snippets (compiled with "-std=c++0x -fgnu-tm")
trigger slightly different ICEs in build_transaction_expr since GCC 4.7.0.
The first two snippets are valid, the last one is invalid:
===
int foo()
{
return __transaction_atomic noexcept(false) (false);
}
===
bug.cc: In function 'int foo()':
bug.cc:3:53: internal compiler error: tree check: expected class 'expression',
have 'constant' (integer_cst) in build_transaction_expr, at cp/semantics.c:5224
return __transaction_atomic noexcept(false) (false);
^
0xcd8c59 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/gcc/tree.c:9227
0x6bcf7a expr_check
../../gcc/gcc/tree.h:2778
0x6bcf7a build_transaction_expr(unsigned int, tree_node*, int, tree_node*)
../../gcc/gcc/cp/semantics.c:5224
0x6443e9 cp_parser_transaction_expression
../../gcc/gcc/cp/parser.c:28568
0x6443e9 cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:6845
0x644cff cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:7701
0x6451bf cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:7937
0x647023 cp_parser_expression
../../gcc/gcc/cp/parser.c:8099
0x63dbf2 cp_parser_expression
../../gcc/gcc/cp/parser.c:8138
0x63dbf2 cp_parser_jump_statement
../../gcc/gcc/cp/parser.c:10472
0x63dbf2 cp_parser_statement
../../gcc/gcc/cp/parser.c:9182
0x63e452 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:9552
0x63e596 cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:9506
0x64f95b cp_parser_function_body
../../gcc/gcc/cp/parser.c:18328
0x64f95b cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:18364
0x6509af cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:22351
0x6516d5 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:22272
0x6516d5 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:16357
0x65198f cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:10995
0x653810 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:10876
Please submit a full bug report, [etc.]
===
int foo(int i)
{
return __transaction_atomic noexcept(false) (i);
}
===
bug.cc: In function 'int foo(int)':
bug.cc:3:49: internal compiler error: tree check: expected class 'expression',
have 'declaration' (parm_decl) in build_transaction_expr, at
cp/semantics.c:5224
return __transaction_atomic noexcept(false) (i);
^
0xcd8c59 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/gcc/tree.c:9227
[etc.]
===
int foo()
{
return __transaction_atomic noexcept(false) (x);
}
===
bug.cc: In function 'int foo()':
bug.cc:3:48: error: 'x' was not declared in this scope
return __transaction_atomic noexcept(false) (x);
^
bug.cc:3:49: internal compiler error: tree check: expected class 'expression',
have 'exceptional' (error_mark) in build_transaction_expr, at
cp/semantics.c:5224
return __transaction_atomic noexcept(false) (x);
^
0xcd8c59 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/gcc/tree.c:9227
[etc.]
[Bug c++/57945] [4.9 Regression] ICE: in varpool_get_node, at cgraph.h:840
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57945
Volker Reichelt changed:
What|Removed |Added
Keywords||ice-on-valid-code
Last reconfirmed|2013-07-27 00:00:00 |2013-10-05
CC||reichelt at gcc dot gnu.org
Known to work||4.7.0, 4.8.0
Known to fail||4.9.0
--- Comment #1 from Volker Reichelt ---
Here's an even simpler testcase which is probably valid (at least it was
accepted in 4.8.x):
=
static int i __attribute__((weakref("j")));
=
cc1plus: internal compiler error: in varpool_get_node, at cgraph.h:891
0x512ddc varpool_get_node
../../gcc/gcc/cgraph.h:891
0xd2d101 varpool_get_node
../../gcc/gcc/varpool.c:389
0xd2d101 varpool_analyze_node(varpool_node*)
../../gcc/gcc/varpool.c:396
0x804217 analyze_functions
../../gcc/gcc/cgraphunit.c:1035
0x805739 finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2260
0x618920 cp_write_global_declarations()
../../gcc/gcc/cp/decl2.c:4365
Please submit a full bug report, [etc.]
[Bug c++/58466] [4.8/4.9 Regression] ICE in cxx_eval_constant_expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58466 Paolo Carlini changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2013-10-05 Ever confirmed|0 |1
[Bug c++/58636] New: [4.7/4.8/4.9 Regression] ICE with initializer_list and rvalue references
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58636
Bug ID: 58636
Summary: [4.7/4.8/4.9 Regression] ICE with initializer_list and
rvalue references
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 similar invalid code snippets (compiled with "-std=c++11")
trigger ICEs in different parts of the compiler:
#include
int foo(std::initializer_list);
int i = foo({ 0 });
bug.cc:5:18: error: 'const' qualifiers cannot be applied to 'int&&'
int i = foo({ 0 });
^
In file included from bug.cc:1:0:
.../include/c++/4.9.0/initializer_list: In instantiation of 'class
std::initializer_list':
bug.cc:5:18: required from here
.../include/c++/4.9.0/initializer_list:54:26: error: forming pointer to
reference type 'int&&'
typedef const _E* iterator;
^
.../include/c++/4.9.0/initializer_list:55:26: error: forming pointer to
reference type 'int&&'
typedef const _E* const_iterator;
^
bug.cc: In function 'void __static_initialization_and_destruction_0(int, int)':
bug.cc:5:18: internal compiler error: in gimplify_init_ctor_eval, at
gimplify.c:3734
int i = foo({ 0 });
^
0x96977d gimplify_init_ctor_eval
../../gcc/gcc/gimplify.c:3734
0x96fbd4 gimplify_init_constructor
../../gcc/gcc/gimplify.c:4133
0x970a7e gimplify_modify_expr_rhs
../../gcc/gcc/gimplify.c:4518
0x970de4 gimplify_modify_expr
../../gcc/gcc/gimplify.c:4834
0x9661d5 gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,
bool (*)(tree_node*), int)
../../gcc/gcc/gimplify.c:7332
0x9691a6 gimplify_stmt(tree_node**, gimple_statement_d**)
../../gcc/gcc/gimplify.c:5709
0x964130 gimplify_and_add
../../gcc/gcc/gimplify.c:329
0x964130 internal_get_tmp_var
../../gcc/gcc/gimplify.c:594
0x964bae gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,
bool (*)(tree_node*), int)
../../gcc/gcc/gimplify.c:8163
0x96dec9 gimplify_call_expr
../../gcc/gcc/gimplify.c:2635
0x96567a gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,
bool (*)(tree_node*), int)
../../gcc/gcc/gimplify.c:7303
0x970f58 gimplify_modify_expr
../../gcc/gcc/gimplify.c:4875
0x9661d5 gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,
bool (*)(tree_node*), int)
../../gcc/gcc/gimplify.c:7332
0x9691a6 gimplify_stmt(tree_node**, gimple_statement_d**)
../../gcc/gcc/gimplify.c:5709
0x9656fe gimplify_cleanup_point_expr
../../gcc/gcc/gimplify.c:5485
0x9656fe gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,
bool (*)(tree_node*), int)
../../gcc/gcc/gimplify.c:7669
0x9691a6 gimplify_stmt(tree_node**, gimple_statement_d**)
../../gcc/gcc/gimplify.c:5709
0x964f9b gimplify_statement_list
../../gcc/gcc/gimplify.c:1525
0x964f9b gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,
bool (*)(tree_node*), int)
../../gcc/gcc/gimplify.c:7721
0x9691a6 gimplify_stmt(tree_node**, gimple_statement_d**)
../../gcc/gcc/gimplify.c:5709
Please submit a full bug report, [etc.]
===
#include
auto i = std::initializer_list{ 0 };
===
In file included from bug.cc:1:0:
.../include/c++/4.9.0/initializer_list: In instantiation of 'class
std::initializer_list':
bug.cc:3:42: required from here
.../include/c++/4.9.0/initializer_list:54:26: error: forming pointer to
reference type 'int&&'
typedef const _E* iterator;
^
.../include/c++/4.9.0/initializer_list:55:26: error: forming pointer to
reference type 'int&&'
typedef const _E* const_iterator;
^
bug.cc:3:42: error: 'const' qualifiers cannot be applied to 'int&&'
auto i = std::initializer_list{ 0 };
^
bug.cc:3:42: internal compiler error: in split_nonconstant_init_1, at
cp/typeck2.c:597
0x5dd883 split_nonconstant_init_1
../../gcc/gcc/cp/typeck2.c:597
0x5e0f12 split_nonconstant_init
../../gcc/gcc/cp/typeck2.c:692
0x5e0f12 store_init_value(tree_node*, tree_node*, vec**, int)
../../gcc/gcc/cp/typeck2.c:810
0x557478 check_initializer
../../gcc/gcc/cp/decl.c:5728
0x56a35c cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/gcc/cp/decl.c:6347
0x651267 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:16577
0x65198f cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:10995
0x653810 cp_parser_block_declaration
../../gcc/gcc/cp/parser.
[Bug c++/58527] Failures when a function parameter pack is not final
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58527 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Paolo Carlini --- Closing.
[Bug rtl-optimization/58517] icvt (after combine) puts ccreg clobbering insn between ccset insn and ccreg use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58517 Oleg Endo changed: What|Removed |Added CC||steven at gcc dot gnu.org --- Comment #3 from Oleg Endo --- The problematic transformation happens in ifcvt.c (noce_try_cmove_arith). I've only briefly looked over that code and can think of the following options how to fix the issue: 1) Check whether insn_a and insn_b modify the src reg (ccreg) of the conditional branch. If they do, don't do the transformation. On SH, the resulting code would be the same as not specifying -mpretend-cmove: cmp/ge r5,r4 mov r6,r0 bf/s.L6 sub r4,r0 rts nop .L6: sett mov r5,r0 rts subcr4,r0 2) Check whether insn_a and insn_b modify the src reg (ccreg) of the conditional branch. If they do, try to move the insn that sets the ccreg before the conditional branch, _after_ the emitted insn_a and insn_b and right before the conditional move. On SH, the resulting code would look something like this: sett mov r5,r0 sub r4,r6 subcr4,r0 cmp/ge r5,r4 bf 0f mov r6,r0 0: rts nop Steven, since you're RTL optimizers reviewer, could you please provide some feedback regarding the matter?
[Bug c++/58466] [4.8/4.9 Regression] ICE in cxx_eval_constant_expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58466
Volker Reichelt changed:
What|Removed |Added
CC||reichelt at gcc dot gnu.org
Known to work||4.7.0, 4.8.0
Known to fail||4.8.1, 4.8.2, 4.9.0
--- Comment #1 from Volker Reichelt ---
Here's an even simpler testcase:
=
template struct A;
template struct B;
template struct B> {};
B> b;
=
[Bug c++/58466] [4.8/4.9 Regression] ICE in cxx_eval_constant_expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58466 --- Comment #2 from Volker Reichelt --- Crash stack trace: PR58466.cc:7:11: internal compiler error: unexpected expression 'C' of kind template_parm_index B> b; ^ 0x6c40ce cxx_eval_constant_expression ../../gcc/gcc/cp/semantics.c:8197 0x6c7036 cxx_eval_outermost_constant_expr ../../gcc/gcc/cp/semantics.c:8217 0x6c9cab maybe_constant_value(tree_node*) ../../gcc/gcc/cp/semantics.c:8327 0x5b164e convert_nontype_argument ../../gcc/gcc/cp/pt.c:5576 0x5b164e convert_template_argument ../../gcc/gcc/cp/pt.c:6453 0x5aa702 coerce_template_parameter_pack ../../gcc/gcc/cp/pt.c:6577 0x5aa702 coerce_template_parms ../../gcc/gcc/cp/pt.c:6776 0x5b327a lookup_template_class_1 ../../gcc/gcc/cp/pt.c:7398 0x5b327a lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*, int, int) ../../gcc/gcc/cp/pt.c:7695 0x5b894e tsubst_aggr_type ../../gcc/gcc/cp/pt.c:9977 0x5ac34b tsubst(tree_node*, tree_node*, int, tree_node*) ../../gcc/gcc/cp/pt.c:11367 0x5b7f1a tsubst_template_args ../../gcc/gcc/cp/pt.c:9774 0x5ac09f tsubst(tree_node*, tree_node*, int, tree_node*) ../../gcc/gcc/cp/pt.c:11672 0x5c6ee0 get_class_bindings ../../gcc/gcc/cp/pt.c:18177 0x5c7ad2 most_specialized_class ../../gcc/gcc/cp/pt.c:18401 0x5d85f0 instantiate_class_template_1 ../../gcc/gcc/cp/pt.c:8687 0x5d85f0 instantiate_class_template(tree_node*) ../../gcc/gcc/cp/pt.c:9216 0x66445b complete_type(tree_node*) ../../gcc/gcc/cp/typeck.c:132 0x555239 start_decl_1(tree_node*, bool) ../../gcc/gcc/cp/decl.c:4670 0x57f03d start_decl(cp_declarator const*, cp_decl_specifier_seq*, int, tree_node*, tree_node*, tree_node**) ../../gcc/gcc/cp/decl.c:4633 Please submit a full bug report, [etc.]
[Bug c++/58637] New: [c++1y] ICE with wrong usage of template<> in front of function containing auto parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58637 Bug ID: 58637 Summary: [c++1y] ICE with wrong usage of template<> in front of function containing auto parameter 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 line of code (compiled with "-std=c++1y") triggers an ICE on trunk (since at least 4.9.0-20130920): = template<> void foo(auto); = bug.cc:1:21: internal compiler error: in add_implicit_template_parms, at cp/parser.c:28978 template<> void foo(auto); ^ 0x64f044 add_implicit_template_parms ../../gcc/gcc/cp/parser.c:28978 0x64f044 cp_parser_parameter_declaration_list ../../gcc/gcc/cp/parser.c:18067 0x64f356 cp_parser_parameter_declaration_clause ../../gcc/gcc/cp/parser.c:17882 0x649f04 cp_parser_direct_declarator ../../gcc/gcc/cp/parser.c:16834 0x649f04 cp_parser_declarator ../../gcc/gcc/cp/parser.c:16705 0x650cc7 cp_parser_init_declarator ../../gcc/gcc/cp/parser.c:16268 0x651fd4 cp_parser_single_declaration ../../gcc/gcc/cp/parser.c:22665 0x6553fd cp_parser_explicit_specialization ../../gcc/gcc/cp/parser.c:13986 0x65cac5 cp_parser_declaration ../../gcc/gcc/cp/parser.c:10726 0x65b5aa cp_parser_declaration_seq_opt ../../gcc/gcc/cp/parser.c:10659 0x65ce76 cp_parser_translation_unit ../../gcc/gcc/cp/parser.c:3939 0x65ce76 c_parse_file() ../../gcc/gcc/cp/parser.c:28911 0x7708b3 c_common_parse_file() ../../gcc/gcc/c-family/c-opts.c:1046 Please submit a full bug report, [etc.]
[Bug rtl-optimization/58517] icvt (after combine) puts ccreg clobbering insn between ccset insn and ccreg use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58517
--- Comment #4 from Steven Bosscher ---
So if I understand correctly, this is what happens (sorry, reading
LIPSy RTL is still just too unnatural to me! ;-))
before ifcvt-after-combine:
r147:=(r424>r178)
r190:=r423-r189
if (r147==0) goto L433
{r190:=(~r189)+r424; r147:=X}
L433:
after ifcvt-after-combine:
r147:=(r424>r189)
r190:=r423-r189
{r945:=(~r189)+r424; r147:=X}
r946:=r423-r189
r190:=(r147==0) ? r946:r945 // but r147 was clobbered!
r147:=(r190==0)
if (r147==0) goto L501
This is noce_try_cmove_arith:
/* if (test) x = a + b; else x = c - d;
=> y = a + b;
x = c - d;
if (test)
x = y;
*/
with "(test)" being clobbered by the assignment to "y" or "x" on the
code after the transformation has been applied. noce_try_cmove_arith
does not expect that the arithmetic insns emitted to load vtrue or
vfalse into general operands may clobber the condition. There should
be tests like this:
Index: ifcvt.c
===
--- ifcvt.c (revision 203224)
+++ ifcvt.c (working copy)
@@ -1573,6 +1573,8 @@ noce_try_cmove_arith (struct noce_if_info *if_info
optimize_bb_for_speed_p (BLOCK_FOR_INSN (insn_a)));
if (insn_cost == 0 || insn_cost > COSTS_N_INSNS (if_info->branch_cost))
return FALSE;
+ if (modified_in_p (if_info->cond, insn_a))
+ return FALSE;
}
else
insn_cost = 0;
@@ -1584,6 +1586,8 @@ noce_try_cmove_arith (struct noce_if_info *if_info
optimize_bb_for_speed_p (BLOCK_FOR_INSN (insn_b)));
if (insn_cost == 0 || insn_cost > COSTS_N_INSNS (if_info->branch_cost))
return FALSE;
+ if (modified_in_p (if_info->cond, insn_b))
+ return FALSE;
}
/* Possibly rearrange operands to make things come out more natural. */
That's option 1 of comment #3. Option 2 is only viable if the insn
computing "cond" is nearby (i.e. immediately above insn_a / insn_b),
otherwise it'll be necessary to solve a code motion dataflow problem.
Within one basic block that still would be doable (modified_between_p),
but I doubt it's worth the trouble.
[Bug c++/56060] ICE on invalid code in type_dependent_expression_p, at cp/pt.c:19742
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56060 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com Target Milestone|--- |4.9.0 --- Comment #3 from Paolo Carlini --- Mine.
[Bug fortran/58226] negative subscript pos at fortran/options.c:1205
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58226 Bud Davis changed: What|Removed |Added CC||bdavis at gcc dot gnu.org --- Comment #2 from Bud Davis --- works for me. GNU Fortran (GCC) 4.9.0 20131005 (experimental)
[Bug libstdc++/58638] New: libstdc++ builds as non-PIC when --with-pic is specified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58638 Bug ID: 58638 Summary: libstdc++ builds as non-PIC when --with-pic is specified Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: skunk at iskunk dot org Host: x86_64-unknown-linux-gnu Target: x86_64-unknown-linux-gnu Build: x86_64-unknown-linux-gnu I built GCC 4.8.1 with "--disable-shared --with-pic" so that I can statically link libgcc/libstdc++ into executables, including shared-library builds. However, when I attempted to build a C++ shared object on Linux/amd64 using the new compiler, I got this: libtool: link: g++ -fPIC -DPIC -shared -nostdlib /usr/lib/../lib64/crti.o /opt/tg-opt/gcc--4.8.1--linux64/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.1/crtbeginS.o .libs/Dqa_wrap.o .libs/dqa_func.o [...] -L/opt/tg-opt/gcc--4.8.1--linux64/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.1/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/opt/tg-opt/gcc--4.8.1--linux64/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.1/../../.. /opt/tg/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/libstdc++.a -lm -lc -lgcc /opt/tg-opt/gcc--4.8.1--linux64/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.1/crtendS.o /usr/lib/../lib64/crtn.o -march=opteron -mno-3dnow -O0 -pthread -Wl,-soname -Wl,libdqa_swig_interface.so -o .libs/libdqa_swig_interface.so /usr/bin/ld: /opt/tg/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/libstdc++.a(eh_throw.o): relocation R_X86_64_32S against `a local symbol' can not be used when making a shared object; recompile with -fPIC /opt/tg/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/libstdc++.a: could not read symbols: Bad value collect2: error: ld returned 1 exit status make[6]: *** [libdqa_swig_interface.la] Error 1 This is a regression from 4.7.x, when --with-pic correctly caused all (static) runtime libraries to be built with PIC code.
[Bug c++/58639] New: ICE on self-referential struct member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58639
Bug ID: 58639
Summary: ICE on self-referential struct member
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dirtyepic at gentoo dot org
#include
struct node
{
node &parent;
};
void f()
{
std::vector v;
v.push_back({});
}
$ g++ -std=c++11 487010.cxx
g++: internal compiler error: Segmentation fault (program cc1plus)
ICE with trunk, 4.8.1, 4.7.3, and 4.6.4 with -std=c++0x. 4.5.4 correctly gives
an error.
[Bug tree-optimization/58640] New: wrong code (segfaults) at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58640
Bug ID: 58640
Summary: wrong code (segfaults) at -O3 on x86_64-linux-gnu
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 -O3 in
both 32-bit and 64-bit modes, resulting in a segfault.
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 20131005 (experimental) [trunk revision 203223] (GCC)
$
$ gcc-trunk -O2 small.c; a.out
$ gcc-4.8 -O3 small.c; a.out
$ gcc-trunk -O3 small.c; a.out
Segmentation fault (core dumped)
$
-
int a, b, c, d = 1, e;
static signed char
foo ()
{
int f, g = a;
for (f = 1; f < 3; f++)
for (; b < 1; b++)
{
if (d)
for (c = 0; c < 4; c++)
for (f = 0; f < 3; f++)
{
for (e = 0; e < 1; e++)
a = g;
if (f)
break;
}
else if (f)
continue;
return 0;
}
return 0;
}
int
main ()
{
foo ();
return 0;
}
