[Bug target/57310] [4.7/4.8/4.9 Regression] segfault with -O2 or higher on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57310 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Invalid.
[Bug c++/58627] [4.9 Regression] crash during compilation of boost testsuite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58627 Markus Trippelsdorf markus at trippelsdorf dot de changed: What|Removed |Added CC||jason at gcc dot gnu.org Component|tree-optimization |c++ --- Comment #2 from Markus Trippelsdorf markus at trippelsdorf dot de --- Started with r198099. The following patch apparently fixes the issue: diff --git a/gcc/cp/class.c b/gcc/cp/class.c index c587e55ac681..9547da539c57 100644 --- a/gcc/cp/class.c +++ b/gcc/cp/class.c @@ -7436,7 +7436,6 @@ resolve_address_of_overloaded_function (tree target_type, if (same_type_p (target_fn_type, static_fn_type (instantiation))) matches = tree_cons (instantiation, fn, matches); - ggc_free (targs); } /* Now, remove all but the most specialized of the matches. */
[Bug bootstrap/58666] New: make install after make bootstrap-lean fails starting with r202895
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58666 Bug ID: 58666 Summary: make install after make bootstrap-lean fails starting with r202895 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: krebbel at gcc dot gnu.org After bootstrap-lean the installation process tries to rebuild several files with the host GCC and -Werror which fails: /build/gcc-head/gcc/langhooks.c: In function ‘void lhd_print_error_function(diagnostic_context*, const char*, diagnostic_info*)’: /build/gcc-head/gcc/langhooks.c:457:41: error: unknown conversion type character ‘r’ in format [-Werror=format] /build/gcc-head/gcc/langhooks.c:457:41: error: format ‘%d’ expects argument of type ‘int’, but argument 5 has type ‘const char*’ [-Werror=format] /build/gcc-head/gcc/langhooks.c:457:41: error: unknown conversion type character ‘R’ in format [-Werror=format] /build/gcc-head/gcc/langhooks.c:457:41: error: too many arguments for format [-Werror=format-extra-args] /build/gcc-head/gcc/langhooks.c:462:31: error: unknown conversion type character ‘r’ in format [-Werror=format] /build/gcc-head/gcc/langhooks.c:462:31: error: format ‘%d’ expects argument of type ‘int’, but argument 5 has type ‘const char*’ [-Werror=format] /build/gcc-head/gcc/langhooks.c:462:31: error: unknown conversion type character ‘R’ in format [-Werror=format] /build/gcc-head/gcc/langhooks.c:462:31: error: too many arguments for format [-Werror=format-extra-args] At global scope: cc1plus: error: unrecognized command line option -Wno-narrowing [-Werror] cc1plus: all warnings being treated as errors The output comes from an s390x build but similiar errors can be observed on x86-64: cc1plus: warnings being treated as errors /home/andreas/clean/gcc-head/gcc/attribs.c: In function ‘tree_node* decl_attributes(tree_node**, tree_node*, int)’: /home/andreas/clean/gcc-head/gcc/attribs.c:428: error: unknown conversion type character ‘E’ in format /home/andreas/clean/gcc-head/gcc/attribs.c:428: error: too many arguments for format /home/andreas/clean/gcc-head/gcc/attribs.c:432: error: unknown conversion type character ‘E’ in format /home/andreas/clean/gcc-head/gcc/attribs.c:432: error: unknown conversion type character ‘E’ in format /home/andreas/clean/gcc-head/gcc/attribs.c:432: error: too many arguments for format /home/andreas/clean/gcc-head/gcc/attribs.c:441: error: unknown conversion type character ‘E’ in format /home/andreas/clean/gcc-head/gcc/attribs.c:441: error: too many arguments for format /home/andreas/clean/gcc-head/gcc/attribs.c:473: error: unknown conversion type character ‘E’ in format /home/andreas/clean/gcc-head/gcc/attribs.c:473: error: too many arguments for format /home/andreas/clean/gcc-head/gcc/attribs.c:525: error: unknown conversion type character ‘E’ in format /home/andreas/clean/gcc-head/gcc/attribs.c:525: error: too many arguments for format In file included from /home/andreas/clean/gcc-head/gcc/tree-core.h:27, from /home/andreas/clean/gcc-head/gcc/tree.h:23, from /home/andreas/clean/gcc-head/gcc/attribs.c:24: /home/andreas/clean/gcc-head/gcc/vec.h: In static member function ‘static size_t vecT, A, vl_embed::embedded_size(unsigned int) [with T = scoped_attributes, A = va_heap]’: /home/andreas/clean/gcc-head/gcc/vec.h:298: instantiated from ‘static void va_heap::reserve(vecT, va_heap, vl_embed*, unsigned int, bool) [with T = scoped_attributes]’ /home/andreas/clean/gcc-head/gcc/vec.h:1480: instantiated from ‘bool vecT, A, vl_ptr::reserve(unsigned int, bool) [with T = scoped_attributes, A = va_heap]’ /home/andreas/clean/gcc-head/gcc/vec.h:1575: instantiated from ‘T* vecT, A, vl_ptr::safe_push(const T) [with T = scoped_attributes, A = va_heap]’ /home/andreas/clean/gcc-head/gcc/attribs.c:143: instantiated from here /home/andreas/clean/gcc-head/gcc/vec.h:1103: error: invalid access to non-static data member ‘vecscoped_attributes, va_heap, vl_embed::m_vecdata’ of NULL object /home/andreas/clean/gcc-head/gcc/vec.h:1103: error: (perhaps the ‘offsetof’ macro was used incorrectly) At global scope: cc1plus: error: unrecognized command line option -Wno-narrowing make[2]: *** [attribs.o] Error 1 make[2]: Leaving directory `/home/andreas/clean/gcc-head-build/gcc' make[1]: *** [install-gcc] Error 2 make[1]: Leaving directory `/home/andreas/clean/gcc-head-build' make: *** [install] Error 2
[Bug tree-optimization/58530] [4.9 Regression] crash in get_combined_adhoc_loc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58530 David Binderman dcb314 at hotmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from David Binderman dcb314 at hotmail dot com --- Seems to be fixed by 20131009, revision 203302
[Bug bootstrap/58666] make install after make bootstrap-lean fails starting with r202895
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58666 --- Comment #1 from Mario Held mario.held at de dot ibm.com --- Same behavior seen on my systems. A 'make' of GCC (s390x) sucessful, ' make bootstrap-lean' fails.
[Bug tree-optimization/50417] regression: memcpy with known alignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50417
Georg-Johann Lay gjl at gcc dot gnu.org changed:
What|Removed |Added
Keywords||missed-optimization
Target|sh*-*-* arm*-*-* avr*-*-* |sh*-*-* arm*-*-*
CC||gjl at gcc dot gnu.org
--- Comment #4 from Georg-Johann Lay gjl at gcc dot gnu.org ---
(In reply to Richard Biener from comment #1)
The middle-end does not know anything about the parameters alignment.
But the following code will use SImode load / store, even on strict-alignment
backends
void test (const int* a, int* b)
{
*b = *a;
}
If SImode operations are in order here, why not in memcpy et al. provided it is
feeded with int*?
In the case where an unaligned pointer is used in *b = *a and this causes, e.g.
a trap, this is in order. Similar should apply for memcpy on strict-alignment
machines if it gets an unaligned int* for example and the size is a multiple of
the alignment requirement.
BTW: AVR is an 8-bit machine that copies in chunks of 1 byte, this applies also
for 4.5 and older. avr-gcc is /not/ a strict alignment backend. Thul removed
from the targets.
[Bug tree-optimization/58539] [4.7/4.8 Regression] ICE with segfault at -O3 with -g enabled on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58539 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Oct 9 09:26:48 2013 New Revision: 203307 URL: http://gcc.gnu.org/viewcvs?rev=203307root=gccview=rev Log: Backport from mainline 2013-09-26 Richard Biener rguent...@suse.de PR tree-optimization/58539 * tree-vect-loop.c (vect_create_epilog_for_reduction): Honor the fact that debug statements are not taking part in loop-closed SSA construction. * gcc.dg/torture/pr58539.c: New testcase. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/torture/pr58539.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/tree-vect-loop.c
[Bug fortran/31593] Invariant DO loop variables and subroutines
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31593 --- Comment #45 from Dominique d'Humieres dominiq at lps dot ens.fr --- Anything left to fix in this PR?
[Bug debug/58663] entry-value: missing DW_TAG_GNU_call_site for libasan calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58663 Jan Kratochvil jan.kratochvil at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Jan Kratochvil jan.kratochvil at redhat dot com --- I forgot DW_TAG_GNU_call_site is only generated with -O. Just in such case it is still not resolved but it is because the value is not saved in the caller: (gdb) p addr Cannot find matching parameter at DW_TAG_GNU_call_site 0x4007c6 at main $1 = optimized out 0: DW_OP_GNU_entry_value 2: DW_OP_reg5 [$rdi] + 2600: Abbrev Number: 10 (DW_TAG_GNU_call_site) 601 DW_AT_low_pc : 0x4007c6 609 DW_AT_abstract_origin: 0x65d [no parameters]
[Bug fortran/58667] New: Add -Wfloat-conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58667 Bug ID: 58667 Summary: Add -Wfloat-conversion Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org When C/C++ support -Wfloat-conversion, it might make sense to support it also in Fortran for flag compatibility. See PR53001 and http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00576.html
[Bug middle-end/58570] [4.9 Regression] wrong code for bitfields at -O2 and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58570 --- Comment #13 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Author: ebotcazou Date: Wed Oct 9 12:59:02 2013 New Revision: 203315 URL: http://gcc.gnu.org/viewcvs?rev=203315root=gccview=rev Log: PR middle-end/58570 * tree-ssa-alias.c (nonoverlapping_component_refs_of_decl_p): Return false if both components are bitfields. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr58570.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-alias.c
[Bug c/20318] RFE: add attribute to specify that a function never returns NULL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20318
--- Comment #10 from Marc Glisse glisse at gcc dot gnu.org ---
Author: glisse
Date: Wed Oct 9 13:03:13 2013
New Revision: 203316
URL: http://gcc.gnu.org/viewcvs?rev=203316root=gccview=rev
Log:
2013-10-09 Marc Glisse marc.gli...@inria.fr
PR tree-optimization/20318
gcc/c-family/
* c-common.c (handle_returns_nonnull_attribute): New function.
(c_common_attribute_table): Add returns_nonnull.
gcc/
* doc/extend.texi (returns_nonnull): New function attribute.
* fold-const.c (tree_expr_nonzero_warnv_p): Look for returns_nonnull
attribute.
* tree-vrp.c (gimple_stmt_nonzero_warnv_p): Likewise.
(stmt_interesting_for_vrp): Accept all GIMPLE_CALL.
gcc/testsuite/
* c-c++-common/pr20318.c: New file.
* gcc.dg/tree-ssa/pr20318.c: New file.
Added:
trunk/gcc/testsuite/c-c++-common/pr20318.c (with props)
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr20318.c (with props)
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/doc/extend.texi
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vrp.c
Propchange: trunk/gcc/testsuite/c-c++-common/pr20318.c
('svn:eol-style' added)
Propchange: trunk/gcc/testsuite/c-c++-common/pr20318.c
('svn:keywords' added)
Propchange: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr20318.c
('svn:eol-style' added)
Propchange: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr20318.c
('svn:keywords' added)
[Bug middle-end/58570] [4.9 Regression] wrong code for bitfields at -O2 and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58570 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #14 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Thanks for reporting the problem.
[Bug c++/58635] [c++11] ICE with __transaction_atomic and noexcept(false)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58635 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Wed Oct 9 14:51:28 2013 New Revision: 203323 URL: http://gcc.gnu.org/viewcvs?rev=203323root=gccview=rev Log: PR c++/58635 cp/ * semantics.c (finish_return_stmt): Return error_mark_node when error_operand_p of the expr is true. (build_transaction_expr): Check for EXPR_P before setting the expr location. testsuite/ * g++.dg/tm/pr58635-1.C: New test. * g++.dg/tm/pr58635-2.C: New test. Added: trunk/gcc/testsuite/g++.dg/tm/pr58635-1.C trunk/gcc/testsuite/g++.dg/tm/pr58635-2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog
[Bug c++/58635] [c++11] ICE with __transaction_atomic and noexcept(false)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58635 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/58654] [4.9 Regression] ICE: abort compiling libstdc++-v3/src/c ++98/sstream-inst.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58654 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from John David Anglin danglin at gcc dot gnu.org --- Seems to be fixed (r203300).
[Bug target/58668] New: [arm with hardfp ABI]: internal compiler error: in cond_exec_process_insns, at ifcvt.c:339
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58668 Bug ID: 58668 Summary: [arm with hardfp ABI]: internal compiler error: in cond_exec_process_insns, at ifcvt.c:339 Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sebastien at debian dot org Created attachment 30969 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30969action=edit Preprocessed source to replicate the ICE See the attached preprocessed source for replicating the ICE. Here are the compiler specs: COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.8/lto-wrapper Target: arm-linux-gnueabihf Configured with: ../src/configure -v --with-pkgversion='Debian 4.8.1-10' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libitm --disable-libquadmath --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-armhf/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-armhf --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-armhf --with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-sjlj-exceptions --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf Thread model: posix gcc version 4.8.1 (Debian 4.8.1-10) Note that I was also able to replicate the ICE with a GCC snapshot from Sept 17, 2013. On the contrary, GCC 4.7.3 is not affected.
[Bug java/58669] New: does not detect all cpu cores/threads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58669
Bug ID: 58669
Summary: does not detect all cpu cores/threads
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
Assignee: unassigned at gcc dot gnu.org
Reporter: folkert at vanheusden dot com
Created attachment 30970
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30970action=edit
example code
When a java program compiled with gcj asks how many processing units are in the
system, it always returns 1.
folkert@belle:~$ cat test2.java
class test2 {
public static void main(String [] args) {
System.out.println( +
Runtime.getRuntime().availableProcessors());
}
}
folkert@belle:~$ javac test2.java
folkert@belle:~$ java test2
12
folkert@belle:~$ gcj --main=test2 test2.java
folkert@belle:~$ ./a.out
1
[Bug java/58669] does not detect all cpu cores/threads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58669
Andrew John Hughes gnu_andrew at member dot fsf.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-10-09
CC||gnu_andrew at member dot
fsf.org
Ever confirmed|0 |1
--- Comment #1 from Andrew John Hughes gnu_andrew at member dot fsf.org ---
jint
java::lang::Runtime::availableProcessors (void)
{
// FIXME: find the real value.
return 1;
}
:)
[Bug java/58669] does not detect all cpu cores/threads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58669 --- Comment #2 from Andrew John Hughes gnu_andrew at member dot fsf.org --- This is easily fixed with sysconf(_SC_NPROCESSORS_ONLN);
[Bug java/58669] does not detect all cpu cores/threads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58669 --- Comment #3 from Folkert van Heusden folkert at vanheusden dot com --- Did some googling and with appropriate #ifdefs it should be at least on linux possible to retrieve this value: sysconf(_SC_NPROCESSORS_ONLN); If that function can't figure it out, it will return '1' which is somewhat sensible. On http://stackoverflow.com/questions/150355/programmatically-find-the-number-of-cores-on-a-machine I found a whole list of implementations for windows, *bsd, macos, aix, well I think all relevant platforms. Also http://stackoverflow.com/questions/4586405/get-number-of-cpus-in-linux-using-c gives some ideas. If there's any further help I can do; let me know.
[Bug target/58668] [arm with hardfp ABI]: internal compiler error: in cond_exec_process_insns, at ifcvt.c:339
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58668 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #1 from ktkachov at gcc dot gnu.org --- Hmmm... I can't seem to reproduce it with current trunk and 4.8.2
[Bug middle-end/58670] New: asm goto miscompilation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58670
Bug ID: 58670
Summary: asm goto miscompilation
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
__attribute__((noinline, noclone)) int
foo (int a, int b)
{
if (a)
return -3;
asm volatile goto (bts $1, %0; jc %l[lab] : : m (b) : memory : lab);
return 0;
lab:
return 0;
}
int
main ()
{
if (foo (1, 0) != -3 || foo (0, 3) != 0 || foo (0, 0) != 0)
__builtin_abort ();
return 0;
}
is miscompiled, *.optimized dump looks fine, but expansion looks wrong, perhaps
during expansion we don't handle the case of at least one asm goto labels
pointing to the fallthru block.
[Bug java/58669] does not detect all cpu cores/threads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58669 --- Comment #4 from Andrew John Hughes gnu_andrew at member dot fsf.org --- Yes, I just said that above. I'll propose a patch when I get chance.
[Bug java/58669] does not detect all cpu cores/threads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58669 --- Comment #5 from Andrew John Hughes gnu_andrew at member dot fsf.org --- Thanks for reporting this. I'll let you know when a fix is committed.
[Bug middle-end/21718] real.c rounding not perfect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21718 --- Comment #19 from Rick Regan exploringbinary at gmail dot com --- I've looked into this and found that real.c/real.h use a precision of SIGNIFICAND_BITS, which is dependent on an architecture-dependent value called HOST_BITS_PER_LONG. In addition, SIGNIFICAND_BITS limits the precision to 192 bits on a 64-bit system, and I was able to find an example of an incorrect conversion there: 5.0216813883093451685872615018317116712748411717802652598273e58. (Please see my article http://www.exploringbinary.com/gcc-conversions-are-incorrect-architecture-or-otherwise/ for details.)
[Bug middle-end/58670] asm goto miscompilation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58670 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- I see multiple issues: 1) commit_one_edge_insertion doesn't seem to cope with asm goto, I think asm goto with only labels pointing to the fallthru bb's labels can happen both for the single_pred_p (e-dest) case, as well as the single_succ_p case. JUMP_P in that case would be true, but we certainly can't insert in that case before the jump (aka asm goto). 2) during expansion, we apparently emit some further insns (some noop pseudo copy and unconditional jump) directly after asm goto into the same bb, then commit these edge insertions (so commit_one_edge_insertion actually doesn't see the asm goto at the end of the bb, but an unconditional jump) and only later on split the bb in find_many_sub_basic_blocks.
[Bug fortran/48923] Type with Allocatable Length Character Component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48923 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||burnus at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org --- Close as FIXED as gfortran 4.8 and 4.9 no longer crash but print: character (len = :), allocatable :: mail 1 Error: Deferred-length character component 'mail' at (1) is not yet supported For the implementation of that Fortran 2003 feature: That's tracked at PR 51976
[Bug c++/58207] [4.7/4.8/4.9 Regression] ICE in sort_constexpr_mem_initializers due to out of bounds vector access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58207 Volker Reichelt reichelt at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-invalid-code Known to work||4.5.0, 4.6.0, 4.7.0, 4.7.1, ||4.7.2 Target Milestone|4.8.2 |4.7.4 Summary|[4.8/4.9 Regression] ICE in |[4.7/4.8/4.9 Regression] |sort_constexpr_mem_initiali |ICE in |zers due to out of bounds |sort_constexpr_mem_initiali |vector access |zers due to out of bounds ||vector access Known to fail||4.7.3, 4.8.0, 4.9.0 --- Comment #4 from Volker Reichelt reichelt at gcc dot gnu.org --- It's actually a regression in GCC 4.7.3.
[Bug c++/58671] New: ICE with thread_local and self-referential variable initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58671 Bug ID: 58671 Summary: ICE with thread_local and self-referential variable initialization 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 line(compiled with -std=c++11) triggers an ICE since GCC 4.8.0 (when thread_local was introduced): == thread_local int i = i; == bug.cc:1:22: internal compiler error: in var_defined_without_dynamic_init, at cp/decl2.c:2836 thread_local int i = i; ^ 0x60966a var_defined_without_dynamic_init ../../gcc/gcc/cp/decl2.c:2836 0x60966a var_needs_tls_wrapper ../../gcc/gcc/cp/decl2.c:2852 0x6164db get_tls_wrapper_fn(tree_node*) ../../gcc/gcc/cp/decl2.c:2950 0x6b612f finish_id_expression(tree_node*, tree_node*, tree_node*, cp_id_kind*, bool, bool, bool*, bool, bool, bool, bool, char const**, unsigned int) ../../gcc/gcc/cp/semantics.c:3387 0x63fc90 cp_parser_primary_expression ../../gcc/gcc/cp/parser.c:4539 0x641890 cp_parser_postfix_expression ../../gcc/gcc/cp/parser.c:5814 0x64405d cp_parser_unary_expression ../../gcc/gcc/cp/parser.c:7009 0x644c2f cp_parser_binary_expression ../../gcc/gcc/cp/parser.c:7701 0x6450ef cp_parser_assignment_expression ../../gcc/gcc/cp/parser.c:7937 0x645546 cp_parser_assignment_expression ../../gcc/gcc/cp/parser.c:7987 0x645546 cp_parser_constant_expression ../../gcc/gcc/cp/parser.c:8197 0x6512ae cp_parser_init_declarator ../../gcc/gcc/cp/parser.c:16530 0x65187f cp_parser_simple_declaration ../../gcc/gcc/cp/parser.c:10995 0x653700 cp_parser_block_declaration ../../gcc/gcc/cp/parser.c:10876 0x65c73e cp_parser_declaration ../../gcc/gcc/cp/parser.c:10773 0x65b4aa cp_parser_declaration_seq_opt ../../gcc/gcc/cp/parser.c:10659 0x65cd76 cp_parser_translation_unit ../../gcc/gcc/cp/parser.c:3939 0x65cd76 c_parse_file() ../../gcc/gcc/cp/parser.c:28911 0x770903 c_common_parse_file() ../../gcc/gcc/c-family/c-opts.c:1046 Please submit a full bug report, [etc.]
[Bug c++/58672] New: ICE with thread_local and variable of broken class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58672
Bug ID: 58672
Summary: ICE with thread_local and variable of broken 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 invalid code snippet (compiled with -std=c++11) triggers an ICE
since GCC 4.8.0 (when thread_local was introduced):
==
struct A
{
A(int);
i;
};
thread_local A a(0);
==
bug.cc:4:3: error: 'i' does not name a type
i;
^
bug.cc: In function 'void __tls_init()':
bug.cc:7:16: internal compiler error: Segmentation fault
thread_local A a(0);
^
0xaefa5f crash_signal
../../gcc/gcc/toplev.c:335
0x7fa439 cgraph_create_function_alias(tree_node*, tree_node*)
../../gcc/gcc/cgraph.c:565
0x7fa51c cgraph_same_body_alias(cgraph_node*, tree_node*, tree_node*)
../../gcc/gcc/cgraph.c:594
0x617d7b handle_tls_init
../../gcc/gcc/cp/decl2.c:3976
0x617d7b cp_write_global_declarations()
../../gcc/gcc/cp/decl2.c:4171
Please submit a full bug report, [etc.]
[Bug target/58673] New: ICE in final_scan_insn for movti_ppc64 with base+offset address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58673
Bug ID: 58673
Summary: ICE in final_scan_insn for movti_ppc64 with
base+offset address
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: pthaugen at gcc dot gnu.org
CC: bergner at gcc dot gnu.org, dje at gcc dot gnu.org,
meissner at gcc dot gnu.org
Host: powerpc64-linux
Target: powerpc64-linux
Build: powerpc64-linux
Created attachment 30971
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30971action=edit
testcase
Seeing the following ICE with trunk (r203249). Testcase reduced from CPU2000
benchmark 176.gcc. Adding the option -mvsx-timode results in successful
compile.
[pthaugen@igoo p8_spec_errors]$ /home/pthaugen/install/gcc/trunk/bin/gcc -c
-m64 -O1 -mcpu=power8 bc-optab.c
bc-optab.c: In function ‘bc_expand_binary_operation’:
bc-optab.c:74:1: error: could not split insn
}
^
(insn 40 77 78 (set (reg:TI 10 10 [155])
(mem:TI (plus:DI (reg:DI 9 9)
(const_int 112 [0x70])) [0 S16 A64])) bc-optab.c:71 508
{*movti_ppc64}
(expr_list:REG_DEAD (reg:DI 9 9)
(expr_list:REG_EQUIV (mem:TI (plus:DI (reg/f:DI 1 1)
(const_int 112 [0x70])) [0 S16 A64])
(nil
bc-optab.c:74:1: internal compiler error: in final_scan_insn, at final.c:2949
0x105b23c3 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/pthaugen/src/gcc/trunk/gcc/gcc/rtl-error.c:109
0x1034ecfb final_scan_insn(rtx_def*, _IO_FILE*, int, int, int*)
/home/pthaugen/src/gcc/trunk/gcc/gcc/final.c:2949
0x1034f1e7 final(rtx_def*, _IO_FILE*, int)
/home/pthaugen/src/gcc/trunk/gcc/gcc/final.c:2019
0x1034f4df rest_of_handle_final
/home/pthaugen/src/gcc/trunk/gcc/gcc/final.c:4424
0x1034f4df execute
/home/pthaugen/src/gcc/trunk/gcc/gcc/final.c:4499
Please submit a full bug report,
[Bug target/58673] ICE in final_scan_insn for movti_ppc64 with base+offset address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58673
--- Comment #1 from Pat Haugen pthaugen at gcc dot gnu.org ---
Created attachment 30972
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30972action=edit
testcase
Another similar example, but this one is on a store to memory instead of a
load. Reduced from CPU2006 benchmark 435.gromacs.
[pthaugen@igoo p8_spec_errors]$ /home/pthaugen/install/gcc/trunk/bin/gcc -c
-m64 -O3 -funroll-loops -mcpu=power8 do_gct.c
...
do_gct.c:208:1: error: could not split insn
}
^
(insn 90 93 94 (set (mem/c:TI (plus:DI (reg:DI 6 6)
(const_int 368 [0x170])) [2 leg+0 S16 A128])
(reg:TI 10 10 [423])) do_gct.c:93 508 {*movti_ppc64}
(expr_list:REG_DEAD (reg:DI 6 6)
(expr_list:REG_DEAD (reg:TI 10 10 [423])
(nil
do_gct.c:208:1: internal compiler error: in final_scan_insn, at final.c:2949
0x105b23c3 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/pthaugen/src/gcc/trunk/gcc/gcc/rtl-error.c:109
0x1034ecfb final_scan_insn(rtx_def*, _IO_FILE*, int, int, int*)
/home/pthaugen/src/gcc/trunk/gcc/gcc/final.c:2949
0x1034f1e7 final(rtx_def*, _IO_FILE*, int)
/home/pthaugen/src/gcc/trunk/gcc/gcc/final.c:2019
0x1034f4df rest_of_handle_final
/home/pthaugen/src/gcc/trunk/gcc/gcc/final.c:4424
0x1034f4df execute
/home/pthaugen/src/gcc/trunk/gcc/gcc/final.c:4499
Please submit a full bug report,
[Bug c++/58674] New: [4.8/4.9 Regression] [c++11] ICE with template using declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58674
Bug ID: 58674
Summary: [4.8/4.9 Regression] [c++11] ICE with template using
declaration
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following invalid code snippet (compiled with -std=c++11) triggers an ICE
since GCC 4.8.0:
templateint struct A {};
templateint N using B = AN;
templatetypename T struct C
{
BT::i b;
};
struct X
{
static const int i;
};
CX c;
bug.cc: In substitution of 'templateint N using B = AN [with int N =
X::i]':
bug.cc:7:11: required from 'struct CX'
bug.cc:15:6: required from here
bug.cc:7:11: error: the value of 'X::i' is not usable in a constant expression
BT::i b;
^
bug.cc:12:20: note: 'X::i' was not initialized with a constant expression
static const int i;
^
bug.cc:7:11: note: in template argument for type 'int'
BT::i b;
^
bug.cc:7:11: internal compiler error: tree check: expected tree_vec, have
error_mark in get_innermost_template_args, at cp/pt.c:569
0xcec8da tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.c:9176
0x587845 tree_check
../../gcc/gcc/tree.h:2609
0x587845 get_innermost_template_args(tree_node*, int)
../../gcc/gcc/cp/pt.c:569
0x5d0585 instantiate_template_1
../../gcc/gcc/cp/pt.c:15042
0x5d0585 instantiate_template(tree_node*, tree_node*, int)
../../gcc/gcc/cp/pt.c:15117
0x5ac7bb instantiate_alias_template
../../gcc/gcc/cp/pt.c:15147
0x5ac7bb tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:11312
0x5bca41 tsubst_decl
../../gcc/gcc/cp/pt.c:10657
0x5ac634 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:11285
0x5d8fc1 instantiate_class_template_1
../../gcc/gcc/cp/pt.c:8952
0x5d8fc1 instantiate_class_template(tree_node*)
../../gcc/gcc/cp/pt.c:9216
0x66435b complete_type(tree_node*)
../../gcc/gcc/cp/typeck.c:132
0x554fa9 start_decl_1(tree_node*, bool)
../../gcc/gcc/cp/decl.c:4670
0x57edbd start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
../../gcc/gcc/cp/decl.c:4633
0x650fd8 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:16453
0x65187f cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:10995
0x653700 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:10876
0x65c73e cp_parser_declaration
../../gcc/gcc/cp/parser.c:10773
0x65b4aa cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:10659
0x65cd76 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:3939
Please submit a full bug report, [etc.]
[Bug target/58675] New: ICE in rs6000_secondary_reload_inner:15460, type = store
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58675 Bug ID: 58675 Summary: ICE in rs6000_secondary_reload_inner:15460, type = store Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: pthaugen at gcc dot gnu.org CC: bergner at gcc dot gnu.org, dje at gcc dot gnu.org, meissner at gcc dot gnu.org Host: powerpc64-linux Target: powerpc64-linux Build: powerpc64-linux Created attachment 30973 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30973action=edit Reduced testcase Hit the following trying to build cpu2000 benchmark 177.mesa with -mcpu=power8. [pthaugen@igoo p8_spec_errors]$ /home/pthaugen/install/gcc/trunk/bin/gcc -c -m64 -O1 -mcpu=power8 triangle.c rs6000_secondary_reload_inner:15460, type = store (parallel [ (set (mem/c:SF (plus:DI (plus:DI (reg/f:DI 1 1) (const_int 65536 [0x1])) (const_int -30152 [0x8a38])) [0 %sfp+35384 S4 A32]) (reg:SF 43 11)) (clobber (reg:DI 10 10)) ]) triangle.c: In function ‘lambda_textured_triangle’: triangle.c:443:1: internal compiler error: in rs6000_secondary_reload_fail, at config/rs6000/rs6000.c:15287 } ^ 0x109093e7 rs6000_secondary_reload_fail /home/pthaugen/src/gcc/trunk/gcc/gcc/config/rs6000/rs6000.c:15287 0x1093b3a3 rs6000_secondary_reload_inner(rtx_def*, rtx_def*, rtx_def*, bool) /home/pthaugen/src/gcc/trunk/gcc/gcc/config/rs6000/rs6000.c:15460 0x10a005eb gen_reload_sf_di_store(rtx_def*, rtx_def*, rtx_def*) /home/pthaugen/src/gcc/trunk/gcc/gcc/config/rs6000/vector.md:196 0x105a9e0f insn_gen_fn::operator()(rtx_def*, rtx_def*, rtx_def*) const /home/pthaugen/src/gcc/trunk/gcc/gcc/recog.h:285 0x105a9e0f emit_output_reload_insns /home/pthaugen/src/gcc/trunk/gcc/gcc/reload1.c:7696 0x105a9e0f do_output_reload /home/pthaugen/src/gcc/trunk/gcc/gcc/reload1.c:8006 0x105a9e0f emit_reload_insns /home/pthaugen/src/gcc/trunk/gcc/gcc/reload1.c:8074 0x105ad713 reload_as_needed /home/pthaugen/src/gcc/trunk/gcc/gcc/reload1.c:4649 0x105b1673 reload(rtx_def*, int) /home/pthaugen/src/gcc/trunk/gcc/gcc/reload1.c:1054 0x10484983 do_reload /home/pthaugen/src/gcc/trunk/gcc/gcc/ira.c:4698 0x10484983 rest_of_handle_reload /home/pthaugen/src/gcc/trunk/gcc/gcc/ira.c:4815 0x10484983 execute /home/pthaugen/src/gcc/trunk/gcc/gcc/ira.c:4844 Please submit a full bug report,
[Bug c++/58333] performance regression when using -std=c++0x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58333 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- I can reproduce with 4.6.x, but currently maintained branches are fine.
[Bug c++/50961] Fails to decay template function properly(?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50961 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-10-09 Ever confirmed|0 |1
[Bug fortran/58676] New: Intrinsic functions not considered pure actual arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58676 Bug ID: 58676 Summary: Intrinsic functions not considered pure actual arguments Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: ian_harvey at bigpond dot com The following example, when compiled with recent trunk: MODULE m IMPLICIT NONE CONTAINS SUBROUTINE sub(proc) INTERFACE PURE FUNCTION proc(x) IMPLICIT NONE REAL, INTENT(IN) :: x REAL :: proc END FUNCTION proc END INTERFACE PRINT *, proc(0.0) END SUBROUTINE sub END MODULE m PROGRAM p USE m IMPLICIT NONE INTRINSIC :: sin CALL sub(sin) !xxx END PROGRAM p results in an error Interface mismatch in dummy procedure 'proc' ... : Mismatch in PURE attribute, which I think (but maybe I've missed something) is erroneous. All standard intrinsic functions are pure (13.1p2) and elemental intrinsic functions may be associated with a dummy procedure (which cannot be elemental) (12.5.2.9p1) and `sin` is the relevant bullet-less specific for the generic sin (13.6). See also http://software.intel.com/en-us/forums/topic/476356 and perhaps pr41724.
[Bug c++/21802] Two-stage name lookup fails for operators
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21802 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- This bug likely needs an update: the testcase is still rejected, but likewise happens with ICC and clang.
[Bug middle-end/21718] real.c rounding not perfect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21718 --- Comment #20 from Vincent Lefèvre vincent-gcc at vinc17 dot net --- I suppose that for any 54-bit[*] odd integer multiplied by a power of two with a large exponent (in absolute value), some decimal numbers close to this value will be affected. [*] 54-bit for double, 25-bit for float, 65-bit for long double if x87 extended precision, 114-bit for long double if quadruple precision.
[Bug c++/56926] Crash (without ICE) while compiling Boost.Math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926 asmwarrior asmwarrior at gmail dot com changed: What|Removed |Added CC||asmwarrior at gmail dot com --- Comment #3 from asmwarrior asmwarrior at gmail dot com --- We meet this issue when building wxWidgets trunk and Codeblocks using PCH, see http://forums.codeblocks.org/index.php/topic,18383.msg125964.html#msg125964
[Bug middle-end/58677] New: wrong code at -O1 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58677
Bug ID: 58677
Summary: wrong code at -O1 on x86_64-linux-gnu
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk miscompiles the attached testcase on x86_64-linux at
(only) -O1 in 64-bit mode.
This is a regression from 4.8.x.
This one was quite tough to reduce. The attached testcase is the best I was
able to get so far.
$ 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 20131009 (experimental) [trunk revision 203302] (GCC)
$
$ gcc-trunk -O0 small.c; a.out
0
0
1
$ gcc-4.8 -O1 small.c; a.out
0
0
1
$ gcc-trunk -m32 -O1 small.c; a.out
0
0
1
$ clang-trunk -O1 small.c; a.out
0
0
1
$ gcc-trunk -O1 small.c; a.out
0
0
0
$
-
int printf (const char *, ...);
#pragma pack(1)
struct S
{
unsigned int f0:7;
int f1:19;
unsigned int f2:22;
int f3:25;
} k[6][8];
int a, b, c, e, h, l, m, n, o, *p = h, **q = p, r, s;
unsigned int d[256];
static void
fn1 ()
{
for (a = 0; a 256; a++)
d[a] = a;
}
static void
fn2 (unsigned int p1, char *p2, int p3)
{
e = d[e ^ p1];
printf (%s%X\n, p2, e);
}
static int *
fn3 (int p1, int p2)
{
for (s = 10; s 2; s = -6)
for (r = 0; r 6; r++)
for (n = 0; n 8; n++)
{
struct S t = { 1, -195, 321, 4857 };
k[r][n] = t;
}
return *q;
}
static int
fn4 ()
{
*q = fn3 (l, b);
return c;
}
int
main (int argc, char *argv[])
{
int v = 0;
if (argc == 2)
v = 1;
fn1 ();
fn4 ();
fn2 (m, , v);
fn2 (o, , v);
fn2 (k[0][0].f0, , v);
return 0;
}
[Bug c++/58671] [c++11] ICE with thread_local and self-referential variable initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58671 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-10-10 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed.
