[Bug tree-optimization/60823] [4.9/4.10 Regression] ICE in gimple_expand_cfg, at cfgexpand.c:5644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60823 vincenzo Innocente vincenzo.innocente at cern dot ch changed: What|Removed |Added CC||vincenzo.innocente at cern dot ch --- Comment #9 from vincenzo Innocente vincenzo.innocente at cern dot ch --- sorry fro squatting this thread: I noticed that compiling the test case for haswell it does not make use of umm registers c++ -std=c++11 -Ofast -fopenmp -S simdCloning.cc -march=haswell; grep ymm simdCloning.s vmovupd%ymm0, -80(%rbp) vmovupd%ymm1, -48(%rbp) vmovapd%ymm0, -80(%rbp) vmovapd%ymm1, -48(%rbp) vmovdqa-112(%rbp), %ymm0 changing int to long long does not make any effect... same changing double to float and widening the simdlen to 8. any good reason? should I open a new bug report (tree-optimization I suppose)?
[Bug libfortran/52539] I/O: Wrong result for UTF-8/UCS-4 list-directed and namelist read and nml write
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52539 --- Comment #29 from Tobias Burnus burnus at gcc dot gnu.org --- Status: Patch committed to the trunk (4.10), but fails (xfailed) on powerpc*-apple-darwin*.
[Bug bootstrap/61084] [4.10 regression] wide-int merge broke Solaris/SPARC bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61084 --- Comment #12 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Mon May 19 07:25:25 2014 New Revision: 210604 URL: http://gcc.gnu.org/viewcvs?rev=210604root=gccview=rev Log: gcc/ PR target/61084 * config/sparc/sparc.c (sparc_fold_builtin): Use widest_int rather than wide_int. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sparc/sparc.c
[Bug tree-optimization/60823] [4.9/4.10 Regression] ICE in gimple_expand_cfg, at cfgexpand.c:5644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60823 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to vincenzo Innocente from comment #9) sorry fro squatting this thread: I noticed that compiling the test case for haswell it does not make use of umm registers c++ -std=c++11 -Ofast -fopenmp -S simdCloning.cc -march=haswell; grep ymm simdCloning.s vmovupd %ymm0, -80(%rbp) vmovupd %ymm1, -48(%rbp) vmovapd %ymm0, -80(%rbp) vmovapd %ymm1, -48(%rbp) vmovdqa -112(%rbp), %ymm0 changing int to long long does not make any effect... same changing double to float and widening the simdlen to 8. any good reason? should I open a new bug report (tree-optimization I suppose)? If you look into the -fdump-tree-vect-details dump, you'll see it is not vectorized at all, I guess the primary issue is the nested loop in there, I guess you were expecting that the 4 or 8 outer loop (the compiler added) iterations will be vectorized and just get execute the inner loop which has fixed number of iterations and doesn't have any conditionals. But that is not what our vectorizer supports unfortunately, for nested loops it instead attempts to vectorize consecutive iterations of the inner loop (which doesn't of course work here, because the iterations depend on each other).
[Bug libstdc++/60758] Infinite backtrace in __cxa_end_cleanup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60758 --- Comment #6 from Alexey Merzlyakov alexey.merzlyakov at samsung dot com --- The issue was reproduced at my side. Let me make necessary investigations to fix the problem as soon as possible.
[Bug target/61195] single precision fmov does not need to switch mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61195 --- Comment #2 from chrbr at gcc dot gnu.org --- Author: chrbr Date: Mon May 19 08:04:22 2014 New Revision: 210608 URL: http://gcc.gnu.org/viewcvs?rev=210608root=gccview=rev Log: PR target/61195 * config/sh/sh.md (movsf_ie): Unset fp_mode for fmov Added: trunk/gcc/testsuite/gcc.target/sh/pr61195.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.md trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 57328, which changed state. Bug 57328 Summary: Missed optimization: Unable to vectorize Fortran min and max intrinsics https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57328 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/57328] Missed optimization: Unable to vectorize Fortran min and max intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57328 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.10.0 Resolution|--- |FIXED --- Comment #12 from Richard Biener rguenth at gcc dot gnu.org --- The testcase is vectorized just fine for me with -Ofast for 4.8, 4.9 and trunk. With -O3 half of it is vectorized as reported. On trunk this is fixed and we vectorize both functions (after the fix for PR61194).
[Bug target/61202] gcc generates invalid sqdmulh instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61202 jgreenhalgh at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-19 CC||jgreenhalgh at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from jgreenhalgh at gcc dot gnu.org --- I did a pass over these last year ( https://gcc.gnu.org/ml/gcc-patches/2013-09/msg00369.html ), but it looks like I missed the vqdmulh_n intrinsics. A patch along the same lines would be helpful. Better yet would be moving these to be RTL intrinsics.
[Bug middle-end/61209] [4.10 Regression] internal compiler error: in fold_convert_loc, at fold-const.c:1950
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61209 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-19 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed. It requires -fbounds-check (it could be a duplicate).
[Bug middle-end/61225] New: [4.10 Regression] Several new failures after r210458 on x86_64-*-* with -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61225 Bug ID: 61225 Summary: [4.10 Regression] Several new failures after r210458 on x86_64-*-* with -m32 Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr After r210458 the following failures appeared with -m32 (see https://gcc.gnu.org/ml/gcc-regression/2014-05/msg00155.html) FAIL: gcc.dg/guality/pr43051-1.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions line 34 c == a[0] FAIL: gcc.dg/guality/pr43051-1.c -O3 -fomit-frame-pointer -funroll-loops line 34 c == a[0] FAIL: gcc.dg/shrink-wrap-loop.c scan-rtl-dump pro_and_epilogue Performing shrink-wrapping FAIL: gcc.target/i386/pr49095.c scan-assembler-not test[lq] FAIL: gfortran.dg/assumed_charlen_needed_1.f90 -O (internal compiler error) FAIL: gfortran.dg/assumed_charlen_needed_1.f90 -O (test for excess errors) FAIL: gfortran.dg/der_array_io_1.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (internal compiler error) FAIL: gfortran.dg/der_array_io_1.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gfortran.dg/der_array_io_1.f90 -O3 -fomit-frame-pointer -funroll-loops (internal compiler error) FAIL: gfortran.dg/der_array_io_1.f90 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gfortran.dg/der_array_io_1.f90 -O3 -fomit-frame-pointer (internal compiler error) FAIL: gfortran.dg/der_array_io_1.f90 -O3 -fomit-frame-pointer (test for excess errors) FAIL: gfortran.dg/der_array_io_1.f90 -O3 -g (internal compiler error) FAIL: gfortran.dg/der_array_io_1.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/fmt_t_3.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (internal compiler error) FAIL: gfortran.dg/fmt_t_3.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gfortran.dg/fmt_t_3.f90 -O3 -fomit-frame-pointer -funroll-loops (internal compiler error) FAIL: gfortran.dg/fmt_t_3.f90 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gfortran.dg/fmt_t_3.f90 -O3 -fomit-frame-pointer (internal compiler error) FAIL: gfortran.dg/fmt_t_3.f90 -O3 -fomit-frame-pointer (test for excess errors) FAIL: gfortran.dg/fmt_t_3.f90 -O3 -g (internal compiler error) FAIL: gfortran.dg/fmt_t_3.f90 -O3 -g (test for excess errors) On x86_64-apple-darwin13, configured with ../work/configure --prefix=/opt/gcc/gcc4.10w --enable-languages=c,c++,fortran,objc,obj-c++,ada,java,lto --with-gmp=/opt/mp --with-system-zlib --with-isl=/opt/mp --enable-lto --enable-plugin --with-arch=corei7 --with-cpu=corei7 I only see the failures FAIL: gcc.dg/shrink-wrap-loop.c scan-rtl-dump pro_and_epilogue Performing shrink-wrapping FAIL: gcc.target/i386/pr49095.c scan-assembler-not test[lq] FAIL: gfortran.dg/assumed_charlen_needed_1.f90 -O (internal compiler error) FAIL: gfortran.dg/assumed_charlen_needed_1.f90 -O (test for excess errors) The ICE is [Book15] f90/bug% gfc /opt/gcc/work/gcc/testsuite/gfortran.dg/assumed_charlen_needed_1.f90 -m32 -O /opt/gcc/work/gcc/testsuite/gfortran.dg/assumed_charlen_needed_1.f90: In function 'MAIN__': /opt/gcc/work/gcc/testsuite/gfortran.dg/assumed_charlen_needed_1.f90:8:0: internal compiler error: in maybe_record_trace_start, at dwarf2cfi.c:2239 print *, fun (a) ^ /opt/gcc/work/gcc/testsuite/gfortran.dg/assumed_charlen_needed_1.f90:8:0: internal compiler error: Abort trap: 6 The ICE disappears if the code is compiled with -mtune=intel and if gcc is configured with --enable-checking=release.
[Bug go/61226] New: gccgo: hangs in sort_var_inits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61226 Bug ID: 61226 Summary: gccgo: hangs in sort_var_inits Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: dvyukov at google dot com Created attachment 32818 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32818action=edit reproducer $ gccgo -v Using built-in specs. COLLECT_GCC=gccgo COLLECT_LTO_WRAPPER=libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../configure --enable-languages=c,c++,go --disable-bootstrap --enable-checking=yes --disable-multilib --prefix=gcc_trunk/install Thread model: posix gcc version 4.10.0 20140516 (experimental) (GCC) The reproducer program is attached (it contains several packages, so you need to set GOPATH to the root of the tree). $ go build -compiler=gccgo main hangs in sort_var_inits at gcc/go/gofrontend/gogo.cc:1009 burning 100% of CPU.
[Bug bootstrap/61210] bootstrap failure with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61210 --- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to David Binderman from comment #2) (In reply to Manuel López-Ibáñez from comment #1) In which sense are they interesting? They show bugs in gcc trunk. Same as running cppcheck over gcc trunk shows bugs. Both both cases, I've reported the ones that I think are worth fixing. Thanks! As you may know, GCC doesn't currently have the resources behind Clang, so every little thing helps. I think this is being discussed in the mailing list here: https://gcc.gnu.org/ml/gcc/2014-05/msg00194.html so hopefully it will get fixed soon. It seems to be reproducible also with older GCC versions.
[Bug target/60609] [4.8 Regression] Error: value of 256 too large for field of 1 bytes at 68242
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60609 cbaylis at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||cbaylis at gcc dot gnu.org Known to work||4.8.3 Resolution|--- |FIXED --- Comment #10 from cbaylis at gcc dot gnu.org --- Now also fixed on 4.7 and 4.8 branches.
[Bug middle-end/61225] [4.10 Regression] Several new failures after r210458 on x86_64-*-* with -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61225 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Target||i686 Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-19 CC||ubizjak at gmail dot com, ||zhenqiang.chen at linaro dot org Target Milestone|--- |4.10.0 Ever confirmed|0 |1 --- Comment #1 from Uroš Bizjak ubizjak at gmail dot com --- Confirmed, adding CC.
[Bug libstdc++/61227] New: [C++11] Regex does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61227 Bug ID: 61227 Summary: [C++11] Regex does not work Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: fatony at fatony dot net Created attachment 32819 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32819action=edit Code sample The attached code produces std::regex_error in g++ 4.9.0. Here's what debugger says: Debugger name and version: GNU gdb (GDB) 7.6.2 (Debian 7.6.2-1.1) In __cxa_throw () (/usr/lib/x86_64-linux-gnu/libstdc++.so.6) #2 0x00410380 in std::__detail::_Compilerstd::regex_traitschar ::_M_expression_termfalse, false (this=0x7fffe3f0, __matcher=...) at /usr/include/c++/4.9/bits/regex_compiler.tcc:455 /usr/include/c++/4.9/bits/regex_compiler.tcc:455:13755:beg:0x410380 At /usr/include/c++/4.9/bits/regex_compiler.tcc:455
[Bug c/61184] [4.10 Regression] wrong code (that hangs) by LTO on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61184 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Ok, it's rather an old bug in vrp_operand_equal_p which does if (is_overflow_infinity (val1)) return is_overflow_infinity (val2); which isn't correct for how it is called from update_value_range (old value first, new value last and in this particular case +INF and +INF(OVF) which are happily classified as equal).
[Bug rtl-optimization/61220] ICE on valid code at -O2 on x86_64-linux-gnu in maybe_record_trace_start, at dwarf2cfi.c:2239
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61220 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target||x86_64-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-19 Target Milestone|--- |4.10.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed.
[Bug tree-optimization/61221] [4.10 Regression] ICE on valid code at -O1 and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61221 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-05-19 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |4.10.0 Summary|ICE on valid code at -O1|[4.10 Regression] ICE on |and above on|valid code at -O1 and above |x86_64-linux-gnu|on x86_64-linux-gnu Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed, mine.
[Bug rtl-optimization/61222] [4.10 Regression] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu in decompose, at rtl.h:1456
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61222 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-19 Target Milestone|--- |4.10.0 Summary|ICE on valid code at -O2|[4.10 Regression] ICE on |and -O3 on x86_64-linux-gnu |valid code at -O2 and -O3 |in decompose, at rtl.h:1456 |on x86_64-linux-gnu in ||decompose, at rtl.h:1456 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed.
[Bug rtl-optimization/61224] [4.10 Regression] ICE in rtl.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61224 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-19 Component|tree-optimization |rtl-optimization Target Milestone|--- |4.10.0 Summary|ICE in rtl.h|[4.10 Regression] ICE in ||rtl.h Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed.
[Bug lto/61218] lto ICE building libcilkrts with 4.9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61218 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Looks like LTO needs the cilk builtins.
[Bug c++/61214] [4.9/4.10 regression] Weird interaction between -fvisibility-inlines-hidden, inline virtuals and devirtualization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61214 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||jason at gcc dot gnu.org Target Milestone|--- |4.9.1 Summary|[4.9 regression] Weird |[4.9/4.10 regression] Weird |interaction between |interaction between |-fvisibility-inlines-hidden |-fvisibility-inlines-hidden |, inline virtuals and |, inline virtuals and |devirtualization|devirtualization
[Bug ipa/61211] [4.9/4.10 Regression] ICE: verify_cgraph_node failed: edge points to wrong declaration with -O3 -fno-inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61211 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||jamborm at gcc dot gnu.org Target Milestone|--- |4.9.1
[Bug bootstrap/61210] bootstrap failure with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61210 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-05-19 Ever confirmed|0 |1 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Can you try to use -O0 with clang as it is otherwise the default for the host compiler invocations? Thus, it may very well be a miscompilation by clang.
[Bug middle-end/61209] [4.10 Regression] internal compiler error: in fold_convert_loc, at fold-const.c:1950
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61209 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 Target Milestone|--- |4.10.0 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Mine.
[Bug tree-optimization/61203] [4.7/4.8/4.9/4.10 Regression] g++.old-deja/g++.jason/rvalue2.C FAILs with -O2 -fno-inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61203 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.4
[Bug libstdc++/60758] Infinite backtrace in __cxa_end_cleanup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60758 --- Comment #7 from Alexey Merzlyakov alexey.merzlyakov at samsung dot com --- The problem does not appear for thumb2 targets. On older architectures (armv6 and below) in thumb-mode the LR indeed can not be used as argument of POP instruction. To support __cxa_end_cleanup backtracing on thumb1, we can make additional register operations before push/pop. But I guess, this will have a negative effect on __cxa_end_cleanup performance. So, I propose to preserve __cxa_end_cleanup backtracing on thumb2 architectures and revert it on thumb1.
[Bug tree-optimization/61221] [4.10 Regression] ICE on valid code at -O1 and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61221 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Interesting ;) We do some non-sensical simplification on dead code and ICE. But our dead-CFG compute code in SCCVN isn't up to recognizing a dead loop because it's conservative and not optimistic. Ultimatively this all is because of replacing a call with sth that doesn't have a VDEF and gsi_replace/update_stmt being called which releases an SSA name which corrupts the value-numbering lattice.
[Bug libstdc++/60758] Infinite backtrace in __cxa_end_cleanup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60758 --- Comment #8 from Alexey Merzlyakov alexey.merzlyakov at samsung dot com --- Created attachment 32820 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32820action=edit Fix for thumb fail Proposed bugfix (build OK, but not regtested).
[Bug c++/61228] New: noexcept(expression) causes internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61228
Bug ID: 61228
Summary: noexcept(expression) causes internal compiler error
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: igorkuo at meta dot ua
The following code
# include cctype
# include algorithm
templateint ( F)(int)
constexpr int safeCtype(unsigned char c) noexcept(noexcept(F(c)))
{ return F(c); }
int main()
{
const char t[] = a;
//safeCtypestd::isspace(*t);
std::find_if(t, t + 1, safeCtypestd::isspace);
}
compiled with
$ g++ noexcept_bug.cpp -std=c++11
produces output:
In file included from /usr/include/c++/4.9.0/bits/stl_algobase.h:71:0,
from /usr/include/c++/4.9.0/algorithm:61,
from noexcept_bug.cpp:2:
/usr/include/c++/4.9.0/bits/predefined_ops.h: In instantiation of ‘bool
__gnu_cxx::__ops::_Iter_pred_Predicate::operator()(_Iterator) [with _Iterator
= const char*; _Predicate = int (*)(unsigned char) noexcept
(uninstantiated)]’:
/usr/include/c++/4.9.0/bits/stl_algo.h:120:22: required from
‘_RandomAccessIterator std::__find_if(_RandomAccessIterator,
_RandomAccessIterator, _Predicate, std::random_access_iterator_tag) [with
_RandomAccessIterator = const char*; _Predicate =
__gnu_cxx::__ops::_Iter_predint (*)(unsigned char) noexcept
(uninstantiated)]’
/usr/include/c++/4.9.0/bits/stl_algo.h:162:43: required from ‘_Iterator
std::__find_if(_Iterator, _Iterator, _Predicate) [with _Iterator = const char*;
_Predicate = __gnu_cxx::__ops::_Iter_predint (*)(unsigned char) noexcept
(uninstantiated)]’
/usr/include/c++/4.9.0/bits/stl_algo.h:3804:45: required from ‘_IIter
std::find_if(_IIter, _IIter, _Predicate) [with _IIter = const char*; _Predicate
= int (*)(unsigned char) noexcept (uninstantiated)]’
noexcept_bug.cpp:11:51: required from here
/usr/include/c++/4.9.0/bits/predefined_ops.h:231:30: internal compiler error:
in nothrow_spec_p, at cp/except.c:1271
{ return bool(_M_pred(*__it)); }
^
Please submit a full bug report,
with preprocessed source if appropriate.
See https://bugs.archlinux.org/ for instructions.
Internal compiler error is produced by g++4.7.2(Debian), g++4.8.2(Mageia),
g++4.9.0(Manjaro).
If noexcept(noexcept(F(c))) is replaced with noexcept OR
safeCtypestd::isspace(*t); is uncommented, compilation succeeds.
[Bug c++/47461] warn_unused_result attribute ignored for templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47461
--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org ---
Works with 4.9.0
w.cc: In function ‘void f(C*)’:
w.cc:6:33: warning: ignoring return value of ‘bool C::f(T*) [with T = int]’,
declared with attribute warn_unused_result [-Wunused-result]
void f(C* pc) { int i; pc-f(i); }
^
[Bug c++/61229] New: warn_unused_result fails to work with member functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61229
Bug ID: 61229
Summary: warn_unused_result fails to work with member functions
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: plasmahh at gmx dot net
Since gcc 4.5 (4.4 is fine) the following code will not emit any warning:
struct A
{
__attribute__((warn_unused_result)) int callme( ) { return 42; }
};
struct B
{
void foo( A a )
{
a.callme();
}
};
[Bug c++/61229] warn_unused_result fails to work with member functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61229 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 --- You get a warning if you call B::foo or if it's not inline.
[Bug c++/61228] noexcept(expression) causes internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61228 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-19 Ever confirmed|0 |1
[Bug target/61230] New: [4.10 regression][AArch64] New shift costs make scalar_shift_1.c to FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61230 Bug ID: 61230 Summary: [4.10 regression][AArch64] New shift costs make scalar_shift_1.c to FAIL Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: christophe.lyon at st dot com Since commit 210503 (New AArch64 costs 11/18-rotate and shifts), the scalar_shift_1.c test now FAILs. Tested with qemu-aarch64 on target aarch64-none-linux-gnu, and with the Foundation Model on aarch64_be-none-elf and aarch64-none-elf.
[Bug libstdc++/61227] [C++11] Regex does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61227
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-05-19
CC||timshen at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
Only your first and last regexes give an error, it would be helpful if you said
what you expect them to do.
The sequence \w is intepreted as [_[:alnum:]] but is rejected inside a bracket
expression.
Reduced:
#include regex
int main()
{
std::regex{ R([\w]) };
}
For this to match a string such as w or \\ it should be R([\\w])
To use the special \w class you can use [_[:alnum:]] as a workaround.
Tim, could you take a look at this please?
I don't think the C++ standard is clear, but Perl does interpret [\w] as
equivalent to just \w so I think we should do the same.
[Bug target/61230] [4.10 regression][AArch64] New shift costs make scalar_shift_1.c to FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61230 jgreenhalgh at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-05-19 Assignee|unassigned at gcc dot gnu.org |jgreenhalgh at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from jgreenhalgh at gcc dot gnu.org --- https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01260.html The testcase relies on a very particular code sequence being emitted, when other valid sequences exist. The scan-assembler portions of this testcase are clearly bogus. There is no reason a left shift by 1 should not be implemented by an add if the compiler so wishes.
[Bug target/61230] [4.10 regression][AArch64] New shift costs make scalar_shift_1.c to FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61230 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target||aarch64 Target Milestone|--- |4.10.0
[Bug c/61184] [4.10 Regression] wrong code (that hangs) by LTO on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61184 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Mon May 19 12:32:15 2014 New Revision: 210611 URL: http://gcc.gnu.org/viewcvs?rev=210611root=gccview=rev Log: 2014-05-19 Richard Biener rguent...@suse.de PR tree-optimization/61184 * tree-vrp.c (is_negative_overflow_infinity): Use TREE_OVERFLOW_P and do that check first. (is_positive_overflow_infinity): Likewise. (is_overflow_infinity): Likewise. (vrp_operand_equal_p): Properly treat operands with differing overflow as not equal. * c-c++-common/torture/pr61184.c: New testcase. Added: trunk/gcc/testsuite/c-c++-common/torture/pr61184.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c
[Bug c++/61229] warn_unused_result fails to work with member functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61229
Dennis Lubert plasmahh at gmx dot net changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |---
--- Comment #2 from Dennis Lubert plasmahh at gmx dot net ---
Since someone else pointed out that there is a bug talking about duplicates
already, now how my real code is more like the following. Also note that it
warns when I remove the dtor of evr.
struct evr
{
~evr( );
};
struct evd
{
virtual __attribute__((warn_unused_result)) evr rs( ) = 0;
};
class sd
{
[[gnu::warn_unused_result]] evr callme( evd );
};
evr sd::callme( evd edis )
{
edis.rs();
}
[Bug target/61231] New: [4.9/4.10 Regression] bootstrap comparision failure on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61231 Bug ID: 61231 Summary: [4.9/4.10 Regression] bootstrap comparision failure on powerpc64le-linux-gnu Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org Seen on the trunk r210608, and the 4.9 branch r210592 on powerpc64le-linux-gnu, using the 4.8.3 release candidate (plus the one rs6000 update) as a bootstrap compiler: trunk: Comparing stages 2 and 3 warning: gcc/cc1objplus-checksum.o differs warning: gcc/cc1plus-checksum.o differs warning: gcc/cc1obj-checksum.o differs warning: gcc/cc1-checksum.o differs Bootstrap comparison failure! gcc/ada/exp_attr.o differs gcc/ada/exp_atag.o differs gcc/ada/eval_fat.o differs libiberty/xstrdup.o differs libiberty/pic/argv.o differs libiberty/pic/choose-temp.o differs libiberty/pic/regex.o differs libiberty/argv.o differs libiberty/choose-temp.o differs powerpc64le-linux-gnu/libstdc++-v3/src/debug/c++98/list.o differs Makefile:21206: recipe for target 'compare' failed make[4]: *** [compare] Error 1 4.9 branch: Comparing stages 2 and 3 warning: gcc/cc1objplus-checksum.o differs warning: gcc/cc1plus-checksum.o differs warning: gcc/cc1obj-checksum.o differs warning: gcc/cc1-checksum.o differs Bootstrap comparison failure! gcc/d/argtypes.dmd.o differs libiberty/choose-temp.o differs Makefile:20526: recipe for target 'compare' failed make[4]: *** [compare] Error 1
[Bug libstdc++/61227] [C++11] Regex does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61227 --- Comment #2 from Andreas Schwab sch...@linux-m68k.org --- The C++ standard refers to ECMA-262 which defines [\w] as Perl does.
[Bug tree-optimization/61184] [4.10 Regression] wrong code (that hangs) by LTO on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61184 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Component|c |tree-optimization Resolution|--- |FIXED --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug target/61231] [4.9/4.10 Regression] bootstrap comparision failure on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61231 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||build Priority|P3 |P1 Target Milestone|--- |4.9.1
[Bug go/61232] New: [4.10 Regression] link errors building libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61232 Bug ID: 61232 Summary: [4.10 Regression] link errors building libgo Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: doko at gcc dot gnu.org libgo fails to link, at least on x86*, powerpc*, arm*, aarch64* -linux with trunk 20140519: .libs/bytes.o:(.data.rel.C237[__go_td_FppN12_bytes.ReaderN9_io.WritererN5_int64N5_erroree]+0x0): multiple definition of `C237' .libs/bufio.o:(.bss.C237[__go_td_FpN16_bufio.ReadWriteree]+0x0): first defined here .libs/bytes.o: In function `bytes.Len.pN12_bytes.Buffer': /build/buildd/gcc-snapshot-20140519/build/aarch64-linux-gnu/libgo/../../../src/libgo/go/bytes/buffer.go:57: multiple definition of `C217' .libs/bufio.o:/build/buildd/gcc-snapshot-20140519/build/aarch64-linux-gnu/libgo/../../../src/libgo/go/bufio/bufio.go:71: first defined here /usr/bin/aarch64-linux-gnu-ld: Warning: size of symbol `C217' changed from 16 in .libs/bufio.o to 8 in .libs/bytes.o .libs/bytes.o: In function `bytes.Len.pN12_bytes.Buffer': [some hundred messages like these follow] complete build logs at https://launchpad.net/ubuntu/+source/gcc-snapshot/20140519-0ubuntu1
[Bug go/61232] [4.10 Regression] link errors building libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61232 --- Comment #1 from Matthias Klose doko at gcc dot gnu.org --- this was r210608
[Bug libstdc++/61227] [C++11] Regex does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61227 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- So it does, thanks, Andreas. I read C++11 [re.grammar]/7 as saying those classes are part of the changes to the ECMAScript spec.
[Bug other/61233] New: Demangler crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61233 Bug ID: 61233 Summary: Demangler crash Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: gbenson at redhat dot com The demangler crashes when given this symbol: _Z7ZipWithI7QStringS0_5QListZN4oral6detail16AdaptCreateTableI7AccountEES0_RKNS3_16CachedFieldsDataEEUlRKS0_SA_E_ET1_IDTclfp1_cvT__EcvT0__RKT1_ISC_ERKT1_ISD_ET2_ See https://sourceware.org/bugzilla/show_bug.cgi?id=16957
[Bug go/61232] [4.10 Regression] link errors building libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61232 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Version|4.9.0 |4.10.0 Target Milestone|--- |4.10.0
[Bug middle-end/61209] [4.10 Regression] internal compiler error: in fold_convert_loc, at fold-const.c:1950
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61209 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Mon May 19 14:32:23 2014 New Revision: 210613 URL: http://gcc.gnu.org/viewcvs?rev=210613root=gccview=rev Log: 2014-05-19 Richard Biener rguent...@suse.de PR tree-optimization/61209 * tree-ssa-sccvn.c (visit_phi): Avoid setting expr to VN_TOP. * gfortran.dg/pr61209.f90: New testcase. Added: trunk/gcc/testsuite/gfortran.dg/pr61209.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-sccvn.c
[Bug tree-optimization/61221] [4.10 Regression] ICE on valid code at -O1 and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61221 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Mon May 19 14:33:31 2014 New Revision: 210614 URL: http://gcc.gnu.org/viewcvs?rev=210614root=gccview=rev Log: 2014-05-19 Richard Biener rguent...@suse.de PR tree-optimization/61221 * tree-ssa-pre.c (eliminate_dom_walker::before_dom_children): Do nothing for unreachable blocks. * tree-ssa-sccvn.c (cond_dom_walker::before_dom_children): Improve unreachability detection. * gcc.dg/torture/pr61221.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr61221.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-pre.c trunk/gcc/tree-ssa-sccvn.c
[Bug libstdc++/61227] [C++11] Regex does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61227 --- Comment #4 from FaTony fatony at fatony dot net --- The first regex is used to find illegal characters in symbol name in my project. The last regex is used to tokenize command line arguments. Those regexes work in Visual Studio 2012/2013 and clang with libc++.
[Bug middle-end/61209] [4.10 Regression] internal compiler error: in fold_convert_loc, at fold-const.c:1950
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61209 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/61221] [4.10 Regression] ICE on valid code at -O1 and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61221 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Fixed (worked around, real fix in testing).
[Bug target/61154] [4.10 Regression][ARM] wide-int merge introduced regressions in vshuf tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61154 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ramana at gcc dot gnu.org --- Comment #5 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- (In reply to rsand...@gcc.gnu.org from comment #3) This code is doing an OImode ASHIFT and fails the check: #if TARGET_SUPPORTS_WIDE_INT == 0 /* This assert keeps the simplification from producing a result that cannot be represented in a CONST_DOUBLE but a lot of upstream callers expect that this function never fails to simplify something and so you if you added this to the test above the code would die later anyway. If this assert happens, you just need to make the port support wide int. */ gcc_assert (width = HOST_BITS_PER_DOUBLE_INT); #endif since without CONST_WIDE_INT we won't be able to represent all results correctly. Unfortunately porting to CONST_WIDE_INT is something that needs knowledge of the target-specific code, but it shouldn't be much work. It's just a case of auditing each use of const_double in config/arm to see whether it is handling integer const_doubles or floating-point const_doubles. Since ARM is a 32-bit target and since HWI and CONST_INT are 64 bits, I assume most places really are handling floating-point values. (A grep makes that obvious for some things, but arm_immediate_di_operand does accept const_double. I'm not sure whether that's just a left-over from pre need_64bit_hwint days though.) I suppose mine. In addition to auditing for the use of const_doubles, I think one thing that needs to be mentioned explicitly is trying to find use of const_double_operand as well. One of the splitters in the backend which split DImode immediate moves was actually explicitly trying to only look for const_double_operand and it appears that this just worked (TM) prior to a trial switch to TARGET_SUPPORTS_WIDE_INT. I'm still trying to test through the rest of that. I note that SPARC has a similar define_split so it might also be affected by such a switch over. I still have an unfinished patch stack on top of that which will attempt to fix other cases in the backend where we could be replacing uses of GEN_INT with gen_int_mode. Is there any rule of thumb for such a conversion ? regards Ramana Adding: #define TARGET_SUPPORTS_WIDE_INT 1 does fix the ICE but it'd be good audit the use of const_doubles too.
[Bug lto/53831] [4.7 Regression] Virtuals missing in LTO symtab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53831
Sami Farin hvtaifwkbgefbaei at gmail dot com changed:
What|Removed |Added
CC||hvtaifwkbgefbaei at gmail dot
com
--- Comment #33 from Sami Farin hvtaifwkbgefbaei at gmail dot com ---
Is 4.9.0 supposed to work with -flto with ar archives? It works if I do gcc
-flto *.o, though.
$ gcc-ar r libdiv.a div64.o
/bin/ar terminated with signal 11 [Segmentation fault]
...
Starting program: /usr/bin/ar r --plugin
/usr/libexec/gcc/x86_64-redhat-linux/4.9.?/liblto_plugin.so libdiv.a div64.o
Program received signal SIGSEGV, Segmentation fault.
bfd_plugin_get_symbols_in_object_only (abfd=0x6138f0) at plugin.c:151
151 plugin_data-object_only_syms = NULL;
(gdb) bt
#0 bfd_plugin_get_symbols_in_object_only (abfd=0x6138f0) at plugin.c:151
#1 add_symbols (handle=0x6138f0, nsyms=1, syms=0x618e20) at plugin.c:278
#2 0x70bb577a in claim_file_handler (file=0x7fff9880,
claimed=0x7fff987c) at ../../lto-plugin/lto-plugin.c:929
#3 0x77b806d4 in bfd_plugin_object_p (abfd=0x6138f0) at plugin.c:450
#4 0x77b0c415 in bfd_check_format_matches (abfd=0x6138f0,
format=bfd_object, matching=0x0) at format.c:278
#5 0x77b047a2 in _bfd_write_archive_contents (arch=0x615cd0) at
archive.c:2149
#6 0x77b0dcef in bfd_close (abfd=abfd@entry=0x615cd0) at opncls.c:718
#7 0x00404f37 in write_archive (iarch=iarch@entry=0x60f1e0) at
ar.c:1160
#8 0x004054ec in replace_members (arch=arch@entry=0x60f1e0,
files_to_move=0x60ef10, files_to_move@entry=0x60ef08, quick=0) at ar.c:1401
#9 0x00402a8f in main (argc=6, argv=0x60ef00) at ar.c:836
(gdb) p plugin_data
$2 = (struct plugin_data_struct *) 0x0
$ cat div64.c
#include stdint.h
uint64_t div64(uint64_t x, uint64_t y) { return x/y; }
[Bug lto/53831] [4.7 Regression] Virtuals missing in LTO symtab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53831 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #34 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Sami Farin from comment #33) Is 4.9.0 supposed to work with -flto with ar archives? It works if I do gcc -flto *.o, though. $ gcc-ar r libdiv.a div64.o /bin/ar terminated with signal 11 [Segmentation fault] ... Starting program: /usr/bin/ar r --plugin /usr/libexec/gcc/x86_64-redhat-linux/4.9.?/liblto_plugin.so libdiv.a div64.o Program received signal SIGSEGV, Segmentation fault. bfd_plugin_get_symbols_in_object_only (abfd=0x6138f0) at plugin.c:151 151 plugin_data-object_only_syms = NULL; (gdb) bt #0 bfd_plugin_get_symbols_in_object_only (abfd=0x6138f0) at plugin.c:151 #1 add_symbols (handle=0x6138f0, nsyms=1, syms=0x618e20) at plugin.c:278 #2 0x70bb577a in claim_file_handler (file=0x7fff9880, claimed=0x7fff987c) at ../../lto-plugin/lto-plugin.c:929 This looks like a binutils bug to me. What version of binutils are you using? Does it still happen with binutils trunk?
[Bug fortran/61234] New: Warn for use-stmt without explicit only-list.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61234 Bug ID: 61234 Summary: Warn for use-stmt without explicit only-list. Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: Joost.VandeVondele at mat dot ethz.ch It would be nice to have a warning (-Wuse-only) for a use-stmt without explicit only-list. It would allow for enforcing this good style with -Werror. Extra useful would be if the warning message would list everything that would be required on the only-list.
[Bug fortran/53940] Optionally warn about multiple explicit USE-association of the same symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53940 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||Joost.VandeVondele at mat dot ethz ||.ch --- Comment #4 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- still useful.
[Bug lto/53831] [4.7 Regression] Virtuals missing in LTO symtab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53831 --- Comment #35 from Sami Farin hvtaifwkbgefbaei at gmail dot com --- binutils-2.24-13.fc21 haven't tried latest from git://sourceware.org/git/binutils-gdb.git
[Bug target/61231] [4.9/4.10 Regression] bootstrap comparision failure on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61231 --- Comment #1 from Matthias Klose doko at gcc dot gnu.org --- so this happens because I had sys/sdt.h installed during the build, and automatically gets picked up during the build. So probably an invalid issue, or should the inclusion of this header be guarded for architectures that are actually supported by systemtap?
[Bug ada/61201] Cross compile fails with SPARK_05 undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61201 --- Comment #2 from Richard Henderson rth at gcc dot gnu.org --- While that does allow me to proceed further, I think you're dismissing an actual problem somewhere. If gnat 4.8.2 can compile gnat 4.9.0 for native, then I do not understand why it can't compile 4.9.0 for cross. It seems like you've got a search path problem somewhere.
[Bug ada/61201] Cross compile fails with SPARK_05 undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61201 --- Comment #3 from Arnaud Charlet charlet at gcc dot gnu.org --- The build of GNAT cross is designed to rely on a matching native, to simplify the set up, so this is really as designed here, and not just a 'search path problem'. The coupling between the Ada runtime and the Ada compiler is very strong, and trying to support this combination would simply lead to lots of complexity, hence the choice of not trying to address this combination, as per the documentation. So: this is as designed and as documented. Arno
[Bug go/61232] [4.10 Regression] link errors building libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61232 Ian Lance Taylor ian at airs dot com changed: What|Removed |Added CC||hubicka at ucw dot cz --- Comment #2 from Ian Lance Taylor ian at airs dot com --- Something is setting the comdat group of a static (TREE_PUBLIC == DECL_EXTERNAL == 0) variable. That fails when the static variable does not have a unique name, as in this case. It's not revision 210608, that only affects the SH backend.
[Bug go/61232] [4.10 Regression] link errors building libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61232 --- Comment #3 from Ian Lance Taylor ian at airs dot com --- It's almost certainly the new ipa-comdats pass. When ipa-comdats converts a variable from static to comdat, it needs to give it a unique name.
[Bug target/61219] float to double conversion does not silence sNaN on soft-float ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61219 Joseph S. Myers jsm28 at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Joseph S. Myers jsm28 at gcc dot gnu.org --- This is bug 59833. *** This bug has been marked as a duplicate of bug 59833 ***
[Bug target/59833] ARM soft-float extendsfdf2 fails to quiet signaling NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59833 Joseph S. Myers jsm28 at gcc dot gnu.org changed: What|Removed |Added CC||aurelien at aurel32 dot net --- Comment #2 from Joseph S. Myers jsm28 at gcc dot gnu.org --- *** Bug 61219 has been marked as a duplicate of this bug. ***
[Bug libstdc++/61235] New: SYSTEM(3) - had better copy its command string parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61235
Bug ID: 61235
Summary: SYSTEM(3) - had better copy its command string
parameter
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: shaneyfelt at yahoo dot com
The cstdlib system function sometimes assumes that the
caller will keep the command string allocated
after the call returns. The result may be accessing
memory that is no longer available and attempting
to run commands from it.
This happens whenever the system command contains
'' to spawn a new process as in the example below.
#include stdlib.c
void example() {
string cmd = xdot EOF \ndigraph { a-b }\nEOF\n;
system(cmd.c_str());
}
int main() {
f(); // allocate some memory on the heap
example();
g(); // delete some memory from the heap
example();
// stderr shows extra garbage indicating that
// sh tried to executes bits and pieces of the
// previously executed command
}
The suggested solution is for the system function to copy
string into memory where it will be kept until the
subprocess that is reading it terminates.
Although the caller may try to allocate the strings in
dynamic memory whenever the system function is called,
the caller may not be able to easily tell when the process
terminates in order to free the memory. Therefore forcing the
solution on the caller may cause memory leaks.
[Bug c/61236] New: GCC 4.9 generates incorrect object code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61236
Bug ID: 61236
Summary: GCC 4.9 generates incorrect object code
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: muks at banu dot com
Hi all
This is a bug report from the BIND DNS project team at ISC.org. We have
a report to make of buggy code generated with GCC 4.9.0, and we request
a C compiler developer to take a look.
For the purpose of this ticket, you will have to look at source
code. All code mentioned here is under the ISC license (free software
license equivalent to MIT license). I have not been successful in making
an isolated testcase, but I'll instead describe our analysis.
The bug first was reported a few days ago on the Arch Linux bug tracker
against BIND 9.10.0: https://bugs.archlinux.org/task/40304
They had recently switched the system gcc compiler to:
gcc version 4.9.1 20140507 (prerelease) (GCC)
and built the BIND package with this compiler.
We had not seen such a crash on any of our builders or even our
development environments. When we looked at it, it was an assertion
being triggered in code that is similar to this:
void
crashing_function(void) {
/* some code */
if (some_condition) {
goto free_and_exit;
}
/* some more code */
free_and_exit:
if (ptr != NULL) {
internal_mem_free(ptr, sizeof_ptr);
}
}
void
internal_mem_free(void *ptr, size_t size) {
assert(ptr != NULL);
UNUSED(size);
free(ptr);
}
From the above, it is obvious that the assertion inside
internal_mem_free() cannot fail. Yet this is what is happening and is
the bug.
You can find the code in question here:
ftp://ftp.isc.org/isc/bind9/9.10.0-P1/bind-9.10.0-P1.tar.gz
Open dns_rdataslab_fromrdataset()'s definition in lib/dns/rdataslab.c.
It has the following code at the end of the function:
free_rdatas:
if (x != NULL)
isc_mem_put(mctx, x, nalloc * sizeof(struct xrdata));
return (result);
}
The isc__mem_put() function [called by isc_mem_put() macro] asserts that
x is not NULL as a prerequisite, and this assertion fails.
The bug has also been reported on other operating systems such as LFS
and also Fedora 20 with a locally built GCC 4.9. If you need any help
in compiling the BIND tree, please ask us via email, or in #bind on
irc.freenode.net, but it should be as simple as ./configure make.
Running the 'dnssec' system test will reproduce the assertion
failure. If you want help on running the test too, please ask.
To run the system test after successful configure and make, you'll have
to run (as root):
# sh bin/tests/system/ifconfig.sh up
to setup local interface addresses that the tests use.
Then (as a user):
$ cd bin/tests/system/
$ #ulimit -c unlimited # if necessary, to dump core
$ sh ./run.sh dnssec
Core files should be inside bin/tests/system/dnssec/ tree after the
assertion fails.
I'll follow up with an analysis of the generated x86_64 object code for
dns_rdataslab_fromrdataset() from our internal bug tracker that points
out the bug in generated object code.
[Bug rtl-optimization/61224] [4.10 Regression] ICE in rtl.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61224 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||rsandifo at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Caused by wide-int merge: r210113.
[Bug rtl-optimization/61222] [4.10 Regression] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu in decompose, at rtl.h:1456
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61222 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||rsandifo at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Caused by wide-int merge: r210113.
[Bug c/61236] GCC 4.9 generates incorrect object code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61236 --- Comment #1 from Mukund Sivaraman muks at banu dot com --- The following is _correct_ generated x8t_64 code for dns_rdataslab_fromrdataset() as compiled with: gcc version 4.8.2 20131212 (Red Hat 4.8.2-7) (GCC) Under free_rdatas label, you can see that there is a 0 check for x (%r14) as in the C code. It was not deleted by the compiler. 00521450 dns_rdataslab_fromrdataset: ; find dns_rdata_set_first() call below: 521450: 41 57 push %r15 521452: 49 89 f7mov%rsi,%r15 521455: 41 56 push %r14 521457: 41 55 push %r13 521459: 41 54 push %r12 52145b: 49 89 fcmov%rdi,%r12 52145e: 55 push %rbp 52145f: 53 push %rbx 521460: 48 83 ec 38 sub$0x38,%rsp 521464: 48 89 54 24 10 mov%rdx,0x10(%rsp) 521469: 89 4c 24 0c mov%ecx,0xc(%rsp) 52146d: e8 ce e7 ff ff callq 51fc40 dns_rdataset_count 521472: 41 89 c5mov%eax,%r13d 521475: 45 85 edtest %r13d,%r13d 521478: 75 26 jne5214a0 dns_rdataslab_fromrdataset+0x50 52147a: 45 31 f6xor%r14d,%r14d 52147d: 66 41 83 7c 24 22 00cmpw $0x0,0x22(%r12) 521484: b8 19 00 00 00 mov$0x19,%eax 521489: 74 4c je 5214d7 dns_rdataslab_fromrdataset+0x87 52148b: 48 83 c4 38 add$0x38,%rsp 52148f: 5b pop%rbx 521490: 5d pop%rbp 521491: 41 5c pop%r12 521493: 41 5d pop%r13 521495: 41 5e pop%r14 521497: 41 5f pop%r15 521499: c3 retq 52149a: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1) 5214a0: 41 81 fd ff ff 00 00cmp$0x,%r13d 5214a7: b8 13 00 00 00 mov$0x13,%eax 5214ac: 77 dd ja 52148b dns_rdataslab_fromrdataset+0x3b 5214ae: 44 89 e8mov%r13d,%eax 5214b1: b9 a1 00 00 00 mov$0xa1,%ecx 5214b6: ba eb 20 64 00 mov$0x6420eb,%edx 5214bb: 48 8d 34 40 lea(%rax,%rax,2),%rsi 5214bf: 4c 89 ffmov%r15,%rdi 5214c2: 48 c1 e6 04 shl$0x4,%rsi 5214c6: e8 45 c2 0a 00 callq 5cd710 isc__mem_get 5214cb: 48 85 c0test %rax,%rax 5214ce: 49 89 c6mov%rax,%r14 5214d1: 0f 84 a7 00 00 00 je 52157e dns_rdataslab_fromrdataset+0x12e 5214d7: 4c 89 e7mov%r12,%rdi ; result = dns_rdataset_first(rdataset); 5214da: e8 41 e8 ff ff callq 51fd20 dns_rdataset_first ; if (result != ISC_R_SUCCESS result != ISC_R_NOMORE) ; goto free_rdatas; ; 0x1d (ISC_R_NOMORE) 5214df: 83 f8 1dcmp$0x1d,%eax 5214e2: 74 04 je 5214e8 dns_rdataslab_fromrdataset+0x98 ; 0x0 (ISC_R_SUCCESS). if (result != ISC_R_SUCCESS result != ; ISC_R_NOMORE), jmp to 52153f (free_rdatas) below. ;; test instruction does logical AND of operands and sets zero flag if ;; %eax is 0. jne (same as jnz) tests ZF and performs conditional jump ;; if ZF=0. 5214e4: 85 c0 test %eax,%eax 5214e6: 75 57 jne52153f dns_rdataslab_fromrdataset+0xef ; go below to free_rdatas. ; ignore: for loop 5214e8: 31 db xor%ebx,%ebx 5214ea: 85 c0 test %eax,%eax 5214ec: 75 4c jne52153a dns_rdataslab_fromrdataset+0xea 5214ee: 45 85 edtest %r13d,%r13d 5214f1: 75 0a jne5214fd dns_rdataslab_fromrdataset+0xad 5214f3: eb 45 jmp52153a dns_rdataslab_fromrdataset+0xea 5214f5: 0f 1f 00nopl (%rax) ; ignore: for loop iterate (continue;) 5214f8: 41 39 ddcmp%ebx,%r13d 5214fb: 76 3d jbe52153a dns_rdataslab_fromrdataset+0xea 5214fd: 89 d8 mov%ebx,%eax 5214ff: 48 8d 2c 40 lea(%rax,%rax,2),%rbp 521503: 48 c1 e5 04 shl$0x4,%rbp 521507: 4c 01 f5add%r14,%rbp 52150a: 48 89 efmov%rbp,%rdi 52150d: e8 4e 9e fd ff callq 4fb360 dns_rdata_init 521512: 48 89 eemov%rbp,%rsi 521515: 4c 89 e7mov
[Bug libstdc++/61235] SYSTEM(3) - had better copy its command string parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61235 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- System is part of libc and not libstdc++ so please report this behavior there. Also it might not be a bug.
[Bug c/61236] GCC 4.9 generates incorrect object code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61236
--- Comment #2 from Mukund Sivaraman muks at banu dot com ---
This is the C function (so you can compare notes from the next comment):
isc_result_t
dns_rdataslab_fromrdataset(dns_rdataset_t *rdataset, isc_mem_t *mctx,
isc_region_t *region, unsigned int reservelen)
{
/*
* Use removed as a sentinal pointer for duplicate
* rdata as rdata.data == NULL is valid.
*/
static unsigned char removed;
struct xrdata *x;
unsigned char *rawbuf;
#if DNS_RDATASET_FIXED
unsigned char *offsetbase;
#endif
unsigned intbuflen;
isc_result_tresult;
unsigned intnitems;
unsigned intnalloc;
unsigned inti;
#if DNS_RDATASET_FIXED
unsigned int *offsettable;
#endif
unsigned intlength;
buflen = reservelen + 2;
nalloc = dns_rdataset_count(rdataset);
nitems = nalloc;
if (nitems == 0 rdataset-type != 0)
return (ISC_R_FAILURE);
if (nalloc 0x)
return (ISC_R_NOSPACE);
if (nalloc != 0) {
x = isc_mem_get(mctx, nalloc * sizeof(struct xrdata));
if (x == NULL)
return (ISC_R_NOMEMORY);
} else
x = NULL;
/*
* Save all of the rdata members into an array.
*/
result = dns_rdataset_first(rdataset);
if (result != ISC_R_SUCCESS result != ISC_R_NOMORE)
goto free_rdatas;
for (i = 0; i nalloc result == ISC_R_SUCCESS; i++) {
INSIST(result == ISC_R_SUCCESS);
dns_rdata_init(x[i].rdata);
dns_rdataset_current(rdataset, x[i].rdata);
INSIST(x[i].rdata.data != removed);
#if DNS_RDATASET_FIXED
x[i].order = i;
#endif
result = dns_rdataset_next(rdataset);
}
if (result != ISC_R_NOMORE)
goto free_rdatas;
if (i != nalloc) {
/*
* Somehow we iterated over fewer rdatas than
* dns_rdataset_count() said there were!
*/
result = ISC_R_FAILURE;
goto free_rdatas;
}
/*
* Put into DNSSEC order.
*/
qsort(x, nalloc, sizeof(struct xrdata), compare_rdata);
/*
* Remove duplicates and compute the total storage required.
*
* If an rdata is not a duplicate, accumulate the storage size
* required for the rdata. We do not store the class, type, etc,
* just the rdata, so our overhead is 2 bytes for the number of
* records, and 8 for each rdata, (length(2), offset(4) and order(2))
* and then the rdata itself.
*/
for (i = 1; i nalloc; i++) {
if (compare_rdata(x[i-1].rdata, x[i].rdata) == 0) {
x[i-1].rdata.data = removed;
#if DNS_RDATASET_FIXED
/*
* Preserve the least order so A, B, A - A, B
* after duplicate removal.
*/
if (x[i-1].order x[i].order)
x[i].order = x[i-1].order;
#endif
nitems--;
} else {
#if DNS_RDATASET_FIXED
buflen += (8 + x[i-1].rdata.length);
#else
buflen += (2 + x[i-1].rdata.length);
#endif
/*
* Provide space to store the per RR meta data.
*/
if (rdataset-type == dns_rdatatype_rrsig)
buflen++;
}
}
/*
* Don't forget the last item!
*/
if (nalloc != 0) {
#if DNS_RDATASET_FIXED
buflen += (8 + x[i-1].rdata.length);
#else
buflen += (2 + x[i-1].rdata.length);
#endif
}
/*
* Provide space to store the per RR meta data.
*/
if (rdataset-type == dns_rdatatype_rrsig)
buflen++;
/*
* Ensure that singleton types are actually singletons.
*/
if (nitems 1 dns_rdatatype_issingleton(rdataset-type)) {
/*
* We have a singleton type, but there's more than one
* RR in the rdataset.
*/
result = DNS_R_SINGLETON;
goto free_rdatas;
}
/*
* Allocate the memory, set up a buffer, start copying in
* data.
*/
rawbuf = isc_mem_get(mctx, buflen);
if (rawbuf == NULL) {
result = ISC_R_NOMEMORY;
goto free_rdatas;
}
#if DNS_RDATASET_FIXED
/* Allocate temporary offset table. */
offsettable = isc_mem_get(mctx, nalloc * sizeof(unsigned int));
if (offsettable == NULL) {
isc_mem_put(mctx, rawbuf, buflen);
result = ISC_R_NOMEMORY;
goto free_rdatas;
}
memset(offsettable, 0, nalloc * sizeof(unsigned int));
#endif
region-base = rawbuf;
region-length = buflen;
rawbuf += reservelen;
#if DNS_RDATASET_FIXED
offsetbase = rawbuf;
#endif
*rawbuf++ = (nitems 0xff00) 8;
*rawbuf++ = (nitems 0x00ff);
#if DNS_RDATASET_FIXED
/* Skip load order table. Filled in later. */
rawbuf += nitems * 4;
#endif
for (i = 0; i nalloc; i++) {
if (x[i].rdata.data == removed)
continue;
#if DNS_RDATASET_FIXED
offsettable[x[i].order] = rawbuf - offsetbase;
#endif
[Bug go/61232] [4.10 Regression] link errors building libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61232 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-05-19 CC||hubicka at gcc dot gnu.org Assignee|ian at airs dot com|hubicka at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Jan Hubicka hubicka at gcc dot gnu.org --- I am going to reproduce it, but I am bit confused here. I intend to make static symbols inside a comdat group. That is I have a comdat group with external comdat symbol (i.e. the variable the comdat was created for) and I find a variable that is referenced only from its constructor. I intend to introduce static symbol inside that section and I do not want to export it out. We do that for thunks, so I assumed it works for variables, too. I will check what exactly goes wrong here. Honza
[Bug c/61236] GCC 4.9 generates incorrect object code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61236 --- Comment #3 from Mukund Sivaraman muks at banu dot com --- The following is _incorrect_ generated x86_64 code for dns_rdataslab_fromrdataset() as compiled with: gcc version 4.9.1 20140507 (prerelease) (GCC). (the current version of GCC on Arch Linux). NOTE that there are two copies of generated code for this function. Either the first or second copy of code is called based on whether (nalloc == 0) implying (nitems == 0) too. In the (nitems == 0) case, the entire free_rdatas block is deleted by GCC as x is inferred to be NULL. In the (nitems != 0) case, the if (x != NULL) check is deleted as x is inferred to NOT be NULL, and isc_mem_put() is always called. The failed assertion obviously happens when (x == NULL), i.e., (nitems == 0). And the fact that the if (x != NULL) check was deleted is an obvious sign that code flow is through that path to cause the assertion failure. Because the code is like noodles, I've added STEP# comments in the code to take you through the (nitems == 0) case. Go from STEP #0 to STEP #13. The bug happens because the (nitems == 0) case branches into code for (nitems != 0) where checks have been removed. ; STEP #0 0051fc10 dns_rdataslab_fromrdataset: 51fc10: 41 57 push %r15 51fc12: 41 56 push %r14 51fc14: 49 89 f7mov%rsi,%r15 51fc17: 41 55 push %r13 51fc19: 41 54 push %r12 51fc1b: 49 89 fcmov%rdi,%r12 51fc1e: 55 push %rbp 51fc1f: 53 push %rbx 51fc20: 48 83 ec 38 sub$0x38,%rsp 51fc24: 48 89 54 24 08 mov%rdx,0x8(%rsp) 51fc29: 89 4c 24 20 mov%ecx,0x20(%rsp) 51fc2d: e8 9e e7 ff ff callq 51e3d0 dns_rdataset_count 51fc32: 41 89 c5mov%eax,%r13d ;; STEP #1 ;; Is (nitems == 0)? If not, go to 51fc60. It is 0 in our case. 51fc35: 45 85 edtest %r13d,%r13d 51fc38: 75 26 jne51fc60 dns_rdataslab_fromrdataset+0x50 ;; STEP #2 ;; if (nitems == 0 rdataset-type != 0) ;;return (ISC_R_FAILURE); ;; ;; Here, let's take it that (rdataset-type != 0) so that we can ;; continue execution. Jump to 51fd20 (STEP #3). 51fc3a: 66 41 83 7c 24 22 00cmpw $0x0,0x22(%r12) 51fc41: ba 19 00 00 00 mov$0x19,%edx 51fc46: 0f 84 d4 00 00 00 je 51fd20 dns_rdataslab_fromrdataset+0x110 ; out: ; ; control comes back here as part of a return; statement's code from ; below. 51fc4c: 48 83 c4 38 add$0x38,%rsp 51fc50: 89 d0 mov%edx,%eax 51fc52: 5b pop%rbx 51fc53: 5d pop%rbp 51fc54: 41 5c pop%r12 51fc56: 41 5d pop%r13 51fc58: 41 5e pop%r14 51fc5a: 41 5f pop%r15 51fc5c: c3 retq 51fc5d: 0f 1f 00nopl (%rax) ; (nitems != 0) case. 51fc60: 41 81 fd ff ff 00 00cmp$0x,%r13d 51fc67: ba 13 00 00 00 mov$0x13,%edx 51fc6c: 77 de ja 51fc4c dns_rdataslab_fromrdataset+0x3c 51fc6e: 44 89 e8mov%r13d,%eax 51fc71: b9 a1 00 00 00 mov$0xa1,%ecx 51fc76: ba 6b e1 63 00 mov$0x63e16b,%edx 51fc7b: 48 8d 1c 40 lea(%rax,%rax,2),%rbx 51fc7f: 4c 89 ffmov%r15,%rdi 51fc82: 48 c1 e3 04 shl$0x4,%rbx 51fc86: 48 89 demov%rbx,%rsi 51fc89: e8 d2 a9 0a 00 callq 5ca660 isc__mem_get 51fc8e: 48 85 c0test %rax,%rax 51fc91: 49 89 c6mov%rax,%r14 51fc94: 0f 84 7d 01 00 00 je 51fe17 dns_rdataslab_fromrdataset+0x207 51fc9a: 4c 89 e7mov%r12,%rdi ; /* FIRST COPY OF GENERATED CODE (nalloc 0) */ ; ; result = dns_rdataset_first(rdataset); 51fc9d: e8 0e e8 ff ff callq 51e4b0 dns_rdataset_first ; if (result != ISC_R_SUCCESS result != ISC_R_NOMORE) ; goto free_rdatas; ; 0x1d (ISC_R_NOMORE) 51fca2: 83 f8 1dcmp$0x1d,%eax 51fca5: 74 08 je 51fcaf dns_rdataslab_fromrdataset+0x9f ; 0x0 (ISC_R_SUCCESS). if (result != ISC_R_SUCCESS result != ; ISC_R_NOMORE), jmp to 51fd53 (free_rdatas) below. 51fca7: 85 c0 test %eax,%eax 51fca9: 0f 85 a4 00 00 00 jne51fd53 dns_rdataslab_fromrdataset+0x143 ; go below to free_rdatas. ; ignore: for loop 51fcaf: 31
[Bug bootstrap/61210] bootstrap failure with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61210 --- Comment #5 from David Binderman dcb314 at hotmail dot com --- (In reply to Richard Biener from comment #4) Can you try to use -O0 with clang as it is otherwise the default for the host compiler invocations? Thus, it may very well be a miscompilation by clang. I think I'm right in saying that boot compiler (clang here) only does stage1. Hence a difference between stage2 and stage3 AFAIK can't be produced by clang. However, I tried out what you suggested and it made no difference. Comparing stages 2 and 3 warning: gcc/cc1-checksum.o differs warning: gcc/cc1plus-checksum.o differs Bootstrap comparison failure! gcc/simplify-rtx.o differs gcc/fold-const.o differs gcc/tree-ssa-ccp.o differs make[2]: *** [compare] Error 1 I'll try again in a few days time.
[Bug go/61232] [4.10 Regression] link errors building libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61232 Ian Lance Taylor ian at airs dot com changed: What|Removed |Added CC||ian at airs dot com --- Comment #5 from Ian Lance Taylor ian at airs dot com --- I haven't been able to figure out how to recreate this in C/C++. The case in Go is straightforward: a comdat weak variable (specifically, a Go type descriptor for an unnamed type) has an initializer that refers to the address of a static variable. That static variable does not have a unique name. There are hundreds of cases in the standard Go library. I have a patch for the Go frontend that simply gives the static variables a unique name. That seems to fix the problem for Go. It doesn't fix the general problem for the pass, which is: the pass assumes that when a comdat variable refers to a static variable, the static variable has a unique name. It happens that for C/C++, as far as I can tell, they always do have a unique name. To fix the pass properly I think you'll need to give those static variables a unique asm name without disturbing the debug info.
[Bug c/61236] GCC 4.9 generates incorrect object code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61236 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-05-19 CC||trippels at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Could you please try to reproduce the issue with a more recent snapshot: ftp://gcc.gnu.org/pub/gcc/snapshots/4.10-20140518/ There were several bug fixes for tree-ssa-threadedge.c that went in after gcc version 4.9.1 20140507.
[Bug c/61236] GCC 4.9 generates incorrect object code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61236 --- Comment #5 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Markus Trippelsdorf from comment #4) Could you please try to reproduce the issue with a more recent snapshot: ftp://gcc.gnu.org/pub/gcc/snapshots/4.10-20140518/ Sorry wrong address. This one is correct: ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20140514/
[Bug go/61232] [4.10 Regression] link errors building libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61232 --- Comment #6 from Jan Hubicka hubicka at gcc dot gnu.org --- Well, is there a reason why I can not place static symbol into the comdat section, just as we do for labels within functions or thunks? Those also do not have unique name. It seems to me that there is a problem in the output machinery confusing comdat locals with comdats in the case of variables. Let me see if I can fix it easily or I will disable the pass for variables for time being.
[Bug rtl-optimization/61222] [4.10 Regression] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu in decompose, at rtl.h:1456
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61222 rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org changed: What|Removed |Added CC||ishiura-compiler at ml dot kwansei ||.ac.jp --- Comment #3 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org --- *** Bug 61224 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/61224] [4.10 Regression] ICE in rtl.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61224 rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org --- Same underlying bug as 61222, although the testcases are different enough for both to be worth adding to the testsuite. *** This bug has been marked as a duplicate of bug 61222 ***
[Bug rtl-optimization/61222] [4.10 Regression] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu in decompose, at rtl.h:1456
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61222 rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #4 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org --- Combine is getting confused about which mode it's using.
[Bug target/61231] [4.9/4.10 Regression] bootstrap comparision failure on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61231
Frank Ch. Eigler fche at redhat dot com changed:
What|Removed |Added
CC||fche at redhat dot com
--- Comment #2 from Frank Ch. Eigler fche at redhat dot com ---
(Note that strictly speaking, systemtap per se doesn't need to support
an architecture for the sys/sdt.h header file to work there. gdb is
a fully independent client of sys/sdt.h markers.)
Perhaps the way to go forward is to have the gcc configury test-compile
some toy sys/sdt.h code [1], and activate the probes only if that works.
[1]
#include sys/sdt.h
int main ()
{
DTRACE_PROBE(foo,bar);
return 0;
}
[Bug c++/58761] ICE with a lambda capturing this in a NSDMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58761 --- Comment #5 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Mon May 19 18:41:24 2014 New Revision: 210624 URL: http://gcc.gnu.org/viewcvs?rev=210624root=gccview=rev Log: PR c++/58761 * pt.c (tsubst_copy): Don't check at_function_scope_p. (instantiate_class_template_1): Don't push_to_top_level in an nsdmi. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nsdmi6.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug c/56724] sub-optimal location in error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56724
--- Comment #9 from Marek Polacek mpolacek at gcc dot gnu.org ---
(In reply to Tom Tromey from comment #5)
I tried this today with a recent-ish gcc trunk build, and
there's been a regression.
Now:
barimba. gcc --syntax-only r.c
r.c: In function ‘docall’:
r.c:7:10: warning: passing argument 3 of ‘callf’ from incompatible pointer
type
return callf (23, 72,
^
r.c:3:5: note: expected ‘int (*)(double *)’ but argument is of type ‘int
(*)(int *)’
int callf (int, int, int (*)(double *));
^
Note how the first warning now points to callf, whereas
in comment #0 it pointed to the actual argument causing the diagnostic.
The new situation is much worse for me as it prevents automated
rewriting...
That is not a regression; previously it didn't point to the actual argument,
but it used input_location, so it pointed to the start of the line. In the
previous testcase it only looks like it's pointing to the last argument. E.g.
on this
int f (int *);
int callf (int, int, int (*)(double *));
int docall(void)
{
return callf (23,
72, f);
}
it will point to 72.
I hope I will have the cycles to look into this this week.
[Bug rtl-optimization/61220] [4.10 Regression] ICE on valid code at -O2 on x86_64-linux-gnu in maybe_record_trace_start, at dwarf2cfi.c:2239
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61220 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||zqchen at gcc dot gnu.org Summary|ICE on valid code at -O2 on |[4.10 Regression] ICE on |x86_64-linux-gnu in |valid code at -O2 on |maybe_record_trace_start, |x86_64-linux-gnu in |at dwarf2cfi.c:2239 |maybe_record_trace_start, ||at dwarf2cfi.c:2239 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Caused by r210457.
[Bug go/61232] [4.10 Regression] link errors building libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61232 --- Comment #7 from Jan Hubicka hubicka at gcc dot gnu.org --- Created attachment 32821 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32821action=edit patch I am testing This patch seems to do what I want - it makes the comdat local variables to be in the comdat group section but not declared as unique_object (and thus they should not land the symbol table). Iant, since I do have your attention and you know a lot more about the topic, does it seem sane?
[Bug c/61236] GCC 4.9 generates incorrect object code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61236 --- Comment #6 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Markus Trippelsdorf from comment #4) Could you please try to reproduce the issue with a more recent snapshot: No need. I can reproduce the issue and will look deeper tomorrow.
[Bug c++/61133] g++ doesn't implement DR1760
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61133 --- Comment #1 from Ville Voutilainen ville.voutilainen at gmail dot com --- Patch is in https://gcc.gnu.org/ml/gcc-patches/2014-05/msg00656.html
[Bug c++/47202] Endless recursion during mangling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47202 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- This is an issue of combinatorial explosion in checking code; when we have lots of substitutions, checking each one against each other takes a long time, especially when each comparison involves recursively comparing all the template arguments. In release mode we don't do the substitution checking and type comparison just uses canonical types. We ought to hit the recursion limit before we try to do the mangling, though; this is an issue with DECL_COMDAT_GROUP that I've been meaning to address. I think I'll dig out that branch again...
[Bug rtl-optimization/61220] [4.10 Regression] ICE on valid code at -O2 on x86_64-linux-gnu in maybe_record_trace_start, at dwarf2cfi.c:2239
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61220 --- Comment #3 from Uroš Bizjak ubizjak at gmail dot com --- Related to PR61225
[Bug c/61236] GCC 4.9 generates incorrect object code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61236 --- Comment #7 from Markus Trippelsdorf trippels at gcc dot gnu.org --- -fno-delete-null-pointer-checks fixes the issue and is an easy workaround for now.
[Bug bootstrap/61210] bootstrap failure with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61210 --- Comment #6 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to David Binderman from comment #5) I'll try again in a few days time. Richard S. is preparing a patch at [1], perhaps you can help to test it? [1] https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01519.html
[Bug debug/61237] New: gcc puts line number 11 ahead of line number 10 in function call in debug info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61237
Bug ID: 61237
Summary: gcc puts line number 11 ahead of line number 10 in
function call in debug info
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at google dot com
I can imagine gcc's trying to be helpful here, but it's not working in this
case (at least in IMHO).
I want to set a breakpoint on line 10, but when I get there line 11 has already
been executed, and by that time it's too late.
[This example is stripped down from the original.]
1 int
2 foo (int a, int b)
3 {
4 return a + b;
5 }
6
7 int
8 main ()
9 {
10foo (1,
11 -foo (2, 3));
12return 0;
13 }
$ gdb a.out
(gdb) disas /m main
Dump of assembler code for function main:
9 {
0x00400484 +0: push %rbp
0x00400485 +1: mov%rsp,%rbp
10foo (1,
0x00400497 +19:neg%eax
0x00400499 +21:mov%eax,%esi
0x0040049b +23:mov$0x1,%edi
0x004004a0 +28:callq 0x400470 foo
11 -foo (2, 3));
0x00400488 +4: mov$0x3,%esi
0x0040048d +9: mov$0x2,%edi
0x00400492 +14:callq 0x400470 foo
12return 0;
0x004004a5 +33:mov$0x0,%eax
13 }
0x004004aa +38:pop%rbp
0x004004ab +39:retq
End of assembler dump.
gdb's attempt at making mixed disassembly output more readable isn't helpful
either. The thing to note here is that line 11 appears before line 10 in the
code. Technically, one can argue that that is correct I suppose. And if that
is the answer, fine. I'm just filing this so that the answer is written down
somewhere. I did spend 10 minutes trying to find an existing bug in the
database (which feels like enough - I have to time out at some point), and I
grepped for O0 in the not a bug page
https://gcc.gnu.org/bugs/#nonbugs
and didn't find anything.
OTOH, if you want to agree this is a bug, fine by me. :-)
[Bug bootstrap/61210] bootstrap failure with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61210 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|WAITING |NEW CC||gerald at pfeifer dot com, ||rsandifo at gcc dot gnu.org Version|4.9.0 |4.10.0 Target Milestone|--- |4.10.0 --- Comment #7 from Uroš Bizjak ubizjak at gmail dot com --- Confirmed and adding CCs.
[Bug target/61223] libstdc++ build fail due to pop lr register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61223 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Component|libstdc++ |target --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- This is a target-specific bug, please set the Target field appropriately.
[Bug target/61202] gcc generates invalid sqdmulh instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61202 --- Comment #3 from Carrot carrot at google dot com --- 4.8 branch also has the same problem.
