On 7/2/25 4:12 PM, Jerry D wrote:
On 7/2/25 9:40 AM, Jerry D wrote:
On 7/2/25 3:14 AM, Andre Vehreschild wrote:
Hi all,
I successfully created a big mess with the previous patch. First of all by
applying an outdated one and secondly by adding the conformance checks for
coranks in a3f1cdd8ed46f9816b31ab162ae4dac547d34ebc. Checking the standard even
using AI (haha) to figure if coranks of an expression have restrictions on
them, failed. I found nothing. AI fantasized about restrictions that did not
exist. Therefore the current approach is to remove the conformance check and
just use the computed coranks in expressions to prevent recomputaion whenever
they needed.
Jerry, Harald: Sorry for all the bother and all my mistakes. I am really sorry
to have wasted your time.
The patch has been regtested fine on x86_64-pc-linux-gnu / F41. Ok for mainline
and later backport to gcc-15?
Regards,
Andre
--- snip ---
With this fixer patch, I can successfully compile Toon's test case.
The patch also regression tests here OK.
OK to push.
Jerry
As a followup, with the fixer patch applied, OpenCoarrays builds. However, make
test hangs at Test 4.
3/88 Test #3: register_vector .......................................
Passed 0.42 sec
Start 4: register_alloc_vector
^Cmake[3]: *** [CMakeFiles/check.dir/build.make:70: CMakeFiles/check] Interrupt
make[2]: *** [CMakeFiles/Makefile2:962: CMakeFiles/check.dir/all] Interrupt
make[1]: *** [CMakeFiles/Makefile2:969: CMakeFiles/check.dir/rule] Interrupt
make: *** [Makefile:205: check] Interrupt
I waited about 20 minutes. This may be another bug. I built and tested
OpenCorrays about 2 days ago with gfortran 14 with no problems.
I am able to compile and run Toon's test case with this OpenCoarrays. So we
still have some breakage on 15 and 16 remaining. I have not tried building
OpenCoarrays with the shmem patch applied yet. This will be my next step here.
Regards,
Jerry
I managed to build OpenCoarrays with a new clone from Andre's suggested branch.
I started with a completely empty build directory.
Although it builds, I still get the hang on register_alloc_vector.f90. I pulled
that test case out to see what it is doing. It will compile and run with
-lcaf_shmem and appears to run OK. I tried to test it under valgrind and it
prints that it passed however, right after that it hangs. I could not kill the
process and had to do a system shutdown and wait for the kernel to kill it.
Valgrind was starting to report an unfreed block 26 allocated 25 freed. The
system froze after that. This is on x86_64 Fedora 42
With Toon's test case, when one chooses a number of images for the test that
does not satisfy: (I used np=17)
if (mod(nxglobal * nyglobal, npxy) /= 0) then
print*, 'Number of images and domain size do not allow an equal-sized
partitioning.'
stop 1
endif
The stop does not exit the program. I wonder if either finalization or needing
to handle stop with multiple images needs to be addressed. I don't know.
Regardless, it is not playing well with something in the system here. Andre, as
your time is running short, maybe push this to a gcc development branch to
capture what you have so we can examine further. There is something lurking in
this still.
Let me know.
Regards,
Jerry
