AaronBallman wrote:
> I'm surprised about the "compiler-rt is not supported on windows" comment -
> in our distribution, we've been building compiler-rt on windows for years,
> and I don't remember significant issues.
>
> It's true that `__divsc3` is not available _without_ compiler-rt (i.e.
h-vetinari wrote:
I'm surprised about the "compiler-rt is not supported on windows" comment - in
our distribution, we've been building compiler-rt on windows for years, and I
don't remember significant issues.
It's true that `__divsc3` is not available _without_ compiler-rt (i.e. just
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/88161
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jcranmer-intel approved this pull request.
https://github.com/llvm/llvm-project/pull/88161
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
zahiraam wrote:
LGTM. Thanks.
https://github.com/llvm/llvm-project/pull/88161
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/zahiraam approved this pull request.
https://github.com/llvm/llvm-project/pull/88161
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/philnik777 approved this pull request.
LGTM from my side. I'll leave the conformance test details to the folks who
know what they're doing.
https://github.com/llvm/llvm-project/pull/88161
___
cfe-commits mailing list
AaronBallman wrote:
> > > Note that
> > > ```c++
> > > auto div(_Complex float lhs, _Complex float rhs) {
> > > return lhs / rhs;
> > > }
> > >
> > > int main() {
> > > return __real div(1.f, 2.f);
> > > }
> > > ```
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
philnik777 wrote:
> > Note that
> > ```c++
> > auto div(_Complex float lhs, _Complex float rhs) {
> > return lhs / rhs;
> > }
> >
> > int main() {
> > return __real div(1.f, 2.f);
> > }
> > ```
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > will
AaronBallman wrote:
> You're missing checks for type domain rules, so things like:
>
> * converting between `float _Complex` and `double _Complex`
>
> * common type of `float _Complex` and `double`
>
> * result of `int` and `float _Complex`
>
> * complex types not allowed in
@@ -0,0 +1,97 @@
+// RUN: %clang_cc1 -verify -std=c99 %s
+
+/* WG14 N620, N638, N657, N694, N809: Yes*
+ * Complex and imaginary support in
+ *
+ * NB: Clang supports _Complex but not _Imaginary. In C99, _Complex support is
+ * required outside of freestanding, but _Imaginary
@@ -373,6 +355,10 @@ C99 implementation status
Yes
+(2): Clang supports _Complex type specifiers
but
+does not support _Imaginary type specifiers. Support for
+_Imaginary is optional in C99 which is why Clang is fully
conforming.
AaronBallman
@@ -0,0 +1,97 @@
+// RUN: %clang_cc1 -verify -std=c99 %s
+
+/* WG14 N620, N638, N657, N694, N809: Yes*
+ * Complex and imaginary support in
+ *
+ * NB: Clang supports _Complex but not _Imaginary. In C99, _Complex support is
+ * required outside of freestanding, but _Imaginary
@@ -0,0 +1,97 @@
+// RUN: %clang_cc1 -verify -std=c99 %s
+
+/* WG14 N620, N638, N657, N694, N809: Yes*
+ * Complex and imaginary support in
+ *
+ * NB: Clang supports _Complex but not _Imaginary. In C99, _Complex support is
+ * required outside of freestanding, but _Imaginary
@@ -373,6 +355,10 @@ C99 implementation status
Yes
+(2): Clang supports _Complex type specifiers
but
+does not support _Imaginary type specifiers. Support for
+_Imaginary is optional in C99 which is why Clang is fully
conforming.
jcranmer-intel
@@ -0,0 +1,97 @@
+// RUN: %clang_cc1 -verify -std=c99 %s
+
+/* WG14 N620, N638, N657, N694, N809: Yes*
+ * Complex and imaginary support in
+ *
+ * NB: Clang supports _Complex but not _Imaginary. In C99, _Complex support is
+ * required outside of freestanding, but _Imaginary
@@ -0,0 +1,97 @@
+// RUN: %clang_cc1 -verify -std=c99 %s
+
+/* WG14 N620, N638, N657, N694, N809: Yes*
+ * Complex and imaginary support in
+ *
+ * NB: Clang supports _Complex but not _Imaginary. In C99, _Complex support is
+ * required outside of freestanding, but _Imaginary
https://github.com/jcranmer-intel edited
https://github.com/llvm/llvm-project/pull/88161
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jcranmer-intel commented:
You're missing checks for type domain rules, so things like:
- converting between `float _Complex` and `double _Complex`
- common type of `float _Complex` and `double`
- result of `int` and `float _Complex`
- complex types not allowed in
AaronBallman wrote:
> Note that
>
> ```c++
> auto div(_Complex float lhs, _Complex float rhs) {
> return lhs / rhs;
> }
>
> int main() {
> return __real div(1.f, 2.f);
> }
> ```
>
> will fail to link on windows due to `__divsc3` not being available. Similar
> programs probably also fail
philnik777 wrote:
Note that
```c++
auto div(_Complex float lhs, _Complex float rhs) {
return lhs / rhs;
}
int main() {
return __real div(1.f, 2.f);
}
```
will fail to link on windows due to `__divsc3` not being available. Similar
programs probably also fail due to other compiler-rt
frederick-vs-ja wrote:
> But fails on Windows.
This seems because of that MS UCRT's complex math functions are non-conforming.
I _guess_ they could work if we write the following before including UCRT's
``.
```C
#define _C_COMPLEX_T
typedef double _Complex _C_double_complex;
typedef float
zahiraam wrote:
> > > I'm not convinced I have sufficient tests, so I'm especially interested
> > > in some help figuring out what else to test and how to go about it. I
> > > don't believe we need to test library behavior here because Clang does
> > > not provide any library support for
AaronBallman wrote:
> > I'm not convinced I have sufficient tests, so I'm especially interested in
> > some help figuring out what else to test and how to go about it. I don't
> > believe we need to test library behavior here because Clang does not
> > provide any library support for complex
zahiraam wrote:
> I'm not convinced I have sufficient tests, so I'm especially interested in
> some help figuring out what else to test and how to go about it. I don't
> believe we need to test library behavior here because Clang does not provide
> any library support for complex types in
AaronBallman wrote:
I'm not convinced I have sufficient tests, so I'm especially interested in some
help figuring out what else to test and how to go about it. I don't believe we
need to test library behavior here because Clang does not provide any library
support for complex types in
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Aaron Ballman (AaronBallman)
Changes
There's so much overlap between the cited papers so this condenses the status
page into a single entry rather than trying to test conformance against
multiple papers doing conflicting things.
---
27 matches
Mail list logo
