https://github.com/hvdijk updated
https://github.com/llvm/llvm-project/pull/110899
>From a334eb150b2d47e7e7cf13123f01c4513832e848 Mon Sep 17 00:00:00 2001
From: Harald van Dijk
Date: Wed, 2 Oct 2024 18:14:38 +0100
Subject: [PATCH] [RecursiveASTVisitor] Skip implicit instantiations.
In DEF_TRAV
@@ -2069,22 +2069,24 @@ bool
RecursiveASTVisitor::TraverseTemplateArgumentLocsHelper(
#define DEF_TRAVERSE_TMPL_SPEC_DECL(TMPLDECLKIND, DECLKIND)
\
DEF_TRAVERSE_DECL(TMPLDECLKIND##TemplateSpecializationDecl, {
\
+auto TSK = D->getTemp
@@ -2069,22 +2069,24 @@ bool
RecursiveASTVisitor::TraverseTemplateArgumentLocsHelper(
#define DEF_TRAVERSE_TMPL_SPEC_DECL(TMPLDECLKIND, DECLKIND)
\
DEF_TRAVERSE_DECL(TMPLDECLKIND##TemplateSpecializationDecl, {
\
+auto TSK = D->getTemp
@@ -2069,22 +2069,24 @@ bool
RecursiveASTVisitor::TraverseTemplateArgumentLocsHelper(
#define DEF_TRAVERSE_TMPL_SPEC_DECL(TMPLDECLKIND, DECLKIND)
\
DEF_TRAVERSE_DECL(TMPLDECLKIND##TemplateSpecializationDecl, {
\
+auto TSK = D->getTemp
https://github.com/hvdijk created
https://github.com/llvm/llvm-project/pull/110899
In DEF_TRAVERSE_TMPL_SPEC_DECL, we attempted to skip implicit instantiations by
detecting that D->getTemplateArgsAsWritten() returns nullptr, but as this test
shows, it is possible for that to return a non-null
hvdijk wrote:
> > Apologies, but I'm having a bit of trouble understanding the scenario that
> > this PR addresses.
>
> Nixpkgs adds the tools being used to `$PATH` so find program needs to use
> path.
This PR enables inadvertent errors on non-Nix systems though. When a specific
LLVM path is
hvdijk wrote:
Apologies, but I'm having a bit of trouble understanding the scenario that this
PR addresses. It looks like it's meant to handle the case where
`LLVM_TOOLS_BINARY_DIR` does not contain the LLVM binaries, is that right? In
that case, why can `LLVM_TOOLS_BINARY_DIR` not instead be
@@ -55,7 +55,7 @@ if( LIBCLC_STANDALONE_BUILD OR CMAKE_SOURCE_DIR STREQUAL
CMAKE_CURRENT_SOURCE_DI
# Import required tools
if( NOT EXISTS ${LIBCLC_CUSTOM_LLVM_TOOLS_BINARY_DIR} )
foreach( tool IN ITEMS clang llvm-as llvm-link opt )
- find_program( LLVM_TOOL_${tool
hvdijk wrote:
Both buildbot failures appear to be unrelated to this PR: neither fails in
libclc, the first has resolved itself and passes in later attempts, the second
looks like the builder has just run out of disk space. If I am wrong and there
is something I should look into please let me k
https://github.com/hvdijk closed https://github.com/llvm/llvm-project/pull/97811
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
hvdijk wrote:
ping
https://github.com/llvm/llvm-project/pull/97811
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
hvdijk wrote:
The SPIRV-LLVM-Translator change that this depended on has been merged, so this
PR no longer depends on external changes.
https://github.com/llvm/llvm-project/pull/97811
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lis
https://github.com/hvdijk edited https://github.com/llvm/llvm-project/pull/97811
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/hvdijk created
https://github.com/llvm/llvm-project/pull/97811
* Move the setup_host_tool calls to the directories of their tool. Although it
works to call it in libclc, it can only appear in a single location so it fails
the "what if everyone did this?" test and causes prob
https://github.com/hvdijk closed https://github.com/llvm/llvm-project/pull/97392
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/hvdijk created
https://github.com/llvm/llvm-project/pull/97392
When performing cross in-tree builds, we need native versions of various tools,
we cannot assume the cross builds that are part of the current build are
executable. LLVM provides the setup_host_tool function to h
https://github.com/hvdijk closed https://github.com/llvm/llvm-project/pull/94976
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/hvdijk created
https://github.com/llvm/llvm-project/pull/94976
The SVE diagnostics were guarded by a FD->hasBody() check that prevented the
diagnostic from being emitted for code that still triggered the backend crashes
that the errors were meant to avoid, because FD->hasBod
https://github.com/hvdijk updated
https://github.com/llvm/llvm-project/pull/94229
>From 895f71d5f890a3988014e0d779586b9f142be90f Mon Sep 17 00:00:00 2001
From: Harald van Dijk
Date: Mon, 3 Jun 2024 15:03:17 +0100
Subject: [PATCH] [SYCL] Allow neon attributes for ARM host
We permit neon attribu
https://github.com/hvdijk created
https://github.com/llvm/llvm-project/pull/94229
We permit neon attributes in CUDA device code, but this permission was only for
CUDA device code. The same permission makes sense for SYCL device code as well,
especially now that neon attributes are used in glib
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
_
@@ -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
https://github.com/hvdijk closed https://github.com/llvm/llvm-project/pull/88873
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -645,7 +645,7 @@ LazyValueInfoImpl::solveBlockValueImpl(Value *Val,
BasicBlock *BB) {
// instruction is placed, even if it could legally be hoisted much higher.
// That is unfortunate.
PointerType *PT = dyn_cast(BBI->getType());
- if (PT && isKnownNonZero(BBI, DL))
+
https://github.com/hvdijk created
https://github.com/llvm/llvm-project/pull/88873
Prior to #85863, the required parameters of llvm::isKnownNonZero were Value and
DataLayout. After, they are Value, Depth, and SimplifyQuery, where
SimplifyQuery is implicitly constructible from DataLayout. The ch
@@ -645,7 +645,7 @@ LazyValueInfoImpl::solveBlockValueImpl(Value *Val,
BasicBlock *BB) {
// instruction is placed, even if it could legally be hoisted much higher.
// That is unfortunate.
PointerType *PT = dyn_cast(BBI->getType());
- if (PT && isKnownNonZero(BBI, DL))
+
@@ -645,7 +645,7 @@ LazyValueInfoImpl::solveBlockValueImpl(Value *Val,
BasicBlock *BB) {
// instruction is placed, even if it could legally be hoisted much higher.
// That is unfortunate.
PointerType *PT = dyn_cast(BBI->getType());
- if (PT && isKnownNonZero(BBI, DL))
+
@@ -0,0 +1,66 @@
+//===- SemaOpenACC.h 000- Semantic Analysis for SYCL constructs
---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apa
@@ -271,6 +271,9 @@ Improvements to Clang's diagnostics
- Clang now correctly diagnoses no arguments to a variadic macro parameter as
a C23/C++20 extension.
Fixes #GH84495.
+- ``-Wmicrosoft`` or ``-Wgnu`` is now required to diagnose C99 flexible
+ array members in a union
https://github.com/hvdijk approved this pull request.
Looks good to me, thanks, aside from one typo in the release notes. Let me
pre-emptively mark this as approved. Just to confirm, the warnings are also
enabled by `-pedantic`? Is that worth mentioning in the release notes too? I'm
fine if yo
@@ -21,10 +27,76 @@ struct __attribute((packed, aligned(4))) { char a; int x;
char z[]; } e = { 1, 2
struct { int x; char y[]; } f = { 1, { 13, 15 } };
// CHECK: @f ={{.*}} global <{ i32, [2 x i8] }> <{ i32 1, [2 x i8] c"\0D\0F" }>
-union {
- struct {
-int a;
-char b
hvdijk wrote:
Flexible array initialization is, roughly, implemented as building a different
type in which the flexible array member is replaced by an array of the right
size, initializing that, and then pretending it was the original type. It does
not surprise me too much that this does not w
hvdijk wrote:
The problem with `union { char x[]; } x = {0};` is in
`ConstStructBuilder::Build` ( `clang/lib/CodeGen/CGExprConstant.cpp`). It does:
```diff
// If this is a union, skip all the fields that aren't being initialized.
if (RD->isUnion() &&
!declaresSameEntity(ILE->getI
@@ -1,13 +1,158 @@
-// RUN: %clang_cc1 %s -verify=c -fsyntax-only
-// RUN: %clang_cc1 %s -verify -fsyntax-only -x c++
-// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility
-// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility -x c++
+// RUN: %clang_cc1 %s -veri
@@ -1,13 +1,58 @@
-// RUN: %clang_cc1 %s -verify=c -fsyntax-only
+// RUN: %clang_cc1 %s -verify -fsyntax-only
// RUN: %clang_cc1 %s -verify -fsyntax-only -x c++
-// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility
// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compa
@@ -1,13 +1,58 @@
-// RUN: %clang_cc1 %s -verify=c -fsyntax-only
+// RUN: %clang_cc1 %s -verify -fsyntax-only
// RUN: %clang_cc1 %s -verify -fsyntax-only -x c++
-// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility
// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compa
https://github.com/hvdijk closed https://github.com/llvm/llvm-project/pull/81175
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
hvdijk wrote:
> I would really like to avoid Clang 18 being released in this broken state, if
> possible, and I see no way short of a revert to realistically achieve that.
It's too late for that now, it's out there, and it's now everybody else's
problem regardless of what Clang does in the fut
hvdijk wrote:
That would be nice, but that will take time, and I did wait months already
before creating this PR. Leaving Clang in its current state until someone steps
up to fix it, in my opinion, does a massive disservice to users.
If code is written to use `_BitInt`, and it correctly uses c
hvdijk wrote:
> At least that shouldn't be a problem: LLVM has separate concepts of "store
> size" and "alloc size" where only the latter rounds up to alignment. So `load
> i129` is specified to access only 9 bytes, not 16 bytes.
Sure, but when it appears inside a struct, the memory reserved i
hvdijk wrote:
> It should be technically possible for Clang to give _BitInt(N) an alignment
> that is independent from LLVM's alignment
I'm not sure it's even technically possible: if loading a `_BitInt(129)` from
memory should load 3 bytes, but it is translated to an LLVM IR load of `i129`
t
hvdijk wrote:
> I find your PR description very vague. Please be more specific about which
> ICEs and miscompilations you are concerned about (godbolt please). Is this
> _just_ about the open alignment question, or also something else?
I linked to where one major example had already been provi
https://github.com/hvdijk created
https://github.com/llvm/llvm-project/pull/81175
This reverts commit def720726b73e0d7ab139376ab3ea955f25f4d89.
As noted in #60925 and in D86310, with the current implementation of `_BitInt`
in Clang, we can have either a correct `__int128` implementation, or a
Author: Harald van Dijk
Date: 2023-03-30T02:18:52+01:00
New Revision: 6b868139458d258c1ed4c0279e8f4374556c1c1e
URL:
https://github.com/llvm/llvm-project/commit/6b868139458d258c1ed4c0279e8f4374556c1c1e
DIFF:
https://github.com/llvm/llvm-project/commit/6b868139458d258c1ed4c0279e8f4374556c1c1e.dif
Author: Harald van Dijk
Date: 2022-05-02T18:07:47+01:00
New Revision: fed7be096f8ed5d70029acd712ac19ffc61e04e5
URL:
https://github.com/llvm/llvm-project/commit/fed7be096f8ed5d70029acd712ac19ffc61e04e5
DIFF:
https://github.com/llvm/llvm-project/commit/fed7be096f8ed5d70029acd712ac19ffc61e04e5.dif
Author: Harald van Dijk
Date: 2021-07-15T20:52:25+01:00
New Revision: 66ab8568c485c4dd7461f1acf0e55cd4a7a3b4a0
URL:
https://github.com/llvm/llvm-project/commit/66ab8568c485c4dd7461f1acf0e55cd4a7a3b4a0
DIFF:
https://github.com/llvm/llvm-project/commit/66ab8568c485c4dd7461f1acf0e55cd4a7a3b4a0.dif
Author: Harald van Dijk
Date: 2021-06-07T20:48:39+01:00
New Revision: 75521bd9d8d1e39b1a765a14d95c49291d2adde5
URL:
https://github.com/llvm/llvm-project/commit/75521bd9d8d1e39b1a765a14d95c49291d2adde5
DIFF:
https://github.com/llvm/llvm-project/commit/75521bd9d8d1e39b1a765a14d95c49291d2adde5.dif
Author: Harald van Dijk
Date: 2021-05-05T19:25:34+01:00
New Revision: 7907c46fe6195728fafd843b8c0fb19a3e68e9ad
URL:
https://github.com/llvm/llvm-project/commit/7907c46fe6195728fafd843b8c0fb19a3e68e9ad
DIFF:
https://github.com/llvm/llvm-project/commit/7907c46fe6195728fafd843b8c0fb19a3e68e9ad.dif
Author: Harald van Dijk
Date: 2021-04-01T09:47:56+01:00
New Revision: 1d463c2a386099597a8e2d26b9b964bc8fda8042
URL:
https://github.com/llvm/llvm-project/commit/1d463c2a386099597a8e2d26b9b964bc8fda8042
DIFF:
https://github.com/llvm/llvm-project/commit/1d463c2a386099597a8e2d26b9b964bc8fda8042.dif
Author: Harald van Dijk
Date: 2021-01-25T00:56:45Z
New Revision: f4537935dcdbf390c863591cf556e76c3abab9c1
URL:
https://github.com/llvm/llvm-project/commit/f4537935dcdbf390c863591cf556e76c3abab9c1
DIFF:
https://github.com/llvm/llvm-project/commit/f4537935dcdbf390c863591cf556e76c3abab9c1.diff
LO
50 matches
Mail list logo
