farzonl wrote:
> > I didn't want the current set of changes to go stale.
>
> How many changes are we talking about here? If it's just the tan() ones,
> that's fine; it probably makes sense to land constrained-tan separately
> anyway.
There are 4 for tan. There will be more for the other
efriedma-quic wrote:
> I didn't want the current set of changes to go stale.
How many changes are we talking about here? If it's just the tan() ones,
that's fine; it probably makes sense to land constrained-tan separately anyway.
https://github.com/llvm/llvm-project/pull/90276
github-actions[bot] wrote:
@maribu Congratulations on having your first Pull Request (PR) merged into the
LLVM Project!
Your changes will be combined with recent changes from other authors, then
tested
by our [build bots](https://lab.llvm.org/buildbot/). If there is a problem with
a build,
benisxdxd wrote:
@smithp35 The system i'm interacting with has a GCC plugin that uses r4 and r5
for custom software mitigations against exploitation.
I need a way to inform LLVM to keep this registers untouched so I don't
interfere and cause a corruption.
By reserving those registers I will
Author: Marian Buschsieweke
Date: 2024-05-07T13:58:13-07:00
New Revision: bc8a42762057d7036f6871211e62b1c3efb2738a
URL:
https://github.com/llvm/llvm-project/commit/bc8a42762057d7036f6871211e62b1c3efb2738a
DIFF:
https://github.com/asl closed https://github.com/llvm/llvm-project/pull/91258
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/asl approved this pull request.
Thanks!
https://github.com/llvm/llvm-project/pull/91258
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/asl edited https://github.com/llvm/llvm-project/pull/91258
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ellishg closed
https://github.com/llvm/llvm-project/pull/90925
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Ellis Hoag
Date: 2024-05-07T13:55:44-07:00
New Revision: 2ad6917c4c524576405f2146424911fd9adb3528
URL:
https://github.com/llvm/llvm-project/commit/2ad6917c4c524576405f2146424911fd9adb3528
DIFF:
https://github.com/llvm/llvm-project/commit/2ad6917c4c524576405f2146424911fd9adb3528.diff
sdkrystian wrote:
@adrian-prantl While I'm not 100% certain of this, I _think_ modules are cached
between test runs for LLDB (the only way I was able to reproduce the crash was
by precompiling modules with clang built from the commit before this one, and
then deserializing with clang built
@@ -529,9 +529,325 @@ bool SystemZTargetCodeGenInfo::isVectorTypeBased(const
Type *Ty,
return false;
}
+//===--===//
+// z/OS XPLINK ABI Implementation
https://github.com/efriedma-quic commented:
At first glance, making a separate ABI seemed weird, but I guess it's pretty
different from the normal SystemZ ABI.
https://github.com/llvm/llvm-project/pull/91384
___
cfe-commits mailing list
@@ -529,9 +529,325 @@ bool SystemZTargetCodeGenInfo::isVectorTypeBased(const
Type *Ty,
return false;
}
+//===--===//
+// z/OS XPLINK ABI Implementation
@@ -529,9 +529,325 @@ bool SystemZTargetCodeGenInfo::isVectorTypeBased(const
Type *Ty,
return false;
}
+//===--===//
+// z/OS XPLINK ABI Implementation
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/91384
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
adrian-prantl wrote:
How did you address the LLDB test failures?
https://github.com/llvm/llvm-project/pull/91393
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -2893,7 +2915,6 @@ static void RenderFloatingPointOptions(const ToolChain
, const Driver ,
AssociativeMath = false;
ReciprocalMath = false;
SignedZeros = true;
- FPContract = "on";
zahiraam wrote:
Not quite sure why this is removed
MaskRay wrote:
> Thanks for the additional context. My main concern is that we're undoing the
> consensus of [reviews.llvm.org/D45164](https://reviews.llvm.org/D45164) which
> if I've understood the comments properly was "There is a reasonable
> expectation that compiled (not assembled) code
https://github.com/diggerlin approved this pull request.
https://github.com/llvm/llvm-project/pull/77732
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
diggerlin wrote:
> @diggerlin ,
>
> > > can we implement -fcomplex-ppc-gnu-abi as "-msoft-float" ? what is your
> > > opinion ?
> > > that was not the intent here and we need to consultant ABI reference
> > > regrading the same ,before we decide on implementation .
I think I do not express
AaronBallman wrote:
I think I've addressed all of the feedback (thank you all for the
improvements!), except for the suggestion from @Endilll to switch to using
italics rather than code font. I think the suggestion is a good one, but it's a
time-consuming edit that doesn't change the meaning
llvmbot wrote:
@llvm/pr-subscribers-clang-tools-extra
Author: Krystian Stasiowski (sdkrystian)
Changes
Reapplies #81642
---
Patch is 164.19 KiB, truncated to 20.00 KiB below, full version:
https://github.com/llvm/llvm-project/pull/91393.diff
26 Files Affected:
- (modified)
Author: Adrian Prantl
Date: 2024-05-07T13:03:14-07:00
New Revision: 2e4abfae57f81e2bb23fc654d6edbaeae51ae10a
URL:
https://github.com/llvm/llvm-project/commit/2e4abfae57f81e2bb23fc654d6edbaeae51ae10a
DIFF:
https://github.com/llvm/llvm-project/commit/2e4abfae57f81e2bb23fc654d6edbaeae51ae10a.diff
@@ -8,109 +8,91 @@ Standard C++ Modules
Introduction
-The term ``modules`` has a lot of meanings. For the users of Clang, modules may
-refer to ``Objective-C Modules``, ``Clang C++ Modules`` (or ``Clang Header
Modules``,
-etc.) or ``Standard C++ Modules``. The
https://github.com/aheejin closed
https://github.com/llvm/llvm-project/pull/91299
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Heejin Ahn
Date: 2024-05-07T13:02:31-07:00
New Revision: dca3a6e562e012940c2b62a4d8dae3afec09caa4
URL:
https://github.com/llvm/llvm-project/commit/dca3a6e562e012940c2b62a4d8dae3afec09caa4
DIFF:
https://github.com/llvm/llvm-project/commit/dca3a6e562e012940c2b62a4d8dae3afec09caa4.diff
aheejin wrote:
According to https://webassembly.org/features/, EH is supported from node v17,
which is also Emscripten test infra requires:
https://github.com/emscripten-core/emscripten/blob/2fefc1911e2e6265174c3fd5da38c8e9ab7abb60/test/common.py#L866-L868
So EH tests should have been already
adrian-prantl wrote:
This broke several tests in the LLDB testsuite, I'm going to have to revert
this.
https://green.lab.llvm.org/job/llvm.org/view/LLDB/job/as-lldb-cmake/3480/
https://github.com/llvm/llvm-project/pull/81642
___
cfe-commits mailing
https://github.com/yxsamliu approved this pull request.
https://github.com/llvm/llvm-project/pull/85672
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rnk wrote:
I played with the idea of using LLVM packed structs (`<{ i129 }>`) to represent
something like this, but they don't work the way I expected them to do:
https://godbolt.org/z/M6hMYYhax
LLVM DataLayout's idea of `sizeof(i129)` is still rounded up from 17 bytes to
32 bytes.
Using
dwblaikie wrote:
Oh, and I take it there's no /official/ extension space in the SHT_* space? The
intent is to standardize it where it lies? (like use 20 for the shipped
version? Or eventually get some lower designation?) I understand tnhe hesitance
to use "SHT_LLVM" or the like (though
dwblaikie wrote:
Presumably this'll be split out into separate reviews for the components here?
(I'd guess llvm-mc then clang integrated assembler, with readobj and yaml2obj
in any order/don't have dependencies, unless they're needed for testing, in
which case I guess they come first?)
I
hdoc wrote:
>From my reading of the Doxygen documentation it seems like anything goes
>except putting the doc comment inside the actual body of a function. That
>being said, I think that change is out of the scope of this PR because it
>would likely require modifications to the Clang
https://github.com/katzdm edited https://github.com/llvm/llvm-project/pull/89565
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -925,45 +923,41 @@ In that case, you need to convert your source files (.cpp
files) to module imple
// Following off should be unchanged.
...
-The module implementation unit will import the primary module implicitly.
-We don't include any headers in the module
mizvekov wrote:
> Thanks, guarding the second specialization with the feature test macro works.
>
>
>
> I will try to reduce the test case tomorrow, if you still need this.
>
>
Thanks. If it's not too much work for you, that would be great. Otherwise, I
think a pretty good guess can be
kiranchandramohan wrote:
Done.
https://github.com/llvm/llvm-project/pull/90420
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -738,22 +736,21 @@ the following style significantly:
import M;
... // use declarations from module M.
-The key part of the tip is to reduce the duplications from the text includes.
+Reducing the duplication from textual includes is what improves compile-time
https://github.com/kiranchandramohan updated
https://github.com/llvm/llvm-project/pull/90420
>From 78e91d2d84638ded51267c5e0720cc1d1d4d773b Mon Sep 17 00:00:00 2001
From: Kiran Chandramohan
Date: Fri, 26 Apr 2024 09:26:11 +
Subject: [PATCH 1/2] [Flang][Driver] Add support for -w option 1/n
jhuber6 wrote:
I'm getting the same kind of output on `main`, but the warning is mysteriously
absent.
https://github.com/llvm/llvm-project/pull/91264
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
@@ -400,24 +389,27 @@ And the compilation process for module units are like:
mod1.cppm -> clang++ mod1.cppm ... -> mod1.pcm --,--> clang++
mod1.pcm ... -> mod1.o -+
src2.cpp +> clang++
src2.cpp --->
https://github.com/fanbo-meng updated
https://github.com/llvm/llvm-project/pull/91384
>From 7b40fa0aab937dfc0ab8db48ed93db1a5debef0b Mon Sep 17 00:00:00 2001
From: Fanbo Meng
Date: Tue, 7 May 2024 13:36:38 -0400
Subject: [PATCH 1/2] [SystemZ][z/OS] Implement z/OS XPLINK ABI
The XPLINK calling
Author: Kazu Hirata
Date: 2024-05-07T12:40:19-07:00
New Revision: 65e2fab401a2da55c51d3caceae8478c33f3c60f
URL:
https://github.com/llvm/llvm-project/commit/65e2fab401a2da55c51d3caceae8478c33f3c60f
DIFF:
https://github.com/llvm/llvm-project/commit/65e2fab401a2da55c51d3caceae8478c33f3c60f.diff
mejedi wrote:
cc @anakryiko
https://github.com/llvm/llvm-project/pull/91310
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
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 27becf0c3c1e7ac4a2f2e848b44d872f1aa1db9a
7b40fa0aab937dfc0ab8db48ed93db1a5debef0b --
@@ -8,109 +8,91 @@ Standard C++ Modules
Introduction
-The term ``modules`` has a lot of meanings. For the users of Clang, modules may
-refer to ``Objective-C Modules``, ``Clang C++ Modules`` (or ``Clang Header
Modules``,
-etc.) or ``Standard C++ Modules``. The
tom-anders wrote:
ping - [Support for textDocument/rangesFormatting is about to be merged into
neovim](https://github.com/neovim/neovim/pull/27323), so we'll soon have at
least two editors (nvim, vscode) with support for this
https://github.com/llvm/llvm-project/pull/80180
llvmbot wrote:
@llvm/pr-subscribers-clang
@llvm/pr-subscribers-backend-systemz
Author: Fanbo Meng (fanbo-meng)
Changes
The XPLINK calling convention is specified in the Language Environment Vendor
Interface, chapter 22,
https://github.com/fanbo-meng created
https://github.com/llvm/llvm-project/pull/91384
The XPLINK calling convention is specified in the Language Environment Vendor
Interface, chapter 22,
(https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.cee/cee.htm)
and in Redbook
eaeltsin wrote:
Thanks, guarding the second specialization with the feature test macro works.
I will try to reduce the test case tomorrow, if you still need this.
https://github.com/llvm/llvm-project/pull/89807
___
cfe-commits mailing list
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/91310
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/efriedma-quic commented:
Is it possible you could put this code into CompleteExternalDeclaration(),
instead of writing it out in every place that can refer to the address of a
function?
https://github.com/llvm/llvm-project/pull/91310
@@ -1950,8 +1950,22 @@ ConstantLValueEmitter::tryEmitBase(const
APValue::LValueBase ) {
if (D->hasAttr())
return CGM.GetWeakRefReference(D).getPointer();
-if (auto FD = dyn_cast(D))
- return CGM.GetAddrOfFunction(FD);
+if (auto FD = dyn_cast(D)) {
+
https://github.com/huangjd ready_for_review
https://github.com/llvm/llvm-project/pull/81545
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/huangjd converted_to_draft
https://github.com/llvm/llvm-project/pull/81545
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1391,17 +1381,17 @@ with the following one:
$ clang++ -std=c++20 -xc++-system-header --precompile iostream -o
iostream.pcm
$ clang++ -std=c++20 -fmodule-file=iostream.pcm --precompile M.cppm -o M.cpp
-In the latter example, the Clang could find the BMI for the
https://github.com/zibi2 closed https://github.com/llvm/llvm-project/pull/90990
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Sean Perry
Date: 2024-05-07T15:23:50-04:00
New Revision: c9ab1d890586bd8a6a194e6a37968538b80f81bd
URL:
https://github.com/llvm/llvm-project/commit/c9ab1d890586bd8a6a194e6a37968538b80f81bd
DIFF:
https://github.com/llvm/llvm-project/commit/c9ab1d890586bd8a6a194e6a37968538b80f81bd.diff
https://github.com/ellishg edited
https://github.com/llvm/llvm-project/pull/90925
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ellishg updated
https://github.com/llvm/llvm-project/pull/90925
>From 4760ebce0ff7725f4bb75f5107f551d867e4db6d Mon Sep 17 00:00:00 2001
From: Ellis Hoag
Date: Thu, 2 May 2024 17:47:38 -0700
Subject: [PATCH 1/4] [modules] Accept equivalent module caches from different
https://github.com/arsenm updated
https://github.com/llvm/llvm-project/pull/90925
>From 4760ebce0ff7725f4bb75f5107f551d867e4db6d Mon Sep 17 00:00:00 2001
From: Ellis Hoag
Date: Thu, 2 May 2024 17:47:38 -0700
Subject: [PATCH 1/4] [modules] Accept equivalent module caches from different
symlink
jhuber6 wrote:
>
> Maybe. The message is emitted on the host, so there is something wrong with
> the host code or runtime library.
This might be some issue with the host codegen actually.
```console
> clang malloc.c -fopenmp -fopenmp-targets=x86_64-pc-linux-gnu
>
@@ -633,36 +631,36 @@ example:
// module M's interface, so is discarded
int c = use_h(); // OK
-In the above example, the function definition of ``N::g`` is elided from the
Reduced
-BMI of ``M.cppm``. Then the use of ``use_g`` in
@@ -400,24 +389,27 @@ And the compilation process for module units are like:
mod1.cppm -> clang++ mod1.cppm ... -> mod1.pcm --,--> clang++
mod1.pcm ... -> mod1.o -+
src2.cpp +> clang++
src2.cpp --->
https://github.com/PiotrZSL closed
https://github.com/llvm/llvm-project/pull/88735
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Edwin Vane
Date: 2024-05-07T21:06:51+02:00
New Revision: b1bc1dbea6d0423813bb73d625c6eedc040007ed
URL:
https://github.com/llvm/llvm-project/commit/b1bc1dbea6d0423813bb73d625c6eedc040007ed
DIFF:
https://github.com/llvm/llvm-project/commit/b1bc1dbea6d0423813bb73d625c6eedc040007ed.diff
@@ -312,75 +300,76 @@ So all of the following name is not valid by default:
__test
// and so on ...
-If you still want to use the reserved module names for any reason, use
-``-Wno-reserved-module-identifier`` to suppress the warning.
+Using a reserved module name is
sdkrystian wrote:
This seems to cause a crash in lldb in
`ClassTemplateSpecializationDecl::getSourceRange()`... investigating
https://github.com/llvm/llvm-project/pull/81642
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/sdkrystian updated
https://github.com/llvm/llvm-project/pull/90760
>From e5e0f25de3307128914b6fcfc9223b389e7b6438 Mon Sep 17 00:00:00 2001
From: Krystian Stasiowski
Date: Wed, 1 May 2024 10:54:12 -0400
Subject: [PATCH 1/5] [Clang][Sema] Explicit template arguments are not
https://github.com/jhuber6 approved this pull request.
Hopefully in the future we can handle this in the linker better.
https://github.com/llvm/llvm-project/pull/85672
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/sdkrystian closed
https://github.com/llvm/llvm-project/pull/81642
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
alexey-bataev wrote:
> > > > > ```llvm
> > > > > struct.anon
> > > > > ```
> > > >
> > > >
> > > > Can you provide full IR dump here?
> > >
> > >
> > > https://godbolt.org/z/48h5s3W6v
> >
> >
> > It does not look like the issue of the target code, I don't see any wrong
> > access for
https://github.com/sdkrystian updated
https://github.com/llvm/llvm-project/pull/90760
>From e5e0f25de3307128914b6fcfc9223b389e7b6438 Mon Sep 17 00:00:00 2001
From: Krystian Stasiowski
Date: Wed, 1 May 2024 10:54:12 -0400
Subject: [PATCH 1/5] [Clang][Sema] Explicit template arguments are not
b-sumner wrote:
Looks good to me.
https://github.com/llvm/llvm-project/pull/85672
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mjklemm wrote:
@tblah Ping :-)
https://github.com/llvm/llvm-project/pull/90886
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/tlively closed
https://github.com/llvm/llvm-project/pull/90906
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Brendan Dahl
Date: 2024-05-07T11:33:10-07:00
New Revision: 1a2a1fbd7c03381fe5e4f459f7081bef13366ef4
URL:
https://github.com/llvm/llvm-project/commit/1a2a1fbd7c03381fe5e4f459f7081bef13366ef4
DIFF:
https://github.com/llvm/llvm-project/commit/1a2a1fbd7c03381fe5e4f459f7081bef13366ef4.diff
jhuber6 wrote:
> > > > ```llvm
> > > > struct.anon
> > > > ```
> > >
> > >
> > > Can you provide full IR dump here?
> >
> >
> > https://godbolt.org/z/48h5s3W6v
>
> It does not look like the issue of the target code, I don't see any wrong
> access for __context. Мост probably something
hvdijk wrote:
Thanks for doing this, it's unfortunate that Clang is in a rather broken state
with these types right now and it will be good to see improvement. I think the
approach you're taking here is the only approach that will work.
https://github.com/llvm/llvm-project/pull/91364
alexey-bataev wrote:
> > > ```llvm
> > > struct.anon
> > > ```
> >
> >
> > Can you provide full IR dump here?
>
> https://godbolt.org/z/48h5s3W6v
It does not look like the issue of the target code, I don't see any wrong
access for __context. Мост probably something wrong with the host
mizvekov wrote:
Oh I see the code already includes workaround for GCC vs non-GCC. It's possible
in this case you may replace the workaround with a check for the feature
testing macro.
But if this is a new ambiguity not covered by any of the cases I am tracking,
it could still be worthwhile
@@ -1,14 +1,17 @@
// RUN: %clang_cc1 %s -triple=amdgcn-amd-amdhsa -std=c++11 -emit-llvm -o %t.ll
-O1 -disable-llvm-passes -fms-extensions -fstrict-vtable-pointers
+// RUN: %clang_cc1 %s -triple i686-pc-win32 -emit-llvm -o %t.ms.ll -O1
-disable-llvm-passes -fms-extensions
smithp35 wrote:
Thanks for the additional context. My main concern is that we're undoing the
consensus of https://reviews.llvm.org/D45164 which if I've understood the
comments properly was "There is a reasonable expectation that compiled (not
assembled) code should be identical, or at least
@@ -1989,6 +1989,14 @@ llvm::Value *CodeGenFunction::EmitLoadOfScalar(Address
Addr, bool Volatile,
return EmitAtomicLoad(AtomicLValue, Loc).getScalarVal();
}
+ if (const auto *BIT = Ty->getAs()) {
+if (BIT->getNumBits() > 128) {
hvdijk wrote:
For
mizvekov wrote:
> Hi, is there a way to make a compile-time check for this feature?
Yes, this is exposed by a standard feature testing macro:
https://en.cppreference.com/w/cpp/feature_test#cpp_template_template_args
>
> Looking at
>
Thanks for reporting this. A few questions:
* Does
@@ -8,79 +8,60 @@ Standard C++ Modules
Introduction
-The term ``modules`` has a lot of meanings. For the users of Clang, modules may
-refer to ``Objective-C Modules``, ``Clang C++ Modules`` (or ``Clang Header
Modules``,
-etc.) or ``Standard C++ Modules``. The
efriedma-quic wrote:
I don't think FPGA folks will run into any practical issue with this; this only
impacts the in-memory types, and backends shouldn't really be using in-memory
types for anything anyways.
https://github.com/llvm/llvm-project/pull/91364
erichkeane wrote:
> > It seems to me this is a case where we're trying to work -around an llvm
> > bug? Should we just be fixing that instead?
>
> You mean, revert https://reviews.llvm.org/D86310 ? Making any changes in LLVM
> here is painful; I'd rather not revisit that. CC @hvdijk @rnk
I
efriedma-quic wrote:
> It seems to me this is a case where we're trying to work -around an llvm bug?
> Should we just be fixing that instead?
You mean, revert https://reviews.llvm.org/D86310 ? Making any changes in LLVM
here is painful; I'd rather not revisit that. CC @hvdijk @rnk
eaeltsin wrote:
Hi, is there a way to make a compile-time check for this feature?
Looking at
1.
https://github.com/xtensor-stack/xtensor/blob/master/include/xtensor/xutils.hpp#L1029
2.
https://github.com/xtensor-stack/xtensor/blob/master/include/xtensor/xstorage.hpp#L1415
After this commit,
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/90237
>From a75aa14fcad6f346a3073ae88e91fa890e803422 Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Fri, 26 Apr 2024 13:12:51 -0400
Subject: [PATCH 1/2] Revise the modules document for clarity
The intention
@@ -5348,6 +5348,13 @@ Value *ScalarExprEmitter::VisitVAArgExpr(VAArgExpr *VE) {
return llvm::UndefValue::get(ArgTy);
}
+ if (const auto *BIT = Ty->getAs()) {
+if (BIT->getNumBits() > 128) {
efriedma-quic wrote:
This seems a little fragile;
https://github.com/efriedma-quic commented:
Maybe add a helper somewhere to check "is this type a bitint wider than 128
bits"?
https://github.com/llvm/llvm-project/pull/91364
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/91364
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1774,6 +1774,18 @@ llvm::Constant
*ConstantEmitter::emitForMemory(CodeGenModule ,
return Res;
}
+ if (const auto *BIT = destType->getAs()) {
+if (BIT->getNumBits() > 128) {
+ // Long _BitInt has array of bytes as in-memory type.
+
https://github.com/erichkeane commented:
This is unfortunate, and will likely result in the FPGAs needing to generate
extra bits here, so this is somewhat harmful in that regard.
It seems to me this is a case where we're trying to work -around an llvm bug?
Should we just be fixing that
https://github.com/erichkeane approved this pull request.
happy now :)
https://github.com/llvm/llvm-project/pull/88963
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
llvmbot wrote:
@llvm/pr-subscribers-clang
@llvm/pr-subscribers-clang-codegen
Author: Mariya Podchishchaeva (Fznamznon)
Changes
Currently for i128:128 targets correct implementation is possible either for
__int128 or for _BitInt(129+) with lowering to iN, but not both. Since we have
now
https://github.com/Fznamznon created
https://github.com/llvm/llvm-project/pull/91364
Currently for i128:128 targets correct implementation is possible either for
__int128 or for _BitInt(129+) with lowering to iN, but not both. Since we have
now correct implementation of __int128 in place
101 - 200 of 488 matches
Mail list logo
