No problem, thanks for the response!
Phab emails are apparently about 30 minutes delayed for me apparently, which is
unfortunate or I would have had the fix ready before your revert š
Let me know if you run into any more issues, but Iām 99% sure I got it right
this time.
Thanks
-Erich
From: S
Right, the intent was to get this to match Microsoftās behavior better while
still making sense on other platforms. IIRC this was in order to fix a codegen
bug due to type mismatches, though I donāt completely remember (as it was
nearly a year ago).
From: James Y Knight
Sent: Wednesday, Febru
Thanks! On the way home for the evening, so I'll fix it up tomorrow.
On Oct 10, 2019 2:34 PM, Nico Weber via Phabricator
wrote:
thakis added a comment.
Since you just left IRC, I reverted this in 374456 for now.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D68824/new/
https://reviews
Yep, I agree. I tend to figure if I can get it done in ~1-2 hours, that I
could just fix it. Note that this was 1:30 š
From: Nico Weber
Sent: Wednesday, October 2, 2019 4:37 PM
To: Keane, Erich
Cc: cfe-commits
Subject: Re: r373247 - Teach CallGraph to look into Generic Lambdas.
Thanks!
If
Should be fixe din r373259
From: Nico Weber
Sent: Monday, September 30, 2019 12:50 PM
To: Keane, Erich
Cc: cfe-commits
Subject: Re: r373247 - Teach CallGraph to look into Generic Lambdas.
This broke a few clangd unit tests:
http://lab.llvm.org:8011/builders/clang-ppc64be-linux/builds/38857/st
I saw that, thanks! Iām looking into them now. I can revert if it takes me
too long.
From: Nico Weber
Sent: Monday, September 30, 2019 12:50 PM
To: Keane, Erich
Cc: cfe-commits
Subject: Re: r373247 - Teach CallGraph to look into Generic Lambdas.
This broke a few clangd unit tests:
http://l
Ah, sorry-
It broke the sphinx build bot, and the author was home for the evening and is
going to get to it during the day today.
From: Richard Smith
Sent: Tuesday, September 17, 2019 8:10 PM
To: Keane, Erich
Cc: cfe-commits
Subject: Re: r372185 - Revert "Create UsersManual section entitled 'C
Yeah, sorry about that. I fixed it in 369284.
From: Leonard Chan [mailto:leonardc...@google.com]
Sent: Monday, August 19, 2019 11:33 AM
To: Keane, Erich
Cc: cfe-commits cfe
Subject: Re: r369281 - Implement P1668R1
Not sure if this was caught by upstream bots already, but we're seeing a
failin
Ah! Thanks. Iāll fix it now.
From: Richard Smith [mailto:rich...@metafoo.co.uk]
Sent: Thursday, July 25, 2019 9:26 AM
To: Keane, Erich
Cc: cfe-commits
Subject: Re: r367027 - Implement P1771
On Thu, 25 Jul 2019, 08:10 Erich Keane via cfe-commits,
mailto:cfe-commits@lists.llvm.org>> wrote:
Aut
To Update: Nico and I discussed this on IRC and believe the best way to fix
this is to simply suppress this when it comes from a macro-expansion in a
system header ala r221172 (or r220992).
I intend to work on that fix next after my current (fairly short) fix.
Thanks!
-Erich
From: Nico Weber [
It IS an attribute that works on Linux as well (about Ā½ way down this page:
https://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/Function-Attributes.html), though
used rarely (at least in C++ code) as far as I understand.
The fact that a mistake like this is in the ATL headers is frustrating, but Iām
n
Presumably the right choice for you on this one is to separate the diagnostic
into a new group. Copying Aaron since he might have an idea of an existing
group, otherwise Iāll push a commit to put it in a new one.
Thanks for the report!
-Erich
From: Nico Weber [mailto:tha...@chromium.org]
Sent:
Youāre right, GCC has these in a header as a #define. This patch didnāt
interfere with that and was causing some other failures for us as a result. If
its OK, Iād prefer to revert ONLY the enable on Linux mode at the moment, the
long-int fix WAS valuable as well.
From: James Y Knight [mailto:
Thanks for the heads up! Looking now.
-Original Message-
From: Peter Smith [mailto:peter.sm...@linaro.org]
Sent: Friday, January 18, 2019 2:33 AM
To: Keane, Erich
Cc: cfe-commits cfe
Subject: Re: r351495 - Make integral-o-pointer conversions in SFINAE illegal.
Hello Erich,
The test a
co.uk>> wrote:
I have a patch I put together a while back as an attempt to fix a different
bug, that creates a new CastKind for this operation (didn't work out there, but
it might do so here). I'll dig it out and mail it to you in case it's a useful
starting point.
On Fr
Thank you for that!
From: Shoaib Meenai [mailto:smee...@fb.com]
Sent: Tuesday, January 8, 2019 4:48 PM
To: David Majnemer
Cc: Keane, Erich ; cfe-commits@lists.llvm.org; Martin
Storsjo
Subject: Re: r350643 - Limit COFF 'common' emission to <=32 alignment types.
I sent out https://reviews.llvm.o
That seems like it would make sense to me. COFF isnāt my expertise, so
hopefully David/Martin/others can let me know if this is subtly broken
elsewhere.
From: Shoaib Meenai [mailto:smee...@fb.com]
Sent: Tuesday, January 8, 2019 1:09 PM
To: Keane, Erich ; cfe-commits@lists.llvm.org; David
Majne
Yep, exactly. I looked, and isKnownWindowsMSVCEnvironment checks for OS=Win32,
which I believe would be different for other architectures.
From: Shoaib Meenai [mailto:smee...@fb.com]
Sent: Tuesday, January 8, 2019 12:41 PM
To: Keane, Erich ; cfe-commits@lists.llvm.org; David
Majnemer
Subject:
to:rich...@metafoo.co.uk>> wrote:
I have a patch I put together a while back as an attempt to fix a different
bug, that creates a new CastKind for this operation (didn't work out there, but
it might do so here). I'll dig it out and mail it to you in case it's a useful
starti
Reverted in r349206.
From: Richard Smith [mailto:rich...@metafoo.co.uk]
Sent: Friday, December 14, 2018 2:41 PM
To: Keane, Erich
Cc: cfe-commits
Subject: Re: r349201 - Add extension to always default-initialize nullptr_t.
Sorry, I was late with my review comment. I think this is the wrong way t
Alright, no problem. Iāll push a revert in a few minutes and give it another
try. Perhaps I can suppress the creation of a CK_LValueToRValue in the case
where itās a read from nullptr_t
From: Richard Smith [mailto:rich...@metafoo.co.uk]
Sent: Friday, December 14, 2018 2:41 PM
To: Keane, Erich
I'd be tentative to commit to any stability guarantees, particularly as the AST
tends to change reasonably often. That said, I can see the value of this.
Additionally, it would be preferential I suspect if we could make the standard
ast-dump just another (albeit default) "format" in whatever pl
Coolbeans, will do! Thanks for the review.
-Erich
From: Richard Smith [mailto:rich...@metafoo.co.uk]
Sent: Monday, November 12, 2018 11:59 AM
To: Keane, Erich
Cc: cfe-commits
Subject: Re: r346677 - Implement P1094R2 (nested inline namespaces)
On Mon, 12 Nov 2018 at 09:22, Erich Keane via cfe-
From: David Blaikie [mailto:dblai...@gmail.com]
Sent: Monday, October 29, 2018 11:41 AM
To: Keane, Erich
Cc: Eric Christopher ; cfe-commits@lists.llvm.org
Subject: Re: r344957 - Give Multiversion-inline functions linkonce linkage
On Mon, Oct 29, 2018 at 11:30 AM Keane, Erich
mailto:erich.ke..
GCC actually doesnāt support function multiversioning in C mode, so this fix is
part of our extension to support C with multiversioning. I perhaps wonder if
this is part of the reason GCC only supports it in C++ mode...
From: David Blaikie [mailto:dblai...@gmail.com]
Sent: Monday, October 29, 2
AH! Thanks! I was just messing around on Godbolt to try to figure out what was
going on.
From: Richard Smith [mailto:rich...@metafoo.co.uk]
Sent: Thursday, August 9, 2018 2:16 PM
To: Keane, Erich
Cc: cfe-commits
Subject: Re: r339387 - Revert -r339382, which apparently breaks the Windows
build
Good grief... I even made a note to remove this 'TODO' on my whiteboard!
I discussed the name with AaronBallman who preferred ParsedAttr over
ParsedAttribute (since ParsedAttributes is also a type).
Fixed in r339039.
-Original Message-
From: meiners...@googlemail.com [mailto:meiners...@
Hi, sorry for the delayed response, I only just got back into the office. I've
added the author of the patch to this email chain.
-Original Message-
From: Abramo Bagnara [mailto:abramo.bagn...@bugseng.com]
Sent: Sunday, August 5, 2018 5:03 AM
To: Keane, Erich ; cfe-commits@lists.llvm.or
I suspect you're right about that. Hopefully it would be easy enough.
Unfortunately, SourceLocation doesn't have an operator<, which kind of stinks.
I suspect that it'll be a non-trivial thing to do, since it is actually
possible to have attributes added with empty source-locations in some cas
> As a possible idea (that may or may not work): the Attr object itself has a
> SourceRange on it; perhaps a solution is to keep the > attributes in sorted
> order within DeclBase::addAttr() based on the SourceRanges passed in?
Interestingly, I think I came up with that idea in a comment on D502
Thanks for the heads up! I reproāed both in Godbolt, and saw that clang
suggests wrapping in a void-cast, so Iāve done that.
From: Nico Weber [mailto:tha...@chromium.org]
Sent: Friday, August 3, 2018 6:16 AM
To: Keane, Erich
Cc: cfe-commits
Subject: Re: r338884 - [NFC] Silence unused variable
Hmmā¦ I thought this was a pretty clever one. Again, that didnāt show up in my
older GCC :/
Any thoughts on how I can silence this AND the other warning?
From: Nico Weber [mailto:tha...@chromium.org]
Sent: Friday, August 3, 2018 6:16 AM
To: Keane, Erich
Cc: cfe-commits
Subject: Re: r338884 -
Thanks Vlad for the removal! This warning didnāt show up in my environment
when committing this, I really need get a newer GCC :/
I suspect the patch author should extract that assert to the bitfield area with
the rest.
From: David Jones [mailto:d...@google.com]
Sent: Wednesday, August 1, 201
Uggā¦ I did not. Seemingly my svn-property cleaning script isnāt working for
some reason. If it hasnāt been done yet, Iāll clear the properties now.
From: Nico Weber [mailto:tha...@chromium.org]
Sent: Wednesday, July 18, 2018 5:21 AM
To: Keane, Erich
Cc: cfe-commits
Subject: Re: r336380 - Add
Sorry everyone, I didn't police my subversion directory correctly. I noticed
when I got the email that the 'commit' list was too large! Reverted in 336727.
-Original Message-
From: Erich Keane via cfe-commits [mailto:cfe-commits@lists.llvm.org]
Sent: Tuesday, July 10, 2018 1:47 PM
To:
Fixed in R336364. Thank you very much for the heads up!
From: Evgenii Stepanov [mailto:eugeni.stepa...@gmail.com]
Sent: Tuesday, July 3, 2018 12:59 PM
To: Keane, Erich
Cc: cfe-commits
Subject: Re: r334650 - Implement constexpr __builtin_*_overflow
Hi,
with this change, the following compiles
Unfortunately I'm not sure of a good way to validate this. The only way I was
able to even discover this was with manual instrumentation of D48788. There is
a future opportunity to better instrument the source to find these things in
the future that'll catch more issues like this one however.
Yikes! Thanks for the heads up! Iāll start looking into this.
Thanks for letting me know.
From: Evgenii Stepanov [mailto:eugeni.stepa...@gmail.com]
Sent: Tuesday, July 3, 2018 12:59 PM
To: Keane, Erich
Cc: cfe-commits
Subject: Re: r334650 - Implement constexpr __builtin_*_overflow
Hi,
with
Hi Richard-
Thanks for the feedback. Iām copying the author of this patch on this email
for further discussion if you care to.
Weāll have her take another look at it. Thanks for the revert.
(https://github.com/llvm-mirror/clang/commit/746b78de7812bc785fbb5207b788348040b23fa7).
-Erich
From: R
I donāt believe the member initialization for bitfields (of which all the ā0ā
values are) happened until C++17, right? I could definitely member initialize
the two enum fields though.
From: David Blaikie [mailto:dblai...@gmail.com]
Sent: Monday, May 7, 2018 12:03 PM
To: Keane, Erich
Cc: cfe-co
Thanks for your comments Richard, Iāve added the author to this email so that
she can take a look.
From: Richard Smith [mailto:rich...@metafoo.co.uk]
Sent: Tuesday, February 13, 2018 5:39 PM
To: Keane, Erich
Cc: cfe-commits
Subject: Re: r325081 - Implement function attribute artificial
On 13 F
It did not, I held it until just after the branch was made.
-Original Message-
From: hwennb...@google.com [mailto:hwennb...@google.com] On Behalf Of Hans
Wennborg
Sent: Wednesday, January 17, 2018 4:47 AM
To: reviews+d41837+public+36225483e5851...@reviews.llvm.org
Cc: Keane, Erich ; Richa
Fixed in 320493. Thanks for catching that.
From: Richard Smith [mailto:rich...@metafoo.co.uk]
Sent: Tuesday, December 12, 2017 8:07 AM
To: Keane, Erich
Cc: cfe-commits
Subject: Re: r320489 - Fix ICE when __has_unqiue_object_representations called
with invalid decl
On 12 Dec 2017 16:02, "Erich
Gah, no it wasnāt. Iāll revert that now.
From: Richard Smith [mailto:rich...@metafoo.co.uk]
Sent: Tuesday, December 12, 2017 8:07 AM
To: Keane, Erich
Cc: cfe-commits
Subject: Re: r320489 - Fix ICE when __has_unqiue_object_representations called
with invalid decl
On 12 Dec 2017 16:02, "Erich K
Thanks for the review Richard. Would you like me to revert, or can I just make
these changes in a new patch?
From: Richard Smith [mailto:rich...@metafoo.co.uk]
Sent: Thursday, October 26, 2017 9:50 AM
To: Keane, Erich
Cc: cfe-commits
Subject: Re: r316518 - mplement __has_unique_object_represe
Yikes! Thanks for pointing this out, fixing it now.
From: David Majnemer [mailto:david.majne...@gmail.com]
Sent: Tuesday, October 24, 2017 2:55 PM
To: Keane, Erich
Cc: cfe-commits
Subject: Re: r316518 - mplement __has_unique_object_representations
On Tue, Oct 24, 2017 at 2:31 PM, Erich Keane
Ah, thanks for letting me know! Iāll do that now.
From: tha...@google.com [mailto:tha...@google.com] On Behalf Of Nico Weber
Sent: Tuesday, October 24, 2017 8:59 AM
To: Keane, Erich
Cc: cfe-commits
Subject: Re: r316447 - Fix spelling in comment, field is isMsStruct, not Strust
This is fine, but
Elizabeth gave me a patch, submitted it with a test in r314939
From: Andrews, Elizabeth
Sent: Wednesday, October 4, 2017 1:54 PM
To: Friedman, Eli ; Keane, Erich
; Nico Weber
Cc: cfe-commits
Subject: RE: r314262 - Emit section information for extern variables.
Alright. Will do. Thanks!
From:
Ah, cool! I didnāt realize that, and that is actually exactly what Elizabeth
is looking into now.
Elizabeth, if you send me a diff, Iāll commit it as review-after-commit if Eli
is alright with this. It should be something like changing:
+ if (VD->isThisDeclarationADefinition() != VarDecl:
Elizabeth pointed out to me separately that the āisDeclarationADefinitionā
check ought to have prevented this from happening, so sheās taking a look I
believe. The usage proposal I mentioned below might be handy as well.
My fear is that this is a case where the existing functionality in Chromiu
I saw thatā¦ I donāt see where it prevents the same change from being made in
link.h.
As I mentioned, there is a solution to make this Warning less aggressive (in
the lib/Sema/SemaDecl.cpp changes, add a condition that Old->isUsed() before
the warning. Iām wondering if that solves your issue.
Iāve added Elizabeth, who is the original patch author. Hopefully she can help
out here. Additionally, Eli did the original review, so hopefully he can chime
in as well.
I believe the necessity for this warning came out of the discussion on fixing
the section behavior. The issue here is that
BTW: The guy who told me about this issue ALSO discovered a different issue
that that I didn't solve due to his reproducer not contining the whole
testcase. I've got a patch to fix all of it in his hands right now, so I'll
submit this fix with it together.
-Erich
-Original Message-
Fr
Ah! Sorry, I didn't realize that isExternCXXContext actually searched the
entire search-set! Followup patch coming Thanks for the heads up!
-Original Message-
From: Friedman, Eli [mailto:efrie...@codeaurora.org]
Sent: Tuesday, September 26, 2017 12:06 PM
To: Keane, Erich ; cfe-commits@
Fixed in 313909.
-Original Message-
From: Friedman, Eli [mailto:efrie...@codeaurora.org]
Sent: Thursday, September 21, 2017 1:14 PM
To: Keane, Erich ; cfe-commits@lists.llvm.org
Subject: Re: r313907 - Suppress Wsign-conversion for enums with matching
underlying type
On 9/21/2017 12:58 P
Ugg... good catch, thanks.
-Original Message-
From: Friedman, Eli [mailto:efrie...@codeaurora.org]
Sent: Thursday, September 21, 2017 1:14 PM
To: Keane, Erich ; cfe-commits@lists.llvm.org
Subject: Re: r313907 - Suppress Wsign-conversion for enums with matching
underlying type
On 9/21/20
Thereās an existing test in r311683. Iād initially implemented handling ā\r\nā
as well as ā\n\rā, but Reid had suggested that I simply handle the former. Iād
inadvertently contributed the previous revision. I noticed this morning that
Iād done so, so I corrected my commit.
From: tha...@googl
Oops, totally forgot this got approved āŗ Thanks for the reminder!
From: Eric Christopher [mailto:echri...@gmail.com]
Sent: Friday, September 1, 2017 12:40 PM
To: reviews+d36707+public+aa8b48c258736...@reviews.llvm.org; Keane, Erich
; llvm-...@redking.me.uk; craig.top...@gmail.com
Cc: cfe-commits
Alright, final update. Thanks to some fantastic help on #llvm, I believe this
is fixed.
Stephen: You may have to do some shenanigans to fix your local stuff, but the
monorepo and another repo both seem to work. Sorry for this everyone :/
From: Stephen Hines [mailto:srhi...@google.com]
Sent: T
1 more dataset, Craig has the git mirror working right, but with the public
mirrorā¦
From: Stephen Hines [mailto:srhi...@google.com]
Sent: Thursday, August 24, 2017 3:18 PM
To: Keane, Erich
Cc: cfe-commits
Subject: Re: r311683 - [Preprocessor] Correct internal token parsing of newline
character
Hi Stephen-
Iām digging through this, and it seems odd. SVN seems to store it with the
CRLF line endings. The Git mirror for some reason is not paying attention to
the svn file attribute. However, the .gitattribute file seems to convert it to
the CRLF endings (as it should be), but it seems t
Can you better clarify what went wrong? I included a ā.gitattriutesā that
matches only the new test that is supposed to keep it as CLRF
From: Stephen Hines [mailto:srhi...@google.com]
Sent: Thursday, August 24, 2017 3:18 PM
To: Keane, Erich
Cc: cfe-commits
Subject: Re: r311683 - [Preprocessor
Hi Richard:
Iām not sure if you noticed this, but my coworker did submit a review here:
https://reviews.llvm.org/D34671 with the changes you suggested.
Thanks,
Erich
From: meta...@gmail.com [mailto:meta...@gmail.com] On Behalf Of Richard Smith
Sent: Monday, June 26, 2017 2:25 PM
To: Keane, Erich
Sorry Richard, I thought I gave you enough time before committing this for Jen.
Adding her so she can respond to your comments and fix these.
Thanks,
Erich
From: meta...@gmail.com [mailto:meta...@gmail.com] On Behalf Of Richard Smith
Sent: Monday, June 26, 2017 2:25 PM
To: Keane, Erich
Cc: cfe-
Thanks for the heads up! Fixed in 305491. Turns out a function that
AllocateMacroInfo returns a pointer, but the PP still owns it.
MacroArgs::create returns a pointer, and expects the user to delete it. I
added a unique_ptr with a custom delete to call the macro-args 'destroy'
function.
-
Ah, rightā¦ This function mallocs, and is usually tossed in the Preprocessor
Cache, but Iām doing an end-run around that this time. Iāll see if it is
better to put it into the PP Cache, or just call āfreeā on it.
Thanks!
-Erich
From: Kostya Serebryany [mailto:k...@google.com]
Sent: Thursday, Ju
Should be fixed as of here: https://reviews.llvm.org/rL305128 . Curious that
none of the other tests found this, but thankfully UBSan did!
Committed as no-wait due to the breakage and not wanting to leave it broken
over the weekend.
-Original Message-
From: Evgenii Stepanov [mailto:
Thanks, I didn't notice that one. Looking into it.
-Erich
-Original Message-
From: Evgenii Stepanov [mailto:eugeni.stepa...@gmail.com]
Sent: Friday, June 9, 2017 3:00 PM
To: Keane, Erich
Cc: cfe-commits
Subject: Re: r305087 - support operator keywords used in Windows SDK
Hi,
http://
No problem, I definitely think it was the right choice.
A change that contains all of what Melanieās original patch did, plus the
Header changes (plus the clang-tidy fixes that came out of this) would be
acceptable?
Also, I believe sheās working on the warning as well. We were discussing it,
Patch and Buildbot fixes all reverted as of ār303882. Sorry for the thrash.
From: tha...@google.com [mailto:tha...@google.com] On Behalf Of Nico Weber
Sent: Thursday, May 25, 2017 9:16 AM
To: Blower, Melanie
Cc: rnk ; Keane, Erich ; cfe-commits
; Hans Wennborg
Subject: RE: r303798 - For Micros
How does chromium compiler in CL? It seems that it would have a similar
problem hereā¦
From: tha...@google.com [mailto:tha...@google.com] On Behalf Of Nico Weber
Sent: Thursday, May 25, 2017 9:16 AM
To: Blower, Melanie
Cc: rnk ; Keane, Erich ; cfe-commits
; Hans Wennborg
Subject: RE: r303798 -
Adding Melanie, the author of the patch.
From: tha...@google.com [mailto:tha...@google.com] On Behalf Of Nico Weber
Sent: Wednesday, May 24, 2017 12:43 PM
To: Keane, Erich
Cc: cfe-commits ; rnk
Subject: Re: r303798 - For Microsoft compatibility, set fno_operator_names
Reviewed here: https://rev
Ended up being simpler than I expected. I added -r298433 To fix this.
The issue is that the test had a conditional based on the "C" version, so I
explicitly added a test for C89 and C99, which the PS4 is apparently not
defaulting to.
Thanks!
-Erich
-Original Message-
From: Yung, D
I saw that, I was digging into it, then went to lunch. I'm hoping to push a
fix by EOD if I can.
Thanks for the heads up though!
-Original Message-
From: Yung, Douglas [mailto:douglas.y...@sony.com]
Sent: Tuesday, March 21, 2017 12:59 PM
To: Keane, Erich
Cc: cfe-commits
Subject: RE:
I don't see any .ll files for the tests. I see the directory
build/tools/clang/test/OpenMP/Output has a bunch of .script and .tmp(binary
files), but no obvious .ll files.
-Original Message-
From: Alexey Bataev [mailto:a.bat...@hotmail.com]
Sent: Monday, October 10, 2016 1:22 PM
To: Ke
This causes a massive number of openmp test failures (obviously), and I'm not
terribly comfortable with how OpenMP works. I can update the tests (and will),
but would like it if you could be extra diligent in confirming the correct
behavior for me.
Failing Tests (6):
Clang :: OpenMP/for_re
That does turn ArgType into a PointerType int*. However, line 301
(GenerateOpenMPCapturedStmtFunction) attempts to cast it to a reference type a
bit later, resulting in a SIGABRT there. Do I need to re-add the reference
there? Is removing the array type REALLY what we wish to do?
-Origin
I did. I changed line 236 to "ArgType =
getContext().getCanonicalParamType(ArgType);" (as I believe you were
suggesting), and the output was identical when doing dump on ArgType:
This:
LValueReferenceType 0xa451620 'int (&)[*]' variably_modified
`-VariableArrayType 0xa4515e0 'int [*]' vari
Ok, I dug into this deeper. ASTContext.cpp:2811 (getVariableArrayDecayedType)
intentionaly sets size to nullptr in this case for the purpose of turning it
into a [*] type. OpenMP.cpp:236
(CodeGenFunction::GenerateOpenMPCapturedStmtFunction) calls this to replace
variably modified type with th
Added Alexey to the list, heās the OMP Maintainer, so hopefully he knows better
āŗ
From: David Blaikie [mailto:dblai...@gmail.com]
Sent: Friday, October 7, 2016 11:51 AM
To: reviews+d25373+public+d8ec2a4bb41b1...@reviews.llvm.org; Keane, Erich
; cfe-commits@lists.llvm.org; david.majne...@gmail.co
I cannot personally right now, though I will dig into OpenMP implementation to
see how intentional that is. The size is seemingly determined by the OMP code
generation as far as I can tell.
From: David Blaikie [mailto:dblai...@gmail.com]
Sent: Friday, October 7, 2016 11:51 AM
To: reviews+d25373
Fixed in: r277206 after review in https://reviews.llvm.org/D22970
From: Keane, Erich
Sent: Friday, July 29, 2016 11:58 AM
To: 'Andrey Bokhanko' ; Mike Aizatsky
Cc: cfe-commits
Subject: RE: r277134 - [GCC] Support for __final specifier
Sure, looking into it now.
From: Andrey Bokhanko [mailto:
I don't have the ability to commit this, but if it is blocking someone in some
way (since the build verifier would otherwise be broken), someone committing it
before then would be much appreciated.
Thanks!
-Erich
-Original Message-
From: Andrey Bokhanko [mailto:andreybokha...@gmail.com]
Sure, looking into it now.
From: Andrey Bokhanko [mailto:andreybokha...@gmail.com]
Sent: Friday, July 29, 2016 11:57 AM
To: Mike Aizatsky ; Keane, Erich
Cc: cfe-commits
Subject: Re: r277134 - [GCC] Support for __final specifier
Mike,
Thanks for letting me know.
I committed a patch authored by E
gt;>
Cc: cfe-commits@lists.llvm.org<mailto:cfe-commits@lists.llvm.org>
Subject: Re: [ReviewRequest] [Sema/Parser] GCC Compatibility Patch: Support for
__final specifier
I'd rename VS_Alt_Final to VS_GNU_Final.
On Mon, Jul 25, 2016 at 2:24 PM, Keane, Erich via cfe-commits
mailto:cfe-
ema/Parser] GCC Compatibility Patch: Support for
__final specifier
I'd rename VS_Alt_Final to VS_GNU_Final.
On Mon, Jul 25, 2016 at 2:24 PM, Keane, Erich via cfe-commits
mailto:cfe-commits@lists.llvm.org>> wrote:
Hi all, my first potential-contribution, so I apologize if Iām submitting t
Compatibility Patch: Support for
__final specifier
I'd rename VS_Alt_Final to VS_GNU_Final.
On Mon, Jul 25, 2016 at 2:24 PM, Keane, Erich via cfe-commits
mailto:cfe-commits@lists.llvm.org>> wrote:
Hi all, my first potential-contribution, so I apologize if Iām submitting this
impr
Hi all, my first potential-contribution, so I apologize if I'm submitting this
improperly, I'm unfamiliar with the 'type' keys that you use in the topic, so
hopefully I have this right.
As reported in bug 28473, GCC supports 'final' functionality in pre-C++11 code
using the __final keyword. Cl
88 matches
Mail list logo
