https://github.com/pogo59 commented:
@adrian-prantl We do have a pretty strong guarantee of compatibility in the
llvm-c API. A new parameter pretty much means you need to define a new function.
https://github.com/llvm/llvm-project/pull/72234
___
cfe-c
pogo59 wrote:
The member is const with an initializer in-class. How is the constant value not
available for the definition?
https://github.com/llvm/llvm-project/pull/71780
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/
pogo59 wrote:
I think it is a valuable bit of information for the debugger, to know the
constant value without having to read it from memory. I think we should emit
both the location and the value.
https://github.com/llvm/llvm-project/pull/71780
___
pogo59 wrote:
> We already have a way to set alignment: it's the "align" attribute.
Is clang aware of the target's default function alignment? I'd thought not, in
which case deferring to LLVM (as this new attribute does) is correct. Happy to
be corrected on this point.
> there isn't any obvio
https://github.com/pogo59 approved this pull request.
One comment, otherwise LGTM.
https://github.com/llvm/llvm-project/pull/72730
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/pogo59 edited https://github.com/llvm/llvm-project/pull/72730
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -69,6 +69,29 @@ static uint32_t getDeclAlignIfRequired(const Decl *D, const
ASTContext &Ctx) {
return D->hasAttr() ? D->getMaxAlignment() : 0;
}
+/// Given a VarDecl corresponding to either the definition or
+/// declaration of a C++ static data member, if it has a const
pogo59 wrote:
I guess I'm a little confused still. Are you claiming that `cold` has a
specified ABI effect? That if some pass decides a function is cold, that
decision (correctly) affects its ABI? I'm not seeing any documentation to that
effect, either on the clang attribute or the IR attribut
pogo59 wrote:
The psABI doesn't say anything about function alignment, implying that align(1)
is functionally correct, and anything more than that is either an optimization
or functional dependency for our target. So, if we depend on anything more, we
have to set alignment explicitly.
@FlameT
pogo59 wrote:
FTR, the "Worker" tab on that buildbot page will point you to the maintainer.
But tagging me is also fine in general.
I'm unable to repro the problem locally because my local build doesn't seem to
include clang-repl.exe, so the whole clang/test/Interpreter directory is
Unsupporte
pogo59 wrote:
If you want to XFAIL specifically for the Sony targets, what you suggested
would work.
I'm unclear about the "MSVC C++ ABI" aspect, but if that gets the test to work,
go for it.
https://github.com/llvm/llvm-project/pull/70991
___
cfe-co
pogo59 wrote:
>From a UI perspective, "add a visibility attribute" doesn't seem all that
>descriptive. What visibility does it add? Therefore, I suggest
>`-fvisibility-global-new-delete[=]` so the user can ask for what
>they want, and `-fvisibility-global-new-delete-hidden` equals
>`-fvisibil
pogo59 wrote:
Ben and I talked about this offline. I was a little skittish about these
power-user options letting you do whatever you wanted, and maybe a small number
(2? 3?) of predefined combinations would be more straightforward. He convinced
me that (a) these wouldn't be needed often, and
pogo59 wrote:
> I do wonder how feasible it would be for the downstream tests to be adjusted
> to look at the `DW_AT_location`..
As I mentioned on the other thread, the point is not to have to read the value
from the process-under-debug. This is not efficient in a remote-debugging
scenario.
pogo59 wrote:
Thanks for adding the guard to the include adxintrin.h, now that it has only
the ADX stuff it is the right way to go. As PS4 code owner I approve!
https://github.com/llvm/llvm-project/pull/75992
___
cfe-commits mailing list
cfe-commits@l
pogo59 wrote:
Actually I kind of prefer all these options to have `-fvisibility-` as a
prefix. Even if it doesn't read quite naturally, it strongly implies that the
options are related (which is true) and any lexically sorted list of options
will naturally group them together. WDYT @frobtech ?
pogo59 wrote:
> Edit: Actually we still have the problem of when in LLVM not knowing if
> optimze-by-size got set on the cold funtion by it being cold or if Os was
> used.
Not sure I understand the question (sorry I missed this comment when it was
made). The suggestion is that for our target,
https://github.com/pogo59 created
https://github.com/llvm/llvm-project/pull/77525
Doxygen comment style for every other intrinsic-function header uses ///
comments, so change ia32intrin.h from the /** style to /// style. While I was
in there, change ` INSTR ` to `\c INSTR` and toss in a few mi
https://github.com/pogo59 updated
https://github.com/llvm/llvm-project/pull/77525
>From cd91a7f0e5cacb682cb6280655a8d1112cecaf6a Mon Sep 17 00:00:00 2001
From: Paul Robinson
Date: Tue, 9 Jan 2024 13:22:36 -0800
Subject: [PATCH 1/2] [Headers][X86] Reformat ia32intrin.h doc to match the
other he
pogo59 wrote:
I'm going to be adding some new function descriptions to this file shortly, and
figured I should get the formatting thing out of the way first.
https://github.com/llvm/llvm-project/pull/77525
___
cfe-commits mailing list
cfe-commits@list
https://github.com/pogo59 closed https://github.com/llvm/llvm-project/pull/77525
___
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/77686
ia32intrin.h gets descriptions for all remaining non-privileged intrinsic
functions; the macros providing alternate names are not described. immintrin.h
ditto, except for the InterlockedExchange functions.
>From
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
conversion
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/4] [Headers][X86] Add rounding and exception notes to
conversion
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/l
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
___
@@ -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 optimi
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
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" t
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 oth
@@ -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, 0xFFF
@@ -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:
I
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 al
@@ -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:
@@ -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:
Do
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
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 line
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 _
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
U
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
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
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
conversion
@@ -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
+///re
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
https://lists.llvm.org/cgi-bin/mail
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
Comparison
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/3] [Headers][X86] Add specific results to comparisons
Comparison
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 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 docum
@@ -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 /*
@@ -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
+/
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?
https://g
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 maili
@@ -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 bits
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
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:
> 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
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
___
@@ -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
+ /// CallDes
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
@@ -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 =
-PathDiagnosticLocation::createBegin(LenArg
@@ -393,20 +385,19 @@ class ExprEngine {
ProgramStateRef processAssume(ProgramStateRef state, SVal cond,
bool assumption);
- /// processRegionChanges - Called by ProgramStateManager whenever a change
is made
+ /// processRegionChanges - Cal
@@ -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 =
-PathDiagnosticLocation::createBegin
@@ -393,20 +385,19 @@ class ExprEngine {
ProgramStateRef processAssume(ProgramStateRef state, SVal cond,
bool assumption);
- /// processRegionChanges - Called by ProgramStateManager whenever a change
is made
+ /// processRegionChanges - Cal
@@ -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 =
-PathDiagnosticLocation::createBegin
@@ -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 various
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
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 a
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/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 R
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/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
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
@@ -3379,6 +3379,54 @@ Query for this feature with
``__has_builtin(__builtin_debugtrap)``.
Query for this feature with ``__has_builtin(__builtin_trap)``.
+``__builtin_verbose_trap``
+--
+
+``__builtin_verbose_trap`` causes the program to stop its exec
https://github.com/pogo59 commented:
The documentation should say that this works only when debug information is
enabled.
https://github.com/llvm/llvm-project/pull/79230
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cg
@@ -3379,6 +3379,54 @@ Query for this feature with
``__has_builtin(__builtin_debugtrap)``.
Query for this feature with ``__has_builtin(__builtin_trap)``.
+``__builtin_verbose_trap``
+--
+
+``__builtin_verbose_trap`` causes the program to stop its exec
@@ -3379,6 +3379,54 @@ Query for this feature with
``__has_builtin(__builtin_debugtrap)``.
Query for this feature with ``__has_builtin(__builtin_trap)``.
+``__builtin_verbose_trap``
+--
+
+``__builtin_verbose_trap`` causes the program to stop its exec
https://github.com/pogo59 edited https://github.com/llvm/llvm-project/pull/79230
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -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";
+
+templ
https://github.com/pogo59 updated
https://github.com/llvm/llvm-project/pull/77686
>From 39a884d27f56772a222d352665be95194716beff Mon Sep 17 00:00:00 2001
From: Paul Robinson
Date: Wed, 10 Jan 2024 10:42:24 -0800
Subject: [PATCH 1/2] [Headers][X86] Add more descriptions to ia32intrin.h and
immi
@@ -173,25 +183,59 @@ __popcntq(unsigned long long __A)
#endif /* __x86_64__ */
#ifdef __x86_64__
+/// Returns the program status and control \c RFLAGS register with the \c VM
+///and \c RF flags cleared.
+///
+/// \headerfile
+///
+/// This intrinsic corresponds to the \
@@ -361,42 +425,146 @@ _wbinvd(void) {
__builtin_ia32_wbinvd();
}
+/// Rotates an 8-bit value to the left by the specified number of bits.
+///This operation is undefined if the number of bits exceeds the size of
+///the value.
+///
+/// \headerfile
+///
+/// This i
pogo59 wrote:
I think "pure virtual" is a more common phrasing than "virtual pure" so maybe
`isPureVirtual` instead? Up to Aaron, though.
https://github.com/llvm/llvm-project/pull/78463
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://l
https://github.com/pogo59 closed https://github.com/llvm/llvm-project/pull/77686
___
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/78613
These are largely copy-pasted from the corresponding function descriptions.
Updated _rdtsc definition because it was just plain wrong.
>From e4c9272ee9cbb918347a23d2dce14c9c12765009 Mon Sep 17 00:00:00 2001
From:
pogo59 wrote:
Reviewer questions:
1. When a macro is merely an alternate name for an intrinsic function, does it
want to be documented as its own intrinsic function? I assume yes in this
patch, but if there's a different tactic that avoids duplicating a bunch of
descriptions, I'm open to sugge
https://github.com/pogo59 updated
https://github.com/llvm/llvm-project/pull/78613
>From e4c9272ee9cbb918347a23d2dce14c9c12765009 Mon Sep 17 00:00:00 2001
From: Paul Robinson
Date: Thu, 18 Jan 2024 10:50:21 -0800
Subject: [PATCH 1/2] [Headers][X86] Add macro descriptions to ia32intrin.h
These a
pogo59 wrote:
> When a macro is merely an alternate name for an intrinsic function, does it
> want to be documented as its own intrinsic function? I assume yes in this
> patch, but if there's a different tactic that avoids duplicating a bunch of
> descriptions, I'm open to suggestions.
I disc
@@ -1,7 +1,7 @@
// RUN: %clang -x c -ffixed-point -S -emit-llvm -o - %s | FileCheck %s
-// RUN: %clang -x c -ffixed-point -S -emit-llvm -o -
--target=x86_64-scei-ps4-ubuntu-fast %s | FileCheck %s
pogo59 wrote:
Thanks for tagging me. These are definitely invalid
@@ -411,13 +497,45 @@ __rdpmc(int __A) {
/// \param __A
///Address of where to store the 32-bit \c IA32_TSC_AUX value.
/// \returns The 64-bit value of the time stamp counter.
+/// \see _rdtsc
static __inline__ unsigned long long __DEFAULT_FN_ATTRS
__rdtscp(unsigned int *
https://github.com/pogo59 updated
https://github.com/llvm/llvm-project/pull/78613
>From e4c9272ee9cbb918347a23d2dce14c9c12765009 Mon Sep 17 00:00:00 2001
From: Paul Robinson
Date: Thu, 18 Jan 2024 10:50:21 -0800
Subject: [PATCH 1/3] [Headers][X86] Add macro descriptions to ia32intrin.h
These a
https://github.com/pogo59 approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/74629
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/pogo59 edited https://github.com/llvm/llvm-project/pull/75364
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -359,6 +359,12 @@ void toolchains::PS4PS5Base::addClangTargetOptions(
CC1Args.push_back("-fno-use-init-array");
+ // Default to -fglobal-new-delete-visibility=source for PS5.
pogo59 wrote:
Spelling in comment needs to match the option spelling.
https:
https://github.com/pogo59 commented:
I'm okay with the PS5-specific bits. Other people should have a chance to chime
in so I won't mark it approved.
https://github.com/llvm/llvm-project/pull/75364
___
cfe-commits mailing list
cfe-commits@lists.llvm.or
@@ -79,6 +107,8 @@ extern void __declspec(dllimport) imported_e();
// EXPLICIT-DAG: declare hidden void @_Z10imported_ev()
// ALL_DEFAULT-DAG: declare void @_Z1ev()
// ALL_DEFAULT-DAG: declare void @_Z10imported_ev()
+// ALL_KEEP-DAG: declare hidden void @_Z1ev()
+// ALL_KEEP-D
1 - 100 of 336 matches
Mail list logo
