------- Original Message ------- On Tuesday, March 7th, 2023 at 1:04 PM, Mark Millard <mark...@yahoo.com> wrote:
> > > On Mar 7, 2023, at 03:45, Dimitry Andric d...@freebsd.org wrote: > > > On 7 Mar 2023, at 11:26, Mark Millard mark...@yahoo.com wrote: > > > > > 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. > > > ... > > > 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 > > > > Very strange, I don't see this at all here. All the values are always > > correct, at every optimization level. I tried clang 13, clang 14, clang > > 15 from base and clang 15 from ports. However, my architecture is amd64, > > so maybe you are running into a armv7 specific issue? > > > Yep: aarch64 and amd64 gcc builds all worked fine > via system-clang 15 and the test case also works > fine in my context on those. (All platforms > have FreeBSD built from copies of the same > source code.) > > It is only on armv7 that I got the gcc build > problems and the test case failures. > > FYI: > > aarch64 Fedora 37 using clang-15 also works > fine for me (only tried the test case, not > gcc builds): > > # clang-15 -g -O2 partition.c ; ./a.out > 0: 0x420038 : next?: 0x420038 > 1: 0x420048 : next?: 0x420048 > 2: 0x420058 : next?: 0x420058 > 3: 0x420068 : next?: 0x420068 > 4: 0x420078 : next?: 0x420078 > 5: 0x420088 : next?: 0x420088 > 6: 0x420098 : next?: 0x420098 > 7: 0x4200a8 : next?: 0x4200a8 > 8: 0x4200b8 : next?: 0x4200b8 > 9: 0x4200c8 : next?: 0x4200c8 > 10: 0x4200d8 : next?: 0x4200d8 > 11: 0x4200e8 : next?: 0x4200e8 > 12: 0x4200f8 : next?: 0x4200f8 > 13: 0x420108 : next?: 0x420108 > 14: 0x420118 : next?: 0x420118 > 15: 0x420128 : next?: 0x420128 > 16: 0x420138 : next?: 0x420138 > 17: 0x420148 : next?: 0x420148 > 18: 0x420158 : next?: 0x420158 > 19: 0x420168 : next?: 0x420168 > 20: 0x420178 : next?: 0x420178 > 21: 0x420188 : next?: 0x420188 > 22: 0x420198 : next?: 0x420198 > 23: 0x4201a8 : next?: 0x4201a8 > 24: 0x4201b8 : next?: 0x4201b8 > 25: 0x4201c8 : next?: 0x4201c8 > 26: 0x4201d8 : next?: 0x4201d8 > 27: 0x4201e8 : next?: 0x4201e8 > 28: 0x4201f8 : next?: 0x4201f8 > 29: 0x420208 : next?: 0x420208 > 30: 0x420218 : next?: 0x420218 > 31: 0x420228 : next?: 0x420228 > > # clang-15 -v > clang version 15.0.7 (Fedora 15.0.7-1.fc37) > Target: aarch64-redhat-linux-gnu > Thread model: posix > InstalledDir: /usr/bin > Found candidate GCC installation: /usr/bin/../lib/gcc/aarch64-redhat-linux/12 > Selected GCC installation: /usr/bin/../lib/gcc/aarch64-redhat-linux/12 > Candidate multilib: .;@m64 > Selected multilib: .;@m64 > > If I understand right, Lorenzo indicates that he has > more failing contexts. I've no evidence of my own of > such. I am sorry, I was in a hurry and I read Mark's email too quickly. Then now I have stopped, read more carefully, rerun the tests and everything works as intended instead. So, the testcode works correctly at all optmization levels on FreeBSD amd64 and Linux OpenSuse amd64, at least on my machine. I am sorry for my mistake. Cheers, Lorenzo Salvadore
