[PATCH] D27140: Allow clang to write compilation database records

joerg updated the summary for this revision. joerg set the repository for this revision to rL LLVM. joerg updated this revision to Diff 79997. joerg added a comment. Add test case. Repository: rL LLVM https://reviews.llvm.org/D27140 Files: include/clang/Basic/DiagnosticDriverKinds.td inc

[PATCH] D27304: [PATCH] [Sema][X86] Don't allow floating-point return types when SSE is disabled

joerg added a comment. Rejecting -mno-sse2 for x86_64 is even worse. Dynamic linkers e.g. in FreeBSD and NetBSD depend on that. They also don't contain floating point code, but that's a separate question. Similar constraints exist for the kernels. https://reviews.llvm.org/D27304 ___

[PATCH] D26564: Use PIC relocation mode by default for PowerPC64 ELF

joerg added a comment. Ping https://reviews.llvm.org/D26564 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D27140: Allow clang to write compilation database records

joerg added a comment. Ping Repository: rL LLVM https://reviews.llvm.org/D27140 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D27140: Allow clang to write compilation database records

This revision was automatically updated to reflect the committed changes. Closed by commit rL288821: Allow clang to write compilation database records. (authored by joerg). Changed prior to commit: https://reviews.llvm.org/D27140?vs=79997&id=80429#toc Repository: rL LLVM https://reviews.llv

[PATCH] D32427: Fix float abi for SUSE ARM triples

joerg added a comment. I'm not sure the results will really work that well either. https://reviews.llvm.org/D32427 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D33259: Don't defer to the GCC driver for linking arm-baremetal

joerg added a comment. While I fully agree that the current fallback-to-GCC behavior is far from helpful, I'm not sure how much sense providing linker support for bare-metal makes. I would expect this to changes wildly depending on the specific environment. https://reviews.llvm.org/D33259

[PATCH] D33272: Method loadFromCommandLine should be able to report errors

joerg added a comment. Can this use ErrorOr? https://reviews.llvm.org/D33272 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D33304: [clang-tidy] Add a new module Android and a new check for file descriptors.

joerg added a comment. I find the use of "must" at the very least inappropriate. If there was no use case for not including it, it wouldn't be an option. There is also nothing really Android-specific here beside maybe the open64 mess. Repository: rL LLVM https://reviews.llvm.org/D33304 _

[PATCH] D33356: [Nios2] Changes in frontend to support Nios2 LLVM target

joerg added inline comments. Comment at: lib/Basic/Targets.cpp:7614 + resetDataLayout(("e-" + Layout).str()); +} + } Can you just give the full string and avoid the runtime allocations? Comment at: lib/Basic/Targets.cpp:7650 +Defi

[PATCH] D33356: [Nios2] Changes in frontend to support Nios2 LLVM target

joerg added inline comments. Comment at: lib/Basic/Targets.cpp:7650 +DefineStd(Builder, "nios2", Opts); +DefineStd(Builder, "NIOS2", Opts); + belickim wrote: > joerg wrote: > > DefineStd tends to give a lot of namespace pollution, is that intentional > >

[PATCH] D33356: [Nios2] Changes in frontend to support Nios2 LLVM target

joerg added inline comments. Comment at: lib/Basic/Targets.cpp:7650 +DefineStd(Builder, "nios2", Opts); +DefineStd(Builder, "NIOS2", Opts); + belickim wrote: > joerg wrote: > > belickim wrote: > > > joerg wrote: > > > > DefineStd tends to give a lot of na

[PATCH] D116088: [compiler-rt] Implement ARM atomic operations for architectures without SMP support

joerg added a comment. Correct me if I'm wrong, but I don't think this stubs are async signal safe nor will they work for preemptive multitasking systems? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D116088/new/ https://reviews.llvm.org/D116088

[PATCH] D118021: [Driver] Use libatomic for 32-bit SPARC atomics support

joerg added inline comments. Comment at: clang/lib/Driver/ToolChains/Solaris.cpp:135 } +// LLVM lacks atomics support on 32-bit SPARC, so forcibly link with +// libatomic as a workaround. This comment is misleading. It's not so much that LLVM doesn't

[PATCH] D101122: introduce flag -fsanitize-address-detect-stack-use-after-return-mode. No functional change.

joerg added a comment. This review doesn't make sense to me. Why add a flag that isn't affecting anything? Why add a flag that isn't even tested? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D101122/new/ https://reviews.llvm.org/D101122 _

[PATCH] D101122: introduce flag -fsanitize-address-detect-stack-use-after-return-mode. No functional change.

joerg added a comment. There are two approaches that work for reviewing: starting from clang and going down or starting from compiler-rt and going up the layers. I'd prefer to do the latter as it means meaningful testing can be done easier. There are two natural steps here: clang flag+IR genera

[PATCH] D116882: [docs] [clang] Small documentation change for compilation databases

joerg accepted this revision. joerg added inline comments. This revision is now accepted and ready to land. Comment at: clang/docs/JSONCompilationDatabase.rst:33 +Clang has the ablity to generate compilation database fragments via +the :option:`-MJ argument >`. You can contantina

[PATCH] D114564: Fix the use of -fno-approx-func along with -Ofast or -ffast-math

joerg added inline comments. Comment at: clang/lib/Driver/ToolChains/Clang.cpp:2760 case options::OPT_fno_honor_nans: HonorNaNs = false;break; case options::OPT_fapprox_func: ApproxFunc = true;break; case options::OPT_fno_approx_func:

[PATCH] D113372: [Driver] Add CLANG_DEFAULT_PIE to emulate GCC --enable-default-pie

joerg added inline comments. Comment at: clang/CMakeLists.txt:230 +option(CLANG_DEFAULT_PIE "Default to -fPIE and -pie (Linux only)" OFF) +if(CLANG_DEFAULT_PIE) This option should really be called something like CLANG_DEFAULT_PIE_ON_LINUX or so. It should be e

[PATCH] D113372: [Driver] Add CLANG_DEFAULT_PIE_ON_LINUX to emulate GCC --enable-default-pie

joerg added a comment. Last update introduced a lot of unrelated changes? But the actual intended change seems fine now. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D113372/new/ https://reviews.llvm.org/D113372 __

[PATCH] D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs

joerg added a comment. The NetBSD part looks ok, but also lacks proper testing. I'm not sure anyone but Linux cares at all otherwise as they lack 32bit SPARC support. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D98574/new/ https://reviews.llvm.or

[PATCH] D100054: Handle flags such as -m32 when computing the triple prefix for programs

joerg added a comment. This sounds wrong. If you are using 'x86_64-freebsd' as triple and -m32, it should still call 'x86_64-freebsd-ld', but it is the responsibility of the driver to ensure that also the right set of linker flags are passed as well. Compare `netbsd::Linker::ConstructJob` for o

[PATCH] D93031: Enable fexec-charset option

joerg added a comment. "Keeping the original spelling around" would assume that the input is not using a stateful encoding. That seems worse as assumption than giving the canonical output in UTF-8 and shifting the problem to the user's editor? Repository: rG LLVM Github Monorepo CHANGES SIN

[PATCH] D111863: [libunwind] Add an interface for dynamic .eh_frame registration

joerg added a comment. I would strongly prefer if ORCv2 doesn't depend on this. It essentially forces libunwind to parse the whole section just to find the delimiters of the FDEs. That's a lot of unnecessary work as JIT use normally allows registering functions individually. Repository: rG

[PATCH] D111863: [libunwind] Add an interface for dynamic .eh_frame registration

joerg added a comment. In D111863#3071651 , @lhames wrote: > In D111863#3071353 , @joerg wrote: > >> I would strongly prefer if ORCv2 doesn't depend on this. It essentially >> forces libunwind to parse the whole

[PATCH] D111863: [libunwind] Add an interface for dynamic .eh_frame registration

joerg added a comment. In D111863#3072023 , @housel wrote: > It's also worth noting that FreeBSD's version of libgcc exception handling is > actually based on the libunwind code, with a local patch >

[PATCH] D112413: [X86] Add -mskip-rax-setup support to align with GCC

joerg added inline comments. Comment at: llvm/lib/Target/X86/X86ISelLowering.cpp:99 +cl::desc("Skips setting up the RAX register when SSE is disabled and there " + "are no variable arguments passed in vector registers."), +cl::Hidden); The de

<    1   2   3