Skip to content

GCC/EDG Extension: Comparison of void** and void const** rejected. #6718

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.

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
llvmbot opened this issue Feb 18, 2010 · 3 comments
Closed

GCC/EDG Extension: Comparison of void** and void const** rejected. #6718

llvmbot opened this issue Feb 18, 2010 · 3 comments
Labels
bugzilla Issues migrated from bugzilla c++

Comments

@llvmbot
Copy link
Member

llvmbot commented Feb 18, 2010

Bugzilla Link 6346
Resolution FIXED
Resolved on Feb 25, 2010 16:30
Version trunk
OS All
Reporter LLVM Bugzilla Contributor
CC @DougGregor

Extended Description

g++ accepts the code fragment: int main(void) { void** i; void const** j; i == j; }

clang++ rejects this, with the error:

t.cc:1:46: error: comparison of distinct pointer types ('void ' and
'void const ')
int main(void) { void i; void const
j; i == j; }
~ ^ ~

@DougGregor
Copy link
Contributor

I'm looking into this one...

@DougGregor
Copy link
Contributor

This code is ill-formed, because the composite pointer type (as defined in [expr.rel]p2 would be

void const **

However, there's no standard conversion from void ** to const void ** (see [conv.qual]p4).

However^2, both GCC and EDG accept this code, and it's a completely reasonable to allow this comparison. The question is how, because we either:

  • Allow the conversion despite the fact that it's not a proper qualification conversion
  • Change the formulation of "composite pointer type" to produce, e.g., void const * const *, which both can convert to.

I favor the latter, but we shouldn't make this change without also bringing the issue to the C++ committee for consideration.

@DougGregor
Copy link
Contributor

Fixed in r97177.

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 3, 2021
topperc added a commit to topperc/llvm-project that referenced this issue Jan 11, 2024
This is an alternative to llvm#6718 now that the MC layer amocas.d/amocas.q
instructions use GPRPair register class.

While working on this I noticed that the change of setMaxAtomicSizeInBitsSupported
caused atomic load/store/rmw for 2*XLen types to be affected. The
AtomicExpandPass will not convert them to libcalls immediately.
Instead they get converted to different library calls by type
legalization.

I didn't see any way to signal AtomicExpandPass to convert them
to the same libcalls using any of the shouldExpandAtomic* hooks.
So I've forced them to use to CmpXChg expansion. I've disabled
the insertion of fences for atomic load/store when we use CmpXChg.

I've very unsure if this the right thing to do or if we should
make changes to AtomicExpand to get back the libcalls.
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla c++
Projects
None yet
Development

No branches or pull requests

2 participants