[Bug go/63731] New: Fallback to netgo does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
Bug ID: 63731
Summary: Fallback to netgo does not work
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: yohei at jp dot ibm.com
CC: cmang at google dot com
When the DNS resolver with CGO fails for statically linked binaries, it should
fall back to the pure-go DNS resolver, if I understand correctly.
This fallback mechanism does work at least on Linux for x86_64 and ppc64le.
The variable ok in lookupIP in go/net/lookup_unix.go seems always set to true,
so the fallback mechanism would never be called.
Here is an example code to demonstrate the problem.
$ gccgo -v
Using built-in specs.
COLLECT_GCC=gccgo
COLLECT_LTO_WRAPPER=/usr/local/gccgo-216834/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../src/configure --enable-threads=posix --enable-shared
--enable-__cxa_atexit --enable-languages=c,c++,go --enable-secureplt
--enable-checking=yes --with-long-double-128 --enable-decimal-float
--disable-bootstrap --disable-alsa --disable-multilib
--prefix=/usr/local/gccgo-216834
Thread model: posix
gcc version 5.0.0 20141029 (experimental) (GCC)
$ cat lookup.go
package main
import (
fmt
net
)
func main() {
addrs, err := net.LookupHost(gcc.gnu.org)
if err != nil {
fmt.Println(err)
} else {
for i := 0; i len(addrs); i++ {
fmt.Println(addrs[i])
}
}
}
$ gccgo lookup.go
$ ./a.out
209.132.180.131
$ gccgo -static lookup.go
/usr/local/gccgo-216834/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/../../../../lib64/libgo.a(net.o):
In function `net.cgoLookupPort':
/home/yohei/gccgo.216834/bld/x86_64-unknown-linux-gnu/libgo/../../../src/libgo/go/net/cgo_unix.go:83:
warning: Using 'getaddrinfo' in statically linked applications requires at
runtime the shared libraries from the glibc version used for linking
$ ./a.out
lookup gcc.gnu.org: Name or service not known
$ LD_LIBRARY_PATH=/lib/x86_64-linux-gnu ./a.out
209.132.180.131
[Bug fortran/63640] move_alloc memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63640 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||Joost.VandeVondele at mat dot ethz ||.ch --- Comment #1 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- this rather is a misunderstanding, allocatables are not necessarily freed at the end of the main program. For example this is leak free: cat PR63640.f90 subroutine testmv3 type bar integer, allocatable :: ia(:), ja(:) end type integer, allocatable :: ia(:), ja(:) type(bar), allocatable :: sm,sm2 allocate(sm) allocate(sm2) allocate(sm%ia(100),sm%ja(100)) allocate(sm2%ia(1000),sm2%ja(1000)) allocate(ia(100),ja(1000)) call move_alloc(ja,ia) call move_alloc(sm%ia,sm2%ia) call move_alloc(sm%ja,sm2%ja) end subroutine testmv3 call testmv3 END BTW, to check for leaks, you can now use the following way to compile your code: gfortran -fsanitize=leak PR63640.f90 without the need to run under valgrind.
[Bug bootstrap/63714] AIX (5.3.7, xlC v11) fails to bootstrap for gcc 4.9.2, 4.8.3 and 4.7.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63714 --- Comment #7 from Michael Felt aixtools at gmail dot com --- update: CONFIG_SHELL=/usr/bin/ksh still fails at the start CONFIG_SHELL=/opt/bin/bash (v4-30) complains, but moves on. [ -f stage_final ] || echo stage3 stage_final /opt/bin/bash: command substitution: line 2: syntax error near unexpected token `-qlanglvl=extc89' /opt/bin/bash: command substitution: line 2: `case cc -qlanglvl=extc89 in *gcc*) echo -Wl,-bbigtoc ;; esac;' ... What needs correcting so that a switch/case statement (I presume) is constructed correctly? On Mon, Nov 3, 2014 at 10:46 PM, aixtools at gmail dot com gcc-bugzi...@gcc.gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63714 --- Comment #6 from Michael Felt aixtools at gmail dot com --- thanks. it is night. shall look at this again tomorrow. had not spotted CONFIG_SHELL among the how to build ada text. I had been trying to follow what seemed relevant. must write my own document headers I guess :smile: On Nov 3, 2014 10:25 PM, glisse at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63714 --- Comment #5 from Marc Glisse glisse at gcc dot gnu.org --- https://gcc.gnu.org/wiki/FAQ#Configuration_fails_with_.27.27configure:_error:_cannot_compute_suffix_of_object_files:_cannot_compile.27.27._What_is_the_problem.3F (and for selecting the shell: https://gcc.gnu.org/install/prerequisites.html ) Please read the docs...
[Bug c++/63732] New: constexpr is not constant expression, when cast member data pointer to data parent type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63732
Bug ID: 63732
Summary: constexpr is not constant expression, when cast member
data pointer to data parent type
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pavel.kral at omsquare dot com
The code bellow returns error on 4.9.2 (and cause ICE on 4.8.x) tested on
Linux, MinGW and arm-none-eabi. While 'xxx' compiles just fine, 'yyy' which is
casted to parent type doesn't. Just for clarification static const array
'm_members' compiles fine and generate values at compile time in .rodata
section as expected (arm-none-eabi).
class PropertyBase {};
class Number : PropertyBase {};
class ComplexProperty : PropertyBase {
public:
Number m_firstNumber;
static PropertyBase ComplexProperty::* const m_members[];
// compiles fine
static constexpr auto xxx = (Number
ComplexProperty::*)ComplexProperty::m_firstNumber;
// error: '(PropertyBase
ComplexProperty::*)ComplexProperty::m_firstNumber' is not a constant
expression
static constexpr auto yyy = (PropertyBase
ComplexProperty::*)ComplexProperty::m_firstNumber;
};
// compiles fine
PropertyBase ComplexProperty::* const ComplexProperty::m_members[] = {
(PropertyBase ComplexProperty::*) ComplexProperty::m_firstNumber
};
static ComplexProperty person;
int main() {
}
[Bug fortran/63733] New: [OOP] wrong resolution for OPERATOR generics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63733 Bug ID: 63733 Summary: [OOP] wrong resolution for OPERATOR generics Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: sfilippone at uniroma2 dot it Created attachment 33881 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33881action=edit test case Hi, The attached test case, slightly modified from an original by Alberto F. Martin-Huertas in https://gcc.gnu.org/ml/fortran/2014-10/msg00124.html, changes behaviour across versions; in particular, 4.7.3 seems correct and all other versions I tried are not. According to Steve Lionel https://software.intel.com/en-us/forums/topic/534799 the current Intel and gfortran behaviour is wrong, and this is also my impression. We have not had a definite answer at https://groups.google.com/forum/#!topic/comp.lang.fortran/aFNK3FXqTUA Again, my reading of the standard is that 4.7.3 is correct and the others are wrong, but of course I will gladly accept a correction; either way, at least one version of gfortran is wrong. -- [sfilippo@jacobi F2003]$ module switch gnu gnu/4.6.4 gnu/4.6.4 - loads the GNU 4.6.4 compilers suite Version 4.6.4 [sfilippo@jacobi F2003]$ gfortran -o test_ov test_ov.f90 [sfilippo@jacobi F2003]$ ./test_ov sum_parent sum_parent sum_child [sfilippo@jacobi F2003]$ module switch gnu gnu/4.7.3 gnu/4.7.3 - loads the GNU 4.7.3 compilers suite Version 4.7.3 [sfilippo@jacobi F2003]$ gfortran -o test_ov test_ov.f90 [sfilippo@jacobi F2003]$ ./test_ov sum_parent sum_child sum_child [sfilippo@jacobi F2003]$ module switch gnu gnu/4.8.3 gnu/4.8.3 - loads the GNU 4.8.3 compilers suite Version 4.8.3 [sfilippo@jacobi F2003]$ gfortran -o test_ov test_ov.f90 [sfilippo@jacobi F2003]$ ./test_ov sum_parent sum_parent sum_child [sfilippo@jacobi F2003]$ module switch gnu gnu/4.9.1 gnu/4.9.1 - loads the GNU 4.9.1 compilers suite Version 4.9.1 [sfilippo@jacobi F2003]$ gfortran -o test_ov test_ov.f90 [sfilippo@jacobi F2003]$ ./test_ov sum_parent sum_parent sum_child [sfilippo@jacobi F2003]$ module switch gnu gnu/5.0.0 gnu/5.0.0 - loads the GNU 5.0.0-pre compilers suite Version 5.0.0 [sfilippo@jacobi F2003]$ gfortran -o test_ov test_ov.f90 [sfilippo@jacobi F2003]$ ./test_ov sum_parent sum_parent sum_child [sfilippo@jacobi F2003]$
[Bug tree-optimization/63595] [5.0 Regression] Segmentation faults inside kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63595
--- Comment #9 from Martin Liška marxin at gcc dot gnu.org ---
Merged function by IPA ICF after expand_thunk is called:
Triangulationdim::raw_quad_iterator Triangulationdim::end_quad() const
[with int dim = 3; Triangulationdim::raw_quad_iterator = TriaRawIterator3,
TriaObjectAccessor2, 3 ] (const struct Triangulation * const this)
{
bb 2:
# DEBUG this = _2(D)
# DEBUG parent = this_3(D)
# DEBUG level = -1
# DEBUG index = -1
# DEBUG local_data = 0B
# DEBUG this = _2(D)
# DEBUG D#265 = MEM[(struct TriaRawIterator *)_2(D)].accessor
# DEBUG this = D#265
# DEBUG parent = this_3(D)
# DEBUG level = -1
# DEBUG index = -1
# DEBUG local_data = 0B
# DEBUG D#264 = D#265-D.46601
# DEBUG this = D#264
# DEBUG parent = this_3(D)
# DEBUG level = -1
# DEBUG index = -1
# DEBUG D.101330 = 0B
MEM[(struct TriaAccessor *)_2(D)].present_level = -1;
MEM[(struct TriaAccessor *)_2(D)].present_index = -1;
MEM[(struct TriaAccessor *)_2(D)].tria = this_3(D);
return _2(D);
}
Triangulationdim::raw_cell_iterator Triangulationdim::end() const [with int
dim = 3; Triangulationdim::raw_cell_iterator = TriaRawIterator3,
CellAccessor3 ] (const struct Triangulation * const this)
{
bb 2:
Triangulation3::end_quad (this_2(D)); [tail call]
return;
}
[Bug c++/63650] conflicting type attributes specified for ‘virtual..'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63650 --- Comment #8 from Richard PALO richard at netbsd dot org --- (In reply to Richard PALO from comment #7) Further testing indicates that 'cdecl' is okay and that keeping 'regparm(0)' causes the error. Is there perhaps a hint where I could checkout in the code, or is this a case of a faulty program (in this case xulrunner)... since this test code compiles without errors/warnings with clang++ 3.5, it would seem that it should be okay.
[Bug tree-optimization/63734] New: [5.0 regression] FAIL: gcc.dg/torture/vshuf-v8qi.c -O2 (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63734 Bug ID: 63734 Summary: [5.0 regression] FAIL: gcc.dg/torture/vshuf-v8qi.c -O2 (internal compiler error) Product: gcc Version: 5.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: sch...@linux-m68k.org CC: glisse at gcc dot gnu.org Target: ia64-*-* $ gcc/xgcc -Bgcc/ ../gcc/testsuite/gcc.dg/torture/vshuf-v8qi.c -O2 -lm -o ./vshuf-v8qi.exe ../gcc/testsuite/gcc.dg/torture/vshuf-v8qi.c: In function ‘test_3’: ../gcc/testsuite/gcc.dg/torture/vshuf-v8qi.c:10:0: internal compiler error: in gen_reg_rtx, at emit-rtl.c:1030 #include vshuf-main.inc ^ 0x4064179f gen_reg_rtx(machine_mode) ../../gcc/emit-rtl.c:1030 0x41503b4f expand_vec_perm_interleave_2 ../../gcc/config/ia64/ia64.c:11540 0x4150485f ia64_expand_vec_perm_const_1 ../../gcc/config/ia64/ia64.c:11620 0x41504b6f ia64_vectorize_vec_perm_const_ok ../../gcc/config/ia64/ia64.c:11749 0x40b83b2f can_vec_perm_p(machine_mode, bool, unsigned char const*) ../../gcc/optabs.c:6580 0x40724baf fold_ternary_loc(unsigned int, tree_code, tree_node*, tree_node*, tree_node*, tree_node*) ../../gcc/fold-const.c:14271 0x40837baf gimple_fold_stmt_to_constant_1(gimple_statement_base*, tree_node* (*)(tree_node*)) ../../gcc/gimple-fold.c:4582 0x411e7b3f try_to_simplify ../../gcc/tree-ssa-sccvn.c:3387 0x411e7b3f visit_use ../../gcc/tree-ssa-sccvn.c:3464 0x411eb19f extract_and_process_scc_for_name ../../gcc/tree-ssa-sccvn.c:3911 0x411eb19f DFS ../../gcc/tree-ssa-sccvn.c:3963 0x411ee18f cond_dom_walker::before_dom_children(basic_block_def*) ../../gcc/tree-ssa-sccvn.c:4242 0x41690e4f dom_walker::walk(basic_block_def*) ../../gcc/domwalk.c:188 0x411ec6af run_scc_vn(vn_lookup_kind) ../../gcc/tree-ssa-sccvn.c:4334 0x41173a6f execute ../../gcc/tree-ssa-pre.c:4885 Broken by r217033. 2014-11-03 Marc Glisse marc.gli...@inria.fr PR tree-optimization/63666 * fold-const.c: Include optabs.h. (fold_ternary_loc) VEC_PERM_EXPR: Avoid canonicalizing a can_vec_perm_p permutation to one that is not.
[Bug tree-optimization/63734] [5.0 regression] FAIL: gcc.dg/torture/vshuf-v8qi.c -O2 (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63734 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Target Milestone|--- |5.0
[Bug libstdc++/63614] With gcc-4.8.3 and -stdgnu++0x call to std::this_thread::get_id() creates SIGSEV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63614 Oliver Maurhart dyle at dyle dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Oliver Maurhart dyle at dyle dot org --- Thank you for the hint. Using valgrind gave me the warning of switching stacks?, which let me increase my stack-size, which wasn't enough, which gave me the final clue, that my last changes exploded the stack with way too great local variables arrays. Re reconfigured my code to create dynamic arrays as local vars like std::unqiue_ptruint64_t[] d(new uint64_t[REAL_LARGE_NUMBER_HERE]); instead of just uint64_t d[REAL_LARGE_NUMBER_HERE]; Now my stack feels fine again. Thx. Solved - invalid.
[Bug bootstrap/63714] AIX (5.3.7, xlC v11) fails to bootstrap for gcc 4.9.2, 4.8.3 and 4.7.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63714 --- Comment #8 from Michael Felt aixtools at gmail dot com --- This ran MUCH better - thanks, but curious about what to do with following messages (there where more than I could reverse scroll). I forgot where I read about some systems having .o files that are always different, maybe I need to verify a tool. Next suggestion is welcome. powerpc-ibm-aix5.3.0.0/libstdc++-v3/src/.libs/compatibility-list.o differs powerpc-ibm-aix5.3.0.0/libstdc++-v3/src/.libs/compatibility-parallel_list-2.o differs powerpc-ibm-aix5.3.0.0/libstdc++-v3/src/.libs/compatibility-parallel_list.o differs powerpc-ibm-aix5.3.0.0/libstdc++-v3/src/.libs/compatibility-debug_list.o differs powerpc-ibm-aix5.3.0.0/libstdc++-v3/src/.libs/compatibility-list-2.o differs powerpc-ibm-aix5.3.0.0/libstdc++-v3/src/.libs/compatibility-thread-c++0x.o differs powerpc-ibm-aix5.3.0.0/libstdc++-v3/src/.libs/compatibility.o differs powerpc-ibm-aix5.3.0.0/libstdc++-v3/src/.libs/compatibility-debug_list-2.o differs powerpc-ibm-aix5.3.0.0/libstdc++-v3/src/.libs/compatibility-atomic-c++0x.o differs zlib/libz_a-compress.o differs zlib/libz_a-inftrees.o differs zlib/libz_a-deflate.o differs zlib/libz_a-gzio.o differs zlib/libz_a-inffast.o differs zlib/libz_a-zutil.o differs zlib/libz_a-uncompr.o differs zlib/libz_a-inflate.o differs zlib/libz_a-crc32.o differs zlib/libz_a-trees.o differs zlib/libz_a-adler32.o differs zlib/libz_a-infback.o differs make[2]: *** [compare] Error 1 make[2]: Leaving directory `/data/prj/gnu/gcc/objdir/gcc-4.7.4' make[1]: *** [stage3-bubble] Error 2 make[1]: Leaving directory `/data/prj/gnu/gcc/objdir/gcc-4.7.4' make: *** [all] Error 2 On Tue, Nov 4, 2014 at 10:09 AM, aixtools at gmail dot com gcc-bugzi...@gcc.gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63714 --- Comment #7 from Michael Felt aixtools at gmail dot com --- update: CONFIG_SHELL=/usr/bin/ksh still fails at the start CONFIG_SHELL=/opt/bin/bash (v4-30) complains, but moves on. [ -f stage_final ] || echo stage3 stage_final /opt/bin/bash: command substitution: line 2: syntax error near unexpected token `-qlanglvl=extc89' /opt/bin/bash: command substitution: line 2: `case cc -qlanglvl=extc89 in *gcc*) echo -Wl,-bbigtoc ;; esac;' ... What needs correcting so that a switch/case statement (I presume) is constructed correctly? On Mon, Nov 3, 2014 at 10:46 PM, aixtools at gmail dot com gcc-bugzi...@gcc.gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63714 --- Comment #6 from Michael Felt aixtools at gmail dot com --- thanks. it is night. shall look at this again tomorrow. had not spotted CONFIG_SHELL among the how to build ada text. I had been trying to follow what seemed relevant. must write my own document headers I guess :smile: On Nov 3, 2014 10:25 PM, glisse at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63714 --- Comment #5 from Marc Glisse glisse at gcc dot gnu.org --- https://gcc.gnu.org/wiki/FAQ#Configuration_fails_with_.27.27configure:_error:_cannot_compute_suffix_of_object_files:_cannot_compile.27.27._What_is_the_problem.3F (and for selecting the shell: https://gcc.gnu.org/install/prerequisites.html ) Please read the docs...
[Bug middle-end/63735] New: [5.0 regression] 5% code size regression since 2014/10/13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63735 Bug ID: 63735 Summary: [5.0 regression] 5% code size regression since 2014/10/13 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: rearnsha at gcc dot gnu.org Target: arm aarch64 Since 2014/10/13 there have been a number of commits that have contributed to a significant overall code-size regression at -Os. The numbers (building CSiBE) for Thumb2 are: 2014/10/13 2538705 2014/10/14 2539189 2014/10/20 2677449 2014/10/21 2677449 2014/10/22 2677449 2014/10/23 2677449 2014/10/24 2677421 2014/10/27 2684943 2014/10/28 2684943 2014/10/29 2684943 2014/10/30 2684943 2014/10/31 2685049 2014/11/03 2685124 Overall that's an increase of 5.76% in 2 weeks, but most of this is between the 14 and the 20th October (no successful builds in that time period). The regression is similar for both ARM and AArch64 with all optimization levels and target cpu options. In addition to the code size regression there has also been a compile time regression of ~15%.
[Bug target/63679] [5.0 Regression][AArch64] Failure to constant fold.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
--- Comment #2 from Tejas Belagod belagod at gcc dot gnu.org ---
foo.c.optimized:
5.0:
;;prev block 0, next block 1, flags: (NEW, REACHABLE)
;;pred: ENTRY [100.0%] (FALLTHRU,EXECUTABLE)
# .MEM_4 = VDEF .MEM_3(D)
aD.1380 = *.LC0D.1387;
# VUSE .MEM_4
vect__6.6_13 = MEM[(intD.7 *)aD.1380];
# VUSE .MEM_4
vect__6.6_10 = MEM[(intD.7 *)aD.1380 + 16B];
_27 = BIT_FIELD_REF vect__6.6_13, 32, 0;
_16 = BIT_FIELD_REF vect__6.6_10, 32, 0;
_15 = _16 + _27;
_18 = BIT_FIELD_REF vect__6.6_13, 32, 32;
_14 = BIT_FIELD_REF vect__6.6_10, 32, 32;
_5 = _14 + _18;
_12 = BIT_FIELD_REF vect__6.6_13, 32, 64;
_2 = BIT_FIELD_REF vect__6.6_10, 32, 64;
_29 = _2 + _12;
_30 = BIT_FIELD_REF vect__6.6_13, 32, 96;
_31 = BIT_FIELD_REF vect__6.6_10, 32, 96;
_32 = _30 + _31;
vect_sum_7.7_17 = {_15, _5, _29, _32};
stmp_sum_7.8_19 = _15;
stmp_sum_7.8_20 = _5;
stmp_sum_7.8_21 = stmp_sum_7.8_19 + stmp_sum_7.8_20;
stmp_sum_7.8_22 = _29;
stmp_sum_7.8_23 = stmp_sum_7.8_21 + _29;
stmp_sum_7.8_24 = _32;
stmp_sum_7.8_25 = stmp_sum_7.8_23 + _32;
vect_sum_7.9_26 = stmp_sum_7.8_25;
# .MEM_9 = VDEF .MEM_4
aD.1380 ={v} {CLOBBER};
# VUSE .MEM_9
return vect_sum_7.9_26;
;;succ: EXIT [100.0%]
Very strange that vectorizer seems to be kicking in with -mgeneral-regs-only
4.9.2:
;; basic block 2, loop depth 0, count 0, freq , maybe hot
;;prev block 0, next block 1, flags: (NEW, REACHABLE)
;;pred: ENTRY [100.0%] (FALLTHRU,EXECUTABLE)
# .MEM_4 = VDEF .MEM_3(D)
aD.1374[0] = 0;
# .MEM_5 = VDEF .MEM_4
aD.1374[1] = 1;
# .MEM_6 = VDEF .MEM_5
aD.1374[2] = 2;
# .MEM_7 = VDEF .MEM_6
aD.1374[3] = 3;
# .MEM_8 = VDEF .MEM_7
aD.1374[4] = 4;
# .MEM_9 = VDEF .MEM_8
aD.1374[5] = 5;
# .MEM_10 = VDEF .MEM_9
aD.1374[6] = 6;
# VUSE .MEM_10
_20 = aD.1374[0];
# VUSE .MEM_10
_29 = aD.1374[1];
sum_30 = _20 + _29;
# VUSE .MEM_10
_36 = aD.1374[2];
sum_37 = sum_30 + _36;
# VUSE .MEM_10
_43 = aD.1374[3];
sum_44 = sum_37 + _43;
# VUSE .MEM_10
_50 = aD.1374[4];
sum_51 = sum_44 + _50;
# VUSE .MEM_10
_57 = aD.1374[5];
sum_58 = sum_51 + _57;
# VUSE .MEM_10
_64 = aD.1374[6];
sum_65 = sum_58 + _64;
sum_14 = sum_65 + 7;
# .MEM_17 = VDEF .MEM_10
aD.1374 ={v} {CLOBBER};
# VUSE .MEM_17
return sum_14;
;;succ: EXIT [100.0%]
4.9's much saner.
[Bug middle-end/63735] [5.0 regression] 5% code size regression since 2014/10/13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63735 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Target Milestone|--- |5.0 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Can you bisect that to actual commits? Otherwise it's unlikely that somebody will feel guilty enough.
[Bug middle-end/63735] [5.0 regression] 5% code size regression since 2014/10/13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63735 --- Comment #2 from Richard Earnshaw rearnsha at gcc dot gnu.org --- I'll try, but with build breakage as well, it may not prove very much.
[Bug tree-optimization/63734] [5.0 regression] FAIL: gcc.dg/torture/vshuf-v8qi.c -O2 (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63734 --- Comment #1 from Marc Glisse glisse at gcc dot gnu.org --- My first impression is that this is a target issue, we should be able to call TARGET_VECTORIZE_VEC_PERM_CONST_OK from gimple. Either the target should avoid calling gen_reg_rtx when we are only calling the predicate, or it should do what is necessary to make gen_reg_rtx not fail. I am surprised because I would expect it to be reproducible (with a different testcase) without my patch, since vector lowering calls can_vec_perm_p. Does anyone have a different interpretation of what is happening?
[Bug fortran/61847] bug in gfortran runtime: digits cut off when reading floating point number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847 --- Comment #22 from Janne Blomqvist jb at gcc dot gnu.org --- (In reply to Tobias Burnus from comment #21) (In reply to Jerry DeLisle from comment #20) Created attachment 33858 [details] Proposed patch /* If the current locale is expecting a comma rather than a decimal point, convert it now. */ if (dtp-u.p.current_unit-decimal_locale == ',') *strchr (buffer, '.') = ','; In principle, there are more options than just , and .; for instance, in Britain, one often uses a centered dot (·) but that's not in the locale. Looking at the output of all my locales, I found: ps_AF.utf8: 0٫40 as the only locale which doesn't use either a '.' or a ','. Interesting.. still, Jerry's patch looks like an improvement over the status quo and should cover the vast majority of cases. Still, using a code like the following looks more robust. /* During _gfortran_st_read/write. */ const char *curr_locale = setlocale(LC_ALL, NULL); setlocale(LC_ALL, C); ... /* During _gfortran_st_read_done/write_done. */ setlocale(LC_ALL, curr_locale); I really don't think we should mess with setlocale(). It changes the process-wide locale, and if some other thread does something locale-dependent between our setlocale() calls there will be a bug in the user program which will be very hard to track down. As an aside, Jerry's patch suffers from similar issues, as the locale might be changed between checking the decimal separator (on OPEN) and using some locale-dependent functions. The robust solution really is to use strtod_l etc. as previously mentioned.
[Bug bootstrap/63714] AIX (5.3.7, xlC v11) fails to bootstrap for gcc 4.9.2, 4.8.3 and 4.7.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63714 --- Comment #9 from Michael Felt aixtools at gmail dot com --- While I may yet find a bug - my apologies for not better understanding the installation document. I see there is a better mail-list (gcc-help) and shall request assistance via that path. Thank you again for your assistance! FYI: gcc-4.7.4 seems to want to finish, but I am probably still not understand all of the instructions, e.g., where to place binutils so that they get used properly.
[Bug bootstrap/63714] AIX (5.3.7, xlC v11) fails to bootstrap for gcc 4.9.2, 4.8.3 and 4.7.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63714 --- Comment #10 from David Edelsohn dje at gcc dot gnu.org --- I had not realized that Bash-isms had crept into Autoconf, but I am not surprised. Using KSH to bootstrap is extremely slow and causes other problems. Both Bull Freeware for AIX and Perzl websites have RPMs for recent releases of GCC, so I do not understand the ancient comment. The GCC build process really wants any non-GCC bootstrap compiler to be called cc. If you want to add more options, you likely need to create a script in your $HOME/bin directory in your path and insert the option there.
[Bug bootstrap/63714] AIX (5.3.7, xlC v11) fails to bootstrap for gcc 4.9.2, 4.8.3 and 4.7.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63714 --- Comment #11 from David Edelsohn dje at gcc dot gnu.org --- Do not use GNU Binutils on AIX 5.3 (or later). GNU assembler and GNU linker do not work properly with recent releases of AIX. Installing GCC does not require installing all parts of the toolchain. Again, I strongly recommend that you simply use GCC from Bull Freeware or Perzl.
[Bug bootstrap/63714] AIX (5.3.7, xlC v11) fails to bootstrap for gcc 4.9.2, 4.8.3 and 4.7.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63714 --- Comment #12 from Michael Felt aixtools at gmail dot com --- I can try them again, but all the additional rpms that installing gcc requires tends to break things. I try to make as few assumptions about an environment as possible (such as bash installed on AIX). It may perform better, but I have never relied on it and it's differences are difficult for me. Additionally, as AIX is my focus, I cannot make the assumption that bash will be installed. I do not know about the BULL software, but as M Perlz is still making software for AIX 5.1 (as one example) I am unsure of the platform he is building on. I have tried this in the past, years ago, and understood gnu requirements even less than now. I do not expect it to be easy but do hope it can be accomplished by an 'expert-layman' compared to/with developer :smile: On Tue, Nov 4, 2014 at 2:59 PM, dje at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63714 --- Comment #10 from David Edelsohn dje at gcc dot gnu.org --- I had not realized that Bash-isms had crept into Autoconf, but I am not surprised. Using KSH to bootstrap is extremely slow and causes other problems. Both Bull Freeware for AIX and Perzl websites have RPMs for recent releases of GCC, so I do not understand the ancient comment. The GCC build process really wants any non-GCC bootstrap compiler to be called cc. If you want to add more options, you likely need to create a script in your $HOME/bin directory in your path and insert the option there. -- You are receiving this mail because: You reported the bug.
[Bug bootstrap/63714] AIX (5.3.7, xlC v11) fails to bootstrap for gcc 4.9.2, 4.8.3 and 4.7.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63714 --- Comment #13 from Michael Felt aixtools at gmail dot com --- As far as I know, GNU as and GNU ld have never been favored on AIX. And, they are LAST in the PATH variable. In the initial attempts I had read about the compare pass, that some hosts never succeed, and than a tool in binutils was missed in the make process. FYI: I only installed binutils after the first compare passes had failed. And, ultimately, I may (be forced to) follow your recommendation. Which I would consider a sad thing. On Tue, Nov 4, 2014 at 3:01 PM, dje at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63714 --- Comment #11 from David Edelsohn dje at gcc dot gnu.org --- Do not use GNU Binutils on AIX 5.3 (or later). GNU assembler and GNU linker do not work properly with recent releases of AIX. Installing GCC does not require installing all parts of the toolchain. Again, I strongly recommend that you simply use GCC from Bull Freeware or Perzl. -- You are receiving this mail because: You reported the bug.
[Bug c++/63736] New: gcc generated program with segfault on atomic exchange when the atomic variable is a member of a struct allocated with make_shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63736
Bug ID: 63736
Summary: gcc generated program with segfault on atomic exchange
when the atomic variable is a member of a struct
allocated with make_shared
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: leandrosansilva at gmail dot com
Created attachment 33882
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33882action=edit
self contained program which reproduces the problem
I am sending a sample code with a self contained program which declares a
struct called PStruct which contains a variable member which is an atomic of a
simple struct.
G++ compiles the code correctly, however it has a segmentation fault in a (IMO)
valid atomic exchance operation, when PStruct is allocated using make_shared,
but it does not happen when it's allocated using new operator.
In clang 3.5 the code generate a valid program, which runs as expected.
G++ info:
Using built-in specs.
COLLECT_GCC=g++-4.8
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.8.1-2ubuntu1~12.04' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.1 (Ubuntu 4.8.1-2ubuntu1~12.04)
The command line I am using to compile the code:
$ g++-4.8 -std=c++11 -Wall -Wextra atomic_of_struct_test.cpp -o
atomic_of_struct_test -lrt -latomic
The attached file reproduces the problem, because allocates using make_shared.
To allocate using new operator, comment line 34 and uncomment line 37.
The expected output in both allocation ways is:
field1: 2, field2: 4
The actual output when compiled with g++ is:
Segmentation fault (core dumped)
The backtrace of the later execution:
#0 0x77bd5897 in ?? () from /usr/lib/x86_64-linux-gnu/libatomic.so.1
No symbol table info available.
#1 0x00401186 in std::atomicTwoFieldStruct::exchange (this=0x604028,
__i=..., _m=std::memory_order_seq_cst) at /usr/include/c++/4.8/atomic:225
tmp = {
field1 = 140737488346624,
field2 = 4198920
}
#2 0x004010e3 in PStruct::setMs (this=0x604028, ms=...) at
atomic_of_struct_test.cpp:18
No locals.
#3 0x00400f81 in main () at atomic_of_struct_test.cpp:39
ms = {
field1 = 2,
field2 = 4
}
ptr = std::shared_ptr (count 1, weak 0) 0x604028
oms = {
field1 = 0,
field2 = 4197680
}
[Bug c++/63736] gcc generated program with segfault on atomic exchange when the atomic variable is a member of a struct allocated with make_shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63736 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Severity|blocker |normal
[Bug c++/63736] gcc generated program with segfault on atomic exchange when the atomic variable is a member of a struct allocated with make_shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63736 --- Comment #1 from Leandro Santiago leandrosansilva at gmail dot com --- I forgot to mention I am using Ubuntu 12.04 64-bit on a i7 machine and kernel 3.8.0.
[Bug c++/63723] Narrowing conversion allowed in braced init list in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63723 --- Comment #4 from Tavian Barnes tavianator at gmail dot com --- Still happens with 4.9.2 though. Is a backport of the fix possible?
[Bug middle-end/63735] [5.0 regression] 5% code size regression since 2014/10/13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63735 --- Comment #3 from Richard Earnshaw rearnsha at gcc dot gnu.org --- regression is caused by the switch to GNU11. Adding -std=gnu90 gives expected numbers. That's a pretty big penalty for using GNU11 coding!
[Bug c/63737] New: Missed optimization: -ffixed-reg and unelided copies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63737
Bug ID: 63737
Summary: Missed optimization: -ffixed-reg and unelided copies
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: tstache1 at binghamton dot edu
Excuse me if I'm misunderstanding the semantics of -ffixed-reg and pinned
registers, but take this trivial example:
#include emmintrin.h
register __m128i fixed_reg_1 __asm__ (xmm6);
register __m128i fixed_reg_2 __asm__ (xmm7);
__m128i xmm_add(__m128i a, __m128i b) {
__m128i dest;
fixed_reg_1 = a + b;
fixed_reg_2 = fixed_reg_1 + b;
dest = fixed_reg_1 + fixed_reg_2;
return dest;
}
Compiling it (-c -O2 -ffixed-xmm6 -ffixed-reg-xmm7 -mavx) seems to produce the
following, non-optimal code (the compiler does not elide the copies):
xmm_add:
0:c5 f9 d4 c1 vpaddq %xmm1,%xmm0,%xmm0
4:c5 f9 6f f0 vmovdqa %xmm0,%xmm6
8:c5 f1 d4 c0 vpaddq %xmm0,%xmm1,%xmm0
c:c5 f9 6f f8 vmovdqa %xmm0,%xmm7
10:c5 f9 d4 c6 vpaddq %xmm6,%xmm0,%xmm0
14:c3 retq
Ideally, I would think that the compiler should generate code like so, no?
xmm_add_opt:
0:c5 f9 d4 f1 vpaddq %xmm1,%xmm0,%xmm6
4:c5 f1 d4 fe vpaddq %xmm6,%xmm1,%xmm7
8:c5 c1 d4 c6 vpaddq %xmm6,%xmm7,%xmm0
c:c3 retq
[Bug middle-end/63735] [5.0 regression] 5% code size regression since 2014/10/13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63735 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Huh! I suppose it might be the different semantics of inline then? ISTR CSiBE is mostly composed of an (old) linux kernel build.
[Bug rtl-optimization/63737] Missed optimization: -ffixed-reg and unelided copies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63737 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||ra Status|UNCONFIRMED |RESOLVED Component|c |rtl-optimization Resolution|--- |WONTFIX --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- -ffixed-reg and esp. global register vars are not a tool for optimization.
[Bug middle-end/62289] [5 Regression] ICE (segfault) for gfortran.dg/graphite/pr42393.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62289 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org --- ISL 0.14 has been released, cf. https://gcc.gnu.org/ml/gcc/2014-11/msg00038.html
[Bug middle-end/63735] [5.0 regression] 5% code size regression since 2014/10/13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63735 --- Comment #5 from Richard Earnshaw rearnsha at gcc dot gnu.org --- Yeah, all the changes are in the linux kernel module. It's only one component of the benchmark (though probably the largest). Adding -fgnu89-inline is also sufficient to fix the code size regression. Increased compile times are (probably) just a side effect of generating the additional code.
[Bug bootstrap/63714] AIX (5.3.7, xlC v11) fails to bootstrap for gcc 4.9.2, 4.8.3 and 4.7.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63714
--- Comment #14 from Michael Felt aixtools at gmail dot com ---
Please accept my apologies for replying here, the gcc-help is not a high
traffic list today :) and I removed myself from the gcc-bugs list.
I checked out the BULL and Perlz sites (I am slowly building one of my own, no
advertisement here) and there are two concerns:
For AIX 5.3 (TL7) - which is the base level I am trying to build from (not
concerned with AIX 5.3 TL6 and earlier - need to draw a line somewhere) I am
packaging tools in /opt/{bin,sbin,lib,include} and /opt/aixtools/{...}.
The reasoning is simple: in /opt/freeware IBM, BULL and perlz put their
software. And, if I understand perlz correctly I continue having dependencies
in files
placed there - packaged as RPM. I am not packaging as RPM and do not want to
have
to worry if something I build overwrites an IBM file and vice versa.
So, I am back at my original reason for not wanting to even use these compilers
as a baseline: they set dependencies to where things go. If Michael Perlz could
not change that, I have no illusion that I will succeed there suddenly.
Generally speaking the perlz distribution is fairly recent, BULL is oldish.
BULL
gcc-4.6.1-1.aix5.3.ppc.rpm
libgcc-4.6.1-1.aix5.3.ppc.rpm
gmp-5.0.2-1.aix5.3.ppc.rpm
libiconv-1.13.1-2.aix5.3.ppc.rpm
gettext-0.17-6.aix5.3.ppc.rpm
libmpc-0.9-1.aix5.3.ppc.rpm
mpfr-3.0.1-1.aix5.3.ppc.rpm
zlib-1.2.5-2.aix5.3.ppc.rpm
info-4.13-3.aix5.3.ppc.rpm
bash-4.2-5.aix5.3.ppc.rpm
Perlz has 4.8.2 compiled for AIX 5.3, comparably current dependencies
[Bug bootstrap/63714] AIX (5.3.7, xlC v11) fails to bootstrap for gcc 4.9.2, 4.8.3 and 4.7.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63714 --- Comment #15 from David Edelsohn dje at gcc dot gnu.org --- GNU as and GNU ld do not consistently generate correct object files and executables on AIX. AIX 5.2, 5.3, 6.1, and 7.1 continued to extend and adjust the XCOFF object file format, and the GNU tools were too lax with what they generated for undefined fields. Shared libraries don't work quite right. It is regrettable that the GNU tools don't work. KSH on AIX is very old. It does not support some new constructs. And GNU Autoconf makes very aggressive use of saving and restoring state, such as IFS. KSH on AIX uses temporary files while Bash uses memory. The file operations cause the entire configure process to be unbearably and unnecessarily slow. I do not understand what you are trying to accomplish by installing GCC but not installing other packages on which GCC depends. One can bootstrap GCC on AIX, but you appear to be imposing conflicting requirements about the software dependencies. To provide full ISO C, ISO C++, etc. conformance, and to simplify the build process, building GCC depends on a lot of other libraries and tools.
[Bug bootstrap/63714] AIX (5.3.7, xlC v11) fails to bootstrap for gcc 4.9.2, 4.8.3 and 4.7.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63714 --- Comment #16 from David Edelsohn dje at gcc dot gnu.org --- Bull Freeware provides GCC 4.8.1 for AIX 6.1. I do not know why they only provide GCC 4.6.1 for AIX 7.1. AIX 5.3 no longer is supported by IBM and newer features in GCC require object file and OS feature not provided by AIX 5.3. If a customer continues to run AIX 5.3 because they want the system to remain stable for some legacy software, I do not understand why installing the latest release of GCC would be a priority.
[Bug middle-end/63735] [5.0 regression] 5% code size regression since 2014/10/13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63735 --- Comment #6 from Richard Earnshaw rearnsha at gcc dot gnu.org --- Confirmed that the compilation time regression is related entirely to the extra code generated.
[Bug bootstrap/63714] AIX (5.3.7, xlC v11) fails to bootstrap for gcc 4.9.2, 4.8.3 and 4.7.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63714 --- Comment #17 from Michael Felt aixtools at gmail dot com --- The problem is not installing other tools. Of course I will do that. It is an issue on AIX because will buildable they are not there by default. In a linux stack they are nearly native. I do not want to be dependent on something I cannot recreate - especially if it sets boundaries. What also is not forgotten by me: Years ago I was trying to package, even limit it to just make install in place, and ran into considerable issues - and grew tired of the comment of not having the latest tools (just the latest I could download). Currently there are some (gnu) projects that no longer attempt to be what I would call 'portable'. That is, some developers equate being able to compile on gcc (which is portable) as portable programming. That was not the definition I learned. I am not asking, or even expecting for it to be easy to start late in the game. I know there is a lot I do not know - and I will need pointers. And, hopefully, someone will be slightly interested in the assumptions that get laid bare. In short, why AIX 5.3 - for compatibility, not because someone is limited to that level of AIX. Almost anything compiled on AIX 5.3 will run unchanged on AIX 5.3, AIX 6.1 and AIX 7.1. If compiled on AIX 7.1 it will not run on AIX 6.1 or AIX 5.3. That simple (from my perspective).
[Bug middle-end/63735] [5.0 regression] 5% code size regression since 2014/10/13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63735 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #7 from Andrew Pinski pinskia at gcc dot gnu.org --- Closing as invalid as the semantics of inline is different between gnu89 and c99.
[Bug target/63679] [5.0 Regression][AArch64] Failure to constant fold.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
--- Comment #3 from Tejas Belagod belagod at gcc dot gnu.org ---
When I try 5.0 with -fno-tree-vectorize, I get:
;; basic block 2, loop depth 0
;;pred: ENTRY
# .MEM_4 = VDEF .MEM_3(D)
aD.2496 = *.LC0D.2503;
# VUSE .MEM_4
_10 = aD.2496[0];
# VUSE .MEM_4
_22 = aD.2496[1];
sum_23 = _10 + _22;
# VUSE .MEM_4
_29 = aD.2496[2];
sum_30 = sum_23 + _29;
# VUSE .MEM_4
_36 = aD.2496[3];
sum_37 = sum_30 + _36;
# VUSE .MEM_4
_43 = aD.2496[4];
sum_44 = sum_37 + _43;
# VUSE .MEM_4
_50 = aD.2496[5];
sum_51 = sum_44 + _50;
# VUSE .MEM_4
_57 = aD.2496[6];
sum_58 = sum_51 + _57;
# VUSE .MEM_4
_6 = aD.2496[7];
sum_7 = _6 + sum_58;
# .MEM_9 = VDEF .MEM_4
aD.2496 ={v} {CLOBBER};
# VUSE .MEM_9
return sum_7;
;;succ: EXIT
This:
# .MEM_4 = VDEF .MEM_3(D)
aD.2496 = *.LC0D.2503;
is what's mainly different from 4.9. 5.0 seems to use a TImode load to
initialize the stack with the const array.
(insn 10 9 11 (set (mem/c:TI (reg:DI 91) [1 aD.2496+0 S16 A128])
(reg:TI 93)) foo.c:4 -1
(nil))
(insn 11 10 12 (set (reg:TI 94)
(mem/u/c:TI (plus:DI (reg:DI 92)
(const_int 16 [0x10])) [0 S16 A32])) foo.c:4 -1
(nil))
(insn 12 11 0 (set (mem/c:TI (plus:DI (reg:DI 91)
(const_int 16 [0x10])) [1 aD.2496+16 S16 A128])
(reg:TI 94)) foo.c:4 -1
(nil))
;; sum_23 = _10 + _22;
(insn 13 12 14 (set (reg:SI 95)
(mem/c:SI (plus:DI (reg/f:DI 68 virtual-stack-vars)
(const_int -32 [0xffe0])) [1 aD.2496+0 S4 A128]))
foo.c:9 -1
(nil))
When DSE wants to optimize it away, it fails to extract SI values from the
TImode stores:
**scanning insn=14
cselib lookup (reg/f:DI 64 sfp) = 3:3
cselib value 6:4299 0x2f6de50 (plus:DI (reg/f:DI 64 sfp)
(const_int -28 [0xffe4]))
cselib lookup (plus:DI (reg/f:DI 64 sfp)
(const_int -28 [0xffe4])) = 6:4299
mem: (plus:DI (reg/f:DI 64 sfp)
(const_int -28 [0xffe4]))
after canon_rtx address: (plus:DI (reg/f:DI 64 sfp)
(const_int -28 [0xffe4]))
gid=0 offset=-28
processing const load gid=0[-28..-24)
trying to replace SImode load in insn 14 from TImode store in insn 10
(lshiftrt:DI (reg:DI 105)
(const_int 32 [0x20]))
Hot cost: 8 (final)
-- could not extract bits of stored value
removing from active insn=10 has store
mems_found = 0, cannot_delete = true
cselib lookup (mem/c:SI (plus:DI (reg/f:DI 64 sfp)
(const_int -28 [0xffe4])) [1 aD.2496+4 S4 A32]) = 0:0
**scanning insn=15
[Bug c/63738] New: ssa corruption when compiled with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63738 Bug ID: 63738 Summary: ssa corruption when compiled with -O3 Product: gcc Version: tree-ssa Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: guido at fceia dot unr.edu.ar Created attachment 33883 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33883action=edit The data about the bug
[Bug tree-optimization/63738] [5 Regression] ssa corruption when compiled with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63738 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Version|tree-ssa|5.0 Last reconfirmed||2014-11-04 Component|c |tree-optimization CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 Summary|ssa corruption when |[5 Regression] ssa |compiled with -O3 |corruption when compiled ||with -O3 Target Milestone|--- |5.0 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed.
[Bug fortran/63640] move_alloc memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63640 --- Comment #2 from patnel97269-gfortran at yahoo dot fr --- Thanks for the tip and the comment. So the standard say that move_alloc deallocate the array from. Does that mean that the compiler mark the array as not allocated but does not free the memory ?
[Bug target/63293] [AArch64] can read from deallocated stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63293 --- Comment #4 from Jiong Wang jiwang at gcc dot gnu.org --- Author: jiwang Date: Tue Nov 4 17:13:25 2014 New Revision: 217091 URL: https://gcc.gnu.org/viewcvs?rev=217091root=gccview=rev Log: [AArch64] fix unsafe access to deallocated stack 2014-11-04 Jiong Wang jiong.w...@arm.com 2014-11-04 Wilco Dijkstra wilco.dijks...@arm.com gcc/ PR target/63293 * config/aarch64/aarch64.c (aarch64_expand_epiloue): Add barriers before stack adjustment. Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64.c
[Bug target/63293] [AArch64] can read from deallocated stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63293 Jiong Wang jiwang at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jiong Wang jiwang at gcc dot gnu.org --- mark as fixed.
[Bug tree-optimization/63738] [5 Regression] ssa corruption when compiled with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63738 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added CC||glisse at gcc dot gnu.org --- Comment #2 from Marc Glisse glisse at gcc dot gnu.org --- Most likely my fault :-( Might have to revert until I have time to fix it...
[Bug c++/63739] New: template id needed for constructor inheritance with using keyword
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63739
Bug ID: 63739
Summary: template id needed for constructor inheritance with
using keyword
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: darkdragon-001 at web dot de
There are problems with automatically determining the template id when
inheriting constructors with using keyboard.
In the following example there is only one case (out of four) which works as
expected (- see NOTE comments)
#include iostream
#include utility
class A : public std::pairint,bool {
// NOTE here it is not possible to ommit the template id
// EXPECTED using std::pair::pair;
using std::pairint,bool::pair;
};
templateclass T
class B : public std::pairT,bool {
// NOTE here it is not possible to ommit the template id
// EXPECTED using std::pair::pair;
using std::pairT,bool::pair;
};
// NOTE following examples use namespace std
using namespace std;
class C : public pairint,bool {
using pair::pair;
};
templateclass T
class D : public pairT,bool {
// NOTE here it is not possible to ommit the template id
// EXPECTED using pair::pair;
using pairT,bool::pair;
};
int main() {
A a(5,true);
cout a.first: a.first endl;
Bint b(5,true);
cout b.first: b.first endl;
C c(5,true);
cout c.first: c.first endl;
Dint d(5,true);
cout d.first: d.first endl;
return 0;
}
[Bug c++/63739] template id needed for constructor inheritance with using keyword
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63739 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- This is the correct behaviour required by the standard. std::pair is not a type, so you cannot say using std::pair::pair In a non-template you can say using pair::pair which finds the injected class name from the base class. In a template when std::pairA,B is a dependent base class the injected class name is not visible because name lookup does not consider dependent base classes, so you cannot say using pair::pair
[Bug target/63691] GCC 4.9.x fails to build GLIBC 2.20 on HPPA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63691 --- Comment #13 from Aaro Koskinen aaro.koskinen at iki dot fi --- Created attachment 33884 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33884action=edit Preprocessed dl-conflict Here's the preprocessed dl-conflict.c. In elf_machine_rela(), the sym_map gets always assigned to 0, and in the following switch cases it's dereferenced without any checks. Those are where the compiler will add abort refs. When compiled with -fno-delete-null-pointer-checks GCC won't do that, but it's not really related to any null pointer checks, instead the switch has also other meanings, i.e. it's also telling the compiler that NULL deref is not erroneous so it cannot make program fail on those. Or at least that's how I understand it.
[Bug target/57792] toplevel configure should enable --with-sysroot=`xcrun --show-sdk-path` for darwin13 and later
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792 howarth at bromo dot med.uc.edu changed: What|Removed |Added CC||howarth at bromo dot med.uc.edu --- Comment #10 from howarth at bromo dot med.uc.edu --- (In reply to Hin-Tak Leung from comment #9) Did the change make it into 4.9.2? I recently tried that and found that I need the explicit --sysroot: https://gcc.gnu.org/ml/gcc-testresults/2014-11/msg00268.html Otherwise it fails during the stage1-fixincludes stage. (luckily I saw the tips and reference to this bug report in the older buildstat). This change was reverted when Apple abandoned the idea of removing the /usr/include. They didn't appreciate the number of packages (like python) which would require the changes to also find the new location of the /usr/include.
[Bug target/57792] toplevel configure should enable --with-sysroot=`xcrun --show-sdk-path` for darwin13 and later
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792 --- Comment #11 from howarth at bromo dot med.uc.edu --- (In reply to Hin-Tak Leung from comment #9) Did the change make it into 4.9.2? I recently tried that and found that I need the explicit --sysroot: https://gcc.gnu.org/ml/gcc-testresults/2014-11/msg00268.html Also, if you can't find /usr/include on OS X, that means you need to install the Command Line Tools with 'xcode-select --install'.
[Bug c++/63730] C++11 ICE REGRESSION mangling template alias into function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63730 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com --- The same problem exists for gcc HEAD 5.0.0 20141104 (experimental)
[Bug tree-optimization/63738] [4.9/5 Regression] ssa corruption when compiled with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63738
Marc Glisse glisse at gcc dot gnu.org changed:
What|Removed |Added
Summary|[5 Regression] ssa |[4.9/5 Regression] ssa
|corruption when compiled|corruption when compiled
|with -O3|with -O3
--- Comment #3 from Marc Glisse glisse at gcc dot gnu.org ---
Actually no, this isn't related to my clobber patch, I can reproduce with 4.9.
// gcc bug.c -c -O3 -std=gnu99
typedef long __jmp_buf[8];
typedef struct
{
unsigned long int __val[16];
} __sigset_t;
struct __jmp_buf_tag
{
__jmp_buf __jmpbuf;
int __mask_was_saved;
__sigset_t __saved_mask;
};
typedef struct __jmp_buf_tag jmp_buf[1];
extern int _setjmp (struct __jmp_buf_tag __env[1]) __attribute__
((__nothrow__));
struct longjmp_buffer {
jmp_buf buf;
};
void plouf();
extern long interprete()
{
long * sp;
struct longjmp_buffer raise_buf;
_setjmp (raise_buf.buf);
plouf();
sp -= 4;
int n;
long * args;
for (int i = 0; i n; i++)
args[i] = sp[10-i];
plouf();
return 0;
}
$ gcc bug.c -c -O3 -std=gnu99
Unable to coalesce ssa_names 2 and 12 which are marked as MUST COALESCE.
sp_2(ab) and sp_12(ab)
bug.c: In function ‘interprete’:
bug.c:27:13: internal compiler error: SSA corruption
extern long interprete()
^
[Bug bootstrap/63740] New: GCC 4.9.2 bootstrap fails on ARM, haifa-sched.c:6507:1: internal compiler error: in lra_create
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63740 Bug ID: 63740 Summary: GCC 4.9.2 bootstrap fails on ARM, haifa-sched.c:6507:1: internal compiler error: in lra_create Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: aaro.koskinen at iki dot fi GCC 4.9.2 native bootstrap on ARM fails with ICE from the second stage compiler: /home/aaro/gcctest/build/./prev-gcc/xg++ -B/home/aaro/gcctest/build/./prev-gcc/ -B/usr/local/arm-unknown-linux-gnueabi/bin/ -nostdinc++ -B/home/aaro/gcctest/build/prev-arm-unknown-linux-gnueabi/libstdc++-v3/src/.libs -B/home/aaro/gcctest/build/prev-arm-unknown-linux-gnueabi/libstdc++-v3/libsupc++/.libs -I/home/aaro/gcctest/build/prev-arm-unknown-linux-gnueabi/libstdc++-v3/include/arm-unknown-linux-gnueabi -I/home/aaro/gcctest/build/prev-arm-unknown-linux-gnueabi/libstdc++-v3/include -I/home/aaro/gcctest/gcc-4.9.2/libstdc++-v3/libsupc++ -L/home/aaro/gcctest/build/prev-arm-unknown-linux-gnueabi/libstdc++-v3/src/.libs -L/home/aaro/gcctest/build/prev-arm-unknown-linux-gnueabi/libstdc++-v3/libsupc++/.libs -c -g -O2 -gtoggle -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.9.2/gcc -I../../gcc-4.9.2/gcc/. -I../../gcc-4.9.2/gcc/../include -I../../gcc-4.9.2/gcc/../libcpp/include -I../../gcc-4.9.2/gcc/../libdecnumber -I../../gcc-4.9.2/gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc-4.9.2/gcc/../libbacktrace-o haifa-sched.o -MT haifa-sched.o -MMD -MP -MF ./.deps/haifa-sched.TPo ../../gcc-4.9.2/gcc/haifa-sched.c ../../gcc-4.9.2/gcc/haifa-sched.c: In function 'bool schedule_block(basic_block_def**, state_t)': ../../gcc-4.9.2/gcc/haifa-sched.c:6507:1: internal compiler error: in lra_create_copy, at lra.c:1532 } ^ 0x8a2ac7 lra_create_copy(int, int, int) ../../gcc-4.9.2/gcc/lra.c:1532 0x8cbaaf process_bb_lives ../../gcc-4.9.2/gcc/lra-lives.c:568 0x8cd583 lra_create_live_ranges(bool) ../../gcc-4.9.2/gcc/lra-lives.c:1008 0x8a51ef lra(_IO_FILE*) ../../gcc-4.9.2/gcc/lra.c:2372 0x83df07 do_reload ../../gcc-4.9.2/gcc/ira.c:5457 0x83e35b rest_of_handle_reload ../../gcc-4.9.2/gcc/ira.c:5598 0x83e3d3 execute ../../gcc-4.9.2/gcc/ira.c:5627 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. The host GCC is 4.9.2 (cross-compiled on x86_64 using GCC 4.9.2). Configure command for bootstrap was: $ ../gcc-4.9.2/configure --with-arch=armv4t --with-float=soft --disable-nls --enable-languages=c,c++ --host=arm-unknown-linux-gnueabi --build=arm-unknown-linux-gnueabi --target=arm-unknown-linux-gnueabi --with-system-zlib --with-sysroot=/ --disable-static --enable-shared
[Bug c++/63732] constexpr is not constant expression, when cast member data pointer to data parent type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63732 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com --- I disagree with your interpretation. Note that in your code example for yyy there is an effective C-cast or reinterpret_cast. This is so, because your are attempting to convert an address to a pointer of member of type Number ComplexProperty::* to PropertyBase ComplexProperty::* Irrespective of the private base classes, this kind of pointer conversion is not allowed without a reinterpret_cast, but reinterpret_casts are not valid in constants expressions. The conversion to xxx is valid, because there is no type change involved (Number ComplexProperty::* is converted to Number ComplexProperty::*) and for the out-of-class member ComplexProperty::m_members definition the code is well-formed, because you do have an effective reinterpret_cast but not in a place where a constant expression would be required.
[Bug regression/61887] vect.exp UNRESOLVED tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61887 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Indeed.
[Bug target/63679] [5.0 Regression][AArch64] Failure to constant fold.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|--- |5.0 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- I will have a look. Note that 4.9 simply didn't vectorize this. And note that unfortunately only FRE/PRE have a chance to optimize this but they do not run that late. Jakub wanted to enable FRE late for some other PR. Tejas, can you try Index: passes.def === --- passes.def (revision 217035) +++ passes.def (working copy) @@ -255,7 +255,7 @@ NEXT_PASS (pass_reassoc); NEXT_PASS (pass_strength_reduction); NEXT_PASS (pass_tracer); - NEXT_PASS (pass_dominator); + NEXT_PASS (pass_fre); NEXT_PASS (pass_strlen); NEXT_PASS (pass_vrp); /* The only const/copy propagation opportunities left after ?
[Bug bootstrap/63740] [4.9 Regression] GCC 4.9.2 bootstrap fails on ARM, haifa-sched.c:6507:1: internal compiler error: in lra_create
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63740 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-11-04 Target Milestone|--- |4.9.3 Summary|GCC 4.9.2 bootstrap fails |[4.9 Regression] GCC 4.9.2 |on ARM, |bootstrap fails on ARM, |haifa-sched.c:6507:1: |haifa-sched.c:6507:1: |internal compiler error: in |internal compiler error: in |lra_create |lra_create Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Can you provide preprocessed source of haifa-sched.c for the failing command?
[Bug tree-optimization/63738] [4.9/5 Regression] ssa corruption when compiled with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63738 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Mine.
[Bug bootstrap/63740] [4.9 Regression] GCC 4.9.2 bootstrap fails on ARM, haifa-sched.c:6507:1: internal compiler error: in lra_create
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63740 --- Comment #2 from Aaro Koskinen aaro.koskinen at iki dot fi --- Created attachment 33885 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33885action=edit haifa-sched preprocessed source This is the preprocessed source of haifa-sched produced with full original xg++ command line with -E added. I had to compress it as the plain/text version exceeded the 1000 KB attachment limit.
[Bug c++/63732] constexpr is not constant expression, when cast member data pointer to data parent type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63732 Pavel Král pavel.kral at omsquare dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Pavel Král pavel.kral at omsquare dot com --- Hi Daniel, your are right about effective reintepret_cast, thanks for clarification. Best Regards, Pavel
[Bug debug/63741] New: lm32 ICE in dwarf2out_frame_debug_expr, at dwarf2cfi.c:1677
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63741 Bug ID: 63741 Summary: lm32 ICE in dwarf2out_frame_debug_expr, at dwarf2cfi.c:1677 Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: joel at gcc dot gnu.org Created attachment 33886 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33886action=edit Preprocessed RTEMS fastlz.c which produces the error. The attached preprocessed code gives an ICE at -O0, -O1, -O2, and -0s. Dropping the -g gets by the ICE so this seems like a debug info issue. lm32-rtems4.11-gcc -O0 -g -c fastlz.c lm32-rtems4.11-gcc --pipe -DHAVE_CONFIG_H -I.. -I../../cpukit/../../../milkymist/lib/include -DRTEMS_RTL_RAP_LOADER=1 -DRTEMS_RTL_ELF_LOADER=1 -mbarrel-shift-enabled -mmultiply-enabled -mdivide-enabled -msign-extend-enabled -O2 -g -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -MT libdl_a-fastlz.o -MD -MP -MF .deps/libdl_a-fastlz.Tpo -c -o libdl_a-fastlz.o `test -f 'fastlz.c' || echo '../../../../../../rtems/c/src/../../cpukit/libdl/'`fastlz.c In file included from ../../../../../../rtems/c/src/../../cpukit/libdl/fastlz.c:113:0: ../../../../../../rtems/c/src/../../cpukit/libdl/fastlz.c: In function 'fastlz1_compress': ../../../../../../rtems/c/src/../../cpukit/libdl/fastlz.c:418:1: internal compiler error: in dwarf2out_frame_debug_expr, at dwarf2cfi.c:1677 } ^ 0x52e8b6 dwarf2out_frame_debug_expr ../../gcc-4.9.1/gcc/dwarf2cfi.c:1675 0x52ef6c dwarf2out_frame_debug ../../gcc-4.9.1/gcc/dwarf2cfi.c:2043 0x52ef6c scan_insn_after ../../gcc-4.9.1/gcc/dwarf2cfi.c:2369 0x5307d2 scan_trace ../../gcc-4.9.1/gcc/dwarf2cfi.c:2526 0x5311d5 create_cfi_notes ../../gcc-4.9.1/gcc/dwarf2cfi.c:2565 0x5311d5 execute_dwarf2_frame ../../gcc-4.9.1/gcc/dwarf2cfi.c:2925 0x5311d5 execute ../../gcc-4.9.1/gcc/dwarf2cfi.c:3421 Please submit a full bug report, with preprocessed source if appropriate.
[Bug c++/63736] gcc generated program with segfault on atomic exchange when the atomic variable is a member of a struct allocated with make_shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63736 --- Comment #2 from Leandro Santiago leandrosansilva at gmail dot com --- I tested the same program again with gcc from master branch from today and it worked as expected, generated a runnable executable. Is it possible to backport whichever the solution is to gcc 4.8? [1] COLLECT_GCC=/home/tenchi/programs/gcc/bin/g++ COLLECT_LTO_WRAPPER=/home/tenchi/programs/gcc/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../configure --prefix=/home/tenchi/programs/gcc --enable-debug --enable-lto Thread model: posix gcc version 5.0.0 20141104 (experimental) (GCC)
[Bug tree-optimization/61515] [4.9/5 Regression] Extremely long compile time for generated code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61515 --- Comment #23 from Jeffrey A. Law law at redhat dot com --- The piece you're missing in this is that when we seen an assignment to some SSA_NAME, call it LHS and we've traversed a backedge, then we have to walk through all the equivalences and see if there's anything that's been marked as equivalent to LHS and invalidate those. Then we also ahve to invalidate LHS. for (unsigned int i = 1; i num_ssa_names; i++) if (ssa_name (i) SSA_NAME_VALUE (ssa_name (i)) == lhs) record_temporary_equivalence (ssa_name (i), NULL_TREE, stack); if (SSA_NAME_VALUE (lhs)) record_temporary_equivalence (lhs, NULL_TREE, stack); The loop finds handles things equivalent to LHS, the second handles LHS itself. Both are required for correctness. In the past there was a map similar to your implementation, but it's not sufficient. See pr61289.C and pr61289-2.C. The problem is you may need to invalidate equivalences that are created *outside* tree-ssa-threadedge.c. So any attempts to track inside tree-ssa-threadedge are not sufficient for correctness. What's still not clear to me here is *why* we're calling the invalidation code in the first place. It's only supposed to be called when we encounter a statement which produces an output that we can't handle *and* we've traversed a backedge. The combination of those two events is supposed to be very rare. Otherwise the invalidation is obviously too expensive. That's why I suggested in c#12 that we need to look at *why* we're calling the invalidation code at all.
[Bug debug/63741] lm32 ICE in dwarf2out_frame_debug_expr, at dwarf2cfi.c:1677
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63741 Joel Sherrill joel at gcc dot gnu.org changed: What|Removed |Added Known to fail||4.9.1 --- Comment #1 from Joel Sherrill joel at gcc dot gnu.org --- Confirmed in lm32-rtems4.11-gcc (GCC) 4.9.2 20141028 (prerelease) But now at: $ ~/test-gcc/install-head/bin/lm32-rtems4.11-gcc -O2 -g -c /tmp/fastlz.c In file included from ../../../../../../rtems/c/src/../../cpukit/libdl/fastlz.c:113:0: ../../../../../../rtems/c/src/../../cpukit/libdl/fastlz.c: In function 'fastlz1_compress': ../../../../../../rtems/c/src/../../cpukit/libdl/fastlz.c:418:1: internal compiler error: in dwarf2out_frame_debug_expr, at dwarf2cfi.c:1675 0x52ddb0 dwarf2out_frame_debug_expr ../../gcc/gcc/dwarf2cfi.c:1675 0x52e3ac dwarf2out_frame_debug ../../gcc/gcc/dwarf2cfi.c:2043 0x52e3ac scan_insn_after ../../gcc/gcc/dwarf2cfi.c:2369 0x52fc37 scan_trace ../../gcc/gcc/dwarf2cfi.c:2526 0x530690 create_cfi_notes ../../gcc/gcc/dwarf2cfi.c:2565 0x530690 execute_dwarf2_frame ../../gcc/gcc/dwarf2cfi.c:2925 0x530690 execute ../../gcc/gcc/dwarf2cfi.c:3421 Please submit a full bug report, with preprocessed source if appropriate.
[Bug go/63269] libgo/math test failures in TestLog2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63269 Ian Lance Taylor ian at airs dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-11-05 Ever confirmed|0 |1 --- Comment #3 from Ian Lance Taylor ian at airs dot com --- First, let me say that this code is in the Go master library and must be fixed there. It might be more effective to discuss it on the Go issue tracker at http://golang.org/issue. I don't agree with your argument for item 1. You say that the wrong result happens when using a fused multiply-add instruction. The math library is compiled with -ffp-contract=off (see MATH_FLAG in configure.ac and Makefile.am), so the compiler should not be generating a fused multiply-add instruction. I'm not entirely persuaded by your argument for item 2. Zero is a special value. When we expect a zero, we should get a zero, not something close to zero. I don't think this change is correct in general. It may be correct for some specific cases, but then we need to investigate those. Item 3 is the same sort of thing: when we expect zero, we should, in general, get exactly zero.
[Bug target/57792] toplevel configure should enable --with-sysroot=`xcrun --show-sdk-path` for darwin13 and later
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792 --- Comment #12 from Hin-Tak Leung htl10 at users dot sourceforge.net --- (In reply to howarth from comment #10) This change was reverted when Apple abandoned the idea of removing the /usr/include. They didn't appreciate the number of packages (like python) which would require the changes to also find the new location of the /usr/include. (In reply to howarth from comment #11) Also, if you can't find /usr/include on OS X, that means you need to install the Command Line Tools with 'xcode-select --install'. Have Apple really abandoned the idea of removing /usr/include ? xcode 6.1 ships all the headers under the SDK places; indeed as you said, running 'xcode-select --install' prompts for installing the command line developer's tools, which seems to install /usr/include ; but the Command Line Developer's Tool installed this way is only version 5.1 (i.e. against an older version of xcode, I think). Also I think it could be a bit more user friendly - e.g. test for the existence of /usr/include, and set --with-sysroot=\`xcrun --show-sdk-path`\ if /usr/include does not exist? It isn't much more code, but would make a lot of difference in user-friendliness.
[Bug other/63699] bootstrap fails with Apple clang 6.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63699 Andreas Tobler andreast at gcc dot gnu.org changed: What|Removed |Added CC||andreast at gcc dot gnu.org --- Comment #2 from Andreas Tobler andreast at gcc dot gnu.org --- Cross compilation with clang is also affected. amd64-*-freebsd* - arm-*-freebsd* fails with the same error. The snippet attached to this report 'solves' the issue for me. Thanks!
[Bug target/63742] New: arm *movhi_insn_arch4 pattern may emit ldrh which is wrong for big-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63742
Bug ID: 63742
Summary: arm *movhi_insn_arch4 pattern may emit ldrh which is
wrong for big-endian
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: fei.yang0953 at gmail dot com
CC: ramana.radhakrishnan at arm dot com
Host: x86_64-suse-linux
Target: armeb-linux-gnueabi-gcc
Build: x86_64-suse-linux
Simple testcase (test.c):
unsigned short v;
int i;
int j = 0;
int *ptr = j;
unsigned short func()
{
for (i = 0; i 1; ++i)
{
*ptr = -1;
v = 0x1234;
}
return v;
}
Compile option: armeb-linux-gnueabi-gcc -S -O1 test.c
Assembly code snippet:
func:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
str lr, [sp, #-4]!
movwr3, #:lower16:i
movtr3, #:upper16:i
mov r2, #0
str r2, [r3]
movwr0, #:lower16:.LANCHOR0
movtr0, #:upper16:.LANCHOR0
mvn lr, #0
movwr1, #:lower16:v
movtr1, #:upper16:v
ldrhip, .L5 @ movhi
mov r2, r3
.L2:
ldr r3, [r0]
str lr, [r3]
strhip, [r1]@ movhi
ldr r3, [r2]
add r3, r3, #1
str r3, [r2]
cmp r3, #0
ble .L2
movwr3, #:lower16:v
movtr3, #:upper16:v
ldrhr0, [r3]
ldr pc, [sp], #4
.L6:
.align 2
.L5:
.word 4660
Issue under big-endian:
The ldrh loads the wrong value as immediate 4660 is in big-endian form.
GCC version: gcc version 5.0.0 20141026 (experimental)
[Bug target/63742] arm *movhi_insn_arch4 pattern may emit ldrh which is wrong for big-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63742 --- Comment #1 from Fei Yang fei.yang0953 at gmail dot com --- A proposed patch for this issue: https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00258.html
