[Bug libstdc++/65246] [5 Regression] libstdc++ pretty printers don't work anymore with Python3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65246 Matthias Klose doko at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Matthias Klose doko at gcc dot gnu.org --- fixed
[Bug libstdc++/65246] [5 Regression] libstdc++ pretty printers don't work anymore with Python3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65246 Matthias Klose doko at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0
[Bug target/65250] New: [SH] Improve comparisons followed by a negated cstore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65250
Bug ID: 65250
Summary: [SH] Improve comparisons followed by a negated cstore
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target: sh*-*-*
The following example
bool test (int value)
{
switch(value)
{
case 0:
case 1:
case 2:
return true;
default:
return false;
}
}
with -O2 -m4 compiles to:
mov #2,r1
cmp/hi r1,r4
mov #-1,r0
rts
negcr0,r0
On SH4 there is no movrt, so it's better to do that as:
mov #2,r1
cmp/hs r4,r2
rts
movtr0
..which is just inverting the comparison.
Combine tries the following pattern:
Failed to match this instruction:
(parallel [
(set (reg:SI 168)
(leu:SI (reg:SI 4 r4 [ value ])
(const_int 2 [0x2])))
(set (reg:SI 147 t)
(const_int 1 [0x1]))
(use (reg:SI 169))
])
..which is a combination of the inverted comparison and the expanded movrt (via
negc), which always sets T = 1.
A treg_set_expr pattern like the following could be added:
(define_insn_and_split *
[(set (match_operand:SI 0 arith_reg_dest)
(match_operand 1 treg_set_expr_not_const01))
(set (reg:SI T_REG) (const_int 1))
(use (match_operand:SI 2 arith_reg_operand))]
...)
which would then split out the comparison insn and a trailing sett. If the
sett is a dead store it will (should) get eliminated afterwards.
However, before that, the initial comparison and cstore expansion should be
investigated.
[Bug libstdc++/65246] [5 Regression] libstdc++ pretty printers don't work anymore with Python3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65246 --- Comment #1 from Matthias Klose doko at gcc dot gnu.org --- Author: doko Date: Sat Feb 28 09:22:43 2015 New Revision: 221076 URL: https://gcc.gnu.org/viewcvs?rev=221076root=gccview=rev Log: 2015-02-28 Matthias Klose d...@ubuntu.com PR libstdc++/65246 * python/libstdcxx/v6/__init__.py: Use explicit relative imports. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/python/libstdcxx/v6/__init__.py
[Bug target/65251] New: sh4: internal compiler error: Bus error when compiling cpp-netlib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65251 Bug ID: 65251 Summary: sh4: internal compiler error: Bus error when compiling cpp-netlib Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: glaubitz at physik dot fu-berlin.de Target: sh*-*-* Created attachment 34899 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34899action=edit Preprocessed source file for cpp-netlib 0.11.1 (gzipped) Hello! Just ran into another apparent gcc-4.9 regression on the Debian sh4 buildds, this time when trying to build cpp-netlib: [ 9%] Building CXX object libs/network/src/CMakeFiles/cppnetlib-uri.dir/uri/uri.cpp.o cd /«BUILDDIR»/cpp-netlib-0.11.1+dfsg1/obj-sh4-linux-gnu/libs/network/src /usr/bin/c++ -DBOOST_NETWORK_ENABLE_HTTPS -DBOOST_TEST_DYN_LINK -Dcppnetlib_uri_EXPORTS -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wall -fPIC -I/«BUILDDIR»/cpp-netlib-0.11.1+dfsg1-o CMakeFiles/cppnetlib-uri.dir/uri/uri.cpp.o -c /«BUILDDIR»/cpp-netlib-0.11.1+dfsg1/libs/network/src/uri/uri.cpp In file included from /usr/include/boost/spirit/home/qi/nonterminal.hpp:14:0, from /usr/include/boost/spirit/home/qi.hpp:20, from /«BUILDDIR»/cpp-netlib-0.11.1+dfsg1/boost/network/uri/uri.ipp:9, from /«BUILDDIR»/cpp-netlib-0.11.1+dfsg1/libs/network/src/uri/uri.cpp:6: /usr/include/boost/spirit/home/qi/nonterminal/rule.hpp: In function 'static void boost::spirit::qi::ruleIterator, T1, T2, T3, T4::define(boost::spirit::qi::ruleIterator, T1, T2, T3, T4, const Expr, mpl_::true_) [with Auto = mpl_::bool_true; Expr = boost::proto::exprns_::exprboost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2const boost::proto::exprns_::exprboost::proto::tagns_::tag::terminal, boost::proto::argsns_::termboost::spirit::tag::raw, 0l, const boost::proto::exprns_::exprboost::proto::tagns_::tag::bitwise_or, boost::proto::argsns_::list2const boost::proto::exprns_::exprboost::proto::tagns_::tag::bitwise_or, boost::proto::argsns_::list2const boost::proto::exprns_::exprboost::proto::tagns_::tag::bitwise_or, boost::proto::argsns_::list2const boost::proto::exprns_::exprboost::proto::tagns_::tag::bitwise_or, boost::proto::argsns_::list2const boost::proto::exprns_::exprboost::proto::tagns_::tag::bitwise_or, boost::proto::argsns_::list2const boost::proto::exprns_::exprboost::proto::tagns_::tag::bitwise_or, boost::proto::argsns_::list2const boost::proto::exprns_::exprboost::proto::tagns_::tag::bitwise_or, boost::proto::argsns_::list2const boost::proto::exprns_::exprboost::proto::tagns_::tag::bitwise_or, boost::proto::argsns_::list2const boost::proto::exprns_::exprboost::proto::tagns_::tag::bitwise_or, boost::proto::argsns_::list2const boost::proto::exprns_::exprboost::proto::tagns_::tag::bitwise_or, boost::proto::argsns_::list2const boost::proto::exprns_::exprboost::proto::tagns_::tag::bitwise_or, boost::proto::argsns_::list2const boost::proto::exprns_::exprboost::proto::tagns_::tag::bitwise_or, boost::proto::argsns_::list2const boost::proto::exprns_::exprboost::proto::tagns_::tag::bitwise_or, boost::proto::argsns_::list2const boost::proto::exprns_::exprboost::proto::tagns_::tag::bitwise_or, boost::proto::argsns_::list2const boost::proto::exprns_::exprboost::proto::tagns_::tag::bitwise_or, boost::proto::argsns_::list2const boost::proto::exprns_::exprboost::proto::tagns_::tag::bitwise_or, boost::proto::argsns_::list2const boost::proto::exprns_::exprboost::proto::tagns_::tag::bitwise_or, boost::proto::argsns_::list2const boost::proto::exprns_::exprboost::proto::tagns_::tag::bitwise_or, boost::proto::argsns_::list2const boost::proto::exprns_::exprboost::proto::tagns_::tag::bitwise_or, boost::proto::argsns_::list2const boost::proto::exprns_::exprboost::proto::tagns_::tag::bitwise_or, boost::proto::argsns_::list2const boost::proto::exprns_::exprboost::proto::tagns_::tag::bitwise_or, boost::proto::argsns_::list2const boost::proto::exprns_::exprboost::proto::tagns_::tag::bitwise_or, boost::proto::argsns_::list2const boost::proto::exprns_::exprboost::proto::tagns_::tag::bitwise_or, boost::proto::argsns_::list2const boost::proto::exprns_::exprboost::proto::tagns_::tag::bitwise_or, boost::proto::argsns_::list2const boost::proto::exprns_::exprboost::proto::tagns_::tag::bitwise_or, boost::proto::argsns_::list2const boost::proto::exprns_::exprboost::proto::tagns_::tag::bitwise_or, boost::proto::argsns_::list2const boost::proto::exprns_::exprboost::proto::tagns_::tag::bitwise_or, boost::proto::argsns_::list2const boost::proto::exprns_::exprboost::proto::tagns_::tag::bitwise_or, boost::proto::argsns_::list2const boost::proto::exprns_::exprboost::proto::tagns_::tag::bitwise_or, boost::proto::argsns_::list2const
[Bug target/64760] [SH] Avoid multiple #imm,r0 insns with the same #imm value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64760 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-28 Ever confirmed|0 |1 --- Comment #1 from Oleg Endo olegendo at gcc dot gnu.org --- Another scenario where #imm,r0 insns could/should be avoided is code such as: ... mov.b r0,@(1,r2) mov.b r0,@(2,r2) mov.b r0,@(3,r2) mov r1,r0 tst #1,r0 bt/s... mov.b r0,@(0,r2) Because before the #imm,r0 insn the r0 reg is used the code is forced to be sequential. In the example however, the stores and the test can be parallelized which would save 1 cycle: ... mov.b r0,@(1,r2) mov #1,r3 mov.b r0,@(2,r2) tst r3,r1 mov.b r0,@(3,r2) bt/s... mov.b r0,@(0,r2)
[Bug lto/65252] New: Link time optimization breaks use of filenames in linker scripts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65252
Bug ID: 65252
Summary: Link time optimization breaks use of filenames in
linker scripts
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: goswin-v-b at web dot de
CC: goswin-v-b at web dot de
Host: x86_64-linux-gnu
Target: x86_64-linux-gnu
Build: arm-none-eabi
I'm building a kernel for a Rapsberry Pi 2 with -flto. Most of the code will be
linked to 0x8000. The kernel image will be loaded to 0x8000 and I have set
up LMA and VMA in my linker script accordingly. But I have some bootstrap code
(boot.S and early.cc) that needs to at the physical address. So I put the
following in my linker script:
ENTRY(_start)
PHYS_TO_VIRT = 0x8000;
SECTIONS
{
. = 0x8000;
.early : {
boot.o(.*)
early.o(.*)
}
/* rest of the code runs in higher half virtual address */
. = . + PHYS_TO_VIRT;
.text : AT(ADDR(.text) - PHYS_TO_VIRT) {
...
Using objdump -d I see the boot.o contents show up at 0x8000 exactly as it
should. But all the code from early.o only appears later in the .text section
and at the virtual adress. If I drop the -flto then everything works as
expected. It would be nice if -flto could preserve which file each function and
variable comes from so the linker can place them properly.
[Bug bootstrap/65232] [5 Regression] bootstrap failure (ICE in change_symbol_block, at varasm.c:1230) on arm-linux-gnueabihf, in libstdc++ stage1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65232 --- Comment #2 from Matthias Klose doko at gcc dot gnu.org --- Created attachment 34900 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34900action=edit preprocessed source preprocessed source, produced with r221076
[Bug c++/62182] New warning wished: operator== and equality comparison result unused [-Wunused-comparison]/-Wunsed-value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62182 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-28 CC||manu at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org --- I'm going to confirm this because we obviously want it.
[Bug bootstrap/65232] [5 Regression] bootstrap failure (ICE in change_symbol_block, at varasm.c:1230) on arm-linux-gnueabihf, in libstdc++ stage1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65232 --- Comment #3 from Matthias Klose doko at gcc dot gnu.org --- reverting r221040 lets the bootstrap succeed.
[Bug target/65251] sh4: internal compiler error: Bus error when compiling cpp-netlib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65251 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added CC||kkojima at gcc dot gnu.org, ||olegendo at gcc dot gnu.org --- Comment #1 from Oleg Endo olegendo at gcc dot gnu.org --- attachment 34899 doesn't compile on sh-elf out of the box. I had to remove all lines starting with #: sed '/^#/ d' ccw3pP9A.out ccw3pP9A_1.out Other than that, I wasn't able to reproduce the error with an sh-elf xgcc running on i686. The Bus error could be some buggy misaligned mem access, which is in the native sh4 gcc. This means that probably the compiler that was used to compile the current native sh4 gcc produced buggy code.
[Bug target/65249] unable to find a register to spill in class 'R0_REGS' when compiling protobuf on sh4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65249 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-28 CC||kkojima at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Oleg Endo olegendo at gcc dot gnu.org --- Compiling attachment 34901 on sh-elf with '-m4 -ml -O2 -fPIC -fstack-protector-strong': 4.9: NG 5: NG 5 -mlra: OK On 4.8 there is no option -fstack-protector-strong. Omitting this option seems to be a possible workaround.
[Bug lto/65252] Link time optimization breaks use of filenames in linker scripts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65252 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- You could use -fno-lto when compiling early.cc.
[Bug c/65253] New: Wmemsize-comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65253 Bug ID: 65253 Summary: Wmemsize-comparison Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: manu at gcc dot gnu.org Clang does: remote.c:5519:47: warning: size argument in 'strncmp' call is a comparison [-Wmemsize-comparison] strncmp (p, core, strlen (core) != 0)) ^~~~ remote.c:5519:11: note: did you mean to compare the result of 'strncmp' instead? strncmp (p, core, strlen (core) != 0)) ^ ~ ) remote.c:5519:31: note: explicitly cast the argument to size_t to silence this warning strncmp (p, core, strlen (core) != 0)) ^ (size_t)( ) and it founds bugs in gdb: https://sourceware.org/ml/gdb/2015-02/msg00088.html
[Bug target/65249] unable to find a register to spill in class 'R0_REGS' when compiling protobuf on sh4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65249 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added CC||olegendo at gcc dot gnu.org --- Comment #2 from Oleg Endo olegendo at gcc dot gnu.org --- Created attachment 34901 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34901action=edit Reduced test case
[Bug target/65249] unable to find a register to spill in class 'R0_REGS' when compiling protobuf on sh4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65249
--- Comment #4 from Oleg Endo olegendo at gcc dot gnu.org ---
For some reason r0 is live throughout the whole basic block where the problem
occures. The basic block starts with:
(note 36 35 38 5 [bb 5] NOTE_INSN_BASIC_BLOCK)
(note 38 36 39 5 NOTE_INSN_DELETED)
(note 39 38 70 5 NOTE_INSN_DELETED)
(insn 70 39 133 5 (set (reg:SI 0 r0)
(const_int 0 [0])) ccdkVmsq_1.out:48 252 {movsi_ie}
(nil))
When using LRA, r0 is spilled to stack, and PIC_REG (r12) is copied to r0 for
the mem load. r0 is then reloaded from stack, but rematerialized and converted
into a load of constant.
mov r12,r2
add r11,r2
mov #0,r0
mov.l .L25,r1
mov.l @r2,r2
mov.l r0,@r15
mov r12,r0
mov.l @(60,r10),r3
mov.l @r2,r7
cmp/eq r3,r7
mov #0,r3
mov #0,r7
mov.l @(r0,r1),r1
bf/s.L16
mov #0,r0
add #12,r15
...
If I'm not mistaken, the above can be done better as:
mov r11,r0
mov.l @(r0,r12),r2
mov.l .L25,r0
mov.l @(60,r10),r3
mov.l @r2,r7
cmp/eq r3,r7
mov #0,r3
mov #0,r7
mov.l @(r0,r12),r1
bf/s.L16
mov #0,r0
add #12,r15
...
[Bug ipa/65237] [5 Regression] r221040 caused many regressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65237 --- Comment #15 from Jan Hubicka hubicka at gcc dot gnu.org --- Author: hubicka Date: Sat Feb 28 22:53:37 2015 New Revision: 221079 URL: https://gcc.gnu.org/viewcvs?rev=221079root=gccview=rev Log: PR ipa/65237 * ipa-icf.c (sem_function::merge): Do not attempt to produce alias across COMDAT group boundary. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-icf.c
[Bug bootstrap/65232] [5 Regression] bootstrap failure (ICE in change_symbol_block, at varasm.c:1230) on arm-linux-gnueabihf, in libstdc++ stage1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65232 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Jan Hubicka hubicka at gcc dot gnu.org --- Fixed.
[Bug ipa/65236] [5 Regression]: IPA ICF causes miscompilation in Chromium built with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65236 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Jan Hubicka hubicka at gcc dot gnu.org --- Fixed.
[Bug target/65249] unable to find a register to spill in class 'R0_REGS' when compiling protobuf on sh4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65249
--- Comment #7 from Oleg Endo olegendo at gcc dot gnu.org ---
Created attachment 34902
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34902action=edit
Various R0 pre-alloc splits
I've tried compiling CSiBE with the two split patterns in comment #5 ...
It's a can of worms. I'm dumping my current state as a patch here, maybe it's
helpful in some way. I ended up adding one r0 split pattern after another, but
probably some are still missing.
bzip2 (haven't tried anything else so far) fails with:
internal compiler error: in spill_failure, at reload1.c:2143
error: this is the insn:
(insn 8965 8964 8966 70 (set (mem:SI (plus:SI (reg:SI 0 r0)
(reg:SI 945 [ D.5064 ])) [1 MEM[base: _692, index: _1412,
offset: 0B]+0 S4 A32])
(reg:SI 7 r7 [orig:592 D.5066 ] [592])) bzip2-1.0.2/blocksort.c:564 252
{movsi_ie}
(expr_list:REG_DEAD (reg:SI 7 r7 [orig:592 D.5066 ] [592])
(expr_list:REG_DEAD (reg:SI 0 r0)
(nil
Probably reload can't resolve adjacent insns which have r0 constraints. I
haven't checked the details though.
Regardless of that, I think the cmpeqsi_t hunk in sh.md and the
sh_disp_addr_displacement huink in predicates.md should be applied on trunk.
[Bug other/65254] New: libiberty produces using extended field designator is an extension warnings in clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65254 Bug ID: 65254 Summary: libiberty produces using extended field designator is an extension warnings in clang Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: howarth at bromo dot med.uc.edu The simple-object-xcoff.c file in libiberty produces a number of warnings of the form... ./../../gcc-5-20150228/libiberty/simple-object-xcoff.c:330:12: warning: using extended field designator is an extension [-Wextended-offsetof] + offsetof (struct external_filehdr, ^ /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.0/include/stddef.h:87:24: note: expanded from macro 'offsetof' #define offsetof(t, d) __builtin_offsetof(t, d) ^ under the clang compiler as offsetof(T, field,subfield) and offsetof(T, arr[3]) are C/C++ extensions and only offsetof(T, field) is standard. Shouldn't these be recoded to use the standard form?
[Bug ipa/65236] [5 Regression]: IPA ICF causes miscompilation in Chromium built with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65236 --- Comment #6 from Jan Hubicka hubicka at gcc dot gnu.org --- Author: hubicka Date: Sat Feb 28 20:32:15 2015 New Revision: 221077 URL: https://gcc.gnu.org/viewcvs?rev=221077root=gccview=rev Log: PR ipa/65236 * g++.dg/ipa/ipa-icf-6.C: New testcase. * cgraphunit.c (cgraph_node::expand_thunk): Enable return slot opt. Added: trunk/gcc/testsuite/g++.dg/ipa/ipa-icf-6.C Modified: trunk/gcc/ChangeLog trunk/gcc/cgraphunit.c trunk/gcc/testsuite/ChangeLog
[Bug c++/65255] std::thread does not work for cross compiling on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65255 --- Comment #2 from Yichao Yu yyc1992 at gmail dot com --- ARM environment is ArchLinuxARM (armv7h)[1] on a Xilinx Zynq 0702 Eval board which has a dual-core Cortex-a9 processor. [1] http://archlinuxarm.org/packages
[Bug c++/65255] std::thread does not work for cross compiling on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65255 --- Comment #3 from Yichao Yu yyc1992 at gmail dot com --- I didn't keep the config.log file used to compile the gcc I used to compile the binary attached but here's the config.log of a slightly later snapshot (20150204, which is the same used for the arm native compiler) which reproduce the same issue at runtime.
[Bug bootstrap/65232] [5 Regression] bootstrap failure (ICE in change_symbol_block, at varasm.c:1230) on arm-linux-gnueabihf, in libstdc++ stage1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65232 --- Comment #7 from Jan Hubicka hubicka at gcc dot gnu.org --- Aha, the DECL is first seen by notice_global_symbol and then turned to alias. I guess we just need to clear DECL_RTL on the path producing aliases.
[Bug c++/65255] std::thread does not work for cross compiling on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65255 --- Comment #1 from Yichao Yu yyc1992 at gmail dot com --- Created attachment 34904 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34904action=edit Source and output programs
[Bug c++/65255] std::thread does not work for cross compiling on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65255 --- Comment #4 from Yichao Yu yyc1992 at gmail dot com --- Created attachment 34905 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34905action=edit config.log of a more recent snapshot
[Bug bootstrap/65232] [5 Regression] bootstrap failure (ICE in change_symbol_block, at varasm.c:1230) on arm-linux-gnueabihf, in libstdc++ stage1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65232 --- Comment #8 from Jan Hubicka hubicka at gcc dot gnu.org --- Author: hubicka Date: Sat Feb 28 22:46:22 2015 New Revision: 221078 URL: https://gcc.gnu.org/viewcvs?rev=221078root=gccview=rev Log: PR ipa/65232 * ipa-icf.c (clear_decl_rtl): New function. (sem_function::merge): Clear RTL before forming alias. (sem_variable::merge): Clear RTL before forming alias. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-icf.c
[Bug target/65251] sh4: internal compiler error: Bus error when compiling cpp-netlib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65251 --- Comment #2 from Kazumoto Kojima kkojima at gcc dot gnu.org --- FYI, I can't reproduce the problem on i686-gcc cross sh4-unknown-linux-gnu 4.9/5 compilers, though the preprocessed source can be compiled as is.
[Bug c++/65255] New: std::thread does not work for cross compiling on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65255
Bug ID: 65255
Summary: std::thread does not work for cross compiling on ARM
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: yyc1992 at gmail dot com
Created attachment 34903
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34903action=edit
PKGBUILD used to compile the cross compiling version of gcc
Duplicate of the problem reported in the comment of #42734. However, IMHO, that
bug was tracking a different issue and it should be better to open a new bug
for this one although the error message produced at runtime are very similar.
See attached file for the script used to compile the cross-compiler
(CHOST=x86_64-unknown-linux-gnu).
Minimum source that produces the problem
```
#include thread
int
main()
{
std::thread([] {}).join();
return 0;
}
```
When compiling with `arm-linux-gnueabihf-g++` on x86_64 and run on arm, it
throws an runtime error
```
pure virtual method called
terminate called without an active exception
Aborted (core dumped)
```
However, the error disappeared if run with gdb
The same source works on the host machine (x86_64), with clang cross compiling
on ARM and with both clang and gcc natively compiled on ARM. Adding `-latomic`
as suggested in #42734 does not help either and is also not needed using the
native compiler on arm.
Command line option used to compile:
gcc cross compile:
arm-linux-gnueabihf-g++ -pthread -std=c++14 -Os -Wall -Wextra thread.cpp -o
thread-arm
clang cross compile:
clang++ --target=arm-linux-gnueabihf -pthread -std=c++14 -Os -Wall -Wextra
thread.cpp -o thread-arm_clang -I
/usr/arm-linux-gnueabihf/include/c++/4.9.2/arm-linux-gnueabihf
gcc native compile (on ARM):
g++ -pthread -std=c++14 -Os -Wall -Wextra thread.cpp -o thread-arm_native
clang native compile (on ARM):
clang++ -pthread -std=c++14 -Os -Wall -Wextra thread.cpp -o
thread-arm_native_clang
I'll try to upload the binaries (if they are allowed) or the output of `objdump
-S` (if I cannot upload binaries).
[Bug middle-end/65256] New: [5 regression] Undefined symbols linking f951
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65256 Bug ID: 65256 Summary: [5 regression] Undefined symbols linking f951 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Host: hppa2.0w-hp-hpux11.11 Target: hppa2.0w-hp-hpux11.11 Build: hppa2.0w-hp-hpux11.11 In stage2: /test/gnu/gcc/objdir/./prev-gcc/xg++ -B/test/gnu/gcc/objdir/./prev-gcc/ -B/opt/gnu/gcc/gcc-5.0/hppa2.0w-hp-hpux11.11/bin/ -nostdinc++ -B/test/gnu/gcc/objdir/pre v-hppa2.0w-hp-hpux11.11/libstdc++-v3/src/.libs -B/test/gnu/gcc/objdir/prev-hppa2.0w-hp-hpux11.11/libstdc++-v3/libsupc++/.libs -I/test/gnu/gcc/objdir/prev-hppa2 .0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux11.11 -I/test/gnu/gcc/objdir/prev-hppa2.0w-hp-hpux11.11/libstdc++-v3/include -I/test/gnu/gcc/gcc/libstdc ++-v3/libsupc++ -L/test/gnu/gcc/objdir/prev-hppa2.0w-hp-hpux11.11/libstdc++-v3/src/.libs -L/test/gnu/gcc/objdir/prev-hppa2.0w-hp-hpux11.11/libstdc++-v3/libsupc+ +/.libs -g -O2 -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribu te -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overl ength-strings -Werror -fno-common -DHAVE_CONFIG_H -static-libstdc++ -static-lib gcc -o f951 \ fortran/arith.o fortran/array.o fortran/bbt.o fortran/check.o fo rtran/class.o fortran/constructor.o fortran/cpp.o fortran/data.o fortran/decl.o fortran/dump-parse-tree.o fortran/error.o fortran/expr.o fortran/interface.o for tran/intrinsic.o fortran/io.o fortran/iresolve.o fortran/match.o fortran/matchex p.o fortran/misc.o fortran/module.o fortran/openmp.o fortran/options.o fortran/p arse.o fortran/primary.o fortran/resolve.o fortran/scanner.o fortran/simplify.o fortran/st.o fortran/symbol.o fortran/target-memory.o fortran/convert.o fortran /dependency.o fortran/f95-lang.o fortran/trans.o fortran/trans-array.o fortran/t rans-common.o fortran/trans-const.o fortran/trans-decl.o fortran/trans-expr.o fortran/trans-intrinsic.o fortran/trans-io.o fortran/trans-openmp.o fortran/trans-stmt.o fortran/trans-types.o fortran/frontend-passes.o libbackend.a main.o tree-browser.o libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a -L../zlib -lz libcommon.a ../libcpp/libcpp.a ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a attribs.o \ -L/opt/gnu/gcc/gmp/lib -lmpc -lmpfr -lgmp -L../zlib -lz /usr/ccs/bin/ld: Unsatisfied symbols: (anonymous namespace)::pass_dce::gate(function*) (first referenced in libbackend.a(tree-ssa-dce.o)) (data) (anonymous namespace)::pass_diagnose_tm_blocks::gate(function*) (first referenced in libbackend.a(trans-mem.o)) (data) (anonymous namespace)::pass_refactor_eh::gate(function*) (first referenced in libbackend.a(tree-eh.o)) (data) (anonymous namespace)::pass_build_alias::gate(function*) (first referenced in libbackend.a(tree-ssa-structalias.o)) (data) (anonymous namespace)::pass_ira::gate(function*) (first referenced in libbackend.a(ira.o)) (data) (anonymous namespace)::pass_lower_tm::gate(function*) (first referenced in libbackend.a(trans-mem.o)) (data) (anonymous namespace)::pass_lower_subreg::gate(function*) (first referenced in libbackend.a(lower-subreg.o)) (data) (anonymous namespace)::pass_optimize_bswap::gate(function*) (first referenced in libbackend.a(tree-ssa-math-opts.o)) (data) (anonymous namespace)::pass_rtl_fwprop::gate(function*) (first referenced in libbackend.a(fwprop.o)) (data) (anonymous namespace)::pass_dominator::gate(function*) (first referenced in libbackend.a(tree-ssa-dom.o)) (data) /usr/ccs/bin/ld: Invalid symbol type for plabel (libbackend.a(trans-mem.o), (anonymous namespace)::pass_diagnose_tm_blocks::gate(function*)). collect2: error: ld returned 1 exit status make[3]: *** [f951] Error 1 make[3]: *** Waiting for unfinished jobs rm gfortran.pod gcov.pod cpp.pod gfdl.pod gcov-tool.pod fsf-funding.pod gcc.pod make[3]: Leaving directory `/test/gnu/gcc/objdir/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/test/gnu/gcc/objdir' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/test/gnu/gcc/objdir' make: *** [bootstrap] Error 2 Wed Feb 25 22:27:01 EST 2015 r220778 was okay.
[Bug bootstrap/65232] [5 Regression] bootstrap failure (ICE in change_symbol_block, at varasm.c:1230) on arm-linux-gnueabihf, in libstdc++ stage1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65232 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-28 Ever confirmed|0 |1 --- Comment #4 from Aldy Hernandez aldyh at gcc dot gnu.org --- Confirmed with an x86-64 cross to arm-linux-gnueabihf with: configure --enable-languages=c++ --disable-bootstrap --target=arm-linux-gnueabihf and then: ./cc1plus -quiet strstream.ii -O2 -I./ -fPIC -fdata-sections
[Bug middle-end/65224] fprofile-reorder-functions reorders using expand order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65224 --- Comment #2 from Jan Hubicka hubicka at gcc dot gnu.org --- Yep, I am aware of this problem. Good we have tracking bug for this. LRA is not the first pass down top-down propagation and I originally set up the topological order precisely to make these kind of tricks possible (we propagate stack alignments and also thinks like late pure-const, nothrow and similar discoveries). There are several two downsides of this decision: 1) The order also plays badly with unreachable code removal, because when all uses of functions get optimized out late (that is quite frequent given that it is first time we see code after IPA passes) we will not take the function away. 2) The order is very bad for code layout, because it is backward (i.e. the code basically executes from the end. With IPA and rather large partitions this matters. I think we need both - the support for fragments and support for sections to get output right. The downside of sections is extra padding added between functions that is undesirable unless we really want to get interprocedural order right. (I have a patch for non-FDO based reordering. I would like to get that one in next release, so it will become even more important to get this right). I have prototype ipa-reorder pass solving 2) that produce sane function order w/o need to have a profile. Of course it completely kills the top-down propagation that is why I did not get around producing mainline version of it. I also think we simply want to cut the late optimization queue once again: execute all gimple optimization passes, re-do unreachable function removal and only then proceed with expansion.
[Bug target/65249] unable to find a register to spill in class 'R0_REGS' when compiling protobuf on sh4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65249
--- Comment #5 from Oleg Endo olegendo at gcc dot gnu.org ---
On trunk, I've tried adding this:
(define_split
[(set (match_operand:SI 0 arith_reg_dest)
(mem:SI (plus:SI (match_operand:SI 1 arith_reg_operand)
(match_operand:SI 2 arith_reg_operand]
TARGET_SH1 can_create_pseudo_p ()
[(const_int 0)]
{
rtx tmp = gen_reg_rtx (SImode);
rtx r0 = gen_rtx_REG (SImode, R0_REG);
emit_move_insn (tmp, r0);
emit_move_insn (r0, operands[1]);
rtx mem = replace_equiv_address (XEXP (PATTERN (curr_insn), 1),
gen_rtx_PLUS (SImode, r0, operands[2]),
false);
emit_move_insn (operands[0], mem);
emit_move_insn (r0, tmp);
})
to workaround the r0 spill failure for the (r0+rm) mem load.
Then another spill failure with the 'cmp/eq #imm,r0' insn popped up. So I've
added this:
(define_split
[(set (reg:SI T_REG)
(eq:SI (match_operand:SI 1 arith_reg_operand)
(match_operand:SI 2 const_int_operand)))]
TARGET_SH1 can_create_pseudo_p ()
satisfies_constraint_I08 (operands[2])
[(const_int 0)]
{
rtx tmp = gen_reg_rtx (SImode);
rtx r0 = gen_rtx_REG (SImode, R0_REG);
emit_move_insn (tmp, r0);
emit_move_insn (r0, operands[1]);
emit_insn (gen_cmpeqsi_t (r0, operands[2]));
emit_move_insn (r0, tmp);
})
With those two split patterns added attachment 34901 compiles.
This is basically the same trick as done in prepare_move_operands for QIHImode
loads with displacement. Effectively it pre-allocates the r0 uses and shortens
the r0 live ranges.
When compiling with LRA the resulting code seems a bit better (comment #4),
too. I haven't checked the impact on average code (CSiBE) though.
While we probably could add those two patterns as a quick fix, I don't think
it's a great solution, because we'd actually need to add such patterns for
*all* insns that have the 'z'/r0 constraint. In this case it might be better
to add an SH specific RTL pass before IRA which can do such kind of RA
preparations to improve the RA result/process.
[Bug bootstrap/65232] [5 Regression] bootstrap failure (ICE in change_symbol_block, at varasm.c:1230) on arm-linux-gnueabihf, in libstdc++ stage1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65232 --- Comment #6 from Jan Hubicka hubicka at gcc dot gnu.org --- Hmm, it seems we triggered another bug of aliases WRT anchors. How does the declarations in question look like? (basically all aliases introduced by ipa-icf can also be coded by hand). Is it the path /* For a duplicate declaration, we can be called twice on the same DECL node. Don't discard the RTL already made. */ if (DECL_RTL_SET_P (decl)) ...? Why the declaration is considered duplicate to start with?
[Bug ipa/65237] [5 Regression] r221040 caused many regressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65237 --- Comment #13 from Jan Hubicka hubicka at gcc dot gnu.org --- The alias is really in a wrong comdat group. C++ FE should produce lthunk correctly. It may be related to PR64988 I suppose the code I added to resolve_alias to redirect aliases of aliases to their target triggered more of sanity check here. I am looking into the ARM alias issue and will try to look into this later today.
[Bug go/63731] Fallback to netgo does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731 --- Comment #26 from Ian Lance Taylor ian at airs dot com --- Tatsushi: are you asking about gccgo, or about gc?
[Bug bootstrap/65232] [5 Regression] bootstrap failure (ICE in change_symbol_block, at varasm.c:1230) on arm-linux-gnueabihf, in libstdc++ stage1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65232
--- Comment #5 from Aldy Hernandez aldyh at gcc dot gnu.org ---
For the following symbol:
(symbol_ref:SI (_ZTCSt9strstream8_So) [flags 0x82] var_decl 0x7fffeecd4090
_ZTCSt9strstream8_So)
We fail this assertion:
change_symbol_block (rtx symbol, struct object_block *block)
{
if (block != SYMBOL_REF_BLOCK (symbol))
{
gcc_assert (SYMBOL_REF_BLOCK_OFFSET (symbol) 0);
SYMBOL_REF_BLOCK (symbol) = block;
}
}
The symbol's block offset has been previously set (to 0) in place_block_symbol
here:
if (snode-alias)
{
rtx target = DECL_RTL (snode-ultimate_alias_target ()-decl);
gcc_assert (MEM_P (target)
GET_CODE (XEXP (target, 0)) == SYMBOL_REF
SYMBOL_REF_HAS_BLOCK_INFO_P (XEXP (target, 0)));
target = XEXP (target, 0);
place_block_symbol (target);
SYMBOL_REF_BLOCK_OFFSET (symbol) = SYMBOL_REF_BLOCK_OFFSET (target);
return;
}
Interestingly, without the patch in r221040, snode-alias is not set, so a
different path is used to set the offset.
Be that as it may, the killer is that change_symbol_block() is being called on
mainline through do_assemble_alias - make_decl_rtl, because the symbol is
considered an alias which it wasn't in r221040.
Honza?
[Bug target/65249] unable to find a register to spill in class 'R0_REGS' when compiling protobuf on sh4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65249 --- Comment #6 from Oleg Endo olegendo at gcc dot gnu.org --- (In reply to Oleg Endo from comment #5) While we probably could add those two patterns as a quick fix, I don't think it's a great solution, because we'd actually need to add such patterns for *all* insns that have the 'z'/r0 constraint. In this case it might be better to add an SH specific RTL pass before IRA which can do such kind of RA preparations to improve the RA result/process. Actually, that pass might also cover the issue in PR 64785.
[Bug ipa/65237] [5 Regression] r221040 caused many regressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65237 --- Comment #14 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Pat Haugen from comment #12) Commentary got lost for prior attachment... 483.xalancbmk from cpu2006 started to fail building on powerpc64[le] with the subject revision. I got the same error on Linux/x86-64.
[Bug target/65248] [5 Regression] Copy relocation in PIE against protected symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65248 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-28 Target Milestone|--- |5.0 Ever confirmed|0 |1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com --- A patch is posted at https://gcc.gnu.org/ml/gcc-patches/2015-02/msg01746.html
[Bug c++/65257] New: cin not working with empty string when _GLIBCXX_DEBUG is defined on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65257
Bug ID: 65257
Summary: cin not working with empty string when _GLIBCXX_DEBUG
is defined on Windows
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: melnakeeb at hotmail dot com
Using latest Cygwin32 ,Cygwin64 and MinGW32 with GCC 4.9.2 , 4.9.2 and 4.8.1
respectively on Windows 7 64-bit. I am testing also on 32-bit Linux using GCC
4.8.2.
So on all systems this works
#include bits/stdc++.h
using namespace std;
string s,t;
int main(){
cinst;
couts;
}
and this works
#define _GLIBCXX_DEBUG
#include bits/stdc++.h
using namespace std;
string s=a,t=b;
int main(){
cinst;
couts;
}
but the next one crashes on Windows after inputting the first string on the 3
configurations mentioned above, but works correctly on Linux:
#define _GLIBCXX_DEBUG
#include bits/stdc++.h
using namespace std;
string s,t;
int main(){
cinst;
couts;
}
Clearly the only difference is that the string is empty before inputting, and
_GLIBCXX_DEBUG is enabled.
Previous discussions:
http://stackoverflow.com/questions/28708802/cin-not-working-with-empty-string-when-glibcxx-debug-on-windows
, http://sourceforge.net/p/mingw/bugs/1666/
and http://codeforces.com/blog/entry/15547#comment-215143
[Bug fortran/64506] FORMAT Parse Error with Continuation Line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64506 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- No further issues identified. Closing.
[Bug fortran/57822] I/O: (g0) wrongly prints E+0000
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57822 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- No further issues. Closing
[Bug libfortran/65234] Output descriptor (*(1E15.7)) not accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65234 --- Comment #4 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Created attachment 34906 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34906action=edit Patch tested on x86-64 This patch passes regression testing and NIST testing. Fairly simple.
[Bug lto/65252] Link time optimization breaks use of filenames in linker scripts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65252 --- Comment #2 from Goswin von Brederlow goswin-v-b at web dot de --- As long as it's only one C/C++ file that works. But if one has multiple files then -fno-lto would optimize less. I was thinking of a more general case than mine.
