* 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).