https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/135236
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
What I am taking away from this conversation is: 1) We need to keep tgmath.h,
so this PR can be closed. 2) We should consider implementing
`__builtin_tgmath`, 3) We should consider bumping the `__GNUC__` version we
report. I think all of those are sensible, though (2) seems
h-vetinari wrote:
> Clang would either need to change its `__GNUC__` value
Independently of the discussion here, that value should IMO be updated
(https://github.com/llvm/llvm-project/issues/42162) or at least documented
(https://github.com/llvm/llvm-project/issues/99804)
https://github.com/l
zygoloid wrote:
> > For some reason, WG21 has trampled over that meaning of "freestanding" and
> > we no longer have such a separation for C++, but it still exists for C
>
> See #132232.
Sigh. So we can't use "freestanding" as the line between compiler and standard
library anywhere any more,
hubert-reinterpretcast wrote:
> We could add a builtin matching the GCC `__builtin_tgmath` builtin and remove
> our header for at least those targets, though.
Clang would either need to change its `__GNUC__` value or the glibc header
would need to add a `__has_builtin` query.
Oddly enough, `__
zygoloid wrote:
A few datapoints:
* uClibc [uses
`__builtin_classify_type`](https://git.uclibc.org/uClibc/tree/include/tgmath.h)
and it looks like that'd work fine for us.
* newlib [uses
`__builtin_choose_expr`](https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=newlib/libc/include/tgmat
zygoloid wrote:
I see. The glibc header comment gives an idea of what's going on here:
```c
/* There are two variant implementations of type-generic macros in
this file: one for GCC 8 and later, using __builtin_tgmath and
where each macro expands each of its arguments only once, and one
perry-ca wrote:
> > Today, that's no longer the case.
>
> IBM's AIX ships a `tgmath.h` that only works with the IBM non-Clang-based XL
> compiler.
Same for z/OS.
https://github.com/llvm/llvm-project/pull/135236
___
cfe-commits mailing list
cfe-com
hubert-reinterpretcast wrote:
Does it make sense to keep the tests for all platforms then? If we decide to
restrict the testing to the platforms expected to use the Clang-provided
header, then I think it should at least be staged so that there is some CI
cycle where the tests are run regardles
zygoloid wrote:
> > I wonder if we can put it into an AIX-only (plus whatever other targets
> > still need it) include directory, though, so we only find and use it on the
> > targets where it's necessary?
>
> That, or, generally `#include_next` except for certain platforms (like AIX)?
Possib
hubert-reinterpretcast wrote:
> I wonder if we can put it into an AIX-only (plus whatever other targets still
> need it) include directory, though, so we only find and use it on the targets
> where it's necessary?
That, or, generally `#include_next` except for certain platforms (like AIX)?
ht
hubert-reinterpretcast wrote:
> Thank you for pointing that out! So IBM still needs Clang to vend this for
> now, I take it? Is IBM planning to update their tgmath.h so that it works
> with the Clang-based XL compiler (so we can eventually remove Clang's)?
The road to being able to retain the
zygoloid wrote:
> Background: it's not clear to me which C Standard Library headers Clang
> should or should not provide,
Historically, the easiest line to draw has been that we aim to provide the
freestanding headers. This matches GCC's [documented
position](https://gcc.gnu.org/onlinedocs/gc
AaronBallman wrote:
> > Today, that's no longer the case.
>
> IBM's AIX ships a `tgmath.h` that only works with the IBM non-Clang-based XL
> compiler.
Thank you for pointing that out! So IBM still needs Clang to vend this for now,
I take it? Is IBM planning to update their tgmath.h so that it
hubert-reinterpretcast wrote:
> Today, that's no longer the case.
IBM's AIX ships a `tgmath.h` that only works with the IBM non-Clang-based XL
compiler.
https://github.com/llvm/llvm-project/pull/135236
___
cfe-commits mailing list
cfe-commits@lists.l
AaronBallman wrote:
Background: it's not clear to me which C Standard Library headers Clang should
or should not provide, so perhaps this change is wrong for reasons I don't
understand. However, we have a number of open bug reports about our
implementation of tgmath.h, and there are further ch
github-actions[bot] wrote:
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
You can test this locally with the following command:
``bash
git-clang-format --diff HEAD~1 HEAD --extensions cpp --
clang/lib/Lex/ModuleMap.cpp
``
View the
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Aaron Ballman (AaronBallman)
Changes
Clang provides a number of headers which are required because the compiler is
the only part of the implementation which can provide the correct macro
definitions. Things like or a
https://github.com/AaronBallman created
https://github.com/llvm/llvm-project/pull/135236
Clang provides a number of headers which are required because the compiler is
the only part of the implementation which can provide the correct macro
definitions. Things like or are such headers.
is no
19 matches
Mail list logo
