a system-clang 15 and devel/llvm1[56] armv7 code generation error: a small test case

[This is just an FYI about a system-clang 15 and
devel/llvm1[56] armv7 code generation bug. The
investigation sequence notes that lead to this
discovery is on the freebsd-ports list.]

On Mar 7, 2023, at 02:26, Mark Millard <[email protected]> wrote
on the freebsd-ports list:

> Below is a small example C source showing the clang 15+ armv7
> problem that leads to the unbounded looping in later code in
> the lang/gcc12+ builds: a data structure is mis-initialized,
> breaking its invariant properties used by the later code
> structure.
> 
> # more partition.c
> // Minor varation of part of some gcc source code!
> 
> // For system-clang 15: cc      -g -O2 partition.c ; ./a.out
> // For devel/llvm16:    clang16 -g -O2 partition.c ; ./a.out
> 
> #include <stdio.h>
> 
> #define NUM_ELEMENTS 32
> 
> struct partition_elem
> {
>  struct partition_elem* next;
>  int class_element;
>  unsigned class_count;
> };
> 
> typedef struct partition_def
> {
>  int num_elements;
>  struct partition_elem elements[NUM_ELEMENTS];
> } *partition;
> 
> struct partition_def partition_storage;
> 
> partition
> partition_new (int num_elements)
> {
>  int e;
> 
>  if (NUM_ELEMENTS < num_elements) num_elements = NUM_ELEMENTS;
> 
>  partition part= &partition_storage;
>  part->num_elements = num_elements;
>  for (e = 0; e < num_elements; ++e)
>    {
>      part->elements[e].class_element = e;
>      part->elements[e].next = &(part->elements[e]);
>      part->elements[e].class_count = 1;
>    }
> 
>  for (e = 0; e < num_elements; ++e)
>      printf("%d: %p : next?: %p\n",e,(void*)&part->elements[e],(void*)part->elements[e].next);
> 
>  return part;
> }
> 
> int main(void)
> {
>    partition part;
>    part= partition_new(NUM_ELEMENTS);
> 
>    return !part;
> }
> 
> In the output below, note the blocks of 4 "next"
> values that do not change. Each should match the
> earlier hexadecimal value on the same line: point
> back to same element of the array. 3 of 4 do not.
> 
> # cc -g -O2 partition.c
> # ./a.out
> 0: 0x40a84 : next?: 0x40a84
> 1: 0x40a90 : next?: 0x40a84
> 2: 0x40a9c : next?: 0x40a84
> 3: 0x40aa8 : next?: 0x40a84
> 4: 0x40ab4 : next?: 0x40ab4
> 5: 0x40ac0 : next?: 0x40ab4
> 6: 0x40acc : next?: 0x40ab4
> 7: 0x40ad8 : next?: 0x40ab4
> 8: 0x40ae4 : next?: 0x40ae4
> 9: 0x40af0 : next?: 0x40ae4
> 10: 0x40afc : next?: 0x40ae4
> 11: 0x40b08 : next?: 0x40ae4
> 12: 0x40b14 : next?: 0x40b14
> 13: 0x40b20 : next?: 0x40b14
> 14: 0x40b2c : next?: 0x40b14
> 15: 0x40b38 : next?: 0x40b14
> 16: 0x40b44 : next?: 0x40b44
> 17: 0x40b50 : next?: 0x40b44
> 18: 0x40b5c : next?: 0x40b44
> 19: 0x40b68 : next?: 0x40b44
> 20: 0x40b74 : next?: 0x40b74
> 21: 0x40b80 : next?: 0x40b74
> 22: 0x40b8c : next?: 0x40b74
> 23: 0x40b98 : next?: 0x40b74
> 24: 0x40ba4 : next?: 0x40ba4
> 25: 0x40bb0 : next?: 0x40ba4
> 26: 0x40bbc : next?: 0x40ba4
> 27: 0x40bc8 : next?: 0x40ba4
> 28: 0x40bd4 : next?: 0x40bd4
> 29: 0x40be0 : next?: 0x40bd4
> 30: 0x40bec : next?: 0x40bd4
> 31: 0x40bf8 : next?: 0x40bd4
> 
> Turns out that the -O2 is important: no other that I
> tried got the problem, including -O3 not getting the
> problem. lang/gcc12+ builds happen to use -O2 , at
> least in my environment.
> 
> -g is not required for the problem.
> 

I've not built lang/gcc11 or before in a long time.
Building them "no bootstrap" style via clang15+ may
hit the same type of problem for all I know.

===
Mark Millard
marklmi at yahoo.com