Date: Tue, 07 Mar 2023 11:12:34 +0000 From: Lorenzo Salvadore <developer@lorenzosalvadore.it> To: Mark Millard <marklmi@yahoo.com> Cc: Brooks Davis <brooks@FreeBSD.org>, "salvadore@freebsd.org" <salvadore@FreeBSD.org>, FreeBSD Mailing List <freebsd-ports@freebsd.org> Subject: Re: armv7 lang/gcc12 "no bootstrap" build via system clang 15.0.7 based poudriere build ends up stuck in a small loop Message-ID: <QdRxSqmLcfs4rhVDld9j3g-vhVK3IGqu2Zwbj3uB5svUD0wtiDfAKGYIYaRUi6ZdsnHKyl_nGV1j0nfhaoUN1LJ6YbvvXEOqIa-JdRu5l9c=@lorenzosalvadore.it> In-Reply-To: <B703089D-0EA6-49D4-96F9-69C09B0FF23C@yahoo.com> References: <F536BC00-49D3-41F8-A328-EA10FD21E1DC.ref@yahoo.com> <F536BC00-49D3-41F8-A328-EA10FD21E1DC@yahoo.com> <2HOLCFE6Z_cOyGycU4ZBU7Lf6kcqohVx7tiLiRLzdjMEc6a8DFeH1IaJqdPNJOqFVTh1MGE7_UUJLcg2gg0UbTZIHZl72NbaNEsqrJwJ3xA=@lorenzosalvadore.it> <93707ED2-F529-49DE-A018-794827F56247@yahoo.com> <7AA0AE73-87CC-4B26-92B2-A0EC4281F429@yahoo.com> <480C8278-DC30-40D6-AED2-F52F59E78EBC@yahoo.com> <EB917CA9-CC67-4F79-8EBD-6BE82B021D45@yahoo.com> <B703089D-0EA6-49D4-96F9-69C09B0FF23C@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
------- Original Message -------
On Tuesday, March 7th, 2023 at 11:26 AM, Mark Millard <marklmi@yahoo.com> w=
rote:
>=20
>=20
> 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.
>=20
> # more partition.c
> // Minor varation of part of some gcc source code!
>=20
> // For system-clang 15: cc -g -O2 partition.c ; ./a.out
> // For devel/llvm16: clang16 -g -O2 partition.c ; ./a.out
>=20
> #include <stdio.h>
>=20
>=20
> #define NUM_ELEMENTS 32
>=20
> struct partition_elem
> {
> struct partition_elem* next;
> int class_element;
> unsigned class_count;
> };
>=20
> typedef struct partition_def
> {
> int num_elements;
> struct partition_elem elements[NUM_ELEMENTS];
> } *partition;
>=20
> struct partition_def partition_storage;
>=20
> partition
> partition_new (int num_elements)
> {
> int e;
>=20
> if (NUM_ELEMENTS < num_elements) num_elements =3D NUM_ELEMENTS;
>=20
> partition part=3D &partition_storage;
> part->num_elements =3D num_elements;
>=20
> for (e =3D 0; e < num_elements; ++e)
> {
> part->elements[e].class_element =3D e;
>=20
> part->elements[e].next =3D &(part->elements[e]);
>=20
> part->elements[e].class_count =3D 1;
>=20
> }
>=20
> for (e =3D 0; e < num_elements; ++e)
> printf("%d: %p : next?: %p\n",e,(void*)&part->elements[e],(void*)part->el=
ements[e].next);
>=20
>=20
> return part;
> }
>=20
> int main(void)
> {
> partition part;
> part=3D partition_new(NUM_ELEMENTS);
>=20
> return !part;
> }
>=20
> 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.
>=20
> # 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
>=20
> 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.
>=20
> -g is not required for the problem.
This last point about optimization is interesting.
It is just a guess, but maybe when you enable bootstrap
in lang/gcc12 you build the first compiler without
optimization, while if you disable it you do use -O2.
I have taken your example C code and tested it in
FreeBSD amd64 and in a virtual machine running Linux
(OpenSuse) amd64: I have got the same failure
in both cases. I used clang15. So the bug does not
depend on the OS nor on the architecture.
However, my results have a difference from yours:
in my case tests fail with any level of optimization.
At this point, I would say that the issue is in clang.
I think you should file a bug upstream.
Thanks,
Lorenzo Salvadore
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?QdRxSqmLcfs4rhVDld9j3g-vhVK3IGqu2Zwbj3uB5svUD0wtiDfAKGYIYaRUi6ZdsnHKyl_nGV1j0nfhaoUN1LJ6YbvvXEOqIa-JdRu5l9c=>