* Question about ASMCONS @ 2016-12-19 12:29 Claudiu Zissulescu 2016-12-19 17:06 ` Segher Boessenkool 0 siblings, 1 reply; 6+ messages in thread From: Claudiu Zissulescu @ 2016-12-19 12:29 UTC (permalink / raw) To: gcc; +Cc: Francois Bedard Hi guys, I have the following rtl before asmcons pass: (insn 8 13 9 2 (set (reg:SI 157 [ list ]) (asm_operands:SI ("") ("=g") 0 [ (const:SI (unspec:SI [ (symbol_ref:SI ("c_const") [flags 0x2] <var_decl 0x7f6735ad25a0 c_const>) ] ARC_UNSPEC_GOTOFFPC)) ] [ (asm_input:SI ("0") ../t02.c:9) ] [] ../t02.c:9)) ../t02.c:9 -1 (nil)) Asmcons pass leads to this: (insn 13 3 8 2 (set (reg:SI 157 [ list ]) (const:SI (unspec:SI [ (symbol_ref:SI ("c_const") [flags 0x2] <var_decl 0x7fd69f6365a0 c_const>) ] ARC_UNSPEC_GOTOFFPC))) ../t02.c:9 -1 (nil)) (insn 8 13 9 2 (set (reg:SI 157 [ list ]) (asm_operands:SI ("") ("=g") 0 [ (const:SI (unspec:SI [ (symbol_ref:SI ("c_const") [flags 0x2] <var_decl 0x7fd69f6365a0 c_const>) ] ARC_UNSPEC_GOTOFFPC)) ] [ (asm_input:SI ("0") ../t02.c:9) ] [] ../t02.c:9)) ../t02.c:9 -1 (nil)) Is the above output correct? My understanding is that the insn 8 needs be changed to have as input the reg:SI 157. Thanks, Claudiu ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Question about ASMCONS 2016-12-19 12:29 Question about ASMCONS Claudiu Zissulescu @ 2016-12-19 17:06 ` Segher Boessenkool 2016-12-19 18:59 ` Claudiu Zissulescu 0 siblings, 1 reply; 6+ messages in thread From: Segher Boessenkool @ 2016-12-19 17:06 UTC (permalink / raw) To: Claudiu Zissulescu; +Cc: gcc, Francois Bedard Hi Claudiu, On Mon, Dec 19, 2016 at 12:28:54PM +0000, Claudiu Zissulescu wrote: > I have the following rtl before asmcons pass: > > (insn 8 13 9 2 (set (reg:SI 157 [ list ]) > (asm_operands:SI ("") ("=g") 0 [ > (const:SI (unspec:SI [ > (symbol_ref:SI ("c_const") [flags 0x2] <var_decl 0x7f6735ad25a0 c_const>) > ] ARC_UNSPEC_GOTOFFPC)) > ] > [ > (asm_input:SI ("0") ../t02.c:9) > ] > [] ../t02.c:9)) ../t02.c:9 -1 > (nil)) [ snip ] asmcons eventual does reg_overlap_mentioned_p on the input of the move it created with an input of the asm. The very first thing reg_overlap_mentioned_p tests for is if the thing is constant. And it is here, and that makes no sense at all (since it is an output, too!) So how did that happen? Segher ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Question about ASMCONS 2016-12-19 17:06 ` Segher Boessenkool @ 2016-12-19 18:59 ` Claudiu Zissulescu 2018-12-11 10:03 ` Claudiu Zissulescu 0 siblings, 1 reply; 6+ messages in thread From: Claudiu Zissulescu @ 2016-12-19 18:59 UTC (permalink / raw) To: Segher Boessenkool, Claudiu Zissulescu; +Cc: gcc, Francois Bedard On 19/12/2016 18:06, Segher Boessenkool wrote: > Hi Claudiu, > > On Mon, Dec 19, 2016 at 12:28:54PM +0000, Claudiu Zissulescu wrote: >> I have the following rtl before asmcons pass: >> >> (insn 8 13 9 2 (set (reg:SI 157 [ list ]) >> (asm_operands:SI ("") ("=g") 0 [ >> (const:SI (unspec:SI [ >> (symbol_ref:SI ("c_const") [flags 0x2] <var_decl 0x7f6735ad25a0 c_const>) >> ] ARC_UNSPEC_GOTOFFPC)) >> ] >> [ >> (asm_input:SI ("0") ../t02.c:9) >> ] >> [] ../t02.c:9)) ../t02.c:9 -1 >> (nil)) > > [ snip ] > > asmcons eventual does reg_overlap_mentioned_p on the input of the move > it created with an input of the asm. The very first thing > reg_overlap_mentioned_p tests for is if the thing is constant. And it > is here, and that makes no sense at all (since it is an output, too!) > > So how did that happen? > Right, the reg_overlap_mentioned_p returns zero letting the insn 8 unchanged. The problem is observed in crtstuff.c when compiling __do_globa_dtor_aux (line 398). Here it is a short test code: typedef void (*func_ptr) (void); static func_ptr __DTOR_LIST__[1] = { (func_ptr)(-1) }; void foo (int a) { func_ptr *dtor_list; __asm ("" : "=g" (dtor_list) : "0" (__DTOR_LIST__)); dtor_list[a](); } compiled with -O1 -fpic -mcpu=archs for ARC ;) it will crash somewhere in verify_rtx_sharing due to the duplicated const(unspec) thingy. I was thinking to force the replacement of the input, in function.c:6781 by adding to the condition an i == j check. Due to this issue, the mainline cannot build ARC uClibc toolchain. I suspect that this issue may affect also mips or nios2, but not 100% sure. Thanks, Claudiu ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Question about ASMCONS 2016-12-19 18:59 ` Claudiu Zissulescu @ 2018-12-11 10:03 ` Claudiu Zissulescu 2018-12-11 10:34 ` Segher Boessenkool 0 siblings, 1 reply; 6+ messages in thread From: Claudiu Zissulescu @ 2018-12-11 10:03 UTC (permalink / raw) To: Segher Boessenkool, Claudiu Zissulescu; +Cc: gcc, Francois Bedard Hi all, This issue still keeps biting me, specially in the glibc upstreaming process. I have made a bugzilla entry for this (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88001) where I also added my solution for the given issue. Please can someone help me, or maybe let me know if my patch is acceptable? Thank you, Claudiu On Mon, Dec 19, 2016 at 8:59 PM Claudiu Zissulescu <claziss@gmail.com> wrote: > > On 19/12/2016 18:06, Segher Boessenkool wrote: > > Hi Claudiu, > > > > On Mon, Dec 19, 2016 at 12:28:54PM +0000, Claudiu Zissulescu wrote: > >> I have the following rtl before asmcons pass: > >> > >> (insn 8 13 9 2 (set (reg:SI 157 [ list ]) > >> (asm_operands:SI ("") ("=g") 0 [ > >> (const:SI (unspec:SI [ > >> (symbol_ref:SI ("c_const") [flags 0x2] <var_decl 0x7f6735ad25a0 c_const>) > >> ] ARC_UNSPEC_GOTOFFPC)) > >> ] > >> [ > >> (asm_input:SI ("0") ../t02.c:9) > >> ] > >> [] ../t02.c:9)) ../t02.c:9 -1 > >> (nil)) > > > > [ snip ] > > > > asmcons eventual does reg_overlap_mentioned_p on the input of the move > > it created with an input of the asm. The very first thing > > reg_overlap_mentioned_p tests for is if the thing is constant. And it > > is here, and that makes no sense at all (since it is an output, too!) > > > > So how did that happen? > > > Right, the reg_overlap_mentioned_p returns zero letting the insn 8 > unchanged. > The problem is observed in crtstuff.c when compiling __do_globa_dtor_aux > (line 398). Here it is a short test code: > > typedef void (*func_ptr) (void); > static func_ptr __DTOR_LIST__[1] = { (func_ptr)(-1) }; > > void foo (int a) > { > func_ptr *dtor_list; > __asm ("" : "=g" (dtor_list) : "0" (__DTOR_LIST__)); > dtor_list[a](); > } > > compiled with -O1 -fpic -mcpu=archs for ARC ;) it will crash somewhere > in verify_rtx_sharing due to the duplicated const(unspec) thingy. > > I was thinking to force the replacement of the input, in function.c:6781 > by adding to the condition an i == j check. > > Due to this issue, the mainline cannot build ARC uClibc toolchain. I > suspect that this issue may affect also mips or nios2, but not 100% sure. > > Thanks, > Claudiu > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Question about ASMCONS 2018-12-11 10:03 ` Claudiu Zissulescu @ 2018-12-11 10:34 ` Segher Boessenkool 2018-12-11 11:28 ` Claudiu Zissulescu 0 siblings, 1 reply; 6+ messages in thread From: Segher Boessenkool @ 2018-12-11 10:34 UTC (permalink / raw) To: Claudiu Zissulescu; +Cc: Claudiu Zissulescu, gcc, Francois Bedard, bergner Hi! On Tue, Dec 11, 2018 at 12:02:42PM +0200, Claudiu Zissulescu wrote: > This issue still keeps biting me, specially in the glibc upstreaming > process. I have made a bugzilla entry for this > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88001) where I also > added my solution for the given issue. > > Please can someone help me, or maybe let me know if my patch is acceptable? I have good news for you. The problem reproduced with my 20181025 compiler, but between then and now the problem was fixed -- probably one of Peter's IRA patches, which dealt with exactly this kind of problem :-) Segher ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Question about ASMCONS 2018-12-11 10:34 ` Segher Boessenkool @ 2018-12-11 11:28 ` Claudiu Zissulescu 0 siblings, 0 replies; 6+ messages in thread From: Claudiu Zissulescu @ 2018-12-11 11:28 UTC (permalink / raw) To: Segher Boessenkool; +Cc: Claudiu Zissulescu, gcc, Francois Bedard, bergner Hi, Thank you for the quick response, but I still get it with the latest gcc sources. The error is shown only when the compiler is configured with all the internal checks in place. Please, can you share with me the way how you build the toolchain. I am trying to see what I do wrong... Thank you, Claudiu On Tue, Dec 11, 2018 at 12:34 PM Segher Boessenkool <segher@kernel.crashing.org> wrote: > > Hi! > > On Tue, Dec 11, 2018 at 12:02:42PM +0200, Claudiu Zissulescu wrote: > > This issue still keeps biting me, specially in the glibc upstreaming > > process. I have made a bugzilla entry for this > > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88001) where I also > > added my solution for the given issue. > > > > Please can someone help me, or maybe let me know if my patch is acceptable? > > I have good news for you. The problem reproduced with my 20181025 > compiler, but between then and now the problem was fixed -- probably > one of Peter's IRA patches, which dealt with exactly this kind of > problem :-) > > > Segher ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2018-12-11 11:28 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-12-19 12:29 Question about ASMCONS Claudiu Zissulescu 2016-12-19 17:06 ` Segher Boessenkool 2016-12-19 18:59 ` Claudiu Zissulescu 2018-12-11 10:03 ` Claudiu Zissulescu 2018-12-11 10:34 ` Segher Boessenkool 2018-12-11 11:28 ` Claudiu Zissulescu
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).