https://github.com/AaronBallman approved this pull request.
LGTM but a question about whether a test should be split off or not.
https://github.com/llvm/llvm-project/pull/99331
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/99331
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1721,11 +1721,13 @@ void Preprocessor::ExpandBuiltinMacro(Token ) {
Diag(Tok.getLocation(), diag::warn_pp_date_time);
// MSVC, ICC, GCC, VisualAge C++ extension. The generated string should be
// of the form "Ddd Mmm dd hh::mm::ss ", which is returned by
@@ -1722,10 +1722,12 @@ void Preprocessor::ExpandBuiltinMacro(Token ) {
// MSVC, ICC, GCC, VisualAge C++ extension. The generated string should be
// of the form "Ddd Mmm dd hh::mm::ss ", which is returned by asctime.
const char *Result;
+char
https://github.com/AaronBallman approved this pull request.
LGTM, thank you!
https://github.com/llvm/llvm-project/pull/99330
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -2068,7 +2068,8 @@ bool Lexer::LexNumericConstant(Token , const char
*CurPtr) {
}
// If we have a digit separator, continue.
- if (C == '\'' && (LangOpts.CPlusPlus14 || LangOpts.C23)) {
+ if (C == '\'' &&
+ (LangOpts.CPlusPlus14 || LangOpts.C23 ||
https://github.com/AaronBallman approved this pull request.
LGTM assuming @andykaylor doesn't have any additional concerns.
https://github.com/llvm/llvm-project/pull/98520
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
AaronBallman wrote:
> > Out of curiosity, how does the current division of Sema fit into the
> > "unique language dialect" classification? I've noticed there are a bunch of
> > architecture specific Sema classes (e.g. SemaRISCV, SemaX86) and those
> > don't really fit the classification.
>
>
@@ -1722,10 +1722,12 @@ void Preprocessor::ExpandBuiltinMacro(Token ) {
// MSVC, ICC, GCC, VisualAge C++ extension. The generated string should be
// of the form "Ddd Mmm dd hh::mm::ss ", which is returned by asctime.
const char *Result;
+char
AaronBallman wrote:
> I can add test with sizeof for sure, the problem is that it is already
> working https://godbolt.org/z/K69v8KPYa and we have similar ones in codebase
> already.
Ah, if we have sufficient coverage already, that's fine. I was just thinking
about coverage in general,
AaronBallman wrote:
> > > As noted above `-fbounds-safety` **is a C language extension** which
> > > makes it seem like it would fit nicely into the existing division of Sema
> > > into multiple objects and relevant source files.
> >
> >
> > No, it doesn't fit nicely into the division, which
https://github.com/AaronBallman approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/94355
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
> The part I'm confused about is that this commit doesn't appear to simply be
> adding "or `alignas`" to some code that said "if `_Alignas`". Yes, the newly
> added `isAlignas()` checks do cover both attributes, but `_Alignas` was still
> working even after
>
AaronBallman wrote:
d3f8105c65046173e20c4c59394b4a7f1bbe7627 restores the targets, thank you all
for the discussion!
https://github.com/llvm/llvm-project/pull/98497
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/99079
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
> After some initial experiments, it looks unlikely that a quick fix is
> possible on our side. May I suggest a revert with a (say) 30-day expiration
> date? That should give us enough time to come up with a fix on our side
> (which will actually be a
AaronBallman wrote:
> > > Could you add a flang driver test as well?
> >
> >
> > The RFC was specifically about `-Ofast` in Clang and not behavior in Flang,
> > so what test behavior would you like to see? This patch currently
> > deprecates for both Clang and Flang, is that acceptable?
>
>
AaronBallman wrote:
> Could you add a flang driver test as well?
The RFC was specifically about `-Ofast` in Clang and not behavior in Flang, so
what test behavior would you like to see? This patch currently deprecates for
both Clang and Flang, is that acceptable?
https://github.com/AaronBallman approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/98671
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman commented:
Changes LGTM but I agree with @cor3ntin that we should add the test case from
https://github.com/llvm/llvm-project/pull/97274#issuecomment-2230410564
explicitly. Some other tests to consider adding at the same time:
```
static_assert(_Generic(
#embed
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/99038
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman commented:
I mostly support the removal but I'd feel more comfortable documenting the
extension as deprecated in Clang 18, adding a release note warning users about
it going away and what the replacement code would look like, and then remove
`__is_nullptr()` in
https://github.com/AaronBallman commented:
While I think these changes are defensible, I think I would prefer to *not*
move all of the blocks logic into SemaObjC, but I'd love to hear if @rjmccall
agrees with my rationale and conclusion.
Blocks are largely an Objective-C feature, so putting
AaronBallman wrote:
The separations we've been making so far in `Sema` have been at a higher level
of granularity than this proposal. Vlad was calling it "language extensions"
but perhaps a different way to phrase it would be "unique language dialects".
e.g., Objective-C is its own language,
@@ -344,10 +352,17 @@ class ComplexExprEmitter
return QualType();
}
+ template
+ FPOptionsOverride getStoredFPFeaturesOrDefault(const T *E,
+ const CodeGenFunction ) {
AaronBallman wrote:
`CGF` is
AaronBallman wrote:
> It looks like the removal missed a few bits: PNaClABIBuiltinVaList and
> clang/lib/CodeGen/Targets/PNaCl.cpp weren't removed.
I was under the impression those bits were still needed for Chromium. CC
@dschuff
> > Unfortunately, this utterly breaks Halide, which was in
https://github.com/AaronBallman approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/98736
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/99023
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/97274
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
> I thought there was agreement that at least for C the literals have type int,
That's correct; this patch gets started on addressing that issue by updating
the way we expand the embedded contents but isn't intended to fix the type
issue yet (that will be a follow-up
https://github.com/AaronBallman approved this pull request.
The 32-bit fix LGTM!
https://github.com/llvm/llvm-project/pull/99022
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -442,6 +442,9 @@ def warn_drv_deprecated_arg : Warning<
def warn_drv_deprecated_arg_no_relaxed_template_template_args : Warning<
"argument '-fno-relaxed-template-template-args' is deprecated">,
InGroup;
+def warn_drv_deprecated_arg_ofast : Warning<
+ "argument '-Ofast'
@@ -3298,7 +3298,18 @@ static void RenderFloatingPointOptions(const ToolChain
, const Driver ,
}
// Handle __FINITE_MATH_ONLY__ similarly.
- if (!HonorINFs && !HonorNaNs)
+ bool InfValues = true;
+ bool NanValues = true;
+ auto processArg = [&](const auto *Arg) {
+
@@ -1165,6 +1165,8 @@ static void InitializePredefinedMacros(const TargetInfo
,
DefineType("__WCHAR_TYPE__", TI.getWCharType(), Builder);
DefineType("__WINT_TYPE__", TI.getWIntType(), Builder);
DefineTypeSizeAndWidth("__SIG_ATOMIC", TI.getSigAtomicType(), TI, Builder);
AaronBallman wrote:
Duplicate of https://github.com/llvm/llvm-project/pull/97208 ... which I
reviewed.
https://github.com/llvm/llvm-project/pull/98945
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/98945
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -3298,7 +3298,18 @@ static void RenderFloatingPointOptions(const ToolChain
, const Driver ,
}
// Handle __FINITE_MATH_ONLY__ similarly.
- if (!HonorINFs && !HonorNaNs)
+ bool InfValues = true;
+ bool NanValues = true;
+ auto processArg = [&](const auto *Arg) {
+
https://github.com/AaronBallman deleted
https://github.com/llvm/llvm-project/pull/97342
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -3298,7 +3298,18 @@ static void RenderFloatingPointOptions(const ToolChain
, const Driver ,
}
// Handle __FINITE_MATH_ONLY__ similarly.
- if (!HonorINFs && !HonorNaNs)
+ bool InfValues = true;
+ bool NanValues = true;
+ auto processArg = [&](const auto *Arg) {
+
@@ -3298,7 +3298,18 @@ static void RenderFloatingPointOptions(const ToolChain
, const Driver ,
}
// Handle __FINITE_MATH_ONLY__ similarly.
- if (!HonorINFs && !HonorNaNs)
+ bool InfValues = true;
+ bool NanValues = true;
+ auto processArg = [&](const auto *Arg) {
+
AaronBallman wrote:
Given the amount of pain involved, I think this should be applied as a C++23
change rather than applied as a DR. I'd like to avoid adding a feature flag for
this if possible (I'd prefer warning-default-as-error instead, but that doesn't
seem particularly plausible here),
Author: Aaron Ballman
Date: 2024-07-15T12:13:49-04:00
New Revision: c2fab5a4c69c857061b06b9a826bf4730821e483
URL:
https://github.com/llvm/llvm-project/commit/c2fab5a4c69c857061b06b9a826bf4730821e483
DIFF:
https://github.com/llvm/llvm-project/commit/c2fab5a4c69c857061b06b9a826bf4730821e483.diff
@@ -347,6 +355,8 @@ class ComplexExprEmitter
#define HANDLEBINOP(OP)
\
ComplexPairTy VisitBin##OP(const BinaryOperator *E) {
\
QualType promotionTy = getPromotionType(
@@ -328,12 +328,20 @@ class ComplexExprEmitter
}
}
- QualType getPromotionType(QualType Ty, bool IsDivOpCode = false) {
+ QualType getPromotionType(FPOptionsOverride Features, QualType Ty,
+bool IsDivOpCode = false) {
if (auto *CT =
https://github.com/AaronBallman commented:
Thank you for working on this!
https://github.com/llvm/llvm-project/pull/98736
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -442,6 +442,9 @@ def warn_drv_deprecated_arg : Warning<
def warn_drv_deprecated_arg_no_relaxed_template_template_args : Warning<
"argument '-fno-relaxed-template-template-args' is deprecated">,
InGroup;
+def warn_drv_deprecated_arg_ofast : Warning<
+ "argument '-Ofast'
@@ -931,7 +931,8 @@ def O : Joined<["-"], "O">, Group,
def O_flag : Flag<["-"], "O">, Visibility<[ClangOption, CC1Option, FC1Option]>,
Alias, AliasArgs<["1"]>;
def Ofast : Joined<["-"], "Ofast">, Group,
- Visibility<[ClangOption, CC1Option, FlangOption]>;
+
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/98736
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -34,8 +34,8 @@ void LangOptions::resetNonModularOptions() {
// invocations that cannot be round-tripped to arguments.
// FIXME: we should derive this automatically from ImpliedBy in tablegen.
AllowFPReassoc = UnsafeFPMath;
- NoHonorNaNs = FiniteMathOnly;
-
@@ -0,0 +1,45 @@
+// RUN: %clang_cc1 %s -verify -fno-builtin -Werror=comment -Wno-error=abi
-Wfatal-errors=assume -Wno-fatal-errors=assume
+
+#define diagnose_if(...) __attribute__((diagnose_if(__VA_ARGS__)))
+
+template
+void diagnose_if_wcomma() diagnose_if(b, "oh no",
AaronBallman wrote:
> @AaronBallman was there anything else that needed to be done? Just did a
> merge because ReleaseNotes was edited but this should be fine
Nope, this is approved to land.
https://github.com/llvm/llvm-project/pull/92767
___
Author: Aaron Ballman
Date: 2024-07-15T09:31:14-04:00
New Revision: bd04ac0694cc9fb3c43a4acb2f7cd1db08eba673
URL:
https://github.com/llvm/llvm-project/commit/bd04ac0694cc9fb3c43a4acb2f7cd1db08eba673
DIFF:
https://github.com/llvm/llvm-project/commit/bd04ac0694cc9fb3c43a4acb2f7cd1db08eba673.diff
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/98489
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/98489
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
> I'm not sure I understand what happened here, since `_Alignas` did work
> properly before this change, right? How/why are `_Alignas` and `alignas`
> acting differently from eachother in C23 mode?
`_Alignas` on a field used to work properly before
AaronBallman wrote:
> @AaronBallman could you please review?
>
> I've fixed at least the LLDB tests. There was an actual bug in function
> parameters construction that was revealed by the invariant check.
>
> However, I can't run the whole LLDB suite. Even among the reported failing
> tests,
AaronBallman wrote:
Thank you for letting me know, I've pushed a fix for that.
Curiously, it seems `_Alignof` on an expression always returns the *preferred*
alignment and not the actual alignment. This is consistent with GCC, even if
it's a bit surprising: https://godbolt.org/z/nvKx98ff9
Author: Aaron Ballman
Date: 2024-07-15T09:03:30-04:00
New Revision: 1af3a89a4b384cbc5a6b111a0f7756085de818cd
URL:
https://github.com/llvm/llvm-project/commit/1af3a89a4b384cbc5a6b111a0f7756085de818cd
DIFF:
https://github.com/llvm/llvm-project/commit/1af3a89a4b384cbc5a6b111a0f7756085de818cd.diff
AaronBallman wrote:
> This started to cause
>
> ```
> $ cat test.c
> #include
> void f(void) {
> char a[strlen("x")];
> (void) a;
> }
> ```
>
> ```
> $ clang -Wall -fsyntax-only test.c
> test.c:3:12: warning: variable length array folded to constant array as an
> extension
AaronBallman wrote:
Just making sure that this didn't fall off your radar; it seems like a good fix
for us to get into Clang 19 before the branch, if possible.
https://github.com/llvm/llvm-project/pull/92767
___
cfe-commits mailing list
AaronBallman wrote:
> @budimirarandjelovicsyrmia Any updates? Should we revert the patch?
I already reverted in 9d1017204a253782a82d1b7d16c59eea3f811a11 so the bots have
been slowly getting back to green
https://github.com/llvm/llvm-project/pull/70024
https://github.com/AaronBallman approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/97894
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Aaron Ballman
Date: 2024-07-12T10:50:48-04:00
New Revision: ac2426e08e6f7c1eb97725f1d6cc35a8a6ddc5ef
URL:
https://github.com/llvm/llvm-project/commit/ac2426e08e6f7c1eb97725f1d6cc35a8a6ddc5ef
DIFF:
https://github.com/llvm/llvm-project/commit/ac2426e08e6f7c1eb97725f1d6cc35a8a6ddc5ef.diff
https://github.com/AaronBallman approved this pull request.
LGTM -- @cor3ntin, are you happy with the changes as well?
https://github.com/llvm/llvm-project/pull/89078
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
@@ -233,6 +233,7 @@ ENUM_CODEGENOPT(StructReturnConvention,
StructReturnConventionKind, 2, SRCK_Defa
CODEGENOPT(RelaxAll , 1, 0) ///< Relax all machine code instructions.
CODEGENOPT(RelaxedAliasing , 1, 0) ///< Set when -fno-strict-aliasing is
enabled.
https://github.com/AaronBallman approved this pull request.
LGTM aside from a minor code formatting suggestion.
https://github.com/llvm/llvm-project/pull/76612
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/76612
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/97210
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
> It's a bit weird to have an extension warning given we seem to not support u8
> in older language modes at all https://www.godbolt.org/z/1KrqGeT1q
>
> I think we should support the extension before in addition of having a
> warning for it @AaronBallman
It's not an
https://github.com/AaronBallman approved this pull request.
Changes LGTM but please be sure to add a release note when landing so users
know about the improvement.
https://github.com/llvm/llvm-project/pull/97424
___
cfe-commits mailing list
AaronBallman wrote:
> > Do you have an idea as to why the type location is invalid in the first
> > place?
>
> Looking at the new test, my guess is that `auto` remains undeduced, so it has
> nowhere to point out to.
Even when it's undeduced, we should still have a source location for it
https://github.com/AaronBallman commented:
Do you have an idea as to why the type location is invalid in the first place?
https://github.com/llvm/llvm-project/pull/98622
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
AaronBallman wrote:
There are multiple distinct issues that were caught:
build failure -- https://lab.llvm.org/buildbot/#/builders/72/builds/1123
sanitizer failure -- https://lab.llvm.org/buildbot/#/builders/164/builds/920
different failure from above --
@@ -860,9 +861,15 @@ bool Preprocessor::HandleIdentifier(Token ) {
ModuleImportLoc = Identifier.getLocation();
NamedModuleImportPath.clear();
IsAtImport = true;
-ModuleImportExpectsIdentifier = true;
CurLexerCallback = CLK_LexAfterModuleImport;
}
+
+
https://github.com/AaronBallman commented:
The changes generally LGTM but I'd love to hear from @ChuanqiXu9 as well.
https://github.com/llvm/llvm-project/pull/90574
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
@@ -905,6 +912,7 @@ void Preprocessor::Lex(Token ) {
// This token is injected to represent the translation of '#include "a.h"'
// into "import a.h;". Mimic the notional ';'.
case tok::annot_module_include:
+case tok::annot_repl_input_end:
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/90574
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman approved this pull request.
Presuming precommit CI comes back without surprises, this LGTM!
https://github.com/llvm/llvm-project/pull/95969
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/98146
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
> Perhaps also update
>
> https://github.com/llvm/llvm-project/blob/345861b186645f82c0b812427fdafe6ebd62a058/clang/www/c_status.html#L1283-L1285
Oh what the heck, I thought I already did that! :-D But yes, I'll update that
when landing, thank you!
AaronBallman wrote:
> The android NDK code is wrong, but this no longer compiles (even with
> -Wno-error).
Well that's unfortunate! Thank you for letting us know.
@alanzhao1 do you think it's reasonable for the workaround to only apply to
code in system headers, or does the NDK get included
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/98617
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/98497
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/98525
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,65 @@
+// RUN: %clang_cc1 -std=c2y %s -verify -Wno-gnu-alignof-expression
+
+/* WG14 N3244: Partial
+ * Slay Some Earthly Demons I
+ *
+ * NB: the committee adopted:
+ * Annex J Item 21 (including additional change) -- no, we lack explicit
documentation
+ * Annex
AaronBallman wrote:
> Thank you very much for fixing that:)
Happy to help, thank you for your contribution!
https://github.com/llvm/llvm-project/pull/98016
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
AaronBallman wrote:
> > Yup, that resolved the issue:
> > https://lab.llvm.org/buildbot/#/builders/144/builds/2082 -- not certain why
> > that builder has a different default value for `-std` though. Clang
> > defaults to C17, but that builder seems to be defaulting to C99.
>
> This bot
AaronBallman wrote:
Precommit CI failure on Windows appears to be unrelated:
```
_bk;t=1720718143606 TEST 'lld :: ELF/basic-sparcv9.s'
FAILED
_bk;t=1720718143606Exit Code: 1
_bk;t=1720718143606
_bk;t=1720718143606Command Output (stdout):
@@ -0,0 +1,2 @@
+if not config.root.clang_enable_cir:
+clang.unsupported = True
AaronBallman wrote:
It looks like this is causing precommit CI failures:
```
llvm-lit.py: C:\ws\src\llvm\utils\lit\lit\llvm\config.py:57: note: using lit
tools: C:\Program
https://github.com/AaronBallman approved this pull request.
LGTM, thank you!
https://github.com/llvm/llvm-project/pull/70024
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
Yup, that resolved the issue:
https://lab.llvm.org/buildbot/#/builders/144/builds/2082 -- not certain why
that builder has a different default value for `-std` though. Clang defaults to
C17, but that builder seems to be defaulting to C99.
AaronBallman wrote:
I've relanded the changes with a fix here in commit
0171e23647d58f65c1cddbc22e16fda2bafa6e85, hopefully that sticks!
https://github.com/llvm/llvm-project/pull/98016
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
Author: Constantin Kronbichler
Date: 2024-07-11T13:26:24-04:00
New Revision: 0171e23647d58f65c1cddbc22e16fda2bafa6e85
URL:
https://github.com/llvm/llvm-project/commit/0171e23647d58f65c1cddbc22e16fda2bafa6e85
DIFF:
AaronBallman wrote:
I think adding `-std=c11` to the `RUN` line should help; it at least removes
the "is a C11 extension" diagnostics. (I guess this builder isn't defaulting to
C17 for some reason?)
https://github.com/llvm/llvm-project/pull/98016
AaronBallman wrote:
Okay, the Windows issue seems to have gone away with a full rebuild, which
makes *way* more sense to me. :-) So I think it's just the
`llvm-clang-x86_64-sie-ubuntu-fast` issue that needs to be resolved.
https://github.com/llvm/llvm-project/pull/98016
AaronBallman wrote:
I've reverted the changes in 9f283bfb9e66d57fefeb3a28318ec40081fa9a24 because
of the bot breakage. Oddly, I am seeing a different failure on Windows locally:
```
FAIL: Clang :: Sema/undefined-internal-basic.c (1 of 1)
TEST 'Clang ::
Author: Aaron Ballman
Date: 2024-07-11T13:07:06-04:00
New Revision: 9f283bfb9e66d57fefeb3a28318ec40081fa9a24
URL:
https://github.com/llvm/llvm-project/commit/9f283bfb9e66d57fefeb3a28318ec40081fa9a24
DIFF:
https://github.com/llvm/llvm-project/commit/9f283bfb9e66d57fefeb3a28318ec40081fa9a24.diff
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/98016
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
I filed https://github.com/llvm/llvm-project/issues/98504 to track the
remaining issue.
https://github.com/llvm/llvm-project/pull/98016
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/AaronBallman approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/98016
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
101 - 200 of 5460 matches
Mail list logo
