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
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.
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
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
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
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
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
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
dim added a comment.
@rsmith, any objections?
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
dim added a comment.
I'm fine with either this approach, or with the approach in stdint.h, e.g.
using `__has_include_next()`, and in that case first including the
system-provided header before this one.
Repository:
rC Clang
https://reviews.llvm.org/D44604
dim added inline comments.
Comment at: CMakeLists.txt:422
+ "${CLANG_VERSION_MAJOR}" CACHE STRING
"Version number that will be placed into the clang executable, in the form
XX.YY")
set(LIBCLANG_LIBRARY_VERSION
Please update the descriptions too, e.g.
dim added a comment.
In https://reviews.llvm.org/D44536#1039420, @rjmccall wrote:
> I'm not sure it's supposed to be a valid state to get into IRGen with a
> non-trivial destructor that isn't yet declared. Richard?
As a side note, clang also emits a warning about it (but then crashes :) ):
dim created this revision.
dim added reviewers: rjmccall, rsmith, majnemer, efriedma.
In some cases, a class type can have a definition, but its destructor
may not yet be known. In that case, a segfault can occur in
`EmitObjectDelete`.
Avoid it by checking the return value of
This revision was automatically updated to reflect the committed changes.
Closed by commit rL325446: [X86] Add sahf CPU feature to frontend
(authored by dim, committed by ).
Herald added a subscriber: llvm-commits.
Repository:
rL LLVM
https://reviews.llvm.org/D43394
Files:
dim updated this revision to Diff 134808.
dim added a comment.
Remove the `__LAHFSAHF__` predefined macro.
Repository:
rC Clang
https://reviews.llvm.org/D43394
Files:
include/clang/Driver/Options.td
lib/Basic/Targets/X86.cpp
lib/Basic/Targets/X86.h
test/CodeGen/attr-target-x86.c
dim updated this revision to Diff 134746.
dim added a comment.
Added the `sahf` feature for knm, knl and amdfam10 too.
Repository:
rC Clang
https://reviews.llvm.org/D43394
Files:
include/clang/Driver/Options.td
lib/Basic/Targets/X86.cpp
lib/Basic/Targets/X86.h
dim added inline comments.
Comment at: lib/Basic/Targets/X86.cpp:1049
+ if (HasLAHFSAHF)
+Builder.defineMacro("__LAHFSAHF__");
craig.topper wrote:
> Does gcc define this? It's such a low level instruction I have a hard time
> believing this define would
dim created this revision.
dim added reviewers: craig.topper, coby, efriedma, rsmith.
Make clang accept `-msahf` (and `-mno-sahf`) flags to activate the
`+sahf` feature for the backend, for bug 36028 (Incorrect use of
pushf/popf enables/disables interrupts on amd64 kernels). This was
originally
This revision was automatically updated to reflect the committed changes.
Closed by commit rCXX325027: Put type attributes after class keyword (authored
by dim, committed by ).
Changed prior to commit:
https://reviews.llvm.org/D43209?vs=133932=134065#toc
Repository:
rCXX libc++
dim created this revision.
dim added reviewers: EricWF, mclow.lists.
Compiling `` in C++17 or higher mode results in:
functional:2500:1: warning: attribute '__visibility__' is ignored, place it
after "class" to apply attribute to type declaration [-Wignored-attributes]
_LIBCPP_TYPE_VIS
^
dim added a comment.
In https://reviews.llvm.org/D43159#1004625, @EricWF wrote:
> So my main concern with this patch is that `nullptr` is actually
> `#defined`'ed in C++03 mode. That definition comes from the `__nullptr`
> header, and therefore we would need to add that header to each include
This revision was automatically updated to reflect the committed changes.
Closed by commit rL324855: Add default C++ ABI libname and include paths for
FreeBSD (authored by dim, committed by ).
Herald added a subscriber: llvm-commits.
Repository:
rL LLVM
https://reviews.llvm.org/D43166
Files:
dim added a comment.
LGTM minus a few nits, though it would be nice if you can verify that all the
changed headers still compile in `-std=c++98` and/or `-std=gnu++98` mode.
Comment at: include/functional:1573
return &__f_.first();
-return (const void*)0;
+
dim created this revision.
dim added reviewers: emaste, EricWF, mclow.lists.
Herald added subscribers: krytarowski, mgorny.
As noted in a discussion about testing the LLVM 6.0.0 release candidates
(with libc++) for FreeBSD, many tests turned out to fail with
"exception_ptr not yet implemented".
dim added a comment.
FWIW, this allows me to build wine again for x86_64, without any crashes or
assertions. So that looks good, in any case.
Repository:
rC Clang
https://reviews.llvm.org/D43016
___
cfe-commits mailing list
dim accepted this revision.
dim added a comment.
This revision is now accepted and ready to land.
LGTM, though a test case would be nice (could be added to
`tools/clang/test/Driver/freebsd.c`)
Repository:
rC Clang
https://reviews.llvm.org/D42972
This revision was automatically updated to reflect the committed changes.
Closed by commit rCXX321963: Add pre-C++11 is_constructible wrappers for 3
arguments (authored by dim, committed by ).
Changed prior to commit:
https://reviews.llvm.org/D41805?vs=128860=128873#toc
Repository:
rCXX
dim created this revision.
dim added reviewers: EricWF, mclow.lists.
Herald added a subscriber: krytarowski.
After https://reviews.llvm.org/rL319736 for https://reviews.llvm.org/D28253
(which fixes PR28929), gcc cannot compile `` anymore in pre-C+11 modes,
complaining:
In file included from
dim added a comment.
Actually, having thought about it a little more, if the warning is "rather
broken", or even "completely broken", depending on one's point of view, then
maybe it is better not have it under `-Wextra` either? E.g. somebody has to
ask for the warning specifically, using
dim accepted this revision.
dim added a comment.
This revision is now accepted and ready to land.
Yes, please. Rather sooner than later, the warning itself can be fixed
post-6.0.0.
Repository:
rC Clang
https://reviews.llvm.org/D41512
___
This revision was automatically updated to reflect the committed changes.
Closed by commit rC320755: Dont trigger -Wuser-defined-literals for
system headers (authored by dim, committed by ).
Changed prior to commit:
https://reviews.llvm.org/D41080?vs=126436=127029#toc
Repository:
rC Clang
dim updated this revision to Diff 126436.
dim added a comment.
Add a test case.
Repository:
rC Clang
https://reviews.llvm.org/D41080
Files:
lib/Sema/SemaDeclCXX.cpp
test/SemaCXX/no-warn-user-defined-literals-in-system-headers.cpp
dim abandoned this revision.
dim added a comment.
Abandoned in favor of https://reviews.llvm.org/D41080.
Repository:
rCXX libc++
https://reviews.llvm.org/D41064
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
dim created this revision.
In https://reviews.llvm.org/D41064, I proposed adding `#pragma clang diagnostic
ignored
"-Wuser-defined-literals"` to some of libc++'s headers, since these
warnings are now triggered by clang's new `-std=gnu++14` default:
$ cat test.cpp
#include
$ clang
dim updated this revision to Diff 126397.
dim added a comment.
Updated to also include and . I think all cases are
covered now.
Repository:
rCXX libc++
https://reviews.llvm.org/D41064
Files:
include/chrono
include/complex
include/string
include/string_view
Index:
dim created this revision.
When compiling and/or with -Wsystem-headers, in
C++14 or higher mode, clang produces warnings about the literal suffixes
defined in them, e.g.:
$ cat test.cpp
#include
$ clang -std=c++14 -Wsystem-headers -Wall -Wextra -c test.cpp
In file included from
dim accepted this revision.
dim added a comment.
This revision is now accepted and ready to land.
For the rest, LGTM. It fixes the segfault, for both the full original test
case, and my reduced version.
Comment at: lib/Sema/SemaLambda.cpp:1491
else
diag <<
dim added a comment.
In https://reviews.llvm.org/D33900#824172, @thakis wrote:
> dim: Does putting the target listing behind a different flag work for you?
> Which problem are you trying to solve here?
I'm fine with a different flag. For the problem I was trying to solve, see my
earlier
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:
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
This revision was automatically updated to reflect the committed changes.
Closed by commit rL304899: Only print registered targets for `--version`
(authored by dim).
Changed prior to commit:
https://reviews.llvm.org/D33981?vs=101690=101697#toc
Repository:
rL LLVM
dim created this revision.
In https://reviews.llvm.org/D33900, I added printing of the registered targets
in clang's
`PrintVersion` function, which is not only used for `--version` output,
but also for `-v` (verbose mode) and `-###`. Especially the latter
seems to trip up some test cases, so it
This revision was automatically updated to reflect the committed changes.
Closed by commit rL304837: Adjust SetVersionPrinter call for D33899 (authored
by dim).
Changed prior to commit:
https://reviews.llvm.org/D33959?vs=101623=101630#toc
Repository:
rL LLVM
https://reviews.llvm.org/D33959
dim created this revision.
In https://reviews.llvm.org/D33899, I'm adding a `raw_ostream &` parameter to
the function
objects passed to `cl::SetVersionPrinter`. Adjust the call in
clang-apply-replacements for this.
https://reviews.llvm.org/D33959
Files:
dim created this revision.
Other llvm tools display their registered targets when showing version
information, but for some reason clang has never done this.
To support this, https://reviews.llvm.org/D33899 adds the llvm parts, which
make it possible to
print version information to arbitrary
dim accepted this revision.
dim added a comment.
This revision is now accepted and ready to land.
LGTM, though it would be nice if we implemented gcc's extension for this at
some point... ;)
https://reviews.llvm.org/D30538
___
cfe-commits mailing
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
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:
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
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
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
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
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
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
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
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=85939#toc
Repository:
rL LLVM
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:
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
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
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
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
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:
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
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
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
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
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
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
===
---
dim added a comment.
Actually, according to
https://svnweb.freebsd.org/base?view=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, right?
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
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
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
===
---
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
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
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
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
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=83672#toc
Repository:
rL LLVM
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
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
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
101 - 180 of 180 matches
Mail list logo
