[Bug rtl-optimization/67443] [5/6 regression] DSE removes required store instruction

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67443 --- Comment #22 from Richard Biener --- Author: rguenth Date: Mon Oct 26 15:24:45 2015 New Revision: 229372 URL: https://gcc.gnu.org/viewcvs?rev=229372=gcc=rev Log: 2015-10-26 Richard Biener Dominik Vogt

[Bug rtl-optimization/67443] [5/6 regression] DSE removes required store instruction

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67443 --- Comment #21 from Dominik Vogt --- Trying to write a test case for Power, I was unable to force the bug to show in the first place. Although I can force the addresses used into different registers, dead store elimination on power does not

[Bug rtl-optimization/67443] [5/6 regression] DSE removes required store instruction

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67443 --- Comment #16 from Richard Biener --- I see multiple issues with ao_ref_from_mem connected with MEM_OFFSET/MEM_SIZE. I don't remember exactly what was the issue with the promoted parameters but it may have been with ranges_overlap_p not

[Bug rtl-optimization/67443] [5/6 regression] DSE removes required store instruction

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67443 --- Comment #19 from Dominik Vogt --- This is a cleaner test case for s390/s390x. If there was a way to tell gcc "all registers except the first three argument registers are not available", the test should be fairly easy to convert to other

[Bug rtl-optimization/67443] [5/6 regression] DSE removes required store instruction

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67443 --- Comment #20 from Dominik Vogt --- Created attachment 36553 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36553=edit Dejagnu test case for s390/s390x.

[Bug rtl-optimization/67443] [5/6 regression] DSE removes required store instruction

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67443 --- Comment #18 from rguenther at suse dot de --- On Tue, 20 Oct 2015, vogt at linux dot vnet.ibm.com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67443 > > --- Comment #17 from Dominik Vogt --- > > So does [patch] fix the issue? >

[Bug rtl-optimization/67443] [5/6 regression] DSE removes required store instruction

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67443 --- Comment #17 from Dominik Vogt --- > So does [patch] fix the issue? Yes. The testsuite on 64-bit and 31-bit systems has no regressions with the patch either.

[Bug rtl-optimization/67443] [5/6 regression] DSE removes required store instruction

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67443 --- Comment #15 from Dominik Vogt --- The original problem was that a 4-byte load (or whatever) from memory M into an 8-byte-register on bigendian machines is represented by a memory reference of size 8 starting at M-4? This problem was present

[Bug rtl-optimization/67443] [5/6 regression] DSE removes required store instruction

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67443 --- Comment #14 from Dominik Vogt --- This is the thread discussing the patch that introduced the if-condition above to ao_ref_from_mem: https://gcc.gnu.org/ml/gcc-patches/2009-09/msg01638.html

[Bug rtl-optimization/67443] [5/6 regression] DSE removes required store instruction

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67443 --- Comment #13 from wmi at google dot com --- Use the extracted testcase vogt contributed. Here is some digging about why rtx_refs_may_alias_p returns noalias for the load and store: (gdb) c Continuing. Breakpoint 3, rtx_refs_may_alias_p

[Bug rtl-optimization/67443] [5/6 regression] DSE removes required store instruction

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67443 --- Comment #12 from wmi at google dot com --- Yes, I agree it is a problem that memrefs_conflict_p doesn't take effect. But I am still wondering even if memrefs_conflict_p doesn't take effect, the alias oracle query in rtx_refs_may_alias_p

[Bug rtl-optimization/67443] [5/6 regression] DSE removes required store instruction

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67443 --- Comment #10 from Dominik Vogt --- This is what's happening: Before the dse2 pass, there is a store instruction (25) followed by a read instruction later (29): --- # store first byte (insn 25 135 136 4 (set (mem/j:QI (reg/v/f:DI 2 %r2

[Bug rtl-optimization/67443] [5/6 regression] DSE removes required store instruction

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67443 --- Comment #11 from Dominik Vogt --- This is the bug report for the problem that the patch fixed: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64557

[Bug rtl-optimization/67443] [5/6 regression] DSE removes required store instruction

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67443 --- Comment #4 from Dominik Vogt --- Now this is the result of my efforts of reducing the original large test program to a minimum. --- struct s_t { unsigned f1: 8; unsigned f2: 24; }; bool foo(int a, int **pp, s_t **pps, void *s, int

[Bug rtl-optimization/67443] [5/6 regression] DSE removes required store instruction

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67443 --- Comment #5 from Dominik Vogt --- Created attachment 36509 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36509=edit test program and debug output test program and debug output

[Bug rtl-optimization/67443] [5/6 regression] DSE removes required store instruction

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67443 --- Comment #6 from wmi at google dot com --- (In reply to Dominik Vogt from comment #3) > I think the Rtl in comment 1 ist correct. Note that "i" is stored at > 0x.xx00 and "j" is stored at 0x.00xx. That is the > reason

[Bug rtl-optimization/67443] [5/6 regression] DSE removes required store instruction

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67443 Dominik Vogt changed: What|Removed |Added CC||vogt at linux dot vnet.ibm.com ---

[Bug rtl-optimization/67443] [5/6 regression] DSE removes required store instruction

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67443 --- Comment #7 from Dominik Vogt --- Almost. Note the strange bit numbering on s390. The highest order bit in any operation always has the number 0, and the lowest order bit has the highest number. So the 8-bit-move instruction "mvi" stores a

[Bug rtl-optimization/67443] [5/6 regression] DSE removes required store instruction

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67443 --- Comment #9 from Dominik Vogt --- > or %r1,%r2 # 32-bit or r1 := r1 | r2 -> 0xXX00 This should be or %r1,%r2 # 32-bit or r1 := r1

[Bug rtl-optimization/67443] [5/6 regression] DSE removes required store instruction

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67443 --- Comment #8 from Dominik Vogt --- Snippet of the assembly code from the test program posted in comment 4: good compiler: == # r1 is 0x**XX (XX = value to store in the f1 field) # r3 is the target address (ps) # r9 is

[Bug rtl-optimization/67443] [5/6 regression] DSE removes required store instruction

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67443 --- Comment #1 from wmi at google dot com --- Seems the patch makes some problem exposed. For the testcase 1.cxx below: typedef struct A { unsigned i : 8; unsigned j : 24; } A; void foo(A *a) { a->i = 3; a->j = 5; } The rtl generated

[Bug rtl-optimization/67443] [5/6 regression] DSE removes required store instruction

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67443 --- Comment #2 from wmi at google dot com --- Another problem is found in true_dependence_1 in alias.c. true_mem_addr or true_x_addr got after calling get_addr may be used as inputs of memrefs_conflict_p. However memrefs_conflict_p expects to use

[Bug rtl-optimization/67443] [5/6 regression] DSE removes required store instruction

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67443 Richard Biener changed: What|Removed |Added Target Milestone|--- |5.3 Summary|[5 regression]