Add Cray support #137
Add Cray support #137
Conversation
The Cray compiler rejected passing the first block [class(field_t)] to create_block, expecting [type(field_t)], resolved with a pointer.
| ! If the list is empty, allocate a new block before returning a | ||
| ! pointer to it. | ||
| if (.not. associated(self%first)) then | ||
| ! Construct a field_t. This effectively allocates | ||
| ! storage space. | ||
| self%first => self%create_block(next=self%first) |
There was a problem hiding this comment.
It looks like there is a mistake in the original implementation. We don't really need to pass a next to create_block, because each time we need to allocate a field it means that the linked list is empty and the next will always be a null pointer. If we edit create_block and use self%first in place of receiving a next argument and using it in field instantiation it should work fine.
newblock = field_t(self%ngrid, self%first, id=self%next_id)
I guess the trouble here with Cray compiler is passing a null pointer as argument to create_block so this should solve the issue without requiring two new functions. If select type stuff is necessary with Cray then we can have that inside the original create_block functions. Each time we create a block we create the first one in the linked list anyways.
There was a problem hiding this comment.
The issue with the Cray compiler stems from create_block taking a type(field_t) and the allocator's first field being class(field_t) - it is technically correct, this seemed the minimal change to me.
However, if as you suggest we don't need to pass next then yes this can be resolved more neatly.
There was a problem hiding this comment.
Actually this select type here is relevant to #97. Maybe using select type will solve the issue there too. My confusion however is that when we instantiate an allocator, there are initially no fields, and then the first pointer just points to a null pointer, so not sure how its type could be resolved down to field_t or cuda_field_t.
There was a problem hiding this comment.
ah, we're considering two issues here:
- Cray won't compile the code due to the different types
- At runtime the first field should indeed be uncertain (I've not been able to test the code yet)
I think your suggestion of removing the next argument from create_block should resolve both issues
We don't need the `next` pointer
No description provided.