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:
@@ -1168,8 +1202,8 @@ _mm_comige_ss(__m128 __a, __m128 __b)
///operands to determine if the first operand is not equal to the second
///operand.
///
-///The comparison returns 0 for false, 1 for true. If either of the two
-///lower floating-point values is NaN,
@@ -207,6 +207,8 @@ _mm256_div_ps(__m256 __a, __m256 __b)
/// Compares two 256-bit vectors of [4 x double] and returns the greater
///of each pair of values.
///
+///If either value in a comparison is NaN, returns the value from \a __b.
pogo59 wrote:
@@ -4743,7 +4771,9 @@ static __inline__ __m128d __DEFAULT_FN_ATTRS
_mm_castsi128_pd(__m128i __a) {
///128-bit vectors of [2 x double], using the operation specified by the
///immediate integer operand.
///
-///Each comparison yields 0x0 for false,
pogo59 wrote:
cc @craigflores
I have resisted the temptation to do a general editorial pass over these
headers. This patch is "functional" in that it (mostly) adds information that
was not provided before. There's a lot that could be done to make the
descriptions more consistent with each
https://github.com/pogo59 created
https://github.com/llvm/llvm-project/pull/85862
Make sure all float/double comparison intrinsics specify what happens with a
NaN input. Update some existing descriptions of comparison results to make them
all consistent.
Also replace "yields" with "returns"
https://github.com/pogo59 closed https://github.com/llvm/llvm-project/pull/83447
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,49 @@
+// RUN: %clang_cc1 -triple arm64-apple-ios -std=c++20 -emit-llvm
-debug-info-kind=limited %s -o - | FileCheck %s
pogo59 wrote:
If you want to test optimization behavior, that would be an LLVM test starting
from IR. Clang itself does not
pogo59 wrote:
> CC @llvm/clang-vendors
Thank you for that! I don't know whether our sanitizer guys were aware of this,
I've filed an internal ticket to find out.
+1 to the complaint about no Release Note.
https://github.com/llvm/llvm-project/pull/74809
pogo59 wrote:
> Do we know the users of *-windows-itanium triples?
I think @bd1976bris might have been using that triple for testing the
dllimport/visibility intersection. I've lost track and don't know what state
that's in now, and whether the triple is still used by us.
https://github.com/pogo59 updated
https://github.com/llvm/llvm-project/pull/83447
>From 64cdd358d0bf359383a5dd3d1da236a219644c9e Mon Sep 17 00:00:00 2001
From: Paul Robinson
Date: Thu, 29 Feb 2024 08:59:26 -0800
Subject: [PATCH 1/4] [Headers][X86] Add rounding and exception notes to
pogo59 wrote:
Reworded the parts about truncating results.
https://github.com/llvm/llvm-project/pull/83447
___
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/83447
>From 64cdd358d0bf359383a5dd3d1da236a219644c9e Mon Sep 17 00:00:00 2001
From: Paul Robinson
Date: Thu, 29 Feb 2024 08:59:26 -0800
Subject: [PATCH 1/3] [Headers][X86] Add rounding and exception notes to
https://github.com/pogo59 closed https://github.com/llvm/llvm-project/pull/83316
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
pogo59 wrote:
Thanks!
https://github.com/llvm/llvm-project/pull/84136
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1405,11 +1413,12 @@ static __inline__ __m128d __DEFAULT_FN_ATTRS
_mm_cvtss_sd(__m128d __a,
/// Converts the two double-precision floating-point elements of a
///128-bit vector of [2 x double] into two signed 32-bit integer values,
-///returned in the lower 64
pogo59 wrote:
> I think so - we're just losing the extra info about -1/0 or 1/0 result values?
That's my understanding. I haven't actually tried regenerating the tooltips to
check.
https://github.com/llvm/llvm-project/pull/83316
___
cfe-commits
https://github.com/pogo59 commented:
The example for `\fn` in the [doxygen
documentation](https://www.doxygen.nl/manual/commands.html#cmdfn) puts the
directive at the top of the comment block, not at the end. Do we know whether
putting it at the end will produce the expected result?
@@ -4745,6 +4745,77 @@ static __inline__ __m128d __DEFAULT_FN_ATTRS
_mm_castsi128_pd(__m128i __a) {
return (__m128d)__a;
}
+/// Compares each of the corresponding double-precision values of two
+///128-bit vectors of [2 x double], using the operation specified by the
@@ -2940,6 +2940,84 @@ _mm_movemask_ps(__m128 __a)
return __builtin_ia32_movmskps((__v4sf)__a);
}
+/* Compare */
+#define _CMP_EQ_OQ0x00 /* Equal (ordered, non-signaling) */
+#define _CMP_LT_OS0x01 /* Less-than (ordered, signaling) */
+#define _CMP_LE_OS0x02
@@ -4745,6 +4745,77 @@ static __inline__ __m128d __DEFAULT_FN_ATTRS
_mm_castsi128_pd(__m128i __a) {
return (__m128d)__a;
}
+/// Compares each of the corresponding double-precision values of two
+///128-bit vectors of [2 x double], using the operation specified by the
@@ -2940,6 +2940,84 @@ _mm_movemask_ps(__m128 __a)
return __builtin_ia32_movmskps((__v4sf)__a);
}
+/* Compare */
+#define _CMP_EQ_OQ0x00 /* Equal (ordered, non-signaling) */
+#define _CMP_LT_OS0x01 /* Less-than (ordered, signaling) */
+#define _CMP_LE_OS0x02
https://github.com/pogo59 commented:
Thanks for the heads-up @RKSimon I've made suggestions for consistency with
existing practice in emmintrin.h which I've adopted in the latest revision to
#83316.
I'm unsure how replacing a function declaration with an \fn directive will play
with our
https://github.com/pogo59 edited https://github.com/llvm/llvm-project/pull/84136
___
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/83316
>From 2afca3e91d96cc77f43556bbf71b6e60a22e45f2 Mon Sep 17 00:00:00 2001
From: Paul Robinson
Date: Wed, 28 Feb 2024 11:04:41 -0800
Subject: [PATCH 1/3] [Headers][X86] Add specific results to comparisons
pogo59 wrote:
@RKSimon note this will affect what the tooltips show. Is that okay?
https://github.com/llvm/llvm-project/pull/83316
___
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/83316
>From 2afca3e91d96cc77f43556bbf71b6e60a22e45f2 Mon Sep 17 00:00:00 2001
From: Paul Robinson
Date: Wed, 28 Feb 2024 11:04:41 -0800
Subject: [PATCH 1/2] [Headers][X86] Add specific results to comparisons
pogo59 wrote:
@RKSimon I was not aware of the comparison intrinsics in emmintrin.h. I will
follow that pattern.
https://github.com/llvm/llvm-project/pull/83316
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
@@ -2180,7 +2180,8 @@ _mm256_cvtepi32_pd(__m128i __a)
return (__m256d)__builtin_convertvector((__v4si)__a, __v4df);
}
-/// Converts a vector of [8 x i32] into a vector of [8 x float].
+/// Converts a vector of [8 x i32] into a vector of [8 x float]. Rounds inexact
+///
https://github.com/pogo59 updated
https://github.com/llvm/llvm-project/pull/83447
>From 64cdd358d0bf359383a5dd3d1da236a219644c9e Mon Sep 17 00:00:00 2001
From: Paul Robinson
Date: Thu, 29 Feb 2024 08:59:26 -0800
Subject: [PATCH 1/2] [Headers][X86] Add rounding and exception notes to
pogo59 wrote:
I grepped `clang` for "^/+=[^/]*/.*\.(h|cpp) " and found only 35 files with
directory components. So, the majority of files have only the filename in the
header line. The example in the Coding Standard does not reflect common
practice.
I think it's fine to remove everything but
pogo59 wrote:
FYI @cflores
https://github.com/llvm/llvm-project/pull/83447
___
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/83447
Consistently describe rounding/truncating on convert intrinsics. Add notes
where an out-of-range result can raise an exception.
>From 64cdd358d0bf359383a5dd3d1da236a219644c9e Mon Sep 17 00:00:00 2001
From: Paul
pogo59 wrote:
Also tag @cflores for your review.
https://github.com/llvm/llvm-project/pull/83316
___
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/83316
Comparison intrinsics were described as returning the "result" without
specifying how. The "cmp" intrinsics return zero or all 1's in the
corresponding elements of a returned vector; the "com" intrinsics return
https://github.com/pogo59 closed https://github.com/llvm/llvm-project/pull/82422
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1,10 +1,10 @@
-//===- unittest/ASTMatchers/Dynamic/VariantValueTest.cpp - VariantValue unit
tests -===//
+// unittest/ASTMatchers/Dynamic/VariantValueTest.cpp - VariantValue unit tests
pogo59 wrote:
Repeating the full path name seems unnecessary? (In
@@ -244,24 +246,25 @@ void WalkAST::VisitCallExpr(CallExpr *CE) {
if (containsBadStrlcpyStrlcatPattern(CE)) {
const Expr *DstArg = CE->getArg(0);
const Expr *LenArg = CE->getArg(2);
- PathDiagnosticLocation Loc =
-
@@ -393,20 +385,19 @@ class ExprEngine {
ProgramStateRef processAssume(ProgramStateRef state, SVal cond,
bool assumption);
- /// processRegionChanges - Called by ProgramStateManager whenever a change
is made
+ /// processRegionChanges -
@@ -244,24 +246,25 @@ void WalkAST::VisitCallExpr(CallExpr *CE) {
if (containsBadStrlcpyStrlcatPattern(CE)) {
const Expr *DstArg = CE->getArg(0);
const Expr *LenArg = CE->getArg(2);
- PathDiagnosticLocation Loc =
-
@@ -393,20 +385,19 @@ class ExprEngine {
ProgramStateRef processAssume(ProgramStateRef state, SVal cond,
bool assumption);
- /// processRegionChanges - Called by ProgramStateManager whenever a change
is made
+ /// processRegionChanges -
@@ -219,17 +219,19 @@ void WalkAST::VisitCallExpr(CallExpr *CE) {
if (containsBadStrncatPattern(CE)) {
const Expr *DstArg = CE->getArg(0);
const Expr *LenArg = CE->getArg(2);
- PathDiagnosticLocation Loc =
-
https://github.com/pogo59 edited https://github.com/llvm/llvm-project/pull/82599
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -107,7 +107,8 @@ class CallDescription {
return CD1.matches(Call);
}
- /// \copydoc clang::ento::CallDescription::matchesAny(const CallEvent &,
const CallDescription &)
+ /// \copydoc clang::ento::CallDescription::matchesAny(const CallEvent &,
const
+ ///
https://github.com/pogo59 commented:
Would be good to feed back some of these examples to the RFC. Improving how
clang-format handles some of these cases (esp. the doxygen ones) would help
progress toward the goal.
https://github.com/llvm/llvm-project/pull/82599
pogo59 wrote:
> This seems akin to running clang-format on the entire project, which last
> time we talked about still faced opposition
My impression (I admit I haven't reviewed the whole thread lately) is that the
opposition has mostly to do with how clang-format mangles some constructs, not
@@ -2099,9 +2099,11 @@ static __inline__ __m128i __DEFAULT_FN_ATTRS
_mm_add_epi64(__m128i __a,
}
/// Adds, with saturation, the corresponding elements of two 128-bit
-///signed [16 x i8] vectors, saving each sum in the corresponding element
of
-///a 128-bit result
@@ -2099,9 +2099,11 @@ static __inline__ __m128i __DEFAULT_FN_ATTRS
_mm_add_epi64(__m128i __a,
}
/// Adds, with saturation, the corresponding elements of two 128-bit
-///signed [16 x i8] vectors, saving each sum in the corresponding element
of
-///a 128-bit result
pogo59 wrote:
@cflores this is the upstream review I mentioned
https://github.com/llvm/llvm-project/pull/82422
___
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/82422
In Sony's document processing, the first "paragraph" of the description is
copied to a Brief Description section. Add paragraph breaks to make those brief
descriptions less verbose.
In fmaintrin.h we were
https://github.com/pogo59 closed https://github.com/llvm/llvm-project/pull/80490
___
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/80490
>From c068144b1e372aec29f268edf7184ee3d3dc7d54 Mon Sep 17 00:00:00 2001
From: Paul Robinson
Date: Fri, 2 Feb 2024 12:38:16 -0800
Subject: [PATCH 1/2] [Headers][X86] Editorial fixes to ia32intrin.h
descriptions
pogo59 wrote:
Tag @cflores as well,
https://github.com/llvm/llvm-project/pull/80490
___
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/80490
Use indicative not imperative; fix missing capitalization; spell out some
abbreviations; "time-stamp" not "time stamp".
>From c068144b1e372aec29f268edf7184ee3d3dc7d54 Mon Sep 17 00:00:00 2001
From: Paul Robinson
@@ -0,0 +1,28 @@
+// RUN: %clang_cc1 -std=c++11 -fsyntax-only -fcxx-exceptions -verify %s
+
+#if !__has_builtin(__builtin_verbose_trap)
+#error
+#endif
+
+constexpr char const* constMsg1 = "hello";
+char const* const constMsg2 = "hello";
+char const constMsg3[] = "hello";
+
1 - 100 of 206 matches
Mail list logo
