[PATCH] D72910: Fix a bug with clang with object destructor, while skipping object initialization - make clang crash

dim added a comment. Eh, no it does not crash clang, at least not here? Instead it gives you a compile error, as it should: cleanup.cpp:15:5: error: cannot jump from this goto statement to its label goto clean_up; ^ cleanup.cpp:20:7: note: jump bypasses v

[PATCH] D72910: Fix a bug with clang with object destructor, while skipping object initialization - make clang crash

dim added a comment. Aha, which version of clang-cl are you using? With the released version of clang-cl 9.0.1, I get a warning instead of an error: cleanup.cpp(15,5): warning: jump from this goto statement to its label is a Microsoft extension [-Wmicrosoft-goto] goto clean

[PATCH] D71600: PowerPC 32-bit - forces 8 byte lock/lock_free decisions at compiled time

dim added inline comments. Comment at: clang/lib/AST/ExprConstant.cpp:11180 +// Avoid emiting call for runtime decision on PowerPC 32-bit +// The lock free possibilities on this platform are covered by the lines `s/emiting/emitting/` Repository: r

[PATCH] D41808: Rename clang link from clang-X.Y to clang-X

dim accepted this revision. dim added a comment. This revision is now accepted and ready to land. LGTM. https://reviews.llvm.org/D41808 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commit

[PATCH] D44536: Avoid segfault when destructor is not yet known

dim added a comment. Ping. Open to sugggestions here :) Repository: rC Clang https://reviews.llvm.org/D44536 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D45406: Document -std= values for different languages

dim created this revision. dim added reviewers: rsmith, dexonsmith, sylvestre.ledru, mgorny. Herald added subscribers: krytarowski, fhahn. After a remark on a FreeBSD mailing list that the clang man page did not have any list of possible values for the `-std=` flag, I have now attempted to exhaust

[PATCH] D45406: Document -std= values for different languages

dim added a comment. In https://reviews.llvm.org/D45406#1060768, @mgorny wrote: > To be honest, I find those '(deprecated)' confusing — the user may mistakenly > assume that it's about all values rather than the alias. Sure, what would you suggest as an alternative? Not listing them, listing

[PATCH] D45406: Document -std= values for different languages

dim updated this revision to Diff 141513. dim added a comment. - Use "values" instead of "options" - Remove deprecated standard values Repository: rC Clang https://reviews.llvm.org/D45406 Files: docs/CommandGuide/clang.rst Index: docs/CommandGuide/clang.rst ==

[PATCH] D45406: Document -std= values for different languages

dim added a comment. In https://reviews.llvm.org/D45406#1060914, @mgorny wrote: > Well, my idea was to list the standards one per line (like on GCC manpage), > and then the '(deprecated)' comments would probably stand out enough to apply > to a single line. Also, FWICS the gcc manpage simply li

[PATCH] D45406: Document -std= values for different languages

dim updated this revision to Diff 141529. dim added a comment. Attempt to put the standard values in to definition lists. In the HTML output, this looks fairly nice, but as a man page, it seems a bit strange, for example: -std= Specify the language standard to compile for.

[PATCH] D45406: Document -std= values for different languages

dim added a comment. So, does this look good enough to commit? Repository: rC Clang https://reviews.llvm.org/D45406 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D45406: Document -std= values for different languages

dim added a comment. Ping Repository: rC Clang https://reviews.llvm.org/D45406 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D45406: Document -std= values for different languages

This revision was automatically updated to reflect the committed changes. Closed by commit rL329827: Document -std= values for different languages (authored by dim, committed by ). Herald added a subscriber: llvm-commits. Changed prior to commit: https://reviews.llvm.org/D45406?vs=141529&id=142

[PATCH] D144778: [Driver][FreeBSD] Further simplify the Driver handling for older FreeBSD releases

dim accepted this revision. dim added a comment. This revision is now accepted and ready to land. LGTM, are there no test cases which are affected by this? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D144778/new/ https://reviews.llvm.org/D144778

[PATCH] D144823: [Driver][FreeBSD] Simplify ARM handling

dim accepted this revision. dim added a comment. This revision is now accepted and ready to land. I think this is fine. @emaste can you think of any objections? 8 and 9 are long gone. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D144823/new/ https

[PATCH] D152788: [Clang] Show type in enum out of range diagnostic

dim added a comment. In D152788#4439714 , @shafik wrote: > Thank you for this improvement! Well, it would still be nice to have the instantiation trace, as Aaron suggested. So that is probably one of those "exercise for the reader" things. :D Reposito

[PATCH] D135171: FreeBSD: enable __float128 on x86 and powerpc64le

dim accepted this revision. dim added a comment. LGTM again :) Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D135171/new/ https://reviews.llvm.org/D135171 ___ cfe-commits mailing list cfe-commits@lists.ll

[PATCH] D144232: [PowerPC] Correctly use ELFv2 ABI on FreeBSD/powerpc64

dim added a comment. In D144232#4136787 , @brad wrote: > I noticed this review. I have provided a more complete diff for review at > D144321 . Yeah I think that is probably the better option, hope @pkubaj and @adalava

[PATCH] D144321: [PowerPC] Correctly use ELFv2 ABI on all OS's that use the ELFv2 ABI

dim accepted this revision. dim added a comment. This revision is now accepted and ready to land. LGTM, some minor clang-format nits, but these aren't critical (to me at least :) Comment at: clang/lib/Basic/Targets/PPC.h:432 + Triple.getOSMajorVersion() >= 13)) || Trip

[PATCH] D144321: [PowerPC] Correctly use ELFv2 ABI on all OS's that use the ELFv2 ABI

dim accepted this revision. dim added a comment. Yeah, this looks quite a bit nicer, and should be more maintainable. Thanks. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D144321/new/ https://reviews.llvm.org/D144321 __

[PATCH] D144341: [Driver][FreeBSD] Correct driver behavior if a triple is provided without a version

dim accepted this revision. dim added a comment. This revision is now accepted and ready to land. In D144341#4140652 , @arichardson wrote: > LGTM, but I'll let @dim and @emaste decide if FreeBSD 8 code is still needed. No, these versions are ancient now

[PATCH] D144444: [PowerPC] Use member function to determine PowerPC Secure PLT

dim accepted this revision. dim added a comment. This revision is now accepted and ready to land. Yes, this is quite a bit nicer. Maybe run the isPPCSecurePlt() function through clang-format, just to be sure of the style? (I think you can ignore the weird libFuzzer Unit Test errors, they don't s

[PATCH] D144444: [PowerPC] Use member function to determine PowerPC Secure PLT

dim added a comment. In D14#4142146 , @MaskRay wrote: > `isPPC32SecurePlt` is probably more accurate. I agree, good catch! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D14/new/ https://reviews.llv

[PATCH] D144444: [PowerPC] Use member function to determine PowerPC Secure PLT

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

[PATCH] D150226: [Clang] Remove ability to downgrade warning on the diagnostic for setting a non fixed enum to a value outside the range of the enumeration values

dim added a comment. I submitted a similar workaround for the FreeBSD devel/gdb port, via https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271045 that also applies `-Wno-enum-constexpr-conversion`. As the upstream commit message said, they didn't see any other good way to get rid of the warnin

[PATCH] D150226: [Clang] Remove ability to downgrade warning on the diagnostic for setting a non fixed enum to a value outside the range of the enumeration values

dim added a subscriber: bsdjhb. dim added a comment. In D150226#4353911 , @aaron.ballman wrote: > One of the major selling points to `constexpr` functions in C++ is that they > cannot contain UB -- if your code compiles, it is correct. This bug that >

[PATCH] D148822: [clang][BFloat] Avoid redefining bfloat16_t in arm_neon.h

dim created this revision. dim added reviewers: t.p.northover, fpetrogalli, sdesmalen, az, LukeGeeson, stuij. Herald added a project: All. dim requested review of this revision. Herald added a project: clang. As of https://reviews.llvm.org/D79708, clang-tblgen generates both `arm_neon.h` and `arm

[PATCH] D148822: [clang][BFloat] Avoid redefining bfloat16_t in arm_neon.h

dim updated this revision to Diff 515409. dim added a comment. Also fix up arm_sve.h. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D148822/new/ https://reviews.llvm.org/D148822 Files: clang/utils/TableGen/NeonEmitter.cpp clang/utils/TableGen/S

[PATCH] D148822: [clang][BFloat] Avoid redefining bfloat16_t in arm_neon.h

dim added a comment. In D148822#4305188 , @simonbutcher wrote: > I can't see anything wrong with this patch and it looks pretty > straightforward to me, but is it necessary? > > '-Wtypedef-redefinition' is documented as not applying to system headers >

[PATCH] D148822: [clang][BFloat] Avoid redefining bfloat16_t in arm_neon.h

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rGdb492316399a: [clang][BFloat] Avoid redefining bfloat16_t in arm_neon.h (authored by dim). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST

[PATCH] D152788: [Clang] Show type in enum out of range diagnostic

dim created this revision. dim added reviewers: aaron.ballman, erichkeane, shafik, thakis. Herald added a project: All. dim requested review of this revision. Herald added a project: clang. When the diagnostic for an out of range enum value is printed, it currently does not show the actual enum ty

[PATCH] D152788: [Clang] Show type in enum out of range diagnostic

dim updated this revision to Diff 531011. dim added a comment. Add release note and test with template instantiation. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D152788/new/ https://reviews.llvm.org/D152788 Files: clang/docs/ReleaseNotes.rst

[PATCH] D152788: [Clang] Show type in enum out of range diagnostic

dim updated this revision to Diff 531013. dim added a comment. Squash. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D152788/new/ https://reviews.llvm.org/D152788 Files: clang/docs/ReleaseNotes.rst clang/include/clang/Basic/DiagnosticASTKinds.t

[PATCH] D152788: [Clang] Show type in enum out of range diagnostic

dim added inline comments. Comment at: clang/test/SemaCXX/constant-expression-cxx11.cpp:2479-2486 +template struct Bitfield { + static constexpr T max = static_cast((1 << size) - 1); +}; + +void testValueInRangeOfEnumerationValuesViaTemplate() { + Bitfield good; + Bitfield bad

[PATCH] D152788: [Clang] Show type in enum out of range diagnostic

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG69d42eef4bec: [Clang] Show type in enum out of range diagnostic (authored by dim). Changed prior to commit: https://reviews.llvm.org/D152788?vs=53

[PATCH] D28472: Move _PairT declaration out of __hash_combine to avoid warning under C++98

dim created this revision. dim added reviewers: EricWF, mclow.lists. dim added subscribers: emaste, cfe-commits. Some parts of the FreeBSD tree are still compiled with C++98, and until https://reviews.llvm.org/rL288554 this has always worked fine. After that, a complaint about the newly introduc

[PATCH] D28472: Move _PairT declaration out of __hash_combine to avoid warning under C++98

This revision was automatically updated to reflect the committed changes. Closed by commit rL291476: Move _PairT declaration out of __hash_combine to avoid warning under C++98 (authored by dim). Changed prior to commit: https://reviews.llvm.org/D28472?vs=83654&id=83672#toc Repository: rL LLV

[PATCH] D28520: Disable -Wthread-safety-analysis for some functions in __thread_support

dim created this revision. dim added reviewers: EricWF, mclow.lists. dim added subscribers: cfe-commits, emaste, joerg. Many thread-related libc++ test cases fail on FreeBSD, due to the following -Werror warnings: In file included from /share/dim/src/llvm/trunk/projects/libcxx/test/std/thread

[PATCH] D28520: Disable -Wthread-safety-analysis for some functions in __thread_support

dim added a comment. In https://reviews.llvm.org/D28520#641534, @aaron.ballman wrote: > Alternatively, these functions could be given the proper thread safety > annotations, couldn't they? Aha, I was not aware of the existence of these attributes. I'll take a look. https://reviews.llvm.org/

[PATCH] D28520: Disable -Wthread-safety-analysis for some functions in __thread_support

dim added a comment. In https://reviews.llvm.org/D28520#641563, @EricWF wrote: > Also look in `__mutex` where libc++ defines its own macros for the > annotations. I assume you mean `__mutex_base`. Do we want to reuse the macros from that file? If so we'd have to include it in `__thread_supp

[PATCH] D28520: Disable -Wthread-safety-analysis for some functions in __thread_support

dim updated this revision to Diff 83843. dim added a comment. - Move `_LIBCPP_THREAD_SAFETY_ANNOTATION` macro definition to `__config`. - Add `_LIBCPP_THREAD_SAFETY_ANNOTATION(no_thread_safety_analysis)` macros to `__threading_support` function declarations which require them. Note that I was no

[PATCH] D28520: Disable -Wthread-safety-analysis for some functions in __thread_support

dim added a comment. Hmm, actually this does not work. The definition of `_LIBCPP_THREAD_SAFETY_ANNOTATION` I moved from `__mutex_base` to `__config` is only enabled if `_LIBCPP_ENABLE_THREAD_SAFETY_ANNOTATIONS` is manually defined. There must have been some reason to do it like this in `__mut

[PATCH] D28520: Disable -Wthread-safety-analysis for some functions in __thread_support

dim updated this revision to Diff 83851. dim added a comment. Let's try this simpler version instead. https://reviews.llvm.org/D28520 Files: include/__threading_support Index: include/__threading_support === --- include/__threa

[PATCH] D28520: Disable -Wthread-safety-analysis for some functions in __thread_support

dim added a subscriber: ed. dim added a comment. In https://reviews.llvm.org/D28520#646160, @aaron.ballman wrote: > I feel like I must be missing something; why is this disabling rather than > specifying the thread safety behavior? e.g., `__libcpp_mutex_lock()` > specifying that it acquires the

[PATCH] D28520: Disable -Wthread-safety-analysis for some functions in __thread_support

dim updated this revision to Diff 84451. dim added a comment. Something like this might work, maybe. (I haven't yet run the full test suite, as that takes quite a while on my machines.) I did not re-use the `_LIBCPP_THREAD_SAFETY_ANNOTATION` macro from `__mutex_base`, since that is included *a

[PATCH] D28520: Disable -Wthread-safety-analysis for some functions in __thread_support

dim updated this revision to Diff 84452. dim added a comment. Also added capability attributes to the non-pthread versions of `__libcpp_mutex` types. https://reviews.llvm.org/D28520 Files: include/__threading_support Index: include/__threading_support ==

[PATCH] D28520: Disable -Wthread-safety-analysis for some functions in __thread_support

dim added a comment. Actually, according to https://svnweb.freebsd.org/base?view=revision&revision=270943 (where the annotations were added), this helped to uncover existing bugs. I don't see why it would interfere with anything; if you ask for -Wthread-safety warnings, you should get them, r

[PATCH] D28520: Disable -Wthread-safety-analysis for some functions in __thread_support

dim updated this revision to Diff 84462. dim added a comment. Remove extraneous parenthesis. https://reviews.llvm.org/D28520 Files: include/__threading_support Index: include/__threading_support === --- include/__threading_supp

[PATCH] D28520: Disable -Wthread-safety-analysis for some functions in __thread_support

dim updated this revision to Diff 84465. dim added a comment. Rebase after recent changes. https://reviews.llvm.org/D28520 Files: include/__threading_support Index: include/__threading_support === --- include/__threading_suppor

[PATCH] D28520: Disable -Wthread-safety-analysis for some functions in __thread_support

dim added a comment. In https://reviews.llvm.org/D28520#646564, @EricWF wrote: > This breaks on all platforms were pthread_mutex_t isn't annotated. Hm, sorry about that, I didn't realize. I'm building it on Ubuntu now to see what breaks, and how to fix it. https://reviews.llvm.org/D28520

[PATCH] D28520: Disable -Wthread-safety-analysis for some functions in __thread_support

dim added a comment. Note that my earlier approach of just disabling -Wthread-safety for those few functions might be easier. This should not cause any trouble for any platforms which don't use annotated pthread functions. https://reviews.llvm.org/D28520 ___

[PATCH] D28520: Disable -Wthread-safety-analysis for some functions in __thread_support

dim added inline comments. Comment at: include/__threading_support:43 +#if defined(__clang__) && __has_attribute(acquire_capability) +#define _LIBCPP_THREAD_SAFETY_ATTRIBUTE(x) __attribute__((x)) I think the least intrusive way would be to add a `defined(__Free

[PATCH] D28981: Use GNU-style attributes for several __throw_XXX() functions

dim created this revision. In https://reviews.llvm.org/rL279744, `__throw_XXX()` functions were introduced, partially for compatibility with software compiled against libstdc++. `_LIBCPP_NORETURN` is used on all of them, and when C++11 attributes are available, this gets defined as `[[noreturn

[PATCH] D28520: Disable -Wthread-safety-analysis for some functions in __thread_support

dim added a comment. In https://reviews.llvm.org/D28520#648880, @delesley wrote: > Sorry about the slow response. My main concern here is that the thread > safety analysis was designed for use with a library that wraps the system > mutex in a separate Mutex class. We did that specifically to

[PATCH] D28520: Disable -Wthread-safety-analysis for some functions in __thread_support

dim updated this revision to Diff 85283. dim added a comment. Let's try it with this much simpler version instead, which disables the thread safety analysis _only_ for FreeBSD, and nowhere else. And no messing with capabilities, either. https://reviews.llvm.org/D28520 Files: include/__thre

[PATCH] D28520: Disable -Wthread-safety-analysis for some functions in __thread_support

dim updated this revision to Diff 85440. dim added a comment. In https://reviews.llvm.org/D28520#653360, @aaron.ballman wrote: > In https://reviews.llvm.org/D28520#652607, @dim wrote: > > > > [...] >> I'm really open to any variant, as long as something that works can get in >> before the 4.0

[PATCH] D28981: Use GNU-style attributes for several __throw_XXX() functions

dim added a comment. In https://reviews.llvm.org/D28981#653908, @mclow.lists wrote: > > In https://reviews.llvm.org/rL279744, __throw_XXX() functions were > > introduced, partially for compatibility with software compiled against > > libstdc++. > > You're working from a false premise. These fu

[PATCH] D28981: Use GNU-style attributes for several __throw_XXX() functions

dim abandoned this revision. dim added a comment. Ok, back to Mozilla we go. https://reviews.llvm.org/D28981 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D28520: Disable -Wthread-safety-analysis for some functions in __thread_support

dim added a comment. In https://reviews.llvm.org/D28520#656202, @delesley wrote: > The big question for me is whether these functions are exposed as part of the > public libcxx API, or whether they are only used internally. As far as I can see, they are only used internally, in `src/algorithm.

[PATCH] D28520: Disable -Wthread-safety-analysis for some functions in __thread_support

dim updated this revision to Diff 85794. dim added a comment. Back to the previous version, using `no_thread_safety_analysis` for FreeBSD only. Optionally, we could delete the `defined(__FreeBSD__)` part, and disable the analysis for all platforms. https://reviews.llvm.org/D28520 Files: in

[PATCH] D28520: Disable -Wthread-safety-analysis for some functions in __thread_support

This revision was automatically updated to reflect the committed changes. Closed by commit rL293197: Disable thread safety analysis for some functions in __thread_support (authored by dim). Changed prior to commit: https://reviews.llvm.org/D28520?vs=85794&id=85939#toc Repository: rL LLVM ht

[PATCH] D28213: [Frontend] Correct values of ATOMIC_*_LOCK_FREE to match builtin

dim added a comment. In https://reviews.llvm.org/D28213#639397, @hfinkel wrote: > LGTM. This seems consistent with what GCC does. On x86 it also sets > __GCC_ATOMIC_LLONG_LOCK_FREE to 2. Hmm, unfortunately on i386-freebsd, it does not: $ gcc6 -v Using built-in specs. COLLECT_GCC=gcc6

[PATCH] D28213: [Frontend] Correct values of ATOMIC_*_LOCK_FREE to match builtin

dim added a comment. In https://reviews.llvm.org/D28213#666196, @mgorny wrote: > In https://reviews.llvm.org/D28213#665967, @dim wrote: > > > I don't think FreeBSD has lock-free 64 bit atomic operations on 32-bit x86. > > IIRC we already had some trouble before with clang emitting libcalls to

[PATCH] D28213: [Frontend] Correct values of ATOMIC_*_LOCK_FREE to match builtin

dim added a comment. In https://reviews.llvm.org/D28213#666269, @dim wrote: > In https://reviews.llvm.org/D28213#666196, @mgorny wrote: > > > > ... >> What's the value of `__atomic_always_lock_free(sizeof(long long), 0)` for >> gcc and clang? > > For gcc, it is always 0, for clang (I tested

[PATCH] D28213: [Frontend] Correct values of ATOMIC_*_LOCK_FREE to match builtin

dim added a comment. Created https://llvm.org/bugs/show_bug.cgi?id=31864 to continue this on the bug tracker. Repository: rL LLVM https://reviews.llvm.org/D28213 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-b

[PATCH] D29542: [TargetInfo] Adjust x86-32 atomic support to the CPU used

dim added inline comments. Comment at: lib/Basic/Targets.cpp:4244 +} else // allow locked atomics up to 4 bytes + MaxAtomicPromoteWidth = 32; + } Are you purposefully not setting `MaxAtomicInlineWidth` here? (It seems from `TargetInfo` that the defaul

[PATCH] D29542: [TargetInfo] Adjust x86-32 atomic support to the CPU used

dim added a comment. There's still something strange here. If I compile the following on i386-freebsd12, with `clang -march=i486 -O2 -S`: _Atomic(long long) ll; void f(void) { ++ll; } the result is: .globl f .p2align4, 0x90 .type f,@function

[PATCH] D33900: Print registered targets in clang's version information

dim added a comment. In https://reviews.llvm.org/D33900#818957, @thakis wrote: > Sorry, I just noticed this weeks later. Why are we adding this to `--version` > instead of adding some new flag for printing this? When I pass `--version`, > I'm usually interested in clang's version and don't need

[PATCH] D33900: Print registered targets in clang's version information

dim added a comment. Also note that it is only added to the `--version` output, not the `-v` output (the former is really a "verbose" version of the latter): $ clang -v clang version 5.0.0 (trunk 308421) Target: x86_64-unknown-freebsd12.0 Thread model: posix InstalledDir: /share/dim/ll

[PATCH] D27277: Make _LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR user-settable

dim created this revision. dim added reviewers: EricWF, emaste, mclow.lists, theraven. dim added a subscriber: cfe-commits. In https://reviews.llvm.org/rL275749 the old _LIBCPP_TRIVIAL_PAIR_COPY_CTOR define was replaced by _LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR, which is also auto-

[PATCH] D27277: Make _LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR user-settable

dim abandoned this revision. dim added a comment. No, let's drop it. In the FreeBSD ports bug I have posted a patch to use `_LIBCPP_ABI_UNSTABLE ` instead, which appears to work fine. And at some point we'll update to `_LIBCPP_ABI_VERSION` 2, but not today. :) https://reviews.llvm.org/D27277

[PATCH] D32670: Ensure showbase does not overflow do_put buffers

dim created this revision. Herald added a subscriber: emaste. In https://bugs.freebsd.org/207918, Daniel McRobb describes how using std::showbase with ostreams can cause truncation of unsigned long long when output format is octal. In fact, this can even happen with unsigned int and unsigned long

[PATCH] D32670: Ensure showbase does not overflow do_put buffers

dim added a comment. Note: I copied some of the test case from https://reviews.llvm.org/rL227097, which had a similar case of a too short buffer. https://reviews.llvm.org/D32670 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.l

[PATCH] D32670: Ensure showbase does not overflow do_put buffers

dim updated this revision to Diff 97198. dim added a comment. Simplify test case a bit. https://reviews.llvm.org/D32670 Files: include/locale test/std/input.output/iostream.format/output.streams/ostream.formatted/ostream.inserters.arithmetic/minmax_showbase.pass.cpp Index: test/std/input.

[PATCH] D32670: Ensure showbase does not overflow do_put buffers

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

[PATCH] D117388: [Driver][FreeBSD] -r: imply -nostdlib like GCC

dim accepted this revision. dim added a comment. This revision is now accepted and ready to land. LGTM, thanks! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D117388/new/ https://reviews.llvm.org/D117388

[PATCH] D94355: [Passes] Add relative lookup table converter pass

dim added subscribers: emaste, jrtc27, dim. dim added a comment. FWIW, this commit turned out to break the FreeBSD dns/bind916 port, see https://bugs.freebsd.org/259921. The short story is that the bind9 code on and after this line: https://gitlab.isc.org/isc-projects/bind9/-/blob/main/lib/isc/

[PATCH] D98286: [Driver] Enable kernel address and memory sanitizers on FreeBSD

dim accepted this revision. dim added a comment. LGTM, but this would probably need some sort of test, at least that it correctly accepts the flag(s) now? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D98286/new/ https://reviews.llvm.org/D98286 __

[PATCH] D94941: Add minor version to libclang.so and libclang-cpp.so SONAME

dim added a comment. @sylvestre.ledru removed the minor version from the binary (on purpose, I think?) in rGa8b717fda42294d1c8e1f05d71280503e5839f14 : commit a8b717fda42294d1c8e1f05d71280503e5839f14 Author: Sylvestre Ledru

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

dim added a subscriber: emaste. dim 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] D104386: [PowerPC][Builtins] Added a number of builtins for compatibility with XL.

dim added subscribers: emaste, dim. dim added a comment. Note that this unexpectedly broke FreeBSD's powerpc64 builds, as we've long used the following in our `lib/libc/powerpc64/string/bcopy.S`: #ifndef FN_NAME #ifdef MEMMOVE #define FN_NAME __memmove WEAK_REFERE

[PATCH] D104386: [PowerPC][Builtins] Added a number of builtins for compatibility with XL.

dim added subscribers: adalava, jhibbits. dim added a comment. In D104386#2973372 , @nemanjai wrote: > In D104386#2973245 , @dim wrote: > >> Note that this unexpectedly broke FreeBSD's powerpc64 builds, as we've l

[PATCH] D104386: [PowerPC][Builtins] Added a number of builtins for compatibility with XL.

dim added a comment. Just encountered another similar error, apparently introduced in rGc8937b6cb9751807de1e69f0f0f70a9a58f8f5dc (as more additions to the `defineXLCompatMacros` function, by @lei): In file included from /h

[PATCH] D104386: [PowerPC][Builtins] Added a number of builtins for compatibility with XL.

dim added a comment. In D104386#2977302 , @nemanjai wrote: > The idea with putting all of these in a separate function was to: > > 1. Make it easy to limit it to specific targets as I suggested above > 2. Have them all in one place to easily identify whic

<    1   2