tru wrote:
Yeah. It's still on my list to update the patch to be recursive - but it's been
a pretty busy period and I haven't gotten around to it yet.
https://github.com/llvm/llvm-project/pull/88857
___
cfe-commits mailing list
cfe-commits@lists.llvm
tru wrote:
I can recommend the hyperfine tool when benchmarking. It runs the same command
multiple times and does all the fancy things to make sure you are measuring
correctly.
https://github.com/llvm/llvm-project/pull/114260
___
cfe-commits mailing
@@ -0,0 +1,13 @@
+// This test checks if Window PE file compiled with -flto option contains a
magic
+// string "LTCG" to indicate LTO compilation.
+
+// REQUIRES: system-windows
+
+// RUN: %clang --target=x86_64-pc-windows-msvc -flto -fuse-ld=lld %s -o %t.exe
tr
tru wrote:
You can consolidate the tests into a single cpp file instead of having three
different ones.
https://github.com/llvm/llvm-project/pull/114260
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https:
https://github.com/tru commented:
Thanks for working on this. It's always good to be compatible with MSVC as much
as possible. Some comments and questions. We also need some more people that
know more COFF to weigh in.
https://github.com/llvm/llvm-project/pull/114260
_
@@ -0,0 +1,13 @@
+// This test checks if Window PE file compiled with -flto option contains a
magic
+// string "LTCG" to indicate LTO compilation.
+
+// REQUIRES: system-windows
+
+// RUN: %clang --target=x86_64-pc-windows-msvc -flto -fuse-ld=lld %s -o %t.exe
+// RUN: dumpbin /H
@@ -1165,6 +1188,23 @@ void Writer::createMiscChunks() {
llvm::TimeTraceScope timeScope("Misc chunks");
Configuration *config = &ctx.config;
+ auto searchForPgoMagicSection = [this](char sectionName[]) {
tru wrote:
How expensive is this recursive search
https://github.com/tru edited https://github.com/llvm/llvm-project/pull/114260
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/tru approved this pull request.
LGTM! Thanks for doing that!
https://github.com/llvm/llvm-project/pull/112378
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/tru approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/108725
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tru wrote:
> @tru No, this is my first llvm pr. I'd appreciate you doing it :)
Thanks for your contribution!
https://github.com/llvm/llvm-project/pull/106369
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailma
https://github.com/tru closed https://github.com/llvm/llvm-project/pull/106369
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tru wrote:
Yeah it needs to be towards the 19.x release branch as I described in my
comment here
https://github.com/llvm/llvm-project/pull/107964#issuecomment-2352261158
https://github.com/llvm/llvm-project/pull/108801
___
cfe-commits mailing list
c
tru wrote:
Create a branch from `release/19.x` in your own fork, then cherry-pick over the
changes from `main`, edit them to match the things we talked about above (and
fix any merge problems). Then submit a PR that wants to merge `yourbranch` into
`release/19.x`. And check the checkbox `maint
tru wrote:
@nebulark do you have commit access to merge this? otherwise I can do it for
you.
https://github.com/llvm/llvm-project/pull/106369
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-c
tru wrote:
@ganeshgit or @RKSimon can one of you put up a PR against release/19.x with the
abi compatible changes so that we have chance to look at it and approve it
before the release tomorrow.
https://github.com/llvm/llvm-project/pull/107964
___
cf
tru wrote:
I think it's better it land as it should be in `main` and then you can create a
new PR against the ` release/19.x` branch with the different enum layout.
https://github.com/llvm/llvm-project/pull/107964
___
cfe-commits mailing list
cfe-comm
tru wrote:
> It would be messy, but could we not place the CK_ZNVER5 enum entry at the end
> of the enum list just for 19.x and then fix the sorting in trunk?
I would be fine with that. WDYT @nikic ?
https://github.com/llvm/llvm-project/pull/107964
_
tru wrote:
> The change to X86TargetParser.h looks ABI breaking to me.
This seems unfortunate to me. But I don't think it would be good to insert the
enum at the end of the list and changing the sorting order.
How big of a problem would it be with a ABI break now? I know you have
requested th
https://github.com/tru approved this pull request.
LGTM. Let's remove it.
https://github.com/llvm/llvm-project/pull/108342
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tru wrote:
This was suggested in https://github.com/llvm/llvm-project/pull/91856 and the
suggestion there was that we need to split it up per sub-project which is
something @e-kwsm has been doing:
https://github.com/llvm/llvm-project/pulls/e-kwsm so I don't think this one is
needed.
https://
tru wrote:
Do we still need to fix this for 19.1.0-final?
https://github.com/llvm/llvm-project/pull/100091
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tru wrote:
> Though having said all this, I marked this for LLVM 19 as my reading of
> https://discourse.llvm.org/t/update-on-llvm-19-x-releases/80511 was that new
> features are still ok before RC2, but re-reading it it's a bit ambiguous: it
> says "New features will have to wait until LLVM 2
tru wrote:
This seems to add a new feature, is it really relevant for a backport?
https://github.com/llvm/llvm-project/pull/99335
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/tru approved this pull request.
https://github.com/llvm/llvm-project/pull/98431
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tru wrote:
Hmm. It's a bit worrying that we can't have the tests running... I wonder what
the workflow would be here since we need to verify before we run the binaries.
What's the problem with the tests currently?
https://github.com/llvm/llvm-project/pull/98431
tru wrote:
I don't have the bandwidth to get a RFC through right now. If this is broken
and no-one wants to take care of getting consensus for something new, I suggest
you revert to the previous state. For my toolchain I can continue to carry a
patch until this is all sorted.
https://github.c
https://github.com/tru approved this pull request.
https://github.com/llvm/llvm-project/pull/90138
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tru wrote:
Did you consider the parallel setting as well?
https://github.com/llvm/llvm-project/pull/90138
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tru wrote:
Yeah I think this should be brought up as an RFC in discourse. I would like to
see that we move away from two different layouts and just adopt one (my
preference is the new layout, but honestly - I don't feel that strongly about
it).
https://github.com/llvm/llvm-project/pull/89775
tru wrote:
It needs a release note and documentation though.
https://github.com/llvm/llvm-project/pull/89775
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tru wrote:
I think this is fine. I probably have to carry a one line patch in our tree to
make it the default on windows as well. But that's acceptable to me.
https://github.com/llvm/llvm-project/pull/89775
___
cfe-commits mailing list
cfe-commits@li
@@ -1105,6 +1105,11 @@ bool MicrosoftCXXABI::hasMostDerivedReturn(GlobalDecl
GD) const {
static bool isTrivialForMSVC(const CXXRecordDecl *RD, QualType Ty,
CodeGenModule &CGM) {
+ // If the record is marked with the trivial_abi attribute, we don'
tru wrote:
ping on this.
https://github.com/llvm/llvm-project/pull/88857
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tru wrote:
If this is for permanent storage I suggest we use TXZ instead, since it has
better compression. You should also set CPACK_ARCHIVE_THREADS to something
higher than the default (1). Since xz really benefits from this.
https://github.com/llvm/llvm-project/pull/90138
___
https://github.com/tru approved this pull request.
https://github.com/llvm/llvm-project/pull/90139
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tru wrote:
I think I suggested that we should make the CMake variable change the driver
behaviour to reflect the setting in order to remove unexpected fallbacks and
that the vendor could select the layout. I still think that's probably the
better solution.
https://github.com/llvm/llvm-projec
tru wrote:
> > LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=on
>
>
>
> I'm unable to find what code this affects. I don't see it mentioned anywhere
> in clang/lib or clang/include.
>
>
>
> It does seem like it should control the behavior of
> `ToolChain::getCompilerRT`; where I had added the Windo
https://github.com/tru approved this pull request.
I find changes to the multi-stage build caches a bit confusing to review
without being able to see the cache that's generated. But I trust that you have
tested this and it works as expected, In that case you can merge this.
https://github.com/
https://github.com/tru approved this pull request.
https://github.com/llvm/llvm-project/pull/89517
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tru wrote:
And I think it's better to revert it all instead of implementing this
half-revert in this PR in that case and then we should discuss how to move
forward.
https://github.com/llvm/llvm-project/pull/89775
___
cfe-commits mailing list
cfe-comm
tru wrote:
Honestly - I think going back to *one* style of runtime path is to be preferred
now. But I don't think it's fair to say that it doesn't solve any problems,
because we switched to it so that we could ship more platforms in one toolchain
package without having to add cfg files and sim
tru wrote:
I agree that if downstream want to change stuff, they need to engage. We can't
guess what microsoft wants to do (or sony) unless we have a discussion about
it. This is also documented in the developer policy. If there are missed
release notes, they need to be added of course.
That
tru wrote:
It's been like that for maybe 2-3 years now and no one has complained about it,
so I think that change is solid. I can suggest a CMake change, but last time it
was discussed I think @maskray was against a new variable, but since we might
need to have some different behaviour it migh
tru wrote:
We have a custom toolchain that uses the new style on windows and if you build
with runtimes on windows (which is the suggested way) it will end up with the
new style without arch suffix. I don't think we can assume this is correct for
windows in all setups. I am fine with this chan
tru wrote:
The final decision is Toms, but I don't think it qualifies since we are so late
in the current process and that 19 will start in just a few months.
https://github.com/llvm/llvm-project/pull/87392
___
cfe-commits mailing list
cfe-commits@li
@@ -1105,6 +1105,11 @@ bool MicrosoftCXXABI::hasMostDerivedReturn(GlobalDecl
GD) const {
static bool isTrivialForMSVC(const CXXRecordDecl *RD, QualType Ty,
CodeGenModule &CGM) {
+ // If the record is marked with the trivial_abi attribute, we don'
tru wrote:
@efriedma-quic are you ok with this change?
https://github.com/llvm/llvm-project/pull/88857
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/tru updated https://github.com/llvm/llvm-project/pull/88857
>From 08214d87d1a7c83ea25eef3bf18de1568a20a152 Mon Sep 17 00:00:00 2001
From: Tobias Hieta
Date: Tue, 16 Apr 2024 09:38:53 +0200
Subject: [PATCH] [clang] Handle trivial_abi attribute for Microsoft ABI.
Previously the
@@ -0,0 +1,21 @@
+// RUN: %clang_cc1 -triple x86_64-pc-windows-msvc -std=c++11 -fcxx-exceptions
-fexceptions -emit-llvm -o - %s | FileCheck %s
+
+// CHECK: %[[STRUCT_TRIVIAL:.*]] = type { ptr }
+struct __attribute__((trivial_abi)) Trivial {
+ int *p;
+ Trivial() : p(0) {}
+ Tr
https://github.com/tru created https://github.com/llvm/llvm-project/pull/88857
Previously the trivial_abi was ignored for records when targetting the
microsoft abi, the MSVC rules where always enforced to ensure compatibility
with MSVC. This commit changes it to be closer to the itanium abi whe
tru wrote:
> I think .natvis files should be CRLF (those are used with Visual Studio for
> debug visualizers).
Agreed, Visual Studio should handle this correctly, but who knows 🤷🏼
https://github.com/llvm/llvm-project/pull/86318
___
cfe-commits maili
@@ -2410,20 +2410,35 @@ usual build cycle when using sample profilers for
optimization:
1. Build the code with source line table information. You can use all the
usual build flags that you always build your application with. The only
- requirement is that you add ``-glin
@@ -2410,20 +2410,35 @@ usual build cycle when using sample profilers for
optimization:
1. Build the code with source line table information. You can use all the
usual build flags that you always build your application with. The only
- requirement is that you add ``-glin
@@ -2410,20 +2410,35 @@ usual build cycle when using sample profilers for
optimization:
1. Build the code with source line table information. You can use all the
usual build flags that you always build your application with. The only
- requirement is that you add ``-glin
https://github.com/tru commented:
Thanks for working on documentation!
https://github.com/llvm/llvm-project/pull/84864
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/tru edited https://github.com/llvm/llvm-project/pull/84864
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/tru approved this pull request.
This seems good to me, it worked in my internal test as I expected it!
https://github.com/llvm/llvm-project/pull/81037
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi
tru wrote:
cc @sylvain-audi
https://github.com/llvm/llvm-project/pull/81677
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tru wrote:
I haven't checked closely yet, but it seems like you need to add tests.
https://github.com/llvm/llvm-project/pull/79390
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/tru approved this pull request.
https://github.com/llvm/llvm-project/pull/78823
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tru wrote:
Thanks @owenca !
https://github.com/llvm/llvm-project/pull/78682
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tru wrote:
@owenca What's the things that still needs to be addressed for this to land?
https://github.com/llvm/llvm-project/pull/70338
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tru wrote:
@tomekpaszek Hi Tomek, do you think you will have time to work on this soon?
Otherwise, I can probably finish it off for you since we also want this feature.
https://github.com/llvm/llvm-project/pull/70338
___
cfe-commits mailing list
cfe-c
@@ -10,112 +10,70 @@ on:
- 'llvmorg-*'
jobs:
- release-tasks:
-permissions:
- contents: write # To upload assets to release.
+ validate-tag:
+name: Validate Tag
runs-on: ubuntu-latest
if: github.repository == 'llvm/llvm-project'
+outputs:
+
@@ -0,0 +1,74 @@
+name: Release Lit
+
+permissions:
+ contents: read
+
+on:
+ workflow_dispatch:
+inputs:
+ release-version:
+description: 'Release Version'
+required: true
+type: string
+
+ workflow_call:
+inputs:
+ release-version:
+
https://github.com/tru approved this pull request.
https://github.com/llvm/llvm-project/pull/75903
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tru wrote:
It also needs tests.
https://github.com/llvm/llvm-project/pull/75373
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tru wrote:
This needs to be cleaned up before it can be merged. There needs to be only one
commit in this PR without the merge commits from main.
https://github.com/llvm/llvm-project/pull/75373
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
h
tru wrote:
This should be good now - a last look @boomanaiden154 ?
https://github.com/llvm/llvm-project/pull/73957
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/tru updated https://github.com/llvm/llvm-project/pull/73957
>From 2791b93517fbffec8757ab994246a98b4fd9d727 Mon Sep 17 00:00:00 2001
From: Tobias Hieta
Date: Mon, 2 Oct 2023 09:42:33 +0200
Subject: [PATCH 1/4] [workflow] Fix abi checker in llvm-tests. Same fix as in
99fb0af80d
tru wrote:
@rnk @amykhuang might be interested in reviewing as well.
https://github.com/llvm/llvm-project/pull/71300
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tru wrote:
> Thanks for trying it on 17.x. We can't backport it then.
Any idea if there is another workaround or fix that we could do to target 17.x?
18 is still pretty far off and clang-format for 17 will soon be included in a
lot of downstream tools. Happy to help out fixing it if you have a
tru wrote:
@owenca I picked da1b1fba5cfd41521a840202d8cf4c3796c5e10b on top of the 17.x
branch and my test case was not fixed, it still crashes in the same way as
described in #72628
https://github.com/llvm/llvm-project/pull/72520
___
cfe-commits ma
tru wrote:
> We probably should backport it to 17.0.6. What do you all think? @tru
Yep - seems like a good and small fix to have in 17.x
https://github.com/llvm/llvm-project/pull/72520
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://li
tru wrote:
17.0.5 is going to be released tomorrow, is this fix good to go for the
backport?
https://github.com/llvm/llvm-project/pull/70646
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-co
tru wrote:
@tomekpaszek do you plan to finish this PR? we have been testing it internally
on our code and would really like this to land in upstream LLVM.
https://github.com/llvm/llvm-project/pull/70338
___
cfe-commits mailing list
cfe-commits@lists.l
tru wrote:
Can this be merged and ready for a backport next week?
https://github.com/llvm/llvm-project/pull/70646
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tru wrote:
Our code compiles without warnings with this patch!
https://github.com/llvm/llvm-project/pull/70646
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tru wrote:
Thanks for the patch @spavloff - I will make sure to try it today!
https://github.com/llvm/llvm-project/pull/70646
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tru wrote:
@gedare can you fix the merge conflict on this one?
https://github.com/llvm/llvm-project/pull/69340
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tru wrote:
Yep. Want me to do it or do you have access now?
https://github.com/llvm/llvm-project/pull/65215
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tru wrote:
cc @mstorsjo @sylvain-audi @aganea
https://github.com/llvm/llvm-project/pull/66816
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tru wrote:
We guarantee abi/api stability between the patch versions, so I would say no.
Maybe if we think it's critical enough we could do a 17.1.0, but this doesn't
seem to be the case when reading the description at least. Is this a regression
from LLVM 16?
I could be convinced, but my def
tru wrote:
Yeah i noticed when I got further down in my notification stack :)
https://github.com/llvm/llvm-project/pull/67891
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tru wrote:
oh sorry for merging this @owenca - it was tagged for the 17.x release and I
thought it was a PR towards the backport branch so ti wasn't my intention to
merge it into main for you.
https://github.com/llvm/llvm-project/pull/67911
___
cfe-
https://github.com/tru closed https://github.com/llvm/llvm-project/pull/67911
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tru wrote:
Did you plan to backport this as well @mstorsjo ?
https://github.com/llvm/llvm-project/pull/67891
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tru wrote:
Looking at it - it seems like none of Tablegen is correctly clang-formatted. If
that's not desired, maybe it should have a local .clang-format file to disable
the formatting of these files.
Do we have a clang-tblgen maintainer? Couldn't find anything in the codeowners
and git log h
tru wrote:
No I don't think it's job's fault. I ran clang-format on this file and it's not
formatted at all, so I think when we ask it to just format a patch like we do
in the job, it gets a bit confused and give you a bit of non-sense formatting.
This is just a limitation of not running forma
https://github.com/tru commented:
It looks fine to me, but maybe we should have an entry for it in the
`CMake.rst` documentation since the other `LLVM_*_VC` options are documented.
https://github.com/llvm/llvm-project/pull/67125
___
cfe-commits mailin
https://github.com/tru approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/65215
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tru wrote:
ping @tstellar - guess it can be a wrong team name / label name?
https://github.com/llvm/llvm-project/pull/66420
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tru wrote:
@ldionne thanks for the whitespace check! I have already put some work into the
clang-format action on my end. Would you mind dropping it from this PR and let
me push mine first? My action is not just restricted to the clang subdir.
https://github.com/llvm/llvm-project/pull/66509
_
tru wrote:
Instead of updating the module manually on the bot, I still think it's a good
idea to add a requirements.txt that should be installed before running the
build, ideally in a virtualenv. WDYT @andreil99
https://github.com/llvm/llvm-project/pull/65664
_
tru wrote:
Seems like a nice cleanup on top of the fact that we don't have to use a
deprecated module. I am guessing it didn't cause any output errors.
Regarding build-bots, I am unsure where we automatically build the
documentation. Pushing the docs to the main branch will rebuild and put the
tru wrote:
Ping @llvm/pr-subscribers-libcxx
https://github.com/llvm/llvm-project/pull/65246
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -39,6 +40,4 @@ struct C {
static_assert(__builtin_offsetof(C, n) == 8,
"long long field in ms_struct should be 8-byte aligned");
-#if !defined(TEST_FOR_ERROR) && !defined(TEST_FOR_WARNING)
-// expected-no-diagnostics
-#endif
+// expected-warning@-2 {{offset of
@@ -39,6 +40,4 @@ struct C {
static_assert(__builtin_offsetof(C, n) == 8,
"long long field in ms_struct should be 8-byte aligned");
-#if !defined(TEST_FOR_ERROR) && !defined(TEST_FOR_WARNING)
-// expected-no-diagnostics
-#endif
+// expected-warning@-2 {{offset of
tru wrote:
I suspect maybe the MSVC_VERSION check might exclude clang-cl, but we should
make sure, because @omjavaid is correct, we shouldn't apply this to clang-cl
unless it shows the same problems.
https://github.com/llvm/llvm-project/pull/65215
__
1 - 100 of 127 matches
Mail list logo
