Page MenuHomePhabricator

eandrews (Elizabeth Andrews)
User

Projects

User does not belong to any projects.

User Details

User Since
Jul 10 2017, 11:37 AM (289 w, 6 d)

Recent Activity

Thu, Jan 26

eandrews committed rGc10615e4a94f: [SYCL] Fix test to conform to SYCL2020 (authored by eandrews).
[SYCL] Fix test to conform to SYCL2020
Thu, Jan 26, 1:54 PM · Restricted Project, Restricted Project

Wed, Jan 25

eandrews added a comment to D141375: [SYCL][OpenMP] Fix compilation errors for unsupported __bf16 intrinsics.

Thanks for the reviews!

Wed, Jan 25, 12:49 PM · Restricted Project, Restricted Project
eandrews committed rGf81d529f8955: [Clang] Fix compilation errors for unsupported __bf16 intrinsics (authored by eandrews).
[Clang] Fix compilation errors for unsupported __bf16 intrinsics
Wed, Jan 25, 12:49 PM · Restricted Project, Restricted Project
eandrews closed D141375: [SYCL][OpenMP] Fix compilation errors for unsupported __bf16 intrinsics.
Wed, Jan 25, 12:49 PM · Restricted Project, Restricted Project

Wed, Jan 11

eandrews added a comment to D141375: [SYCL][OpenMP] Fix compilation errors for unsupported __bf16 intrinsics.

LGTM.
I expect this to be a common issue for all single-source offloading programming models (i.e. CUDA and HIP in addition to SYCL and OpenMP offload). Probably we can generalize the code patterns used in this patch for all of them.

Wed, Jan 11, 1:24 AM · Restricted Project, Restricted Project

Tue, Jan 10

eandrews requested review of D141375: [SYCL][OpenMP] Fix compilation errors for unsupported __bf16 intrinsics.
Tue, Jan 10, 4:56 AM · Restricted Project, Restricted Project

Dec 16 2022

eandrews added a comment to D124351: [Clang] Implement Change scope of lambda trailing-return-type.

I came across a strange error when capturing arguments in a lambda inside another lambda. I filed an issue here - https://github.com/llvm/llvm-project/issues/59549

Dec 16 2022, 5:04 AM · Restricted Project, Restricted Project

Nov 18 2022

eandrews updated subscribers of D138296: [clang] Avoid duplicating ProgramAddressSpace in TargetInfo. NFCI.

Functionally this looks ok to me. However I am not sure if CodeGenTypes is the 'right' place for this function to live, considering that other functions with similar functionality are in ASTContext - including overloads of getTargetAddressSpace( ). @erichkeane @aaron.ballman could you please take a look?

Nov 18 2022, 8:20 AM · Restricted Project, Restricted Project

Feb 7 2022

eandrews added a comment to D119045: Fix address space for function types with AS qualifier.

LGTM aside from some nits

Feb 7 2022, 12:56 PM · Restricted Project
eandrews committed rGed5b42b74188: Fix address space for function pointers with qualifier (authored by eandrews).
Fix address space for function pointers with qualifier
Feb 7 2022, 12:54 PM
eandrews closed D119045: Fix address space for function types with AS qualifier.
Feb 7 2022, 12:54 PM · Restricted Project

Feb 4 2022

eandrews requested review of D119045: Fix address space for function types with AS qualifier.
Feb 4 2022, 4:07 PM · Restricted Project

Jan 13 2022

eandrews committed rG4eaf5846d0e7: [clang] Fix function pointer address space (authored by eandrews).
[clang] Fix function pointer address space
Jan 13 2022, 8:12 AM
eandrews closed D111566: [SYCL] Fix function pointer address space.
Jan 13 2022, 8:12 AM · Restricted Project, Restricted Project

Jan 12 2022

eandrews added inline comments to D111566: [SYCL] Fix function pointer address space.
Jan 12 2022, 3:29 PM · Restricted Project, Restricted Project
eandrews updated the diff for D111566: [SYCL] Fix function pointer address space.

Implemented review comments

  • Remove unnecessary set method and set default value during construction instead
  • Changed default address space for function pointer for avr target to 1.
Jan 12 2022, 3:13 PM · Restricted Project, Restricted Project

Jan 11 2022

eandrews added inline comments to D111566: [SYCL] Fix function pointer address space.
Jan 11 2022, 2:45 PM · Restricted Project, Restricted Project
eandrews updated the diff for D111566: [SYCL] Fix function pointer address space.

Add program address space to TargetInfo. Targets with non-default address space for functions should explicitly set value.

Jan 11 2022, 2:34 PM · Restricted Project, Restricted Project
eandrews added inline comments to D111566: [SYCL] Fix function pointer address space.
Jan 11 2022, 6:57 AM · Restricted Project, Restricted Project

Jan 10 2022

eandrews updated the diff for D111566: [SYCL] Fix function pointer address space.

Implement review comments - add a comment + remove unnecessary code

Jan 10 2022, 5:11 PM · Restricted Project, Restricted Project
eandrews added inline comments to D111566: [SYCL] Fix function pointer address space.
Jan 10 2022, 4:38 PM · Restricted Project, Restricted Project
eandrews added a comment to D111566: [SYCL] Fix function pointer address space.

Block pointers are actually data pointers and should stay in the generic address space if they don't have an address space qualifier. That might require new logic.

Jan 10 2022, 1:03 PM · Restricted Project, Restricted Project
eandrews updated the diff for D111566: [SYCL] Fix function pointer address space.

Implemented review comment to move logic into function (getTargetAddressSpace) as opposed to call site.

Jan 10 2022, 1:00 PM · Restricted Project, Restricted Project

Jan 7 2022

eandrews added inline comments to D111566: [SYCL] Fix function pointer address space.
Jan 7 2022, 2:14 PM · Restricted Project, Restricted Project

Dec 2 2021

eandrews added a comment to D111566: [SYCL] Fix function pointer address space.

Thanks for the reviews @dylanmckay and @rjmccall ! I agree that moving the logic for functions pointers to getTargetAddressSpace makes sense. However, I'm not sure what the consequences are, since that increases the impact of this change quite a bit. I'm not sure if I will have the time to deal with any issues that arise before I go on vacation for Christmas. I'll take a quick look sometime this week, and hopefully its a simple enough change. If not, I can do it in a follow-up PR as suggested above, unless someone objects.

Dec 2 2021, 6:58 AM · Restricted Project, Restricted Project

Nov 30 2021

eandrews added a comment to D111566: [SYCL] Fix function pointer address space.

Since this patch has been accepted by one code owner, and has been under review for over a month, I plan to submit it by the end of the week. If anyone has feedback/concerns, please comment on the review.

Nov 30 2021, 1:36 PM · Restricted Project, Restricted Project
eandrews added inline comments to D112663: [clang-repl] Allow Interpreter::getSymbolAddress to take a mangled name..
Nov 30 2021, 1:29 PM
eandrews committed rG3ad0c6b75ea5: [clang-repl][NFC] Fix calling convention mismatch in test (authored by eandrews).
[clang-repl][NFC] Fix calling convention mismatch in test
Nov 30 2021, 1:27 PM

Nov 9 2021

eandrews added a comment to D98895: [X86][clang] Disable long double type for -mno-x87 option.

This patch causes a regression.

To reproduce - clang -cc1 -fsycl-is-device -triple spir64 test.cpp

test.cpp:x:3: error: 'bar<__float128>' requires 128 bit size '__float128' type support, but target 'spir64' does not support it
T bar() { return T(); };
  ^

I looked at it briefly, and I believe the issue is call to checkTypeSupport() in ActOnFinishFunctionBody(). I tried deleting the call but it breaks tests (E.g. L26 in x86_64-no-x87.cpp). @asavonic Please take a look. I will be reverting the patch if this cannot be fixed soon.

The diagnostic seems to be correct - this instance of bar returns an unsupported type. Why do you think it should not be diagnosed?

Nov 9 2021, 11:52 AM · Restricted Project
eandrews added a comment to D98895: [X86][clang] Disable long double type for -mno-x87 option.

This patch causes a regression.

Nov 9 2021, 9:12 AM · Restricted Project

Nov 4 2021

eandrews added a comment to D111566: [SYCL] Fix function pointer address space.

ping

Nov 4 2021, 7:22 AM · Restricted Project, Restricted Project

Nov 2 2021

eandrews committed rG5c8d3053fa0c: Fix complex types declared using mode TC (authored by eandrews).
Fix complex types declared using mode TC
Nov 2 2021, 12:01 PM
eandrews closed D112975: Fix complex types declared using mode TC.
Nov 2 2021, 12:01 PM · Restricted Project
eandrews added a comment to D112975: Fix complex types declared using mode TC.

For posterity in case someone tracks down this review: TC corresponds to an unspecified 128-bit format, which on some targets is a double-double format (like __ibm128_t) and on others is float128_t. The bug in the previous patch is that long double is only safe to use when it's known to be one of those formats.

Patch LGTM.

Nov 2 2021, 9:14 AM · Restricted Project

Nov 1 2021

eandrews added a comment to D109950: [Clang] Enable IC/IF mode for __ibm128.

Oh, yes, I think this should be preserving the old logic there and just adding a new clause for explicit requests for ibm128, right?

I do wonder whether that's the right priority between float128_t and a double-double long double. I think that particular configuration only exists on certain PPC targets; does anyone know what GCC does?

Nov 1 2021, 6:06 PM · Restricted Project
eandrews requested review of D112975: Fix complex types declared using mode TC.
Nov 1 2021, 5:58 PM · Restricted Project

Oct 29 2021

eandrews added a comment to D109950: [Clang] Enable IC/IF mode for __ibm128.

Oh, yes, I think this should be preserving the old logic there and just adding a new clause for explicit requests for ibm128, right?

Oct 29 2021, 12:55 PM · Restricted Project
eandrews added a comment to D109950: [Clang] Enable IC/IF mode for __ibm128.

This has changed the behavior for -

Oct 29 2021, 8:54 AM · Restricted Project

Oct 21 2021

eandrews added inline comments to D111566: [SYCL] Fix function pointer address space.
Oct 21 2021, 8:50 AM · Restricted Project, Restricted Project

Oct 20 2021

eandrews added a comment to D111566: [SYCL] Fix function pointer address space.

ping

Oct 20 2021, 8:44 AM · Restricted Project, Restricted Project

Oct 13 2021

eandrews updated the diff for D111566: [SYCL] Fix function pointer address space.

Thanks for taking a look @yaxunl! I added a test.

Oct 13 2021, 5:25 PM · Restricted Project, Restricted Project

Oct 11 2021

eandrews requested review of D111566: [SYCL] Fix function pointer address space.
Oct 11 2021, 10:57 AM · Restricted Project, Restricted Project

Mar 18 2021

eandrews committed rGd8b8f544d9de: [Reland] "Do not apply calling conventions to MSVC entry points" (authored by eandrews).
[Reland] "Do not apply calling conventions to MSVC entry points"
Mar 18 2021, 4:41 AM
eandrews closed D97941: [Reland] "Do not apply calling conventions to MSVC entry points".
Mar 18 2021, 4:41 AM · Restricted Project

Mar 8 2021

eandrews added inline comments to D97941: [Reland] "Do not apply calling conventions to MSVC entry points".
Mar 8 2021, 12:31 PM · Restricted Project
eandrews updated the diff for D97941: [Reland] "Do not apply calling conventions to MSVC entry points".

Implemented review comment to restrict __stdcall default calling convention (for WinMain, wWinMain, and DllMain) to 32 bit Windows.

Mar 8 2021, 12:29 PM · Restricted Project

Mar 4 2021

eandrews requested review of D97941: [Reland] "Do not apply calling conventions to MSVC entry points".
Mar 4 2021, 5:48 AM · Restricted Project

Feb 12 2021

eandrews accepted D96538: [SYCL] Ignore file-scope asm during device-side SYCL compilation..

LGTM Thanks!

Feb 12 2021, 12:47 AM · Restricted Project
eandrews edited reviewers for D96538: [SYCL] Ignore file-scope asm during device-side SYCL compilation., added: eandrews; removed: elizabethandrews.
Feb 12 2021, 12:46 AM · Restricted Project

Sep 17 2020

eandrews added a comment to D87701: Do not apply calling conventions to MSVC entry points.

This broke Firefox builds too, in one of our helper binaries that uses a wWinMain, although I'm having trouble writing a minimal reproducer for it. Simply making a barebones wWinMain program doesn't hit the error.

If the patch re-lands, please cc me and I'll re-test.

Sep 17 2020, 2:25 PM · Restricted Project

Sep 16 2020

eandrews added a comment to D87701: Do not apply calling conventions to MSVC entry points.
In D87701#2274860, @rnk wrote:

lgtm, thanks.

Sep 16 2020, 9:44 AM · Restricted Project
eandrews committed rG4cff1b40dacf: Do not apply calling conventions to MSVC entry points (authored by eandrews).
Do not apply calling conventions to MSVC entry points
Sep 16 2020, 9:43 AM
eandrews closed D87701: Do not apply calling conventions to MSVC entry points.
Sep 16 2020, 9:42 AM · Restricted Project

Sep 15 2020

eandrews requested review of D87701: Do not apply calling conventions to MSVC entry points.
Sep 15 2020, 8:24 AM · Restricted Project

Feb 12 2020

eandrews committed rGa58017e5cae5: Fix type-dependency of bitfields in templates (authored by eandrews).
Fix type-dependency of bitfields in templates
Feb 12 2020, 1:38 PM
eandrews closed D72242: Fix crash on value dependent bitfields in if conditions in templates.
Feb 12 2020, 1:38 PM · Restricted Project
eandrews added a comment to D72242: Fix crash on value dependent bitfields in if conditions in templates.

I'm not sure why Phabricator is still showing Needs Review, but @rnk's approval should make this count as accepted.

Feb 12 2020, 1:37 PM · Restricted Project
eandrews added a comment to D72242: Fix crash on value dependent bitfields in if conditions in templates.

Actually I just noticed it still says 'Needs review' above. I'm not sure what the protocol is. Can I push the patch?

Feb 12 2020, 1:10 PM · Restricted Project
eandrews added a comment to D72242: Fix crash on value dependent bitfields in if conditions in templates.

Thanks! I'll push it shortly. Just running a final ninja check-all after updating workspace.

Feb 12 2020, 11:47 AM · Restricted Project

Feb 6 2020

eandrews updated the diff for D72242: Fix crash on value dependent bitfields in if conditions in templates.

Thanks for taking a look Richard. This patch adds the required value-dependency check and sets type-dependency accordingly.

Feb 6 2020, 4:51 PM · Restricted Project

Jan 22 2020

eandrews added a comment to D72242: Fix crash on value dependent bitfields in if conditions in templates.
In D72242#1820908, @rnk wrote:

I think I liked the first version of this patch better. I would say, if the AST after instantiation remains the same as it was before D69950, then the first one seems like the right fix.

Jan 22 2020, 3:12 PM · Restricted Project

Jan 9 2020

eandrews updated the diff for D72242: Fix crash on value dependent bitfields in if conditions in templates.

Semantic analysis for value dependent conditions is now skipped as per Erich's comment. Patch adds an argument to CheckBooleanCondition to still do the required analysis for noexcept expressions.

Jan 9 2020, 11:39 AM · Restricted Project

Jan 8 2020

eandrews added a comment to D72242: Fix crash on value dependent bitfields in if conditions in templates.

Thanks for taking a look Erich!

Jan 8 2020, 8:09 AM · Restricted Project

Jan 5 2020

eandrews created D72242: Fix crash on value dependent bitfields in if conditions in templates.
Jan 5 2020, 7:39 PM · Restricted Project

Dec 5 2019

eandrews added a comment to D69950: Reapply "Fix crash on switch conditions of non-integer types in templates".

This (when reapplied in https://reviews.llvm.org/rG878a24ee244a24c39d1c57e9af2) broke compilation of code that earlier built fine. A reduced example:

namespace glslang {
class TPoolAllocator {
  void operator=(TPoolAllocator);
};
template <class> class a {
  TPoolAllocator *b;
  void c() { allocator = *b; }
  TPoolAllocator allocator;
};
} // namespace glslang

With this patch, some errors in templates are diagnosed earlier (i.e. does not wait till instantiation). Since 'allocator' and 'b' aren't dependent, I think this is a valid diagnosis. GCC throws an error on this code upon instantiation. https://godbolt.org/z/X9Y-Vy

The original non-reduced case does build fine with GCC though (I'm fairly sure). I can try to reduce one later that still builds with GCC but fails with current clang.

Dec 5 2019, 11:30 AM · Restricted Project
eandrews added a comment to D69950: Reapply "Fix crash on switch conditions of non-integer types in templates".

This (when reapplied in https://reviews.llvm.org/rG878a24ee244a24c39d1c57e9af2) broke compilation of code that earlier built fine. A reduced example:

namespace glslang {
class TPoolAllocator {
  void operator=(TPoolAllocator);
};
template <class> class a {
  TPoolAllocator *b;
  void c() { allocator = *b; }
  TPoolAllocator allocator;
};
} // namespace glslang
Dec 5 2019, 9:46 AM · Restricted Project

Dec 3 2019

eandrews committed rG878a24ee244a: Reapply "Fix crash on switch conditions of non-integer types in templates" (authored by eandrews).
Reapply "Fix crash on switch conditions of non-integer types in templates"
Dec 3 2019, 3:42 PM

Nov 19 2019

eandrews added a comment to D69950: Reapply "Fix crash on switch conditions of non-integer types in templates".

hence not throwing the warning on any platform?

The way I read the buildbot breakage, an existing ClangTidy test passed before and after this change, but broke on Windows. The breakage was that the warnings stopped being produced.

The existing test does not have this warning. I modified the test to add the check for this warning since it is generated on Linux after my patch. It is not generated on Windows because of delayed template parsing.

Is it just that warning that is not generated, or all warnings in that test file?

Nov 19 2019, 2:42 PM · Restricted Project
eandrews added a comment to D69950: Reapply "Fix crash on switch conditions of non-integer types in templates".

hence not throwing the warning on any platform?

The way I read the buildbot breakage, an existing ClangTidy test passed before and after this change, but broke on Windows. The breakage was that the warnings stopped being produced.

Nov 19 2019, 9:01 AM · Restricted Project

Nov 11 2019

eandrews added a comment to D69950: Reapply "Fix crash on switch conditions of non-integer types in templates".

The patch changes type dependency of field 'std::string s' and sets it based on field type (i.e. not type-dependent).

Nov 11 2019, 12:58 PM · Restricted Project

Nov 8 2019

eandrews added a comment to D69950: Reapply "Fix crash on switch conditions of non-integer types in templates".

Thank you for letting me know. The patch has been reverted.

Nov 8 2019, 2:33 PM · Restricted Project
eandrews added a comment to D69950: Reapply "Fix crash on switch conditions of non-integer types in templates".

@rnk @gribozavr2 clang-tidy test "bugprone-string-integer-assignment.cpp" caused a bot fail on windows. From the logs it looks like the 'CHECK-FIXES' I added in that test is failing because the fix isn't applied. I am not sure why. I don't have a windows build set up and I assume a new build is going to take some time. I am not sure what the protocol for this is. Should I go ahead and revert my patch while I investigate the issue on Windows or should I just push a new patch deleting the 'CHECK-FIXES' while I look into the issue?

Nov 8 2019, 11:21 AM · Restricted Project
eandrews updated subscribers of D69950: Reapply "Fix crash on switch conditions of non-integer types in templates".

Thank you for taking a look Reid and Dmitri. There were no fails with check-all.

Nov 8 2019, 9:58 AM · Restricted Project

Nov 7 2019

eandrews created D69950: Reapply "Fix crash on switch conditions of non-integer types in templates".
Nov 7 2019, 8:18 AM · Restricted Project

Aug 14 2019

eandrews added a comment to D61027: Fix crash on switch conditions of non-integer types in templates.

Thank you for letting me know. I did try reproducing the issue with check-all yesterday but was unable to. I do not think I build with 'clang-tools-extra' project enabled though. I'll take another look today.

Aug 14 2019, 7:16 AM · Restricted Project

Aug 13 2019

eandrews added a comment to D61027: Fix crash on switch conditions of non-integer types in templates.

Sorry, but this change broke ClangTidy tests: http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/16398. I reverted it.

Aug 13 2019, 12:20 PM · Restricted Project
eandrews committed rG76945821b9ca: Fix crash on switch conditions of non-integer types in templates (authored by eandrews).
Fix crash on switch conditions of non-integer types in templates
Aug 13 2019, 8:54 AM
eandrews committed rL368706: Fix crash on switch conditions of non-integer types in templates.
Fix crash on switch conditions of non-integer types in templates
Aug 13 2019, 8:54 AM
eandrews closed D61027: Fix crash on switch conditions of non-integer types in templates.
Aug 13 2019, 8:54 AM · Restricted Project

Aug 7 2019

eandrews added a comment to D61027: Fix crash on switch conditions of non-integer types in templates.

Thanks for taking a look Reid! I rebased the patch and had a conflict with one of Richard's patches and so ran the lit tests again and noticed there are several new failures. I am taking a look at those now.

Aug 7 2019, 7:22 AM · Restricted Project

Jul 29 2019

eandrews added a comment to D61027: Fix crash on switch conditions of non-integer types in templates.

ping

Jul 29 2019, 8:34 AM · Restricted Project

Jul 17 2019

eandrews added a comment to D61027: Fix crash on switch conditions of non-integer types in templates.

I just realized I modified the summary when I uploaded a new patch, but did not add a comment about the changes I made. Based on feedback from the bug report (https://bugs.llvm.org/show_bug.cgi?id=40982), I changed my approach for this crash. This patch changes the type dependency of the member which causes the crash.

Jul 17 2019, 3:12 PM · Restricted Project

Jun 10 2019

eandrews updated the diff for D61027: Fix crash on switch conditions of non-integer types in templates.
Jun 10 2019, 10:08 AM · Restricted Project

Apr 24 2019

eandrews added a comment to D61027: Fix crash on switch conditions of non-integer types in templates.

I ran the test you provided and it does throw errors without instantiation

Apr 24 2019, 2:22 PM · Restricted Project

Apr 23 2019

eandrews added a comment to D61027: Fix crash on switch conditions of non-integer types in templates.

I apologize for the confusion. I was working on an incorrect branch earlier, and so abandoned that patch and uploaded a new revision.

Apr 23 2019, 9:44 AM · Restricted Project
eandrews created D61027: Fix crash on switch conditions of non-integer types in templates.
Apr 23 2019, 9:31 AM · Restricted Project

Nov 6 2018

eandrews committed rL346237: [benchmark] Disable exceptions in Microsoft STL.
[benchmark] Disable exceptions in Microsoft STL
Nov 6 2018, 8:00 AM
eandrews closed D52998: [benchmark] Disable exceptions in Microsoft STL.
Nov 6 2018, 8:00 AM

Nov 2 2018

eandrews added a comment to D52998: [benchmark] Disable exceptions in Microsoft STL.

Thanks!

Nov 2 2018, 10:28 AM

Nov 1 2018

eandrews added a comment to D52998: [benchmark] Disable exceptions in Microsoft STL.

Upstreaming it first might be better, especially since the change seems to be trivial. Is this line addition the only change proposed for the benchmark library?

Yes this line is the only change.

Do you want me to submit the patch to the benchmark library? It seems that it would help to speedup the process.

That would be helpful. Thank you!

Nov 1 2018, 11:57 AM
eandrews updated the diff for D52998: [benchmark] Disable exceptions in Microsoft STL.

@kbobyrev I apologize if I was unclear in the comments. I was asking if the changes proposed in the comments are alright with you since they would involve modifying benchmark/CMakelists.txt (instead of llvm/CMakeLists.txt as discussed in mailing list). As Zachary mentioned in comments, _HAS_EXCEPTIONS should be set to 0 only when exceptions are disabled. Since exception handling for benchmarks is handled in benchmark/CMakeLists.txt, I think it makes most sense to add the definition there. I have now uploaded the proposed change for review.

Nov 1 2018, 10:37 AM

Oct 29 2018

eandrews added a comment to D52998: [benchmark] Disable exceptions in Microsoft STL.

Yes. I understand. At the moment, exception handling flags are generated based on BENCHMARK_ENABLE_EXCEPTIONS in utils/benchmark/CMakeLists.txt . However, _HAS_EXCEPTIONS is not defined based on this (code below). The warnings are a result of this mismatch.

if (NOT BENCHMARK_ENABLE_EXCEPTIONS)
    add_cxx_compiler_flag(-EHs-)
    add_cxx_compiler_flag(-EHa-)
  endif()

I think it makes most sense to add definition for _HAS_EXCEPTIONS=0 here as opposed to modifying llvm/CMakeLists.txt.

Then i'd recommend/suggest to submit this upstream first.

Please correct me if I'm wrong. I'm not too familiar with CMake. @kbobyrev Please let me know what you think as well since you had suggested llvm/CMakeLists.txt.

Oct 29 2018, 3:24 PM

Oct 25 2018

eandrews added a comment to D40925: Add option -fkeep-static-consts.

I think it makes sense to include this case just to make the flag more complete. Also, we don't really match GCC behavior for this flag. GCC emits all static constants by default (when O0). When optimized, this flag has no effect on GCC. The negation is used to not emit the constants.

Oct 25 2018, 11:26 AM

Oct 9 2018

eandrews added a comment to D52998: [benchmark] Disable exceptions in Microsoft STL.

Yes. I understand. At the moment, exception handling flags are generated based on BENCHMARK_ENABLE_EXCEPTIONS in utils/benchmark/CMakeLists.txt . However, _HAS_EXCEPTIONS is not defined based on this (code below). The warnings are a result of this mismatch.

Oct 9 2018, 9:06 AM

Oct 8 2018

eandrews added a comment to D52998: [benchmark] Disable exceptions in Microsoft STL.

Thanks for the information Zachary.

Oct 8 2018, 2:58 PM
eandrews added a comment to D52998: [benchmark] Disable exceptions in Microsoft STL.

I do not think defining _HAS_EXCEPTIONS=0 affects C++ exceptions in the application. I thought it only affected the STL. I will verify this and update you.

Oct 8 2018, 2:27 PM
eandrews created D52998: [benchmark] Disable exceptions in Microsoft STL.
Oct 8 2018, 1:54 PM

Sep 4 2018

eandrews abandoned D51545: Enable -Wtautological-unsigned-zero-compare under -Wextra.
Sep 4 2018, 7:06 AM
eandrews added a comment to D51545: Enable -Wtautological-unsigned-zero-compare under -Wextra.

Alright. Thanks for the review. I will abandon this patch

Sep 4 2018, 7:05 AM

Aug 31 2018

eandrews added a comment to D51545: Enable -Wtautological-unsigned-zero-compare under -Wextra.

@lebedev.ri is there a specific reason -Wtautological-unsigned-zero-compare was removed? All the issues I am aware of talks about comparisons with min/max.

Aug 31 2018, 8:58 AM