Skip to content

Silence gcc on the use of the GNU typeof extension. #9894

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
Closed

Silence gcc on the use of the GNU typeof extension. #9894

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 4 additions & 0 deletions opal/class/opal_fifo.h
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -216,6 +216,7 @@ static inline opal_list_item_t *opal_fifo_pop_atomic(opal_fifo_t *fifo)
const opal_list_item_t *const ghost = &fifo->opal_fifo_ghost;

# if OPAL_HAVE_ATOMIC_LLSC_PTR

register opal_list_item_t *item, *next;
int attempt = 0, ret = 0;

Expand All @@ -228,7 +229,10 @@ static inline opal_list_item_t *opal_fifo_pop_atomic(opal_fifo_t *fifo)
attempt = 0;
}

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wlanguage-extension-token"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd rather get rid of the typeof() usage in the ll/sc code. I have a bunch of patches to clean up the atomics code; let me go see how bad that change would make things and then we can come back to this. But we really don't want to pragma every usage of the opal_atomic_ll code.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We only have to protect the use of opal_atomic_ll because they are defined as macros (and the diagnostic do not apply to macros when they are read, but only when they are applied. If we convert he macro into an inlined function then we can have the pragma in a single location.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nathan originally used inline functions, but even with always_inline primitives, couldn't keep all the compilers from sometimes not inlining the function. And once not inlined, there was a very high probability of the link failing due to some write in setting up the function call, causing the conditional store to fail, infinitely.

But I think I found a better solution to this problem. Unfortunately, I checked in my branch full of atomic changes. I'll post it later today.

opal_atomic_ll_ptr(&fifo->opal_fifo_head.data.item, item);
#pragma GCC diagnostic pop
if (ghost == item) {
if ((intptr_t) ghost == fifo->opal_fifo_tail.data.item) {
return NULL;
Expand Down
5 changes: 5 additions & 0 deletions opal/class/opal_lifo.h
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -213,6 +213,9 @@ static inline opal_list_item_t *opal_lifo_push_atomic(opal_lifo_t *lifo, opal_li

# if OPAL_HAVE_ATOMIC_LLSC_PTR

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wlanguage-extension-token"

/* Retrieve one element from the LIFO. If we reach the ghost element then the LIFO
* is empty so we return NULL.
*/
Expand Down Expand Up @@ -244,6 +247,8 @@ static inline opal_list_item_t *opal_lifo_pop_atomic(opal_lifo_t *lifo)
return item;
}

#pragma GCC diagnostic pop

# else

/* Retrieve one element from the LIFO. If we reach the ghost element then the LIFO
Expand Down