On Thu, Aug 10, 2023 at 06:55:05AM +0000, Richard Biener wrote:
> On Wed, 9 Aug 2023, Joseph Myers wrote:
>
> > On Wed, 9 Aug 2023, Jakub Jelinek via Gcc-patches wrote:
> >
> > > - _Complex _BitInt(N) isn't supported; again mainly because none of the
> > > psABIs
> > > mention how those should be passed/returned; in a limited way they are
> > > supported internally because the internal functions into which
> > > __builtin_{add,sub,mul}_overflow{,_p} is lowered return COMPLEX_TYPE as
> > > a
> > > hack to return 2 values without using references/pointers
> >
> > What happens when the usual arithmetic conversions are applied to
> > operands, one of which is a complex integer type and the other of which is
> > a wider _BitInt type? I don't see anything in the code to disallow this
> > case (which would produce an expression with a _Complex _BitInt type), or
> > any testcases for it.
> >
> > Other testcases I think should be present (along with any corresponding
> > changes needed to the code itself):
> >
> > * Verifying that the new integer constant suffix is rejected for C++.
> >
> > * Verifying appropriate pedwarn-if-pedantic for the new constant suffix
> > for versions of C before C2x (and probably for use of _BitInt type
> > specifiers before C2x as well) - along with the expected -Wc11-c2x-compat
> > handling (in C2x mode) / -pedantic -Wno-c11-c2x-compat in older modes.
>
> Can we go as far as deprecating our _Complex int extension for
> C17 and make it unavailable for C2x, side-stepping the issue?
> Or maybe at least considering that for C2x?
I can just sorry at it for now. And now that I search through the x86-64
psABI again, it doesn't mention complex integers at all, so we are there on
our own. And it seems we don't have anything for complex integers on the
library side and the complex lowering is before bitint lowering, so it might
just work with < 10 lines of changes in code + testsuite, but if we do
enable it, let's do it incrementally.
Jakub
