[Bug target/53386] Bad assembly code produced for m68000
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53386 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |SUSPENDED Last reconfirmed||2015-01-19 CC||law at redhat dot com Ever confirmed|0 |1 --- Comment #14 from Jeffrey A. Law law at redhat dot com --- We really need a testcase for the issue raised in c#13. Without a reasonable testcase, there really isn't anything we can do.
[Bug libstdc++/64584] basic_regex::assign breaks *this if it throws regex_error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64584 --- Comment #1 from Tim Shen timshen at gcc dot gnu.org --- Author: timshen Date: Mon Jan 19 22:56:04 2015 New Revision: 219865 URL: https://gcc.gnu.org/viewcvs?rev=219865root=gccview=rev Log: PR libstdc++/64584 PR libstdc++/64585 * include/bits/regex.h (basic_regex::basic_regex, basic_regex::assign, basic_regex::imbue, basic_regex::swap, basic_regex::mark_count): Drop NFA after imbuing basic_regex; Make assign() transactional against exception. * include/bits/regex_compiler.h (__compile_nfa): Add back __compile_nfa SFINAE. * include/std/regex: Adjust include order to avoid __compile_nfa forward declaration. * testsuite/28_regex/basic_regex/assign/char/string.cc: New testcase. * testsuite/28_regex/basic_regex/imbue/string.cc: New testcase. Added: trunk/libstdc++-v3/testsuite/28_regex/basic_regex/imbue/ trunk/libstdc++-v3/testsuite/28_regex/basic_regex/imbue/string.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/regex.h trunk/libstdc++-v3/include/bits/regex_compiler.h trunk/libstdc++-v3/include/std/regex trunk/libstdc++-v3/testsuite/28_regex/basic_regex/assign/char/string.cc
[Bug libstdc++/64585] The basic_regex object should not match any character sequence after a call to basic_regex::imbue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64585 --- Comment #1 from Tim Shen timshen at gcc dot gnu.org --- Author: timshen Date: Mon Jan 19 22:56:04 2015 New Revision: 219865 URL: https://gcc.gnu.org/viewcvs?rev=219865root=gccview=rev Log: PR libstdc++/64584 PR libstdc++/64585 * include/bits/regex.h (basic_regex::basic_regex, basic_regex::assign, basic_regex::imbue, basic_regex::swap, basic_regex::mark_count): Drop NFA after imbuing basic_regex; Make assign() transactional against exception. * include/bits/regex_compiler.h (__compile_nfa): Add back __compile_nfa SFINAE. * include/std/regex: Adjust include order to avoid __compile_nfa forward declaration. * testsuite/28_regex/basic_regex/assign/char/string.cc: New testcase. * testsuite/28_regex/basic_regex/imbue/string.cc: New testcase. Added: trunk/libstdc++-v3/testsuite/28_regex/basic_regex/imbue/ trunk/libstdc++-v3/testsuite/28_regex/basic_regex/imbue/string.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/regex.h trunk/libstdc++-v3/include/bits/regex_compiler.h trunk/libstdc++-v3/include/std/regex trunk/libstdc++-v3/testsuite/28_regex/basic_regex/assign/char/string.cc
[Bug libstdc++/64585] The basic_regex object should not match any character sequence after a call to basic_regex::imbue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64585 --- Comment #2 from Tim Shen timshen at gcc dot gnu.org --- Author: timshen Date: Mon Jan 19 23:09:07 2015 New Revision: 219868 URL: https://gcc.gnu.org/viewcvs?rev=219868root=gccview=rev Log: PR libstdc++/64584 PR libstdc++/64585 * include/bits/regex.h (basic_regex::basic_regex, basic_regex::assign, basic_regex::imbue, basic_regex::swap, basic_regex::mark_count): Drop NFA after imbuing basic_regex; Make assign() transactional against exception. * testsuite/28_regex/basic_regex/assign/char/string.cc: New testcase. * testsuite/28_regex/basic_regex/imbue/string.cc: New testcase. Added: branches/gcc-4_9-branch/libstdc++-v3/testsuite/28_regex/basic_regex/imbue/ branches/gcc-4_9-branch/libstdc++-v3/testsuite/28_regex/basic_regex/imbue/string.cc Modified: branches/gcc-4_9-branch/libstdc++-v3/ChangeLog branches/gcc-4_9-branch/libstdc++-v3/include/bits/regex.h branches/gcc-4_9-branch/libstdc++-v3/testsuite/28_regex/basic_regex/assign/char/string.cc
[Bug libstdc++/64584] basic_regex::assign breaks *this if it throws regex_error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64584 --- Comment #2 from Tim Shen timshen at gcc dot gnu.org --- Author: timshen Date: Mon Jan 19 23:09:07 2015 New Revision: 219868 URL: https://gcc.gnu.org/viewcvs?rev=219868root=gccview=rev Log: PR libstdc++/64584 PR libstdc++/64585 * include/bits/regex.h (basic_regex::basic_regex, basic_regex::assign, basic_regex::imbue, basic_regex::swap, basic_regex::mark_count): Drop NFA after imbuing basic_regex; Make assign() transactional against exception. * testsuite/28_regex/basic_regex/assign/char/string.cc: New testcase. * testsuite/28_regex/basic_regex/imbue/string.cc: New testcase. Added: branches/gcc-4_9-branch/libstdc++-v3/testsuite/28_regex/basic_regex/imbue/ branches/gcc-4_9-branch/libstdc++-v3/testsuite/28_regex/basic_regex/imbue/string.cc Modified: branches/gcc-4_9-branch/libstdc++-v3/ChangeLog branches/gcc-4_9-branch/libstdc++-v3/include/bits/regex.h branches/gcc-4_9-branch/libstdc++-v3/testsuite/28_regex/basic_regex/assign/char/string.cc
[Bug c++/64679] New: Spurious redefinition error when parsing not-quite-most-vexing-parse declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64679
Bug ID: 64679
Summary: Spurious redefinition error when parsing
not-quite-most-vexing-parse declarations
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Repro:
class Bar{
public:
Bar(int, int, int);
};
int main () {
int x = 1;
Bar bar(int(x), int(x), int{x});
}
gcc HEAD 5.0.0 20150119 (experimental) with g++ prog.cc -Wall -Wextra
-std=gnu++1y reports:
prog.cc: In function 'int main()':
prog.cc:8:24: error: redefinition of 'int x'
Bar bar(int(x), int(x), int{x});
^
prog.cc:8:16: note: 'int x' previously declared here
Bar bar(int(x), int(x), int{x});
With the last int{x} (note the braces) this cannot be a function declaration,
but g++ appears to emit the redefinition errors too early, before the full
declaration is parsed. Clang compiles this successfully.
[Bug libgomp/64672] ICEs in libgomp.oacc-fortran when using the '-g -flto' options in the test suite.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64672 --- Comment #3 from howarth at bromo dot med.uc.edu --- The attached reduced test case reproduces the ICE with... $ ~/dist/bin/gfortran -fopenacc -DACC_DEVICE_TYPE_host_nonshm=1 -DACC_MEM_SHARED=0 -g -flto asyncwait-1.f90 lto1: internal compiler error: in streamer_get_builtin_tree, at tree-streamer-in.c:1151 0xc266af streamer_get_builtin_tree(lto_input_block*, data_in*) ../../gcc-trunk/gcc/tree-streamer-in.c:1151 0x90aeb4 lto_input_tree_1(lto_input_block*, data_in*, LTO_tags, unsigned int) ../../gcc-trunk/gcc/lto-streamer-in.c:1320 0x90b099 lto_input_scc(lto_input_block*, data_in*, unsigned int*, unsigned int*) ../../gcc-trunk/gcc/lto-streamer-in.c:1248 0x5f88be lto_read_decls ../../gcc-trunk/gcc/lto/lto.c:1900 0x5fa930 lto_file_finalize ../../gcc-trunk/gcc/lto/lto.c:2229 0x5fa930 lto_create_files_from_ids ../../gcc-trunk/gcc/lto/lto.c:2239 0x5fa930 lto_file_read ../../gcc-trunk/gcc/lto/lto.c:2280 0x5fa930 read_cgraph_and_symbols ../../gcc-trunk/gcc/lto/lto.c:2981 0x5fa930 lto_main() ../../gcc-trunk/gcc/lto/lto.c:3436 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. lto-wrapper: fatal error: /home/howarth/dist/bin/gfortran returned 1 exit status compilation terminated. /home/howarth/dist_binutils/bin/ld: lto-wrapper failed collect2: error: ld returned 1 exit status on x86_64 linux and... % gfortran-fsf-5.0 -fopenacc -DACC_DEVICE_TYPE_host_nonshm=1 -DACC_MEM_SHARED=0 -g -flto asyncwait-1.f90 gfortran-fsf-5.0: error: asyncwait-1.f90: No such file or directory [Jack-Howarths-Computer:~/testcase] howarth% gfortran-fsf-5.0 -fopenacc -DACC_DEVICE_TYPE_host_nonshm=1 -DACC_MEM_SHARED=0 -g -flto PR64672.f90 lto1: internal compiler error: in streamer_get_builtin_tree, at tree-streamer-in.c:1151 lto1: internal compiler error: Abort trap: 6 gfortran-fsf-5.0: internal compiler error: Abort trap: 6 (program lto1) lto-wrapper: fatal error: gfortran-fsf-5.0 terminated with signal 6 [Abort trap: 6] compilation terminated. collect2: fatal error: lto-wrapper returned 1 exit status compilation terminated. on x86_64-apple-darwin14.
[Bug go/64595] cgo installed into wrong directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595 --- Comment #8 from Andreas Schwab sch...@linux-m68k.org --- Why does libbacktrace need debug info? All required unwind information is included in the binary. Glibc's backtrace can do that too.
[Bug libgomp/64672] ICEs in libgomp.oacc-fortran when using the '-g -flto' options in the test suite.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64672 --- Comment #2 from howarth at bromo dot med.uc.edu --- Created attachment 34489 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34489action=edit minimal testcase to produce ICE on linux and darwin
[Bug libstdc++/64680] New: basic_regex::operator= does not reset flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64680
Bug ID: 64680
Summary: basic_regex::operator= does not reset flags
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: kariya_mitsuru at hotmail dot com
Created attachment 34491
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34491action=edit
g++ -v
The sample code below should not throw a regex_error.
= sample code =
#include regex
int main()
{
std::regex re([[:alnum:]], std::regex_constants::basic);
re = \\w+;
}
===
cf. http://melpon.org/wandbox/permlink/lrD2Ia4urIPVgakK
According to the C++11 standard 28.8.3[re.regex.assign], operator=(const charT*
ptr) is equivalent to assign(ptr), and assign(ptr) calls assign(const char*
ptr, flag_type f = regex_constants::ECMAScript).
Since \\w+ is a valid ECMAScript syntax, the sample code above should end
normally.
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #216 from Jan Hubicka hubicka at gcc dot gnu.org --- Author: hubicka Date: Tue Jan 20 04:39:45 2015 New Revision: 219878 URL: https://gcc.gnu.org/viewcvs?rev=219878root=gccview=rev Log: PR lto/45375 * i386.c (ix86_option_override_internal): Use ix86_tune_cost to set branch cost. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c
[Bug target/36488] Generated 68K code bad for pipelining (case swap)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36488 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |WONTFIX --- Comment #1 from Jeffrey A. Law law at redhat dot com --- No plans to further improve pipelining further for the m68k platform.
[Bug target/36487] Generated 68K code bad for pipelining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36487 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |WONTFIX --- Comment #1 from Jeffrey A. Law law at redhat dot com --- No plans to enhance pipelining for m68k port.
[Bug libffi/64645] liibffi fails to build on cygwin-32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64645 --- Comment #5 from Bernd Edlinger bernd.edlinger at hotmail dot de --- (In reply to Richard Henderson from comment #4) (In reply to Bernd Edlinger from comment #3) AFAIK Cygwin-32 does not support the unwind info at all, right?. Wrong. This should be enough to fix it. diff --git a/src/x86/sysv.S b/src/x86/sysv.S index 58432d9..78f245b 100644 --- a/src/x86/sysv.S +++ b/src/x86/sysv.S @@ -822,6 +822,8 @@ ENDF(C(__x86.get_pc_thunk.dx)) #ifdef __APPLE__ .section __TEXT,__eh_frame,coalesced,no_toc+strip_static_syms+live_support EHFrame0: +#elif defined(X86_WIN32) +.section .eh_frame,r #elif defined(HAVE_AS_X86_64_UNWIND_SECTION_TYPE) .section .eh_frame,EH_FRAME_FLAGS,@unwind #else OK. Patch works. One question: would --enable-sjlj-exceptions make any difference here?
[Bug go/64595] cgo installed into wrong directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595 --- Comment #10 from Ian Lance Taylor ian at airs dot com --- The point of libbacktrace, at least if you call the backtrace_full function, is to get file/line information. If you don't need file/line information, you can just use _Unwind_Backtrace.
[Bug fortran/64678] New: Expected association error on dependent associate statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64678 Bug ID: 64678 Summary: Expected association error on dependent associate statements Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: antony at cosmologist dot info In trunk module X Type T integer :: map end Type T contains subroutine DoBug Type(T) TT associate(A=TT, B=A%map) end associate end subroutine end module X gives: testbug.f90:10:17: associate(A=TT, B=A%map) 1 Error: Expected association at (1) testbug.f90:11:4: end associate 1 It's not entirely clear to me from the standard if this is allowed, but I don't see why not (useful when you are breaking up complicated array/class structures into associate names, where the second name refers to the first). It compiles in ifort. Obviously low priority as can be worked around easily enough
[Bug ipa/63576] [5 Regression] ICE : in ipa_merge_profiles, at ipa-utils.c:540 during Firefox LTO/PGO build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63576 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org --- Comment #6 from Jan Hubicka hubicka at gcc dot gnu.org --- mine.
[Bug rtl-optimization/49847] [4.8 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #39 from Jeffrey A. Law law at redhat dot com --- Fixed in 4.9 and on trunk. Not planning to backport fix to 4.8.
[Bug rtl-optimization/52714] [4.8 regression] ICE in fixup_reorder_chain, at cfglayout.c:880
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52714 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #18 from Jeffrey A. Law law at redhat dot com --- Fixed in 4.9 and on trunk. Not planning to backport to 4.8.
[Bug go/64595] cgo installed into wrong directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595 --- Comment #7 from Ian Lance Taylor ian at airs dot com --- That failure is not related to the new gotools. I expect it would happen with any Go program. Go requires that there be enough debug info to do a stack backtrace with file/line information. It uses the libbacktrace library, but that library doesn't understand separate debuginfo sections. I can fix this specific problem so that the program is more likely to run, but in general Go code expects to be able to get that backtrace and most real Go programs will fail without it. I guess I or somebody needs to fix libbacktrace to understand separate debuginfo objects.
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #215 from Jan Hubicka hubicka at gcc dot gnu.org --- Author: hubicka Date: Mon Jan 19 23:58:19 2015 New Revision: 219871 URL: https://gcc.gnu.org/viewcvs?rev=219871root=gccview=rev Log: PR lto/45375 * i386.c (gate): Check flag_expensive_optimizations and optimize_size. (ix86_option_override_internal): Drop optimize_size condition on MASK_ACCUMULATE_OUTGOING_ARGS, MASK_VZEROUPPER, MASK_AVX256_SPLIT_UNALIGNED_LOAD, MASK_AVX256_SPLIT_UNALIGNED_STORE, MASK_PREFER_AVX128. (ix86_avx256_split_vector_move_misalign, ix86_avx256_split_vector_move_misalign): Check optimize_insn_for_speed. * sse.md (all uses of TARGET_PREFER_AVX128): Add optimize_insn_for_speed_p check. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/sse.md
[Bug go/64595] cgo installed into wrong directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595 --- Comment #12 from Ian Lance Taylor ian at airs dot com --- It's not libbacktrace that is crashing the app, it's libgo. And, yes, probably libgo should not crash the app either. But it's also true that many Go programs simply won't work correctly if file/line information is not available.
[Bug target/50928] m32c ICE building RTEMS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50928 --- Comment #8 from DJ Delorie dj at redhat dot com --- There are a few regressions in the testsuite (pr26255.c with -mcpu=m32c for example) and libstdc++ still doesn't build, but ieee/920810-1 now passes and newlib builds. I suppose that's better.
[Bug libgomp/64672] ICEs in libgomp.oacc-fortran when using the '-g -flto' options in the test suite.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64672 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr --- The '-fopenacc -flto' options are enough to trigger the ICE.
[Bug go/64595] cgo installed into wrong directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595 --- Comment #9 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Andreas Schwab from comment #8) Why does libbacktrace need debug info? All required unwind information is included in the binary. Glibc's backtrace can do that too. Most likely the same reason why Java needs it. So it can see if the file that the backtrace is coming from is a system library or not.
[Bug fortran/64678] Expected association error on dependent associate statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64678 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- (In reply to Antony Lewis from comment #0) In trunk module X Type T integer :: map end Type T contains subroutine DoBug Type(T) TT associate(A=TT, B=A%map) end associate end subroutine end module X gives: testbug.f90:10:17: associate(A=TT, B=A%map) 1 Error: Expected association at (1) testbug.f90:11:4: end associate 1 It's not entirely clear to me from the standard if this is allowed, but I don't see why not (useful when you are breaking up complicated array/class structures into associate names, where the second name refers to the first). It compiles in ifort. Obviously low priority as can be worked around easily enough I believe gfortran is correct in issuing an error; although I admit it seems to be a subtle distinction in language. For F2003 standard 8.1.4 ASSOCIATE construct The ASSOCIATE construct associates named entities with expressions or variables during the execution of its block. These named construct entities (16.3) are associating entities (16.4.1.5). The names are associate names. The BNF shows R818 association is associate-name = selector R819 selector is expr or variable In your code, 'A' and 'B' are associate-names. The target of an associate-name is a selector, which is an expr or variable. The target for 'B' is 'A%map'. So, the question becomes whether 'A%map' is now a variable or expression even though 'A' is an associate-name. The BNF for 'variable is R601 variable is designator C601 (R601) designator shall not be a constant or a subobject of a constant. R602 variable-name is name C602 (R602) A variable-name shall be the name of a variable. R603 designatoris object-name or array-element or array-section or structure-component or substring R505 object-name is name C505 (R505) The object-name shall be the name of a data object. A data object (often abbreviated to object) is a constant (4.1.2), a variable (6), or a subobject of a constant. The type and type parameters of a named data object may be specified explicitly (5.1) or implicitly (5.3). 'A%map' as a data object is certainly not a constant or subobject of a constant, so it must be a variable. But, we've already established that 'A' is an associate-name not a variable-name. So, 'A%map' is not an object-name. array-element, array-section, and substring are of no consequence here. So, now, structure-component R614 structure-component is data-ref R612 data-ref is part-ref [ % part-ref ] ... R613 part-ref is part-name [ ( section-subscript-list ) ] C612 (R612) The leftmost part-name shall be the name of a data object. We've already established 'A' is not a data object. So, now we are left with 'expr'. I have no interest in reproducing Section 7 of Fortran 2003 standard. I suspect you'll find that 'A%map' is not an 'expr'. Note, I could be wrong. You may want to post to comp.lang.fortran. There are numerous people, who contribute to c.l.f, that are much more in-tune with the nuances of the Fortran standard.
[Bug c++/64677] incorrect result with complex division?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64677 Mikhail Maltsev maltsevm at gmail dot com changed: What|Removed |Added CC||maltsevm at gmail dot com --- Comment #3 from Mikhail Maltsev maltsevm at gmail dot com --- Probably calculating with higher precision will give correct result. Output of Wolfram Alpha: -O0: convert -0.0083223357032193145 to binary -1.000110110100110011010101100001010110111001110010010010111001000111111001011011000..._2×2^-7 | hexadecimal value IEEE double-precision number | 578f5ffd4c0b81bf (assuming little-endian byte ordering) -O1: convert -0.0083223357032193128 to binary -1.0001101101001100110101011000010101110100011001001110010111010110100111010111010010011..._2×2^-7 | hexadecimal value IEEE double-precision number | 568f5ffd4c0b81bf (assuming little-endian byte ordering) Wolfram Alpha's calculation: binary(re(1/(-61.887073591767951 -60.052083270252012i))) -1.00011011010011001101010110000101011011001010101000110101101101101101000101101010..._2×2^-7 | hexadecimal value IEEE double-precision number | 568f5ffd4c0b81bf (assuming little-endian byte ordering) So, compile-time result is more precise. BTW, what does the disassembly look like?
[Bug libstdc++/64649] regex_traits::lookup_classname() only works with random access iterators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64649 --- Comment #3 from Tim Shen timshen at gcc dot gnu.org --- Author: timshen Date: Mon Jan 19 23:12:37 2015 New Revision: 219869 URL: https://gcc.gnu.org/viewcvs?rev=219869root=gccview=rev Log: PR libstdc++/64649 Backported from mainline 2015-01-19 Tim Shen tims...@google.com * include/bits/regex.tcc (regex_traits::lookup_collatename, regex_traits::lookup_classname): Support forward iterators. * testsuite/28_regex/traits/char/lookup_classname.cc: New testcases. * testsuite/28_regex/traits/char/lookup_collatename.cc: New testcase. Modified: branches/gcc-4_9-branch/libstdc++-v3/ChangeLog branches/gcc-4_9-branch/libstdc++-v3/include/bits/regex.tcc branches/gcc-4_9-branch/libstdc++-v3/testsuite/28_regex/traits/char/lookup_classname.cc branches/gcc-4_9-branch/libstdc++-v3/testsuite/28_regex/traits/char/lookup_collatename.cc
[Bug fortran/64678] Expected association error on dependent associate statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64678 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-20 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- I am not sure to understand the standard legaleses, but associate(A=TT) associate(B=A%map) end associate end associate is accepted.
[Bug lto/48724] Lto build of mozilla dies at lto-wrapper: error trying to exec 'make -j1': execvp: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48724 --- Comment #8 from Jan Hubicka hubicka at gcc dot gnu.org --- This no longer happens with recent Firefox builds, but I think it was rather fixed at Firefox buildsystem...
[Bug rtl-optimization/58369] [4.8 regression] ICE in subreg_get_info when compiling boost for m68k-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58369 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #9 from Jeffrey A. Law law at redhat dot com --- Resolved on 4.9/trunk, not planning to backport to 4.8.
[Bug middle-end/52306] [4.8 regression] ICE in cselib_record_set, at cselib.c:2158
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52306 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #35 from Jeffrey A. Law law at redhat dot com --- Fixed in 4.9 and on trunk. Not planning to backport to 4.8.
[Bug target/53988] [SH] tst Rm,Rn not used for QI/HImode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53988 --- Comment #6 from Oleg Endo olegendo at gcc dot gnu.org --- Author: olegendo Date: Mon Jan 19 22:35:53 2015 New Revision: 219864 URL: https://gcc.gnu.org/viewcvs?rev=219864root=gccview=rev Log: gcc/ PR target/53988 * config/sh/sh-protos.h (sh_find_set_of_reg): Make sure not to return nullptr for insn when reaching the first insn. * config/sh/sh.c (sh_unspec_insn_p): Rewrite using subrtx_iterator. (sh_insn_operands_modified_between_p): Add nullptr check. (sh_find_extending_set_of_reg): Fix log message. Don't accept sign extending mem load if the insn contains any UNSPEC or UNSPEC_VOLATILE. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh-protos.h trunk/gcc/config/sh/sh.c
[Bug target/59946] -mpcrel -O2 produces illegal asm code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59946 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-19 Ever confirmed|0 |1
[Bug libstdc++/64649] regex_traits::lookup_classname() only works with random access iterators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64649 --- Comment #2 from Tim Shen timshen at gcc dot gnu.org --- Author: timshen Date: Mon Jan 19 23:00:13 2015 New Revision: 219866 URL: https://gcc.gnu.org/viewcvs?rev=219866root=gccview=rev Log: PR libstdc++/64649 * include/bits/regex.tcc (regex_traits::lookup_collatename, regex_traits::lookup_classname): Support forward iterators. * testsuite/28_regex/traits/char/lookup_classname.cc: New testcases. * testsuite/28_regex/traits/char/lookup_collatename.cc: New testcase. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/regex.tcc trunk/libstdc++-v3/testsuite/28_regex/traits/char/lookup_classname.cc trunk/libstdc++-v3/testsuite/28_regex/traits/char/lookup_collatename.cc
[Bug go/64595] cgo installed into wrong directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595 --- Comment #11 from Andreas Schwab sch...@linux-m68k.org --- But it shouldn't crash the app if you don't have the full information.
[Bug ipa/63576] [5 Regression] ICE : in ipa_merge_profiles, at ipa-utils.c:540 during Firefox LTO/PGO build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63576 --- Comment #7 from Jan Hubicka hubicka at gcc dot gnu.org --- Created attachment 34490 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34490action=edit Proposed fix I am going to try build firefox with PDO myself with the attached patch. It is bit tricky to merge the speculation right becuase both variant may disagree on speculative target.
[Bug inline-asm/64681] New: gcc assign wrong register for arm inline assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64681
Bug ID: 64681
Summary: gcc assign wrong register for arm inline assembly
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongwei.yao at arm dot com
Created attachment 34492
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34492action=edit
all related file.
I compile following code on linux by arm-linux-androideabi-gcc (gcc version 4.9
20140827) with following command:
arm-linux-androideabi-g++ -mfloat-abi=softfp -mfpu=neon -mthumb -Wall -Wextra
-march=armv7-a --sysroot=$ndk/platforms/android-21/arch-arm -O2 -Wall main.cpp
==c code start==
#include arm_neon.h
int main(void) {
return 0;
}
char buffer[32];
void bar(int n) {
int j = 0;
int64x1_t s = vdup_n_s64(0);
int64x1_t onev = vdup_n_s64(1);
int64_t sum = 0;
for (j = 0; j = n; j++) {
asm (vsub.s64 %0, %0, d1
: +w (s): : memory);
}
sum = (int64_t)j;
sum = vget_lane_s64(s, 0);
if(sum 0)
s = vsub_s64(s, onev);
vst1_s64((int64_t*)buffer, s);
}
==code end==
It returns:
/tmp/ccE0j9sL.s: Assembler messages:
/tmp/ccE0j9sL.s:55: Error: invalid instruction shape -- `vsub.s64 s14,s14,d1'
I think it is the bug in gcc that assign wrong register for variable s. It
should be d14 here, while it assignes s14.
The generated assembly file is:
==asm code start==
.syntax unified
.arch armv7-a
.eabi_attribute 27, 3
.fpu neon
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 2
.eabi_attribute 30, 2
.eabi_attribute 34, 1
.eabi_attribute 18, 4
.thumb
.filemain.cpp
.section.text.startup,ax,%progbits
.align2
.globalmain
.thumb
.thumb_func
.typemain, %function
main:
.fnstart
.LFB1870:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
movsr0, #0
bxlr
.cantunwind
.fnend
.sizemain, .-main
.text
.align2
.global_Z3bari
.thumb
.thumb_func
.type_Z3bari, %function
_Z3bari:
.fnstart
.LFB1871:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
cmpr0, #0
vmov.i32d7, #0 @ di
push{lr}
blt.L5
addsr0, r0, #1
movsr2, #0
.L4:
addsr2, r2, #1
cmpr2, r0
#APP
@ 17 src/main.cpp 1
vsub.s64 s14, s14, d1
@ 0 2
.thumb
bne.L4
fmrsr1, s14@ int
asrsr3, r2, #31
rsbr0, r1, #32
subslr, r1, #32
lslr0, r3, r0
lsrr2, r2, r1
itpl
asrpllr, r3, lr
orrr2, r2, r0
itpl
orrplr2, r2, lr
asrsr3, r3, r1
cmpr2, #1
sbcsr3, r3, #0
blt.L5
vmov.i32d16, #0x @ di
vadd.i64d7, d7, d16
.L5:
ldrr3, .L10
.LPIC1:
addr3, pc
ldrr3, [r3]
vst1.64{d7}, [r3:64]
ldrpc, [sp], #4
.L11:
.align2
.L10:
.wordbuffer(GOT_PREL)+(.-(.LPIC1+4))
.cantunwind
.fnend
.size_Z3bari, .-_Z3bari
.globalbuffer
.bss
.align3
.typebuffer, %object
.sizebuffer, 32
buffer:
.space32
.identGCC: (GNU) 4.9 20140827 (prerelease)
.section.note.GNU-stack,,%progbits
==asm code end==
[Bug target/64669] [5 Regression] aarch64-linux profiledbootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64669 --- Comment #4 from Jiong Wang jiwang at gcc dot gnu.org --- haven't enable go front end, ../gcc/configure --enable-languages=c,c++,fortran --disable-libsanitizer --enable-checking=release --disable-werror with make -j16 profiledbootstrap, I got several ../../../gcc/libgcc/libgcc2.c:858:1: internal compiler error: Segmentation fault and then the following final errors during stage2, will do further investigation tomorrow. tall-after-patch/aarch64-unknown-linux-gnu/bin/ -B/home/jiowan01/COMMUNITY/install-after-patch/aarch64-unknown-linux-gnu/lib/ -isystem /home/jiowan01/COMMUNITY/install-after-patch/aarch64-unknown-linux-gnu/include -isystem /home/jiowan01/COMMUNITY/install-after-patch/aarch64-unknown-linux-gnu/sys-include -g -O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -I. -I. -I../.././gcc -I../../../gcc/libgcc -I../../../gcc/libgcc/. -I../../../gcc/libgcc/../gcc -I../../../gcc/libgcc/../include -DHAVE_CC_TLS -o _clrsbdi2.o -MT _clrsbdi2.o -MD -MP -MF _clrsbdi2.dep -DL_clrsbdi2 -c ../../../gcc/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS 0x645377 crash_signal ../../gcc/gcc/toplev.c:372 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. make[3]: *** [_popcountdi2.o] Error 1 make[3]: *** Waiting for unfinished jobs 0x645377 crash_signal ../../gcc/gcc/toplev.c:372 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. make[3]: *** [_popcountsi2.o] Error 1 make[3]: Leaving directory `/home/jiowan01/COMMUNITY/build-after-patch/aarch64-unknown-linux-gnu/libgcc' make[2]: *** [all-stagefeedback-target-libgcc] Error 2 make[2]: Leaving directory `/home/jiowan01/COMMUNITY/build-after-patch' make[1]: *** [stagefeedback-bubble] Error 2 make[1]: Leaving directory `/home/jiowan01/COMMUNITY/build-after-patch' make: *** [profiledbootstrap] Error 2 ~
[Bug target/64652] [SH] ICE when using -mdiv=call-fp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64652 --- Comment #3 from Oleg Endo olegendo at gcc dot gnu.org --- Author: olegendo Date: Mon Jan 19 23:25:03 2015 New Revision: 219870 URL: https://gcc.gnu.org/viewcvs?rev=219870root=gccview=rev Log: gcc/testsuite/ PR target/64652 * gcc.target/sh/torture/pr64652.c (test): Rename to test_0. (test_1): New. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/sh/torture/pr64652.c
[Bug target/59946] -mpcrel -O2 produces illegal asm code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59946 --- Comment #3 from Jeffrey A. Law law at redhat dot com --- The m68000 does not support compare imm,pc-relative. Sadly the various comparison patterns play things fast and loose in terms of what order they emit their operands. That makes it nontrivial to write operand predicates and constraints which would allow the PC-relative addresses. I think the best solution is going to be to disallow pc-relative memory addresses in the comparison patterns/expanders.
[Bug sanitizer/64435] [5 Regression] Bootstrap failure in libsanitizer on AArch64 with Linux kernel = 3.15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64435 --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Mon Jan 19 08:39:27 2015 New Revision: 219833 URL: https://gcc.gnu.org/viewcvs?rev=219833root=gccview=rev Log: PR sanitizer/64435 * sanitizer_common/sanitizer_platform_limits_posix.cc: Cherry pick upstream r223925. Modified: trunk/libsanitizer/ChangeLog trunk/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc
[Bug c/64663] ICE at -O1 and above with -g enabled on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64663 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-19 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |4.8.5 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed.
[Bug testsuite/63971] Some of gcc.target/aarch64/test_frame_*.c tests fail now
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63971 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED |--- Ever confirmed|1 |0 --- Comment #8 from Andrew Pinski pinskia at gcc dot gnu.org --- And now they fail again. We need to add back the patch since conditional compares optimization is now in. This was one of the reasons why I did not revert my patch in the first place because I knew it would be back in for GCC 5.
[Bug fortran/59765] [4.9/5 Regression] [OOP] ICE on valid with finalizable array components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59765 --- Comment #13 from Andrew Pinski pinskia at gcc dot gnu.org --- https://plus.google.com/115499135426714220931/posts/7HfURniQGH9
[Bug go/64595] cgo installed into wrong directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595
--- Comment #5 from rguenther at suse dot de rguenther at suse dot de ---
On Wed, 14 Jan 2015, ian at airs dot com wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595
--- Comment #4 from Ian Lance Taylor ian at airs dot com ---
To invoke cgo, put this code in a file foo.go and type go run foo.go (or go
build foo.go ./foo).
package main
// #include stdio.h
// void cprintln(const char *s) { puts(s); }
import C
func main() {
C.cprintln(C.CString(Hello, world))
}
Hmm, I get
go-5 build foo.go
no debug info in ELF executable errno -1
fatal error: no debug info in ELF executable
runtime stack:
no debug info in ELF executable errno -1
panic during panic
runtime stack:
no debug info in ELF executable errno -1
stack trace unavailable
(not really informative, seems to be from the go-5 binary). On
openSUSE all binaries have debug information stripped and put
into separate objects not necessarily installed. Installing it
doesn't solve the above issue. The message seems to originate
from libbacktrace (unwind information is not stripped, obviously).
readelf -S /usr/bin/go-5
There are 33 section headers, starting at offset 0x70ad10:
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL
0 0 0
[ 1] .interp PROGBITS 00400270 0270
001c A 0 0 1
[ 2] .note.ABI-tag NOTE 0040028c 028c
0020 A 0 0 4
[ 3] .note.gnu.build-i NOTE 004002ac 02ac
0024 A 0 0 4
[ 4] .hash HASH 004002d0 02d0
0704 0004 A 6 0 8
[ 5] .gnu.hash GNU_HASH 004009d8 09d8
001c A 6 0 8
[ 6] .dynsym DYNSYM 004009f8 09f8
1770 0018 A 7 1 8
[ 7] .dynstr STRTAB 00402168 2168
093f A 0 0 1
[ 8] .gnu.version VERSYM 00402aa8 2aa8
01f4 0002 A 6 0 2
[ 9] .gnu.version_rVERNEED 00402ca0 2ca0
0120 A 7 4 8
[10] .rela.dyn RELA 00402dc0 2dc0
0048 0018 A 6 0 8
[11] .rela.plt RELA 00402e08 2e08
16f8 0018 A 613 8
[12] .init PROGBITS 00404500 4500
001a AX 0 0 4
[13] .plt PROGBITS 00404520 4520
0f60 0010 AX 0 0 16
[14] .text PROGBITS 00405480 5480
0029fc34 AX 0 0 16
[15] .fini PROGBITS 006a50b4 002a50b4
0009 AX 0 0 4
[16] .rodata PROGBITS 006a50c0 002a50c0
002b30b0 A 0 0 32
[17] .eh_frame_hdr PROGBITS 00958170 00558170
ea8c A 0 0 4
[18] .eh_frame PROGBITS 00966c00 00566c00
00072dc4 A 0 0 8
[19] .gcc_except_table PROGBITS 009d99c4 005d99c4
4849 A 0 0 4
[20] .tbss NOBITS 00bdec40 005dec40
00d8 WAT 0 0 8
[21] .init_array INIT_ARRAY 00bdec40 005dec40
0018 WA 0 0 8
[22] .fini_array FINI_ARRAY 00bdec58 005dec58
0008 WA 0 0 8
[23] .jcr PROGBITS 00bdec60 005dec60
0008 WA 0 0 8
[24] .data.rel.ro PROGBITS 00bdec80 005dec80
0148 WA 0 0 32
[25] .dynamic DYNAMIC 00bdedc8 005dedc8
0210 0010 WA 7 0 8
[26] .got PROGBITS 00bdefd8 005defd8
0018
[Bug lto/64025] [5 Regression] Several testsuite execution failures with -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64025 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Uroš Bizjak ubizjak at gmail dot com --- Fixed, see [1]. [1] https://gcc.gnu.org/ml/gcc-testresults/2015-01/msg02055.html
[Bug lto/64684] New: wrong code by LTO on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64684
Bug ID: 64684
Summary: wrong code by LTO on x86_64-linux-gnu
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk miscompiles the following code when using LTO on
x86_64-linux-gnu in both 32-bit and 64-bit modes.
This is a regression from 4.9.x.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 5.0.0 20150119 (experimental) [trunk revision 219832] (GCC)
$
$ gcc-trunk -O1 -c fn1.c
$ gcc-trunk -Os -c fn2.c
$ gcc-trunk -O0 -c main.c
$ gcc-trunk -O0 fn1.o fn2.o main.o
$ ./a.out
$
$
$ gcc-4.9 -flto -O1 -c fn1.c
$ gcc-4.9 -flto -Os -c fn2.c
$ gcc-4.9 -flto -O0 -c main.c
$ gcc-4.9 -flto fn1.o fn2.o main.o
$ ./a.out
$
$ gcc-trunk -flto -O1 -c fn1.c
$ gcc-trunk -flto -Os -c fn2.c
$ gcc-trunk -flto -O0 -c main.c
$ gcc-trunk -flto fn1.o fn2.o main.o
$ ./a.out
Aborted (core dumped)
$
$ cat fn1.c
extern void fn2 (void);
extern int a;
void
fn1 ()
{
a = -1;
fn2 ();
a = 1;
}
$ cat fn2.c
extern int a;
void
fn2 (void)
{
a = 0;
}
$ cat main.c
extern void fn1 (void);
int a;
int
main ()
{
fn1 ();
if (a != 0)
__builtin_abort ();
return 0;
}
$
[Bug rtl-optimization/64671] [5 Regression] s390-linux profiledbootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64671 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Thanks, with this patch s390-linux as well as s390x-linux profiledbootstrap succeeds again (well, s390x-linux worked before too).
[Bug go/64683] FAIL: runtime/pprof -- testing.go:278: The entry did not match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64683 --- Comment #3 from vries at gcc dot gnu.org --- configure line nobootstrap build: ... $ ./nobootstrap/install/bin/gccgo -v Using built-in specs. COLLECT_GCC=./nobootstrap/install/bin/gccgo COLLECT_LTO_WRAPPER=/data/vries/ref-master-15-01-19/nobootstrap/install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /home/vries/gcc_versions/data/ref-master-15-01-19/src/configure --prefix=/home/vries/gcc_versions/data/ref-master-15-01-19/nobootstrap/install --with-cloog=/home/vries/gcc_versions/infra --with-ppl=/home/vries/gcc_versions/infra --with-gmp=/home/vries/gcc_versions/infra --with-mpfr=/home/vries/gcc_versions/infra --with-mpc=/home/vries/gcc_versions/infra --with-isl=/home/vries/gcc_versions/infra --disable-bootstrap --enable-checking=yes,rtl --enable-languages=c,fortran,ada,java,objc,c++,go,obj-c++ Thread model: posix gcc version 5.0.0 20150119 (experimental) (GCC) ... configure line bootstrap build (the same, but without --disable-bootstrap): ... $ ./install/bin/gccgo -v Using built-in specs. COLLECT_GCC=./install/bin/gccgo COLLECT_LTO_WRAPPER=/data/vries/ref-master-15-01-19/install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /home/vries/gcc_versions/data/ref-master-15-01-19/src/configure --prefix=/home/vries/gcc_versions/data/ref-master-15-01-19/install --with-cloog=/home/vries/gcc_versions/infra --with-ppl=/home/vries/gcc_versions/infra --with-gmp=/home/vries/gcc_versions/infra --with-mpfr=/home/vries/gcc_versions/infra --with-mpc=/home/vries/gcc_versions/infra --with-isl=/home/vries/gcc_versions/infra --enable-checking=yes,rtl --enable-languages=c,fortran,ada,java,objc,c++,go,obj-c++ Thread model: posix gcc version 5.0.0 20150119 (experimental) (GCC) ...
[Bug go/64683] FAIL: runtime/pprof -- testing.go:278: The entry did not match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64683 --- Comment #2 from vries at gcc dot gnu.org --- Created attachment 34495 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34495action=edit libgo.log (bootstrap build)
[Bug sanitizer/63850] Building TSAN for Aarch64 results in assembler Error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63850 --- Comment #7 from vekumar at gcc dot gnu.org --- (In reply to clyon from comment #6) Venkat, Can you submit your GCC patch, in an accepable way? (no change to sanitizer libs code, and obviously do not activate tsan by default) Okay I will send out a patch that modifies libsanitizer/configure.ac and libsanitizer/tsan/Makefile.am that will separate out tsan_rtl_amd64.S from getting build for other targets. --- a/libsanitizer/tsan/tsan_rtl.h +++ b/libsanitizer/tsan/tsan_rtl.h @@ -679,7 +679,7 @@ void AcquireReleaseImpl(ThreadState *thr, uptr pc, SyncClock *c); // The trick is that the call preserves all registers and the compiler // does not treat it as a call. // If it does not work for you, use normal call. -#if TSAN_DEBUG == 0 +#if defined(__x86_64__) TSAN_DEBUG == 0 This change is also acceptable?
[Bug c/64619] No -Wsign-conversion warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64619
Mikhail Maltsev maltsevm at gmail dot com changed:
What|Removed |Added
CC||maltsevm at gmail dot com
--- Comment #1 from Mikhail Maltsev maltsevm at gmail dot com ---
Indeed, confirmed on recent revision, r219801.
FWIW: it affects only bitwise operations with constants and only in case when
result is wider than non-constant operand. They are handled specially in
unsafe_conversion_p (I guess, that's because bitwise AND is used frequently, so
false positives involving it should be avoided).
$ cat ./test.c
int a;
unsigned long b;
void foo()
{
a ^ b;
a ^ 0x1U;
a ^ 0x1UL;
a + 0x1U;
a + 0x1UL;
a 0xULL;
a 0x7FFFULL;
}
$ ../obj/gcc/xgcc -B../obj/gcc -c ./test.c -Wconversion
./test.c: In function 'foo':
./test.c:6:5: warning: conversion to 'long unsigned int' from 'int' may change
the sign of the result [-Wsign-conversion]
a ^ b;
^
./test.c:7:5: warning: conversion to 'unsigned int' from 'int' may change the
sign of the result [-Wsign-conversion]
a ^ 0x1U;
^
./test.c:9:5: warning: conversion to 'unsigned int' from 'int' may change the
sign of the result [-Wsign-conversion]
a + 0x1U;
^
./test.c:10:5: warning: conversion to 'long unsigned int' from 'int' may change
the sign of the result [-Wsign-conversion]
a + 0x1UL;
^
./test.c:11:5: warning: conversion to 'long long unsigned int' from 'int' may
change the sign of the result [-Wsign-conversion]
a 0xULL;
^
[Bug go/64683] New: FAIL: runtime/pprof -- testing.go:278: The entry did not match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64683 Bug ID: 64683 Summary: FAIL: runtime/pprof -- testing.go:278: The entry did not match Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: vries at gcc dot gnu.org CC: cmang at google dot com --- FAIL: TestMemoryProfiler (0.67s) testing.go:278: The entry did not match: 0: 0 \[1: 2097152\] @ 0x[0-9,a-f x]+ # 0x[0-9,a-f]+ pprof_test\.allocateTransient2M\+0x[0-9,a-f]+ .*/mprof_test.go:30 # 0x[0-9,a-f]+ runtime_pprof_test\.TestMemoryProfiler\+0x[0-9,a-f]+.*/mprof_test.go:65
[Bug go/64683] FAIL: runtime/pprof -- testing.go:278: The entry did not match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64683 --- Comment #4 from vries at gcc dot gnu.org --- Ran into this failure with r219832.
[Bug ipa/63576] [5 Regression] ICE : in ipa_merge_profiles, at ipa-utils.c:540 during Firefox LTO/PGO build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63576 --- Comment #8 from Jan Hubicka hubicka at gcc dot gnu.org --- Markus, I don't seem to be able to train firefox with current tree because of unrelated issues. If you would have chance to test the patch on your setup, it would be cool.
[Bug ipa/64282] [5 Regression] ICE in gimple_get_virt_method_for_vtable, at gimple-fold.c:5635
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64282
--- Comment #4 from Jan Hubicka hubicka at gcc dot gnu.org ---
The reduced testcase does not seem to reproduce for me. The ICE is however
just overactive sanity check - the program is invalid and accesses random data
as vtable pointer. In this case we can just optimize to unreachable instead of
ICEing. I am testing the following:
Index: gimple-fold.c
===
--- gimple-fold.c (revision 219876)
+++ gimple-fold.c (working copy)
@@ -5649,7 +5649,6 @@ gimple_get_virt_method_for_vtable (HOST_
if (TREE_CODE (v) != VAR_DECL
|| !DECL_VIRTUAL_P (v))
{
- gcc_assert (in_lto_p);
/* Pass down that we lost track of the target. */
if (can_refer)
*can_refer = false;
[Bug sanitizer/63850] Building TSAN for Aarch64 results in assembler Error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63850 --- Comment #8 from Dmitry Vyukov dvyukov at google dot com --- On Tue, Jan 20, 2015 at 9:06 AM, vekumar at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63850 --- Comment #7 from vekumar at gcc dot gnu.org --- (In reply to clyon from comment #6) Venkat, Can you submit your GCC patch, in an accepable way? (no change to sanitizer libs code, and obviously do not activate tsan by default) Okay I will send out a patch that modifies libsanitizer/configure.ac and libsanitizer/tsan/Makefile.am that will separate out tsan_rtl_amd64.S from getting build for other targets. --- a/libsanitizer/tsan/tsan_rtl.h +++ b/libsanitizer/tsan/tsan_rtl.h @@ -679,7 +679,7 @@ void AcquireReleaseImpl(ThreadState *thr, uptr pc, SyncClock *c); // The trick is that the call preserves all registers and the compiler // does not treat it as a call. // If it does not work for you, use normal call. -#if TSAN_DEBUG == 0 +#if defined(__x86_64__) TSAN_DEBUG == 0 This change is also acceptable? This change will be overwritten on the next integrate from upstream. Changes to runtimes need to go to llvm repo. However, in this case we just need to wait for mips64 change to be landed and it will fix this define as well.
[Bug fortran/57023] [4.8/4.9/5 Regression] Not packing arrays with changing variable used for size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57023 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org --- Comment #6 from Thomas Koenig tkoenig at gcc dot gnu.org --- Created attachment 34493 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34493action=edit Proposed patch This patch creates a temporary if a bound of the array contains a dummy variable which is not INTENT(IN) (so it could potentially be changed by the user). Modern code should always have INTENT(IN) for something passed as array bounds, anyway. We should be correct for all cases, but not try to optimize the pathological ones.
[Bug ipa/63576] [5 Regression] ICE : in ipa_merge_profiles, at ipa-utils.c:540 during Firefox LTO/PGO build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63576 --- Comment #9 from Markus Trippelsdorf trippels at gcc dot gnu.org --- I will give your patch a try. In case it might help here's the script I use for LTO/PGO (as you can see it starts the instrumented browser. I then just visit a couple of webpages to train it): markus@x4 mozilla-central % cat profile_build #!/bin/zsh mv .mozconfig .mozconfig_tmp cp .mozconfig_profile_gen .mozconfig nice -n 19 make -f client.mk killall firefox /var/tmp/moz-build-dir/dist/bin/firefox rm /var/tmp/moz-build-dir/**/Makefile rm /var/tmp/moz-build-dir/**/*.o rm /var/tmp/moz-build-dir/**/config.status rm /var/tmp/moz-build-dir/**/configure.pkl cp .mozconfig_profile_use .mozconfig nice -n 19 make -f client.mk make DESTDIR=/var/tmp/firefox-destdir -C /var/tmp/moz-build-dir install rm -fr /var/tmp/moz-build-dir mv .mozconfig_tmp .mozconfig Where .mozconfig_profile_gen contains: export CFLAGS=-march=native -fno-semantic-interposition -ffunction-sections -fdata-sections export CXXFLAGS=-march=native -fno-semantic-interposition -fprofile-generate -ffunction-sections -fdata-sections and .mozconfig_profile_use contains: export CFLAGS=-march=native -fno-semantic-interposition -ffunction-sections -fdata-sections export CXXFLAGS=-march=native -fno-semantic-interposition -flto=4 -fdevirtualize-at-ltrans -fprofile-use -fprofile-correction -ffunction-sections -fdata-sections
[Bug tree-optimization/64682] New: wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64682
Bug ID: 64682
Summary: wrong code at -O2 and -O3 on x86_64-linux-gnu
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk miscompiles the following code on x86_64-linux at -O2 and
-O3 in both 32-bit and 64-bit modes.
This is a regression from 4.9.x.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 5.0.0 20150119 (experimental) [trunk revision 219832] (GCC)
$
$ gcc-trunk -Os small.c; a.out
5
$ gcc-4.9 -O2 small.c; a.out
5
$
$ gcc-trunk -O2 small.c; a.out
1
$
---
int printf (const char *, ...);
int a, b = 1;
int
main ()
{
int i;
for (i = 0; i 56; i++)
for (; a; a--)
;
int *c = b;
if (*c)
*c = 1 % (unsigned int) *c | 5;
printf (%d\n, b);
return 0;
}
[Bug go/64683] FAIL: runtime/pprof -- testing.go:278: The entry did not match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64683 --- Comment #1 from vries at gcc dot gnu.org --- Created attachment 34494 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34494action=edit libgo.log (nobootstrap build)
[Bug bootstrap/64676] [5.0 Regression] SEGV in tree-ssa-structalias.c solve_constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64676 --- Comment #5 from David Edelsohn dje at gcc dot gnu.org --- This was caused by r219842 PR rtl-optimization/64081 * loop-iv.c (def_pred_latch_p): New function. (latch_dominating_def): Allow specific cases with non-single definitions. (iv_get_reaching_def): Likewise. (check_complex_exit_p): New function. (check_simple_exit): Use check_complex_exit_p to allow certain cases with exits not executing on any iteration.
[Bug sanitizer/64435] [5 Regression] Bootstrap failure in libsanitizer on AArch64 with Linux kernel = 3.15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64435 --- Comment #21 from Jakub Jelinek jakub at gcc dot gnu.org --- Ugh, there is also this junk: // By default we allow to use SizeClassAllocator64 on 64-bit platform. // But in some cases (e.g. AArch64's 39-bit address space) SizeClassAllocator64 // does not work well and we need to fallback to SizeClassAllocator32. // For such platforms build this code with -DSANITIZER_CAN_USE_ALLOCATOR64=0 or // change the definition of SANITIZER_CAN_USE_ALLOCATOR64 here. #ifndef SANITIZER_CAN_USE_ALLOCATOR64 # if defined(__aarch64__) || defined(__mips64) # define SANITIZER_CAN_USE_ALLOCATOR64 0 # else # define SANITIZER_CAN_USE_ALLOCATOR64 (SANITIZER_WORDSIZE == 64) # endif #endif It would be nice to know why that has been added. Was that just because #if SANITIZER_CAN_USE_ALLOCATOR64 # if defined(__powerpc64__) const uptr kAllocatorSpace = 0xa00ULL; const uptr kAllocatorSize = 0x200ULL; // 2T. # else const uptr kAllocatorSpace = 0x6000ULL; const uptr kAllocatorSize = 0x400ULL; // 4T. # endif has not been adjusted for the port? What is the minimum kAllocatorSize that would work? Given the very small 39-bit VA option on aarch64, I think if the allocator64 memory has to be normal memory with shadow, we could only use say something like kAllocatorSpace 0x8 and kAllocatorSize the same value, i.e. 32GB. Would that be enough? There is also the: // The range of addresses which can be returned my mmap. // FIXME: this value should be different on different platforms, // e.g. on AArch64 it is most likely (1ULL 39). Larger values will still work // but will consume more memory for TwoLevelByteMap. #if defined(__aarch64__) # define SANITIZER_MMAP_RANGE_SIZE FIRST_32_SECOND_64(1ULL 32, 1ULL 39) #else # define SANITIZER_MMAP_RANGE_SIZE FIRST_32_SECOND_64(1ULL 32, 1ULL 47) #endif which is again wrong for aarch64. Does it really has to be compile time constant? The 1ULL 47 is also wrong ppc64, mips64, isn't it?
[Bug c++/64677] incorrect result with complex division?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64677 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- One part is different. Most likely not a bug. Division really depends on fused multiple add to get good results IIRC.
[Bug c++/64677] incorrect result with complex division?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64677 --- Comment #2 from Sanjay Patel spatel at rotateright dot com --- This is on plain x86-64 with SSE (before the addition of any FMA instructions), so lack of FMA must be accounted for? The answers differ in the last digit / ULP. Is there some standard or golden implementation that will answer which answer is correct?
[Bug ipa/64668] [5 Regression] internal compiler error: in compare_ssa_name, at ipa-icf-gimple.c:120
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64668 --- Comment #7 from Martin Liška marxin at gcc dot gnu.org --- Author: marxin Date: Mon Jan 19 22:02:04 2015 New Revision: 219861 URL: https://gcc.gnu.org/viewcvs?rev=219861root=gccview=rev Log: Fix PR64668. * objc/compile/pr64668.m: New test. PR ipa/64668 * ipa-icf-gimple.c (func_checker::compare_operand): Call proper function for second argument of OBJ_TYPE_REF. Added: trunk/gcc/testsuite/objc/compile/pr64668.m Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-icf-gimple.c trunk/gcc/testsuite/ChangeLog
[Bug ipa/64668] [5 Regression] internal compiler error: in compare_ssa_name, at ipa-icf-gimple.c:120
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64668 --- Comment #8 from Martin Liška marxin at gcc dot gnu.org --- Fixed in 5.0.0.
[Bug fortran/64674] [OOP] ICE in ASSOCIATE with allocated class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64674 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-19 CC||janus at gcc dot gnu.org Version|fortran-dev |5.0 Summary|OOP Internal compiler error |[OOP] ICE in ASSOCIATE with |in associate with allocated |allocated class |class | Ever confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org --- Confirmed. Slightly reduced test case: Type T integer :: map end Type T class(T), allocatable :: Cls(:) allocate(Cls(2)) associate(CL = Cls(1)) CL%map = 2 end associate end
[Bug target/64669] [5 Regression] aarch64-linux profiledbootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64669 --- Comment #2 from Richard Henderson rth at gcc dot gnu.org --- Hmm. I'm not even getting that far with r219852 gcc/expmed.h: In function ‘void init_expmed()’: gcc/expmed.h:613:77: error: array subscript is above array bounds [-Werror=array-bounds] return this_target_expmed-x_mul_highpart_cost[speed][mode - MIN_MODE_INT]; ^ gcc/expmed.h:263:33: error: array subscript is below array bounds [-Werror=array-bounds] return costs-cost[speed][idx]; ^ gcc/expmed.h:263:33: error: array subscript is below array bounds [-Werror=array-bounds] return costs-cost[speed][idx]; ^ gcc/expmed.h:263:33: error: array subscript is above array bounds [-Werror=array-bounds] return costs-cost[speed][idx]; ^ gcc/expmed.h:263:33: error: array subscript is above array bounds [-Werror=array-bounds] return costs-cost[speed][idx];
[Bug fortran/64674] [OOP] ICE in ASSOCIATE with allocated class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64674 --- Comment #2 from janus at gcc dot gnu.org --- When commenting the line with 'CL%map', one gets a different ICE: associate(CL = Cls(1)) 1 internal compiler error: in gfc_conv_expr_descriptor, bei fortran/trans-array.c:6499 0x692657 gfc_conv_expr_descriptor(gfc_se*, gfc_expr*) /home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-array.c:6499 0x6de41c trans_associate_var /home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-stmt.c:1313 0x6de41c gfc_trans_block_construct(gfc_code*) /home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-stmt.c:1463 0x681d37 trans_code /home/jweil/gcc/gcc50/trunk/gcc/fortran/trans.c:1755 0x6a2d63 gfc_generate_function_code(gfc_namespace*) /home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-decl.c:5843 0x63e400 translate_all_program_units /home/jweil/gcc/gcc50/trunk/gcc/fortran/parse.c:5341 0x63e400 gfc_parse_file() /home/jweil/gcc/gcc50/trunk/gcc/fortran/parse.c:5538 0x67dda5 gfc_be_parse_file /home/jweil/gcc/gcc50/trunk/gcc/fortran/f95-lang.c:228
[Bug ipa/64668] [5 Regression] internal compiler error: in compare_ssa_name, at ipa-icf-gimple.c:120
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64668 Martin Liška marxin at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Martin Liška marxin at gcc dot gnu.org --- Fixed.
[Bug debug/63741] lm32 ICE in dwarf2out_frame_debug_expr, at dwarf2cfi.c:1677
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63741 --- Comment #4 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Joel Sherrill from comment #3) Added the dwarf maintainers hoping to get an answer. From an RTEMS perspective, the lm32 is not usable. Both 4.9 and the head are broken. Hoping you two have an idea. Happy to help since this is a cross target. This is a target problem. Please see stack_adjust function, where emit_move_insn is used to move an immediate to r10. However, emit_move_insn with (const_int -32812) generates two insn sequence: (insn 952 123 953 2 (set (reg:SI 10 r10) (const_int -65536 [0x])) ../../../../../../rtems/c/src/../../cpukit/libdl/fastlz.c:167 -1 (nil)) (insn/f 953 952 954 2 (set (reg:SI 10 r10) (ior:SI (reg:SI 10 r10) (const_int 32724 [0x7fd4]))) ../../../../../../rtems/c/src/../../cpukit/libdl/fastlz.c:167 -1 (expr_list:REG_EQUAL (const_int -32812 [0x7fd4]) (nil))) However: /* r10 is caller saved so it can be used as a temp reg. */ rtx r10; r10 = gen_rtx_REG (word_mode, 10); insn = emit_move_insn (r10, GEN_INT (amount)); if (amount 0) RTX_FRAME_RELATED_P (insn) = 1; emit_move_insn returns only the *last* insn of the sequence (insn 953 in the above dump). (insn 952) doesn't get RTX_FRAME_RELATED_P flag set - please note lack of /f modifier - and consequently dwarf2out_frame_debug_expr trips in Rule 7 due to unknown cfa_temp.reg (which would be otherwise initialized in insn 952, following Rule 6). So, considering that emit_move_insn can generate a sequence of insns, but only the last insn is returned as a return value of a function, insn = emit_move_insn (r10, GEN_INT (amount)); RTX_FRAME_RELATED_P (insn) = 1; is not the correct way to set /f flags to all insn of the generated sequence.
[Bug target/64669] [5 Regression] aarch64-linux profiledbootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64669 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- That was the --disable-werror.
[Bug target/63347] m68k misoptimisation with -fschedule-insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63347 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added CC||law at redhat dot com --- Comment #10 from Jeffrey A. Law law at redhat dot com --- Bernd, need your input on the best direction here... This BZ is caused by mis-handling of SCHED_GROUP_P in some scheduler work from a few years ago (meaning it's probably a 4.8 and 4.9 regression as well). The offending commit is : Author: bernds bernds@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Fri Apr 1 17:48:35 2011 + * haifa-sched.c (prune_ready_list): New function, broken out of schedule_block. (schedule_block): Use it. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@171845 138bc75d-0d04-0410-961f-82ee72b054a4 As can be seen in this BZ, it can cause incorrect code anywhere we use SCHED_GROUP_P to keep insns together for correctness. It can cause missed-optimizations for things like insn fusion. The old code would just advance the cycle counter forward the appropriate number of cycles when it saw a SCHED_GROUP_P insn. I can hack something together to have a similar effect here, but I'm unsure if it would break the tic6x.
[Bug middle-end/64642] Malformed code as result of C-cast to (polymorphic) object-reference (depends on opt-level ...)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64642 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Well, you invoke undefined behavior here which means GCC can do anything it wants. In this case it simply marks the virtual call unreachable and simplifies the code according to that.
[Bug gcov-profile/64634] [4.8/4.9/5 Regression] gcov reports catch(...) as not executed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64634 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-19 Known to work||4.4.7 Target Milestone|--- |4.8.5 Summary|gcov reports catch(...) as |[4.8/4.9/5 Regression] gcov |not executed|reports catch(...) as not ||executed Ever confirmed|0 |1 Known to fail||4.9.2 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed.
[Bug c++/64667] -Winit-self ignored for reference fields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64667 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-19 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- The fix for PR 18016 can probably be extended to references pretty easily. See also PR 19808 and PR 18605.
[Bug fortran/64230] [4.9/5 Regression] Segmentation fault - invalid memory reference in a compiler-generated finalizer for a complicated type hierarchy when a polymorphic variable is allocated in an e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64230 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org --- Comment #3 from janus at gcc dot gnu.org --- Have a patch ...
[Bug target/64304] AArch64 miscompilation with -mgeneral-regs-only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64304 --- Comment #5 from Jiong Wang jiwang at gcc dot gnu.org --- Author: jiwang Date: Mon Jan 19 14:13:33 2015 New Revision: 219844 URL: https://gcc.gnu.org/viewcvs?rev=219844root=gccview=rev Log: [AArch64] Remove ashift pattern for QI/HI 2015-01-19 Jiong Wang jiong.w...@arm.com Andrew Pinski apin...@cavium.com gcc/ PR target/64304 * config/aarch64/aarch64.md (define_insn *ashlmode3_insn): Deleted. (ashlmode3): Don't expand if operands[2] is not constant. gcc/testsuite/ * gcc.target/aarch64/pr64304.c: New testcase. Added: trunk/gcc/testsuite/gcc.target/aarch64/pr64304.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64.md trunk/gcc/testsuite/ChangeLog
[Bug c++/64647] [5 Regression] [C++14] std::__max_element contains code not allowed in constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64647 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |5.0
[Bug c++/64666] New: gcc wrongly accepts assignment in constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64666
Bug ID: 64666
Summary: gcc wrongly accepts assignment in constant expression
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Given source code
void f()
{
int i = 5, j;
int a[ j = i];
}
Recent trunk code says
$ ~/gcc/results/bin/g++ -g -O2 -Wall -Wextra -c jan19g.cc
jan19g.cc: In function ‘void f()’:
jan19g.cc:6:6: warning: unused variable ‘a’ [-Wunused-variable]
int a[ j = i];
^
$
Here is clang doing something different
$ ~/llvm/results/bin/clang++ -g -O2 -Wall -c jan19g.cc
jan19g.cc:6:11: error: expected ']'
int a[ j = i];
^
jan19g.cc:6:7: note: to match this '['
int a[ j = i];
^
1 error generated.
$
[Bug target/64669] [5 Regression] aarch64-linux profiledbootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64669 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target||aarch64-linux Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-19 Target Milestone|--- |5.0 Ever confirmed|0 |1
[Bug testsuite/63971] Some of gcc.target/aarch64/test_frame_*.c tests fail now
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63971 --- Comment #9 from Tejas Belagod belagod at gcc dot gnu.org --- Author: belagod Date: Mon Jan 19 12:57:48 2015 New Revision: 219838 URL: https://gcc.gnu.org/viewcvs?rev=219838root=gccview=rev Log: 2015-01-19 Tejas Belagod tejas.bela...@arm.com PR target/63971 * gcc.target/aarch64/test_frame_1.c: Expect only two loads of x30 (in the epilogue). * gcc.target/aarch64/test_frame_6.c: Likewise. * gcc.target/aarch64/test_frame_2.c: Expect only one pair load of x30 and x19 (in the epilogue). * gcc.target/aarch64/test_frame_4.c: Likewise. * gcc.target/aarch64/test_frame_7.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/aarch64/test_frame_1.c trunk/gcc/testsuite/gcc.target/aarch64/test_frame_2.c trunk/gcc/testsuite/gcc.target/aarch64/test_frame_4.c trunk/gcc/testsuite/gcc.target/aarch64/test_frame_6.c trunk/gcc/testsuite/gcc.target/aarch64/test_frame_7.c
[Bug fortran/61933] [5 Regression] Inquire on internal units
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61933 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Summary|Inquire on internal units |[5 Regression] Inquire on ||internal units --- Comment #14 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- I'm adding the regression marker for the problem related to finding existing units in the current trunk (comment #7), as is appropriate for the current stage.
[Bug tree-optimization/62630] [5 regression] gcc.dg/graphite/vect-pr43423.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62630
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords||missed-optimization
CC||grosser at gcc dot gnu.org
--- Comment #4 from Richard Biener rguenth at gcc dot gnu.org ---
7: note: === vect_analyze_data_refs ===
Creating dr for a[_56]
analyze_innermost:
failed: evolution of offset is not affine.
base_address:
offset from base address:
constant offset from base address:
step:
aligned to:
base_object: a
Access function 0: (int) {(unsigned int) graphite_IV.5_50, +, 1}_3;
the graphive IVs are signed long
bb 8:
_46 = (signed long) mid_6(D);
...
bb 9:
graphite_IV.5_50 = MAX_EXPR _46, 0;
_51 = (signed long) n_5(D);
_52 = _51 + -1;
bb 10:
# graphite_IV.5_53 = PHI graphite_IV.5_50(9), graphite_IV.5_54(11)
_56 = (int) graphite_IV.5_53;
_55 = a[_56];
_57 = c[_56];
_58 = _55 + _57;
_64 = (int) graphite_IV.5_53;
a[_64] = _58;
graphite_IV.5_54 = graphite_IV.5_53 + 1;
if (graphite_IV.5_53 _52)
goto bb 11;
else
goto bb 13;
bb 11:
goto bb 10;
(instantiate_scev
(instantiate_below = 9)
(evolution_loop = 3)
(chrec = (ssizetype) (int) {(unsigned int) graphite_IV.5_50, +, 1}_3)
(res = (ssizetype) (int) {(unsigned int) graphite_IV.5_50, +, 1}_3))
so it appears to SCEV that the evolution may wrap.
With GCC 4.9 we choose signed int as GRAPHITE IV.
Looks like the IV type is statically determined by
graphite_expression_type_precision as
/* We always try to use signed 128 bit types, but fall back to smaller types
in case a platform does not provide types of these sizes. In the future we
should use isl to derive the optimal type for each subexpression. */
static int max_mode_int_precision =
GET_MODE_PRECISION (mode_for_size (MAX_FIXED_MODE_SIZE, MODE_INT, 0));
static int graphite_expression_type_precision = 128 = max_mode_int_precision ?
128 : max_mode_int_precision;
Not sure how this doesn't end up with __int128_t on x86_64, but ...
It's obviously a bad choice to use __int128_t (or even signed long) everywhere.
Let's XFAIL this testcase if nobody fixes the underlying issue. What does it
take to use ISL to derive the optimal type for each subexpression? Is
that even possible?
[Bug target/64580] very high rs6000_stack_info() usage during LTO Firefox build on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64580 --- Comment #2 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Hi Segher, on gcc112 you can use the following command to reproduce the issue: % g++ -xlto -c -mcpu=power8 -O3 -fPIC -fno-exceptions -fltrans -o /dev/null /var/tmp/libxul.so.ltrans8.o
[Bug target/64448] [5 Regression] New middle-end pattern breaks vector BIF folding on AArch64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64448 --- Comment #3 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Mon Jan 19 14:03:23 2015 New Revision: 219843 URL: https://gcc.gnu.org/viewcvs?rev=219843root=gccview=rev Log: [AArch64] PR 64448: Combine ((x ^ y) m) ^ x into bsl/bif instruction PR target/64448 * config/aarch64/aarch64-simd.md (aarch64_simd_bslmode_internal): Match xor-and-xor RTL pattern. Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64-simd.md
[Bug target/64304] AArch64 miscompilation with -mgeneral-regs-only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64304 Jiong Wang jiwang at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jiong Wang jiwang at gcc dot gnu.org --- mark as fixed.
[Bug target/64669] New: [5 Regression] aarch64-linux profiledbootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64669 Bug ID: 64669 Summary: [5 Regression] aarch64-linux profiledbootstrap failure Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org r219833 (but also older revisions, e.g. r219767) ../configure --enable-languages=c,c++,fortran,go --enable-checking=release --disable-werror make -j16 profiledbootstrap fails on aarch64: /tmp/jakub/gcc/obj/./prev-gcc/cc1plus -quiet -nostdinc++ -I /tmp/jakub/gcc/obj/prev-aarch64-unknown-linux-gnu/libstdc++-v3/include/aarch64-unknown-linux-gnu -I /tmp/jakub/gcc/obj/prev-aarch64-unknown-linux-gnu/libstdc++-v3/include -I /tmp/jakub/gcc/libstdc++-v3/libsupc++ -I . -I go -I ../../gcc -I ../../gcc/go -I ../../gcc/../include -I ../../gcc/../libcpp/include -I ../../gcc/../libdecnumber -I ../../gcc/../libdecnumber/dpd -I ../libdecnumber -I ../../gcc/../libbacktrace -I ../../gcc/go -I ../../gcc/go/gofrontend -iprefix /tmp/jakub/gcc/obj/prev-gcc/../lib/gcc/aarch64-unknown-linux-gnu/5.0.0/ -isystem /tmp/jakub/gcc/obj/./prev-gcc/include -isystem /tmp/jakub/gcc/obj/./prev-gcc/include-fixed -MMD go/lex.d -MF go/.deps/lex.TPo -MP -MT go/lex.o -D_GNU_SOURCE -D IN_GCC_FRONTEND -D IN_GCC -D HAVE_CONFIG_H ../../gcc/go/gofrontend/lex.cc -quiet -dumpbase lex.cc -mlittle-endian -mabi=lp64 -auxbase-strip go/lex.o -g -O2 -Wextra -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wsuggest-attribute=format -Woverloaded-virtual -Wpedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fprofile-use -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -o /tmp/cclDZwuT.s ../../gcc/go/gofrontend/lex.cc: In member function ‘const char* Lex::advance_one_char(const char*, bool, unsigned int*, bool*)’: ../../gcc/go/gofrontend/lex.cc:1158:1: internal compiler error: in convert_move, at expr.c:688 Lex::advance_one_char(const char* p, bool is_single_quote, unsigned int* value, ^ Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Fails the same with stage1-gcc/cc1plus instead of prev-gcc/cc1plus, doesn't ICE without -fprofile-use. #0 fancy_abort (file=0x14b3cd8 ../../gcc/expr.c, line=688, function=0x14b4700 convert_move(rtx_def*, rtx_def*, int)::__FUNCTION__ convert_move) at ../../gcc/diagnostic.c:1288 #1 0x009f2d90 in convert_move (to=0x3ffacdec060, from=0x3ffacdebf58, unsignedp=1) at ../../gcc/expr.c:688 #2 0x009f3264 in convert_modes (mode=SImode, oldmode=CC_DEQmode, x=0x3ffacdebf58, unsignedp=1) at ../../gcc/expr.c:769 #3 0x00c97120 in prepare_operand (icode=CODE_FOR_cbranchsi4, x=0x3ffacdebf58, opnum=1, mode=QImode, wider_mode=SImode, unsignedp=1) at ../../gcc/optabs.c:4293 #4 0x00c96e04 in prepare_cmp_insn (x=0x3ffacdebf58, y=0x3ffaf3e0480, comparison=LEU, size=0x0, unsignedp=1, methods=OPTAB_LIB_WIDEN, ptest=0x3ffe248, pmode=0x3ffe228) at ../../gcc/optabs.c:4203 #5 0x00c974a8 in emit_cmp_and_jump_insns (x=0x3ffacdebf58, y=0x3ffaf3e0480, comparison=LEU, size=0x0, mode=QImode, unsignedp=1, label=0x3fface05e00, prob=0) at ../../gcc/optabs.c:4381 #6 0x0095ca80 in do_compare_rtx_and_jump (op0=0x3ffacdebf58, op1=0x3ffaf3e0480, code=LEU, unsignedp=1, mode=QImode, size=0x0, if_false_label=0x0, if_true_label=0x3fface05e00, prob=0) at ../../gcc/dojump.c:1159 #7 0x0095cca4 in do_compare_and_jump (treeop0=0x3ffac41a200, treeop1=0x3ffaf371038, signed_code=LE, unsigned_code=LEU, if_false_label=0x0, if_true_label=0x3fface05e00, prob=0) at ../../gcc/dojump.c:1241 #8 0x0095abb4 in do_jump_1 (code=LE_EXPR, op0=0x3ffac41a200, op1=0x3ffaf371038, if_false_label=0x0, if_true_label=0x3fface05e00, prob=0) at ../../gcc/dojump.c:296 #9 0x0095a448 in jumpif_1 (code=LE_EXPR, op0=0x3ffac41a200, op1=0x3ffaf371038, label=0x3fface05e00, prob=0) at ../../gcc/dojump.c:176 #10 0x008df938 in expand_gimple_cond (bb=0x3ffac329240, stmt=0x3ffac30a230) at ../../gcc/cfgexpand.c:2231 #11 0x008e7f1c in expand_gimple_basic_block (bb=0x3ffac329240, disable_tail_calls=false) at ../../gcc/cfgexpand.c:5262 #12 0x008e9af4 in (anonymous namespace)::pass_expand::execute (this=0x1a0fe20, fun=0x3ffb10feaf0) at ../../gcc/cfgexpand.c:6003 #13 0x00cc092c in execute_one_pass (pass=0x1a0fe20) at ../../gcc/passes.c:2326 #14 0x00cc0bd8 in execute_pass_list_1 (pass=0x1a0fe20) at ../../gcc/passes.c:2378 #15 0x00cc0c54 in execute_pass_list (fn=0x3ffb10feaf0, pass=0x1a0cca0) at ../../gcc/passes.c:2389 #16 0x00928030 in cgraph_node::expand (this=0x3ffb108e118) at ../../gcc/cgraphunit.c:1804 in prepare_operand x is (reg:CC_DEQ 66 cc [ D.47994 ]) and trying to convert it to SImode is of course deemed to fail. In do_compare_and_jump treeop0
[Bug c++/64665] Overload resolution not working with std::initializer_liststd::string and bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64665 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-19 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- Possibly a duplicate of another bug but I can't find one right now.
[Bug target/64669] [5 Regression] aarch64-linux profiledbootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64669
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jiwang at gcc dot gnu.org,
||zhenqiang.chen at arm dot com
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org ---
Seems this is because of the gen_ccmp_{first,next} stuff that is being
constantly added and reverted again.
How can it work reliably? I mean, if expansion of something returns you
something in completely different mode, how do you ensure that the side that
consumes it will know it has to handle it specially? Some new RTX code
signalizing that would at least make it more clear, but you'd need to ensure
that if you don't handle it specially, that it will be automatically turned
back to the expansion that didn't do anything special.
[Bug lto/61886] [4.8/4.9/5 Regression] LTO breaks fread with _FORTIFY_SOURCE=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886 --- Comment #28 from Richard Biener rguenth at gcc dot gnu.org --- Still broken :(
[Bug middle-end/64313] [5 Regression] gcc.dg/torture/builtin-explog-1.c fails on bare-metal targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64313
--- Comment #6 from Richard Biener rguenth at gcc dot gnu.org ---
So sth like
Index: gcc/c-family/c-gimplify.c
===
--- gcc/c-family/c-gimplify.c (revision 219839)
+++ gcc/c-family/c-gimplify.c (working copy)
@@ -300,6 +300,20 @@ c_gimplify_expr (tree *expr_p, gimple_se
break;
}
+case ADDR_EXPR:
+ {
+ /* If we see a call to a declared builtin or see its address
+ being taken (we can unify those cases) then we can mark
+ the builtin for implicit generation by GCC. */
+ tree fndecl = TREE_OPERAND (*expr_p, 0);
+ if (TREE_CODE (fndecl) == FUNCTION_DECL
+DECL_BUILT_IN_CLASS (fndecl) == BUILT_IN_NORMAL
+ /* C_DECL_DECLARED_BUILTIN */
+DECL_LANG_FLAG_3 (fndecl))
+ set_builtin_decl_implicit_p (DECL_FUNCTION_CODE (fndecl), true);
+ break;
+ }
+
case CILK_SPAWN_STMT:
gcc_assert
(fn_contains_cilk_spawn_p (cfun)
works for C (yeah, that flag check needs to become a new langhook due to the
way we share c_gimplify across frontends... :/). For C++ there isn't anything
similar to C_DECL_DECLARED_BUILTIN, but of course the testcase is only
exercised for C. Alternatively we can add a flag to the middle-end that FEs
can set to treat a builtin as candidate for implicit use if it is used
(but that way we can't distinguish uses of __builtin_log10 from declared
log10).
Thus, similar to [set_]builtin_decl_implicit_p have a
[set_]builtin_decl_declared_p - then we can handle the above in generic
gimplifier routines.
[Bug rtl-optimization/64081] [5 Regression] r217827 prevents RTL loop unroll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64081 --- Comment #3 from ienkovich at gcc dot gnu.org --- Author: ienkovich Date: Mon Jan 19 13:58:54 2015 New Revision: 219842 URL: https://gcc.gnu.org/viewcvs?rev=219842root=gccview=rev Log: gcc/ PR rtl-optimization/64081 * loop-iv.c (def_pred_latch_p): New function. (latch_dominating_def): Allow specific cases with non-single definitions. (iv_get_reaching_def): Likewise. (check_complex_exit_p): New function. (check_simple_exit): Use check_complex_exit_p to allow certain cases with exits not executing on any iteration. gcc/testsuite/ PR rtl-optimization/64081 * gcc.dg/pr64081.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr64081.c Modified: trunk/gcc/ChangeLog trunk/gcc/loop-iv.c trunk/gcc/testsuite/ChangeLog
[Bug target/64532] [4.9/5 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64532 --- Comment #8 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Author: ramana Date: Mon Jan 19 14:55:28 2015 New Revision: 219847 URL: https://gcc.gnu.org/viewcvs?rev=219847root=gccview=rev Log: Improve documentation of register constraints. While looking at PR target/64532- I realized we haven't documented all the register constraints. I'm not documenting the other immediate constraints as it is not clear to me how much of that is actually useful yet and I don't have the time this afternoon to clean this up. Built documentation and looked at it. Applied. Ramana Modified: trunk/gcc/ChangeLog trunk/gcc/doc/md.texi
[Bug rtl-optimization/64671] New: [5 Regression] s390-linux profiledbootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64671
Bug ID: 64671
Summary: [5 Regression] s390-linux profiledbootstrap failure
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
On s390-linux, profiledbootstrap hangs while compiling various libgcc routines
with stageprofile cc1.
This looks like a register allocation issue to me.
.L2667:
.loc 3 1448 0
lr %r1,%r8
ahi %r1,-1
lhi %r4,1
lr %r10,%r1
jne .L2667
is an endless loop, because r8 doesn't change in the loop, so if it is not 1 at
the beginning of the loop, it will cycle forever.
During reload one can see first the:
(code_label 6256 8889 3592 323 2667 [1 uses])
(note 3592 6256 3599 323 [bb 323] NOTE_INSN_BASIC_BLOCK)
(insn 3599 3592 11197 323 (set (reg:SI 4 %r4)
(const_int 1 [0x1])) ../../gcc/vec.h:1448 68 {*movsi_esa}
(nil))
(insn 11197 3599 11038 323 (parallel [
(set (pc)
(if_then_else (ne (reg:SI 8 %r8 [orig:1459 D.73971 ] [1459])
(const_int 1 [0x1]))
(label_ref 6256)
(pc)))
(set (reg:SI 10 %r10 [orig:1460 D.73963 ] [1460])
(plus:SI (reg:SI 8 %r8 [orig:1459 D.73971 ] [1459])
(const_int -1 [0x])))
(clobber (reg:SI 1 %r1 [5607]))
(clobber (reg:CC 33 %cc))
]) ../../gcc/vec.h:1448 619 {doloop_si64}
(nil))
which already is the endless loop, but at *.ira there is no such code like
that, so it rematerialized from somewhere else.
[Bug sanitizer/64670] -fsanitize=vptr leads to undefined reference to `typeinfo for class'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64670 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- I think that's because of the #pragma interface.
[Bug libgomp/64635] darwin produces libgomp-plugin-host_nonshm.1.dylib but tries to load libgomp-plugin-host_nonshm.so.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64635 --- Comment #15 from howarth at bromo dot med.uc.edu --- (In reply to Dominique d'Humieres from comment #14) With the attached patch at https://gcc.gnu.org/bugzilla/attachment.cgi?id=34469 and the patch at https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01479.html, I get ... I have found the origin of the problem: I am testing gfortran with the additional options '-g -flto', apparently this propagates to libgomp.oacc-fortran (I did not check why). Could someone test libgomp.oacc-fortran with these options on a linux platform? I see the same ICEs on linux... $ /home/howarth/build/gcc/xgcc -B/home/howarth/build/gcc/ /home/howarth/gcc-trunk/libgomp/testsuite/libgomp.oacc-fortran/asyncwait-1.f90 -B/home/howarth/build/x86_64-unknown-linux-gnu/32/libgomp/ -B/home/howarth/build/x86_64-unknown-linux-gnu/32/libgomp/.libs -I/home/howarth/build/x86_64-unknown-linux-gnu/32/libgomp -I/home/howarth/gcc-trunk/libgomp/testsuite/../../include -I/home/howarth/gcc-trunk/libgomp/testsuite/.. -march=i486 -fmessage-length=0 -fno-diagnostics-show-caret -fdiagnostics-color=never -fopenacc -B/home/howarth/build/x86_64-unknown-linux-gnu/32/libgomp/../libquadmath/.libs/ -DACC_DEVICE_TYPE_host_nonshm=1 -DACC_MEM_SHARED=0 -O0 -B/home/howarth/build/x86_64-unknown-linux-gnu/32/libgomp/../libgfortran/.libs -fintrinsic-modules-path=/home/howarth/build/x86_64-unknown-linux-gnu/32/libgomp -L/home/howarth/build/x86_64-unknown-linux-gnu/32/libgomp/.libs -L/home/howarth/build/x86_64-unknown-linux-gnu/32/libgomp/../libquadmath/.libs/ -L/home/howarth/build/x86_64-unknown-linux-gnu/32/libgomp/../libgfortran/.libs -lgfortran -lm -m32 -o ./asyncwait-1.exe [howarth@diego1 testsuite]$ /home/howarth/build/gcc/xgcc -B/home/howarth/build/gcc/ /home/howarth/gcc-trunk/libgomp/testsuite/libgomp.oacc-fortran/asyncwait-1.f90 -B/home/howarth/build/x86_64-unknown-linux-gnu/32/libgomp/ -B/home/howarth/build/x86_64-unknown-linux-gnu/32/libgomp/.libs -I/home/howarth/build/x86_64-unknown-linux-gnu/32/libgomp -I/home/howarth/gcc-trunk/libgomp/testsuite/../../include -I/home/howarth/gcc-trunk/libgomp/testsuite/.. -march=i486 -fmessage-length=0 -fno-diagnostics-show-caret -fdiagnostics-color=never -fopenacc -B/home/howarth/build/x86_64-unknown-linux-gnu/32/libgomp/../libquadmath/.libs/ -DACC_DEVICE_TYPE_host_nonshm=1 -DACC_MEM_SHARED=0 -O0 -B/home/howarth/build/x86_64-unknown-linux-gnu/32/libgomp/../libgfortran/.libs -fintrinsic-modules-path=/home/howarth/build/x86_64-unknown-linux-gnu/32/libgomp -L/home/howarth/build/x86_64-unknown-linux-gnu/32/libgomp/.libs -L/home/howarth/build/x86_64-unknown-linux-gnu/32/libgomp/../libquadmath/.libs/ -L/home/howarth/build/x86_64-unknown-linux-gnu/32/libgomp/../libgfortran/.libs -lgfortran -lm -m32 -flto -o ./asyncwait-1.exe lto1: internal compiler error: in streamer_get_builtin_tree, at tree-streamer-in.c:1151 0xc25fcf streamer_get_builtin_tree(lto_input_block*, data_in*) ../../gcc-trunk/gcc/tree-streamer-in.c:1151 0x90a944 lto_input_tree_1(lto_input_block*, data_in*, LTO_tags, unsigned int) ../../gcc-trunk/gcc/lto-streamer-in.c:1320 0x90ab29 lto_input_scc(lto_input_block*, data_in*, unsigned int*, unsigned int*) ../../gcc-trunk/gcc/lto-streamer-in.c:1248 0x5f862e lto_read_decls ../../gcc-trunk/gcc/lto/lto.c:1900 0x5fa6a0 lto_file_finalize ../../gcc-trunk/gcc/lto/lto.c:2229 0x5fa6a0 lto_create_files_from_ids ../../gcc-trunk/gcc/lto/lto.c:2239 0x5fa6a0 lto_file_read ../../gcc-trunk/gcc/lto/lto.c:2280 0x5fa6a0 read_cgraph_and_symbols ../../gcc-trunk/gcc/lto/lto.c:2981 0x5fa6a0 lto_main() ../../gcc-trunk/gcc/lto/lto.c:3436 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. lto-wrapper: fatal error: /home/howarth/build/gcc/xgcc returned 1 exit status compilation terminated. /home/howarth/dist_binutils/bin/ld: lto-wrapper failed collect2: error: ld returned 1 exit status
[Bug c++/64603] [5 Regression] bogus error no matching function for call to ... with templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64603 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r217664.
