[PATCH] D126959: [C++20][Modules] Introduce an implementation module.

bjope added a comment. This seem to case problems when building with asan enabled (LLVM_USE_SANITIZER='Address'): Failed Tests (24): Clang :: CXX/basic/basic.link/p2.cpp Clang :: CXX/basic/basic.lookup/basic.lookup.argdep/p5-ex2.cpp Clang :: CXX/basic/basic.scope/basic.scope.namesp

[PATCH] D126959: [C++20][Modules] Introduce an implementation module.

bjope added a comment. In D126959#4222854 , @iains wrote: > In D126959#4222637 , @bjope wrote: > >> This seem to case problems when building with asan enabled >> (LLVM_USE_SANITIZER='Address'): > > investigating.

[PATCH] D145704: Revert "Set FLT_EVAL_METHOD to -1 when fast-math is enabled."

bjope added a comment. I have no objections about doing this revert. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D145704/new/ https://reviews.llvm.org/D145704 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi

[PATCH] D145868: [clang][ASTImporter] Fix import of typedef with unnamed structures

bjope added inline comments. Comment at: clang/unittests/AST/ASTImporterTest.cpp:8627 + )"; + Decl *ToTU = getToTuDecl("", Lang_CXX11); + Decl *FromTU = getTuDecl(Code, Lang_CXX11); With Werror we get: ``` ../../clang/unittests/AST/ASTImporterTest.cpp:862

[PATCH] D145868: [clang][ASTImporter] Fix import of typedef with unnamed structures

bjope added inline comments. Comment at: clang/unittests/AST/ASTImporterTest.cpp:8627 + )"; + Decl *ToTU = getToTuDecl("", Lang_CXX11); + Decl *FromTU = getTuDecl(Code, Lang_CXX11); balazske wrote: > bjope wrote: > > With Werror we get: > > > > ``` > > ..

[PATCH] D99439: Update @llvm.powi to handle different int sizes for the exponent

bjope added a comment. Ping! (This patch is now 1 month old, has a number of reviewers and 41 subscribers, but not a single comment yet. I believe that if you aren't comfortable with reviewing, then it is perfectly OK to remove yourself as reveiwer to let the author know that the original set

[PATCH] D99439: Update @llvm.powi to handle different int sizes for the exponent

bjope added inline comments. Comment at: llvm/docs/LangRef.rst:13280 +floating-point or vector of floating-point type. The type of the exponent +should typically match the size of ``int``, at least when the intrinsic maps +to one of the ``__powi*`` functions in compiler-rt. Not a

[PATCH] D99439: Update @llvm.powi to handle different int sizes for the exponent

bjope added inline comments. Comment at: llvm/test/Transforms/InstCombine/pow_fp_int16.ll:1 -; NOTE: Assertions have been autogenerated by utils/update_test_checks.py -; RUN: opt -mtriple unknown -instcombine -S < %s | FileCheck %s +; RUN: opt -mtriple msp430 -instcombine -S < %s

[PATCH] D99439: Update @llvm.powi to handle different int sizes for the exponent

bjope added inline comments. Comment at: llvm/test/Transforms/InstCombine/pow-4.ll:4 +; RUN: opt -instcombine -S < %s -mtriple unknown -disable-builtin sqrt | FileCheck %s --check-prefixes=CHECK,CHECKI32,NOSQRT +; RUN: opt -instcombine -S < %s -mtriple msp430

[PATCH] D101194: [Driver] Push multiarch path setup to individual drivers

bjope added a comment. Got some problems with my builds after this commit. My cmake commands looks like this (well, this is after having tried to fix the problem by replacing `x86_64-unknown-linux-gnu` by `x86_64-linux-gnu` as I figured that might be needed after looking at the changes in this

[PATCH] D101194: [Driver] Push multiarch path setup to individual drivers

bjope added a comment. In D101194#2720787 , @phosek wrote: > In D101194#2720761 , @bjope wrote: > >> Or maybe the problem is that we use `-DLLVM_BUILTIN_TARGETS=default`? > > The use of `default` is the issue, the

[PATCH] D89055: [analyzer] Wrong type cast occures during pointer dereferencing after type punning

bjope added inline comments. Comment at: clang/lib/StaticAnalyzer/Core/SValBuilder.cpp:765 +R = StateMgr.getStoreManager().castRegion(ER, CastTy); +return loc::MemRegionVal(R); + } This caused some problems with assertion failures, see https

[PATCH] D81285: [builtins] Change si_int to int in some helper declarations

bjope added a comment. Hi! My users have found problems with miscompiles that seem to originate from this patch. As a background, my target has 16-bit int, and 32-bit long. And the calling convention is not that an i16 is passed as the low bits in a 32-bit register that would be used for an i

[PATCH] D99439: Update @llvm.powi to handle different int sizes for the exponent

bjope added a comment. Ping! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D99439/new/ https://reviews.llvm.org/D99439 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bi

[PATCH] D86632: [Fixed Point] Add codegen for conversion between fixed-point and floating point.

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rGc4944a6f53f6: [Fixed Point] Add codegen for conversion between fixed-point and floating point. (authored by ebevhan, committed by bjope). Herald add

[PATCH] D86632: [Fixed Point] Add codegen for conversion between fixed-point and floating point.

bjope added a comment. I've just landed this on behalf of @ebevhan. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D86632/new/ https://reviews.llvm.org/D86632 ___ cfe-commits mailing list cfe-commits@lists

[PATCH] D94977: [CodeGen] Honor getCharWidth() in CGRecordLowering

bjope created this revision. bjope requested review of this revision. Herald added a project: clang. Herald added a subscriber: cfe-commits. When using getByteArrayType the requested size was calculated in char units, but the type used for the array was hardcoded to the Int8Ty. Honor the size of c

[PATCH] D94979: [CGExpr] Honor getCharWidth() in ConstantAggregateBuilderUtils

bjope created this revision. bjope requested review of this revision. Herald added a project: clang. Herald added a subscriber: cfe-commits. In CGExprConstant.cpp, when dealing with padding etc, some sizes are calculated as char units. But then the type used when creating the aggregate expression

[PATCH] D94979: [CGExpr] Honor getCharWidth() in ConstantAggregateBuilderUtils

bjope added a comment. In D94979#2507242 , @lebedev.ri wrote: > As far as i recall, all RFC's about LLVM support for non-8-bit char targets > didn't end in favor of the proposal > I'd say that until there's general consensus/buy-in (including testing path

[PATCH] D94979: [CGExpr] Use getCharWidth() more consistently in ConstantAggregateBuilderUtils. NFC

bjope updated this revision to Diff 318135. bjope added a comment. Updated to add CharTy to the CodeGenTypeCache (based on review feedback). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D94979/new/ https://reviews.llvm.org/D94979 Files: clang/li

[PATCH] D94979: [CGExpr] Use getCharWidth() more consistently in CCGExprConstant. NFC

bjope added a comment. @lebedev.ri : I think I need your blessing as well on this, considering your earlier concerns. Is it still just confusing? (I doubt that we want/can replace all uses of getCharWidth/getIntWidth etc in clang with integers) Repository: rG LLVM Github Monorepo CHANGES SI

[PATCH] D106102: [analyzer][solver] Introduce reasoning for not equal to operator

bjope added a comment. I get failures after having merged this patch: /llvm/build-all/bin/clang -Xanalyzer -analyzer-output=text -Xanalyzer -analyzer-checker='nullability,optin.portability.UnixAPI,security,valist' -Xanalyzer -analyzer-disable-checker='security.insecureAPI.strcpy' --analyze c

[PATCH] D106102: [analyzer][solver] Introduce reasoning for not equal to operator

bjope added a comment. I actually see lots of these as well: clang: ../lib/Support/APInt.cpp:284: int llvm::APInt::compareSigned(const llvm::APInt &) const: Assertion `BitWidth == RHS.BitWidth && "Bit widths must be same for comparison"' failed. Although I haven't verified if those are relat

<    1   2