mikaelholmen wrote:
> Did any of the builders caught this, or it is some local configuration?
> Asking just in case if we should create one for catching such CE's.
I saw it locally when compiling with -Wall -Werror. I don't know if any builder
use -Werror? I don't see any sign of it in
https:
https://github.com/mikaelholmen approved this pull request.
LGTM since it solves the warning/error.
https://github.com/llvm/llvm-project/pull/147503
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo
@@ -544,6 +544,9 @@ void ClangTidyDiagnosticConsumer::forwardDiagnostic(const
Diagnostic &Info) {
case clang::DiagnosticsEngine::ak_attr:
Builder << reinterpret_cast(Info.getRawArg(Index));
break;
+case clang::DiagnosticsEngine::ak_attr_info:
--
mikaelholmen wrote:
This solves the compilation warning/error I reported in
https://github.com/llvm/llvm-project/pull/144619#issuecomment-3048327120
https://github.com/llvm/llvm-project/pull/147503
___
cfe-commits mailing list
cfe-commits@lists.llvm.
https://github.com/mikaelholmen edited
https://github.com/llvm/llvm-project/pull/147503
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -544,6 +544,9 @@ void ClangTidyDiagnosticConsumer::forwardDiagnostic(const
Diagnostic &Info) {
case clang::DiagnosticsEngine::ak_attr:
Builder << reinterpret_cast(Info.getRawArg(Index));
break;
+case clang::DiagnosticsEngine::ak_attr_info:
--
mikaelholmen wrote:
Hi @a-tarasyuk ,
With this patch I get the following when building clang-tidy:
```
../../clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp:504:13:
error: enumeration value 'ak_attr_info' not handled in switch [-Werror,-Wswitch]
504 | switch (Kind) {
|
mikaelholmen wrote:
Hello,
With this patch I get
```
Unexpectedly Passed Tests (5):
llvm-libc++-shared.cfg.in ::
libcxx/selftest/modules/std-and-std.compat-module.sh.cpp
llvm-libc++-shared.cfg.in :: libcxx/selftest/modules/std-module.sh.cpp
llvm-libc++-shared.cfg.in :: libcxx/selftest/mod
mikaelholmen wrote:
Hi @egorshamshura and @cor3ntin
It seems like a bunch of libc++ testcases start failing with this patch:
```
Failed Tests (9):
llvm-libc++-shared.cfg.in :: libcxx/selftest/dsl/dsl.sh.py
llvm-libc++-shared.cfg.in ::
libcxx/utilities/expected/expected.expected/and_then.man
mikaelholmen wrote:
@AaronBallman @erichkeane
Apparently we used a clang version from July 2023 to compile clang when the
testcase failed.
I made another try with a later build now and then I don't see the failure
anymore so perhaps something has been fixed. Or it just went hiding but then I
mikaelholmen wrote:
Hi @AaronBallman
I see that if I build clang with ASAN with this patch and run the testcase
```clang/test/C/C99/n590.c```
it crashes and I see this
```
AddressSanitizer:DEADLYSIGNAL
=
==2063954==ERROR: AddressSa
mikaelholmen wrote:
> > The FPEvalMethod warning should have been addressed in #136515, by making
> > the relevant bitfields large enough to actually store the enum, are you
> > still seeing these failures?
>
> Yes, I'm still seeing this warning. The earlier quoted warning was maybe from
> bi
mikaelholmen wrote:
> > I did some downstream testing with "-Og" since this patch and noticed that
> > e.g.
>
> Thanks for catching these - in terms of legalizer support it looks like
> everything relevant is implemented except for `SoftenFloatOperand`, so that
> should be a straightforward f
mikaelholmen wrote:
I did some downstream testing with "-Og" since this patch and noticed that e.g.
```
llc -mtriple=avr bbi-106478.ll
```
crashes with
```
SoftenFloatOperand Op #1: t2: ch = fake_use t0, ConstantFP:f64<0.00e+00>
LLVM ERROR: Do not know how to soften this operator's operand!
@@ -3004,6 +3010,15 @@ void MicrosoftRecordLayoutBuilder::layoutField(const
FieldDecl *FD) {
} else {
FieldOffset = Size.alignTo(Info.Alignment);
}
+
+ uint64_t UnpaddedFielddOffsetInBits =
+ Context.toBits(DataSize) - RemainingBitsInField;
mikae
https://github.com/mikaelholmen edited
https://github.com/llvm/llvm-project/pull/130182
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -3004,6 +3010,15 @@ void MicrosoftRecordLayoutBuilder::layoutField(const
FieldDecl *FD) {
} else {
FieldOffset = Size.alignTo(Info.Alignment);
}
+
+ uint64_t UnpaddedFielddOffsetInBits =
+ Context.toBits(DataSize) - RemainingBitsInField;
mikae
mikaelholmen wrote:
If I compile clang with clang (18.1.8) the new windows-Wpadded.cpp testcase
fails for me like
```
error: 'expected-warning' diagnostics seen but not expected:
File /repo/clang/test/SemaCXX/windows-Wpadded.cpp Line 20: padding struct
'Derived' with 2 bits to align 'c'
1 er
mikaelholmen wrote:
> If I compile clang with clang (18.1.8) the new windows-Wpadded.cpp testcase
> fails for me like
>
> ```
> error: 'expected-warning' diagnostics seen but not expected:
> File /repo/clang/test/SemaCXX/windows-Wpadded.cpp Line 20: padding struct
> 'Derived' with 2 bits to
https://github.com/mikaelholmen approved this pull request.
Thanks, LGTM!
https://github.com/llvm/llvm-project/pull/131617
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,201 @@
+//===- EntryPointStats.cpp --*- C++
-*-===//
+//
+// 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: Ap
mikaelholmen wrote:
I've verified that this patch solves the problem I saw. Thanks!
https://github.com/llvm/llvm-project/pull/129224
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mikaelholmen wrote:
Hello @balazs-benics-sonarsource
The following starts crashing with this patch:
```clang --analyze bbi-104578.c```
It crashes with
```
clang: ../../clang/lib/StaticAnalyzer/Core/RegionStore.cpp:375:
LimitedRegionBindingsRef LimitedRegionBindingsRef::addBinding(BindingKey, S
mikaelholmen wrote:
Done already in e1cc5e9f9ab628f5
https://github.com/llvm/llvm-project/pull/128499
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,23 @@
+// RUN: %clang_cc1 -finclude-default-header -triple \
+// RUN: dxil-pc-shadermodel6.3-library %s \
+// RUN: -emit-llvm -O1 -verify
mikaelholmen wrote:
Looks like this testcase will write to the current directory. This may
potentially be wri
mikaelholmen wrote:
> FYI I just
> [merged](https://github.com/llvm/llvm-project/commit/f378e52ed3c6f8da4973f97f1ef043c2eb0da721)
> my second attempt of enabling and fixing the flaky test. Let me know if it
> works. @metaflow @mikaelholmen
No failures so far :)
https://github.com/llvm/llvm-p
mikaelholmen wrote:
Hi,
Heads up that I see a miscompile with this patch where a needed store is
removed. I'll try to extract some kind of reproducer.
https://github.com/llvm/llvm-project/pull/125880
___
cfe-commits mailing list
cfe-commits@lists.llv
https://github.com/mikaelholmen approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/127034
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mikaelholmen wrote:
> > Unfortunately the test still seems to be flaky. With EXPENSIVE_CHECKS I
> > often see it fail on the RHEL8 x86_64 machines I use.
> > E.g.
> > ```
> > FAIL: Clang :: Analysis/live-stmts.cpp (1 of 1)
> > TEST 'Clang :: Analysis/live-stmts.cpp' FAILED
mikaelholmen wrote:
Unfortunately the test still seems to be flaky. With EXPENSIVE_CHECKS I often
see it fail on the RHEL8 x86_64 machines I use.
E.g.
```
FAIL: Clang :: Analysis/live-stmts.cpp (1 of 1)
TEST 'Clang :: Analysis/live-stmts.cpp' FAILED
Exi
@@ -830,6 +830,16 @@ bool OverlayCDB::setCompileCommand(PathRef File,
return true;
}
+std::unique_ptr
+OverlayCDB::getProjectModules(PathRef File) const {
+ auto MDB = DelegatingCDB::getProjectModules(File);
+ MDB->setCommandMangler([&Mangler = Mangler](tooling::CompileCom
@@ -830,6 +830,16 @@ bool OverlayCDB::setCompileCommand(PathRef File,
return true;
}
+std::unique_ptr
+OverlayCDB::getProjectModules(PathRef File) const {
+ auto MDB = DelegatingCDB::getProjectModules(File);
+ MDB->setCommandMangler([&Mangler = Mangler](tooling::CompileCom
mikaelholmen wrote:
Thanks @nico !
https://github.com/llvm/llvm-project/pull/120507
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mikaelholmen wrote:
> LLVM Buildbot has detected a new failure on builder `fuchsia-x86_64-linux`
> running on `fuchsia-debian-64-us-central1-a-1` while building `clang,llvm` at
> step 4 "annotate".
>
> Full details are available at:
> https://lab.llvm.org/buildbot/#/builders/11/builds/10589
>
mikaelholmen wrote:
Thanks!
https://github.com/llvm/llvm-project/pull/118154
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,50 @@
+// RUN: %clang_cc1 -ffreestanding %s -Wno-implicit-function-declaration
-triple=i386-- -target-feature +movrs -target-feature +avx10.2-512 -emit-llvm
-verify
mikaelholmen wrote:
Thanks!
https://github.com/llvm/llvm-project/pull/113274
___
@@ -0,0 +1,98 @@
+// RUN: %clang_cc1 -ffreestanding %s -Wno-implicit-function-declaration
-triple=i386-unknown-unknown -target-feature +movrs -target-feature
+avx10.2-256 -emit-llvm -verify
mikaelholmen wrote:
Same thing here, can we remove "-emit-llvm" since w
@@ -0,0 +1,50 @@
+// RUN: %clang_cc1 -ffreestanding %s -Wno-implicit-function-declaration
-triple=i386-- -target-feature +movrs -target-feature +avx10.2-512 -emit-llvm
-verify
mikaelholmen wrote:
Since we don't care about the actual output, can we remove "-emit
mikaelholmen wrote:
Already fixed in 2954d1f7bc8f
```
[include-cleaner] Fix -Wpessimizing-move in IncludeCleaner.cpp (NFC)
/llvm-project/clang-tools-extra/include-cleaner/tool/IncludeCleaner.cpp:302:14:
error: moving a temporary object prevents copy elision
[-Werror,-Wpessimizi
mikaelholmen wrote:
Hi,
I bisected a crash to this patch. I can't share the C reproducer but it's
instcombine that crashes and a reduced reproducer for that is
```opt -passes=instcombine bbi-99792.ll -o /dev/null```
[bbi-99792.ll.gz](https://github.com/user-attachments/files/17253640/bbi-99792
mikaelholmen wrote:
Thanks @kadircet
https://github.com/llvm/llvm-project/pull/70976
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mikaelholmen wrote:
Hello,
I noticed that before this patch
```clang empty.c -fsanitize=undefined -ffine-grained-bitfield-accesses -c
-Werror```
(on empty file empty.c) resulted in
```warning: option '-ffine-grained-bitfield-accesses' cannot be enabled
together with a sanitizer; flag ignored``
@@ -278,6 +278,13 @@ class SMTConstraintManager : public
clang::ento::SimpleConstraintManager {
if (const SymbolCast *SC = dyn_cast(Sym))
return canReasonAbout(SVB.makeSymbolVal(SC->getOperand()));
+// If a UnarySymExpr is encountered, the Z3
+// wrapper doe
mikaelholmen wrote:
Hello,
I noticed that before this patch
```clang empty.c -fsanitize=undefined -ffine-grained-bitfield-accesses -c
-Werror```
(on empty file empty.c) resulted in
```warning: option '-ffine-grained-bitfield-accesses' cannot be enabled
together with a sanitizer; flag ignored``
@@ -0,0 +1,52 @@
+// RUN: %clang_cc1 -flax-vector-conversions=none -ffreestanding %s
-triple=i386-unknown-unknown -target-feature +avx10.2-512 -emit-llvm -Wall
-Werror -verify
mikaelholmen wrote:
Can we remove "-emit-llvm" from this test (and others in this pat
mikaelholmen wrote:
> > Btw a question about the new warning: So with
> > -Wunsafe-buffer-usage-in-libc-call clang now warns on the following?
> > ```
> > #include
> >
> > void foo(void) {
> > char q[10];
> > snprintf(q, 10, "%s", "hello");
> > }
> > ```
> >
> >
> >
> >
> >
mikaelholmen wrote:
Btw a question about the new warning: So with
-Wunsafe-buffer-usage-in-libc-call clang now warns on the following?
```
#include
void foo(void) {
char q[10];
snprintf(q, 10, "%s", "hello");
}
```
It says
```
foo.c:5:3: warning: function 'snprintf' is unsafe
[-Wunsafe-bu
mikaelholmen wrote:
> We're seeing a crash with this patch when compiling with -Weverything.
>
> ```
> clang: ../../clang/include/clang/AST/Expr.h:3026: const clang::Expr
> *clang::CallExpr::getArg(unsigned int) const: Assertion `Arg < getNumArgs()
> && "Arg access out of range!"' failed.
> ``
mikaelholmen wrote:
We're seeing a crash with this patch when compiling with -Weverything.
```
clang: ../../clang/include/clang/AST/Expr.h:3026: const clang::Expr
*clang::CallExpr::getArg(unsigned int) const: Assertion `Arg < getNumArgs() &&
"Arg access out of range!"' failed.
```
I'm working o
mikaelholmen wrote:
Hello,
The following starts crashing with this patch:
```
clang -cc1 -analyze -analyzer-checker=core bbi-98571.c
```
Result:
```
bbi-98571.c:2:14: warning: expected ';' at end of declaration list
2 | struct a *b
| ^
| ;
bbi-98571.c:
@@ -9955,6 +9955,45 @@ void ASTReader::finishPendingActions() {
}
PendingDefinitions.clear();
+ for (auto [D, Previous] : PendingWarningForDuplicatedDefsInModuleUnits) {
+auto hasDefinitionImpl = [this](Decl *D, auto hasDefinitionImpl) {
+ if (auto *VD = dyn_cast
mikaelholmen wrote:
We also see the ASan complaints on ```Parser/parser_overflow.c``` in downstream
bots for several days now.
A workaround would be appreciated if a real fix is hard.
https://github.com/llvm/llvm-project/pull/104717
___
cfe-commits ma
mikaelholmen wrote:
Hi @pskrgag
The following starts crashing with this patch:
```
clang -cc1 -analyze -analyzer-checker=core bbi-98183.c
```
It crashes like:
```
clang:
../../clang/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h:1212:
clang::ento::ElementRegion::ElementRegion(cla
mikaelholmen wrote:
> @mikaelholmen I can't reproduce this on commit
> [e40915b](https://github.com/llvm/llvm-project/commit/e40915b7407eda4b370658da5c9606e310b55d19)
> with `-DLLVM_USE_SANITIZER=Undefined`. Kindly let me know how to reproduce
> this.
>
> Looking from the code, I suspect that
@@ -0,0 +1,31 @@
+// RUN: %clang_cc1 -finclude-default-header -triple
dxil-pc-shadermodel6.6-library %s -fnative-half-type -emit-llvm
-disable-llvm-passes -verify -verify-ignore-unexpected
mikaelholmen wrote:
Hi @bob80905
I think this "-emit-llvm -disable-llvm
mikaelholmen wrote:
I noticed that if I compile opt with UBSan enabled on this patch and then run
```
opt -passes=objc-arc-contract bbi-98007.ll -o /dev/null
```
we get an UBSan complaint like
```
../lib/Transforms/ObjCARC/ObjCARCContract.cpp:105:39: runtime error: load of
value 255, which is no
mikaelholmen wrote:
> @mikaelholmen Please approve the revert PR then.
Done. Thank you!
https://github.com/llvm/llvm-project/pull/95128
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mikaelholmen approved this pull request.
Thanks!
https://github.com/llvm/llvm-project/pull/95916
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mikaelholmen wrote:
> > I don't know really, I just noticed that main suddenly broke for us and
> > bisected to this patch.
>
> If after the second patch the tests pass then I'm contemplated to say I'd go
> for upgrading Z3 requirements to 4.8.9, and accept that with my first commit
> would h
mikaelholmen wrote:
I don't know really, I just noticed that main suddenly broke for us and
bisected to this patch.
https://github.com/llvm/llvm-project/pull/95128
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/
mikaelholmen wrote:
With the next patch eacc3b3504be061 it fails on rlimit for me, but on this
patch it's on timeout.
https://github.com/llvm/llvm-project/pull/95128
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-b
mikaelholmen wrote:
It seems to be the following tests
```
FalsePositiveRefutationBRVisitorTestBase.UnSatInTheMiddleNoReport
FalsePositiveRefutationBRVisitorTestBase.UnSatAtErrorNodeDueToRefinedConstraintNoReport
FalsePositiveRefutationBRVisitorTestBase.UnSatAtErrorNodeWithNewSymbolNoReport
```
a
mikaelholmen wrote:
> > Hi @steakhal and @NagyDonat ,
> > Does this patch have requirements on the Z3 version?
> > I get
> > `LLVM ERROR: Z3 error: unknown parameter 'timeout'`
> > for the following testcases
> > ```
> > Failed Tests (3):
> > Clang-Unit :: StaticAnalyzer/./StaticAnalysisTests/2
mikaelholmen wrote:
Hi @steakhal and @NagyDonat ,
Does this patch have requirements on the Z3 version?
I get
```LLVM ERROR: Z3 error: unknown parameter 'timeout'```
for the following testcases
```
Failed Tests (3):
Clang-Unit :: StaticAnalyzer/./StaticAnalysisTests/24/188
Clang-Unit :: Stat
On Thu, 2020-06-04 at 13:06 +0300, Kadir Çetinkaya wrote:
> Hi Mikael,
>
> sent out 4f4a8ae72e95f2c7fa5e4ca56dd6b1a83a304680, please let me know
> if it helps!
Hi,
Yes, now it's silent.
Thank you!
/Mikael
>
> On Thu, Jun 4, 2020 at 12:40 PM Mikael Holmén via Phabricator <
> revi...@reviews.l
On Thu, 2020-04-23 at 17:46 +0300, Kadir Çetinkaya wrote:
> Thanks Mikael, sent out an ugly fix
> at 89cb5d558895706e053bc3af972aa5b15aa82863 to get sanitizer build
> bots running.
>
Nice, thanks! Now our buildbots went silent again.
/Mikael
> Will change the testing scheme for a proper fix.
>
Hi Kadir,
I start seeing some sanitizer complaints with this commit for the
following two testcases:
./ClangdTests/PreamblePatchTest.ContainsNewIncludes
./ClangdTests/PreamblePatchTest.IncludeParsing
The complaints look like this:
=
On Fri, 2020-04-17 at 15:02 +0300, Kadir Çetinkaya wrote:
> Thanks Mikael,
>
> 66b54d586fa73499714e2bfef3cedffeabb08f34 should fix this.
>
Yep, now it runs without complaints.
Thanks!
/Mikael
> On Fri, Apr 17, 2020 at 2:42 PM Mikael Holmén <
> mikael.hol...@ericsson.com> wrote:
> > Hi Kadir,
>
Hi Kadir,
I noticed in our buildbots that run with sanitizers that we got a new
complaint with this commit. It's still there on current top-of-tree now
so the fixes you pushed after this patch doesn't seem to address this
one:
==89727==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 1
We see flakiness in the test in our bots too. Fails one time and then
passes again.
/Mikael
On Mon, 2020-04-06 at 21:03 -0400, Nico Weber via cfe-commits wrote:
> This isn't bot-dependent, it's been flaking on many different bots
> over the last few days. Here's one from just now:
> http://lab.l
Hi Hokein, Ilya,
Clang warns on this code when compiled without asserts:
../../clang/lib/AST/TemplateName.cpp:189:3: error: unannotated fall-
through between switch labels [-Werror,-Wimplicit-fallthrough]
default:
^
../../clang/lib/AST/TemplateName.cpp:189:3: note: insert 'break;' to
avoid fa
gt; Hi,
>>
>> As Karl-Johan said I'll be out of office for a few days so please submit a
>> fix if you can find the time.
>>
>> Thanks,
>> Mikael
>>
>> Den 26 sep. 2019 15:39 skrev Hans Wennborg :
>>
>> On Thu, Sep 26, 2019 at 12:55
Hi,
As Karl-Johan said I'll be out of office for a few days so please submit a fix
if you can find the time.
Thanks,
Mikael
Den 26 sep. 2019 15:39 skrev Hans Wennborg :
On Thu, Sep 26, 2019 at 12:55 PM Mikael Holmén via cfe-commits
wrote:
>
> Hi Hans,
>
> I'm a bit suspi
Hi Hans,
I'm a bit suspicious against the part
> This also revertes the part of r369938 which checked that
-working-directory works.
in this revert.
You do:
> + SmallString<128> Buf;
> + if (!llvm::sys::fs::current_path(Buf))
> +Buf = ".";
> + CDB << "{ \"directory\": \"" << escap
Fixed the testcase in r372944.
On 2019-09-26 08:14, Mikael Holmén via cfe-commits wrote:
> Hi,
>
> On 2019-09-26 03:16, Evgenii Stepanov via cfe-commits wrote:
>> Hi,
>>
>> this change breaks the build with
>>
>> /var/lib/buildbot/sanitizer-buildbot6/sa
Hi,
On 2019-09-26 03:16, Evgenii Stepanov via cfe-commits wrote:
> Hi,
>
> this change breaks the build with
>
> /var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/llvm-project/clang/lib/Format/Format.cpp:737:44:
> error: missing field 'SortPriority' initializer
> [-Werror,
Hi Adam,
Is InfiniteLoopCheck.cpp missing?
I get
CMake Error at /data/repo/master/llvm/cmake/modules/AddLLVM.cmake:443
(add_library):
Cannot find source file:
InfiniteLoopCheck.cpp
/Mikael
On Tue, 2019-09-24 at 07:43 +, Adam Balogh via cfe-commits wrote:
> Author: baloghadamsoftwa
Hi,
On 2019-07-15 20:26, Jan Korous wrote:
> Hi Mikael,
>
> Thanks for the notice.
>
> How about this?
> https://reviews.llvm.org/D64764
>
Yes that works for me!
Thanks!
Mikael
> Jan
>
>> On Jul 14, 2019, at 11:45 PM, Mikael Holmén
>> mailto:mikael.hol...@ericsson.com>> wrote:
>>
>> Hi Jan
Hi Jan,
> +elseif(CMAKE_SYSTEM_NAME MATCHES "Linux")
> + check_include_files("sys/inotify.h" HAVE_INOTIFY)
> + if(HAVE_INOTIFY)
> +list(APPEND DIRECTORY_WATCHER_SOURCES
linux/DirectoryWatcher-linux.cpp)
> +find_package(Threads REQUIRED)
> + endif()
I don't think the above is eno
PAssed on our bots too.
Thanks!
/Mikael
On 2/13/19 10:03 PM, Galina Kistanova wrote:
> Passed on llvm-clang-x86_64-expensive-checks-win and
> llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast.
>
> http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/15787
> http://lab.
On 2/12/19 1:41 PM, Nico Weber wrote:
> Thanks for reporting that this depends on the host compiler.
>
> I disabled the test again in r353836 and will look into why the output
> is different depending on if host cc is gcc or clang.
>
Good. Thanks!
When I've seen things like this before it's
Same thing for me with our downstream build bots.
When we compile clang with gcc 7.4 and then run the testcase I get this
output
define dso_local i64 @test__shiftleft128(i64 %l, i64 %h, i8 %d)
local_unnamed_addr #0 {
entry:
%0 = zext i64 %l to i128
%1 = zext i64 %h to i128
%2 = shl nuw
On 1/30/19 10:41 AM, Ilya Biryukov wrote:
> Should be fixed by r352612, let me know if it pops up again.
> This was a use after move, probably gcc and clang prefer different
> evaluation order, hence the difference in behaviours.
Awesome! Now it passes also when I compile with gcc.
Thanks,
Mik
Hi Ilya,
I've no idea why, but when I compile this commit with gcc (7.4.0) the
test fixits-command.test fails, and the output from clangd is rather
different from when I compile it with clang (3.6.0).
So I run
build-all/bin/clangd -lit-test <
/data/repo/master/llvm-master/tools/clang/tools/ex
On 12/12/18 2:17 PM, Bruno Ricci wrote:
>
>
> On 12/12/2018 07:27, Mikael Holmén wrote:
>> Hi,
>>
>> On 12/11/18 5:49 PM, Bruno Ricci wrote:
>>> Hi Mikael,
>>>
>>> I can indeed reproduce this with gcc 5.5.0 when doing a Release
>>> build with assertions. I cannot reproduce this with gcc 6.5.0
>
Hi,
On 12/11/18 5:49 PM, Bruno Ricci wrote:
> Hi Mikael,
>
> I can indeed reproduce this with gcc 5.5.0 when doing a Release
> build with assertions. I cannot reproduce this with gcc 6.5.0
> (also with a Release build with assertions), nor can I reproduce
> this with clang 7 (also with a Release
Hi Bruno,
I've no idea if this is really related to your change, but with this
commit, the following starts crashing:
clang-tidy -allow-enabling-analyzer-alpha-checkers
-checks='-*,clang-analyzer-*' ./reduced.c --
It seems like it recurses forever for some reason, and then we run out
of stack
piler-and-standard-library
suggests that even clang 3.1 should work.
/Mikael
>
> Thanks.
>
> Jan
>
>> On Nov 28, 2018, at 8:59 AM, Yvan Roux > <mailto:yvan.r...@linaro.org>> wrote:
>>
>> On Wed, 28 Nov 2018 at 09:56, Mikael Holmén via cfe-commits
>
ks,
> George
>
>> On Nov 26, 2018, at 12:03 AM, Mikael Holmén
>> mailto:mikael.hol...@ericsson.com>> wrote:
>>
>> Hi again,
>>
>> Do you have any opinion about the below valgrind complaint that starts
>> appearing with this patch?
>>
>&
Hi Jan,
This code doesn't compile with clang 3.6.0:
../tools/clang/tools/extra/clangd/Protocol.cpp:456:10: error: no viable
conversion from 'json::Object' to 'llvm::json::Value'
return result;
^~
../include/llvm/Support/JSON.h:291:3: note: candidate constructor not
viable: no k
On 11/26/18 12:41 PM, Ilya Biryukov wrote:
> Sorry about that, should be fixed in r347539.
>
Yep, thanks!
/Mikael
> On Mon, Nov 26, 2018 at 8:10 AM Mikael Holmén
> mailto:mikael.hol...@ericsson.com>> wrote:
>
> Hi Ilya,
>
> This patch doesn't compile for me with clang 3.6.0. I get:
18 8:33 AM, Mikael Holmén via cfe-commits wrote:
> Hi George,
>
> I noticed that valgrind started complaining in one case with this patch.
>
> I've no idea if it's really due to something in the patch or if it's
> something old that surfaced or if it's a false
Hi Ilya,
This patch doesn't compile for me with clang 3.6.0. I get:
../tools/clang/tools/extra/clangd/Protocol.cpp:474:10: error: no viable
conversion from 'json::Object' to 'llvm::json::Value'
return Result;
^~
../include/llvm/Support/JSON.h:291:3: note: candidate constructor n
Hi George,
I noticed that valgrind started complaining in one case with this patch.
I've no idea if it's really due to something in the patch or if it's
something old that surfaced or if it's a false flag.
Anyway, with this patch the following
valgrind clang-tidy -checks='-*,clang-analyzer-*
On 11/7/18 11:31 AM, Sam McCall wrote:
> I'll send a patch shortly to unbreak this.
>
> Is emitting a warning a problem for you? (i.e. do you build with -Werror)
Yes "unfortunately" we use -Werror.
> I'd like to do something like #ifdef SCHED_IDLE ... #else #warning "old
> libc?" #endif
> Tha
Hi,
On 11/7/18 11:03 AM, Sam McCall wrote:
> On Wed, Nov 7, 2018 at 10:32 AM Mikael Holmén via Phabricator
> mailto:revi...@reviews.llvm.org>> wrote:
>
> uabelho added a comment.
>
> Hi,
>
> I've got a post-review comment about the use of SCHED_IDLE vs the
> needed gcc version.
On 10/17/2018 08:30 PM, Julie Hockett wrote:
> https://reviews.llvm.org/D53381 should fix this -- thanks for the note!
Yep, thanks!
/Mikael
>
> Julie
>
> On Wed, Oct 17, 2018 at 1:58 AM Mikael Holmén
> mailto:mikael.hol...@ericsson.com>> wrote:
>
> Hi Julie,
>
> clang 3.6.0 compla
Hi Julie,
clang 3.6.0 complains on this commit:
/usr/bin/clang++ -march=corei7 -DGTEST_HAS_RTTI=0
-DGTEST_HAS_TR1_TUPLE=0 -DGTEST_LANG_CXX11=1 -D_DEBUG -D_GNU_SOURCE
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-Itools/clang/tools/extra/unittests/clang-doc
-I../tool
Hi Jonas, Bence,
On 10/08/2018 08:22 AM, Mikael Holmén via cfe-commits wrote:
> Hi Jonas,
>
> I get the follwing warning/error when compiling this commit with clang 3.6:
>
> ../tools/clang/tools/extra/clang-tidy/modernize/DeprecatedIosBaseAliasesCheck.cpp:21:5:
> error: sug
Hi Jonas,
I get the follwing warning/error when compiling this commit with clang 3.6:
../tools/clang/tools/extra/clang-tidy/modernize/DeprecatedIosBaseAliasesCheck.cpp:21:5:
error: suggest braces around initialization of subobject
[-Werror,-Wmissing-braces]
"::std::ios_base::io_state", "
1 - 100 of 126 matches
Mail list logo
