[Bug target/94445] New: gcc.target/arm/cmse/cmse-15.c fails for cortex-m33

clyon at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Wed Apr 1 15:55:51 GMT 2020


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94445

            Bug ID: 94445
           Summary: gcc.target/arm/cmse/cmse-15.c fails for cortex-m33
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

I've noticed that when GCC is configured --target arm-none-abi
--with-mode=thumb --with-cpu=cortex-m33, the cmse-15.c test fails:

FAIL: gcc.target/arm/cmse/cmse-15.c   -O2   scan-assembler-times
bl\\s+__gnu_cmse_nonsecure_call 6
FAIL: gcc.target/arm/cmse/cmse-15.c   -O3 -g   scan-assembler-times
bl\\s+__gnu_cmse_nonsecure_call 6
FAIL: gcc.target/arm/cmse/cmse-15.c   -Os   scan-assembler-times
bl\\s+__gnu_cmse_nonsecure_call 6


I've looked at the -O2 case, where 8 calls to __gnu_cmse_nonsecure_call instead
of the expected 6.

The testcase can then be reduced to:
=====================================================
typedef int __attribute__ ((cmse_nonsecure_call)) ns_foo_t (void);
typedef int s_bar_t (void);

typedef int (*s_bar_ptr) (void);

int nonsecure0 (ns_foo_t * ns_foo_p)
{
  return ns_foo_p ();
}
int secure0 (s_bar_t * s_bar_p)
{
  return s_bar_p ();
}
int secure2 (s_bar_ptr s_bar_p)
{
  return s_bar_p ();
}
=====================================================

secure0 and secure2 make use of __gnu_cmse_nonsecure_call instead of doing a
normal call.

If I comment out nonsecure0(), then the test passes (only "bx r0" is generated
for secure0/secure2).


With nonsecure0() un-commented as above, I've looked at
arm_function_ok_for_sibcall() which is called 3 times.

The first time (for nonsecure0):
 <call_expr 0x7facbe3ac630
[...]
    fn <ssa_name 0x7facbe586318
        type <pointer_type 0x7facbe670888 type <function_type 0x7facbe670498
ns_foo_t>
            public unsigned SI size <integer_cst 0x7facbe57bfd8 32> unit-size
<integer_cst 0x7facbe58e000 4>
            align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7facbe670930>
        visited var <parm_decl 0x7facbe39b180 ns_foo_p>
        def_stmt GIMPLE_NOP
        version:2
        ptr-info 0x7facbe39c300>


The next two times (for secure0/secure2):
 <call_expr 0x7facbe3acb10
[...]
    fn <nop_expr 0x7facbe3b34a0
        type <pointer_type 0x7facbe670888 type <function_type 0x7facbe670498
ns_foo_t>
            public unsigned SI size <integer_cst 0x7facbe57bfd8 32> unit-size
<integer_cst 0x7facbe58e000 4>
            align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7facbe670930>

        arg:0 <ssa_name 0x7facbe586900 type <pointer_type 0x7facbe670b28>
            visited var <parm_decl 0x7facbe39b200 s_bar_p>
            def_stmt GIMPLE_NOP
            version:2
            ptr-info 0x7facbe3b5be8>>


 <call_expr 0x7facbe3ac060
[...]
    fn <nop_expr 0x7facbe3ba800
        type <pointer_type 0x7facbe670888 type <function_type 0x7facbe670498
ns_foo_t>
            public unsigned SI size <integer_cst 0x7facbe57bfd8 32> unit-size
<integer_cst 0x7facbe58e000 4>
            align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7facbe670930>

        arg:0 <ssa_name 0x7facbe586af8 type <pointer_type 0x7facbe6707e0
s_bar_ptr>
            visited var <parm_decl 0x7facbe39b280 s_bar_p>
            def_stmt GIMPLE_NOP
            version:2
            ptr-info 0x7facbe3b8b28>>


So in the last two cases, the function being called has an incorrect 'ns_foo_t'
type.

The fact that commenting out nonsecure0 makes the test pass makes me think that
some global state is modified when handling the  cmse_nonsecure_call attribute,
but I couldn't find such a problem in arm_handle_cmse_nonsecure_call().


I haven't yet found where that function type is attached to the 'fn' node,
maybe that's where the problem is.

I've also noticed that in the first case 'fn' is an ssa_name, while in the two
other ones, it is a nop_expr.



I've been investigating this for quite some time, so any clue is appreciated.


More information about the Gcc-bugs mailing list