chandlerc wrote:
I see the build bot up and with the original failure, going to merge the revert
to hopefully make sure it goes green after that.
https://github.com/llvm/llvm-project/pull/118734
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
chandlerc wrote:
> That was a mistake. I originally was going to update the build bot to a later
> version of Visual Studio as while it wouldn't match our internal
> configuration, it was still useful to have some Windows coverage of the
> components we build/test. I then changed my mind and w
dyung wrote:
> So, the builder came back up, and is now passing without this landing...
>
> Here is the first build after it came back up:
> https://lab.llvm.org/buildbot/#/builders/46/builds/9173
>
> And I went through the output and found a specific test that was failing, and
> it seems to
chandlerc wrote:
So, the builder came back up, and is now passing without this landing...
Here is the first build after it came back up:
https://lab.llvm.org/buildbot/#/builders/46/builds/9173
And I went through the output and found a specific test that was failing, and
it seems to pass?
```
dyung wrote:
> > No real updates here, but our internal builder did catch up to this commit
> > and we are seeing the same (and a lot more) failures when this commit is
> > merged into our downstream codebase. I was kind of hoping that it would
> > pass so that it might indicate that the probl
chandlerc wrote:
> No real updates here, but our internal builder did catch up to this commit
> and we are seeing the same (and a lot more) failures when this commit is
> merged into our downstream codebase. I was kind of hoping that it would pass
> so that it might indicate that the problem m
dyung wrote:
No real updates here, but our internal builder did catch up to this commit and
we are seeing the same (and a lot more) failures when this commit is merged
into our downstream codebase. I was kind of hoping that it would pass so that
it might indicate that the problem might be a co
zmodem wrote:
> I've put it up on Dropbox
I looked at Builtins.cpp.obj and compared to the one in my build dir. They're
very similar, in particular the string table is there in both files, and looks
identical. I don't really have any more ideas for debugging this.
https://github.com/llvm/llvm
dyung wrote:
> > I've pulled out the entire tools\clang\lib\Basic directory from a failing
> > build, what would you like me to do with it?
>
> Can you put it in a zip somewhere? It would be interesting to check if
> there's some major difference compared to using a different MSVC version.
I'
zmodem wrote:
> I've pulled out the entire tools\clang\lib\Basic directory from a failing
> build, what would you like me to do with it?
Can you put it in a zip somewhere? It would be interesting to check if there's
some major difference compared to using a different MSVC version.
https://git
dyung wrote:
> > > Not sure what to do debug this... @zmodem maybe has some idea?
> >
> >
> > Sorry, I don't have a lot to add. Things look good on my end so far (local
> > builds and https://lab.llvm.org/buildbot/#/builders/63 +
> > https://lab.llvm.org/buildbot/#/builders/107).
> > Besides
dyung wrote:
> > Not sure what to do debug this... @zmodem maybe has some idea?
>
> Sorry, I don't have a lot to add. Things look good on my end so far (local
> builds and https://lab.llvm.org/buildbot/#/builders/63 +
> https://lab.llvm.org/buildbot/#/builders/107).
>
> Besides the particular
chandlerc wrote:
The arm64-windows failures are from `DirectoryWatcherTest` that seems
exceedingly unlikely to be related.
I think the only real failures here are the originally discussed ones on the
one windows build bot. All the other windows bots seems to be OK here.
https://github.com/llv
uweigand wrote:
The s390x failure is just an unstable test that occasionally fails - that
woudn't be a reason to revert. Cannot say about the arm64-windows failure.
https://github.com/llvm/llvm-project/pull/118734
___
cfe-commits mailing list
cfe-com
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder `clang-arm64-windows-msvc`
running on `linaro-armv8-windows-msvc-04` while building `clang` at step 5
"ninja check 1".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/161/builds/3580
Here is the relev
chandlerc wrote:
(FYI, I'm about to drop offline -- Hans, if you think it makes sense to revert
temporarily, please feel free to do so. I don't have a good sense of whether
the fallout here is enough to warrant that.)
https://github.com/llvm/llvm-project/pull/118734
___
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder `clang-s390x-linux` running
on `systemz-1` while building `clang` at step 5 "ninja check 1".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/42/builds/2256
Here is the relevant piece of the build log f
zmodem wrote:
> Not sure what to do debug this... @zmodem maybe has some idea?
Sorry, I don't have a lot to add. Things look good on my end so far (local
builds and https://lab.llvm.org/buildbot/#/builders/63 +
https://lab.llvm.org/buildbot/#/builders/107).
Besides the particular MSVC version
dyung wrote:
I’m still looking into the failure, but may be a bit slow as the machine isn’t
really setup for debugging, and I’m traveling today.
https://github.com/llvm/llvm-project/pull/118734
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
chandlerc wrote:
> Could the version of VC that we are using possibly have the issue with long
> strings that you mention? Is there a simple way to check that?
It's a compile time error, so no, that'd be really clear cut.
The only other thing I've seen is running out of heap, but that seems li
dyung wrote:
> > > > > > LLVM Buildbot has detected a new failure on builder
> > > > > > `llvm-clang-x86_64-sie-win` running on `sie-win-worker` while
> > > > > > building `clang` at step 7 "test-build-unified-tree-check-all".
> > > > > > Full details are available at:
> > > > > > [lab.llvm.or
chandlerc wrote:
> > > > > LLVM Buildbot has detected a new failure on builder
> > > > > `llvm-clang-x86_64-sie-win` running on `sie-win-worker` while
> > > > > building `clang` at step 7 "test-build-unified-tree-check-all".
> > > > > Full details are available at:
> > > > > [lab.llvm.org/buil
dyung wrote:
> > > > LLVM Buildbot has detected a new failure on builder
> > > > `llvm-clang-x86_64-sie-win` running on `sie-win-worker` while building
> > > > `clang` at step 7 "test-build-unified-tree-check-all".
> > > > Full details are available at:
> > > > [lab.llvm.org/buildbot#/builders
chandlerc wrote:
> > > LLVM Buildbot has detected a new failure on builder
> > > `llvm-clang-x86_64-sie-win` running on `sie-win-worker` while building
> > > `clang` at step 7 "test-build-unified-tree-check-all".
> > > Full details are available at:
> > > [lab.llvm.org/buildbot#/builders/46/bu
dyung wrote:
> > LLVM Buildbot has detected a new failure on builder
> > `llvm-clang-x86_64-sie-win` running on `sie-win-worker` while building
> > `clang` at step 7 "test-build-unified-tree-check-all".
> > Full details are available at:
> > [lab.llvm.org/buildbot#/builders/46/builds/9169](htt
chandlerc wrote:
> LLVM Buildbot has detected a new failure on builder
> `llvm-clang-x86_64-sie-win` running on `sie-win-worker` while building
> `clang` at step 7 "test-build-unified-tree-check-all".
>
> Full details are available at:
> [lab.llvm.org/buildbot#/builders/46/builds/9169](https:
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder `llvm-clang-x86_64-sie-win`
running on `sie-win-worker` while building `clang` at step 7
"test-build-unified-tree-check-all".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/46/builds/9169
Here is the
https://github.com/chandlerc closed
https://github.com/llvm/llvm-project/pull/118734
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
androm3da wrote:
cc @llvm/pr-subscribers-backend-hexagon and @iajbar
https://github.com/llvm/llvm-project/pull/118734
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/chandlerc updated
https://github.com/llvm/llvm-project/pull/118734
>From 9553557e87ec5d9ae5ce5636f6227150fcd080bc Mon Sep 17 00:00:00 2001
From: Chandler Carruth
Date: Thu, 28 Nov 2024 09:56:40 +
Subject: [PATCH 1/6] Switch builtin strings to use string tables
MIME-Versio
chandlerc wrote:
> Confirmed that this works on GCC now. I'd suggest to replace the use of
> StringLiteral::size with plain sizeof(). The build time overhead of going
> through StringLiteral here is substantial.
Sure. I was initially worried about the subtlety of this use of `sizeof`, but
tha
https://github.com/nikic edited https://github.com/llvm/llvm-project/pull/118734
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -68,23 +69,156 @@ enum ID {
FirstTSBuiltin
};
+// The info used to represent each builtin.
struct Info {
- llvm::StringLiteral Name;
- const char *Type, *Attributes;
- const char *Features;
+ // Rather than store pointers to the string literals describing these four
https://github.com/nikic approved this pull request.
Confirmed that this works on GCC now. I'd suggest to replace the use of
StringLiteral::size with plain sizeof(). The build time overhead of going
through StringLiteral here is substantial.
https://github.com/llvm/llvm-project/pull/118734
___
@@ -68,23 +69,156 @@ enum ID {
FirstTSBuiltin
};
+// The info used to represent each builtin.
struct Info {
- llvm::StringLiteral Name;
- const char *Type, *Attributes;
- const char *Features;
+ // Rather than store pointers to the string literals describing these four
@@ -68,23 +69,156 @@ enum ID {
FirstTSBuiltin
};
+// The info used to represent each builtin.
struct Info {
- llvm::StringLiteral Name;
- const char *Type, *Attributes;
- const char *Features;
+ // Rather than store pointers to the string literals describing these four
https://github.com/chandlerc commented:
> Fails to build with GCC:
Doh, I had hoped GCC would support this. Anyways, fixed back to just suppress
the diagnostic with Clang. Did some builds with GCC and everything seems fine,
and it doesn't seem like we're GCC warning clean these days anyways.
https://github.com/chandlerc edited
https://github.com/llvm/llvm-project/pull/118734
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/chandlerc updated
https://github.com/llvm/llvm-project/pull/118734
>From 73a0b5c796881d1e52f8336eb69f678fd4c9f4c4 Mon Sep 17 00:00:00 2001
From: Chandler Carruth
Date: Thu, 28 Nov 2024 09:56:40 +
Subject: [PATCH 1/5] Switch builtin strings to use string tables
MIME-Versio
https://github.com/nikic requested changes to this pull request.
Fails to build with GCC:
```
FAILED: tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Builtins.cpp.o
CCACHE_CPP2=yes CCACHE_HASHDIR=yes /usr/bin/ccache /usr/bin/c++ -DCLANG_EXPORTS
-DGTEST_HAS_RTTI=0 -D_GNU_SOURCE -D__STDC_CON
@@ -68,23 +69,156 @@ enum ID {
FirstTSBuiltin
};
+// The info used to represent each builtin.
struct Info {
- llvm::StringLiteral Name;
- const char *Type, *Attributes;
- const char *Features;
+ // Rather than store pointers to the string literals describing these four
@@ -41,6 +41,10 @@ class LLVM_LIBRARY_VISIBILITY ARCTargetInfo : public
TargetInfo {
MacroBuilder &Builder) const override;
ArrayRef getTargetBuiltins() const override { return {}; }
chandlerc wrote:
Doh, yes. I meant to remove the
https://github.com/chandlerc updated
https://github.com/llvm/llvm-project/pull/118734
>From 73a0b5c796881d1e52f8336eb69f678fd4c9f4c4 Mon Sep 17 00:00:00 2001
From: Chandler Carruth
Date: Thu, 28 Nov 2024 09:56:40 +
Subject: [PATCH 1/2] Switch builtin strings to use string tables
MIME-Versio
@@ -41,6 +41,10 @@ class LLVM_LIBRARY_VISIBILITY ARCTargetInfo : public
TargetInfo {
MacroBuilder &Builder) const override;
ArrayRef getTargetBuiltins() const override { return {}; }
topperc wrote:
Should this override of getTargetB
https://github.com/topperc edited
https://github.com/llvm/llvm-project/pull/118734
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/chandlerc updated
https://github.com/llvm/llvm-project/pull/118734
>From 73a0b5c796881d1e52f8336eb69f678fd4c9f4c4 Mon Sep 17 00:00:00 2001
From: Chandler Carruth
Date: Thu, 28 Nov 2024 09:56:40 +
Subject: [PATCH] Switch builtin strings to use string tables
MIME-Version: 1
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 983f88c1ec9cee51cf0fb4e6a0f00074a7cf1b60
16e70ef753de962e76b5232912094a51ca24 --e
chandlerc wrote:
Updated to use the GCC diagnostic push the same as TableGen does for long
string literals. Also added Aaron to take a look as well (unless he's
comfortable already).
https://github.com/llvm/llvm-project/pull/118734
___
cfe-commits ma
https://github.com/chandlerc updated
https://github.com/llvm/llvm-project/pull/118734
>From 16e70ef753de962e76b5232912094a51ca24 Mon Sep 17 00:00:00 2001
From: Chandler Carruth
Date: Thu, 28 Nov 2024 09:56:40 +
Subject: [PATCH] Switch builtin strings to use string tables
MIME-Version: 1
https://github.com/zygoloid approved this pull request.
LGTM too. I do wonder if we can make tablegen generate the data directly in the
desired format here (perhaps with some additional `.td` files to define exactly
which files we want to include in which targets and to define the placeholder
https://github.com/dwblaikie approved this pull request.
This looks fine to me - though given the broad impact (to every target in
clang) maybe @AaronBallman wants to weigh in.
If you wanted to front-load the things like `getRecord(ID).Attributes` ->
`getAttributesString(ID)` those things coul
chandlerc wrote:
Discussion thread about the MSVC version change:
https://discourse.llvm.org/t/rfc-raising-minimum-msvc-version-by-one-patch-release/83490
https://github.com/llvm/llvm-project/pull/118734
___
cfe-commits mailing list
cfe-commits@lists.
llvmbot wrote:
@llvm/pr-subscribers-backend-arm
Author: Chandler Carruth (chandlerc)
Changes
The Clang binary (and any binary linking Clang as a library), when built using
PIE, ends up with a pretty shocking number of dynamic relocations to apply to
the executable image: roughly 400k.
E
llvmbot wrote:
@llvm/pr-subscribers-backend-msp430
Author: Chandler Carruth (chandlerc)
Changes
The Clang binary (and any binary linking Clang as a library), when built using
PIE, ends up with a pretty shocking number of dynamic relocations to apply to
the executable image: roughly 400k.
llvmbot wrote:
@llvm/pr-subscribers-backend-sparc
Author: Chandler Carruth (chandlerc)
Changes
The Clang binary (and any binary linking Clang as a library), when built using
PIE, ends up with a pretty shocking number of dynamic relocations to apply to
the executable image: roughly 400k.
llvmbot wrote:
@llvm/pr-subscribers-backend-risc-v
Author: Chandler Carruth (chandlerc)
Changes
The Clang binary (and any binary linking Clang as a library), when built using
PIE, ends up with a pretty shocking number of dynamic relocations to apply to
the executable image: roughly 400k.
https://github.com/chandlerc created
https://github.com/llvm/llvm-project/pull/118734
The Clang binary (and any binary linking Clang as a library), when built using
PIE, ends up with a pretty shocking number of dynamic relocations to apply to
the executable image: roughly 400k.
Each of these
57 matches
Mail list logo
