[Bug target/61360] [4.10 Regression] ICE: in lra_update_insn_recog_data, at lra.c:1363 with -mtune=bdver4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61360 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||abensonca at gmail dot com --- Comment #7 from Markus Trippelsdorf trippels at gcc dot gnu.org --- *** Bug 61824 has been marked as a duplicate of this bug. ***
[Bug fortran/61824] ICE using dble() and -march=native
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61824 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #7 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Dup. *** This bug has been marked as a duplicate of bug 61360 ***
[Bug rtl-optimization/61801] sched2 miscompiles syscall sequence with -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61801 --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Thu Jul 17 07:47:19 2014 New Revision: 212738 URL: https://gcc.gnu.org/viewcvs?rev=212738root=gccview=rev Log: 2014-07-17 Richard Biener rguent...@suse.de PR rtl-optimization/61801 * sched-deps.c (sched_analyze_2): For ASM_OPERANDS and ASM_INPUT don't set reg_pending_barrier if it appears in a debug-insn. Modified: trunk/gcc/ChangeLog trunk/gcc/sched-deps.c
[Bug rtl-optimization/61801] sched2 miscompiles syscall sequence with -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61801 --- Comment #10 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Thu Jul 17 07:48:49 2014 New Revision: 212739 URL: https://gcc.gnu.org/viewcvs?rev=212739root=gccview=rev Log: 2014-07-17 Richard Biener rguent...@suse.de PR rtl-optimization/61801 * sched-deps.c (sched_analyze_2): For ASM_OPERANDS and ASM_INPUT don't set reg_pending_barrier if it appears in a debug-insn. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/sched-deps.c
[Bug rtl-optimization/61801] sched2 miscompiles syscall sequence with -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61801 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.10.0, 4.8.4, 4.9.2 Resolution|--- |FIXED Target Milestone|--- |4.8.4 Known to fail|4.10.0 | --- Comment #12 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug rtl-optimization/61801] sched2 miscompiles syscall sequence with -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61801 --- Comment #11 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Thu Jul 17 07:49:44 2014 New Revision: 212740 URL: https://gcc.gnu.org/viewcvs?rev=212740root=gccview=rev Log: 2014-07-17 Richard Biener rguent...@suse.de PR rtl-optimization/61801 * sched-deps.c (sched_analyze_2): For ASM_OPERANDS and ASM_INPUT don't set reg_pending_barrier if it appears in a debug-insn. Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/sched-deps.c
[Bug c/61779] gcc -Og fails with impossible constraint on legal C code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61779 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.9.2 Resolution|--- |FIXED Target Milestone|--- |4.9.2 --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- Fixed for 4.9.2.
[Bug c/61779] gcc -Og fails with impossible constraint on legal C code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61779 --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Thu Jul 17 07:53:16 2014 New Revision: 212741 URL: https://gcc.gnu.org/viewcvs?rev=212741root=gccview=rev Log: 2014-07-17 Richard Biener rguent...@suse.de Backport from mainline 2014-07-14 Richard Biener rguent...@suse.de PR tree-optimization/61779 * tree-ssa-copy.c (copy_prop_visit_cond_stmt): Always try simplifying a condition. * gcc.dg/tree-ssa/ssa-copyprop-2.c: New testcase. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/tree-ssa/ssa-copyprop-2.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/testsuite/ChangeLog branches/gcc-4_9-branch/gcc/tree-ssa-copy.c
[Bug c/61741] wrong code with -fno-strict-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61741 --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Thu Jul 17 07:57:30 2014 New Revision: 212742 URL: https://gcc.gnu.org/viewcvs?rev=212742root=gccview=rev Log: 2014-07-17 Richard Biener rguent...@suse.de Backport from mainline 2014-07-10 Richard Biener rguent...@suse.de PR c-family/61741 * c-c++-common/torture/pr61741.c: Use signed char. 2014-07-09 Richard Biener rguent...@suse.de PR c-family/61741 * c-gimplify.c (c_gimplify_expr): Gimplify self-modify expressions using unsigned arithmetic if overflow does not wrap instead of if overflow is undefined. * c-c++-common/torture/pr61741.c: New testcase. Added: branches/gcc-4_9-branch/gcc/testsuite/c-c++-common/pr61741.c Modified: branches/gcc-4_9-branch/gcc/c-family/ChangeLog branches/gcc-4_9-branch/gcc/c-family/c-gimplify.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug c/61741] wrong code with -fno-strict-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61741 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.9.2 Resolution|--- |FIXED Target Milestone|--- |4.9.2 --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org --- Fixed on trunk and 4.9 branch.
[Bug ipa/61085] [4.9/4.10 Regression] wrong code with -O2 -fno-early-inlining (maybe wrong devirtualization)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61085 --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org --- Can you open a new bug for that?
[Bug c++/61804] rejects-valid if parenthesized temporary is incremented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61804 --- Comment #2 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Thu Jul 17 08:32:18 2014 New Revision: 212743 URL: https://gcc.gnu.org/viewcvs?rev=212743root=gccview=rev Log: /cp 2014-07-17 Paolo Carlini paolo.carl...@oracle.com PR c++/61804 * parser.c (cp_parser_tokens_start_cast_expression): Return -1 for '++' and '--'. /testsuite 2014-07-17 Paolo Carlini paolo.carl...@oracle.com PR c++/61804 * g++.dg/parse/pr61804.C: New. Added: trunk/gcc/testsuite/g++.dg/parse/pr61804.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug c++/61804] rejects-valid if parenthesized temporary is incremented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61804 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.10.0 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed for 4.10.
[Bug ipa/61823] [4.10 Regression] gcc.dg/torture/pr43879_[12].c FAILs with -fno-inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61823
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2014-07-17
CC||hubicka at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Target Milestone|--- |4.10.0
Ever confirmed|0 |1
--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
We fail to process the tbl initializer in IPA PTA (I guess Honza broke this
again with on-demand DECL_INITIAL loading...)
But then when a function pointer is computed as pointing to anything we
fail to have sth like anything-called to make _all_ functions possibly
called receive the proper arguments. That's a pre-existing bug.
Honza, how do I update
/* If this is a global variable with an initializer and we are in
IPA mode generate constraints for it. */
if (DECL_INITIAL (decl)
vnode-definition)
{
which now fails?
[Bug tree-optimization/61822] gcc.dg/vect/vect-cond-reduc-1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61822
--- Comment #2 from Yuri Rumyantsev ysrumyan at gmail dot com ---
It looks like
/* { dg-require-effective-target vect_condition } */
directive was missed in vect-cond-reduc-1.c test.
I will fix it asap.
[Bug ipa/61823] [4.10 Regression] gcc.dg/torture/pr43879_[12].c FAILs with -fno-inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61823
--- Comment #2 from Jan Hubicka hubicka at ucw dot cz ---
/* If this is a global variable with an initializer and we are in
IPA mode generate constraints for it. */
if (DECL_INITIAL (decl)
vnode-definition)
{
which now fails?
You need to call varpool_get_constructor
Honza
[Bug libstdc++/60936] [4.9 Regression] Binary code bloat with std::string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60936 __vic d.v.a at ngs dot ru changed: What|Removed |Added Summary|Binary code bloat with |[4.9 Regression] Binary |std::string |code bloat with std::string Known to fail||4.9.0, 4.9.1 --- Comment #3 from __vic d.v.a at ngs dot ru --- 4.9.1 - same results
[Bug c++/61807] genautomata.c fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61807 --- Comment #2 from Rajesh y.rajesh.4683 at gmail dot com --- Hi, The default genautomata.c in the gcc-4.9.0 package doesn't have the explicit conversions at two places. I have made this change and have been able to get past this error. But I am just curious, if this change is valid and should be added to the src.
[Bug fortran/61819] ICE in gfc_conv_descriptor_data_get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61819 Salvatore Filippone sfilippone at uniroma2 dot it changed: What|Removed |Added Attachment #33127|0 |1 is obsolete|| --- Comment #3 from Salvatore Filippone sfilippone at uniroma2 dot it --- Created attachment 33129 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33129action=edit test case Reduced test case, giving: [sfilippo@jacobi leak-demo]$ gfortran -c foo-test-ice.f90 foo-test-ice.f90: In function ‘__final_foo_vector_field_mod_Vector_field’: foo-test-ice.f90:62:0: internal compiler error: in gfc_conv_descriptor_data_get, at fortran/trans-array.c:146 end module foo_vector_field_mod ^ 0x602fc5 gfc_conv_descriptor_data_get(tree_node*) ../../gcc/gcc/fortran/trans-array.c:146 0x60a24e gfc_array_deallocate(tree_node*, tree_node*, tree_node*, tree_node*, tree_node*, gfc_expr*) ../../gcc/gcc/fortran/trans-array.c:5350 0x674bea gfc_trans_deallocate(gfc_code*) ../../gcc/gcc/fortran/trans-stmt.c:5484 0x5ff2b7 trans_code ../../gcc/gcc/fortran/trans.c:1798 0x66a583 gfc_trans_if_1 ../../gcc/gcc/fortran/trans-stmt.c:989 0x670dea gfc_trans_if(gfc_code*) ../../gcc/gcc/fortran/trans-stmt.c:1020 0x5ff3a7 trans_code ../../gcc/gcc/fortran/trans.c:1736 0x672114 gfc_trans_simple_do ../../gcc/gcc/fortran/trans-stmt.c:1446 0x672114 gfc_trans_do(gfc_code*, tree_node*) ../../gcc/gcc/fortran/trans-stmt.c:1609 0x5ff37a trans_code ../../gcc/gcc/fortran/trans.c:1748 0x62966b gfc_generate_function_code(gfc_namespace*) ../../gcc/gcc/fortran/trans-decl.c:5765 0x600d61 gfc_generate_module_code(gfc_namespace*) ../../gcc/gcc/fortran/trans.c:1995 0x5bc031 translate_all_program_units ../../gcc/gcc/fortran/parse.c:4934 0x5bc031 gfc_parse_file() ../../gcc/gcc/fortran/parse.c:5144 0x5fa935 gfc_be_parse_file ../../gcc/gcc/fortran/f95-lang.c:212 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. [sfilippo@jacobi leak-demo]$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gnu/4.10/libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/usr/local/gnu/4.10 --enable-languages=c,c++,fortran --with-gmp=/home/travel/GNUBUILD/gmp --with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc --with-cloog=/home/travel/GNUBUILD/cloog Thread model: posix gcc version 4.10.0 20140716 (experimental) (GCC) [sfilippo@jacobi leak-demo]$
[Bug fortran/61819] ICE in gfc_conv_descriptor_data_get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61819 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-07-17 Ever confirmed|0 |1 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed on 4.9 and trunk (4.10).
[Bug fortran/61819] ICE in gfc_conv_descriptor_data_get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61819 --- Comment #5 from Salvatore Filippone sfilippone at uniroma2 dot it --- Code works with 4.8.3, so this is a regression.
[Bug fortran/61819] [4.9/4.10 Regression] ICE in gfc_conv_descriptor_data_get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61819 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||janus at gcc dot gnu.org Summary|ICE in |[4.9/4.10 Regression] ICE |gfc_conv_descriptor_data_ge |in |t |gfc_conv_descriptor_data_ge ||t --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr --- Code works with 4.8.3, so this is a regression. Confirmed: revision r206362 (2014-01-06) is OK, r206567 (2014-01-12) gives the ICE. Likely r206379 (pr59589).
[Bug libgomp/42616] OMP'ed loop inside pthread leads to crash.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42616 Varvara Rainchik varvara.s.rainchik at gmail dot com changed: What|Removed |Added CC||varvara.s.rainchik at gmail dot co ||m --- Comment #13 from Varvara Rainchik varvara.s.rainchik at gmail dot com --- I experience the same problem with Android NDK. TLS is not supported into Android, so I observe the similar test crash: [New LWP 18636] Program received signal SIGSEGV, Segmentation fault. [Switching to LWP 18636] (gdb) bt #0 gomp_icv (write=optimized out) at /s/ndk-toolchain/src/build/../gcc/gcc-4.8/libgomp/libgomp.h:393 #1 0x0804a3d7 in omp_set_num_threads (n=4) at /s/ndk-toolchain/src/build/../gcc/gcc-4.8/libgomp/env.c:657 #2 0x08049e70 in _thread (Id=0x1) at omp_test.c:19 #3 0x0804d119 in __pthread_start (arg=0x8087270) at bionic/libc/bionic/pthread_create.cpp:153 #4 0x08055e1a in __start_thread (fn=0x804d0e0 __pthread_start(void*), arg=0x8087270) at bionic/libc/bionic/clone.cpp:39 #5 0x0806b9b7 in __bionic_clone () at bionic/libc/arch-x86/bionic/__bionic_clone.S:42 I use android-ndk-r9d for x86 arch, gcc 4.8. Modified patch solves this issue.
[Bug libgomp/42616] OMP'ed loop inside pthread leads to crash.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42616 --- Comment #14 from Varvara Rainchik varvara.s.rainchik at gmail dot com --- Created attachment 33130 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33130action=edit Modified patch I will send this patch to gcc patches.
[Bug libgomp/42616] OMP'ed loop inside pthread leads to crash.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42616 --- Comment #15 from Varvara Rainchik varvara.s.rainchik at gmail dot com --- Created attachment 33131 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33131action=edit Correct patch
[Bug middle-end/61268] [4.10 regression] ICE in vt_expand_var_loc_chain, at var-tracking.c:8262
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61268 --- Comment #8 from Rainer Orth ro at gcc dot gnu.org --- Richard, from my POV, the patch is good to go. Thanks. Rainer
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #47 from Rainer Orth ro at gcc dot gnu.org --- Thomas, any progress on this one? SPARC bootstrap has been broken for almost two months now (yes, there's an out-of-tree workaround, but still). Thanks. Rainer
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #48 from Richard Biener rguenth at gcc dot gnu.org ---
Please provide preprocessed source for jcf-parse.c and instructions on how
to configure a cross compiler from x86_64-linux. Please also provide
disassembly around the failing place with enough context to spot it
in a cc1 generated output - best with an explanation what's wrong.
From what Thomas says in comment #46 it looks like for some unknown
reason a HI load from a 1-byte aligned address is emitted:
(insn 688 687 689 (set (reg:HI 482)
(mem:HI (reg/v/f:SI 189 [ ptr ]) [0 MEM[base: ptr_110, offset: 0B]+0 S2
A8])) /vol/gcc/src/hg/trunk/local/gcc/java/jcf-parse.c:1622 -1
(nil))
but as the bswap pass emits a plain MEM_REF with an aligned type we should
go through the following path in expand:
if (modifier != EXPAND_WRITE
modifier != EXPAND_MEMORY
!inner_reference_p
mode != BLKmode
align GET_MODE_ALIGNMENT (mode))
{
if ((icode = optab_handler (movmisalign_optab, mode))
!= CODE_FOR_nothing)
{
struct expand_operand ops[2];
/* We've already validated the memory, and we're creating a
new pseudo destination. The predicates really can't fail,
nor can the generator. */
create_output_operand (ops[0], NULL_RTX, mode);
create_fixed_operand (ops[1], temp);
expand_insn (icode, 2, ops);
temp = ops[0].value;
}
else if (SLOW_UNALIGNED_ACCESS (mode, align))
temp = extract_bit_field (temp, GET_MODE_BITSIZE (mode),
0, TYPE_UNSIGNED (TREE_TYPE (exp)),
(modifier == EXPAND_STACK_PARM
? NULL_RTX : target),
mode, mode);
that is, go through extract_bit_field (supposed sparc doesn't have
movmisalign and is SLOW_UNALIGNED_ACCESS for HImode and 8-bit align).
So we need to figure out why we don't go the above path or why
extract_bit_field gets things wrong.
[Bug c++/61825] New: [4.10 regression] g++.dg/cpp0x/static_assert9.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61825 Bug ID: 61825 Summary: [4.10 regression] g++.dg/cpp0x/static_assert9.C FAILs Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org Host: i386-pc-solaris2.11, sparc-sun-solaris2.11, x86_64-unknown-linux-gnu Target: i386-pc-solaris2.11, sparc-sun-solaris2.11, x86_64-unknown-linux-gnu Build: i386-pc-solaris2.11, sparc-sun-solaris2.11, x86_64-unknown-linux-gnu Between 20140711 and 20140716, the ++.dg/cpp0x/static_assert9.C testcase start to FAIL on at least Solaris/x86, Solaris/SPARC, and Linux/x86: FAIL: g++.dg/cpp0x/static_assert9.C -std=c++11 (test for excess errors) FAIL: g++.dg/cpp0x/static_assert9.C -std=c++1y (test for excess errors) Excess errors: /vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/cpp0x/static_assert9.C:5:1: error: non-constant condition for static assertion /vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/cpp0x/static_assert9.C:5:1: error: '(f != 0u)' is not a constant expression This is a regression from 4.9. Rainer
[Bug c++/61825] [4.10 regression] g++.dg/cpp0x/static_assert9.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61825 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.10.0
[Bug fortran/61819] [4.9/4.10 Regression] ICE in gfc_conv_descriptor_data_get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61819 --- Comment #7 from Salvatore Filippone sfilippone at uniroma2 dot it --- The original code leaks memory like a sieve, and looks suspiciously similar to PR55603. It is just possible that the whole area of function results needs to be reviewed (I guess that would be no small task) Salvatore
[Bug fortran/60922] [4.9/4.10 regression] Memory leak with INTENT(OUT) CLASS argument w/ allocatable CLASS components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60922 --- Comment #4 from Salvatore Filippone sfilippone at uniroma2 dot it --- Looking at the original code of PR 61819, it is quite possible that the real culprit are CLASS() ALLOCATABLE components, not necessarily the result itself (being allocatable). Salvatore
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #49 from thopre01 at gcc dot gnu.org --- (In reply to Richard Biener from comment #48) From what Thomas says in comment #46 it looks like for some unknown reason a HI load from a 1-byte aligned address is emitted: Yep that's it. Just look at log for expand in the archive Rainer posted the link to on this bug report and search for :1622. In the last step of gimple (optimized) we can just see a single load. The log doesn't show the alignment of a given load but from the code it should be correct. Best regards.
[Bug middle-end/61826] [4.10 regression] gcc.dg/pr44024.c UNRESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61826 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.10.0
[Bug middle-end/61826] New: [4.10 regression] gcc.dg/pr44024.c UNRESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61826 Bug ID: 61826 Summary: [4.10 regression] gcc.dg/pr44024.c UNRESOLVED Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: hubicka at gcc dot gnu.org Host: i386-pc-solaris2.11, sparc-sun-solaris2.11, x86_64-unknown-linux-gnu Target: i386-pc-solaris2.11, sparc-sun-solaris2.11, x86_64-unknown-linux-gnu Build: i386-pc-solaris2.11, sparc-sun-solaris2.11, x86_64-unknown-linux-gnu Between 20140711 and 20140716, the gcc.dg/pr44024.c testcase became UNRESOLVED. gcc.log shows PASS: gcc.dg/pr44024.c (test for excess errors) gcc.dg/pr44024.c: dump file does not exist UNRESOLVED: gcc.dg/pr44024.c scan-tree-dump-not ccp1 foo and indeed -fdump-tree-ccp1 dumps nothing here, unlike -fdump-tree-original before this change: 2014-07-13 Jan Hubicka hubi...@ucw.cz * gcc.dg/pr36901.h: Simplify because non-zero symbol folding no longer happens during parsing. * gcc.dg/pr44024.c: Update template. This is a regression from 4.9. Rainer
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|thopre01 at gcc dot gnu.org|rguenth at gcc dot gnu.org --- Comment #50 from Richard Biener rguenth at gcc dot gnu.org --- Ah, we also expand one from a TARGET_MEM_REF: ;; basic block 76, loop depth 2 ;;pred: 79 load_dst_215 = MEM[base: ptr_110, offset: 0B]; and TARGET_MEM_REF only handles the movmisalign case. So it's either IVOPTs not punting properly here (it does for unaligned accesses - grep for STRICT_ALIGNMENT) or we need to put a bitfield extraction case into TARGET_MEM_REF expansion (IMHO that's missing anyway, IVOPTs is too much pessimized by not considering this). I'll fix it somewhen after the cauldron unless somebody beats me to it.
[Bug target/61827] New: gcc.target/i386/fuse-caller-save-xmm.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61827 Bug ID: 61827 Summary: gcc.target/i386/fuse-caller-save-xmm.c FAILs Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: vries at gcc dot gnu.org Host: i386-pc-solaris2.11, x86_64-unknown-linux-gnu Target: i386-pc-solaris2.11, x86_64-unknown-linux-gnu Build: i386-pc-solaris2.11, x86_64-unknown-linux-gnu The new gcc.target/i386/fuse-caller-save-xmm.c testcase FAILs in various different ways on different targets: * On Solaris 11/x86 with Sun as, there can be no cfi directives since that assembler doesn't fully support them yet: FAIL: gcc.target/i386/fuse-caller-save-xmm.c scan-assembler-times .cfi_def_cfa_offset 16 1 FAIL: gcc.target/i386/fuse-caller-save-xmm.c scan-assembler-times .cfi_def_cfa_offset 32 1 for both 32 and 64-bit. * On Solaris 11/x86 with gas, I see the same failures although cfi directives are used. * On Linux/x86_64, I see FAIL: gcc.target/i386/fuse-caller-save-xmm.c scan-assembler-times .cfi_def_cfa_offset 32 1 for 32-bit only. In the 32-bit .s file, I find .cfi_def_cfa_offset 16 .cfi_def_cfa_offset 4 compared to 64-bit .cfi_def_cfa_offset 16 .cfi_def_cfa_offset 8 .cfi_def_cfa_offset 32 .cfi_def_cfa_offset 8 Rainer
[Bug target/61827] gcc.target/i386/fuse-caller-save-xmm.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61827 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.10.0
[Bug middle-end/61828] New: gcc.dg/strlenopt-8.c XPASSes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61828 Bug ID: 61828 Summary: gcc.dg/strlenopt-8.c XPASSes Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: rguenth at gcc dot gnu.org Host: sparc-sun-solaris2.11 Target: sparc-sun-solaris2.11 Build: sparc-sun-solaris2.11 Between 20140711 and 20140716, gcc.dg/strlenopt-8.c started to XPASS on Solaris/SPARC due to this patch: 2014-07-11 Richard Biener rguent...@suse.de PR middle-end/61473 * gcc.dg/memmove-4.c: New testcase. * gcc.dg/strlenopt-8.c: XFAIL. Rainer
[Bug middle-end/61828] gcc.dg/strlenopt-8.c XPASSes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61828 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.10.0
[Bug target/61827] gcc.target/i386/fuse-caller-save-xmm.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61827 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Target|i386-pc-solaris2.11,|i386-pc-solaris2.11, |x86_64-unknown-linux-gnu|x86_64-unknown-linux-gnu, ||*-*-darwin* Status|UNCONFIRMED |NEW Last reconfirmed||2014-07-17 CC||iains at gcc dot gnu.org Host|i386-pc-solaris2.11,|i386-pc-solaris2.11, |x86_64-unknown-linux-gnu|x86_64-unknown-linux-gnu, ||*-*-darwin* Ever confirmed|0 |1 Build|i386-pc-solaris2.11,|i386-pc-solaris2.11, |x86_64-unknown-linux-gnu|x86_64-unknown-linux-gnu, ||*-*-darwin* --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Also fails on *-*-darwin* for the same reason as Solaris 11/x86 with Sun as: cfi directives not supported.
[Bug tree-optimization/61829] New: SEGV in fold_binary_loc for gcc.dg/graphite/isl-codegen-loop-dumping.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61829 Bug ID: 61829 Summary: SEGV in fold_binary_loc for gcc.dg/graphite/isl-codegen-loop-dumping.c Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: romangareev at gcc dot gnu.org Host: i386-pc-solaris2.11, sparc-sun-solaris2.11 Target: i386-pc-solaris2.11, sparc-sun-solaris2.11 Build: i386-pc-solaris2.11, sparc-sun-solaris2.11 Between 20140711 (r212451) and 20140716 (r212663), the gcc.dg/graphite/isl-codegen-loop-dumping.c testcase started to FAIL (32-bit only) on Solaris/x86 and SPARC: FAIL: gcc.dg/graphite/isl-codegen-loop-dumping.c (internal compiler error) FAIL: gcc.dg/graphite/isl-codegen-loop-dumping.c (test for excess errors) Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 1)] 0x084af7eb in fold_binary_loc (loc=0, code=MINUS_EXPR, type=0x0, op0=0xfac63528, op1=0xfac0458c) at /vol/gcc/src/hg/trunk/local/gcc/fold-const.c:10814 10814 !TYPE_OVERFLOW_TRAPS (type)) (gdb) where #0 0x084af7eb in fold_binary_loc (loc=0, code=MINUS_EXPR, type=0x0, op0=0xfac63528, op1=0xfac0458c) at /vol/gcc/src/hg/trunk/local/gcc/fold-const.c:10814 #1 0x084d3450 in fold_build2_stat_loc (loc=0, code=MINUS_EXPR, type=0x0, op0=0xfac63528, op1=0xfac0458c) at /vol/gcc/src/hg/trunk/local/gcc/fold-const.c:14988 #2 0x08bea952 in binary_op_to_tree (ip=..., expr=0x953a328, type=0x0) at /vol/gcc/src/hg/trunk/local/gcc/graphite-isl-ast-to-gimple.c:175 #3 gcc_expression_from_isl_expr_op (ip=..., expr=0x953a328, type=0x0) at /vol/gcc/src/hg/trunk/local/gcc/graphite-isl-ast-to-gimple.c:317 #4 gcc_expression_from_isl_expression (type=0x0, expr=0x953a328, ip=...) at /vol/gcc/src/hg/trunk/local/gcc/graphite-isl-ast-to-gimple.c:348 #5 0x08bea766 in binary_op_to_tree (ip=..., expr=0x9517968, type=0x0) at /vol/gcc/src/hg/trunk/local/gcc/graphite-isl-ast-to-gimple.c:164 #6 gcc_expression_from_isl_expr_op (ip=..., expr=0x9517968, type=0x0) at /vol/gcc/src/hg/trunk/local/gcc/graphite-isl-ast-to-gimple.c:317 #7 gcc_expression_from_isl_expression (type=0x0, expr=0x9517968, ip=...) at /vol/gcc/src/hg/trunk/local/gcc/graphite-isl-ast-to-gimple.c:348 #8 0x08beac55 in graphite_create_new_loop_guard (ip=..., ub=synthetic pointer, lb=synthetic pointer, type=synthetic pointer, node_for=0x949e178, entry_edge=0xfac63f00) at /vol/gcc/src/hg/trunk/local/gcc/graphite-isl-ast-to-gimple.c:501 #9 translate_isl_ast_node_for (ip=..., next_e=0xfac63f00, node=0x949e178, context_loop=0xfac0e6b4) at /vol/gcc/src/hg/trunk/local/gcc/graphite-isl-ast-to-gimple.c:536 #10 translate_isl_ast (context_loop=0xfac0e6b4, node=0x949e178, next_e=0xfac63f00, ip=...) at /vol/gcc/src/hg/trunk/local/gcc/graphite-isl-ast-to-gimple.c:558 #11 0x08beb246 in graphite_regenerate_ast_isl (scop=0x9513840) at /vol/gcc/src/hg/trunk/local/gcc/graphite-isl-ast-to-gimple.c:699 #12 0x08be65aa in graphite_transform_loops () at /vol/gcc/src/hg/trunk/local/gcc/graphite.c:304 #13 0x08be6632 in graphite_transforms (fun=0xfacb2000) at /vol/gcc/src/hg/trunk/local/gcc/graphite.c:333 #14 (anonymous namespace)::pass_graphite_transforms::execute (this=0x94a24b0, fun=0xfacb2000) at /vol/gcc/src/hg/trunk/local/gcc/graphite.c:413 #15 0x0864c2e0 in execute_one_pass (pass=0x94a24b0) at /vol/gcc/src/hg/trunk/local/gcc/passes.c:2149 #16 0x0864c85f in execute_pass_list_1 (pass=0x94a24b0) at /vol/gcc/src/hg/trunk/local/gcc/passes.c:2201 #17 0x0864c872 in execute_pass_list_1 (pass=0x94a2468) at /vol/gcc/src/hg/trunk/local/gcc/passes.c:2202 #18 0x0864c872 in execute_pass_list_1 (pass=0x94a2150) at /vol/gcc/src/hg/trunk/local/gcc/passes.c:2202 #19 0x0864c872 in execute_pass_list_1 (pass=0x94a14f0, pass@entry=0x94a1460) at /vol/gcc/src/hg/trunk/local/gcc/passes.c:2202 #20 0x0864c8bb in execute_pass_list (fn=0xfacb2000, pass=0x94a1460) at /vol/gcc/src/hg/trunk/local/gcc/passes.c:2212 #21 0x083c8c97 in expand_function (node=node@entry=0xfac071a8) at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:1786 #22 0x083cae98 in expand_all_functions () at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:1920 #23 compile () at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:2264 #24 0x083cb56b in finalize_compilation_unit () at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:2341 #25 0x0828f24b in c_write_global_declarations () at /vol/gcc/src/hg/trunk/local/gcc/c/c-decl.c:10463 #26 0x087028e5 in compile_file () at /vol/gcc/src/hg/trunk/local/gcc/toplev.c:562 #27 0x08704bec in do_compile () at /vol/gcc/src/hg/trunk/local/gcc/toplev.c:1946 #28 toplev_main (argc=19, argv=0xfeffe398) at
[Bug tree-optimization/61829] SEGV in fold_binary_loc for gcc.dg/graphite/isl-codegen-loop-dumping.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61829 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.10.0
[Bug fortran/61830] New: Memory leak with assignment to array of derived types with allocatable components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61830 Bug ID: 61830 Summary: Memory leak with assignment to array of derived types with allocatable components Product: gcc Version: 4.8.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: sfilippone at uniroma2 dot it Created attachment 33132 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33132action=edit test case Hi, The attached code shows the problem. When I started investigating I was using 4.10 but I ran into PR61819 while reducing the test case. With 4.8.3 I get the following: [sfilippo@jacobi runs]$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gnu/4.8.3/libexec/gcc/x86_64-unknown-linux-gnu/4.8.3/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.8.3/configure --prefix=/usr/local/gnu/4.8.3 --enable-languages=c,c++,fortran --with-gmp=/home/travel/GNUBUILD/gmp --with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc Thread model: posix gcc version 4.8.3 (GCC) [sfilippo@jacobi runs]$ valgrind --leak-check=full ./foo-test-leak ==20638== Memcheck, a memory error detector ==20638== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==20638== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==20638== Command: ./foo-test-leak ==20638== Scalar deallocation Deallocate class() component Scalar deallocation Deallocate class() component Scalar deallocation Deallocate class() component Scalar deallocation Deallocate class() component Scalar deallocation Deallocate class() component Scalar deallocation Deallocate class() component Scalar deallocation Deallocate class() component Scalar deallocation Deallocate class() component Scalar deallocation Deallocate class() component Scalar deallocation Deallocate class() component Scalar deallocation Deallocate class() component Scalar deallocation Deallocate class() component ==20638== ==20638== HEAP SUMMARY: ==20638== in use at exit: 6,164 bytes in 23 blocks ==20638== total heap usage: 89 allocs, 66 frees, 35,518 bytes allocated ==20638== ==20638== 560 (48 direct, 512 indirect) bytes in 1 blocks are definitely lost in loss record 3 of 5 ==20638==at 0x4A069EE: malloc (vg_replace_malloc.c:270) ==20638==by 0x400B70: __foo_base_mod_MOD_foo_geall (foo-test-leak.f90:96) ==20638==by 0x401F8B: __foo_scalar_field_mod_MOD_new_scalar_field (foo-test-leak.f90:141) ==20638==by 0x40271F: __foo_vector_field_mod_MOD_new_vector_field (foo-test-leak.f90:163) ==20638==by 0x402AC8: MAIN__ (foo-test-leak.f90:188) ==20638==by 0x4031D3: main (foo-test-leak.f90:179) ==20638== ==20638== 5,600 (480 direct, 5,120 indirect) bytes in 10 blocks are definitely lost in loss record 5 of 5 ==20638==at 0x4A069EE: malloc (vg_replace_malloc.c:270) ==20638==by 0x400B70: __foo_base_mod_MOD_foo_geall (foo-test-leak.f90:96) ==20638==by 0x401F8B: __foo_scalar_field_mod_MOD_new_scalar_field (foo-test-leak.f90:141) ==20638==by 0x40271F: __foo_vector_field_mod_MOD_new_vector_field (foo-test-leak.f90:163) ==20638==by 0x402C9E: MAIN__ (foo-test-leak.f90:192) ==20638==by 0x4031D3: main (foo-test-leak.f90:179) ==20638== ==20638== LEAK SUMMARY: ==20638==definitely lost: 528 bytes in 11 blocks ==20638==indirectly lost: 5,632 bytes in 11 blocks ==20638== possibly lost: 0 bytes in 0 blocks ==20638==still reachable: 4 bytes in 1 blocks ==20638== suppressed: 0 bytes in 0 blocks ==20638== Reachable blocks (those to which a pointer was found) are not shown. ==20638== To see them, rerun with: --leak-check=full --show-reachable=yes ==20638== ==20638== For counts of detected and suppressed errors, rerun with: -v ==20638== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 6 from 6) --- If I change line 163 this%u = [new_scalar_field()] into do i=1, size(this%u) associate(sf=this%u(i)) sf = new_scalar_field() end associate end do then I get no leak [sfilippo@jacobi runs]$ valgrind --leak-check=full ./foo-test-leak-fixed ==20852== Memcheck, a memory error detector ==20852== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==20852== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==20852== Command: ./foo-test-leak-fixed ==20852== Scalar deallocation Deallocate class() component Scalar deallocation Deallocate class() component Scalar deallocation Deallocate class() component Scalar deallocation Deallocate class() component Scalar deallocation Deallocate class() component Scalar deallocation Deallocate class() component Scalar deallocation Deallocate class()
[Bug fortran/61830] Memory leak with assignment to array of derived types with allocatable components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61830 --- Comment #1 from Salvatore Filippone sfilippone at uniroma2 dot it --- Created attachment 33133 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33133action=edit workaround
[Bug tree-optimization/61829] SEGV in fold_binary_loc for gcc.dg/graphite/isl-codegen-loop-dumping.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61829 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-07-17 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Patch at https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00902.html.
[Bug fortran/61830] Memory leak with assignment to array of derived types with allocatable components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61830 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-07-17 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed.
[Bug fortran/61819] [4.9/4.10 Regression] ICE in gfc_conv_descriptor_data_get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61819 --- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr --- The following PRs give an ICE at the same place: pr54784, pr59765, pr60529, and pr61766.
[Bug fortran/61819] [4.9/4.10 Regression] ICE in gfc_conv_descriptor_data_get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61819 --- Comment #9 from Dominique d'Humieres dominiq at lps dot ens.fr --- Note that the original test of pr54784 now gives the same ICE and the change of behavior is in the range given in comment 6.
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #51 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Ah, we also expand one from a TARGET_MEM_REF: ;; basic block 76, loop depth 2 ;;pred: 79 load_dst_215 = MEM[base: ptr_110, offset: 0B]; and TARGET_MEM_REF only handles the movmisalign case. So it's either IVOPTs not punting properly here (it does for unaligned accesses - grep for STRICT_ALIGNMENT) or we need to put a bitfield extraction case into TARGET_MEM_REF expansion (IMHO that's missing anyway, IVOPTs is too much pessimized by not considering this). TARGET_MEM_REF is supposed to be a valid memory access for the target though and, by definition, an unaligned access is not valid for a strict alignment target (unless you have a movmisalign pattern), so the problem is the TARGET_MEM_REF. If you want to make IVOPTS generate unaligned TARGET_MEM_REFs, you'll need to make sure that the costs are properly adjusted and benchmark the result.
[Bug fortran/61831] New: [4.9.1 regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 Bug ID: 61831 Summary: [4.9.1 regression] runtime error: pointer being freed was not allocated Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: juergen.reuter at desy dot de Our code, WHIZARD 2.2.2, crashes in its self test smtest_5 with the following runtime error: whizard(46878) malloc: *** error for object 0x7faf83d7e270: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug Program received signal SIGABRT: Process abort signal. Backtrace for this error: #0 0x1102fb0b2 #1 0x1102fb86e #2 0x7fff8a300cf9 Abort trap: 6 Our code can be found here: http://www.hepforge.org/archive/whizard/whizard-2.2.2.tar.gz It can be configured with ./configure --disable-ocaml --prefix=your path then just do make, make install and run the code as ./whizard smtest_5.sin from the share/tests folder. We try to isolate the problem, but are not confident to manage to do that in a certain amount of time.
[Bug fortran/61831] [4.9.1 regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 Jürgen Reuter juergen.reuter at desy dot de changed: What|Removed |Added CC||juergen.reuter at desy dot de Severity|normal |critical
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #52 from thopre01 at gcc dot gnu.org --- (In reply to Eric Botcazou from comment #51) TARGET_MEM_REF is supposed to be a valid memory access for the target though and, by definition, an unaligned access is not valid for a strict alignment target (unless you have a movmisalign pattern), so the problem is the TARGET_MEM_REF. So we just need to identify what changes the MEM_REF that bswap introduce into a TARGET_MEM_REF without taking alignment into account. After bswap it's only a MEM_REF: load_dst_215 = MEM[(unsigned char *)load_src_277];
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #53 from thopre01 at gcc dot gnu.org --- (In reply to thopre01 from comment #52) (In reply to Eric Botcazou from comment #51) TARGET_MEM_REF is supposed to be a valid memory access for the target though and, by definition, an unaligned access is not valid for a strict alignment target (unless you have a movmisalign pattern), so the problem is the TARGET_MEM_REF. So we just need to identify what changes the MEM_REF that bswap introduce into a TARGET_MEM_REF without taking alignment into account. After bswap it's only a MEM_REF: load_dst_215 = MEM[(unsigned char *)load_src_277]; So it changes from a MEM_REF to a TARGET_MEM_REF in ivopts from a quick grep. I don't know how much this system but I can take a look after Cauldron where does this happen and bring the right person into this discussion.
[Bug c++/50961] Fails to decay template function properly(?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50961 --- Comment #3 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Thu Jul 17 16:22:19 2014 New Revision: 212760 URL: https://gcc.gnu.org/viewcvs?rev=212760root=gccview=rev Log: /cp 2014-07-17 Paolo Carlini paolo.carl...@oracle.com PR c++/50961 * call.c (standard_conversion): Use resolve_nondeduced_context for type_unknown_p (EXPR) TREE_CODE (TO) == BOOLEAN_TYPE. /testsuite 2014-07-17 Paolo Carlini paolo.carl...@oracle.com PR c++/50961 * g++.dg/template/operator13.C: New. Added: trunk/gcc/testsuite/g++.dg/template/operator13.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog
[Bug c++/50961] Fails to decay template function properly(?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50961 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org Target Milestone|--- |4.10.0 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed for 4.10.
[Bug fortran/61831] [4.9.1 regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org Severity|critical|normal --- Comment #1 from kargl at gcc dot gnu.org --- Can you rebuild your code with compile with the -fcheck=all option?
[Bug fortran/61819] [4.9/4.10 Regression] ICE in gfc_conv_descriptor_data_get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61819 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||damian at sourceryinstitute dot or ||g --- Comment #10 from Dominique d'Humieres dominiq at lps dot ens.fr --- Likely r206379 (pr59589). If I partially revert r206379, the ICEs for pr54784, pr59765, pr60529, pr61766, pr61819, and pr61822 are gone. Indeed the memory leak for pr59589 reappears and I get an ICE at trans-array.c:146 for the test in comment 1 of pr56385 (gfortran.dg/proc_ptr_comp_37.f90), but not in the original test. --- ../_clean/gcc/fortran/class.c2014-05-07 12:46:43.0 +0200 +++ gcc/fortran/class.c2014-07-17 18:01:17.0 +0200 @@ -833,7 +833,20 @@ finalize_component (gfc_expr *expr, gfc_ gfc_expr *e; gfc_ref *ref; - if (!comp_is_finalizable (comp)) +/* if (!comp_is_finalizable (comp)) */ + if (comp-ts.type != BT_DERIVED comp-ts.type != BT_CLASS + !comp-attr.allocatable) +return; + + if ((comp-ts.type == BT_DERIVED comp-attr.pointer) + || (comp-ts.type == BT_CLASS CLASS_DATA (comp) + CLASS_DATA (comp)-attr.pointer)) +return; + + if (comp-ts.type == BT_DERIVED !comp-attr.allocatable + (comp-ts.u.derived-f2k_derived == NULL + || comp-ts.u.derived-f2k_derived-finalizers == NULL) + !has_finalizer_component (comp-ts.u.derived)) return; e = gfc_copy_expr (expr); Note the ICEs reappear if I apply on top of the above the patch in comment 13 of pr59589. Could people familiar with finalization compare the tests in the above PRs and try to infer why comp-ts.u.derived-attr.alloc_comp changes the compiler behavior.
[Bug fortran/60529] [4.9/4.10 Regression] [OOP] ICE with allocatable sub-component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60529 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr --- Per pr61819, duplicate of pr 59765. *** This bug has been marked as a duplicate of bug 59765 ***
[Bug fortran/59765] [4.9/4.10 Regression] [OOP] ICE on valid with finalizable array components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59765 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||carlos.a.cruz at nasa dot gov --- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr --- *** Bug 60529 has been marked as a duplicate of this bug. ***
[Bug fortran/61766] [4.9/4.10 regression] ICE on trans-array.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61766 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr --- Per pr61819, duplicate of pr 59765. *** This bug has been marked as a duplicate of bug 59765 ***
[Bug fortran/59765] [4.9/4.10 Regression] [OOP] ICE on valid with finalizable array components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59765 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||juergen.reuter at desy dot de --- Comment #9 from Dominique d'Humieres dominiq at lps dot ens.fr --- *** Bug 61766 has been marked as a duplicate of this bug. ***
[Bug preprocessor/61832] New: r212638 breaks building ncurses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61832 Bug ID: 61832 Summary: r212638 breaks building ncurses Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: ktkachov at gcc dot gnu.org As of 212638: gcc/c-family/ChangeLog: * c-ppoutput.c (struct print::prev_was_system_token): New data member. (init_pp_output): Initialize it. (maybe_print_line_1, maybe_print_line, print_line_1, print_line) (do_line_change): Return a flag saying if a line marker was emitted or not. (scan_translation_unit): Detect if the system-ness of the token we are about to emit is different from the one of the previously emitted token. If so, emit a line marker. Avoid emitting useless adjacent line markers. Avoid emitting line markers for tokens originating from the expansion of built-in macros. (scan_translation_unit_directives_only): Adjust. by dodji gcc fails to build ncurses. Basically the preprocessor ends up generating invalid C-code. I'll try to reduce a testcase soon, but in the meantime this appears on x86, arm and aarch64 so should be easily reproducible
[Bug fortran/61819] [4.9/4.10 Regression] ICE in gfc_conv_descriptor_data_get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61819 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #11 from Dominique d'Humieres dominiq at lps dot ens.fr --- See comment 4 of pr59765 for the origin of the problem. *** This bug has been marked as a duplicate of bug 59765 ***
[Bug fortran/59765] [4.9/4.10 Regression] [OOP] ICE on valid with finalizable array components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59765 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||sfilippone at uniroma2 dot it --- Comment #10 from Dominique d'Humieres dominiq at lps dot ens.fr --- *** Bug 61819 has been marked as a duplicate of this bug. ***
[Bug c++/61833] New: [4.9] ICE in fold_comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61833 Bug ID: 61833 Summary: [4.9] ICE in fold_comparison Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ppluzhnikov at google dot com Created attachment 33134 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33134action=edit test case Google ref: b/16030670 Originally reported against gcc-4.8. Attached test case causes gcc-4_9-branch (r212536) to ICE like this (but only with -O2): gcc-svn-4_9-r212536/bin/g++ -c -std=c++11 t.ii -O2 t.ii: In function ‘void ToSpec()’: t.ii:158:1: internal compiler error: Segmentation fault ToSpec () ^ 0xb947ff crash_signal ../../gcc/toplev.c:337 0x952096 fold_comparison ../../gcc/fold-const.c:9074 0x95b8a7 fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*, tree_node*) ../../gcc/fold-const.c:12953 0xbca30d cleanup_control_expr_graph ../../gcc/tree-cfgcleanup.c:112 0xbca30d cleanup_control_flow_bb ../../gcc/tree-cfgcleanup.c:187 0xbca30d cleanup_tree_cfg_bb ../../gcc/tree-cfgcleanup.c:630 0xbcbd48 cleanup_tree_cfg_1 ../../gcc/tree-cfgcleanup.c:675 0xbcbd48 cleanup_tree_cfg_noloop ../../gcc/tree-cfgcleanup.c:731 0xbcbd48 cleanup_tree_cfg() ../../gcc/tree-cfgcleanup.c:786 0xaea194 execute_function_todo ../../gcc/passes.c:1811 0xaeaa83 execute_todo ../../gcc/passes.c:1887 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. Trunk rejects the reduced test case with definition of std::initializer_list does not match #include initializer_list due to fixes for PR61723. Trunk @r212277 does not ICE.
[Bug c++/61723] [C++11] ICE in contains_struct_check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61723 --- Comment #8 from Paul Pluzhnikov ppluzhnikov at google dot com --- Filed PR61833
[Bug c++/61834] New: __attribute__((may_alias)) causes compilation error with forward-declared constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61834 Bug ID: 61834 Summary: __attribute__((may_alias)) causes compilation error with forward-declared constructor Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lopresti at gmail dot com Created attachment 33135 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33135action=edit Source file demonstrating bug with may_alias If you compile the attached stand-alone test case with: g++ -S may_alias_bug.cc ...it compiles fine. If you compile with: g++ -DBUG -S may_alias_bug.cc ...it produces a compilation error: may_alias_bug2.cc:16:8: error: prototype for ‘Thing1::Thing1(Thing2)’ does not match any in class ‘Thing1’ This bug appears to exist at least as far back as GCC 4.4.7. The code compiles fine with Clang and with the Intel C++ compiler, as you can see by experimenting here: http://goo.gl/dDyljx
[Bug fortran/61831] [4.9.1 regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 --- Comment #2 from Jürgen Reuter juergen.reuter at desy dot de --- (In reply to kargl from comment #1) Can you rebuild your code with compile with the -fcheck=all option? I did. This does not change anything. And it does not give any further information.
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #54 from rguenther at suse dot de rguenther at suse dot de --- On July 17, 2014 5:50:44 PM CEST, ebotcazou at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #51 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Ah, we also expand one from a TARGET_MEM_REF: ;; basic block 76, loop depth 2 ;;pred: 79 load_dst_215 = MEM[base: ptr_110, offset: 0B]; and TARGET_MEM_REF only handles the movmisalign case. So it's either IVOPTs not punting properly here (it does for unaligned accesses - grep for STRICT_ALIGNMENT) or we need to put a bitfield extraction case into TARGET_MEM_REF expansion (IMHO that's missing anyway, IVOPTs is too much pessimized by not considering this). TARGET_MEM_REF is supposed to be a valid memory access for the target though and, by definition, an unaligned access is not valid for a strict alignment target (unless you have a movmisalign pattern), so the problem is the TARGET_MEM_REF. Ivopts does not change the memory addresses, so even when not using a target_men_ref the access will be unaligned. It's only that we had no way of specifying whether an access is unaligned or not. The addressing mode costs may not reflect reality though. Richard. If you want to make IVOPTS generate unaligned TARGET_MEM_REFs, you'll need to make sure that the costs are properly adjusted and benchmark the result.
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #55 from rguenther at suse dot de rguenther at suse dot de --- On July 17, 2014 6:13:14 PM CEST, thopre01 at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #53 from thopre01 at gcc dot gnu.org --- (In reply to thopre01 from comment #52) (In reply to Eric Botcazou from comment #51) TARGET_MEM_REF is supposed to be a valid memory access for the target though and, by definition, an unaligned access is not valid for a strict alignment target (unless you have a movmisalign pattern), so the problem is the TARGET_MEM_REF. So we just need to identify what changes the MEM_REF that bswap introduce into a TARGET_MEM_REF without taking alignment into account. After bswap it's only a MEM_REF: load_dst_215 = MEM[(unsigned char *)load_src_277]; So it changes from a MEM_REF to a TARGET_MEM_REF in ivopts from a quick grep. I don't know how much this system but I can take a look after Cauldron where does this happen and bring the right person into this discussion. You need to fix may_be_unaligned (or similar) in ivopts.
[Bug libstdc++/61835] New: Invalid comment on pretty printers breaks gdb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61835 Bug ID: 61835 Summary: Invalid comment on pretty printers breaks gdb Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: mariano.bessone at tallertechnologies dot com Created attachment 33136 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33136action=edit Workaround Running gdb with latest pretty printers causes: Traceback (most recent call last): File string, line 3, in module File /data/utils/prettyprinters/libstdcxx/v6/printers.py, line 1056 SyntaxError: (unicode error) 'unicodeescape' codec can't decode bytes in position 194-195: malformed \N character escape /home/marjobe/.gdbinit:6: Error in sourced command file: Error while executing Python code. The problem is that a comment contains an escape sequence. See workaround in the attached patch.
[Bug fortran/61831] [4.9.1 regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-07-17 Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed with 4.9.1 revision r212339. AFAICT revision r210749 is OK. I suspect r211405 for 4.10 and r212329 for 4.9. Can you revert r212329 and see if the error disappear? In any case a reduced test will help a lot.
[Bug fortran/61831] [4.9.1 regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 --- Comment #4 from Steve Kargl sgk at troutmask dot apl.washington.edu --- On Thu, Jul 17, 2014 at 07:14:19PM +, juergen.reuter at desy dot de wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 --- Comment #2 from J??rgen Reuter juergen.reuter at desy dot de --- Can you rebuild your code with compile with the -fcheck=all option? I did. This does not change anything. And it does not give any further information. Thanks. Unfortunately, I cannot get the code to build. Without a reduced testcase, this is going to be difficult for someone to debug.
[Bug c++/61836] New: Incorrect template argument deduction/substitution failure?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61836
Bug ID: 61836
Summary: Incorrect template argument deduction/substitution
failure?
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ilja.j.honkonen at nasa dot gov
Created attachment 33137
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33137action=edit
Preprocessed source
Trying to enable_if a particular implementation of a class member function
based on its template argument:
template
class Out_T
typename std::enable_if
std::is_sameOut_T, bool::value,
Out_T
::type get_parsed_value(...)
template
class Out_T
typename std::enable_if
std::is_sameOut_T, double::value,
Out_T
::type get_parsed_value(...)
including std::array and Eigen::Matrix:
templateclass T struct is_std_array_double : std::false_type {};
templatesize_t N struct is_std_array_double
std::arraydouble, N
: std::true_type {};
templateclass T struct is_eigen_vector_double : std::false_type {};
templatesize_t N struct is_eigen_vector_double
Eigen::Matrixdouble, N, 1
: std::true_type {};
template
class Out_T
typename std::enable_if
detail::is_std_array_doubleOut_T::value,
Out_T
::type get_parsed_value(...)
template
class Out_T
typename std::enable_if
detail::is_eigen_vector_doubleOut_T::value,
Out_T
::type get_parsed_value(...)
fails because apparently is_eigen_vector_double returns false for
Eigen::Matrixdouble, N, 1 even though it shouldn't. The same code compiles
with clangs 3.3-5.
Compile command:
/opt/local/gcc-4.9.1/bin/g++ -I source -std=c++11 -W -Wall -Wextra -pedantic
-O3 -I /opt/local/include/eigen3 -I /opt/local/include -L /opt/local/lib
-lboost_coroutine-mt -lboost_system-mt -lboost_random-mt
-lboost_program_options-mt -I /Users/iljah/include -L /Users/iljah/lib
-lmuparserx -I /Users/iljah/include
tests/program_options/variable_to_option.cpp -o
tests/program_options/variable_to_option.exe -Wno-unused-local-typedefs
-save-temps -v
Output:
Using built-in specs.
COLLECT_GCC=/opt/local/gcc-4.9.1/bin/g++
COLLECT_LTO_WRAPPER=/opt/local/gcc-4.9.1/libexec/gcc/x86_64-apple-darwin13.3.0/4.9.1/lto-wrapper
Target: x86_64-apple-darwin13.3.0
Configured with: ../gcc-4.9.1/configure --prefix=/opt/local/gcc-4.9.1
--enable-shared --enable-threads=posix --enable-__cxa_atexit --disable-multilib
--with-system-zlib --enable-languages=c,c++ --with-gmp=/opt/local
--with-mpfr=/opt/local --with-mpc=/opt/local --disable-bootstrap
Thread model: posix
gcc version 4.9.1 (GCC)
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.9.3' '-I' 'source' '-std=c++11'
'-Wall' '-Wextra' '-Wpedantic' '-O3' '-I' '/opt/local/include/eigen3' '-I'
'/opt/local/include' '-L/opt/local/lib' '-I' '/Users/iljah/include'
'-L/Users/iljah/lib' '-I' '/Users/iljah/include' '-o'
'tests/program_options/variable_to_option.exe' '-Wno-unused-local-typedefs'
'-save-temps' '-v' '-shared-libgcc' '-mtune=core2'
/opt/local/gcc-4.9.1/libexec/gcc/x86_64-apple-darwin13.3.0/4.9.1/cc1plus -E
-quiet -v -I source -I /opt/local/include/eigen3 -I /opt/local/include -I
/Users/iljah/include -I /Users/iljah/include -D__DYNAMIC__
tests/program_options/variable_to_option.cpp -fPIC -mmacosx-version-min=10.9.3
-mtune=core2 -std=c++11 -Wall -Wextra -Wpedantic -Wno-unused-local-typedefs -O3
-fpch-preprocess -o variable_to_option.ii
ignoring nonexistent directory /usr/local/include
ignoring nonexistent directory
/opt/local/gcc-4.9.1/lib/gcc/x86_64-apple-darwin13.3.0/4.9.1/../../../../x86_64-apple-darwin13.3.0/include
ignoring duplicate directory /Users/iljah/include
#include ... search starts here:
#include ... search starts here:
source
/opt/local/include/eigen3
/opt/local/include
/Users/iljah/include
/opt/local/gcc-4.9.1/lib/gcc/x86_64-apple-darwin13.3.0/4.9.1/../../../../include/c++/4.9.1
/opt/local/gcc-4.9.1/lib/gcc/x86_64-apple-darwin13.3.0/4.9.1/../../../../include/c++/4.9.1/x86_64-apple-darwin13.3.0
/opt/local/gcc-4.9.1/lib/gcc/x86_64-apple-darwin13.3.0/4.9.1/../../../../include/c++/4.9.1/backward
/opt/local/gcc-4.9.1/lib/gcc/x86_64-apple-darwin13.3.0/4.9.1/include
/opt/local/gcc-4.9.1/include
/opt/local/gcc-4.9.1/lib/gcc/x86_64-apple-darwin13.3.0/4.9.1/include-fixed
/usr/include
/System/Library/Frameworks
/Library/Frameworks
End of search list.
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.9.3' '-I' 'source' '-std=c++11'
'-Wall' '-Wextra' '-Wpedantic' '-O3' '-I' '/opt/local/include/eigen3' '-I'
'/opt/local/include' '-L/opt/local/lib' '-I' '/Users/iljah/include'
'-L/Users/iljah/lib' '-I' '/Users/iljah/include' '-o'
'tests/program_options/variable_to_option.exe' '-Wno-unused-local-typedefs'
'-save-temps' '-v' '-shared-libgcc' '-mtune=core2'
/opt/local/gcc-4.9.1/libexec/gcc/x86_64-apple-darwin13.3.0/4.9.1/cc1plus
-fpreprocessed variable_to_option.ii -fPIC
[Bug fortran/61831] [4.9.1 regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed with 4.9.1 revision r212339. AFAICT revision r210749 is OK. I suspect r211405 for 4.10 and r212329 for 4.9. Can you revert r212329 and see if the error disappear? I am afraid that I am the culprit, i.e., r212329: I get the error with r209838 + the patch in r212329. However the failures are not exactly the same: with 4.9.1 revision r212339, it is | Creating decay process library for particle W+ | Process library 'default_lib_dp24': initialized | decay_p24_1: W+ = dbar u | Process library 'default_lib_dp24': recorded process 'decay_p24_1' | decay_p24_2: ?O = sbar c | Process library 'default_lib_dp24': recorded process 'decay_p24_2' | decay_p24_3: = e+ nue whizard(32872,0x7fff7738d310) malloc: *** error for object 0x7f805874ea60: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug while with r209838 + patch, it is | Creating decay process library for particle W+ | Process library 'default_lib_dp24': initialized | decay_p24_1: W+ = dbar u | Process library 'default_lib_dp24': recorded process 'decay_p24_1' | decay_p24_2: = sbar c | Process library 'default_lib_dp24': recorded process 'decay_p24_2' whizard(36947,0x7fff7738d310) malloc: *** error for object 0x7fb8c3755810: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug For 4.9.0, I get | Creating decay process library for particle W+ | Process library 'default_lib_dp24': initialized | decay_p24_1: W+ = dbar u | Process library 'default_lib_dp24': recorded process 'decay_p24_1' | decay_p24_2: W+ = sbar c | Process library 'default_lib_dp24': recorded process 'decay_p24_2' | decay_p24_3: W+ = e+ nue | Process library 'default_lib_dp24': recorded process 'decay_p24_3' | decay_p24_4: W+ = mu+ numu | Process library 'default_lib_dp24': recorded process 'decay_p24_4' | decay_p24_5: W+ = tau+ nutau | Process library 'default_lib_dp24': recorded process 'decay_p24_5' | Integrate: current process library needs compilation | Process library 'default_lib_dp24': compiling ... | Process library 'default_lib_dp24': writing makefile | Process library 'default_lib_dp24': writing driver | Process library 'default_lib_dp24': creating source code rm -f decay_p24_1_i1.f90 rm -f opr_decay_p24_1_i1.mod rm -f decay_p24_1_i1.lo rm -f decay_p24_2_i1.f90 rm -f opr_decay_p24_2_i1.mod rm -f decay_p24_2_i1.lo rm -f decay_p24_3_i1.f90 rm -f opr_decay_p24_3_i1.mod rm -f decay_p24_3_i1.lo rm -f decay_p24_4_i1.f90 rm -f opr_decay_p24_4_i1.mod rm -f decay_p24_4_i1.lo rm -f decay_p24_5_i1.f90 rm -f opr_decay_p24_5_i1.mod rm -f decay_p24_5_i1.lo /usr/local/bin/omega_SM.opt -o decay_p24_1_i1.f90 -target:whizard -target:parameter_module parameters_SM -target:module opr_decay_p24_1_i1 -target:md5sum 'B42EAF21C73773800B93C9AE1495DD00' -fusion:progress -decay 'W+ - dbar u' make: /usr/local/bin/omega_SM.opt: Command not found make: *** [decay_p24_1_i1.f90] Error 127 | command: make source -j1 -f default_lib_dp24.makefile | Return code = 512 ** ** *** FATAL ERROR: System command returned with nonzero status code ** ** WHIZARD run aborted.
[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Keywords||wrong-code Known to work||4.9.0 Version|unknown |4.9.1 Summary|[4.9.1 regression] runtime |[4.9/ 4.10 Regression] |error: pointer being freed |runtime error: pointer |was not allocated |being freed was not ||allocated Known to fail||4.10.0, 4.9.1 --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr --- Marked as 4.9/4.10 regression.
[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 --- Comment #7 from Jürgen Reuter juergen.reuter at desy dot de --- (In reply to Dominique d'Humieres from comment #5) Confirmed with 4.9.1 revision r212339. AFAICT revision r210749 is OK. I suspect r211405 for 4.10 and r212329 for 4.9. Can you revert r212329 and see if the error disappear? I am afraid that I am the culprit, i.e., r212329: I get the error with r209838 + the patch in r212329. However the failures are not exactly the same: with 4.9.1 revision r212339, it is | Creating decay process library for particle W+ | Process library 'default_lib_dp24': initialized | decay_p24_1: W+ = dbar u | Process library 'default_lib_dp24': recorded process 'decay_p24_1' | decay_p24_2: ?O = sbar c | Process library 'default_lib_dp24': recorded process 'decay_p24_2' | decay_p24_3: = e+ nue whizard(32872,0x7fff7738d310) malloc: *** error for object 0x7f805874ea60: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug while with r209838 + patch, it is | Creating decay process library for particle W+ | Process library 'default_lib_dp24': initialized | decay_p24_1: W+ = dbar u | Process library 'default_lib_dp24': recorded process 'decay_p24_1' | decay_p24_2: = sbar c | Process library 'default_lib_dp24': recorded process 'decay_p24_2' whizard(36947,0x7fff7738d310) malloc: *** error for object 0x7fb8c3755810: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug For 4.9.0, I get | Creating decay process library for particle W+ | Process library 'default_lib_dp24': initialized | decay_p24_1: W+ = dbar u | Process library 'default_lib_dp24': recorded process 'decay_p24_1' | decay_p24_2: W+ = sbar c | Process library 'default_lib_dp24': recorded process 'decay_p24_2' | decay_p24_3: W+ = e+ nue | Process library 'default_lib_dp24': recorded process 'decay_p24_3' | decay_p24_4: W+ = mu+ numu | Process library 'default_lib_dp24': recorded process 'decay_p24_4' | decay_p24_5: W+ = tau+ nutau | Process library 'default_lib_dp24': recorded process 'decay_p24_5' | Integrate: current process library needs compilation | Process library 'default_lib_dp24': compiling ... | Process library 'default_lib_dp24': writing makefile | Process library 'default_lib_dp24': writing driver | Process library 'default_lib_dp24': creating source code rm -f decay_p24_1_i1.f90 rm -f opr_decay_p24_1_i1.mod rm -f decay_p24_1_i1.lo rm -f decay_p24_2_i1.f90 rm -f opr_decay_p24_2_i1.mod rm -f decay_p24_2_i1.lo rm -f decay_p24_3_i1.f90 rm -f opr_decay_p24_3_i1.mod rm -f decay_p24_3_i1.lo rm -f decay_p24_4_i1.f90 rm -f opr_decay_p24_4_i1.mod rm -f decay_p24_4_i1.lo rm -f decay_p24_5_i1.f90 rm -f opr_decay_p24_5_i1.mod rm -f decay_p24_5_i1.lo /usr/local/bin/omega_SM.opt -o decay_p24_1_i1.f90 -target:whizard -target:parameter_module parameters_SM -target:module opr_decay_p24_1_i1 -target:md5sum 'B42EAF21C73773800B93C9AE1495DD00' -fusion:progress -decay 'W+ - dbar u' make: /usr/local/bin/omega_SM.opt: Command not found make: *** [decay_p24_1_i1.f90] Error 127 | command: make source -j1 -f default_lib_dp24.makefile | Return code = 512 * * * * *** FATAL ERROR: System command returned with nonzero status code * * * * WHIZARD run aborted. Great, thanks. The error you get for 4.9.0 is because the executable omega_SM.opt is absent (this is OCaml code).
[Bug go/59432] [4.9/4.10 regression] sync/atomic FAILs on Solaris/x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59432 --- Comment #6 from Ian Lance Taylor ian at airs dot com --- Re: comment #5. This bug report is about Solaris/x86 and is specific to Solaris. If you want to report a bug on any other target, please open a different bug. Thanks. In your case I suspect you need to use the configure option --with-arch-32=i686.
[Bug middle-end/61776] [4.9/4.10 Regression] ICE: verify_flow_info failed: control flow in the middle of basic block with -fprofile-generate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61776
davidxl xinliangli at gmail dot com changed:
What|Removed |Added
CC||xinliangli at gmail dot com
--- Comment #3 from davidxl xinliangli at gmail dot com ---
In tree-profiling (), in the intrumentation loop (for each def function) -- a
pending list of functions calling pure functions should be recorded.
After the loop that reset the const/pure flags, a loop should iterate though
the pending list, and perform cfg fixup on them.
David
(In reply to Richard Biener from comment #1)
There are several possibilities:
- don't instrument pure/const functions
- do not reset the pure/const flag (I see no reason to - the compiler might
not insert side-effects and we can consider the counter updates as
non-side-effect)
That is, I wonder why we do
/* Drop pure/const flags from instrumented functions. */
FOR_EACH_DEFINED_FUNCTION (node)
{
if (!gimple_has_body_p (node-decl)
|| !(!node-clone_of
|| node-decl != node-clone_of-decl))
continue;
/* Don't profile functions produced for builtin stuff. */
if (DECL_SOURCE_LOCATION (node-decl) == BUILTINS_LOCATION)
continue;
cgraph_set_const_flag (node, false, false);
cgraph_set_pure_flag (node, false, false);
}
but don't then call execute_fixup_cfg () again (but it doesn't yet deal
with a const/pure function becoming non-pure/const and thus a bb-ending
stmt).
Btw, this is yet another case where transitioning to call flags instead
of decl flags would save us - definitely even the instrumented call cannot
return abnormally.
Dropping the clearing of const/pure fixes the bug. Honza? I only can think
of the case where we have
for (..)
{
const ();
const ();
}
and inline only one of the calls where after that loop store-motion might
apply store-motion to the counter updates of the inline clone, overwriting
the updates from the non-inline call. But do we really care?
Anyway, confirmed. Btw, goo() should be leaf but it seems we don't
auto-compute 'leaf' yet?
[Bug c++/61825] [4.10 regression] g++.dg/cpp0x/static_assert9.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61825 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added Target|i386-pc-solaris2.11,|i386-pc-solaris2.11, |sparc-sun-solaris2.11, |sparc-sun-solaris2.11, |x86_64-unknown-linux-gnu|x86_64-unknown-linux-gnu, ||cris-elf Status|UNCONFIRMED |NEW Last reconfirmed||2014-07-17 CC||hp at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Hans-Peter Nilsson hp at gcc dot gnu.org --- cris-elf too, appearing in the svn revision interval (212498:212499]. I think I noticed some traffic and perhaps a patch go by but maybe that stalled; it's still there at r212759.
[Bug middle-end/61776] [4.9/4.10 Regression] ICE: verify_flow_info failed: control flow in the middle of basic block with -fprofile-generate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61776 --- Comment #4 from wmi at google dot com --- Can we move the pure/const resetting loop to an earlier place: inside branch_prob , after instrument_edges and before gsi_commit_edge_inserts (where stmt_ends_bb_p is checked), so that gsi_commit_edge_inserts() which changes cfg could take reset const/pure flags into consideration?
[Bug middle-end/61776] [4.9/4.10 Regression] ICE: verify_flow_info failed: control flow in the middle of basic block with -fprofile-generate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61776 --- Comment #5 from davidxl xinliangli at gmail dot com --- (In reply to wmi from comment #4) Can we move the pure/const resetting loop to an earlier place: inside branch_prob , after instrument_edges and before gsi_commit_edge_inserts (where stmt_ends_bb_p is checked), so that gsi_commit_edge_inserts() which changes cfg could take reset const/pure flags into consideration? Sounds plausible. Have you tried it? David
[Bug middle-end/61268] [4.10 regression] ICE in vt_expand_var_loc_chain, at var-tracking.c:8262
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61268 Pat Haugen pthaugen at gcc dot gnu.org changed: What|Removed |Added CC||pthaugen at gcc dot gnu.org --- Comment #9 from Pat Haugen pthaugen at gcc dot gnu.org --- Following tests started failing on powerpc64-unknown-linux-gnu with r210543. FAIL: gcc.dg/vmx/gcc-bug-5.c -O3 -g (internal compiler error) FAIL: gcc.dg/vmx/gcc-bug-6.c -O3 -g (internal compiler error) FAIL: gcc.dg/vmx/varargs-7.c -O3 -g (internal compiler error) I tried the patch from comment 5 and all 3 now pass. Bootstrap on powerpc64-unknown-linux-gnu also passed with it.
[Bug c++/61833] [4.9] ICE in fold_comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61833 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #1 from Jason Merrill jason at gcc dot gnu.org --- Hmm, I'm not seeing this with r212742.
[Bug middle-end/61776] [4.9/4.10 Regression] ICE: verify_flow_info failed: control flow in the middle of basic block with -fprofile-generate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61776
--- Comment #6 from wmi at google dot com ---
(In reply to davidxl from comment #5)
(In reply to wmi from comment #4)
Can we move the pure/const resetting loop to an earlier place: inside
branch_prob , after instrument_edges and before gsi_commit_edge_inserts
(where stmt_ends_bb_p is checked), so that gsi_commit_edge_inserts() which
changes cfg could take reset const/pure flags into consideration?
Sounds plausible. Have you tried it?
David
I just tried but found it was not very easy.
FOR_EACH_DEFINED_FUNCTION (node) {
execute_fixup_cfg() and cleanup_tree_cfg()
branch_prob()
}
For the above loop, branch_prob is called one by one for each defined func.
Because a func could possibly call any other funcs on the cgraph, we need to
reset the const/pure flags for every defined func before any branch_prob() is
called, so we cannot put the const/pure reset code inside branch_prob().
We also cannot move the const/pure reset loop before the branch_prob() loop,
because execute_fixup_cfg will use const/pure flags to generate different cfg.
If we put the const/pure reset code before the branch_prob() loop, the
const/pure reset code should only be executed in intrumentation phase, not in
annotation phase, so that we may get different cfg between intrumentation and
annotation.
Wei.
[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 --- Comment #8 from Jürgen Reuter juergen.reuter at desy dot de --- Created attachment 33138 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33138action=edit Test case
[Bug middle-end/61776] [4.9/4.10 Regression] ICE: verify_flow_info failed: control flow in the middle of basic block with -fprofile-generate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61776
--- Comment #7 from davidxl xinliangli at gmail dot com ---
(In reply to wmi from comment #6)
(In reply to davidxl from comment #5)
(In reply to wmi from comment #4)
Can we move the pure/const resetting loop to an earlier place: inside
branch_prob , after instrument_edges and before gsi_commit_edge_inserts
(where stmt_ends_bb_p is checked), so that gsi_commit_edge_inserts()
which
changes cfg could take reset const/pure flags into consideration?
Sounds plausible. Have you tried it?
David
I just tried but found it was not very easy.
FOR_EACH_DEFINED_FUNCTION (node) {
execute_fixup_cfg() and cleanup_tree_cfg()
branch_prob()
}
For the above loop, branch_prob is called one by one for each defined func.
Because a func could possibly call any other funcs on the cgraph, we need to
reset the const/pure flags for every defined func before any branch_prob()
is called, so we cannot put the const/pure reset code inside branch_prob().
As you noted below, resetting the flag before branch_prob will lead to cfg
mismatch between instr and profile-use build.
David
We also cannot move the const/pure reset loop before the branch_prob() loop,
because execute_fixup_cfg will use const/pure flags to generate different
cfg. If we put the const/pure reset code before the branch_prob() loop, the
const/pure reset code should only be executed in intrumentation phase, not
in annotation phase, so that we may get different cfg between intrumentation
and annotation.
Wei.
[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 --- Comment #9 from Jürgen Reuter juergen.reuter at desy dot de --- I added the test case which is at least freed from a lot of docu and the heavy autotools/libtool setup. The makefile compiles the code and creates a binary seg_prod. Run this as ./seg_prod input.txt to produce the problem. I try to reduce this further.
[Bug target/61837] New: missed loop invariant expression optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61837
Bug ID: 61837
Summary: missed loop invariant expression optimization
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: carrot at google dot com
Host: x86_64-unknown-linux-gnu
Target: powerpc64le
Compile following code with trunk compiler and options -O2 -m64 -mcpu=power8
void foo(int *p1, char *p2, int s)
{
int n, v, i;
v = 0;
for (n = 0; n = 100; n++) {
for (i = 0; i s; i++)
if (p2[i] == n)
p1[i] = v;
v += 88;
}
}
I got
foo:
addi 9,5,-1
cmpwi 5,5,0
rldicl 9,9,0,32
li 6,0
li 7,0
add 5,4,9
.p2align 4,,15
.L2:
ble 5,.L6
addi 8,4,-1
mr 10,3
subf 9,8,5 // A
mtctr 9
b .L4
.p2align 4,,15
.L3:
addi 10,10,4
bdz .L6
.L4:
lbzu 9,1(8)
cmpw 7,9,7
bne 7,.L3
stw 6,0(10)
addi 10,10,4
bdnz .L4
.L6:
addi 6,6,88
addi 7,7,1
cmpwi 7,6,
extsw 7,7
extsw 6,6
bne 7,.L2
blr
Instruction A computes the inner loop counter, it is loop invariant for the
outer loop, so it can be hoisted out of the outer loop.
[Bug c++/61838] New: ICE on Windows with ctors defined outside class definitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61838 Bug ID: 61838 Summary: ICE on Windows with ctors defined outside class definitions Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lh_mouse at 126 dot com Created attachment 33139 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33139action=edit crashme.cpp A ctor, which takes a parameter of a template class with a template parameter of another variadic template class, and defined outside its class definition, results in an ICE. This ICE seems to happen on Windows only. E:\Desktopg++ crashme.cpp -std=c++1y cc1plus.exe: internal compiler error: Segmentation fault E:\Desktopg++ -v ... Target: x86_64-w64-mingw32 ... Thread model: win32 gcc version 4.9.1 (x86_64-win32-seh-rev0, Built by MinGW-W64 project)
[Bug c/51840] asm goto enhancement request
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51840 --- Comment #11 from Adam Warner adam at consulting dot net.nz --- Thank you for the fixed example! Just for the record only toy VM examples can be implemented using this technique. GCC documentation used to say that that the extended asm 30 operand limit might be lifted in a future version of GCC. This sentence seems to have been deleted. The full statement now reads: The total number of input + output + goto operands has a limit of 30. The Java Virtual Machine, for example, contains almost 200 bytecode instructions. To use this technique to jump to each instruction the list of asm goto labels would number around 200. But the GCC limit is less than 30 (since one must also subtract input operands from the limit). It's a blemish on GCC's compiler architecture and a gross violation of the zero-one-infinity rule. BTW if the example is modified by adding 25+ additional dummy goto labels there is an Internal Compiler Error in extract_insn, at recog.c:2175 [gcc (Debian 4.9.0-7) 4.9.0]
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734 Damien Buhl (daminetreg) damien.buhl at lecbna dot org changed: What|Removed |Added CC||damien.buhl at lecbna dot org --- Comment #40 from Damien Buhl (daminetreg) damien.buhl at lecbna dot org --- I can also confirm the crash with gcc-4.8.1 for an arm platform. Everything compiles fine, but on the platform the support for atomics looks like missing, because it dies with pure virtual method called. Using boost::thread which uses boost::atomic and in this case implements atomic self (not via the gcc compiler) is the only workaround I found without recompiling the compiler with atomic support.
