vader compile issue #5814
Assignees
Comments
|
Well, somehow my local master was very stale. The line is really: fifo->fifo_head = fifo->fifo_tail = VADER_FIFO_FREE;This points to something being off with the definition of the atomic types with this platform/compiler combination. |
hjelmn
added
bug
and removed
invalid
Target: v2.x
Target: v3.0.x
Target: v3.1.x
Target: v4.0.x
labels
|
@siegmargross Can you post a gist with the config.log? |
|
Something is really off here. Might still be a compiler bug. The head and tail are of type typedef volatile intptr_t opal_atomic_intptr_t;or typedef _Atomic intptr_t opal_atomic_intptr_t;depending on whether C11 atomics are in use. Given what @siegmargross has provided above it looks like C11 atomics are indeed in use. The config.log will hopefully confirm. So the line in question has types: Which from my reading of ISO C11 is valid. Might be worth trying to compile this small C program and see if it barfs: #include <stdlib.h>
#include <stdatomic.h>
int main (int argc, char *argv[]) {
_Atomic intptr_t test;
intptr_t x = 0;
test = x;
return 0;
} |
|
@siegmargross Nathan posted a sample program (via editing his prior comment), so you didn't get the mail about it. Can you check #5814 (comment) and compile/run the sample program he proposed and see what happens? |
|
@siegmargross replied in https://www.mail-archive.com/[email protected]/msg32706.html; filing here to keep all the information together. Hi Jeff, hi Nathan, the compilers (Sun C 5.15, Sun C 5.14, Sun C 5.13) don't like the code. I have attached the file config.log.gist from my master build, although I @hjelmn suggested in a followup that Siegmar should add |
|
From @siegmargross ... it works for Sun C 5.14 and Sun C 5.15. |
|
In talking to @hjelmn on the 2018-10-02 webex, we wonder if his simple test is sufficient -- he's going to make a slightly more complicated test (more like the actual OMPI source code) and ask @siegmargross to try it. |
|
Compiler bug! We can work around it I think: cat foo.c
#include <stdlib.h>
#include <stdint.h>
#include <stdatomic.h>
int main (int argc, char *argv[]) {
_Atomic intptr_t x, y;
intptr_t z = 0;
x = y = z;
return 0;
}#include <stdlib.h>
#include <stdint.h>
#include <stdatomic.h>
int main (int argc, char *argv[]) {
_Atomic intptr_t x, y;
intptr_t z = 0;
x = z;
y = z;
return 0;
} |
hjelmn
added a commit
to hjelmn/ompi
that referenced
this issue
Oct 2, 2018
This commit works around an Oracle C compiler bug in 5.15 (not sure when it was introduced). The bug is triggered when we chain assignments of atomic variables. Ex: _Atomic intptr x, y; intptr_t z = 0; x = y = z; Will produce a compiler error of the form: operand cannot have void type: op "=" assignment type mismatch: long "=" void To work around the issue we are removing the chain assignment and setting the head and tail on different lines. Fixes open-mpi#5814 Signed-off-by: Nathan Hjelm <[email protected]>
hjelmn
added a commit
that referenced
this issue
Oct 3, 2018
This commit works around an Oracle C compiler bug in 5.15 (not sure when it was introduced). The bug is triggered when we chain assignments of atomic variables. Ex: _Atomic intptr x, y; intptr_t z = 0; x = y = z; Will produce a compiler error of the form: operand cannot have void type: op "=" assignment type mismatch: long "=" void To work around the issue we are removing the chain assignment and setting the head and tail on different lines. Fixes #5814 Signed-off-by: Nathan Hjelm <[email protected]>
jsquyres
pushed a commit
to jsquyres/ompi
that referenced
this issue
Oct 3, 2018
This commit works around an Oracle C compiler bug in 5.15 (not sure when it was introduced). The bug is triggered when we chain assignments of atomic variables. Ex: _Atomic intptr x, y; intptr_t z = 0; x = y = z; Will produce a compiler error of the form: operand cannot have void type: op "=" assignment type mismatch: long "=" void To work around the issue we are removing the chain assignment and setting the head and tail on different lines. Fixes open-mpi#5814 Signed-off-by: Nathan Hjelm <[email protected]> (cherry picked from commit dfa8d3a)
jsquyres
pushed a commit
to jsquyres/ompi
that referenced
this issue
Oct 3, 2018
This commit works around an Oracle C compiler bug in 5.15 (not sure when it was introduced). The bug is triggered when we chain assignments of atomic variables. Ex: _Atomic intptr x, y; intptr_t z = 0; x = y = z; Will produce a compiler error of the form: operand cannot have void type: op "=" assignment type mismatch: long "=" void To work around the issue we are removing the chain assignment and setting the head and tail on different lines. Fixes open-mpi#5814 Signed-off-by: Nathan Hjelm <[email protected]> (cherry picked from commit dfa8d3a)
jsquyres
pushed a commit
to jsquyres/ompi
that referenced
this issue
Oct 3, 2018
This commit works around an Oracle C compiler bug in 5.15 (not sure when it was introduced). The bug is triggered when we chain assignments of atomic variables. Ex: _Atomic intptr x, y; intptr_t z = 0; x = y = z; Will produce a compiler error of the form: operand cannot have void type: op "=" assignment type mismatch: long "=" void To work around the issue we are removing the chain assignment and setting the head and tail on different lines. Fixes open-mpi#5814 Signed-off-by: Nathan Hjelm <[email protected]> (cherry picked from commit dfa8d3a)
jsquyres
pushed a commit
to jsquyres/ompi
that referenced
this issue
Oct 3, 2018
This commit works around an Oracle C compiler bug in 5.15 (not sure when it was introduced). The bug is triggered when we chain assignments of atomic variables. Ex: _Atomic intptr x, y; intptr_t z = 0; x = y = z; Will produce a compiler error of the form: operand cannot have void type: op "=" assignment type mismatch: long "=" void To work around the issue we are removing the chain assignment and setting the head and tail on different lines. Fixes open-mpi#5814 Signed-off-by: Nathan Hjelm <[email protected]> (cherry picked from commit dfa8d3a)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As reported by @siegmargross in https://www.mail-archive.com/[email protected]/msg32704.html, he's having a compile issue with the vader BTL.
@hjelmn can you have a look?
Siegmar specifically stated that he tested master, but I'm guessing that this affects all of 2.1.x, 3.0.x, 3.1.x, and 4.0.x.
The text was updated successfully, but these errors were encountered: