Unexpected Output behavior ARCHS

[luismgsilva]

Unexpected Output behavior 1
A series of tests have been identified that do not exhibit the expected behavior. These issues predominantly stem from the absence of an operating system and an exception handler in the Baremetal Toolchain testing. Given that the Baremetal Toolchain lacks an operating system, these problems should be categorized as expected failures (XFAIL).

To address this, these tests have been incorporated into the ARCHS allowlist, which can be found at the following links:

1. Line 118: Link
2. Line 129: Link

---

Unexpected Output behavior 2
A previous stated issue regarding the behavior of introducing set_board_info needs_status_wrapper 1 to the arc-sim.exp board, not only affects the DejaGNU output, but also its directives.

The strlenopt-10.c test case checks the behavior and optimizations of string manipulation functions such as strlen, strcpy, strchr, and memcpy. The main function tests and verifies their correctness, raising an error if any checks fail.

/* { dg-final { scan-tree-dump-times "memcpy \\(" 8 "strlen1" { target { ! no_alignment_constraints } } } } */
/* { dg-final { scan-tree-dump-times "memcpy \\(" 7 "strlen1" { target { no_alignment_constraints} } } } */  

These two lines of comments in the code are directives used by DejaGnu to check the compiler's code generation during optimization passes.

• The first comment checks for occurrences of the "memcpy(" function call eight times in the compiler's internal tree dump. It applies to target architectures without alignment constraints.

• The second comment does a similar check but for architectures with no alignment constraints, expecting to find "memcpy(" seven times.

These comments are used to verify how the memcpy function calls are optimized, especially in relation to alignment constraints. The expected number of occurrences is tailored to the expected behavior based on alignment constraints.

The selected DejaGNU directives differ between the Baremetal Toolchain and the Linux Toolchain. In the Baremetal Toolchain, it specifies the expectation of seven occurrences of the "memcpy(" function, whereas in the Linux Toolchain, it anticipates eight occurrences of the "memcpy(" function. Despite this difference in directive specifications, both Toolchain distributions produce the same result, yielding eight occurrences.

# Using wrapper - `set_board_info needs_status_wrapper 1`
spawn arc-elf32-run -Wq,-semihosting ./no_alignment_constraints1284559.exe

*** EXIT code 1
spawn arc-elf32-run -Wq,-semihosting ./strlenopt-10.exe

*** EXIT code 0
PASS: gcc.dg/strlenopt-10.c execution test
PASS: gcc.dg/strlenopt-10.c scan-tree-dump-times strlen1 "strlen \\(" 2
PASS: gcc.dg/strlenopt-10.c scan-tree-dump-times strlen1 "memcpy \\(" 8
PASS: gcc.dg/strlenopt-10.c scan-tree-dump-times strlen1 "strcpy \\(" 0
PASS: gcc.dg/strlenopt-10.c scan-tree-dump-times strlen1 "strcat \\(" 0
PASS: gcc.dg/strlenopt-10.c scan-tree-dump-times strlen1 "strchr \\(" 0
PASS: gcc.dg/strlenopt-10.c scan-tree-dump-times strlen1 "stpcpy \\(" 0
PASS: gcc.dg/strlenopt-10.c scan-tree-dump-times strlen1 "\\*q_[0-9]* = 32;" 1
PASS: gcc.dg/strlenopt-10.c scan-tree-dump-times strlen1 "memcpy \\([^\n\r]*, 1\\)" 1

# No wrapper
spawn arc-elf32-run -Wq,-semihosting ./no_alignment_constraints395951.exe
spawn arc-elf32-run -Wq,-semihosting ./strlenopt-10.exe
gcc.dg/strlenopt-10.c: pattern found 8 times
FAIL: gcc.dg/strlenopt-10.c scan-tree-dump-times strlen1 "memcpy \\(" 7
PASS: gcc.dg/strlenopt-10.c scan-tree-dump-times strlen1 "strcpy \\(" 0
PASS: gcc.dg/strlenopt-10.c scan-tree-dump-times strlen1 "strcat \\(" 0
PASS: gcc.dg/strlenopt-10.c scan-tree-dump-times strlen1 "strchr \\(" 0
PASS: gcc.dg/strlenopt-10.c scan-tree-dump-times strlen1 "stpcpy \\(" 0
PASS: gcc.dg/strlenopt-10.c scan-tree-dump-times strlen1 "\\*q_[0-9]* = 32;" 1
PASS: gcc.dg/strlenopt-10.c scan-tree-dump-times strlen1 "memcpy \\([^\n\r]*, 1\\)" 1

When we incorporate set_board_info needs_status_wrapper 1 into the arc-sim.exp board, as mentioned earlier, there are no discrepancies in the Linux Toolchain. However, a disparity arises in the Baremetal Toolchain. In this case, the DejaGNU directive is altered from expecting seven occurrences to expecting eight.

The validation for no_alignment_constraints relies on the C MACRO __BIGGEST_ALIGNMENT__. It has been verified that both Toolchain distributions share the same value for __BIGGEST_ALIGNMENT__.

Note: This both happens in QEMU and nSIM. Leading to a possible newlib issue.