GNU ARC Toolchain reported a critical error: gcc_assert in cselib_record_set function line: 2409
lipinggoke opened this issue · 7 comments
I am researching to use GNU ARC Toolchain (2018.09) for our project development and I found this critical error of GNU ARC Toolchain.
I am trying to use 'attribute ((interrupt ("ilink1")))' GNU ARC GCC function attribute to replace MWDT '_Interrupt1' keyword to specify an interrupt function of arc700 level 1.
Here is the testing code in my project:
And this is the error reported while compiling:
and I checked the GNU ARC Toolchain source codes, it was here where the exception was thrown:
if I remove the 'attribute ((interrupt ("ilink1")))' function attribute, it compiled fine. but the function would not properly worked as the level 1 ISR routine.
May I ask what is the cause of this problem? and is there any way to avoid it while using 'attribute ((interrupt ("ilink1")))' function attribute?
Thanks.
I think this issue belongs to GCC repository https://github.com/foss-for-synopsys-dwc-arc-processors/gcc.
@claziss
Hi @anthony-kolesov and @claziss ,
I think this problem is caused by the conflication between the compiler optimizations (any '-O' option except '-O0') and 'attribute ((interrupt ("ilink1")))' ARC Function Attributes.
I find a situation to reproduce this exception certainly and instantly.
This is the example codes:
/*
* Exambple codes which would make gnu arc toolchain throw exception for
* '__attribute__ ((interrupt ("ilink1")))' function attribute using
* with any '-O' optimization except '-O0'.
*
* GNU ARC toolchain version: GNU Toolchain for ARC Processors, 2018.09
*
* File: GNU_ARC_GCC_Excption_Trig.c
* Version: 1.0
* Author: Li Ping
* Email: liping@goke.com
*
*/
typedef void (*isr_routine)(void);
isr_routine will_trig_exception;
__attribute__ ((interrupt ("ilink1"))) void isr_template(void)
{
will_trig_exception();
return;
}
int main(void)
{
return 0;
}
and this is the reproducing full command line and logs:
The toolchain version is GNU Toolchain for ARC Processors, 2018.09.
Is there any optimization flag to set to avoid this exception?
Thanks and best regards.
I can reproduce the issue when we use -g
(debug) option. Otherwise, it should work.
The upcoming 2019.03
release doesn't exposes this issue. However, it doesn't mean it is solved.
To avoid the issue until a resolution is found, you can do:
- Avoid passing
-g
or any debug option to your sensitive files; - Pass
-fno-var-tracking
when passing-g
option to your sensitive files.
-g1 will also work (probably it is equivalent of -fno-var-tracking).
Or replacing function pointer with real implementation, if you can afford it.
Good news, this issue has been address in this patch epilogue blockage. Please pick the next release for a fix.