https://github.com/pogo59 closed 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
pogo59 wrote:
Abandoning this. We'll work around the brokenness in our downstream repo.
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
pogo59 wrote:
You should have a look at [this imminent
patch](https://github.com/llvm/llvm-project/pull/91724) which will affect your
test.
https://github.com/llvm/llvm-project/pull/95298
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
pogo59 wrote:
Well, hmmm, I dunno, a radical change like this really wants an RFC and weeks
of debate, right?
https://github.com/llvm/llvm-project/pull/95164
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
pogo59 wrote:
> For my toolchain I can continue to carry a patch until this is all sorted.
Same here; I'm just professionally offended by the brokenness. But I'm not the
right person to drive an RFC. If nobody else is willing to, I'll abandon this
and we'll do what we need to downstream to
@@ -0,0 +1,9 @@
+; Test emitting version_min directives.
+
+; RUN: llc %s -filetype=asm -o - --mtriple arm64-apple-tvos9.0.0 | FileCheck
%s --check-prefix=TVOS
pogo59 wrote:
Right, this test has one arm64 command and two thumb commands.
I just now pushed
https://github.com/pogo59 closed https://github.com/llvm/llvm-project/pull/94514
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/pogo59 updated
https://github.com/llvm/llvm-project/pull/94514
>From 19ddcbdf2eabb812b65bd194085777abc48eade4 Mon Sep 17 00:00:00 2001
From: Paul Robinson
Date: Wed, 5 Jun 2024 11:15:46 -0700
Subject: [PATCH 1/2] [Driver] Rearrange some Apple version testing
There were four
pogo59 wrote:
@MaskRay @tru How do we proceed with this? The current state is broken.
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
pogo59 wrote:
I wonder if a lot of the new target-specific headers don't need to be in
clang/include. That subtree is for headers that declare the exported interface
(exported to other libs/layers); if the target-specific headers are just there
for splitting up the module, they can stay in
https://github.com/pogo59 created
https://github.com/llvm/llvm-project/pull/94514
There were four tests in Driver that actually tested bits of Driver and bits of
CodeGen, and therefore had target restrictions. Rework those four tests into
one Driver test (with no target restrictions) and two
https://github.com/pogo59 closed https://github.com/llvm/llvm-project/pull/94276
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/pogo59 updated
https://github.com/llvm/llvm-project/pull/94276
>From b4b78efe9c8119e6b4b1f539847e5678808bf715 Mon Sep 17 00:00:00 2001
From: Paul Robinson
Date: Mon, 3 Jun 2024 12:43:59 -0700
Subject: [PATCH] [Driver] Fix the sysroot.c test properly
A DEFAULT_SYSROOT
https://github.com/pogo59 edited https://github.com/llvm/llvm-project/pull/94276
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
pogo59 wrote:
Pls try in your environments to see if this solves the problem.
https://github.com/llvm/llvm-project/pull/94276
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/pogo59 created
https://github.com/llvm/llvm-project/pull/94276
A DEFAULT_SYSROOT interfered with the test, apparently. See #95055.
>From c89183017ef9719c92077c1be6fd282e22a98e4e Mon Sep 17 00:00:00 2001
From: Paul Robinson
Date: Mon, 3 Jun 2024 12:43:59 -0700
Subject:
pogo59 wrote:
FTR, when I say I could not reproduce on X86 Windows, exactly what I did is
build on an X86 Windows host but include only the AArch64 target. The test
passed.
https://github.com/llvm/llvm-project/pull/94055
___
cfe-commits mailing list
pogo59 wrote:
Correctly written Driver tests do not depend on any particular target. All
Driver code relevant to all targets is present in all cases.
Exactly one test (out of 133) was failing on exactly two bots. I'm not saying
what I did was the best thing; it was expedient, to get the bots
pogo59 wrote:
Let's hope so! Done.
https://github.com/llvm/llvm-project/pull/94000
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/pogo59 closed https://github.com/llvm/llvm-project/pull/94258
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/pogo59 created
https://github.com/llvm/llvm-project/pull/94258
See #94000 for a report of a downstream failure, this fixes it.
>From 21fea52ae628f1105ea562b77f7987f87908d948 Mon Sep 17 00:00:00 2001
From: Paul Robinson
Date: Mon, 3 Jun 2024 10:08:42 -0700
Subject: [PATCH]
https://github.com/pogo59 closed https://github.com/llvm/llvm-project/pull/94253
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/pogo59 created
https://github.com/llvm/llvm-project/pull/94253
After #94055 this test failed on ARM/AArch64-hosted Windows, but it's not clear
why.
>From b31aa18d5abb553e4c44eff338a8c9e8393986b7 Mon Sep 17 00:00:00 2001
From: Paul Robinson
Date: Mon, 3 Jun 2024 09:38:45
pogo59 wrote:
I'm seeing two bot failures:
https://lab.llvm.org/buildbot/#/builders/60/builds/17462
https://lab.llvm.org/buildbot/#/builders/119/builds/18845
both for sysroot.c.
These are Arm/AArch64 Windows bots, based on the names, which is not an
environment I have available. I cannot
pogo59 wrote:
If you add `--no-cuda-version-check` does the error go away?
https://github.com/llvm/llvm-project/pull/94000
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
pogo59 wrote:
Yeah lit is not so good at this; it means clang exited with an error, but lit
is somehow eating the error message. @erichkeane If you could run that clang
command manually and report the output, that would be extremely helpful.
https://github.com/llvm/llvm-project/pull/94000
https://github.com/pogo59 closed https://github.com/llvm/llvm-project/pull/94055
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1,6 +1,4 @@
// REQUIRES: system-linux
pogo59 wrote:
I hope you feel empowered to post more cleanup patches upstream!
https://github.com/llvm/llvm-project/pull/94055
___
cfe-commits mailing list
https://github.com/pogo59 created
https://github.com/llvm/llvm-project/pull/94055
Removed foo-registered-target constraints from a bunch of tests, because mostly
the driver doesn't need to have a target availabile. I ran check-clang-driver
using a build with only the XCore target, and these
https://github.com/pogo59 closed https://github.com/llvm/llvm-project/pull/94000
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/pogo59 created
https://github.com/llvm/llvm-project/pull/94000
…g run" (#93988)"
This reverts commit 6416958067179c2987af0ef4568cd57f98b7e347.
Fix bots by using different options.
>From 100fb8de09303d15def2dd8db1bf1e6a106e4763 Mon Sep 17 00:00:00 2001
From: Paul Robinson
pogo59 wrote:
Reverted; the change to offloading-interoperability.c is not correct. I have
someone willing to run experiments for me to find another solution.
It would be good if the cuda/nvptx/etc bots ran check-clang-driver as well as
the llvm tests. These just never get run.
https://github.com/pogo59 closed https://github.com/llvm/llvm-project/pull/93988
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/pogo59 created
https://github.com/llvm/llvm-project/pull/93988
Reverts llvm/llvm-project#93960
The change to offloading-interoperability.c broke many bots.
>From 8ce093226b730338a8faacb4ef09f97bcbc17515 Mon Sep 17 00:00:00 2001
From: Paul T Robinson
Date: Fri, 31 May 2024
https://github.com/pogo59 closed https://github.com/llvm/llvm-project/pull/93960
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
pogo59 wrote:
I found these because while I normally build with all targets, I don't usually
bother running check-all. The other day I did, and these two tests failed.
Driver tests normally should not need *-registered-target constraints, and
these tests were looking at the host's CUDA
https://github.com/pogo59 created
https://github.com/llvm/llvm-project/pull/93960
None
>From efbbb7b729ba4a24413f3d2a1769effba3581d8f Mon Sep 17 00:00:00 2001
From: Paul Robinson
Date: Fri, 31 May 2024 06:11:30 -0700
Subject: [PATCH] [CUDA] Fix a couple of driver tests that really weren't
pogo59 wrote:
Mildly curious that there isn't a SemaX86?
https://github.com/llvm/llvm-project/pull/93179
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
pogo59 wrote:
What @SLTozer said. I don't want "members" to mean "some but not all members"
and "methods" was shorter than "member-functions" (but I'm okay with
"member-functions").
https://github.com/llvm/llvm-project/pull/87018
___
cfe-commits
@@ -4849,9 +4852,12 @@ CodeGenModule::GetOrCreateLLVMGlobal(StringRef
MangledName, llvm::Type *Ty,
Entry->setLinkage(llvm::Function::ExternalLinkage);
}
-// Handle dropped DLL attributes.
-if (D && !D->hasAttr() && !D->hasAttr() &&
-
@@ -4554,8 +4554,11 @@ llvm::Constant *CodeGenModule::GetOrCreateLLVMFunction(
Entry->setLinkage(llvm::Function::ExternalLinkage);
}
-// Handle dropped DLL attributes.
-if (D && !D->hasAttr() && !D->hasAttr() &&
+// Handle dropped dllimport.
+if (D
https://github.com/pogo59 edited https://github.com/llvm/llvm-project/pull/93302
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/pogo59 commented:
Does the test exercise both modified paths? I'm guessing it only exercises
GetOrCreateLLVMFunction, but I'm not a codegen expert.
https://github.com/llvm/llvm-project/pull/93302
___
cfe-commits mailing list
https://github.com/pogo59 approved this pull request.
I've been persuaded this is the right direction. LGTM.
https://github.com/llvm/llvm-project/pull/92579
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
@@ -1793,6 +1793,36 @@ void ItaniumCXXABI::EmitDestructorCall(CodeGenFunction
,
ThisTy, VTT, VTTTy, nullptr);
}
+// Check if any non-inline method has the specified attribute.
+template
+static bool CXXRecordNonInlineHasAttr(const CXXRecordDecl
https://github.com/pogo59 edited https://github.com/llvm/llvm-project/pull/92579
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/pogo59 commented:
I am moderately sure this does what we (Sony) want, but I would like a second
set of eyes on it so I'm not marking it approved.
https://github.com/llvm/llvm-project/pull/92579
___
cfe-commits mailing list
@@ -0,0 +1,115 @@
+/// For a class that has a vtable and typeinfo symbol for RTTI, if a user marks
+/// either:
+///
+/// (a) The entire class as dllexport (dllimport)
+/// (b) Any non-inline method of the class as dllexport (dllimport)
+///
+/// then Clang must export the
https://github.com/pogo59 approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/92549
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,32 @@
+/// Check PS4 specific interactions between visibility options.
+/// Detailed testing of -fvisibility-from-dllstorageclass is covered elsewhere.
+
+/// Check defaults.
+// RUN: %clang -### -target x86_64-scei-ps4 -x cl -c -emit-llvm %s 2>&1 | \
+// RUN:
https://github.com/pogo59 approved this pull request.
LGTM. I noted a couple of redundant checks, but if you think it's better for
them to be explicit, I'm okay with keeping them.
https://github.com/llvm/llvm-project/pull/92091
___
cfe-commits
https://github.com/pogo59 edited https://github.com/llvm/llvm-project/pull/92091
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,33 @@
+/// Check PS5 specific interactions between visibility options.
+/// Detailed testing of -fvisibility-from-dllstorageclass is covered elsewhere.
+
+/// Check defaults.
+// RUN: %clang -### -target x86_64-sie-ps5 -x cl -c -emit-llvm %s 2>&1 | \
+// RUN:
pogo59 wrote:
> @pogo59 - you might find this interesting in terms of bitrotten tests, etc.
Fixing these typos is great. Identifying recurring patterns in the typos would
help motivate changes to FileCheck itself to detect them sooner. I think
@jdenny-ornl might have had some private patches,
pogo59 wrote:
Thanks for the link. I've put a comment there pointing here, explaining that
the current default state (at least on Windows) is broken and that this patch
has come to no agreement about how to fix it.
https://github.com/llvm/llvm-project/pull/89775
https://github.com/pogo59 closed https://github.com/llvm/llvm-project/pull/91401
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
pogo59 wrote:
This test was failing in our downstream repo because the metadata didn't come
out in exactly the same order.
https://github.com/llvm/llvm-project/pull/91401
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/pogo59 created
https://github.com/llvm/llvm-project/pull/91401
Debug-info metadata does not have a strictly defined order. Check that elements
are linked to each other correctly, not that metadata appears in a particular
order.
>From
pogo59 wrote:
> I want to hear about opinions why the old compiler-rt file hierarchy is
> preferred by some users.
I think if you really want a range of opinions, you can get them from an RFC.
Not many people will be watching this PR.
https://github.com/llvm/llvm-project/pull/89775
https://github.com/pogo59 commented:
The LLVM changes don't have a test. I expect there are existing
expression-to-final-DWARF tests that you can modify to throw in a few bit-piece
operators and show they come out correctly.
Offhand it seems quite reasonable to use DW_OP_bit_piece for
pogo59 wrote:
Driver tests are supposed to verify Driver behavior. That is, use `-###` and
make sure the correct option is being passed down to the compiler. They should
not be compiling anything.
https://github.com/llvm/llvm-project/pull/89727
___
pogo59 wrote:
To answer @MaskRay 's question directly, with respect to PlayStation (not
Windows, which is the major problem):
We have exactly one target, so neither the arch suffix nor a target-specific
directory are useful. (Arguably we have two targets, but as we deliver entirely
separate
pogo59 wrote:
My understanding is that this change never had a proper Discourse RFC, which
means it was quite possible for vendors not to have noticed it. Certainly I (on
behalf of Sony) was not aware, and I make some effort to keep an eye on things.
There is no good reason to suppose Visual
pogo59 wrote:
@mstorsjo On reflection I agree that a build-time choice for handling this is
not appropriate. It really wants to be target-based. Latest version (a) falls
back to old style for Windows/PS as well as AIX, (b) adds a driver option to
influence that default.
@MaskRay @tru @nico
https://github.com/pogo59 edited 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
pogo59 wrote:
Worth noting that this only affects the presumed layout if the driver can't
find either layout. In most installations, it will detect which one you have
installed, and use it correctly. It's when the driver can't find the libs, and
has to guess, that we run into difficulty.
I
pogo59 wrote:
I've redone the decision to be based on the setting of
LLVM_ENABLE_PER_TARGET_RUNTIME_DIR and updated the tests to work with either
setting as much as possible. Tests that explicitly look for the per-target
_directory_ are enabled only if the CMake variable is ON.
https://github.com/pogo59 updated
https://github.com/llvm/llvm-project/pull/89775
>From c8b04739159fcd4775656aabb4b964272add8c36 Mon Sep 17 00:00:00 2001
From: Paul Robinson
Date: Tue, 23 Apr 2024 08:10:47 -0700
Subject: [PATCH 1/2] [Driver] Restore arch suffix for PS and Windows
Commit
pogo59 wrote:
> `optnone` is a very strange attribute; it's a directive to the compiler with
> no clear semantics.
In an ideal world, an `optnone` function would be compiled as-if the entire
compilation unit had `-O0`. At `-O0`, Clang attaches `optnone` to every
function, implying that this
pogo59 wrote:
Poking around more, it looks like the canonical way to convert a CMake variable
to a C++ define is to add an entry to
llvm/include/llvm/Config/llvm-config.h.cmake. I'll have a go at doing it that
way.
https://github.com/llvm/llvm-project/pull/89775
pogo59 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 Windows/PS check, seems
pogo59 wrote:
> There have been a few cases before and we did not write specific release
> notes for the driver behavior:
Possibly users of those targets do not depend on distributed builds the way our
users do, and didn't run into the problem? They don't look like Windows
targets, anyway.
pogo59 wrote:
> I think the distributed build system users need to prepare a file hierarchy
> to get the intended --dependent-lib= (like how to prepare --sysroot in
> clang/test/Driver tests), or turn off it with the recent -frtlib-defaultlib.
Is there a Release Note for this new requirement
pogo59 wrote:
> My recollection of the past discussions is that we want users to switch to
> the new hierarchy.
Is Microsoft a "user" who agreed to this change? Was clang-vendors tagged on
this discussion about a new file hierarchy? I don't recall it. The library name
change is news to me,
pogo59 wrote:
> It's been like that for maybe 2-3 years now and no one has complained about it
As a downstream vendor I can tell you we work around things all the time
without bothering to try to fix things upstream (I try to encourage more
engagement, but I can't control what people actually
pogo59 wrote:
> what gets emitted as embedded directive, when the compiler doesn't see either
> of them at compile time (with e.g. distributed build systems), while they
> might be available at link time.
This is exactly the scenario we had. I will double-check that it is solved by
my patch,
pogo59 wrote:
> if you build with runtimes on windows (which is the suggested way) it will
> end up with the new style without arch suffix
Was someone from Microsoft party to that decision? If not, perhaps it needs to
be revisited. We should not be making decisions about how they want to do
pogo59 wrote:
Microsoft obviously builds and distributes with the arch suffix, supporting
both 32-bit and 64-bit in the same distro. So I think they will continue to
need it. (I can't actually speak for MS, but it's what I see in the Visual
Studio installation.)
I don't know enough about how
https://github.com/pogo59 edited 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
https://github.com/pogo59 created
https://github.com/llvm/llvm-project/pull/89775
Commit b876596 corrected default compiler-rt library names for many targets,
this patch restores the arch suffix for PlayStation and Windows which both
distribute these libraries with the arch suffix.
>From
pogo59 wrote:
Yes, driver part LGTM.
https://github.com/llvm/llvm-project/pull/87623
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
pogo59 wrote:
FTR, got an internal report about this. Luckily it was my turn to catch new
bugs and I recognized the issue.
@MaskRay Is it too late to add a Release Note for LLVM 18?
https://github.com/llvm/llvm-project/pull/74809
___
cfe-commits
@@ -310,6 +310,24 @@ namespace llvm {
DINode::DIFlags Flags = DINode::FlagZero,
DINodeArray Annotations = nullptr);
+/// Create debugging information entry for a template alias.
+/// \param Ty
@@ -310,6 +310,24 @@ namespace llvm {
DINode::DIFlags Flags = DINode::FlagZero,
DINodeArray Annotations = nullptr);
+/// Create debugging information entry for a template alias.
+/// \param Ty
@@ -465,3 +465,15 @@
// MANGLED_TEMP_NAMES: error: unknown argument
'-gsimple-template-names=mangled'; did you mean '-Xclang
-gsimple-template-names=mangled'
// RUN: %clang -### -target x86_64 -c -g %s 2>&1 | FileCheck
--check-prefix=FULL_TEMP_NAMES
https://github.com/pogo59 edited https://github.com/llvm/llvm-project/pull/87623
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1332,6 +1332,54 @@ llvm::DIType *CGDebugInfo::CreateType(const
TemplateSpecializationType *Ty,
auto PP = getPrintingPolicy();
Ty->getTemplateName().print(OS, PP, TemplateName::Qualified::None);
+ SourceLocation Loc = AliasDecl->getLocation();
+
+ if
https://github.com/pogo59 commented:
The flag situation is good. Tuning influences the default for the new option,
which is how we want that to work.
I'm happy, a couple of nits left. I'll leave it to others to do the final
approval.
https://github.com/llvm/llvm-project/pull/87623
@@ -465,3 +465,15 @@
// MANGLED_TEMP_NAMES: error: unknown argument
'-gsimple-template-names=mangled'; did you mean '-Xclang
-gsimple-template-names=mangled'
// RUN: %clang -### -target x86_64 -c -g %s 2>&1 | FileCheck
--check-prefix=FULL_TEMP_NAMES
@@ -5361,7 +5383,56 @@ static bool IsReconstitutableType(QualType QT) {
return T.Reconstitutable;
}
-std::string CGDebugInfo::GetName(const Decl *D, bool Qualified) const {
+bool CGDebugInfo::HasReconstitutableArgs(
+ArrayRef Args) const {
+ return llvm::all_of(Args,
@@ -4584,6 +4584,32 @@ renderDebugOptions(const ToolChain , const Driver ,
const llvm::Triple ,
}
}
+ // Emit DW_TAG_template_alias for template aliases? True by default for SCE.
+ const auto *DebugTemplateAlias = Args.getLastArg(
+ options::OPT_gtemplate_alias,
https://github.com/pogo59 deleted
https://github.com/llvm/llvm-project/pull/87623
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -4584,6 +4584,32 @@ renderDebugOptions(const ToolChain , const Driver ,
const llvm::Triple ,
}
}
+ // Emit DW_TAG_template_alias for template aliases? True by default for SCE.
+ const auto *DebugTemplateAlias = Args.getLastArg(
+ options::OPT_gtemplate_alias,
pogo59 wrote:
> @pogo59 Hmm - I thought you held a strong preference that debugger tuning
> never be the only way to access a certain feature, and that we should always
> have direct control of these features via flags (but with default (or
> explicit) debugger tuning setting some of these
pogo59 wrote:
Thanks for the link back to the Phab review, that was helpful. I didn't offhand
recall the previous round of this. I'll trust the comments I made on that
review. :)
s/members/methods/ in the option name to avoid the incorrect implication of
suppressing data members?
I suggest
pogo59 wrote:
As a data point, I've been setting `core.autocrlf=true` on Windows for years.
I've been trained to make sure _new_ files have LF endings (usually I copy an
existing file instead of creating a new file) but both Notepad and the Visual
Studio editor are willing to preserve the
https://github.com/pogo59 closed https://github.com/llvm/llvm-project/pull/85862
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -513,7 +526,7 @@ static __inline__ __m128d __DEFAULT_FN_ATTRS
_mm_cmpge_pd(__m128d __a,
///operand are ordered with respect to those in the second operand.
///
///A pair of double-precision values are "ordered" with respect to each
pogo59 wrote:
https://github.com/pogo59 updated
https://github.com/llvm/llvm-project/pull/85862
>From 5ed257ea248a5868cd3190bd1ad89413a1606370 Mon Sep 17 00:00:00 2001
From: Paul Robinson
Date: Tue, 19 Mar 2024 13:20:14 -0700
Subject: [PATCH 1/2] [X86][Headers] Specify result of NaN comparisons
Make sure
@@ -710,6 +728,7 @@ _mm_cmpge_ps(__m128 __a, __m128 __b)
///
///The comparison yields 0x0 for false, 0x for true, in the
///low-order bits of a vector of [4 x float].
+///If either value in a comparison is NaN, returns false.
pogo59 wrote:
1 - 100 of 260 matches
Mail list logo
