mstorsjo wrote:
> Microsoft bit-field layout didn't break an overly-specific regression test
> but rendered unusable double to string conversion. The culprit was the
> following snippet:
>
> ```c++
> union Extractor {
> double value;
> struct {
> bool sign : 1;
> u32 exponent :
mstorsjo wrote:
> `-mms-bitfields` is a GCC x86 specific option (`aarch64-linux-gnu-gcc
> -mms-bitfields -xc /dev/null -E` => `error: unrecognized command-line option
> ‘-mms-bitfields’`).
While it is implemented as an x86 specific option in GCC right now, that
doesn't mean that it only is
https://github.com/mstorsjo approved this pull request.
LGTM, thanks! (I have no idea how I botched that previous fix commit...)
https://github.com/llvm/llvm-project/pull/72314
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
mstorsjo wrote:
> Hi Phoebe, starting seeing this error on rather old codes after this patch
> landed . is there a particular flag you recommend i should compile with to
> get previous behavior ?
>
> error: always_inline function '_mm_setzero_pd' requires target feature
> 'evex512', but
mstorsjo wrote:
This is superseded by #71393 which was merged now.
https://github.com/llvm/llvm-project/pull/66881
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mstorsjo closed
https://github.com/llvm/llvm-project/pull/71393
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mstorsjo closed
https://github.com/llvm/llvm-project/pull/71168
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mstorsjo edited
https://github.com/llvm/llvm-project/pull/71168
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mstorsjo edited
https://github.com/llvm/llvm-project/pull/71168
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mstorsjo wrote:
Thanks, I wasn't aware of this issue (I don't routinely try building with
`-DBUILD_SHARED_LIBS=ON`, which I presume is what you've done to trigger this).
See 592e935e115ffb451eb9b782376711dab6558fe0 for earlier context on this issue;
therefore I'd prefer to fix this as I do in
mstorsjo wrote:
CC @brechtsanders, this is an alternative to #66881.
https://github.com/llvm/llvm-project/pull/71393
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mstorsjo created
https://github.com/llvm/llvm-project/pull/71393
A few symbols within libclangInterpreter have got explicit dllexport
attributes, in order to make them exported (and thus visible at runtime) in any
build, not only when they are part of e.g. a DLL
mstorsjo wrote:
Posting for a second review instead of just relanding the patch as is; in order
to check the host triple, I had to add the `host=triple` string; it was
previously only available for tests under `llvm/test`, but let's move it to the
common llvm test configuration just like the
https://github.com/mstorsjo created
https://github.com/llvm/llvm-project/pull/71168
The const.cpp testcase fails when running in MSVC mode, while it does succeed
in MinGW mode.
In MSVC mode, there are more constructor invocations than expected, as the
printout looks like this:
A(1),
Author: Martin Storsjö
Date: 2023-11-03T11:55:33+02:00
New Revision: 89a336add722f57f61c99b3eafab1c89f943db5e
URL:
https://github.com/llvm/llvm-project/commit/89a336add722f57f61c99b3eafab1c89f943db5e
DIFF:
Author: Martin Storsjö
Date: 2023-11-03T11:30:08+02:00
New Revision: e9db60c05e2fb96ff40cbb1f78790abc5de9237e
URL:
https://github.com/llvm/llvm-project/commit/e9db60c05e2fb96ff40cbb1f78790abc5de9237e
DIFF:
mstorsjo wrote:
> > > > If you still need help reproducing or debugging the issue on our bot,
> > > > please let me know.
> > >
> > >
> > > Thanks, much appreciated. Can you test if
> > > [mstorsjo@clang-repl-xfail](https://github.com/mstorsjo/llvm-project/commit/clang-repl-xfail)
> > >
mstorsjo wrote:
> If you still need help reproducing or debugging the issue on our bot, please
> let me know.
Thanks, much appreciated. Can you test if
https://github.com/mstorsjo/llvm-project/commit/clang-repl-xfail seems to run
correctly in this environment? Otherwise I'll try to push it
mstorsjo wrote:
> FTR, the "Worker" tab on that buildbot page will point you to the maintainer.
Ah, there it is, I tried looking around, but overlooked that one...
> But tagging me is also fine in general.
Ok, thanks!
> I'm unable to repro the problem locally because my local build doesn't
Author: Martin Storsjö
Date: 2023-11-02T10:49:55+02:00
New Revision: b73d7390732b48014983aa9569e68c139f61bfcb
URL:
https://github.com/llvm/llvm-project/commit/b73d7390732b48014983aa9569e68c139f61bfcb
DIFF:
mstorsjo wrote:
This broke on PS5 bots, like
https://lab.llvm.org/buildbot/#/builders/216/builds/29677; those are configured
with a triple like `x86_64-sie-ps5`, which seems to use an MSVC like C++ ABI
behaviour, so I pushed a revert.
Not sure whom to CC to pull in Sony people to discuss
https://github.com/mstorsjo closed
https://github.com/llvm/llvm-project/pull/70991
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mstorsjo wrote:
> Very interesting... See also #68092, now I understand even less what the
> problem is...
No idea actually, but I tested passing `-Xcc --target=x86_64-w64-mingw32` to an
MSVC-built clang-repl, and then it outputs the expected things.
Not sure at what level some JIT
https://github.com/mstorsjo created
https://github.com/llvm/llvm-project/pull/70991
The const.cpp testcase fails when running in MSVC mode, while it does succeed
in MinGW mode.
In MSVC mode, there are more constructor invocations than expected, as the
printout looks like this:
A(1),
@@ -53,3 +53,26 @@ add_flang_library(FortranDecimal INSTALL_WITH_TOOLCHAIN
binary-to-decimal.cpp
decimal-to-binary.cpp
)
+
+if (DEFINED MSVC)
+ set(CMAKE_MSVC_RUNTIME_LIBRARY MultiThreaded)
mstorsjo wrote:
Instead of redefining
https://github.com/mstorsjo closed
https://github.com/llvm/llvm-project/pull/69079
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mstorsjo updated
https://github.com/llvm/llvm-project/pull/69079
From df2dba040dadb5e3222b44b41ea92978d9ddafed Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Martin=20Storsj=C3=B6?=
Date: Sat, 14 Oct 2023 00:55:18 +0300
Subject: [PATCH 1/4] [clang] [Gnu] Improve GCCVersion parsing
https://github.com/mstorsjo updated
https://github.com/llvm/llvm-project/pull/69079
From df2dba040dadb5e3222b44b41ea92978d9ddafed Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Martin=20Storsj=C3=B6?=
Date: Sat, 14 Oct 2023 00:55:18 +0300
Subject: [PATCH 1/3] [clang] [Gnu] Improve GCCVersion parsing
@@ -2007,45 +2007,71 @@ Generic_GCC::GCCVersion
Generic_GCC::GCCVersion::Parse(StringRef VersionText) {
std::pair First = VersionText.split('.');
std::pair Second = First.second.split('.');
- GCCVersion GoodVersion = {VersionText.str(), -1, -1, -1, "", "", ""};
- if
https://github.com/mstorsjo updated
https://github.com/llvm/llvm-project/pull/69079
From df2dba040dadb5e3222b44b41ea92978d9ddafed Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Martin=20Storsj=C3=B6?=
Date: Sat, 14 Oct 2023 00:55:18 +0300
Subject: [PATCH 1/2] [clang] [Gnu] Improve GCCVersion parsing
@@ -2007,45 +2007,71 @@ Generic_GCC::GCCVersion
Generic_GCC::GCCVersion::Parse(StringRef VersionText) {
std::pair First = VersionText.split('.');
std::pair Second = First.second.split('.');
- GCCVersion GoodVersion = {VersionText.str(), -1, -1, -1, "", "", ""};
- if
@@ -2007,45 +2007,71 @@ Generic_GCC::GCCVersion
Generic_GCC::GCCVersion::Parse(StringRef VersionText) {
std::pair First = VersionText.split('.');
std::pair Second = First.second.split('.');
- GCCVersion GoodVersion = {VersionText.str(), -1, -1, -1, "", "", ""};
- if
mstorsjo wrote:
Ping
https://github.com/llvm/llvm-project/pull/69079
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mstorsjo wrote:
> ```c
> #if !defined(LLVM_BUILD_SHARED_LIBS)
> ```
>
> is not great but is not too bad. `-DBUILD_SHARED_LIBS=on` modes are slow to
> execute tests and are not used often for Release builds.
I went ahead and relanded this now, in
538b7ba2aacd6e400ee63c4f9ff1c2543ae69a90, with
Author: Martin Storsjö
Date: 2023-10-20T23:34:28+03:00
New Revision: 538b7ba2aacd6e400ee63c4f9ff1c2543ae69a90
URL:
https://github.com/llvm/llvm-project/commit/538b7ba2aacd6e400ee63c4f9ff1c2543ae69a90
DIFF:
mstorsjo wrote:
> I hope that we do not drop `LLVM_LIBRARY_VISIBILITY` arbitrarily from
> `clang::driver::toolchains::*` classes, just because some unittests need to
> reference the symbols in a shared object.
That’s a reasonable point.
> ```c
> #if !defined(LLVM_BUILD_SHARED_LIBS)
> ```
>
mstorsjo wrote:
> Perhaps this belongs in the ABI-breaking-checks build?
Hmm, ideally I think it should be included in any build - let’s hope we don’t
need to resort to that.
@tstellar @MaskRay Do either of you happen to know about this; would it be ok
ABI wise to remove
Author: Martin Storsjö
Date: 2023-10-18T15:42:18+03:00
New Revision: 1072b94ed8e5a051100557185cb384364850635a
URL:
https://github.com/llvm/llvm-project/commit/1072b94ed8e5a051100557185cb384364850635a
DIFF:
mstorsjo wrote:
> @tbaederr Just came to report the same thing!
>
> @mstorsjo This broke builds that use `-DBUILD_SHARED_LIBS=True`.
Thanks! That was my guess as well, I was running a build with that enabled to
try to reproduce @tbaederr 's issue.
> The problem seems to be that the
mstorsjo wrote:
The prerequisite to this PR has been merged now.
https://github.com/llvm/llvm-project/pull/69079
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mstorsjo updated
https://github.com/llvm/llvm-project/pull/69079
From 468befbb3eeaa0a23b001141976108157608e11d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Martin=20Storsj=C3=B6?=
Date: Sat, 14 Oct 2023 00:55:18 +0300
Subject: [PATCH] [clang] [Gnu] Improve GCCVersion parsing to
https://github.com/mstorsjo closed
https://github.com/llvm/llvm-project/pull/69078
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mstorsjo wrote:
Thanks, I applied the suggested changes - will push in a little while.
https://github.com/llvm/llvm-project/pull/69078
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mstorsjo updated
https://github.com/llvm/llvm-project/pull/69078
From 1aac071988f66ccab67c7a6179841bb272b5684a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Martin=20Storsj=C3=B6?=
Date: Sat, 14 Oct 2023 00:06:05 +0300
Subject: [PATCH] [clang] [unittest] Add a test for
https://github.com/mstorsjo updated
https://github.com/llvm/llvm-project/pull/69079
From 2b127200dc7b7b7c60e3001c7acf49a33a22e2a5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Martin=20Storsj=C3=B6?=
Date: Sat, 14 Oct 2023 00:06:05 +0300
Subject: [PATCH 1/2] [clang] [unittest] Add a test for
mstorsjo wrote:
This goes on top of #69078 - the first commit is reviewed there, thus within
this PR, only review the second commit on its own.
https://github.com/llvm/llvm-project/pull/69079
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/mstorsjo created
https://github.com/llvm/llvm-project/pull/69079
In earlier GCC versions, the Debian/Ubuntu provided mingw toolchains were
packaged in /usr/lib/gcc/ with version strings such as "5.3-win32",
which were matched and found since
https://github.com/mstorsjo created
https://github.com/llvm/llvm-project/pull/69078
This adds actual test cases for all the cases that are listed in a code comment
in the implementation of this function; having such test coverage eases doing
further modifications to the function.
From
@@ -642,18 +642,8 @@ get_sanitizer_flags(SANITIZER_FLAGS
"${LLVM_USE_SANITIZER}")
# Link system libraries ===
function(cxx_link_system_libraries target)
-
-# In order to remove just libc++ from the link step
-# we need to
@@ -642,18 +642,8 @@ get_sanitizer_flags(SANITIZER_FLAGS
"${LLVM_USE_SANITIZER}")
# Link system libraries ===
function(cxx_link_system_libraries target)
-
-# In order to remove just libc++ from the link step
-# we need to
@@ -642,18 +642,8 @@ get_sanitizer_flags(SANITIZER_FLAGS
"${LLVM_USE_SANITIZER}")
# Link system libraries ===
function(cxx_link_system_libraries target)
-
-# In order to remove just libc++ from the link step
-# we need to
@@ -642,18 +642,8 @@ get_sanitizer_flags(SANITIZER_FLAGS
"${LLVM_USE_SANITIZER}")
# Link system libraries ===
function(cxx_link_system_libraries target)
-
-# In order to remove just libc++ from the link step
-# we need to
https://github.com/mstorsjo closed
https://github.com/llvm/llvm-project/pull/68571
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mstorsjo wrote:
> Whatever we decide to do on the LLVM side, this seems fine for the clang side.
Yes, this bit should be fine in any case.
> It looks like clang uses the value of UseInitArray for some ObjC stuff, in
> addition to passing it to the backend, so we need the right value in clang
mstorsjo wrote:
> Right, so adding an `enum DefaultableBool { Default, False, True }` and
> changing the field to that value?
With such a definition, I wonder how to interpret it for MSVC targets;
`UseInitArray` would be false, as MSVC uses the `.CRT` sections, neither
`.ctors` not
mstorsjo wrote:
> Doesn't UseInitArray default to false in LLVM?
The class `TargetOptions` itself initializes it to false indeed. But
`codegen::InitTargetOptionsFromCodeGenFlags` (which seems to be what e.g. `llc`
uses) explicitly sets it to `!getUseCtors()`, which only checks the state of
mstorsjo wrote:
> Hmm...
>
> Maybe the backend should have some notion of a default ctors section. So if
> the frontend doesn't explicitly specify anything, the backend tries to pick
> the right default.
Yep, this is kinda the same issue for lots of target specific options that are
set as
mstorsjo wrote:
> We could go with a clang fix, but also make the backend report_fatal_error if
> you try to use llvm.ctors with UseInitArray on mingw. That keeps everything
> consistent while also making sure non-clang frontends don't miscompile.
Hmm, interesting proposition... But wouldn't
mstorsjo wrote:
This is an alternative to #68570. This has the upside that the `UseInitArray`
flag is set to the correct value throughout the chain, for any other potential
users of the field, in case it would affect code generation in other places.
The downside is that if we only go with
https://github.com/mstorsjo created
https://github.com/llvm/llvm-project/pull/68571
On MinGW targets, the .ctors section is always used for constructors.
Make sure that all layers of code generation is aware of this, wherever it
matters, by passing the -fno-use-init-array option, setting the
mstorsjo wrote:
> > ... I understand this is only a bug on MacOS?
>
> I'm using clang only to compile my binary packages on macOS (the Linux
> binaries are compiled with gcc), so I got bitten by this bug only on macOS.
> The other platforms/targets may or may not be affected, I don't know;
mstorsjo wrote:
> > it's quite possible that someone has ended up depending on the previous de
> > facto behaviour.
>
> Then we have to be super creative and find a better solution.
>
> How about changing the logic, and where `Driver.InstalledDir` is used, if the
> desired file/folder is not
mstorsjo wrote:
> Without any other reference, I checked the Apple clang, on my macOS:
>
> ```
> ilg@wksi ~ % /usr/bin/clang -v
> Apple clang version 14.0.0 (clang-1400.0.29.202)
> Target: x86_64-apple-darwin21.6.0
> Thread model: posix
> InstalledDir:
mstorsjo wrote:
> I'm convinced that such links were occasionally used before, just that the
> result was not necessarily an error, I would say that in most cases using the
> system libraries is functional, and this explains why such cases were not
> reported till now.
Not necessarily; this
mstorsjo wrote:
> > it makes me wonder if someone actually is relying on the current behaviour
>
> To rephrase your question, you ask if someone is using a configuration with a
> folder where various custom libraries are and bin folder with a link to the
> actual clang, and expects for clang
mstorsjo wrote:
> > I haven't checked closely
>
> Hi Martin, please check the #66704 bug report, the current behaviour is
> plainly wrong,
I would kind of agree with that in general - resolving this to the actual clang
binary would indeed seem like the right thing to do. But it makes me
mstorsjo wrote:
FWIW, I'd be quite wary about modifying the logic here (whatever it is - I
haven't checked closely); if we used to resolve to one point of a symlink
before, and now resolve to the other end, I can almost guarantee you that there
are dozens of existing users that rely on the
mstorsjo wrote:
> cc @mstorsjo @sylvain-audi @aganea
Sorry, I don't really know anything about this area at all, so I don't think I
have anything to add here.
https://github.com/llvm/llvm-project/pull/66816
___
cfe-commits mailing list
mstorsjo wrote:
> Did you plan to backport this as well @mstorsjo ?
Yes, I did - in #64464, with
https://github.com/llvm/llvm-project-release-prs/pull/716 (where tests failed
after cherrypicking; looking into that test issue right now).
https://github.com/llvm/llvm-project/pull/67891
https://github.com/mstorsjo closed
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
https://github.com/mstorsjo updated
https://github.com/llvm/llvm-project/pull/67891
From da64c467a35cf544df5346b512746715ffc3db32 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Martin=20Storsj=C3=B6?=
Date: Sun, 1 Oct 2023 00:29:21 +0300
Subject: [PATCH] [clang] [MinGW] Tolerate mingw specific
https://github.com/mstorsjo created
https://github.com/llvm/llvm-project/pull/67891
Prior to 591c4b64b3650884c2c68eb47d755ebb62981b99, the mingw specific linker
options -mthreads, -mconsole, -mwindows and -mdll would be tolerated also at
compile time, but generating a warning about being
mstorsjo wrote:
> But even regardless of #67201, the intended way to use the libc++ test suite
> is to create a `.cfg.in` file that suits your needs if the general ones
> don't, not to add more configuration options to the general ones.
IMO, I think this is something I fundamentally disagree
https://github.com/mstorsjo closed
https://github.com/llvm/llvm-project/pull/66850
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mstorsjo wrote:
> LGTM, thanks. (But let's wait with landing it until e.g. tomorrow, in case
> someone else has comments on it.)
I think this should be fine to land now. Do you have commit access, or do you
want me to push the button?
https://github.com/llvm/llvm-project/pull/66850
https://github.com/mstorsjo approved this pull request.
LGTM, thanks. (But let's wait with landing it until e.g. tomorrow, in case
someone else has comments on it.)
https://github.com/llvm/llvm-project/pull/66850
___
cfe-commits mailing list
@@ -70,10 +70,6 @@ foreach(variable ${_FUCHSIA_BOOTSTRAP_PASSTHROUGH})
endif()
endforeach()
-if(WIN32)
- set(LLVM_USE_CRT_RELEASE "MT" CACHE STRING "")
mstorsjo wrote:
You mean line 91 here? Ok, that's also present elsewhere here.
https://github.com/mstorsjo commented:
Ok, the PR seems fine code-wise then - please update the commit message (PR
description) and this should be fine.
https://github.com/llvm/llvm-project/pull/66850
___
cfe-commits mailing list
https://github.com/mstorsjo edited
https://github.com/llvm/llvm-project/pull/66850
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -30,7 +30,6 @@ set(LLDB_ENABLE_CURSES OFF CACHE BOOL "")
set(LLDB_ENABLE_LIBEDIT OFF CACHE BOOL "")
if(WIN32)
- set(LLVM_USE_CRT_RELEASE "MT" CACHE STRING "")
mstorsjo wrote:
Right, I didn't see that one.
https://github.com/llvm/llvm-project/pull/66850
@@ -951,7 +950,7 @@ if(LLVM_USE_SANITIZER)
endif()
# Prepare ASAN runtime if needed
if (LLVM_USE_SANITIZER MATCHES ".*Address.*")
-if (${LLVM_USE_CRT_${uppercase_CMAKE_BUILD_TYPE}} MATCHES "^(MT|MTd)$")
+if (${CMAKE_MSVC_RUNTIME_LIBRARY}
@@ -14,10 +14,7 @@ set(LLVM_PACKAGE_BUGREPORT @PACKAGE_BUGREPORT@)
set(LLVM_BUILD_TYPE @CMAKE_BUILD_TYPE@)
-set(LLVM_USE_CRT_DEBUG @LLVM_USE_CRT_DEBUG@)
-set(LLVM_USE_CRT_MINSIZEREL @LLVM_USE_CRT_MINSIZEREL@)
-set(LLVM_USE_CRT_RELEASE @LLVM_USE_CRT_RELEASE@)
@@ -70,10 +70,6 @@ foreach(variable ${_FUCHSIA_BOOTSTRAP_PASSTHROUGH})
endif()
endforeach()
-if(WIN32)
- set(LLVM_USE_CRT_RELEASE "MT" CACHE STRING "")
mstorsjo wrote:
Same here - we should probably set `CMAKE_MSVC_RUNTIME_LIBRARY` instead of just
@@ -30,7 +30,6 @@ set(LLDB_ENABLE_CURSES OFF CACHE BOOL "")
set(LLDB_ENABLE_LIBEDIT OFF CACHE BOOL "")
if(WIN32)
- set(LLVM_USE_CRT_RELEASE "MT" CACHE STRING "")
mstorsjo wrote:
This case here seems to lack a corresponding setting of
https://github.com/mstorsjo commented:
This looks mostly good to me, but a few cases might need setting
`CMAKE_MSVC_RUNTIME_LIBRARY` instead of the removed variable.
The commit message needs improving though. This isn't related to the discussion
about crt allocators at all.
Instead the
https://github.com/mstorsjo edited
https://github.com/llvm/llvm-project/pull/66850
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -743,6 +743,7 @@ void CGRecordLowering::calculateZeroInit() {
void CGRecordLowering::clipTailPadding() {
std::vector::iterator Prior = Members.begin();
CharUnits Tail = getSize(Prior->Data);
+
mstorsjo wrote:
Nit: The total PR sums up to adding a
@@ -2866,8 +2871,10 @@
MicrosoftRecordLayoutBuilder::layoutNonVirtualBases(const CXXRecordDecl *RD) {
for (const CXXBaseSpecifier : RD->bases()) {
if (Base.isVirtual())
continue;
+
const CXXRecordDecl *BaseDecl = Base.getType()->getAsCXXRecordDecl();
https://github.com/mstorsjo closed
https://github.com/llvm/llvm-project/pull/65420
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mstorsjo wrote:
CC @cjacek @efriedma-quic
https://github.com/llvm/llvm-project/pull/65420
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Martin Storsjö
Date: 2023-09-01T22:39:38+03:00
New Revision: f9f2fdcf03d9a64741e24a5d480842551163ef4d
URL:
https://github.com/llvm/llvm-project/commit/f9f2fdcf03d9a64741e24a5d480842551163ef4d
DIFF:
Author: Martin Storsjö
Date: 2023-08-24T23:15:26+03:00
New Revision: a23bf1786be7c0738a4cf999c2957155bb32d5af
URL:
https://github.com/llvm/llvm-project/commit/a23bf1786be7c0738a4cf999c2957155bb32d5af
DIFF:
Author: Martin Storsjö
Date: 2023-08-15T10:59:23+03:00
New Revision: d60c3d08e78dfbb4b180776b83e910d810e1f36a
URL:
https://github.com/llvm/llvm-project/commit/d60c3d08e78dfbb4b180776b83e910d810e1f36a
DIFF:
Author: Martin Storsjö
Date: 2023-07-12T11:59:48+03:00
New Revision: a20d57e83441a69fa2bab86593b18cc0402095d2
URL:
https://github.com/llvm/llvm-project/commit/a20d57e83441a69fa2bab86593b18cc0402095d2
DIFF:
Author: Martin Storsjö
Date: 2023-06-03T23:25:33+03:00
New Revision: ac0ea7555ee4ae872bcd153e04513ba0b88b8985
URL:
https://github.com/llvm/llvm-project/commit/ac0ea7555ee4ae872bcd153e04513ba0b88b8985
DIFF:
Author: Martin Storsjö
Date: 2023-05-30T23:05:57+03:00
New Revision: 28b26b161c2f5f8aecf8fffa7220cacc990ba51c
URL:
https://github.com/llvm/llvm-project/commit/28b26b161c2f5f8aecf8fffa7220cacc990ba51c
DIFF:
Author: Martin Storsjö
Date: 2023-05-28T13:16:53+03:00
New Revision: 592e935e115ffb451eb9b782376711dab6558fe0
URL:
https://github.com/llvm/llvm-project/commit/592e935e115ffb451eb9b782376711dab6558fe0
DIFF:
Author: Martin Storsjö
Date: 2023-05-16T10:41:30+03:00
New Revision: c2b256a990590dc8b69930259650cfeb085add03
URL:
https://github.com/llvm/llvm-project/commit/c2b256a990590dc8b69930259650cfeb085add03
DIFF:
Author: Martin Storsjö
Date: 2023-05-10T01:07:45+03:00
New Revision: b80febdf43d33414bbc1c8d8a282a73d8f61a781
URL:
https://github.com/llvm/llvm-project/commit/b80febdf43d33414bbc1c8d8a282a73d8f61a781
DIFF:
Author: Martin Storsjö
Date: 2023-05-10T01:07:37+03:00
New Revision: 7f037e5645bd62fca6fc7c3e77962aafe2bc8b27
URL:
https://github.com/llvm/llvm-project/commit/7f037e5645bd62fca6fc7c3e77962aafe2bc8b27
DIFF:
101 - 200 of 376 matches
Mail list logo
