[Bug c++/65646] [5 Regression] ICE in invalid syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65646 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-01 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |5.0 Summary|ICE in invalid syntax |[5 Regression] ICE in ||invalid syntax Ever confirmed|0 |1
[Bug target/42159] unwinding issues on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42159 --- Comment #32 from Pierre Ossman ossman at cendio dot se --- (In reply to Jack Howarth from comment #31) You might check out the original posting on this issue... http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025900.html I believe that was one of the posts we found and what made us look at which unwind implementation was used. IMHO, the static linkage of -lgcc_eh is evil as it potentially breaks the requirement that only a single unwinder (always the system one) be used. I can understand that. But in that case why keep the gcc unwinder on OS X? If it doesn't work then including it is just an accident waiting to happen. I would suggest something along the lines of the attached patch.
[Bug rtl-optimization/64164] [4.9/5/6 Regression] one more stack slot used due to one less inlining level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64164 --- Comment #34 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Jeffrey A. Law from comment #33) On 03/31/2015 05:25 AM, rguenth at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64164 --- Comment #30 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Jeffrey A. Law from comment #28) So I've been thinking about how to integrate life/conflict analysis into the uncprop code and it may not be that bad, both from an implementation and computation standpoint. Most importantly, we don't have to compute full life information. We really just need to compute the life of the equivalence. Given the life of the equivalence, if the equivalence is live in any block that contains the defining statement for an SSA_NAME appearing in the target PHI, then the equivalence conflicts and we don't want to unpropagate it. Computing the life of the equivalence is pretty easy and should be reasonably quick. This is a cost we'd have to pay regardless of whether or not we integrate uncprop with out-of-ssa since we won't have life information for the expression. Collecting the SSA_NAMEs appearing on the RHS of the PHI so that we don't test for conflicts multiple times if an SSA_NAME shows up in multiple PHI alternatives would help keep the cost down as well. Ultimately I don't think we need to integrate uncprop and out-of-ssa to avoid the unprofitable transformation during uncprop. Also see Boissinot et al., Fast Liveness Checking for SSA-Form Programs (CGO 08). They describe a way to do fast liveness queries without actually doing a (memory) expensive data-flow analysis but using SSA immediate-uses and dominance checks. Sth we could use in SSA coalescing as well to avoid both the liveness bitmaps and the conflict graph. Yea, it looks reasonably interesting and there's probably benefit in experimenting with that approach. However, be aware that it's memory consumption can be problematical. According to their summary, it's quadratic. Yes, but that's only if you store the liveness info. We don't need to do that but we only need to compute whether two partitions conflict for each coalescing candidate (which means a few SSA conflict checks dependent on partition size). Our current algorithm is already quadratic in memory use because we do store SSA liveness and the partition conflict graph. What I'm not sure is whether doing the SSA based liveness check is going to be slower compile-time wise. Though presumably we could drop back to the tried and true approach if we have too many BBs. That definitely is stage1 material. Indeed. Jeff
[Bug target/65644] Assembler errors on Solaris 10 x86-64: `(%eXX)' is not a valid 64 bit base/index expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65644 --- Comment #3 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Jakub Jelinek from comment #2) impossible, and the addr32 pieces in e.g. ix86_decompose_address would need to be disabled based on some configure macro. In this case, a better place for the test is just after /* Index and base should have the same mode. */ check in ix86_legitimate_address_p.
[Bug ipa/65076] [5 Regression] 16% tramp3d-v4.cpp compile time regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076 --- Comment #51 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to rguent...@suse.de from comment #48) Maybe we regressed optimizing GCC itself? (does not bootstrapping but compiling gcc 5 with gcc 4.9 improve things?) No, gcc configured with --disable-bootstrap --enable-checking=release and build with gcc-5 vs. gcc-4.9 does not show any difference.
[Bug c++/65646] New: ICE in invalid syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65646 Bug ID: 65646 Summary: ICE in invalid syntax Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: bernd.edlinger at hotmail dot de Hi, on current trunk (snapshot gcc-5-20150329, r221765) the following file causes an ICE: $ cat test.cpp const_iterator #include sstream $ g++ test.cpp lots of warnings/errors, and then: /home/ed/gnu/install/include/c++/5.0.0/istream:451:14: note: previous declaration 'std::basic_istreamchar::__istream_type std::basic_istreamchar::ignore' /home/ed/gnu/install/include/c++/5.0.0/istream: At global scope: /home/ed/gnu/install/include/c++/5.0.0/istream:648:29: error: 'streamsize' has not been declared getline(char_type* __s, streamsize __n, char_type __delim); ^ /home/ed/gnu/install/include/c++/5.0.0/istream:653:12: error: 'std::basic_istreamchar std::basic_istreamchar::ignore' is not a static data member of 'class std::basic_istreamchar' ignore(streamsize __n); ^ /home/ed/gnu/install/include/c++/5.0.0/istream:653:12: error: 'streamsize' was not declared in this scope /home/ed/gnu/install/include/c++/5.0.0/istream:653:26: internal compiler error: Segmentation fault ignore(streamsize __n); ^ 0xce846f crash_signal ../../gcc-5-20150329/gcc/toplev.c:383 0x719f29 tree_check(tree_node*, char const*, int, char const*, tree_code) ../../gcc-5-20150329/gcc/tree.h:2845 0x719f29 determine_visibility(tree_node*) ../../gcc-5-20150329/gcc/cp/decl2.c:2392 0x68172d cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int) ../../gcc-5-20150329/gcc/cp/decl.c:6696 0x761031 cp_parser_init_declarator ../../gcc-5-20150329/gcc/cp/parser.c:17299 0x76175c cp_parser_single_declaration ../../gcc-5-20150329/gcc/cp/parser.c:23811 0x7621dd cp_parser_explicit_specialization ../../gcc-5-20150329/gcc/cp/parser.c:14622 0x76f1bf cp_parser_declaration ../../gcc-5-20150329/gcc/cp/parser.c:11331 0x76d86a cp_parser_declaration_seq_opt ../../gcc-5-20150329/gcc/cp/parser.c:11264 0x76e0e5 cp_parser_namespace_body ../../gcc-5-20150329/gcc/cp/parser.c:16268 0x76e0e5 cp_parser_namespace_definition ../../gcc-5-20150329/gcc/cp/parser.c:16249 0x76f169 cp_parser_declaration ../../gcc-5-20150329/gcc/cp/parser.c:11366 0x76d86a cp_parser_declaration_seq_opt ../../gcc-5-20150329/gcc/cp/parser.c:11264 0x76db7f cp_parser_translation_unit ../../gcc-5-20150329/gcc/cp/parser.c:4100 0x76db7f c_parse_file() ../../gcc-5-20150329/gcc/cp/parser.c:33192 0x8a0502 c_common_parse_file() ../../gcc-5-20150329/gcc/c-family/c-opts.c:1057 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.
[Bug target/42159] unwinding issues on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42159 --- Comment #33 from Pierre Ossman ossman at cendio dot se --- Created attachment 35198 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35198action=edit Remove unwinder on OS X
[Bug target/65644] Assembler errors on Solaris 10 x86-64: `(%eXX)' is not a valid 64 bit base/index expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65644 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||ro at gcc dot gnu.org, ||uros at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- (%edi) etc. in 64-bit mode should be assembled as addr32 (0x67) prefix on the instruction. If Solaris assembler doesn't handle it, guess first somebody needs to investigate if it has a different syntax for the same thing, or just doesn't support it at all, what versions are affected etc. If it doesn't support it at all, it would mean -mx32 support would be impossible, and the addr32 pieces in e.g. ix86_decompose_address would need to be disabled based on some configure macro.
[Bug ipa/65076] [5 Regression] 16% tramp3d-v4.cpp compile time regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076 --- Comment #48 from rguenther at suse dot de rguenther at suse dot de --- On Tue, 31 Mar 2015, trippels at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076 --- Comment #46 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Jan Hubicka from comment #45) Like Richard wrote in comment 38 it is phase opt and generate that regresses Yes, but is it regression because of one specific pass shown later or is it just a cumulative effect of many little slowdown? Nothing pops into the eye, so it must be the cumulative effect. Maybe we regressed optimizing GCC itself? (does not bootstrapping but compiling gcc 5 with gcc 4.9 improve things?) Could also that replacing more libiberty htabs with hash_tables (the GCed ones) and replacing pointer-set/map made things slower.
[Bug ipa/65076] [5 Regression] 16% tramp3d-v4.cpp compile time regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076 --- Comment #49 from Jan Hubicka hubicka at gcc dot gnu.org --- I did some experiments about the increase of early inlining insns: - Early optimizers of both 4.9 and mainline process 9819 functions. - At release_ssa time, the statement count is 8% - at ipa-cp, we have 9% fewer functions at mainline (so inliing helps) - At copyrename2 time, GCC 4.9 has 2% more statements and same number of functions. The difference drops to 1% at .optimized time. I do not think pure statement count explains the problem - early optimization is small part of the queue. Also early-inlining-insns does not have at all that much effect on GCC 4.9 (26.1s - 16.9s or a noise) A difference may be in a fact, that original metric used relative time benefits that computed estimated time saved over estimated time for executing both caller and callee. Now this metric drops to low values when caller is huge. New metric does not have this property and do not consider it a bad idea to inline into huge callers as long as time seems to improve measurably. I suppose it may account in overall slowdown as we get large functions more often. It seems supported by fact that mainline hits large-function-growth limit 285 times (about 9% of all functions output), while 4.9 7 times. I am also seeing some issues with firefox and the new javascript interpreter. It seems that current limit of inline-unit-growth (reduced from 30 to 15%) is too small for new firefox trees and there is very good improvement for increasing it back to 30%. This however of course makes this PR worse. I have patch to re-implement original badness metric in current tree, lets see.
[Bug target/65644] Assembler errors on Solaris 10 x86-64: `(%eXX)' is not a valid 64 bit base/index expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65644 --- Comment #1 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Daniel Richard G. from comment #0) No such error occurs when I compile this source on a Linux system, so this may have to do with the Solaris assembler. This is perfectly valid addr32 prefixed address: (set (mem:SI (zero_extend:DI (reg/v:SI 5 di))) (reg/v:SI 4 si [orig:90 val ] [90])) foo1: 0: 67 89 37addr32 mov %esi,(%edi) 3: c3 retq I don't know why Solaris assembler emits error here. It should be at most a warning.
[Bug c++/65646] [5 Regression] ICE in invalid syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65646 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r213641. Reducing.
[Bug c++/65646] [5 Regression] ICE in invalid syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65646 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Started with r213641.
[Bug ipa/65076] [5 Regression] 16% tramp3d-v4.cpp compile time regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076 --- Comment #47 from rguenther at suse dot de rguenther at suse dot de --- On Tue, 31 Mar 2015, hubicka at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076 --- Comment #42 from Jan Hubicka hubicka at gcc dot gnu.org --- Sorry, accidental message. It is 69-80.5s between 141127.61083 and 150113.26056 (tester was down) 66-69s between 141123.15275 and 141124.01653 60-64 between 140807.80282 and 140808.66762 Now the other tester shows 59-50 between 150112.41636 and 150113.13858 51-53 between 141124.14999 and 141123.43031 45-48 between 140807.01584 and 140808.72560 Can we, please, restart the frescobaldi tester? It is down sine 23rd. Not sure what happened - trying to investigate. Btw, terbium usually shows more smooth graphs (ok, it's Itanic...) (http://gcc.opensuse.org/c++bench-terbium/tramp3d/split-build.html) I'll see whether I can find the time to setup C++ testing on czerny. For terbium it's 114 - 124 between 141030.96758 (r216126) and 141211.32597 (r218621) (tester was down) 123 - 128 between 141228.22340 (r219074) and 141228.90737 (r219088) 129 - 160 between 150112.86585 (r219449) and 150113.55305 (r219508) 162 - 139 between 150119.02405 (r219836) and 150120.70780 (r219878) 138 - 127 between 150330.74477 (r221762) and 150330.46734 (r221770)
[Bug target/65648] New: [5 Regression] Bad code due to IRA fails to recognize the clobber in parallel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65648
Bug ID: 65648
Summary: [5 Regression] Bad code due to IRA fails to recognize
the clobber in parallel
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: terry.guo at arm dot com
Created attachment 35200
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35200action=edit
test case
When compile attached case with command:
arm-none-eabi-gcc -march=armv6-m -mthumb -Os x.c -S
The gcc generates bad code as below:
main:
push{r0, r1, r2, r4, r5, r6, r7, lr}
ldr r4, .L5
movsr5, #0
ldr r0, [r4, #8]
add r1, sp, #4
rsbsr2, r0, #0
adcsr2, r2, r0
subsr3, r2, r3 //r3 is used but not initialized
The instruction to initialize r3 is removed due to IRA failed to recognize the
clobber in reload pass. Before the reload pass, we have three instructions like
below:
(insn 12 11 14 2 (parallel [
(set (reg:SI 128)
(eq:SI (reg:SI 110 [ D.4914 ])
(const_int 0 [0])))
(clobber (reg:SI 129))
]) x.c:23 760 {*cstoresi_eq0_thumb1_insn}
(expr_list:REG_UNUSED (reg:SI 129)
(nil)))
(insn 20 19 22 2 (set (reg:SI 135)
(plus:SI (plus:SI (reg:SI 136)
(reg:SI 137))
(geu:SI (reg:SI 131 [ D.4914 ])
(reg:SI 134 [ c ] x.c:23 764 {thumb1_addsi3_addgeu}
(expr_list:REG_DEAD (reg:SI 137)
(expr_list:REG_DEAD (reg:SI 136)
(expr_list:REG_DEAD (reg:SI 134 [ c ])
(expr_list:REG_DEAD (reg:SI 131 [ D.4914 ])
(nil))
(insn 22 20 23 2 (set (reg:SI 138)
(minus:SI (reg:SI 128)
(reg:SI 135))) x.c:23 720 {thumb1_subsi3_insn}
(expr_list:REG_DEAD (reg:SI 135)
(expr_list:REG_DEAD (reg:SI 128)
(nil
After the reload pass, those instructions are wrongly turned into:
(insn 20 53 58 2 (set (reg:SI 3 r3 [135])
(plus:SI (plus:SI (reg:SI 3 r3 [137])
(reg:SI 2 r2 [136]))
(geu:SI (reg:SI 7 r7 [orig:131 D.4914 ] [131])
(reg:SI 6 r6 [153] x.c:23 764 {thumb1_addsi3_addgeu}
(nil))
(insn 58 20 55 2 (parallel [
(set (reg:SI 2 r2 [128])
(eq:SI (reg:SI 0 r0 [orig:110 D.4914 ] [110])
(const_int 0 [0])))
(clobber (reg:SI 3 r3 [129]))
]) x.c:23 760 {*cstoresi_eq0_thumb1_insn}
(nil))
(note 55 58 22 2 NOTE_INSN_DELETED)
(insn 22 55 23 2 (set (reg:SI 3 r3 [138])
(minus:SI (reg:SI 2 r2 [128])
(reg:SI 3 r3 [135]))) x.c:23 720 {thumb1_subsi3_insn}
(nil))
However the later pass can recognize the clobber in insn 58 and will remove the
insn 20 because the r3 defined in insn 20 is clobbered by insn 58.
[Bug sanitizer/61978] implement blacklist for sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61978 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #10 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Stewart Martin-Haugh from comment #9) Hi, I see this marked as WONTFIX - still, the use-cases that Kostya identifies are valid, I think. Would anyone be able to implement a patch, or suggest roughly how this might work? Although existing GCC devs may not find this feature interesting enough to implement it themselves, a nice, small patch properly submitted together with a convincingly argued rationale may get accepted. It seems this feature is being used not only by Chromium but also by LibreOffice, and many GCC users would still like to keep using GCC for building those programs. Many features that were initially rejected have been later accepted (e.g., color diagnostics). It just needs someone to get behind the idea and push for it in the right way.
[Bug target/65647] New: [5 Regression] GCC won't stop when compile for armv6-m with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65647 Bug ID: 65647 Summary: [5 Regression] GCC won't stop when compile for armv6-m with -Os Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: terry.guo at arm dot com Created attachment 35199 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35199action=edit gcc won't stop when compile this file When use below command to compile the attached case for armv6-m, seems the gcc won't stop: arm-none-eabi-gcc -march=armv6-m -mthumb -O3 gcc-no-stop.c -S With -da option, the file gcc-no-stop.c.234r.reload becomes larger an larger. I have to use contrl+c to terminate the gcc. Here are some lines extracted from the bottom of the file: Spill r17277(hr=0, freq=328) for r17822 Assign 0 to reload r17822 (freq=328) Assigning to 17823 (cl=LO_REGS, orig=17823, freq=328, tfirst=17823, tfreq=328)... Assign 0 to reload r17823 (freq=328) Assigning to 17825 (cl=LO_REGS, orig=17825, freq=328, tfirst=17825, tfreq=328)... The gcc version is gcc version 5.0.0 20150401 (experimental) (GCC). The issue happens after this commit: commit e0d2c8640c504ecd83291c4e008cb91d17df3e0d Author: rsandifo rsandifo@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Fri May 30 07:35:47 2014 + gcc/ ira.c (ira_get_dup_out_num): Check for output operands at
[Bug target/65647] [5 Regression] GCC won't stop when compile for armv6-m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65647 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||vmakarov at gcc dot gnu.org Target Milestone|--- |5.0
[Bug debug/65549] [5 Regression] crash in htab_hash_string with -flto -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65549 --- Comment #17 from Jakub Jelinek jakub at gcc dot gnu.org --- Lambda functions aren't really nested functions in the tree-nested.c sense, but still are so closely related to the functions they are nested in that IMHO it would be desirable not to split them off into separate partitions, not just temporarily for GCC 5 for debug info reasons. To find out lambdas, I think walking the list of argument types of a function, for each argument type strip of POINTER_TYPE_P and if it is a RECORD_TYPE after stripping those, check if TYPE_CONTEXT of that is some FUNCTION_DECL and in that case try to put the function into the same partition as that other FUNCTION_DECL.
[Bug rtl-optimization/65651] Redundant cmp with zero instruction in loop for x86 target.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65651 --- Comment #2 from Yuri Rumyantsev ysrumyan at gmail dot com --- Created attachment 35203 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35203action=edit test-case to reproduce
Re: [Bug target/65648] New: [5 Regression] Bad code due to IRA fails to recognize the clobber in parallel
On Wed, Apr 1, 2015 at 5:44 PM, terry.guo at arm dot com
gcc-bugzi...@gcc.gnu.org wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65648
Bug ID: 65648
Summary: [5 Regression] Bad code due to IRA fails to recognize
the clobber in parallel
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: terry.guo at arm dot com
Created attachment 35200
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35200action=edit
test case
When compile attached case with command:
arm-none-eabi-gcc -march=armv6-m -mthumb -Os x.c -S
The gcc generates bad code as below:
main:
push{r0, r1, r2, r4, r5, r6, r7, lr}
ldr r4, .L5
movsr5, #0
ldr r0, [r4, #8]
add r1, sp, #4
rsbsr2, r0, #0
adcsr2, r2, r0
subsr3, r2, r3 //r3 is used but not initialized
The instruction to initialize r3 is removed due to IRA failed to recognize the
clobber in reload pass. Before the reload pass, we have three instructions
like
below:
(insn 12 11 14 2 (parallel [
(set (reg:SI 128)
(eq:SI (reg:SI 110 [ D.4914 ])
(const_int 0 [0])))
(clobber (reg:SI 129))
]) x.c:23 760 {*cstoresi_eq0_thumb1_insn}
(expr_list:REG_UNUSED (reg:SI 129)
(nil)))
(insn 20 19 22 2 (set (reg:SI 135)
(plus:SI (plus:SI (reg:SI 136)
(reg:SI 137))
(geu:SI (reg:SI 131 [ D.4914 ])
(reg:SI 134 [ c ] x.c:23 764 {thumb1_addsi3_addgeu}
(expr_list:REG_DEAD (reg:SI 137)
(expr_list:REG_DEAD (reg:SI 136)
(expr_list:REG_DEAD (reg:SI 134 [ c ])
(expr_list:REG_DEAD (reg:SI 131 [ D.4914 ])
(nil))
(insn 22 20 23 2 (set (reg:SI 138)
(minus:SI (reg:SI 128)
(reg:SI 135))) x.c:23 720 {thumb1_subsi3_insn}
(expr_list:REG_DEAD (reg:SI 135)
(expr_list:REG_DEAD (reg:SI 128)
(nil
After the reload pass, those instructions are wrongly turned into:
(insn 20 53 58 2 (set (reg:SI 3 r3 [135])
(plus:SI (plus:SI (reg:SI 3 r3 [137])
(reg:SI 2 r2 [136]))
(geu:SI (reg:SI 7 r7 [orig:131 D.4914 ] [131])
(reg:SI 6 r6 [153] x.c:23 764 {thumb1_addsi3_addgeu}
(nil))
(insn 58 20 55 2 (parallel [
(set (reg:SI 2 r2 [128])
(eq:SI (reg:SI 0 r0 [orig:110 D.4914 ] [110])
(const_int 0 [0])))
(clobber (reg:SI 3 r3 [129]))
]) x.c:23 760 {*cstoresi_eq0_thumb1_insn}
(nil))
(note 55 58 22 2 NOTE_INSN_DELETED)
(insn 22 55 23 2 (set (reg:SI 3 r3 [138])
(minus:SI (reg:SI 2 r2 [128])
(reg:SI 3 r3 [135]))) x.c:23 720 {thumb1_subsi3_insn}
(nil))
However the later pass can recognize the clobber in insn 58 and will remove
the
insn 20 because the r3 defined in insn 20 is clobbered by insn 58.
This is a bug in the arm's thumb1.md file, it uses match_operand when
it should really be using match_scratch.
Looks like most of the arm back-end has this bug in it.
See
https://gcc.gnu.org/onlinedocs/gccint/Regs-and-Memory.html#index-scratch-2870
and the corresponding match_scratch documentation.
That is this:
1515 (define_insn *cstoresi_eq0_thumb1_insn
1516 [(set (match_operand:SI 0 s_register_operand =l,l)
1517 (eq:SI (match_operand:SI 1 s_register_operand l,0)
1518(const_int 0)))
1519(clobber (match_operand:SI 2 s_register_operand =X,l))]
1520 TARGET_THUMB1
1521 @
1522rsbs\\t%0, %1, #0\;adcs\\t%0, %0, %1
1523rsbs\\t%2, %1, #0\;adcs\\t%0, %1, %2
1524 [(set_attr length 4)
1525(set_attr type multiple)]
1526 )
Really should be using (clobber (match_scratch:... ))
So it generates a scratch RTL right away and then the register
allocater knows that it is only used in that instruction.
Thanks,
Andrew
[Bug target/65648] [5 Regression] Bad code due to IRA fails to recognize the clobber in parallel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65648
--- Comment #1 from pinskia at gmail dot com pinskia at gmail dot com ---
On Wed, Apr 1, 2015 at 5:44 PM, terry.guo at arm dot com
gcc-bugzi...@gcc.gnu.org wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65648
Bug ID: 65648
Summary: [5 Regression] Bad code due to IRA fails to recognize
the clobber in parallel
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: terry.guo at arm dot com
Created attachment 35200
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35200action=edit
test case
When compile attached case with command:
arm-none-eabi-gcc -march=armv6-m -mthumb -Os x.c -S
The gcc generates bad code as below:
main:
push{r0, r1, r2, r4, r5, r6, r7, lr}
ldr r4, .L5
movsr5, #0
ldr r0, [r4, #8]
add r1, sp, #4
rsbsr2, r0, #0
adcsr2, r2, r0
subsr3, r2, r3 //r3 is used but not initialized
The instruction to initialize r3 is removed due to IRA failed to recognize the
clobber in reload pass. Before the reload pass, we have three instructions
like
below:
(insn 12 11 14 2 (parallel [
(set (reg:SI 128)
(eq:SI (reg:SI 110 [ D.4914 ])
(const_int 0 [0])))
(clobber (reg:SI 129))
]) x.c:23 760 {*cstoresi_eq0_thumb1_insn}
(expr_list:REG_UNUSED (reg:SI 129)
(nil)))
(insn 20 19 22 2 (set (reg:SI 135)
(plus:SI (plus:SI (reg:SI 136)
(reg:SI 137))
(geu:SI (reg:SI 131 [ D.4914 ])
(reg:SI 134 [ c ] x.c:23 764 {thumb1_addsi3_addgeu}
(expr_list:REG_DEAD (reg:SI 137)
(expr_list:REG_DEAD (reg:SI 136)
(expr_list:REG_DEAD (reg:SI 134 [ c ])
(expr_list:REG_DEAD (reg:SI 131 [ D.4914 ])
(nil))
(insn 22 20 23 2 (set (reg:SI 138)
(minus:SI (reg:SI 128)
(reg:SI 135))) x.c:23 720 {thumb1_subsi3_insn}
(expr_list:REG_DEAD (reg:SI 135)
(expr_list:REG_DEAD (reg:SI 128)
(nil
After the reload pass, those instructions are wrongly turned into:
(insn 20 53 58 2 (set (reg:SI 3 r3 [135])
(plus:SI (plus:SI (reg:SI 3 r3 [137])
(reg:SI 2 r2 [136]))
(geu:SI (reg:SI 7 r7 [orig:131 D.4914 ] [131])
(reg:SI 6 r6 [153] x.c:23 764 {thumb1_addsi3_addgeu}
(nil))
(insn 58 20 55 2 (parallel [
(set (reg:SI 2 r2 [128])
(eq:SI (reg:SI 0 r0 [orig:110 D.4914 ] [110])
(const_int 0 [0])))
(clobber (reg:SI 3 r3 [129]))
]) x.c:23 760 {*cstoresi_eq0_thumb1_insn}
(nil))
(note 55 58 22 2 NOTE_INSN_DELETED)
(insn 22 55 23 2 (set (reg:SI 3 r3 [138])
(minus:SI (reg:SI 2 r2 [128])
(reg:SI 3 r3 [135]))) x.c:23 720 {thumb1_subsi3_insn}
(nil))
However the later pass can recognize the clobber in insn 58 and will remove
the
insn 20 because the r3 defined in insn 20 is clobbered by insn 58.
This is a bug in the arm's thumb1.md file, it uses match_operand when
it should really be using match_scratch.
Looks like most of the arm back-end has this bug in it.
See
https://gcc.gnu.org/onlinedocs/gccint/Regs-and-Memory.html#index-scratch-2870
and the corresponding match_scratch documentation.
That is this:
1515 (define_insn *cstoresi_eq0_thumb1_insn
1516 [(set (match_operand:SI 0 s_register_operand =l,l)
1517 (eq:SI (match_operand:SI 1 s_register_operand l,0)
1518(const_int 0)))
1519(clobber (match_operand:SI 2 s_register_operand =X,l))]
1520 TARGET_THUMB1
1521 @
1522rsbs\\t%0, %1, #0\;adcs\\t%0, %0, %1
1523rsbs\\t%2, %1, #0\;adcs\\t%0, %1, %2
1524 [(set_attr length 4)
1525(set_attr type multiple)]
1526 )
Really should be using (clobber (match_scratch:... ))
So it generates a scratch RTL right away and then the register
allocater knows that it is only used in that instruction.
Thanks,
Andrew
[Bug target/42159] unwinding issues on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42159 --- Comment #34 from Jack Howarth howarth.at.gcc at gmail dot com --- (In reply to Pierre Ossman from comment #32) I can understand that. But in that case why keep the gcc unwinder on OS X? Mainly inertia. The more important issue is weaning darwin off of the compatibility unwinder which is on borrowed time and may well disappear in the next OS release. If it doesn't work then including it is just an accident waiting to happen. I would suggest something along the lines of the attached patch.
[Bug tree-optimization/23331] FIXME from tree-ssa-ccp: dealing with a[3]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23331
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #3 from Richard Biener rguenth at gcc dot gnu.org ---
The FIXME is gone and we transform this to
f ()
{
int a;
char _2;
int _3;
bb 2:
_2 = a[13];
_3 = (int) _2;
return _3;
}
which is good enough (we could make CCP more optimistic, treating _2 as
UNDEFINED and finally replacing remaining UNDEFINED uses with
__builtin_unreachable ()).
But that's a different bug.
[Bug tree-optimization/65650] CCP does not propgate copies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65650 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-04-01 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- I have a patch teaching CCP to perform copy propagation in its lattice.
[Bug tree-optimization/65650] New: CCP does not propgate copies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65650
Bug ID: 65650
Summary: CCP does not propgate copies
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
CCP should be able to optimize the following to return 0; in a single pass
invocation.
int foo (int i)
{
int j = i;
int k = 0;
int l = j + k;
int m = l - j;
return m;
}
[Bug c++/65646] [5 Regression] ICE in invalid syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65646
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||jason at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org ---
Reduced testcase:
template typename = int class A {};
template A A::a;
[Bug ipa/65557] ICE: SIGSEGV in hash_table::find_slot_with_hash() with -fdevirtualize -fipa-cp -fipa-icf-functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65557 Martin Liška marxin at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Martin Liška marxin at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/21791] ccp and copy-prop print out too much garbage with -fdump-tree-ccp/copy-details
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21791 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Fixed (dead stmts are no longer folded but removed): Substituting values and folding statements Folding PHI node: i_1 = PHI i_2(2), i_3(3) Folded into: i_1 = PHI 0(2), i_3(3) Folding statement: if (i_1 = 99) which is likely CONSTANT Not folded Folding statement: i_3 = i_1 + 1; Not folded Folding statement: return; Not folded Removing dead stmt i_2 = 0;
[Bug target/65576] ICE in gcc.c-torture/compile/pr33855.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65576 Alan Modra amodra at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-01 CC||amodra at gmail dot com Ever confirmed|0 |1 --- Comment #4 from Alan Modra amodra at gmail dot com --- Confirmed. The failure occurs with -mcpu=power6x or lower.
[Bug rtl-optimization/65651] Redundant cmp with zero instruction in loop for x86 target.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65651 --- Comment #1 from Yuri Rumyantsev ysrumyan at gmail dot com --- Created attachment 35202 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35202action=edit test-case to reproduce Need to compile with -O2 flag only.
[Bug rtl-optimization/65651] New: Redundant cmp with zero instruction in loop for x86 target.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65651 Bug ID: 65651 Summary: Redundant cmp with zero instruction in loop for x86 target. Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ysrumyan at gmail dot com Compile attached bad.c with -O2 option only we can see that redundant cmp with zero instruction is generated: subl%r9d, %eax cmpl$0, %eax je.L10 but for slightly changed good.c there is no such redundancy: subl%r9d, %eax je.L10 The problem phase is combine. For good case it does combining: Trying 37 - 38: Successfully matched this instruction: (parallel [ (set (reg:CCZ 17 flags) (compare:CCZ (minus:SI (reg:SI 121 [ D.2002 ]) (reg/v:SI 115 [ med ])) (const_int 0 [0]))) (set (reg/v:SI 101 [ n ]) (minus:SI (reg:SI 121 [ D.2002 ]) (reg/v:SI 115 [ med ]))) ]) allowing combination of insns 37 and 38 original costs 4 + 4 = 8 replacement cost 0 but for bad case it is not performed: Trying 37 - 38: Failed to match this instruction: (set (reg:CC 17 flags) (compare:CC (minus:SI (reg:SI 120 [ D.2006 ]) (reg/v:SI 114 [ med ])) (const_int 0 [0]))) Note that this test-case extracted from one of hot loop in bzip2 (mainQSort3).
[Bug c++/65652] New: defaulted default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65652
Bug ID: 65652
Summary: defaulted default constructor
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: wolfgang.roe...@gi-de.com
Hi,
I would like to post a bug report for the GNU C/C++ compiler 4.8.3.
We use the compiler to generate code for a PowerPC processor.
Invokation line for the GNU C++ compiler:
ccppc -c -x c++ -std=c++11 -Wall -Werror -g -mcpu=8540 -meabi
-ftls-model=local-exec -msdata=sysv -fno-common -mspe -mabi=spe
-mfloat-gprs=double -mbig -mmultiple -mno-string -misel -mstrict-align
-fverbose-asm -fno-exceptions -fno-rtti -fgcse-sm -fno-section-anchors
-ftemplate-backtrace-limit=20 -G 8 -O3
-Isome include paths
-Dsome #define's
X.CPP -oX.O
// file X.CPP
struct S
{
// S () = default;
S (const S) = delete;
S operator= (const S) = delete;
};
S x;
The compiler rejects this programm with the following message:
x.CPP:9:3: error: no matching function for call to 'S::S()'
S x;
^
x.CPP:9:3: note: candidate is:
x.CPP:5:5: note: S::S(const S) deleted
S (const S) = delete;
^
x.CPP:5:5: note: candidate expects 1 argument, 0 provided
I think this is not standard conforming. The C++11 standard, 12.1/5 says:
If there is no user-declared constructor for class X, a constructor having
no parameters is implicitly declared as defaulted (8.4). I don't think that
S (const S) = delete; should be counted as a user-declared constructor.
Notes:
. If line 3 is uncommented the compiler accepts the programm.
. IF line 5 is commented out the compiler accepts the programm.
With kind regards
W. Roehrl
[Bug target/65649] New: gcc generates overlarge constants for microblaze-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65649
Bug ID: 65649
Summary: gcc generates overlarge constants for
microblaze-linux-gnu
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dhowells at redhat dot com
Whilst compiling libgcc for microblaze-linux-gnu, gcc produces overlarge
constants that don't fit into a 32-bits (microblaze is a 32-bit arch), eg:
addikr23,r0,0xb746a0003f80
the assembler complains about these:
_powisf2.s:71: Fatal error: operand must be a constant or a label
if it is hosted on a 32-bit arch (eg. i386) but not if it's hosted on a 64-bit
arch (eg. x86_64). This is logged here:
https://sourceware.org/bugzilla/show_bug.cgi?id=18189
However, gcc shouldn't be producing these at all.
Reducing the preprocessed C to the bare function gives:
float __powisf2 (float x, int m)
{
unsigned int n = m 0 ? -m : m;
float y = n % 2 ? x : 1;
while (n = 1)
{
x = x * x;
if (n % 2)
y = y * x;
}
return m 0 ? 1/y : y;
}
Reducing it still further to:
float __powisf2 (float x, int m)
{
unsigned int n = m 0 ? -m : m;
float y = n % 2 ? x : 1;
return y;
}
gives the error _only_ if -g is supplied. Looking at the assembly output of
this, the dodgy instruction is now:
addik r3,r0,0xb745e0003f80
with -g and:
addik r3,r0,0x3f80
without.
The compilation line is:
/root/cross-gcc/gcc-5.0.0-20150319/microblaze-linux-gnu/gcc/xgcc
-B/root/cross-gcc/gcc-5.0.0-20150319/microblaze-linux-gnu/gcc/
-B/usr/microblaze-linux-gnu/bin/ -B/usr/microblaze-linux-gnu/lib/ -O2 -fPIC
-fbuilding-libgcc -fno-exceptions -fno-stack-protector -fvisibility=hidden -o
_powisf2.o -c _powisf2.i --save-temps -g
[Bug tree-optimization/44669] ccp or similar passes aren't run after cunroll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44669 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.6.0 Known to fail||4.5.4 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Fixed already in 4.6.0, optimized by DOM.
[Bug c++/65642] [C++11] GCC rejects valid constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65642 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-04-01 CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |5.0 Ever confirmed|0 |1 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- I'll take a look.
[Bug target/65649] gcc generates overlarge constants for microblaze-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65649 --- Comment #2 from dhowells at redhat dot com dhowells at redhat dot com --- gcc was based on the gcc-5.0.0-20150319 tarball generated from the gcc branch redhat/gcc-5-branch plus the patches for the Fedora rawhide gcc and cross-gcc. Configuration was: CC=gcc \ CXX=g++ \ CFLAGS='-O2 -g -Wall -Wformat-security -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -mtune=atom -fasynchronous-unwind-tables' \ CXXFLAGS=' -O2 -g -Wformat-security -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -mtune=atom -fasynchronous-unwind-tables ' \ CFLAGS_FOR_TARGET='-g -O2 -Wall -fno-exceptions' \ AR_FOR_TARGET=/usr/bin/microblaze-linux-gnu-ar \ AS_FOR_TARGET=/usr/bin/microblaze-linux-gnu-as \ DLLTOOL_FOR_TARGET=/usr/bin/microblaze-linux-gnu-dlltool \ LD_FOR_TARGET=/usr/bin/microblaze-linux-gnu-ld \ NM_FOR_TARGET=/usr/bin/microblaze-linux-gnu-nm \ OBJDUMP_FOR_TARGET=/usr/bin/microblaze-linux-gnu-objdump \ RANLIB_FOR_TARGET=/usr/bin/microblaze-linux-gnu-ranlib \ READELF_FOR_TARGET=/usr/bin/microblaze-linux-gnu-readelf \ STRIP_FOR_TARGET=/usr/bin/microblaze-linux-gnu-strip \ WINDRES_FOR_TARGET=/usr/bin/microblaze-linux-gnu-windres \ WINDMC_FOR_TARGET=/usr/bin/microblaze-linux-gnu-windmc \ LDFLAGS='-Wl,-z,relro ' \ ../gcc-5.0.0-20150319/configure --bindir=/usr/bin --build=i686-redhat-linux-gnu --datadir=/usr/share --disable-decimal-float --disable-dependency-tracking --disable-gold --disable-libgcj --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-libunwind-exceptions --disable-nls --disable-plugin --disable-shared --disable-silent-rules --disable-sjlj-exceptions --disable-threads --with-ld=/usr/bin/microblaze-linux-gnu-ld --enable-__cxa_atexit --enable-checking=release --enable-gnu-indirect-function --enable-gnu-unique-object --enable-initfini-array --enable-languages=c,c++ --enable-linker-build-id --enable-nls --enable-obsolete --enable-plugin --enable-targets=all --exec-prefix=/usr --host=i686-redhat-linux-gnu --includedir=/usr/include --infodir=/usr/share/info --libexecdir=/usr/libexec --localstatedir=/var --mandir=/usr/share/man --prefix=/usr --program-prefix=microblaze-linux-gnu- --sbindir=/usr/sbin --sharedstatedir=/var/lib --sysconfdir=/etc --target=microblaze-linux-gnu --with-bugurl=http://bugzilla.redhat.com/bugzilla/ --with-isl --with-linker-hash-style=gnu --with-newlib --with-sysroot=/usr/microblaze-linux-gnu/sys-root --with-system-libunwind --with-system-zlib --without-headers And the build: make -C microblaze-linux-gnu -j16 tooldir=/usr all-gcc make -C microblaze-linux-gnu -j16 tooldir=/usr all-target-libgcc The microblaze binutils was binutils-2.25 plus the Fedora F21 patches from the cross-binutils targetted at microblaze-linux-gnu.
[Bug target/65624] ICE in aarch64-builtins.c when expanding 4-argument aarch64 intrinsic.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65624 --- Comment #6 from Maxim Ostapenko chefmax at gcc dot gnu.org --- Author: chefmax Date: Wed Apr 1 11:18:03 2015 New Revision: 221807 URL: https://gcc.gnu.org/viewcvs?rev=221807root=gccview=rev Log: 2015-04-01 Max Ostapenko m.ostape...@partner.samsung.com PR target/65624 gcc/ * config/aarch64/aarch64-builtins.c (aarch64_simd_expand_builtin): Increase args array size by one to avoid buffer overflow. gcc/testsuite/ * gcc.target/aarch64/pr65624.c: New test. Added: trunk/gcc/testsuite/gcc.target/aarch64/pr65624.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64-builtins.c trunk/gcc/testsuite/ChangeLog
[Bug target/65649] gcc generates overlarge constants for microblaze-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65649 --- Comment #1 from dhowells at redhat dot com dhowells at redhat dot com --- Created attachment 35201 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35201action=edit Assembler output from larger reduced case Here is the assembler output from the larger reduced case. The dodgy constant occurs on line 71 and also on line 124.
[Bug c++/65554] ICE: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65554 --- Comment #10 from Marek Polacek mpolacek at gcc dot gnu.org --- Could anyone please reduce the original testcase again (but please make sure that cc1plus has the r221808 fix)? If not, I'll try to get to that tomorrow.
[Bug target/65644] Assembler errors on Solaris 10 x86-64: `(%eXX)' is not a valid 64 bit base/index expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65644 --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- (%edi) etc. in 64-bit mode should be assembled as addr32 (0x67) prefix on the instruction. If Solaris assembler doesn't handle it, guess first somebody needs to investigate if it has a different syntax for the same thing, or just doesn't support it at all, what versions are affected etc. If it doesn't support it at all, it would mean -mx32 support would be impossible, and the addr32 pieces in e.g. ix86_decompose_address would need to be disabled based on some configure macro. The versions of /usr/ccs/bin/as I have assemble it just fine, on both Solaris 10 and 11. I haven't investigated the original Solaris 10 FCS assembler, but suggest just installing the latest assembler patch (119961-11) and be done with it. Rainer
[Bug c++/65554] ICE: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65554 --- Comment #9 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Wed Apr 1 13:08:05 2015 New Revision: 221808 URL: https://gcc.gnu.org/viewcvs?rev=221808root=gccview=rev Log: PR c++/65554 * class.c (finish_struct): Require that the second field of a user-defined initializer_list be of size type. * g++.dg/cpp0x/initlist93.C: New test. * g++.dg/cpp0x/initlist94.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/initlist93.C trunk/gcc/testsuite/g++.dg/cpp0x/initlist94.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/testsuite/ChangeLog
[Bug c++/65652] defaulted default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65652 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Wolfgang Roehrl from comment #0) I don't think that S (const S) = delete; should be counted as a user-declared constructor. You declared the constructor, and you defined it as deleted. But that still means you declared it.
[Bug rtl-optimization/65651] Redundant cmp with zero instruction in loop for x86 target.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65651 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||uros at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Well, there is a significant difference between the two testcases, one uses the result of the comparison just in == 0 test, thus CCZmode is appropriate, the other uses it in two comparisons, one == 0 test and one 0 test. For combine to match *submode_2 insn, it has to match ix86_match_ccmode (insn, CCGOCmode) where CCGOCmode stands for: Add CCGOC to indicate comparisons against zero that allows unspecified garbage in the Carry and Overflow flag. This mode is used to simulate comparisons of (a-b) and (a+b) against zero using sub/cmp/add operations. But the jle instruction tests ZF || SF OF and thus it isn't appropriate. So the question is if the CCGOC test isn't too restrictive, say if CCGCmode would be sufficient (but then we'd still need to arrange for the CCGCmode to be used, rather than CCmode), or if the optimization you are looking for is simply not possible.
[Bug rtl-optimization/65651] Redundant cmp with zero instruction in loop for x86 target.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65651 --- Comment #4 from Yuri Rumyantsev ysrumyan at gmail dot com --- Jakub, Thanks for your comments. We will try to fix this issue ourselves. Best regards. Yuri. P.S. Note that icc does not produce such redundant cmp with zero. 2015-04-01 16:10 GMT+03:00 jakub at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65651 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||uros at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Well, there is a significant difference between the two testcases, one uses the result of the comparison just in == 0 test, thus CCZmode is appropriate, the other uses it in two comparisons, one == 0 test and one 0 test. For combine to match *submode_2 insn, it has to match ix86_match_ccmode (insn, CCGOCmode) where CCGOCmode stands for: Add CCGOC to indicate comparisons against zero that allows unspecified garbage in the Carry and Overflow flag. This mode is used to simulate comparisons of (a-b) and (a+b) against zero using sub/cmp/add operations. But the jle instruction tests ZF || SF OF and thus it isn't appropriate. So the question is if the CCGOC test isn't too restrictive, say if CCGCmode would be sufficient (but then we'd still need to arrange for the CCGCmode to be used, rather than CCmode), or if the optimization you are looking for is simply not possible. -- You are receiving this mail because: You reported the bug.
[Bug target/65648] [5 Regression] Bad code due to IRA fails to recognize the clobber in parallel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65648 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target||arm Priority|P3 |P1 Target Milestone|--- |5.0
[Bug c++/65554] ICE: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65554 --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org --- Reducing...
[Bug c++/65646] [5 Regression] ICE in invalid syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65646 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug target/65647] [5 Regression] GCC won't stop when compile for armv6-m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65647 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||ra Target||arm-none-eabi Priority|P3 |P1
[Bug target/65644] Assembler errors on Solaris 10 x86-64: `(%eXX)' is not a valid 64 bit base/index expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65644 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #5 from Uroš Bizjak ubizjak at gmail dot com --- Not a GCC bug then.
[Bug preprocessor/61977] [4.8/4.9/5 Regression] powerpc preprocessor breaks on lines that end with vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61977 --- Comment #9 from David Rivshin drivshin at allworx dot com --- I think the extra newline is the result of maybe_print_line() being invoked when trying to peek past a newline in the input. #0 maybe_print_line_1 (src_loc=134, stream=0x361e3b8800 _IO_2_1_stdout_) at c-ppoutput.c:352 #1 maybe_print_line (src_loc=134) at c-ppoutput.c:385 #2 do_line_change (pfile=0x1ef2910, token=0x1f1dd68, src_loc=134, parsing_args=0) at c-ppoutput.c:463 #3 cb_line_change (pfile=0x1ef2910, token=0x1f1dd68, parsing_args=0) at c-ppoutput.c:490 #4 _cpp_lex_token (pfile=0x1ef2910) at lex.c:2192 #5 cpp_peek_token (pfile=0x1ef2910, index=0) at lex.c:2085 #6 cpp_get_token_1 (pfile=0x1ef2910, location=0x7fffd8fc) at macro.c:2501 If I'm understanding the logic correctly, when _cpp_lex_direct() sees the newline, the processing of the line is considered complete, and therefore that line of output complete. But because of the conditional macro that's not entirely true, and the output only has the line up to (but not including) the conditional macro token itself at that point.
[Bug c++/65646] [5 Regression] ICE in invalid syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65646 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||error-recovery Priority|P3 |P5
[Bug go/63731] Fallback to netgo does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731 --- Comment #34 from boger at us dot ibm.com --- Created a codereview: https://codereview.appspot.com/217620043
[Bug fortran/65541] [5 Regression] namelist regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65541 --- Comment #8 from John jwmwalrus at gmail dot com --- Hi, It seems that some testing was required after all. With the latest gcc snapshot from Debian (20150329-1) I still get the same output from the test code: $ ll `which gfortran-5.0 ` lrwxrwxrwx 1 root staff 35 Feb 26 11:01 /usr/local/bin/gfortran-5.0 - ../../lib/gcc-snapshot/bin/gfortran* $ gfortran-5.0 test_namelist.f90 $ ./a.out $ cat some.dat SOME A+T2+T1%I= 0, A+T2+J= 0, A+K= 0, / In my actual code, what fails is READING a namelist generated by a previous version of gfortran, so maybe that needs some checking as well? System and compiler information follows: $ lsb_release -rd gfortran-5.0 -v Description:Debian GNU/Linux 8.0 (jessie) Release:8.0 Using built-in specs. COLLECT_GCC=gfortran-5.0 COLLECT_LTO_WRAPPER=/usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/5.0.0/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 20150329-1' --with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs --enable-languages=c,ada,c++,java,go,fortran,objc,obj-c++ --prefix=/usr/lib/gcc-snapshot --enable-shared --enable-linker-build-id --disable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=c++98 --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-snap-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-snap-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-snap-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --disable-werror --enable-checking=yes --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 5.0.0 20150329 (experimental) [trunk revision 221764] (Debian 20150329-1)
[Bug ipa/65478] [5 regression] crafty performance regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW --- Comment #22 from Richard Biener rguenth at gcc dot gnu.org --- Seems to be a regression with -flto only? I also see EON regressing without -flto. http://gcc.opensuse.org/SPEC/CINT/sb-megrez-head-64/index.html
[Bug c/65653] cilkplus reducer ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65653 --- Comment #1 from tprince at computer dot org --- Created attachment 35205 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35205action=edit pre-processed C source
[Bug fortran/65541] [5 Regression] namelist regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65541 --- Comment #9 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- (In reply to John from comment #8) Hi, It seems that some testing was required after all. With the latest gcc snapshot from Debian (20150329-1) I still get the same output from the test code: Full testing was done. For me here, if you do not explicitly set the LD_LIBRARY_PATH its possible to compile with one version of gfortran and execute with another library. So, try it with -static to make sure that is not the issue. Also I did confirm with your example in your original post here that output from 5. is compatible with 4.9 and the 4.9 compiled with -static could actually read correctly output generated by 5.0. My comment about testing relates to not being able to run 4.9 and 5.0 automatically in our test suite. If you still see a problem, let me know, maybe there is something else going on.
[Bug c++/65554] ICE: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65554
--- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org ---
namespace std
{
struct B { enum { __value }; };
template typename _Iterator struct C
{
static _Iterator _S_base (_Iterator p1) { return p1; }
};
template typename using _RequireInputIter = int;
template typename _Iterator _Iterator __niter_base (_Iterator p1)
{
return std::C _Iterator::_S_base (p1);
}
template typename _Iterator _Iterator __miter_base (_Iterator p1)
{
return std::C _Iterator::_S_base (p1);
}
struct D
{
template typename _Tp static _Tp *__copy_m (_Tp * p1, _Tp * p2, _Tp *)
{
int _Num = p2 - p1;
__builtin_memmove (0, p1, sizeof (_Tp) * _Num);
}
};
template int, typename _II, typename _OI void __copy_move_a (_II p1, _II
p2, _OI p3)
{
D::__copy_m (p1, p2, p3);
}
template int, typename _II, typename _OI void __copy_move_a2 (_II p1, _II
p2, _OI p3)
{
__copy_move_a 0 (std::__niter_base (p1), std::__niter_base (p2),
std::__niter_base (p3));
}
template typename _II, typename _OI void copy (_II p1, _II p2, _OI p3)
{
__copy_move_a2 B::__value (std::__miter_base (p1), std::__miter_base
(p2), p3);
}
}
template typename _Tp struct F { typedef _Tp *pointer; };
namespace std
{
template typename _Tp using __allocator_base = F _Tp;
template typename _Tp struct allocator:__allocator_base _Tp {};
template class _E struct initializer_list
{
typedef _E *const_iterator;
_E *_M_array;
unsigned long _M_len;
const_iterator begin () { return _M_array; }
const_iterator end () { return begin () + 1; }
};
template typename _Alloc struct allocator_traits
{
template typename _Tp static typename _Tp::pointer _S_pointer_helper (_Tp
*);
typedef decltype (_S_pointer_helper ((_Alloc *) 0)) __pointer;
typedef __pointer pointer;
};
}
template typename struct __alloc_traits:
std::allocator_traits std::allocator const char * {};
namespace std
{
struct G
{
template typename _InputIterator, typename _ForwardIterator static
_ForwardIterator __uninit_copy (_InputIterator p1, _InputIterator p2,
_ForwardIterator p3)
{
copy (p1, p2, p3);
}
};
template typename _InputIterator, typename _ForwardIterator void
uninitialized_copy (_InputIterator p1, _InputIterator p2, _ForwardIterator
p3)
{
G::__uninit_copy (p1, p2, p3);
}
template typename _InputIterator, typename _ForwardIterator, typename _Tp
void __uninitialized_copy_a (_InputIterator p1, _InputIterator p2,
_ForwardIterator p3, allocator _Tp )
{
uninitialized_copy (p1, p2, p3);
}
struct H
{
typedef std::allocator int * _Tp_alloc_type;
typedef __alloc_traits _Tp_alloc_type::pointer pointer;
_Tp_alloc_type _M_get_Tp_allocator ();
};
template typename _Tp, typename = std::allocator _Tp struct J: H
{
void operator= (initializer_list _Tp p1)
{
this-assign (p1.begin (), p1.end ());
}
template typename _InputIterator, typename = std::_RequireInputIter
_InputIterator void assign (_InputIterator p1, _InputIterator p2)
{
_M_assign_dispatch (p1, p2, 0);
}
pointer _M_allocate_and_copy___result;
template typename _ForwardIterator void _M_allocate_and_copy (int,
_ForwardIterator p2, _ForwardIterator p3)
{
__uninitialized_copy_a (p2, p3, _M_allocate_and_copy___result,
_M_get_Tp_allocator ());
}
template typename _InputIterator void _M_assign_dispatch (_InputIterator
p1, _InputIterator p2, int)
{
_M_assign_aux (p1, p2, 0);
}
template typename _ForwardIterator void _M_assign_aux (_ForwardIterator,
_ForwardIterator, int);
};
template typename _Tp, typename _Alloc
template typename _ForwardIterator void J _Tp, _Alloc::_M_assign_aux
(_ForwardIterator p1, _ForwardIterator p2, int)
{
_M_allocate_and_copy (0, p1, p2);
}
class I
{
void tabCompletion (std::J int) const;
};
void
I::tabCompletion (J int) const
{
J const char * extra;
extra = { insert };
}
}
[Bug ipa/65654] New: [5 Regression] 447.dealII in SPEC CPU 2006 failed to build with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65654 Bug ID: 65654 Summary: [5 Regression] 447.dealII in SPEC CPU 2006 failed to build with LTO Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: hubicka at ucw dot cz On Linux/x86-64, r221769 caused: g++ -O3 -funroll-loops -ffast-math -fwhole-program -flto=jobserver -fuse-linker-plugin -DSPEC_CPU_LP64auto_derivative_function.o block_sparse_matrix.o block_sparse_matrix_ez.o block_sparsity_pattern.o block_vector.o compressed_sparsity_pattern.o data_out.o data_out_base.o data_out_faces.o data_out_rotation.o data_out_stack.o derivative_approximation.o dof_accessor.o dof_constraints.o dof_handler.o dof_levels.o dof_renumbering.o dof_tools.o error_estimator.o exceptions.o fe.o fe_data.o fe_dgp.o fe_dgp_1d.o fe_dgp_2d.o fe_dgp_3d.o fe_dgp_nonparametric.o fe_dgq.o fe_dgq_1d.o fe_dgq_2d.o fe_dgq_3d.o fe_nedelec.o fe_nedelec_1d.o fe_nedelec_2d.o fe_nedelec_3d.o fe_q.o fe_q_1d.o fe_q_2d.o fe_q_3d.o fe_q_hierarchical.o fe_raviart_thomas.o fe_system.o fe_tools.o fe_values.o filtered_matrix.o full_matrix.double.o full_matrix.float.o function.o function_derivative.o function_lib.o function_lib_cutoff.o function_time.o geometry_info.o grid_generator.o grid_in.o grid_out.all_dimensions.o grid_out.o grid_refinement.o grid_reordering.o histogram.o intergrid_map.o job_identifier.o log.o mapping.o mapping_c1.o mapping_cartesian.o mapping_q.o mapping_q1.o mapping_q1_eulerian.o matrices.all_dimensions.o matrices.o matrix_lib.o matrix_out.o memory_consumption.o mg_base.o mg_dof_accessor.o mg_dof_handler.o mg_dof_tools.o mg_smoother.o mg_transfer_block.o mg_transfer_prebuilt.o mg_transfer_block.all_dimensions.o multigrid.all_dimensions.o multithread_info.o parameter_handler.o persistent_tria.o polynomial.o polynomial_space.o programid.o quadrature.o quadrature_lib.o solution_transfer.o solver_control.o sparse_matrix.double.o sparse_matrix.float.o sparse_matrix_ez.double.o sparse_matrix_ez.float.o sparsity_pattern.o step-14.o subscriptor.o swappable_vector.o tensor.o tensor_product_polynomials.o tria.all_dimensions.o tria.o tria_accessor.o tria_boundary.o tria_boundary_lib.o vector.o vector.long_double.o vectors.all_dimensions.o fe_dgp_monomial.o fe_poly.o polynomials_bdm.o polynomials_p.o vectors.o -o dealII lto1: internal compiler error: in inline_call, at ipa-inline-transform.c:386 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. lto-wrapper: fatal error: g++ returned 1 exit status compilation terminated. /usr/local/bin/ld: error: lto-wrapper failed collect2: error: ld returned 1 exit status specmake: *** [dealII] Error 1
[Bug target/65624] ICE in aarch64-builtins.c when expanding 4-argument aarch64 intrinsic.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65624 Maxim Ostapenko chefmax at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Maxim Ostapenko chefmax at gcc dot gnu.org --- Fixed.
[Bug fortran/65541] [5 Regression] namelist regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65541 --- Comment #10 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- For the record, my results with trunk: $ gfc pr65541.f90 $ ./a.out $ cat some.dat SOME A%T2%T1%I= 0, A%T2%J= 0, A%K= 0, /
[Bug target/65581] [5 Regression] testsuite lto issue: multiple definition of `main', undefined reference to `WinMain'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65581 --- Comment #7 from Rainer Emrich rai...@emrich-ebersheim.de --- (In reply to Kai Tietz from comment #6) As far as I understand this issue does LTO now handle stuff used from object file different to prior versions. I add Jan. He might be able to give us some more points Any news on this issue. IMHO it would be a shame to not have lto working on mingw-w64 targets for gcc 5.0, even mingw-w64 isn't primary/secondary platform.
[Bug c/65653] cilkplus reducer ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65653 --- Comment #2 from tprince at computer dot org --- runs well with Intel C++ Windows/linux
[Bug c/65653] New: cilkplus reducer ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65653 Bug ID: 65653 Summary: cilkplus reducer ICE Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: tprince at computer dot org Created attachment 35204 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35204action=edit cilkplus C source gcc -c -fcilkplus s319.i gcc version 5.0.0 20150326 s319.c:82:41: internal compiler error: in gimplify_expr, at gimplify.c:8629 (a[1:i__2]=c__[1:i__2]+d__[1:i__2]) +
[Bug preprocessor/61977] [4.8/4.9/5 Regression] powerpc preprocessor breaks on lines that end with vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61977 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org --- Please see: http://gcc.gnu.org/ml/gcc-patches/2015-04/msg4.html http://gcc.gnu.org/ml/gcc-patches/2015-04/msg5.html http://gcc.gnu.org/ml/gcc-patches/2015-04/msg00013.html
[Bug middle-end/61118] Spurious -Wclobbered warning generated by gcc 4.9.0 for pthread_cleanup_push
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61118 --- Comment #2 from Daniel Pouzzner douzzer at mega dot nu --- Alas still there in 4.9.1 as bundled with Ubuntu 14.10.
[Bug target/65647] [5 Regression] GCC won't stop when compile for armv6-m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65647 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-02 CC||law at redhat dot com Assignee|unassigned at gcc dot gnu.org |vmakarov at redhat dot com Ever confirmed|0 |1 --- Comment #1 from Jeffrey A. Law law at redhat dot com --- The dumps would seem to indicate LRA is stuck in a loop trying to reload something.
[Bug target/65576] [5 Regression] ICE in gcc.c-torture/compile/pr33855.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65576 Alan Modra amodra at gmail dot com changed: What|Removed |Added URL||https://gcc.gnu.org/ml/gcc- ||patches/2015-04/msg00043.ht ||ml Assignee|meissner at gcc dot gnu.org|amodra at gmail dot com --- Comment #7 from Alan Modra amodra at gmail dot com --- Alternate patch posted
[Bug tree-optimization/65658] New: Jump threading too pessimistic when optimizing for size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65658
Bug ID: 65658
Summary: Jump threading too pessimistic when optimizing for
size
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: law at redhat dot com
Created attachment 35209
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35209action=edit
testcase, compile with -O2 -Wall note uninitialized warnings for SRA's
variables and trivially threadable block in setup()
The jump threader will cancel jump threads when optimizing for size and the
block will need to be duplicated. But that heuristic fails for something a
block like this:
# _36 = PHI 1(2), 1(4), 0(7)
# problem$l3_101 = PHI problem$l3_8(D)(2), problem$l3_8(D)(4),
problem$l3_35(7)
# problem$l4_100 = PHI problem$l4_124(D)(2), problem$l4_124(D)(4),
problem$l4_34(7)
amt ={v} {CLOBBER};
if (_36 != 0)
goto bb 25;
else
goto bb 9;
All incoming edges are threadable and the block produces no code. It's really
just a redirection block that's not recognized as such -- probably due to the
clobber statement.
The net result is we cancel the jump thread, get worse code and issue false
positive warnings for uninitialized variables. All around a lose.
[Bug target/65581] [5 Regression] testsuite lto issue: multiple definition of `main', undefined reference to `WinMain'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65581 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #8 from Jan Hubicka hubicka at gcc dot gnu.org --- Hmm, is it still a problem and if so, why it is marked as resolved/invalid? crtbegin/crtend should be compiled without LTO even with LTO bootstrap. Can you post the callgraph and resolution file created by compiling the testcase with --save-temps and -fdump-ipa-cgraph?
[Bug target/65576] [5 Regression] ICE in gcc.c-torture/compile/pr33855.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65576 --- Comment #6 from Alan Modra amodra at gmail dot com --- The patch does appear to fix the problem for non-power7, but introduces an ICE on power7 for pr33855.c. gcc.c-torture/compile/pr33855.c:27:1: error: unrecognizable insn: } ^ (insn 124 123 31 5 (set (mem:DF (plus:DI (reg/f:DI 31 31 [orig:161 D.2367 ] [161]) (const_int 24 [0x18])) [5 *_13+24 S8 A64]) (const_double:DF 0.0 [0x0.0p+0])) /src/gcc-virgin/gcc/testsuite/gcc.c-torture/compile/pr33855.c:20 -1 (nil))
[Bug ipa/65076] [5 Regression] 16% tramp3d-v4.cpp compile time regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076 --- Comment #52 from Jan Hubicka hubicka at gcc dot gnu.org --- $ time /aux/hubicka/trunk-install/bin/g++ -Ofast -fpermissive --param large-function-insns=1 tramp3d-v4.ii -w ; ./a.out -n 3 real0m34.232s user0m33.729s sys 0m0.532s i = 1t = 0.00209225 dt = 0.00209225 (0.0175509s/it) i = 2t = 0.00410537 dt = 0.00201312 (0.164169s/it) i = 3t = 0.00603889 dt = 0.00193352 (0.167095s/it) $ time /aux/hubicka/trunk-install/bin/g++ -Ofast -fpermissive --param large-function-insns=10 tramp3d-v4.ii -w ; ./a.out -n 3 real0m34.226s user0m33.749s sys 0m0.506s i = 1t = 0.00209225 dt = 0.00209225 (0.0187211s/it) i = 2t = 0.00410537 dt = 0.00201312 (0.177041s/it) i = 3t = 0.00603889 dt = 0.00193352 (0.181561s/it) $ time /aux/hubicka/trunk-install/bin/g++ -Ofast -fpermissive --param large-function-insns=100 tramp3d-v4.ii -w ; ./a.out -n 3 real0m34.012s user0m33.455s sys 0m0.586s i = 1t = 0.00209225 dt = 0.00209225 (0.0175891s/it) i = 2t = 0.00410537 dt = 0.00201312 (0.172188s/it) i = 3t = 0.00603889 dt = 0.00193352 (0.175776s/it) $ time /aux/hubicka/trunk-install/bin/g++ -Ofast -fpermissive --param large-function-insns=500 tramp3d-v4.ii -w ; ./a.out -n 3 real0m35.720s user0m35.252s sys 0m0.498s i = 1t = 0.00209225 dt = 0.00209225 (0.0190959s/it) i = 2t = 0.00410537 dt = 0.00201312 (0.147543s/it) i = 3t = 0.00603889 dt = 0.00193352 (0.151731s/it) $ time /aux/hubicka/trunk-install/bin/g++ -Ofast -fpermissive --param large-function-insns=2700 tramp3d-v4.ii -w ; ./a.out -n 3 real0m36.697s user0m36.192s sys 0m0.536s $ time /aux/hubicka/trunk-install/bin/g++ -Ofast -fpermissive --param large-function-insns=1000 tramp3d-v4.ii -w ; ./a.out -n 3 real0m36.369s user0m35.900s sys 0m0.500s i = 1t = 0.00209225 dt = 0.00209225 (0.00889301s/it) i = 2t = 0.00410537 dt = 0.00201312 (0.137394s/it) i = 3t = 0.00603889 dt = 0.00193352 (0.14172s/it) $ time /aux/hubicka/trunk-install/bin/g++ -Ofast -fpermissive --param large-function-insns=2700 tramp3d-v4.ii -w ; ./a.out -n 3 real0m36.730s user0m36.216s sys 0m0.546s i = 1t = 0.00209225 dt = 0.00209225 (0.0001s/it) i = 2t = 0.00410537 dt = 0.00201312 (0.134414s/it) i = 3t = 0.00603889 dt = 0.00193352 (0.137397s/it) $ time /aux/hubicka/trunk-install/bin/g++ -Ofast -fpermissive --param large-function-insns=1 tramp3d-v4.ii -w ; ./a.out -n 3 real0m37.722s user0m37.215s sys 0m0.539s i = 1t = 0.00209225 dt = 0.00209225 (0.00893092s/it) i = 2t = 0.00410537 dt = 0.00201312 (0.171207s/it) i = 3t = 0.00603889 dt = 0.00193352 (0.17444s/it) $ time /aux/hubicka/trunk-install/bin/g++ -Ofast -fpermissive --param large-function-insns=10 tramp3d-v4.ii -w ; ./a.out -n 3 real0m37.675s user0m37.147s sys 0m0.559s i = 1t = 0.00209225 dt = 0.00209225 (0.00888085s/it) i = 2t = 0.00410537 dt = 0.00201312 (0.169823s/it) i = 3t = 0.00603889 dt = 0.00193352 (0.173361s/it) So there seems to be 8% compile time performance drop somewhere in between 100 and 1000 of large-function-insns and the current default 2700 seems to sit in sweet spot of the performance (bellow 500 or above 1 starts dropping). The text segment size is 589645 for 1, 587750 for 2700, 591666 for 1000, 576922 for 500 GCC 4.9 seems happy with growth of 100 and drops a bit at growth of 30. It also delivers smaller binary at those growth settings (489406 bytes). So it seems to suggest that noticeable part of the remaining regression may be due to new heuristics prefferring large functions. I will experiment with re-adding the combined function size into the denomiator. But my first experiments does not look amazing.
[Bug target/65648] [5 Regression] Bad code due to IRA fails to recognize the clobber in parallel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65648 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added CC||law at redhat dot com Assignee|unassigned at gcc dot gnu.org |vmakarov at redhat dot com --- Comment #2 from Jeffrey A. Law law at redhat dot com --- Well, I think the real issue here is LRA deciding to move insn 12 regardless of whether or not the MD file gets a scratch register the recommend way or not. Note, the insns below are not consecutive in the .ira dump, had me rather confused for a few minutes.
[Bug target/65648] [5 Regression] Bad code due to IRA fails to recognize the clobber in parallel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65648 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-02 Ever confirmed|0 |1
[Bug c++/65646] [5 Regression] ICE in invalid syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65646 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed Apr 1 16:36:50 2015 New Revision: 221810 URL: https://gcc.gnu.org/viewcvs?rev=221810root=gccview=rev Log: PR c++/65646 * decl.c (grokvardecl): Don't call check_explicit_specialization for non-template members of a class template. Added: trunk/gcc/testsuite/g++.dg/template/static36.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c
[Bug sanitizer/65655] New: [5 Regression][UBSAN] ICE in speculative_call_info, at cgraph.c:1151
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65655 Bug ID: 65655 Summary: [5 Regression][UBSAN] ICE in speculative_call_info, at cgraph.c:1151 Product: gcc Version: 5.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org Created attachment 35206 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35206action=edit testcase.ii g++ -std=c++11 -fsanitize=undefined -O2 input.ii fails now with input.ii:49:1: internal compiler error: in speculative_call_info, at cgraph.c:1151 } ^ 0x92b9ae cgraph_edge::speculative_call_info(cgraph_edge*, cgraph_edge*, ipa_ref*) ../../gcc/cgraph.c:1151 0x92ba8c cgraph_edge::resolve_speculation(tree_node*) ../../gcc/cgraph.c:1166 0xb2c5a3 redirect_to_unreachable ../../gcc/ipa-inline-analysis.c:773 0xb2c5a3 edge_set_predicate ../../gcc/ipa-inline-analysis.c:797 0xb2e161 inline_edge_duplication_hook ../../gcc/ipa-inline-analysis.c:1325 0x92c403 symbol_table::call_edge_duplication_hooks(cgraph_edge*, cgraph_edge*) ../../gcc/cgraph.c:458 0x92c403 cgraph_edge::make_speculative(cgraph_node*, long, int) ../../gcc/cgraph.c:1085
[Bug ipa/65478] [5 regression] crafty performance regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478 --- Comment #23 from Jan Hubicka hubicka at ucw dot cz --- Seems to be a regression with -flto only? I also see EON regressing without -flto. Yes, the inlining is cross file. http://gcc.opensuse.org/SPEC/CINT/sb-megrez-head-64/index.html Saw that one too. It is in between Feb 10, 2015 18:20 UTC (Values: Base: 164.gzip: 1558, 175.vpr: 2392, 176.gcc: 2845, 181.mcf: 3766, 186.crafty: 2926, 197.parser: 1975, 252.eon: 3726, 255.vortex: 3305, 256.bzip2: 2218, 300.twolf: 3257 Peak: , 164.gzip: 1546, 175.vpr: 2397, 176.gcc: 1994, 181.mcf: 3819, 186.crafty: 2737, 197.parser: 1911, 252.eon: 4461, 255.vortex: 4364, 256.bzip2: 2348, 300.twolf: 3265) Feb 10, 2015 09:20 UTC (Values: Base: 164.gzip: 1549, 175.vpr: 2452, 176.gcc: 2734, 181.mcf: 3458, 186.crafty: 2833, 197.parser: 1962, 252.eon: 4083, 255.vortex: 3378, 256.bzip2: 2059, 300.twolf: 3231 Peak: , 164.gzip: 1555, 175.vpr: 2241, 176.gcc: 2800, 181.mcf: 3821, 186.crafty: 2681, 197.parser: 1905, 252.eon: 4415, 255.vortex: 4363, 256.bzip2: 2379, 300.twolf: 3220) So it does not seem to point to inliner changes (fortunately). At Megrez, you should be able to access the diff? Honza
[Bug ipa/65655] [5 Regression] ICE in speculative_call_info, at cgraph.c:1151
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65655 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Started with r221707 or r221706.
[Bug c++/65656] New: __builtin_constant_p should be constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65656
Bug ID: 65656
Summary: __builtin_constant_p should be constexpr
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: scovich at gmail dot com
Consider the following program compiled with `gcc -std=c++11'
= bug.cpp =
#include cstdio
int main(int argc, char *argv[]) {
constexpr bool x = __builtin_constant_p(argc);
std::printf(x=%d\n, x);
}
===
With optimizations disabled, it correctly treats __builtin_constant_p() as
constexpr and prints 0 as expected (because the value of argc is not a
compile-time constant).
With optimizations enabled (-O1 or higher), compilation fails:
bug.cpp: In function ‘int main(int, char**)’:
bug.cpp:3:48: error: ‘argc’ is not a constant expression
constexpr bool x = __builtin_constant_p(argc);
^
Clang 3.4 handles the case just fine.
While I can 100% understand that the return value of __builtin_constant_p()
might change depending on what information the optimizer has available, I'm
pretty sure __builtin_constant_p() should always return a value computable at
compile time.
NOTE: this issue is *NOT* the same as Bug #54021, in spite of the two sharing
the same title. The latter is mis-named: It actually requests support for
constant folding for ternary expressions involving __builtin_constant_p, even
when optimizations are disabled and such folding would not normally occur.
[Bug target/65657] New: [avr] read from __memx address space tramples argument to following function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65657
Bug ID: 65657
Summary: [avr] read from __memx address space tramples argument
to following function
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jonathan.creekm...@synapse-wireless.com
Created attachment 35207
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35207action=edit
Test snippet that exhibits the problem.
For an AVR target, the following code that reads from the __memx address space
results in the wrong code and tramples the handle variable:
extern void writeFlashByte(uint8_t byte, uint16_t handle);
void writeBuf(const uint8_t __memx *from, const uint8_t __memx *to)
{
uint16_t handle = ((uint16_t)(((__uint24)to) 0xUL));
writeFlashByte(*from++, handle++);
}
The relevant assembly code is as follows:
mov r27,r22# Move 'from' out of the way
mov r26,r23# Move 'from' out of the way
mov r21,r24# Move 'from' out of the way
mov r24,r20# Move 'to' into 'handle' for calling writeFlashByte
movw r22,r18 # Move 'to' into 'handle' for calling writeFlashByte
mov r30,r27# Put the relevant bits of 'from' into place to call __xload_1
mov r31,r26# Put the relevant bits of 'from' into place to call __xload_1
call __xload_1 # -- Returns into r22, corrupting the lower byte of 'handle'
mov r24,r22# Move the result of __xload_1 for calling writeFlashByte
jmp writeFlashByte
The line marked -- is where the badness occurs. Since __xload_1 returns into
r22, the 'handle' argument to writeFlashByte (which should be in r22 and r23),
gets its r22 portion corrupted by the value __xload_1.
PR target/52484 mentioned adding R22 to the register footprint for xload, but
that was targeted to 4.7.1, so I am not sure why this is failing in 4.8.1.
== compile ==
avr-gcc -save-temps -mmcu=atmega128rfa1 -Os -v -Wall -Wextra -c test.c
== configure ==
../src/configure -v --enable-languages=c,c++ --prefix=/usr/lib
--infodir=/usr/share/info --mandir=/usr/share/man --bindir=/usr/bin
--libexecdir=/usr/lib --libdir=/usr/lib --enable-shared --with-system-zlib
--enable-long-long --enable-nls --without-included-gettext --disable-libssp
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=avr
Thread model: single
gcc version 4.8.1 (GCC)
[Bug rtl-optimization/65628] valgrind error in improve_allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65628 --- Comment #2 from Vladimir Makarov vmakarov at gcc dot gnu.org --- (In reply to Markus Trippelsdorf from comment #1) Can you take a look Vladimir? There are also PR65629, PR65617 and PR65613, which might be dups. Hi, Markus. I've looked at these bugs. I can not get the same valdgrind messages as you wrote. But I get another one ==13149== Use of uninitialised value of size 8 ==13149==at 0xB6C7C7: process_bb_lives(basic_block_def*, int, bool) (lra-lives.c:936) ==13149==by 0xB6D9A2: lra_create_live_ranges_1(bool, bool) (lra-lives.c:1290) ==13149==by 0xB6E25F: lra_create_live_ranges(bool, bool) (lra-lives.c:1355) ==13149==by 0xB55087: lra(_IO_FILE*) (lra.c:2337) ==13149==by 0xB136A9: do_reload (ira.c:5418) ==13149==by 0xB136A9: (anonymous namespace)::pass_reload::execute(function*) (ira.c:5589) ==13149==by 0xBE5412: execute_one_pass(opt_pass*) (passes.c:2330) ==13149==by 0xBE5875: execute_pass_list_1(opt_pass*) (passes.c:2382) ==13149==by 0xBE5887: execute_pass_list_1(opt_pass*) (passes.c:2383) ==13149==by 0xBE58C8: execute_pass_list(function*, opt_pass*) (passes.c:2393) ==13149==by 0x8E2E4B: cgraph_node::expand() (cgraphunit.c:1878) ==13149==by 0x8E45F8: expand_all_functions (cgraphunit.c:2014) ==13149==by 0x8E45F8: symbol_table::compile() (cgraphunit.c:2367) ==13149==by 0x8E6137: symbol_table::finalize_compilation_unit() (cgraphunit.c:2444) == besides usual ones for sparseset code. There is no such message on the trunk dated by 20th March. Between March 20 and March 29 I submitted only one patch for PR65407. When I revert the patch, I still have the same above message. So I don't think it is RA fault. Intteresting thing about the above message is that there is a sparseset code nearby (2-3 lines away). The sparseset always generates code for valgrind because of its very specific code (a correct use of unitialized values). So I suspect, given message should be about sparseset actually but valgrind reports this about the code nearby because may be the GCC info fed to valgrind was changed somewehere between March 21 and 29. Although it is just my speculations.
[Bug c++/65646] [5 Regression] ICE in invalid syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65646 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jason Merrill jason at gcc dot gnu.org --- (In reply to Bernd Edlinger from comment #5) gcc/testsuite/ChangeLog missing? https://gcc.gnu.org/codingconventions.html#ChangeLogs There is no established convention on when ChangeLog entries are to be made for testsuite changes I prefer not to bother with the ChangeLog for tests.
[Bug sanitizer/65655] [5 Regression][UBSAN] ICE in speculative_call_info, at cgraph.c:1151
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65655 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-01 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |5.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed, bisecting.
[Bug rtl-optimization/65613] valgrind error in find_call_crossed_cheap_reg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65613 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |WORKSFORME --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- not reproducible, closing.
[Bug rtl-optimization/65617] new valgrind error in update_costs_from_copies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65617 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |WORKSFORME --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- not reproducible, closing.
[Bug rtl-optimization/65629] valgrind error in move_spill_restore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65629 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |WORKSFORME --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- not reproducible, closing.
[Bug rtl-optimization/65628] valgrind error in improve_allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65628 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #4 from Markus Trippelsdorf trippels at gcc dot gnu.org --- David, in the future please use an --enable-checking=valgrind compiler for valgrind testing. gcc uses VALGRIND_DISCARDs to avoid false positives.
[Bug c++/56100] spurious -Wshadow warning with local variable in template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56100 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org Target Milestone|--- |5.0 --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed for 5.0.
[Bug target/65576] [5 Regression] ICE in gcc.c-torture/compile/pr33855.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65576 Michael Meissner meissner at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |meissner at gcc dot gnu.org --- Comment #5 from Michael Meissner meissner at gcc dot gnu.org --- Created attachment 35208 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35208action=edit Proposed patch to fix the problem I haven't yet done a full bootstrap build/make check, but I believe this patch fixes the problem. The problem was for non-VSX systems, it still allowed 0.0 as the second argument for the DF-TF expand insn, and reload tried to use it. I rewrote it to only require register for pre-VSX systems.
[Bug c++/56100] spurious -Wshadow warning with local variable in template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56100 --- Comment #6 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Wed Apr 1 21:27:55 2015 New Revision: 221814 URL: https://gcc.gnu.org/viewcvs?rev=221814root=gccview=rev Log: /cp 2015-04-01 Paolo Carlini paolo.carl...@oracle.com PR c++/56100 * pt.c (instantiating_current_function_p): New. * name-lookup.c (pushdecl_maybe_friend_1): Use it. * cp-tree.h (instantiating_current_function_p): Declare. /testsuite 2015-04-01 Paolo Carlini paolo.carl...@oracle.com PR c++/56100 * g++.dg/warn/Wshadow-8.C: New. * g++.dg/warn/Wshadow-9.C: Likewise. * g++.dg/warn/Wshadow-10.C: Likewise. * g++.dg/warn/Wshadow-11.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/warn/Wshadow-10.C trunk/gcc/testsuite/g++.dg/warn/Wshadow-11.C trunk/gcc/testsuite/g++.dg/warn/Wshadow-8.C trunk/gcc/testsuite/g++.dg/warn/Wshadow-9.C Modified: trunk/gcc/cp/cp-tree.h trunk/gcc/cp/name-lookup.c trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug c++/65646] [5 Regression] ICE in invalid syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65646 --- Comment #5 from Bernd Edlinger bernd.edlinger at hotmail dot de --- gcc/testsuite/ChangeLog missing?
[Bug ipa/65655] [5 Regression] ICE in speculative_call_info, at cgraph.c:1151
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65655 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Keywords|ice-on-invalid-code |ice-on-valid-code Component|sanitizer |ipa Summary|[5 Regression][UBSAN] ICE |[5 Regression] ICE in |in speculative_call_info, |speculative_call_info, at |at cgraph.c:1151|cgraph.c:1151 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- But it ICEs even without -fsanitize=undefined, so likely an IPA issue. Also I don't see what's invalid in this testcase, it compiles OK with -O.
[Bug rtl-optimization/65628] valgrind error in improve_allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65628 --- Comment #3 from Markus Trippelsdorf trippels at gcc dot gnu.org --- OK, thanks. I also cannot reproduce them with today's gcc. I will build an --enable-checking=valgrind compiler and double check. If this turns up nothing I will close all these bugs.
[Bug target/65657] [avr] read from __memx address space tramples argument to following function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65657
--- Comment #1 from Jonathan Creekmore
jonathan.creekm...@synapse-wireless.com ---
Apparently, PR target/52484 covered one of the cases in avr.md, but not the
general case of a call to __xload_{1,2,3}. I think adding (clobber (reg:MOVMODE
22)) there as well might fix it.
[Bug c++/65625] [5 Regression] ICE in make_typename_type, at cp/decl.c:3499
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65625 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/65625] [5 Regression] ICE in make_typename_type, at cp/decl.c:3499
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65625 --- Comment #6 from Jason Merrill jason at gcc dot gnu.org --- (In reply to Richard Biener from comment #5) Not error-recovery - P1. I would think P2, since the testcase is ill-formed.
