public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "jingyu at google dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/42691] New: Wrong REG_EQUAL note is added to SUBREG node Date: Mon, 11 Jan 2010 19:45:00 -0000 [thread overview] Message-ID: <bug-42691-17567@http.gcc.gnu.org/bugzilla/> (raw) A wrong REG_EQUAL is attached to SUBREG during forward propagation. Before fwprop1 (insn 56 55 57 3 double.cpp:12 (set (reg/v:DI 180 [ _D_inf ]) (const_int 0 [0x0])) 164 {*thumb1_movdi_insn} (nil)) (insn 60 59 61 3 double.cpp:12 (set (reg:SI 189) (const_int 2146435072 [0x7ff00000])) 168 {*thumb1_movsi_insn} (nil)) (insn 62 61 63 3 double.cpp:12 (set (subreg:SI (reg/v:DI 180 [ _D_inf ]) 4) (reg:SI 189)) 168 {*thumb1_movsi_insn} (nil)) After fwprop1, a note "REG_EQUAL (const_int 2146435072 [0x7ff00000]" is attached to insn 62. (insn 56 54 60 3 double.cpp:12 (set (reg/v:DI 180 [ _D_inf ]) (const_int 0 [0x0])) 164 {*thumb1_movdi_insn} (nil)) (insn 60 56 62 3 double.cpp:12 (set (reg:SI 189) (const_int 2146435072 [0x7ff00000])) 168 {*thumb1_movsi_insn} (nil)) (insn 62 60 63 3 double.cpp:12 (set (subreg:SI (reg/v:DI 180 [ _D_inf ]) 4) (reg:SI 189)) 168 {*thumb1_movsi_insn} (expr_list:REG_EQUAL (const_int 2 146435072 [0x7ff00000]) (nil))) Then at combine pass, when the three insns are combined into one insn, the operand of the set note becomes [0x7ff0000000000000], but the REG_EQUAL note is still [0x7ff00000]. (insn 62 155 63 3 double.cpp:12 (set (reg/v:DI 180 [ _D_inf ]) (const_int 9218868437227405312 [0x7ff0000000000000])) 164 {*thumb1_movdi_insn} (expr_list:REG_EQUAL (const_int 2146435072 [0x7ff00000]) (nil))) If the wrong REG_EQUAL is not used in later optimization, then nothing wrong is observed. However, we find a case that the bug is triggered at ira pass. What happens is at ira pass, in reload() (reload1.c), gcc tries to find "SET REG(regno) = const N". When gcc finds one, it records constant equivalent in reg_equiv_constant so that the use of the register will be substituted by find_reloads. gcc puts "reg_equiv_constant[regno]=x". However, notice that, "x" here is the value from the REG_EQUAL note, not the SET operand. In our case, the value in reg 180 is 0x7ff0000000000000, but gcc says reg_equiv_constant[180]=0x7ff00000. Later, when gcc tries to simplify the SUBREG for insn 65, it picks the wrong value in reg_equiv_const[180] and passes the wrong value to insn 65. (insn 65 64 66 3 double.cpp:13 (set (reg:DF 2 r2) (subreg:DF (reg/v:DI 180 [ _D_inf ]) 0)) 183 {*thumb_movdf_insn} (nil)) becomes (insn 65 64 66 3 double.cpp:13 (set (reg:DF 2 r2) (const_double:DF 1.06047983010398252661938461763305382790433594771e-314 [0x0.ffep-1043])) 183 {*thumb_movdf_insn} (nil)) The const_double in insn 65 is wrong. test case double.cpp: union _D_rep { unsigned short rep[4]; double val; }; int add(double* key, double* table) { unsigned i = 0; double* deletedEntry = 0; while (1) { double* entry = table + i; _D_rep _D_inf = {{ 0, 0, 0, 0x7ff0 }}; if (*entry == _D_inf.val) break; if (*entry == *key) return 0; _D_rep _D_inf2 = {{ 0, 0, 0, 0x7ff0 }}; if (_D_inf2.val) deletedEntry = entry; i++; } if (deletedEntry) return 1; return 0; } The command is: arm-eabi-g++ -Os -mthumb double.cpp -c -o double.o -- Summary: Wrong REG_EQUAL note is added to SUBREG node Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jingyu at google dot com GCC build triplet: X86_64-linux-gnu GCC host triplet: X86_64-linux-gnu GCC target triplet: arm-unknown-eabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42691
next reply other threads:[~2010-01-11 19:45 UTC|newest] Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top 2010-01-11 19:45 jingyu at google dot com [this message] 2010-01-11 19:59 ` [Bug middle-end/42691] " jingyu at google dot com 2010-01-11 22:00 ` [Bug rtl-optimization/42691] problematic REG_EQUAL note added to SUBREG ebotcazou at gcc dot gnu dot org 2010-01-12 2:45 ` jingyu at google dot com 2010-01-12 8:57 ` ebotcazou at gcc dot gnu dot org 2010-01-12 9:33 ` ramana at gcc dot gnu dot org 2010-01-12 22:22 ` jingyu at google dot com 2010-01-13 1:18 ` jingyu at google dot com 2010-01-13 10:03 ` ebotcazou at gcc dot gnu dot org 2010-01-13 20:04 ` jingyu at google dot com 2010-01-13 22:57 ` jingyu at google dot com 2010-01-13 23:27 ` ebotcazou at gcc dot gnu dot org 2010-01-14 0:13 ` jingyu at google dot com 2010-01-14 9:32 ` [Bug rtl-optimization/42691] [4.4/4.5 regression] " rguenth at gcc dot gnu dot org 2010-01-15 18:48 ` jingyu at gcc dot gnu dot org 2010-01-15 19:09 ` jingyu at gcc dot gnu dot org 2010-01-15 20:59 ` sezeroz at gmail dot com 2010-01-15 21:11 ` mikpe at it dot uu dot se 2010-01-15 21:14 ` jingyu at google dot com 2010-01-15 21:42 ` mikpe at it dot uu dot se 2010-01-15 21:46 ` jingyu at google dot com 2010-01-15 21:50 ` ebotcazou at gcc dot gnu dot org 2010-01-15 21:54 ` jingyu at gcc dot gnu dot org 2010-01-15 21:59 ` jakub at gcc dot gnu dot org 2010-01-15 22:12 ` jingyu at gcc dot gnu dot org 2010-01-15 22:25 ` jingyu at google dot com 2010-01-16 16:05 ` jakub at gcc dot gnu dot org 2010-01-20 23:30 ` rguenth at gcc dot gnu dot org 2010-01-20 23:48 ` jingyu at google dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-42691-17567@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).