[PATCH] D30415: Fix -mno-altivec cannot overwrite -maltivec option

uweigand added a comment. In https://reviews.llvm.org/D30415#705889, @echristo wrote: > In https://reviews.llvm.org/D30415#705196, @uweigand wrote: > > > Well, mainline GCC doesn't have -faltivec at all and never had, I think > > this was only an Apple GCC extension ... Not sure what exactly

[PATCH] D30415: Fix -mno-altivec cannot overwrite -maltivec option

uweigand added a comment. In https://reviews.llvm.org/D30415#704761, @echristo wrote: > In https://reviews.llvm.org/D30415#703652, @uweigand wrote: > > > I'm a bit confused by this discussion. -faltivec and -maltivec are simply > > aliases, they do exactly the same thing; the clang-internal

[PATCH] D30415: Fix -mno-altivec cannot overwrite -maltivec option

uweigand added a comment. In https://reviews.llvm.org/D30415#703442, @hfinkel wrote: > In https://reviews.llvm.org/D30415#703398, @echristo wrote: > > > Different suggestion: > > > > Remove the faltivec option. Even gcc doesn't support it anymore afaict. > > > What are you suggesting? Always

[PATCH] D33353: [OpenCL] An error shall occur if any scalar operand has greater rank than the type of the vector element

uweigand added a comment. Looks like this causes the build bot to fail on SystemZ: http://lab.llvm.org:8011/builders/clang-s390x-linux/builds/8741 error: 'error' diagnostics expected but not seen: File

[PATCH] D33353: [OpenCL] An error shall occur if any scalar operand has greater rank than the type of the vector element

uweigand added a comment. In https://reviews.llvm.org/D33353#765783, @bader wrote: > Could you revert Egor's commit, please? I see Renato Golin has already reverted the commit, thanks ... https://reviews.llvm.org/D33353 ___ cfe-commits mailing

[PATCH] D33353: [OpenCL] An error shall occur if any scalar operand has greater rank than the type of the vector element

uweigand added a comment. The problem is that the new test case you added does not contain a -triple argument in the compile command. This means that the compile targets the native architecture on the build system, whatever this is. Since OpenCL support on different architectures may be

[PATCH] D33648: [OpenCL] An error shall occur if any scalar operand has greater rank than the type of the vector element

uweigand accepted this revision. uweigand added a comment. This revision is now accepted and ready to land. Yes, this works for me now. Thanks! https://reviews.llvm.org/D33648 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D52840: Include Python binding tests in CMake rules

uweigand added a comment. In https://reviews.llvm.org/D52840#1265615, @mgorny wrote: > The first one seems to indicate that your `libclang.so` is broken in release > mode (optimization error?). The second one is correct (some of the tests test > for errors, and apparently don't silence the

[PATCH] D52840: Include Python binding tests in CMake rules

uweigand added a comment. This causes check-all to abort for me on SystemZ in Release mode (and never actually run the lit tests): [40/365] cd /home/uweigand/llvm/llvm-head/tools/clang/bindings/python && /usr/bin/cmake -E...BRARY_PATH=/home/uweigand/llvm/build/llvm-head/lib

[PATCH] D55916: [clang] Replace getOS() == llvm::Triple::*BSD with isOS*BSD() [NFCI]

uweigand added a comment. In D55916#1337427 , @uweigand wrote: > This causes test case failures due to no longer linking with -lrt on Linux. Never mind, already fixed :-) Thanks! Repository: rC Clang CHANGES SINCE LAST ACTION

[PATCH] D55916: [clang] Replace getOS() == llvm::Triple::*BSD with isOS*BSD() [NFCI]

uweigand added a comment. This causes test case failures due to no longer linking with -lrt on Linux. Comment at: lib/Driver/ToolChains/CommonArgs.cpp:606 CmdArgs.push_back("-lpthread"); -if (TC.getTriple().getOS() != llvm::Triple::OpenBSD) +if

[PATCH] D55057: [Headers] Make max_align_t match GCC's implementation.

uweigand added inline comments. Comment at: lib/Headers/__stddef_max_align_t.h:40 __attribute__((__aligned__(__alignof__(long double; +#ifdef __i386__ + __float128 __clang_max_align_nonce3 jyknight wrote: > Can you fix clang to consistently define

[PATCH] D55057: [Headers] Make max_align_t match GCC's implementation.

uweigand added inline comments. Comment at: lib/Headers/__stddef_max_align_t.h:40 __attribute__((__aligned__(__alignof__(long double; +#ifdef __i386__ + __float128 __clang_max_align_nonce3 jyknight wrote: > EricWF wrote: > > uweigand wrote: > > >

[PATCH] D55057: [Headers] Make max_align_t match GCC's implementation.

uweigand marked an inline comment as done. uweigand added inline comments. Comment at: lib/Headers/__stddef_max_align_t.h:40 __attribute__((__aligned__(__alignof__(long double; +#ifdef __i386__ + __float128 __clang_max_align_nonce3 uweigand wrote: >

[PATCH] D55057: [Headers] Make max_align_t match GCC's implementation.

uweigand added a comment. As an aside, it would be nice if we had a test case that verifies the explicit values of alignof(max_align_t) on all supported platforms. This is an ABI property that should never change. Repository: rC Clang CHANGES SINCE LAST ACTION

[PATCH] D53157: Teach the IRBuilder about constrained fadd and friends

uweigand added a comment. In D53157#1309743 , @cameron.mcinally wrote: > Digressing a bit, but has anyone given thought to how this implementation > will play out with libraries? When running with traps enabled, libraries must > be compiled for

[PATCH] D55057: [Headers] Make max_align_t match GCC's implementation.

uweigand added inline comments. Comment at: lib/Headers/__stddef_max_align_t.h:40 __attribute__((__aligned__(__alignof__(long double; +#ifdef __i386__ + __float128 __clang_max_align_nonce3 jyknight wrote: > uweigand wrote: > > jyknight wrote: > > >

[PATCH] D53157: Teach the IRBuilder about constrained fadd and friends

uweigand added a comment. In https://reviews.llvm.org/D53157#1305233, @kpn wrote: > In https://reviews.llvm.org/D53157#1304347, @uweigand wrote: > > > But given that there is still infrastructure missing in the IR optimizers, > > I also think that at least in the first implementation, we

[PATCH] D54355: Use is.constant intrinsic for __builtin_constant_p

uweigand added a comment. It seems this patch caused the SystemZ build bots to fail, they're now all running into assertion failures: ICE cannot be evaluated! UNREACHABLE executed at /home/uweigand/sandbox/buildbot/clang-s390x-linux/llvm/tools/clang/lib/AST/ExprConstant.cpp:11442! See e.g.

[PATCH] D53157: Teach the IRBuilder about constrained fadd and friends

uweigand added a comment. OK, let me try to expand on my point 3 above, which appears to have confused everybody :-) First, let's distinguish two separate requirements: those on floating-point operations that explicitly run in regions with non-default control modes, and those on

[PATCH] D53157: Teach the IRBuilder about constrained fadd and friends

uweigand added a comment. In https://reviews.llvm.org/D53157#1303193, @andrew.w.kaylor wrote: > I agree that it's preferable to re-use these existing options if possible. I > have some concerns that -ftrapping-math has a partial implementation in place > that doesn't seem to be well aligned

[PATCH] D53157: Teach the IRBuilder about constrained fadd and friends

uweigand added a comment. A couple of comments on the previous discussion: 1. Instead of defining a new command line option, I'd prefer to use the existing options -frounding-math and -ftrapping-math to set the default behavior of math operations w.r.t. rounding modes and exception status.

[PATCH] D37035: Implement __builtin_LINE() et. al. to support source location capture.

uweigand added a comment. Looks like this test is failing on SystemZ since it was added, making all our build bots red: /home/uweigand/sandbox/buildbot/clang-s390x-linux/llvm/tools/clang/test/CodeGenCXX/builtin_FUNCTION.cpp:9:11: error: CHECK: expected string not found in input // CHECK:

[PATCH] D37035: Implement __builtin_LINE() et. al. to support source location capture.

uweigand added a comment. As of r361920, the SystemZ build bots are green again. Thanks, Eric! Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D37035/new/ https://reviews.llvm.org/D37035 ___ cfe-commits mailing list

[PATCH] D63366: AMDGPU: Add GWS instruction builtins

uweigand added a comment. I'm now getting test suite failures like this: /home/uweigand/llvm/llvm-head/tools/clang/test/CodeGenOpenCL/builtins-amdgcn.cl:554:3: error: cannot compile this builtin function yet __builtin_amdgcn_ds_gws_init(value, id); Is this supposed to work? I'm not

[PATCH] D66795: [Mips] Use appropriate private label prefix based on Mips ABI

uweigand added a comment. This makes sense to me (although we don't currently need the options parameter there). CHANGES SINCE LAST ACTION https://reviews.llvm.org/D66795/new/ https://reviews.llvm.org/D66795 ___ cfe-commits mailing list

[PATCH] D67763: [Clang FE] Recognize -mnop-mcount CL option

uweigand accepted this revision. uweigand added a comment. This revision is now accepted and ready to land. This looks good to me now. Given that this patch implements an option only relevant on SystemZ, this should be OK. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D67763/new/

[PATCH] D71049: Remove implicit conversion that promotes half to other larger precision types for fp classification builtins

uweigand added a comment. This causes build bot failures on SystemZ due to a failed assertion in ConstantFP::getInfinity: http://lab.llvm.org:8011/builders/clang-s390x-linux/builds/28723/steps/ninja%20check%201/logs/FAIL%3A%20Clang%3A%3Abuiltins.c Repository: rG LLVM Github Monorepo CHANGES

[PATCH] D71467: [FPEnv] Generate constrained FP comparisons from clang

uweigand created this revision. uweigand added reviewers: kpn, andrew.w.kaylor, craig.topper, cameron.mcinally, RKSimon, spatel, rjmccall, rsmith. Herald added projects: clang, LLVM. Herald added subscribers: llvm-commits, cfe-commits. Update the IRBuilder to generate constrained FP comparisons

[PATCH] D71408: [lit] Remove lit's REQUIRES-ANY directive

uweigand added a comment. It looks like this caused build bot failures: http://lab.llvm.org:8011/builders/clang-s390x-linux/builds/28928/steps/ninja%20check%201/logs/FAIL%3A%20lit%3A%3A%20shtest-format.py

[PATCH] D71467: [FPEnv] Generate constrained FP comparisons from clang

uweigand updated this revision to Diff 234096. uweigand added a comment. Added float (f32) test cases. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D71467/new/ https://reviews.llvm.org/D71467 Files: clang/lib/CodeGen/CGExprScalar.cpp clang/test/CodeGen/fpconstrained-cmp-double.c

[PATCH] D71467: [FPEnv] Generate constrained FP comparisons from clang

uweigand added a comment. In D71467#1785943 , @erichkeane wrote: > I did the compare operators that didn't work right, and will do a separate > patch for the fp-classification type ones: > f02d6dd6c7afc08f871a623c0411f2d77ed6acf8 >

[PATCH] D71467: [FPEnv] Generate constrained FP comparisons from clang

uweigand added a comment. In D71467#1786192 , @erichkeane wrote: > __builtin_fpclassify/isfinite/isinf/isinf_sign/isnan/isnormal/signbit are all > implemented the same as the OTHER ones, except there is a strange fixup step > in SEMA that removes the

[PATCH] D71669: [Clang FE, SystemZ] Don't add "true" value for the "mnop-mcount" attribute.

uweigand accepted this revision. uweigand added a comment. This revision is now accepted and ready to land. LGTM. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D71669/new/ https://reviews.llvm.org/D71669 ___ cfe-commits mailing list

[PATCH] D71467: [FPEnv] Generate constrained FP comparisons from clang

uweigand added a comment. Ping? CHANGES SINCE LAST ACTION https://reviews.llvm.org/D71467/new/ https://reviews.llvm.org/D71467 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D72722: [FPEnv] [SystemZ] Platform-specific builtin constrained FP enablement

uweigand accepted this revision. uweigand added a comment. This revision is now accepted and ready to land. LGTM, thanks! CHANGES SINCE LAST ACTION https://reviews.llvm.org/D72722/new/ https://reviews.llvm.org/D72722 ___ cfe-commits mailing list

[PATCH] D72906: [X86] Improve X86 cmpps/cmppd/cmpss/cmpsd intrinsics with strictfp

uweigand added a comment. In D72906#1837905 , @craig.topper wrote: > In D72906#1826849 , @uweigand wrote: > > > In D72906#1826122 , @craig.topper > > wrote: > > > > > In

[PATCH] D74146: [SytemZ] Disable vector ABI when using option -march=arch[8|9|10]

uweigand added a comment. LGTM, thanks! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D74146/new/ https://reviews.llvm.org/D74146 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D72675: [Clang][Driver] Fix -ffast-math/-ffp-contract interaction

uweigand added a comment. In D72675#1829866 , @hfinkel wrote: > > I'm not sure whether this is deliberate (but it seems weird) or just a bug. > > I can ask the GCC developers ... > > Please do. If there's a rationale, we should know. Sorry for the

[PATCH] D71467: [FPEnv] Generate constrained FP comparisons from clang

uweigand added a comment. In D71467#1820589 , @rjmccall wrote: > I think I have a slight preference for the second option, where there's a > single method that does all the work for the two cases. OK, now checked in as 870137d

[PATCH] D71467: [FPEnv] Generate constrained FP comparisons from clang

uweigand added a comment. In D71467#1817939 , @rjmccall wrote: > Is this approach going to work with scope-local strictness? We need a way to > do a comparison that has the non-strict properties but appears in a function > that enables strictness

[PATCH] D72722: [FPEnv] [SystemZ] Platform-specific builtin constrained FP enablement

uweigand added a comment. A few comments (see inline) -- otherwise this looks good to me, thanks! Comment at: clang/lib/CodeGen/CGBuiltin.cpp:13354 + return Builder.CreateFNeg(Builder.CreateConstrainedFPCall(F, {X, Y, Z}), "neg"); + +} else {

[PATCH] D72722: [FPEnv] [SystemZ] Platform-specific builtin constrained FP enablement

uweigand added a comment. > What are the semantics of vfnmadb with respect to when it rounds vs the > negation? Hmm, interesting. The z/Architecture Principles of Operation states: > The results for each element of VECTOR FP NEGA- > TIVE MULTIPLY AND ADD and VECTOR FP NEGA- > TIVE MULTIPLY

[PATCH] D72906: [X86] Improve X86 cmpps/cmppd/cmpss/cmpsd intrinsics with strictfp

uweigand added a comment. > The constrained fcmp intrinsics don't allow the TRUE/FALSE predicates. Hmm, maybe they should then? The only reason I didn't add them initially was that I wasn't sure they were useful for anything; if they are, it should be straightforward to add them back.

[PATCH] D72906: [X86] Improve X86 cmpps/cmppd/cmpss/cmpsd intrinsics with strictfp

uweigand added a comment. In D72906#1826122 , @craig.topper wrote: > In D72906#1826061 , @uweigand wrote: > > > > The constrained fcmp intrinsics don't allow the TRUE/FALSE predicates. > > > > Hmm, maybe they

[PATCH] D72675: [Clang][Driver] Fix -ffast-math/-ffp-contract interaction

uweigand added a comment. I've had a quick look at GCC, and it seems there's a couple of different issues. First of all, `-ffast-math` is a "collective" flag that has no separate meaning except setting a bunch of other flags. Currently, these flags are: `-fno-math-errno`, `

[PATCH] D71467: [FPEnv] Generate constrained FP comparisons from clang

uweigand added a comment. Ping again. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D71467/new/ https://reviews.llvm.org/D71467 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D71467: [FPEnv] Generate constrained FP comparisons from clang

This revision was automatically updated to reflect the committed changes. Closed by commit rG76e9c2a9870e: [FPEnv] Generate constrained FP comparisons from clang (authored by uweigand). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D71467/new/

[PATCH] D71854: [SystemZ] Use FNeg in s390x clang builtins

uweigand accepted this revision. uweigand added a comment. This revision is now accepted and ready to land. LGTM, thanks! CHANGES SINCE LAST ACTION https://reviews.llvm.org/D71854/new/ https://reviews.llvm.org/D71854 ___ cfe-commits mailing list

[PATCH] D71854: [SystemZ] Use FNeg in s390x clang builtins

uweigand requested changes to this revision. uweigand added a comment. This revision now requires changes to proceed. This also needs updating the test cases that are testing for the old behavior: Failing Tests (4): Clang :: CodeGen/builtins-systemz-vector.c Clang ::

[PATCH] D71854: [SystemZ] Use FNeg in s390x clang builtins

uweigand added a comment. Otherwise this LGTM. Thanks for taking care of those! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D71854/new/ https://reviews.llvm.org/D71854 ___ cfe-commits mailing list

[PATCH] D75914: systemz: allow configuring default CLANG_SYSTEMZ_ARCH

uweigand added a comment. Thanks for working on this, @thakis ! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D75914/new/ https://reviews.llvm.org/D75914 ___ cfe-commits mailing list

[PATCH] D75914: systemz: allow configuring default CLANG_SYSTEMZ_ARCH

uweigand added a comment. Ah, good point. Dimitry, can you prepare an updated patch to implement Jonas' suggestion? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D75914/new/ https://reviews.llvm.org/D75914

[PATCH] D75914: systemz: allow configuring default CLANG_SYSTEMZ_ARCH

This revision was automatically updated to reflect the committed changes. Closed by commit rG9c9d88d8b1bb: [SystemZ] Allow configuring default CLANG_SYSTEMZ_ARCH (authored by uweigand). Herald added a subscriber: cfe-commits. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION

[PATCH] D87279: [clang] Fix handling of physical registers in inline assembly operands.

uweigand added a comment. In D87279#2334510 , @jonpa wrote: > The problem seems to be with a tied earlyclobber operand: > > asm("" : "+"(a)); > > Per the comment in InlineAsm::ConstraintInfo::Parse(), only output can be > earlyclobber. > > I am not

[PATCH] D81583: Update SystemZ ABI to handle C++20 [[no_unique_address]] attribute

uweigand updated this revision to Diff 276650. uweigand added a comment. Drop AllowNoUniqueAddress parameter; address review comment. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D81583/new/ https://reviews.llvm.org/D81583 Files: clang/lib/CodeGen/TargetInfo.cpp

[PATCH] D81583: Update SystemZ ABI to handle C++20 [[no_unique_address]] attribute

uweigand marked 6 inline comments as done. uweigand added inline comments. Comment at: clang/lib/CodeGen/TargetInfo.cpp:521 + // [[no_unique_address]] attribute (since C++20). Those do count + // as empty according to the Itanium ABI. This property is currently + // only

[PATCH] D81583: Update SystemZ ABI to handle C++20 [[no_unique_address]] attribute

uweigand updated this revision to Diff 276414. uweigand added a comment. Handle array of empty records correctly. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D81583/new/ https://reviews.llvm.org/D81583 Files: clang/lib/CodeGen/TargetInfo.cpp clang/test/CodeGen/systemz-abi.cpp

[PATCH] D81583: Update SystemZ ABI to handle C++20 [[no_unique_address]] attribute

uweigand marked 2 inline comments as done. uweigand added a comment. In D81583#2137277 , @efriedma wrote: > I'm tempted to say this is a bugfix for the implementation of > no_unique_address, and just fix it globally for all ABIs. We're never going > to

[PATCH] D81583: Update SystemZ ABI to handle C++20 [[no_unique_address]] attribute

uweigand added a comment. In D81583#2138127 , @qiucf wrote: > Thanks for this patch! > > If I understand correctly, only `isEmptyRecord`/`isEmptyField` and places > checking any field is zero bit-width may need change for this? Since >

[PATCH] D81583: Update SystemZ ABI to handle C++20 [[no_unique_address]] attribute

uweigand added a comment. Another ping ... See also http://lists.llvm.org/pipermail/cfe-dev/2020-July/066162.html Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D81583/new/ https://reviews.llvm.org/D81583

[PATCH] D81583: Update SystemZ ABI to handle C++20 [[no_unique_address]] attribute

uweigand closed this revision. uweigand added a comment. Committed as 4c5a93bd58bad70e91ac525b0e020bd5119a321a . CHANGES SINCE LAST ACTION https://reviews.llvm.org/D81583/new/ https://reviews.llvm.org/D81583

[PATCH] D80833: [CodeView] Add full repro to LF_BUILDINFO record

uweigand added a comment. In D80833#2123508 , @aganea wrote: > In D80833#2109172 , @uweigand wrote: > > > Hmm, with clang-cl it seems the driver is trying to use this: > > Target: s390x-pc-windows-msvc > > which

[PATCH] D81583: Update SystemZ ABI to handle C++20 [[no_unique_address]] attribute

uweigand updated this revision to Diff 276151. uweigand added a comment. Rebased against mainline. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D81583/new/ https://reviews.llvm.org/D81583 Files: clang/lib/CodeGen/TargetInfo.cpp clang/test/CodeGen/systemz-abi.cpp Index:

[PATCH] D80833: [CodeView] Add full repro to LF_BUILDINFO record

uweigand added a comment. > Line 4 here fails on s390x but not on other Unix flavors, see: > http://lab.llvm.org:8011/builders/clang-s390x-linux/builds/33346/steps/ninja%20check%201/logs/FAIL%3A%20Clang%3A%3Adebug-info-codeview-buildinfo.c > > @thakis @uweigand Any ideas would could go wrong

[PATCH] D81583: Update SystemZ ABI to handle C++20 [[no_unique_address]] attribute

uweigand added a comment. Ping? I'd really appreciate feedback about this ABI issue, in particular from other affected target maintainers ... Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D81583/new/ https://reviews.llvm.org/D81583

[PATCH] D80833: [CodeView] Add full repro to LF_BUILDINFO record

uweigand added a comment. Hmm, with clang-cl it seems the driver is trying to use this: Target: s390x-pc-windows-msvc which of course doesn't exist. Not sure what is supposed to be happening here, but it seems that it's falling back on s390x-linux since on s390x, Linux is currently the only

[PATCH] D78644: [LSan] Enable for SystemZ

uweigand accepted this revision. uweigand added a comment. This revision is now accepted and ready to land. This all looks good to me. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D78644/new/ https://reviews.llvm.org/D78644

[PATCH] D81583: Update SystemZ ABI to handle C++20 [[no_unique_address]] attribute

uweigand created this revision. uweigand added reviewers: craig.topper, erichkeane, jasonliu, kbarton, rnk, asl, sunfish, t.p.northover, arsenm, asb. Herald added subscribers: cfe-commits, wdng. Herald added a project: clang. The SystemZ ABI has special cases to handle structs containing just a

[PATCH] D84341: Implement __builtin_eh_return_data_regno for SystemZ

This revision was automatically updated to reflect the committed changes. Closed by commit rG7f003957bfcd: [SystemZ] Implement __builtin_eh_return_data_regno (authored by uweigand). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D84341/new/

[PATCH] D84341: Implement __builtin_eh_return_data_regno for SystemZ

uweigand accepted this revision. uweigand added a comment. This revision is now accepted and ready to land. LGTM with the format fixes. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D84341/new/ https://reviews.llvm.org/D84341

[PATCH] D82862: [ThinLTO] Always parse module level inline asm with At dialect

uweigand added a comment. Herald added a subscriber: pengfei. Hi @hans , we're having some issues with using the AssemblerDialect mechanism to support both the GNU assembler and the IBM HLASM assembler in the SystemZ back-end. See also the discussion started here:

[PATCH] D82862: [ThinLTO] Always parse module level inline asm with At dialect

uweigand added a comment. In D82862#2500717 , @hans wrote: >> In D82862#2498785 , @hans wrote: >> >>> The motivation for my change was really just to make ThinLTO compiles work >>> the same as non-ThinLTO ones.

[PATCH] D82862: [ThinLTO] Always parse module level inline asm with At dialect

uweigand added a comment. In D82862#2500038 , @pengfei wrote: >> What is the reason for treating this differently in LLVM? > > I'm not sure if it is related to this. I think one difference is that LLVM is > supporting MS inline assembly. Although it uses

[PATCH] D82862: [ThinLTO] Always parse module level inline asm with At dialect

uweigand added a comment. In D82862#2513044 , @rnk wrote: > In D82862#2512908 , @uweigand wrote: > >> So why do you want GNU inline asm for clang-cl anyway? I thought the whole >> point of clang-cl was to be

[PATCH] D96033: [clang-repl] Land initial infrastructure for incremental parsing

uweigand added a comment. Looks like this is also failing on s390x: error: Added modules have incompatible data layouts: E-m:e-i1:8:16-i8:8:16-i64:64-f128:64-a:8:16-n32:64 (module) vs E-m:e-i1:8:16-i8:8:16-i64:64-f128:64-v128:64-a:8:16-n32:64 (jit) The problem here is that on s390x we use a

[PATCH] D96033: [clang-repl] Land initial infrastructure for incremental parsing

uweigand added a comment. In D96033#2765954 , @v.g.vassilev wrote: > @hubert.reinterpretcast, thanks for the feedback. I have created a patch as > discussed -- https://reviews.llvm.org/D102688 > > @uweigand, thanks for reaching out. I believe the patch

[PATCH] D96033: [clang-repl] Land initial infrastructure for incremental parsing

uweigand added a comment. Yes, this patch fixes the problem for me. Thanks! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D96033/new/ https://reviews.llvm.org/D96033 ___ cfe-commits mailing list

[PATCH] D102064: Parse vector bool when stdbool.h and altivec.h are included

uweigand added a comment. In D102064#2751089 , @ZarkoCA wrote: > In D102064#2751001 , @uweigand > wrote: > >> This means the implementation now deviates from the documented vector >> extension syntax, right?

[PATCH] D102064: Parse vector bool when stdbool.h and altivec.h are included

uweigand added a comment. This means the implementation now deviates from the documented vector extension syntax, right? I guess it's strictly an extension of the documented syntax, but that may still lead to incompatibilities with other compilers for the platform. If we want to make such a

[PATCH] D97901: [SystemZ] Test for infinity in testFPKind().

uweigand accepted this revision. uweigand added a comment. This revision is now accepted and ready to land. LGTM, thanks! CHANGES SINCE LAST ACTION https://reviews.llvm.org/D97901/new/ https://reviews.llvm.org/D97901 ___ cfe-commits mailing list

[PATCH] D97901: [SystemZ] Test for infinity in testFPKind().

uweigand added inline comments. Comment at: clang/lib/CodeGen/TargetInfo.cpp:7229 + case Builtin::BI__builtin_isfinite: +Invert = true; +LLVM_FALLTHROUGH; thopre wrote: > jonpa wrote: > > What are these variants all about...? > > > They

[PATCH] D96568: [CFE, SystemZ] Emit s390.tdc instrincic for __builtin_isnan in Constrained FP mode.

uweigand accepted this revision. uweigand added a comment. This revision is now accepted and ready to land. LGTM as well, thanks! CHANGES SINCE LAST ACTION https://reviews.llvm.org/D96568/new/ https://reviews.llvm.org/D96568 ___ cfe-commits

[PATCH] D109362: [SystemZ][z/OS] Add GOFF Support to the DataLayout

uweigand added a comment. SystemZ specific parts LGTM, but it would be good to have someone else review the common code / IR changes as well. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D109362/new/ https://reviews.llvm.org/D109362

[PATCH] D109362: [SystemZ][z/OS] Add GOFF Support to the DataLayout

uweigand accepted this revision. uweigand added a comment. This LGTM now. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D109362/new/ https://reviews.llvm.org/D109362 ___ cfe-commits mailing list

[PATCH] D109362: [SystemZ][z/OS] Add GOFF Support to the DataLayout

uweigand added inline comments. Comment at: llvm/docs/LangRef.rst:2596 * ``e``: ELF mangling: Private symbols get a ``.L`` prefix. +* ``l``: GOFF mangling: Private symbols get a ``.L`` prefix. * ``m``: Mips mangling: Private symbols get a ``$`` prefix.

[PATCH] D109362: [SystemZ][z/OS] Add GOFF Support to the DataLayout

uweigand added a comment. Looking at the common code parts, it seems the behavior of MM_GOFF is actually identical to MM_ELF. Is this correct? If so, do we really need a different format type here? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION

[PATCH] D109362: [SystemZ][z/OS] Add GOFF Support to the DataLayout

uweigand added a comment. In D109362#3000284 , @anirudhp wrote: > In D109362#2999688 , @uweigand > wrote: > >> Looking at the common code parts, it seems the behavior of MM_GOFF is >> actually identical to

[PATCH] D105629: [TSan] Add SystemZ support

uweigand added a comment. See inline comments ... otherwise the SystemZ platform-specific parts look good to me. Comment at: compiler-rt/lib/tsan/rtl/tsan_platform_posix.cpp:123 +#if defined(__s390x__) + ProtectRange(HiAppMemEnd(), 0xf000ull); +#endif

[PATCH] D105629: [TSan] Add SystemZ support

uweigand added inline comments. Comment at: compiler-rt/lib/tsan/rtl/tsan_platform_posix.cpp:123 +#if defined(__s390x__) + ProtectRange(HiAppMemEnd(), 0xf000ull); +#endif iii wrote: > uweigand wrote: > > Did you test this on older kernels without

[PATCH] D105629: [TSan] Add SystemZ support

uweigand added inline comments. Comment at: compiler-rt/lib/tsan/rtl/tsan_platform_posix.cpp:123 +#if defined(__s390x__) + ProtectRange(HiAppMemEnd(), 0xf000ull); +#endif iii wrote: > uweigand wrote: > > iii wrote: > > > uweigand wrote: > > > > Did

[PATCH] D109362: [SystemZ][z/OS] Add GOFF Support to the DataLayout

uweigand added a comment. In D109362#3013253 , @anirudhp wrote: > - Reduced the number of test lines in target-data.c, since we don't have to > check for every combination of arch,cpu for the SystemZ target (for both elf > and z/OS) These changes

[PATCH] D91944: OpenMP 5.0 metadirective

uweigand added a comment. Looks like this was committed again, breaking the SystemZ build bots once again: https://lab.llvm.org/buildbot/#/builders/94/builds/5661 Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D91944/new/

[PATCH] D91944: OpenMP 5.0 metadirective

uweigand added a comment. In D91944#3009868 , @cchen wrote: > The SystemZ issue is due to the fact that we assumed that `device(cpu)` > should be evaluated to true and `device(gpu)` should be evaluated to false in > the test so the test should be fixed

[PATCH] D105629: [TSan] Add SystemZ support

uweigand added a comment. The SystemZ specific changes all look good to me now, thanks! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D105629/new/ https://reviews.llvm.org/D105629 ___ cfe-commits mailing

[PATCH] D123627: Correctly diagnose prototype redeclaration errors in C

uweigand added a comment. It looks like this caused the LNT build bot to fail (at least on s390x), because one of the test cases now triggers this error: https://lab.llvm.org/buildbot/#/builders/45/builds/6787 /usr/bin/make -f

[PATCH] D123627: Correctly diagnose prototype redeclaration errors in C

uweigand added a comment. In D123627#3451373 , @aaron.ballman wrote: > Thank you for letting me know -- I've speculatively fixed the issue in > 726901d06aab2f92d684d28507711308368c29d6 >

[PATCH] D158883: [Matrix] Try to emit fmuladd for both vector and matrix types

uweigand added a comment. In D158883#4638648 , @thegameg wrote: > In D158883#4635997 , @uweigand > wrote: > >> The newly added test cases in ffp-model.c fail on SystemZ, making CI red: > > Should be fixed,

[PATCH] D158883: [Matrix] Try to emit fmuladd for both vector and matrix types

uweigand added a comment. The newly added test cases in ffp-model.c fail on SystemZ, making CI red: https://lab.llvm.org/buildbot/#/builders/94/builds/16280 The root cause seems to be that by default, the SystemZ back-end targets a machine without SIMD support, and therefore vector return types

[PATCH] D127498: [SystemZ/z/OS] Set DWARF version to 4 for z/OS.

uweigand accepted this revision. uweigand added a comment. LGTM Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D127498/new/ https://reviews.llvm.org/D127498 ___ cfe-commits mailing list

  1   2   >