[Bug tree-optimization/64992] More optimize opportunity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64992 --- Comment #3 from Ishiura Lab Compiler Team ishiura-compiler at ml dot kwansei.ac.jp --- Looking only from outside, the two programs are virtually equal, so we just wondered what hinders the optimization on one of the programs. The Optimization on opt.c seems very strong, so we think it would be nice if the same transformation would work on org.c.
[Bug target/64941] -O3 breaks tar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64941 --- Comment #7 from H.J. Lu hjl.tools at gmail dot com --- GCC 4.9.3 20150215 is OK.
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 --- Comment #17 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Created attachment 34765 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34765action=edit Handle KIND=1 and KIND=2 This updated patch gives a proposed way to handle KIND=1 and KIND=2. This is done by adding a new KIND=2 function in the library that accepts a fourth argument used to flag when a KIND=1 for any of the arguments. For KIND=1 rate is set to 1, max is set to 127, count rolls over after 127 to 0. For KIND=2 rate is set to 1000, max is 32767 THis is still in testing. I think we can handle the mixed integer and real situations using this fourth argument with different values to designate real KINDs that are encountered. You may notice that if we mix KIND=2 count and limit, with REAL(8) rate, the rate shows way too large. I am working on the mixed integer/real part. I have attached so others can review and comment. I will keep going with the mixed real/integer cases if no objections.
[Bug c/64768] [4.8/4.9/5 Regression] internal compiler error: tree check: expected tree that contains ‘decl with RTL’ structure, have ‘field_decl’ in set_decl_rtl, at emit-rtl.c:1274
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64768 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed for GCC 5.
[Bug c/65040] [5 Regression] gcc-5 -Wformat broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65040 --- Comment #10 from Marek Polacek mpolacek at gcc dot gnu.org --- That's because on your architecture char is signed by default. Try adding unsigned or using -funsigned-char and the warning should be gone.
[Bug fortran/64927] [4.8 Regression] Surprising error with -Wsurprising (-Wall) and TRANSFER + C_ASSOCIATED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64927 --- Comment #12 from Dominique d'Humieres dominiq at lps dot ens.fr --- I pulled yesterday's 4.8 snapshot, bootstrapped it to verify that the problem still existed, and applied the 1-liner from r198000. It does not fix the issue. Confirmed, for the record, testing results at https://gcc.gnu.org/ml/gcc-testresults/2015-02/msg01669.html Anyway, thanks for suggesting to try this one. Don't waste your time. I am leaving this PR in the WAITING state since the issue may be latent in 4.9 and above.
[Bug tree-optimization/65063] New: gcc.dg/vect/vect-double-reduc-6.c FAILs with -O3 -fno-tree-loop-ivcanon -fno-tree-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65063
Bug ID: 65063
Summary: gcc.dg/vect/vect-double-reduc-6.c FAILs with -O3
-fno-tree-loop-ivcanon -fno-tree-vectorize
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Created attachment 34754
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34754action=edit
reduced testcase
Output (on reduced testcase):
$ gcc -Wall -W testcase.c -O3 -fno-tree-loop-ivcanon -fno-tree-vectorize
$ ./a.out
Aborted
The assembly code shows:
...
movDWORD PTR out[rip], 0# out,
movDWORD PTR out[rip+4], 16# out,
movDWORD PTR out[rip+8], 256# out,
movDWORD PTR out[rip+12], 16384# out,
callabort#
out[] = {0, 16, 256, 16384}
but should be
out[] = {0, 16, 256, 4096}
(gdb) p in
$1 = {{0, 0, 0, 0}, {1, 1, 1, 1}, {1, 1, 1, 1}, {1, 1, 1, 1}, {2, 2, 2, 2}, {2,
2, 2, 2}, {2, 2, 2, 2}, {3, 3, 3, 3}}
(gdb) p out
$2 = {0, 16, 256, 16384}
in[] looks fine, also in the assembly
The first dump where 16384 appears is 191r.cse1. This might be the same as
PR63593.
Tested revisions:
r220676 - fail
[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #37 from Dominique d'Humieres dominiq at lps dot ens.fr ---
[...]
if (D.3430.chars.data != 0B)
{
__builtin_free ((void *) D.3430.chars.data);
}
D.3430.chars.data = 0B;
D.3430.chars.data is freed.
So every iteration of the do loop has the side-effect of freeing
prt_in.chars.data.
Could you please give me a pointer to the code emitting this side-effect?
[Bug c/64768] [4.8/4.9/5 Regression] internal compiler error: tree check: expected tree that contains ‘decl with RTL’ structure, have ‘field_decl’ in set_decl_rtl, at emit-rtl.c:1274
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64768 --- Comment #8 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Sat Feb 14 11:25:19 2015 New Revision: 220708 URL: https://gcc.gnu.org/viewcvs?rev=220708root=gccview=rev Log: PR c/64768 * c-decl.c (grokdeclarator): Set the range of a flexible array member declared through a typedef name. * gcc.dg/array-11.c: New test. * gcc.dg/array-12.c: New test. * gcc.dg/array-13.c: New test. * gcc.dg/array-14.c: New test. * gcc.dg/c99-flex-array-typedef-1.c: New test. * gcc.dg/c99-flex-array-typedef-2.c: New test. * gcc.dg/c99-flex-array-typedef-3.c: New test. * gcc.dg/c99-flex-array-typedef-5.c: New test. * gcc.dg/c99-flex-array-typedef-7.c: New test. * gcc.dg/c99-flex-array-typedef-8.c: New test. Added: trunk/gcc/testsuite/gcc.dg/array-11.c trunk/gcc/testsuite/gcc.dg/array-12.c trunk/gcc/testsuite/gcc.dg/array-13.c trunk/gcc/testsuite/gcc.dg/array-14.c trunk/gcc/testsuite/gcc.dg/c99-flex-array-typedef-1.c trunk/gcc/testsuite/gcc.dg/c99-flex-array-typedef-2.c trunk/gcc/testsuite/gcc.dg/c99-flex-array-typedef-3.c trunk/gcc/testsuite/gcc.dg/c99-flex-array-typedef-5.c trunk/gcc/testsuite/gcc.dg/c99-flex-array-typedef-7.c trunk/gcc/testsuite/gcc.dg/c99-flex-array-typedef-8.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-decl.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #38 from Mikael Morin mikael at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #37)
[...]
if (D.3430.chars.data != 0B)
{
__builtin_free ((void *) D.3430.chars.data);
}
D.3430.chars.data = 0B;
D.3430.chars.data is freed.
So every iteration of the do loop has the side-effect of freeing
prt_in.chars.data.
Could you please give me a pointer to the code emitting this side-effect?
The code you quoted (the call to free) comes from:
#0 gfc_deallocate_with_status at fortran/trans.c:1279
#1 gfc_trans_dealloc_allocated at fortran/trans-array.c:7428
#2 structure_alloc_comps at fortran/trans-array.c:7760
#3 gfc_deallocate_alloc_comp at fortran/trans-array.c:8060
#4 gfc_conv_expr_reference at fortran/trans-expr.c:7139
#5 gfc_conv_procedure_call at fortran/trans-expr.c:4360
#6 gfc_conv_function_expr at fortran/trans-expr.c:6974
#8 gfc_trans_assignment_1 at /fortran/trans-expr.c:8710
#9 trans_code at fortran/trans.c:1650
#10 gfc_trans_code_cond at fortran/trans.c:1946
#11 gfc_trans_simple_do at fortran/trans-stmt.c:1540
#12 gfc_trans_do at fortran/trans-stmt.c:1703
#13 trans_code at fortran/trans.c:1759
#14 gfc_trans_code at fortran/trans.c:1954
#15 gfc_generate_function_code at fortran/trans-decl.c:5842
#16 gfc_generate_code at fortran/trans.c:1971
#17 translate_all_program_units at fortran/parse.c:5341
#18 gfc_parse_file at fortran/parse.c:5538
#19 gfc_be_parse_file at fortran/f95-lang.c:228
#20 compile_file at toplev.c:594
#21 do_compile at toplev.c:2066
#22 toplev::main at toplev.c:2164
#23 main at main.c:39
However, it's not clear to me where the bug comes from, or at least where the
fix should go.
It's an artefact of temporary management which on one hand avoids deep copies,
but on the other hand frees allocated components as for a regular object, as if
a deep copy had happened before.
By the way, I'm not sure that it's at all correct to avoid deep copies.
[Bug c/65040] [5 Regression] gcc-5 -Wformat broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65040
--- Comment #9 from Jiri Slaby jirislaby at gmail dot com ---
What about this?
#include stdio.h
void x(char *ch)
{
printf(%x\n, ch[10]);
}
It still produces the warning. (I cannot reopen as I am not a reporter.)
[Bug fortran/59765] [4.9/5 Regression] [OOP] ICE on valid with finalizable array components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59765 --- Comment #18 from Dominique d'Humieres dominiq at lps dot ens.fr --- I think this PR is now fixed by r220654 for trunk (5.0) and r220659 (4.9).
[Bug c/65040] [5 Regression] gcc-5 -Wformat broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65040 --- Comment #12 from Jiri Slaby jirislaby at gmail dot com --- (In reply to Marek Polacek from comment #10) That's because on your architecture char is signed by default. Try adding unsigned or using -funsigned-char and the warning should be gone. Ok, I wanted to make sure, that the format string is really wrong here. It should be %hhx. Ouch, that will be pain to fix all those 400 bad format strings in grub2, given they use Werror WFormat :D.
[Bug c/65040] [5 Regression] gcc-5 -Wformat broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65040 --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org --- -funsigned-char is an option that shouldn't be used without serious consideration. That said, I think in that case the warning is intentional, you are indeed passing a signed value to unsigned format. If you don't care about that, don't use -Wformat=2 or use -Wno-format-signedness.
[Bug ipa/64963] [5 Regression] IPA Cloning/Splitting does not copy function section attributes resulting in kernel miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64963 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug tree-optimization/62209] [5 Regression] ICE with LTO on valid code on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62209 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
[Bug fortran/64980] [5 Regression] ICE in trans-expr.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64980 --- Comment #11 from Mikael Morin mikael at gcc dot gnu.org --- Created attachment 34755 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34755action=edit Another proposed fix (In reply to Bernd Edlinger from comment #10) Yes, but I have no idea how to know how the result is going to be used, in gfc_conv_procedure_call, line 4544. If you have an idea how to detect this case, that would be great. It is used as argument to the procedure, and also added to the interface mapping mechanism through gfc_add_interface_mapping. From there, it is dropped if the resulting size can be determined by other means; otherwised it is used to set the array result bounds. The attached patch (untested so far) makes a copy of the reference before passing it through VIEW_CONVERT_EXPR. It avoids the second V_C_E at least. Until yesterday, I thought the result is always used in a procedure call context, and I thought we only have aliasing violations on different variations of the same principal class, but that was also wrong. What I don't understand is why there isn't something alike needed for non-class arrays? They also use different variations of the same principal class, don't they?
[Bug fortran/64980] [5 Regression] ICE in trans-expr.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64980 --- Comment #12 from Dominique d'Humieres dominiq at lps dot ens.fr --- With any of the patches the first test for pr64230 fails at run time with At line 35 of file pr64230.f90 Fortran runtime error: Attempt to DEALLOCATE unallocated 't' but the test gfortran.dg/class_allocate_18.f90 succeeds. In addition Bernd's patch fixes/hides the ICE for pr61960.
[Bug fortran/60898] [4.8/4.9/5 Regression] model compile error with gfortran 4.7 and gcc 4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60898 --- Comment #18 from Mikael Morin mikael at gcc dot gnu.org --- Created attachment 34756 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34756action=edit patch fixing comment #7 (In reply to Mikael Morin from comment #17) Using Tobias' analysis in comment #14, there is an obvious fix, augmenting the reference count of the symbols present in the vector (untested): This is not enough. There is some code in resolve_symbol that reassigns some this_symtree-n.sym, and may call gfc_release_symbol. The problem being there is no check that this_symtree-n.sym == sym, so that we may apply gfc_free_symbol to something that remains reachable through this_symtree-n.sym.
[Bug fortran/60898] [4.8/4.9/5 Regression] model compile error with gfortran 4.7 and gcc 4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60898 --- Comment #19 from Dominique d'Humieres dominiq at lps dot ens.fr --- patch fixing comment #7 Confirmed, but it doesn't fix the test in comment 2 (with the addition in comment 10).
[Bug target/64941] -O3 breaks tar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64941 Mikael Pettersson mikpelinux at gmail dot com changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #4 from Mikael Pettersson mikpelinux at gmail dot com --- I can't reproduce on Ivy Bridge, but the OP's machine is Haswell so -march=native -mtune=native may cause different behaviour there. Could someone try this on Haswell?
[Bug fortran/64980] [5 Regression] ICE in trans-expr.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64980 --- Comment #13 from Mikael Morin mikael at gcc dot gnu.org --- Created attachment 34757 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34757action=edit Yet another attempt using TYPE_CANONICAL this tries to remove any use of VIEW_CONVERT_EXPR by setting (well, trying to set) the same TYPE_CANONICAL for the different class containers. And hope the middle-end is satisfied with that.
[Bug fortran/64980] [5 Regression] ICE in trans-expr.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64980 --- Comment #14 from Mikael Morin mikael at gcc dot gnu.org --- Bernd, do you have a reliable way to test a patch, checking for aliasing violations?
[Bug fortran/60898] [4.8/4.9/5 Regression] model compile error with gfortran 4.7 and gcc 4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60898 --- Comment #20 from Mikael Morin mikael at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #19) patch fixing comment #7 Confirmed, but it doesn't fix the test in comment 2 (with the addition in comment 10). Confirmed; for some reason it works with the resolve.c part alone.
[Bug fortran/64927] [4.8 Regression] Surprising error with -Wsurprising (-Wall) and TRANSFER + C_ASSOCIATED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64927 --- Comment #13 from Dominique d'Humieres dominiq at lps dot ens.fr --- Bisecting the range given in comment 4 shows that this PR is fixed by r198155 for 4.9. The fix was supposed to be back ported to 4.8 by r198345. However comparing the logs shows no entry for gcc/fortran/simplify.c in r198345.
[Bug target/64793] [SH] missed delay slot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64793 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added CC||kkojima at gcc dot gnu.org --- Comment #1 from Oleg Endo olegendo at gcc dot gnu.org --- This is caused by the fake annulled conditional true branches. Applying this: Index: gcc/config/sh/sh.md === --- gcc/config/sh/sh.md(revision 220708) +++ gcc/config/sh/sh.md(working copy) @@ -593,20 +593,9 @@ [(and (eq_attr in_delay_slot yes) (eq_attr type !pstore,prget)) (nil) (nil)]) -;; Say that we have annulled true branches, since this gives smaller and -;; faster code when branches are predicted as not taken. - -;; ??? The non-annulled condition should really be in_delay_slot, -;; but insns that can be filled in non-annulled get priority over insns -;; that can only be filled in anulled. - (define_delay - (and (eq_attr type cbranch) - (match_test TARGET_SH2)) - ;; SH2e has a hardware bug that pretty much prohibits the use of - ;; annulled delay slots. - [(eq_attr cond_delay_slot yes) (and (eq_attr cond_delay_slot yes) - (not (eq_attr cpu sh2e))) (nil)]) + (and (eq_attr type cbranch) (match_test TARGET_SH2)) + [(eq_attr cond_delay_slot yes) (nil) (nil)]) ;; - ;; SImode signed integer comparisons results in the expected code: mov r5,r0 mov.b @(r0,r4),r1 mov r1,r0 cmp/eq #92,r0 bt .L3 rts mov r7,r0 .align 1 .L3: rts mov r6,r0 The downside is that code size increases on average. CSiBE shows a total increase 3371399 - 3372451+1052 / +0.031204 % even though there are also individual code size decreases. It also seems that this catches more missed cases of cbranches with delay slot: blocksort.c (fallbackSort): before: .L275: cmp/pl r3 bf .L23 mov.l @(28,r15),r4 mov #0,r0 mov.l @(16,r15),r2 after: .L275: cmp/pl r3 bf/s.L23 mov #0,r0 mov.l @(28,r15),r4 mov.l @(16,r15),r2 The code size increase is caused by duplicated insns such as: before: bf .L315 ... bf .L315 ... bf .L315 ... .L315: cmp/hi r13,r12 bra .L308 movtr0 after: bf/s.L322 cmp/hi r13,r12 ... bf/s.L322 cmp/hi r13,r12 ... bf/s.L322 cmp/hi r13,r12 ... .L322: bra .L307 movtr0 In a similar way, the builtin strcmp code results in sequences such as: bt/s.L67 sett mov.b @r1+,r2 tst r2,r2 bt/s.L67 sett The sh_optimize_sett_clrt pass does not eliminate the sett insn because T is not the same value in all paths and thus it gets copied into the delay slots. There's an old comment from r9888 ;; Say that we have annulled true branches, since this gives smaller and ;; faster code when branches are predicted as not taken. I don't know what this comment is based on. Branch prediction was added on SH4A, which was long time after that comment. Maybe it refers to the fact that conditional branches are faster on SH when they are not taken. Public SH2 documentation states that (bf/s, bt/s) are 2 cycles and (bt, bf) are 3 cycles. In both cases the branch insns take 1 cycle if they don't branch. Looking at other documentation (ST40-300, SH4A), it seems that using the delay-slot variants has a higher chance of executing the branch and delay-slot insn in parallel. Kaz, if you have some time, could you please do a CSiBE runtime comparison with/without the patch above? I'm tempted to apply the patch above and drop the fake annulled delay slot insns.
[Bug tree-optimization/65063] [4.8/4.9/5 Regression] gcc.dg/vect/vect-double-reduc-6.c FAILs with -O3 -fno-tree-loop-ivcanon -fno-tree-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65063 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-14 CC||jakub at gcc dot gnu.org Target Milestone|--- |4.8.5 Summary|gcc.dg/vect/vect-double-red |[4.8/4.9/5 Regression] |uc-6.c FAILs with -O3 |gcc.dg/vect/vect-double-red |-fno-tree-loop-ivcanon |uc-6.c FAILs with -O3 |-fno-tree-vectorize |-fno-tree-loop-ivcanon ||-fno-tree-vectorize Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- r134653 works, r134746 ICEs, r213809 still ICEs, r213810 is miscompiled.
[Bug rtl-optimization/65064] New: [5.0 regression] FAIL: gcc.dg/torture/pr60115.c -O1 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65064 Bug ID: 65064 Summary: [5.0 regression] FAIL: gcc.dg/torture/pr60115.c -O1 (test for excess errors) Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: sch...@linux-m68k.org CC: hjl at gcc dot gnu.org, rth at gcc dot gnu.org Target: ia64-*-* $ gcc/xgcc -B gcc/ ../gcc/testsuite/gcc.dg/torture/pr60115.c -O /usr/ia64-suse-linux/bin/ld: a.out: __gp does not cover short data segment collect2: error: ld returned 1 exit status Broken by r220674. --- gcc-20150213/Build/pr60115.s2015-02-14 21:36:37.0 +0100 +++ gcc-20150214/Build/pr60115.s2015-02-14 21:35:30.0 +0100 @@ -7,22 +7,20 @@ .proc main# main: .prologue - .save ar.lc, r3 - mov r3 = ar.lc + .save ar.lc, r2 + mov r2 = ar.lc .body [.L2:] - addl r14 = @ltoffx(a#), r1 - ;; - ld8.mov r14 = [r14], a# + addl r14 = @gprel(a#), gp ;; ld4 r14 = [r14] ;; cmp4.eq p6, p7 = 0, r14 - addl r2 = @ltoffx(b#), r1 + addl r16 = @ltoffx(b#+32768), r1 ;; - ld8.mov r2 = [r2], b# + ld8.mov r16 = [r16], b#+32768 ;; - addl r16 = 4, r2 + adds r16 = 7232, r16 .L4: .pred.rel.mutex p6, p7 (p6) br.cond.dpnt .L3 @@ -40,17 +38,15 @@ adds r14 = -1, r14 ;; br.cloop.sptk.few .L6 - addl r14 = @ltoffx(a#), r1 - ;; - ld8.mov r14 = [r14], a# + addl r14 = @gprel(a#), gp ;; st4 [r14] = r0 .L3: mov r8 = r0 - mov ar.lc = r3 + mov ar.lc = r2 br.ret.sptk.many b0 ;; .endp main# .common b#,8,4 .common a#,4,4 - .ident GCC: (GNU) 5.0.0 20150213 (experimental) [trunk revision 220673] + .ident GCC: (GNU) 5.0.0 20150214 (experimental) [trunk revision 220705]
[Bug target/64941] -O3 breaks tar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64941 --- Comment #5 from Brian M brian at soulspark dot org --- I can give someone a KDE desktop to the actual machine to reproduce the failure if you like.
[Bug fortran/64980] [5 Regression] ICE in trans-expr.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64980 --- Comment #15 from Bernd Edlinger bernd.edlinger at hotmail dot de --- Created attachment 34758 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34758action=edit Updated patch that also fixes pr64230.f90 (In reply to Dominique d'Humieres from comment #12) With any of the patches the first test for pr64230 fails at run time with At line 35 of file pr64230.f90 Fortran runtime error: Attempt to DEALLOCATE unallocated 't' but the test gfortran.dg/class_allocate_18.f90 succeeds. In addition Bernd's patch fixes/hides the ICE for pr61960. I think this updated patch fixes all mentioned test cases. Especially pr64230.f90. In this example the condition CLASS_DATA (fsym) != CLASS_DATA (e) evaluates to TRUE, but fsym-ts.u.derived-name and e-ts.u.derived-name are the same, something like __class_m_T4_a. But s from pr64230.f90 has an intent(out) parameter. Entering this code path for an intent(out) parameter means complete disaster, because it does only copy the value to the destination and not in the reverse direction. Hopefully these types are really identical also for the back end...
[Bug bootstrap/65065] New: ICE with -O3 -floop-block on bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65065 Bug ID: 65065 Summary: ICE with -O3 -floop-block on bootstrap Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: hete2 at gmx dot de On my System (Ubuntu14.04 on an Intel Sandy-bridge configuering gcc-5-20150208 with ../configure --disable-werror and bootstraping with: make BOOT_CFLAGS='-O3 -floop-block -pipe' bootstrap gave the following error: /home/hete/neugcc/gcc-5-20150208/Build1/./prev-gcc/xg++ -B/home/hete/neugcc/gcc-5-20150208/Build1/./prev-gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -nostdinc++ -B/home/hete/ neugcc/gcc-5-20150208/Build1/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/home/hete/neugcc/gcc-5-20150208/Build1/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/. libs -I/home/hete/neugcc/gcc-5-20150208/Build1/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/home/hete/neugcc/gcc-5-20150208/Build1/prev-x86_64 -unknown-linux-gnu/libstdc++-v3/include -I/home/hete/neugcc/gcc-5-20150208/libstdc++-v3/libsupc++ -L/home/hete/neugcc/gcc-5-20150208/Build1/prev-x86_64-unknown-linux-gnu/libstdc ++-v3/src/.libs -L/home/hete/neugcc/gcc-5-20150208/Build1/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -c -O3 -floop-block -pipe -gtoggle -DIN_GCC-fno-excepti ons -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-varia dic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include -I../../gcc/../libdecnumbe r -I../../gcc/../libdecnumber/bid -I../libdecnumber -I../../gcc/../libbacktrace -o omega.o -MT omega.o -MMD -MP -MF ./.deps/omega.TPo ../../gcc/omega.c ../isl_constraint.c:558: expecting integer value ../../gcc/omega.c: In Funktion »int omega_add_new_wild_card(omega_pb)«: ../../gcc/omega.c:758:1: interner Compiler-Fehler: Abgebrochen omega_add_new_wild_card (omega_pb pb) ^ 0xfa1da2 crash_signal ../../gcc/toplev.c:383 0x18f5833 build_linearized_memory_access ../../gcc/graphite-interchange.c:128 0x18f596b pdr_stride_in_loop ../../gcc/graphite-interchange.c:214 0x18f5ccf memory_strides_in_loop_1 ../../gcc/graphite-interchange.c:300 0x18f5dd2 memory_strides_in_loop ../../gcc/graphite-interchange.c:319 0x18f5e48 lst_interchange_profitable_p ../../gcc/graphite-interchange.c:417 0x18f6331 lst_try_interchange_loops ../../gcc/graphite-interchange.c:554 0x18f6558 lst_interchange_select_inner ../../gcc/graphite-interchange.c:617 0x18f6642 lst_interchange_select_outer ../../gcc/graphite-interchange.c:643 0x18f667b lst_interchange_select_outer ../../gcc/graphite-interchange.c:653 0x18f66cc scop_do_interchange(scop*) ../../gcc/graphite-interchange.c:665 0x18f49c9 scop_do_block(scop*) ../../gcc/graphite-blocking.c:278 0x1817f66 apply_poly_transforms(scop*) ../../gcc/graphite-poly.c:272 0x1811a30 graphite_transform_loops() ../../gcc/graphite.c:309 0x1811ad7 graphite_transforms ../../gcc/graphite.c:338 0x1811c21 execute ../../gcc/graphite.c:419 Bitte senden Sie einen vollständigen Fehlerbericht auf Englisch ein; bearbeiten Sie die Quellen zunächst mit einem Präprozessor, wenn es dienlich ist. Please include the complete backtrace with any bug report. Siehe http://gcc.gnu.org/bugs.html für nähere Anweisungen. make[3]: *** [omega.o] Fehler 1 make[3]: Verlasse Verzeichnis '/home/hete/neugcc/gcc-5-20150208/Build1/gcc' make[2]: *** [all-stage2-gcc] Fehler 2 make[2]: Verlasse Verzeichnis '/home/hete/neugcc/gcc-5-20150208/Build1' make[1]: *** [stage2-bubble] Fehler 2 make[1]: Verlasse Verzeichnis '/home/hete/neugcc/gcc-5-20150208/Build1'
[Bug testsuite/64850] FAIL: gfortran.dg/goacc/acc_on_device-1.f95 -O scan-rtl-dump-times expand \\(call [^\\n]*\\acc_on_device 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64850 --- Comment #2 from Kazumoto Kojima kkojima at gcc dot gnu.org --- Author: kkojima Date: Sat Feb 14 23:50:25 2015 New Revision: 220711 URL: https://gcc.gnu.org/viewcvs?rev=220711root=gccview=rev Log: PR testsuite/64850 Tweak acc_on_device* tests. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/goacc/acc_on_device-2-off.c trunk/gcc/testsuite/c-c++-common/goacc/acc_on_device-2.c trunk/gcc/testsuite/gcc.dg/goacc/acc_on_device-1.c trunk/gcc/testsuite/gfortran.dg/goacc/acc_on_device-1.f95 trunk/gcc/testsuite/gfortran.dg/goacc/acc_on_device-2-off.f95 trunk/gcc/testsuite/gfortran.dg/goacc/acc_on_device-2.f95
[Bug fortran/64927] [4.8 Regression] Surprising error with -Wsurprising (-Wall) and TRANSFER + C_ASSOCIATED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64927 --- Comment #14 from Dominique d'Humieres dominiq at lps dot ens.fr --- The reason why the changes for gcc/fortran/simplify.c on 4.9 have not been applied to 4.8 is that these changes apply to procs introduced on 4.9 at r197159, but not on 4.8. AFAICT these changes are needed to fix this PR and I did not find a simple way to fix this PR for 4.8. Since 4.8 will be history in a couple of months, I don't think fixing this PR for 4.8 is worth the work.
[Bug target/64941] -O3 breaks tar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64941 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-15 CC||areg.melikadamyan at gmail dot com Ever confirmed|0 |1 --- Comment #6 from H.J. Lu hjl.tools at gmail dot com --- Reproduced on Fedora/20 Haswell with gcc-4.8.3-7.fc20.x86_64
[Bug rtl-optimization/65064] [5.0 regression] FAIL: gcc.dg/torture/pr60115.c -O1 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65064 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-02-15 Ever confirmed|0 |1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com --- Can you provide all glibc input files to ld, including crt*.o, ld-linux-ia64.so.2, libc.so, ..., so that I can reproduce it with a cross linker on Linux/x86-64?
[Bug rtl-optimization/65064] [5.0 regression] FAIL: gcc.dg/torture/pr60115.c -O1 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65064 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com --- Does -fno-common fix the problem? If it is the case, we need to treat common symbol differently for ia64 since .commonb#,8,4 .commona#,4,4 won't be placed in small data section reachable via GP reloc. The problem for ia64 is even if a data symbol is defined locally, we can't use GP reloc if it isn't placed in small data section.
[Bug rtl-optimization/65064] [5.0 regression] FAIL: gcc.dg/torture/pr60115.c -O1 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65064 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com --- Created attachment 34759 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34759action=edit A patch Please try this.
[Bug target/64793] [SH] missed delay slot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64793 --- Comment #2 from Kazumoto Kojima kkojima at gcc dot gnu.org --- Created attachment 34760 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34760action=edit CSiBE result-runtime.csv revision 220636 with -O2
[Bug target/64793] [SH] missed delay slot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64793 --- Comment #3 from Kazumoto Kojima kkojima at gcc dot gnu.org --- Created attachment 34761 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34761action=edit CSiBE result-runtime.csv revision 220636 + patch C#1 with -O2
[Bug tree-optimization/62209] [5 Regression] ICE with LTO on valid code on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62209 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Sat Feb 14 08:23:18 2015 New Revision: 220706 URL: https://gcc.gnu.org/viewcvs?rev=220706root=gccview=rev Log: PR tree-optimization/62209 * tree-ssa-reassoc.c (update_range_test): If stmt is a PHI and op == range-exp, insert seq and gimplified code after labels instead of after the phi. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-reassoc.c
[Bug bootstrap/64976] Bootstrap fails with -O3 -fgraphite-identity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64976 --- Comment #2 from hete2 at gmx dot de --- Thank you for this hint. Using this configure option the boootstrapping works. Therefore this report can be renamed to a false warning about -Werror=maybe-uninitialized (if this is considered a Bug) or get closed.
[Bug target/54829] bad optimization: sub followed by cmp w/ zero (x86 ARM)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54829
--- Comment #9 from Daniel Santos daniel.santos at pobox dot com ---
I appologize for my late response.
(In reply to Richard Earnshaw from comment #8)
Unfortunately, computers don't to infinite precision arithmetic by default.
That would perform a different comparison in that it checks that r0 r1,
not whether r0 - r1 0. The difference, for signed comparisons, is when
overflow occurs.
Consider the case where (in your original code) a has the value INT_MIN (ie
-2147483648) and b has the value 1.
Now clearly a b and by the normal rules of arithmetic (infinite precision)
we would expect a - b to be less than zero.
However, INT_MIN - 1 cannot be represented in a 32-bit long value and
becomes INT_MAX due to overflow; the result is that for these values a - b
0!
On ARM and x86, the flag setting that results from a subtract operation is,
in effect a comparison of the original operands, rather than a comparison of
the result; that is on ARM
subs rd, rn, rm
is equivalent to
cmp rn, rm
except that the register rd is not written by the comparison.
Power PC is different: it's subtract and compare instruction really does use
the result of the subtraction to form the comparison.
Thank you very much for your work on this. In re-examining, I'm suspecting that
this may be an invalid bug. :( I have modified the test program slightly:
extern print_gt(void);
extern print_lt(void);
extern print_eq(void);
void cmp_and_branch(long a, long b)
{
long diff = a b ? 1 : (a b ? -1 : 0);
if (diff 0) {
print_gt();
} else if (diff 0) {
print_lt();
} else {
print_eq();
}
}
I thought that I had originally tried this and gotten worse results (although
the diff was being done via a complicated -findirect-inline situation), but
this version of the program leaves a finite number of options. When compiled on
x86_64 and ARM, both are flawless:
ARM
cmp_and_branch:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
cmp r0, r1
bgt .L2
blt .L5
b print_eq
.L2:
b print_gt
.L5:
b print_lt
.size cmp_and_branch, .-cmp_and_branch
.ident GCC: (Gentoo 4.8.3 p1.1, pie-0.5.9) 4.8.3
.section.note.GNU-stack,,%progbits
x86_64
cmp_and_branch:
.LFB0:
.cfi_startproc
cmpq%rsi, %rdi
jg .L2
jl .L5
jmp print_eq
.p2align 4,,10
.p2align 3
.L2:
jmp print_gt
.p2align 4,,10
.p2align 3
.L5:
jmp print_lt
.cfi_endproc
I don't want to close this bug just yet, I want to reset in my other code. This
will certainly help clean up some of my code!!
[Bug middle-end/65041] Improve -Wclobbered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65041 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- I think the setting of fd to -1 is removed which is why there is no warning.
[Bug java/64917] Remove spurious '^L' from libjava/libltdl/COPYING.LIB.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64917 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- Control-L is a legal new page marker. Control-L should be treated as an white space character for the automated license scanning tools. As mentioned this is pulled from upstream so please file this bug there first.
