from:"Dimitry Andric via cfe\-commits"

[libcxx] r339794 - For FreeBSD, don't define _M in nasty_macros.hpp

2018-08-15 Thread Dimitry Andric via cfe-commits

Author: dim
Date: Wed Aug 15 10:30:32 2018
New Revision: 339794

URL: http://llvm.org/viewvc/llvm-project?rev=339794&view=rev
Log:
For FreeBSD, don't define _M in nasty_macros.hpp

Because FreeBSD uses _M in its , and it is hard to avoid
including that header, only define _M to NASTY_MACRO for other operating
systems.  This fixes almost 2000 unexpected test failures.

Discussed with Eric Fiselier.

Modified:
libcxx/trunk/test/support/nasty_macros.hpp

Modified: libcxx/trunk/test/support/nasty_macros.hpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/support/nasty_macros.hpp?rev=339794&r1=339793&r2=339794&view=diff
==
--- libcxx/trunk/test/support/nasty_macros.hpp (original)
+++ libcxx/trunk/test/support/nasty_macros.hpp Wed Aug 15 10:30:32 2018
@@ -22,7 +22,11 @@
 #define _J NASTY_MACRO
 #define _K NASTY_MACRO
 #define _L NASTY_MACRO
+// Because FreeBSD uses _M in its , and it is hard to avoid
+// including that header, only define _M for other operating systems.
+#ifndef __FreeBSD__
 #define _M NASTY_MACRO
+#endif
 #define _N NASTY_MACRO
 #define _O NASTY_MACRO
 #define _P NASTY_MACRO


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libcxx] r324855 - Add default C++ ABI libname and include paths for FreeBSD

2018-02-11 Thread Dimitry Andric via cfe-commits

Author: dim
Date: Sun Feb 11 14:31:05 2018
New Revision: 324855

URL: http://llvm.org/viewvc/llvm-project?rev=324855&view=rev
Log:
Add default C++ ABI libname and include paths for FreeBSD

Summary:
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".  This was because libc++ did not
choose the correct C++ ABI library, and therefore it fell back to the
`exception_fallback.ipp` header.

Since FreeBSD 10.x, we have been using libcxxrt as our C++ ABI library,
and its headers have always been installed in /usr/include/c++/v1,
together with the (system) libc++ headers.  (Older versions of FreeBSD
used GNU libsupc++ by default, but these are now unsupported.)

Therefore, if we are building libc++ for FreeBSD, set:
* `LIBCXX_CXX_ABI_LIBNAME` to "libcxxrt"
* `LIBCXX_CXX_ABI_INCLUDE_PATHS` to "/usr/include/c++/v1"
by default.

Reviewers: emaste, EricWF, mclow.lists

Reviewed By: EricWF

Subscribers: mgorny, cfe-commits, krytarowski

Differential Revision: https://reviews.llvm.org/D43166

Modified:
libcxx/trunk/CMakeLists.txt

Modified: libcxx/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.txt?rev=324855&r1=324854&r2=324855&view=diff
==
--- libcxx/trunk/CMakeLists.txt (original)
+++ libcxx/trunk/CMakeLists.txt Sun Feb 11 14:31:05 2018
@@ -136,6 +136,9 @@ if (LIBCXX_CXX_ABI STREQUAL "default")
   elseif (APPLE)
 set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
 set(LIBCXX_CXX_ABI_SYSTEM 1)
+  elseif (${CMAKE_SYSTEM_NAME} MATCHES "FreeBSD")
+set(LIBCXX_CXX_ABI_LIBNAME "libcxxrt")
+set(LIBCXX_CXX_ABI_INCLUDE_PATHS "/usr/include/c++/v1")
   else()
 set(LIBCXX_CXX_ABI_LIBNAME "default")
   endif()


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libcxx] r325027 - Put type attributes after class keyword

2018-02-13 Thread Dimitry Andric via cfe-commits

Author: dim
Date: Tue Feb 13 09:40:59 2018
New Revision: 325027

URL: http://llvm.org/viewvc/llvm-project?rev=325027&view=rev
Log:
Put type attributes after class keyword

Summary:
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
^
__config:701:46: note: expanded from macro '_LIBCPP_TYPE_VIS'
#define _LIBCPP_TYPE_VIS __attribute__ ((__visibility__("default")))
 ^
1 warning generated.
```

Fix it by putting the attribute after the `class` keyword.

Reviewers: EricWF, mclow.lists

Reviewed By: EricWF

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D43209

Modified:
libcxx/trunk/include/functional

Modified: libcxx/trunk/include/functional
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/functional?rev=325027&r1=325026&r2=325027&view=diff
==
--- libcxx/trunk/include/functional (original)
+++ libcxx/trunk/include/functional Tue Feb 13 09:40:59 2018
@@ -2497,8 +2497,7 @@ __search(_RandomAccessIterator1 __first1
 
 // default searcher
 template>
-_LIBCPP_TYPE_VIS
-class default_searcher {
+class _LIBCPP_TYPE_VIS default_searcher {
 public:
 _LIBCPP_INLINE_VISIBILITY
 default_searcher(_ForwardIterator __f, _ForwardIterator __l, 


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libcxx] r325028 - Make the ctype_byname::widen test cases pass on FreeBSD.

2018-02-13 Thread Dimitry Andric via cfe-commits

Author: dim
Date: Tue Feb 13 09:43:24 2018
New Revision: 325028

URL: http://llvm.org/viewvc/llvm-project?rev=325028&view=rev
Log:
Make the ctype_byname::widen test cases pass on FreeBSD.

Modified:

libcxx/trunk/test/std/localization/locale.categories/category.ctype/locale.ctype.byname/widen_1.pass.cpp

libcxx/trunk/test/std/localization/locale.categories/category.ctype/locale.ctype.byname/widen_many.pass.cpp

Modified: 
libcxx/trunk/test/std/localization/locale.categories/category.ctype/locale.ctype.byname/widen_1.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/localization/locale.categories/category.ctype/locale.ctype.byname/widen_1.pass.cpp?rev=325028&r1=325027&r2=325028&view=diff
==
--- 
libcxx/trunk/test/std/localization/locale.categories/category.ctype/locale.ctype.byname/widen_1.pass.cpp
 (original)
+++ 
libcxx/trunk/test/std/localization/locale.categories/category.ctype/locale.ctype.byname/widen_1.pass.cpp
 Tue Feb 13 09:43:24 2018
@@ -55,7 +55,7 @@ int main()
 assert(f.widen('.') == L'.');
 assert(f.widen('a') == L'a');
 assert(f.widen('1') == L'1');
-#ifdef __APPLE__
+#if defined(__APPLE__) || defined(__FreeBSD__)
 assert(f.widen(char(-5)) == L'\u00fb');
 #else
 assert(f.widen(char(-5)) == wchar_t(-1));

Modified: 
libcxx/trunk/test/std/localization/locale.categories/category.ctype/locale.ctype.byname/widen_many.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/localization/locale.categories/category.ctype/locale.ctype.byname/widen_many.pass.cpp?rev=325028&r1=325027&r2=325028&view=diff
==
--- 
libcxx/trunk/test/std/localization/locale.categories/category.ctype/locale.ctype.byname/widen_many.pass.cpp
 (original)
+++ 
libcxx/trunk/test/std/localization/locale.categories/category.ctype/locale.ctype.byname/widen_many.pass.cpp
 Tue Feb 13 09:43:24 2018
@@ -61,7 +61,7 @@ int main()
 assert(v[3] == L'.');
 assert(v[4] == L'a');
 assert(v[5] == L'1');
-#ifdef __APPLE__
+#if defined(__APPLE__) || defined(__FreeBSD__)
 assert(v[6] == L'\x85');
 #else
 assert(v[6] == wchar_t(-1));


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D43394: [X86] Add 'sahf' CPU feature, and emit LAHFSAHF for it

2018-02-16 Thread Dimitry Andric via cfe-commits

On 17 Feb 2018, at 00:12, Craig Topper via Phabricator 
 wrote:
> 
> craig.topper added inline comments.
> 
> 
> 
> Comment at: lib/Basic/Targets/X86.cpp:1049
> 
> +  if (HasLAHFSAHF)
> +Builder.defineMacro("__LAHFSAHF__");
> 
> dim wrote:
>> craig.topper wrote:
>>> Does gcc define this? It's such a low level instruction I have a hard time 
>>> believing this define would be useful.
>> I tried gcc 6, 7 and 8, and while they do expose stuff like `__POPCNT__`, I 
>> see no `__LAHFSAHF__`.  I am supposing Jonathan's original intent with this 
>> was to make it easily testable in source, so you can insert the right 
>> assembly for the target CPU.  The same could really be said for things like 
>> `__RDSEED__`, and some other defines...
> Most of the defines indicate the availability of intrinsics. At least that 
> was their original intent. They used to control what intrinsic header were 
> included in x86intrin.h or immintrin.h. Though now we include everything 
> except in MSVC compatible mode and allow the target attribute to provide per 
> function control.
> 
> I'd prefer not to add this one if gcc doesn't have it.

Jonathan, can you comment on your reasons for adding the __LAHFSAHF__ define?  
Was this just a nice-to-have, or do you require it for something related to 
https://bugs.llvm.org/show_bug.cgi?id=36028 ?

> 
> 
> Repository:
>  rC Clang
> 
> https://reviews.llvm.org/D43394

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r325446 - [X86] Add 'sahf' CPU feature to frontend

2018-02-17 Thread Dimitry Andric via cfe-commits

Author: dim
Date: Sat Feb 17 13:04:35 2018
New Revision: 325446

URL: http://llvm.org/viewvc/llvm-project?rev=325446&view=rev
Log:
[X86] Add 'sahf' CPU feature to frontend

Summary:
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 submitted in bug 36037 by Jonathan Looney
.

As described there, GCC also uses `-msahf` for this feature, and the
backend already recognizes the `+sahf` feature. All that is needed is to
teach clang to pass this on to the backend.

The mapping of feature support onto CPUs may not be complete; rather, it
was chosen to match LLVM's idea of which CPUs support this feature (see
lib/Target/X86/X86.td).

I also updated the affected test case (CodeGen/attr-target-x86.c) to
match the emitted output.

Reviewers: craig.topper, coby, efriedma, rsmith

Reviewed By: craig.topper

Subscribers: emaste, cfe-commits

Differential Revision: https://reviews.llvm.org/D43394

Modified:
cfe/trunk/include/clang/Driver/Options.td
cfe/trunk/lib/Basic/Targets/X86.cpp
cfe/trunk/lib/Basic/Targets/X86.h
cfe/trunk/test/CodeGen/attr-target-x86.c

Modified: cfe/trunk/include/clang/Driver/Options.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=325446&r1=325445&r2=325446&view=diff
==
--- cfe/trunk/include/clang/Driver/Options.td (original)
+++ cfe/trunk/include/clang/Driver/Options.td Sat Feb 17 13:04:35 2018
@@ -2591,6 +2591,8 @@ def mrtm : Flag<["-"], "mrtm">, Group, Group;
 def mrdseed : Flag<["-"], "mrdseed">, Group;
 def mno_rdseed : Flag<["-"], "mno-rdseed">, Group;
+def msahf : Flag<["-"], "msahf">, Group;
+def mno_sahf : Flag<["-"], "mno-sahf">, Group;
 def msgx : Flag<["-"], "msgx">, Group;
 def mno_sgx : Flag<["-"], "mno-sgx">, Group;
 def msha : Flag<["-"], "msha">, Group;

Modified: cfe/trunk/lib/Basic/Targets/X86.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets/X86.cpp?rev=325446&r1=325445&r2=325446&view=diff
==
--- cfe/trunk/lib/Basic/Targets/X86.cpp (original)
+++ cfe/trunk/lib/Basic/Targets/X86.cpp Sat Feb 17 13:04:35 2018
@@ -220,6 +220,7 @@ bool X86TargetInfo::initFeatureMap(
 LLVM_FALLTHROUGH;
   case CK_Core2:
 setFeatureEnabledImpl(Features, "ssse3", true);
+setFeatureEnabledImpl(Features, "sahf", true);
 LLVM_FALLTHROUGH;
   case CK_Yonah:
   case CK_Prescott:
@@ -261,6 +262,7 @@ bool X86TargetInfo::initFeatureMap(
 setFeatureEnabledImpl(Features, "ssse3", true);
 setFeatureEnabledImpl(Features, "fxsr", true);
 setFeatureEnabledImpl(Features, "cx16", true);
+setFeatureEnabledImpl(Features, "sahf", true);
 break;
 
   case CK_KNM:
@@ -291,6 +293,7 @@ bool X86TargetInfo::initFeatureMap(
 setFeatureEnabledImpl(Features, "xsaveopt", true);
 setFeatureEnabledImpl(Features, "xsave", true);
 setFeatureEnabledImpl(Features, "movbe", true);
+setFeatureEnabledImpl(Features, "sahf", true);
 break;
 
   case CK_K6_2:
@@ -304,6 +307,7 @@ bool X86TargetInfo::initFeatureMap(
 setFeatureEnabledImpl(Features, "sse4a", true);
 setFeatureEnabledImpl(Features, "lzcnt", true);
 setFeatureEnabledImpl(Features, "popcnt", true);
+setFeatureEnabledImpl(Features, "sahf", true);
 LLVM_FALLTHROUGH;
   case CK_K8SSE3:
 setFeatureEnabledImpl(Features, "sse3", true);
@@ -337,6 +341,7 @@ bool X86TargetInfo::initFeatureMap(
 setFeatureEnabledImpl(Features, "prfchw", true);
 setFeatureEnabledImpl(Features, "cx16", true);
 setFeatureEnabledImpl(Features, "fxsr", true);
+setFeatureEnabledImpl(Features, "sahf", true);
 break;
 
   case CK_ZNVER1:
@@ -360,6 +365,7 @@ bool X86TargetInfo::initFeatureMap(
 setFeatureEnabledImpl(Features, "prfchw", true);
 setFeatureEnabledImpl(Features, "rdrnd", true);
 setFeatureEnabledImpl(Features, "rdseed", true);
+setFeatureEnabledImpl(Features, "sahf", true);
 setFeatureEnabledImpl(Features, "sha", true);
 setFeatureEnabledImpl(Features, "sse4a", true);
 setFeatureEnabledImpl(Features, "xsave", true);
@@ -394,6 +400,7 @@ bool X86TargetInfo::initFeatureMap(
 setFeatureEnabledImpl(Features, "cx16", true);
 setFeatureEnabledImpl(Features, "fxsr", true);
 setFeatureEnabledImpl(Features, "xsave", true);
+setFeatureEnabledImpl(Features, "sahf", true);
 break;
   }
   if (!TargetInfo::initFeatureMap(Features, Diags, CPU, FeaturesVec))
@@ -792,6 +799,8 @@ bool X86TargetInfo::handleTargetFeatures
   HasRetpoline = true;
 } else if (Feature == "+retpoline-external-thunk") {
   HasRetpolineExternalThunk = true;
+} else if (Feature == "+sahf") {
+  HasLAHFSAHF = true;
 }
 
 X86SSEEnum Level = llvm::StringSwitch(Feature)
@@ -1269,6 +1278,7 @@

r304836 - Print registered targets in clang's version information

2017-06-06 Thread Dimitry Andric via cfe-commits

Author: dim
Date: Tue Jun  6 16:54:21 2017
New Revision: 304836

URL: http://llvm.org/viewvc/llvm-project?rev=304836&view=rev
Log:
Print registered targets in clang's version information

Summary:
Other llvm tools display their registered targets when showing version
information, but for some reason clang has never done this.

To support this, D33899 adds the llvm parts, which make it possible to
print version information to arbitrary raw_ostreams.  This change adds
a call to printRegisteredTargetsForVersion in clang's PrintVersion, and
adds a raw_ostream parameter to two other PrintVersion functions.

Reviewers: beanz, chandlerc, dberris, mehdi_amini, zturner

Reviewed By: mehdi_amini

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D33900

Modified:
cfe/trunk/lib/Driver/Driver.cpp
cfe/trunk/tools/clang-format/ClangFormat.cpp
cfe/trunk/tools/clang-offload-bundler/ClangOffloadBundler.cpp

Modified: cfe/trunk/lib/Driver/Driver.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Driver.cpp?rev=304836&r1=304835&r2=304836&view=diff
==
--- cfe/trunk/lib/Driver/Driver.cpp (original)
+++ cfe/trunk/lib/Driver/Driver.cpp Tue Jun  6 16:54:21 2017
@@ -68,6 +68,7 @@
 #include "llvm/Support/PrettyStackTrace.h"
 #include "llvm/Support/Process.h"
 #include "llvm/Support/Program.h"
+#include "llvm/Support/TargetRegistry.h"
 #include "llvm/Support/raw_ostream.h"
 #include 
 #include 
@@ -1116,6 +1117,10 @@ void Driver::PrintVersion(const Compilat
 
   // Print out the install directory.
   OS << "InstalledDir: " << InstalledDir << '\n';
+
+  // Print registered targets.
+  OS << '\n';
+  llvm::TargetRegistry::printRegisteredTargetsForVersion(OS);
 }
 
 /// PrintDiagnosticCategories - Implement the --print-diagnostic-categories

Modified: cfe/trunk/tools/clang-format/ClangFormat.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/clang-format/ClangFormat.cpp?rev=304836&r1=304835&r2=304836&view=diff
==
--- cfe/trunk/tools/clang-format/ClangFormat.cpp (original)
+++ cfe/trunk/tools/clang-format/ClangFormat.cpp Tue Jun  6 16:54:21 2017
@@ -328,8 +328,7 @@ static bool format(StringRef FileName) {
 }  // namespace format
 }  // namespace clang
 
-static void PrintVersion() {
-  raw_ostream &OS = outs();
+static void PrintVersion(raw_ostream &OS) {
   OS << clang::getClangToolFullVersion("clang-format") << '\n';
 }
 

Modified: cfe/trunk/tools/clang-offload-bundler/ClangOffloadBundler.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/clang-offload-bundler/ClangOffloadBundler.cpp?rev=304836&r1=304835&r2=304836&view=diff
==
--- cfe/trunk/tools/clang-offload-bundler/ClangOffloadBundler.cpp (original)
+++ cfe/trunk/tools/clang-offload-bundler/ClangOffloadBundler.cpp Tue Jun  6 
16:54:21 2017
@@ -915,8 +915,7 @@ static bool UnbundleFiles() {
   return false;
 }
 
-static void PrintVersion() {
-  raw_ostream &OS = outs();
+static void PrintVersion(raw_ostream &OS) {
   OS << clang::getClangToolFullVersion("clang-offload-bundler") << '\n';
 }
 


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] r304837 - Adjust SetVersionPrinter call for D33899

2017-06-06 Thread Dimitry Andric via cfe-commits

Author: dim
Date: Tue Jun  6 16:54:45 2017
New Revision: 304837

URL: http://llvm.org/viewvc/llvm-project?rev=304837&view=rev
Log:
Adjust SetVersionPrinter call for D33899

Summary:
In 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.

Reviewers: klimek, alexfh

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D33959

Modified:

clang-tools-extra/trunk/clang-apply-replacements/tool/ClangApplyReplacementsMain.cpp

Modified: 
clang-tools-extra/trunk/clang-apply-replacements/tool/ClangApplyReplacementsMain.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-apply-replacements/tool/ClangApplyReplacementsMain.cpp?rev=304837&r1=304836&r2=304837&view=diff
==
--- 
clang-tools-extra/trunk/clang-apply-replacements/tool/ClangApplyReplacementsMain.cpp
 (original)
+++ 
clang-tools-extra/trunk/clang-apply-replacements/tool/ClangApplyReplacementsMain.cpp
 Tue Jun  6 16:54:45 2017
@@ -82,8 +82,8 @@ private:
 };
 } // namespace
 
-static void printVersion() {
-  outs() << "clang-apply-replacements version " CLANG_VERSION_STRING << "\n";
+static void printVersion(raw_ostream &OS) {
+  OS << "clang-apply-replacements version " CLANG_VERSION_STRING << "\n";
 }
 
 /// \brief Convenience function to get rewritten content for \c Filename from
@@ -199,7 +199,7 @@ applyFormatting(const std::vector DiagOpts(new DiagnosticOptions());


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r304899 - Only print registered targets for `--version`

2017-06-07 Thread Dimitry Andric via cfe-commits

Author: dim
Date: Wed Jun  7 07:05:41 2017
New Revision: 304899

URL: http://llvm.org/viewvc/llvm-project?rev=304899&view=rev
Log:
Only print registered targets for `--version`

Summary:
In 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 is probably better to only print
the registered targets for `--version`.

Reviewers: nemanjai, mehdi_amini

Reviewed By: nemanjai

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D33981

Modified:
cfe/trunk/lib/Driver/Driver.cpp

Modified: cfe/trunk/lib/Driver/Driver.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Driver.cpp?rev=304899&r1=304898&r2=304899&view=diff
==
--- cfe/trunk/lib/Driver/Driver.cpp (original)
+++ cfe/trunk/lib/Driver/Driver.cpp Wed Jun  7 07:05:41 2017
@@ -1117,10 +1117,6 @@ void Driver::PrintVersion(const Compilat
 
   // Print out the install directory.
   OS << "InstalledDir: " << InstalledDir << '\n';
-
-  // Print registered targets.
-  OS << '\n';
-  llvm::TargetRegistry::printRegisteredTargetsForVersion(OS);
 }
 
 /// PrintDiagnosticCategories - Implement the --print-diagnostic-categories
@@ -1166,6 +1162,10 @@ bool Driver::HandleImmediateArgs(const C
   if (C.getArgs().hasArg(options::OPT__version)) {
 // Follow gcc behavior and use stdout for --version and stderr for -v.
 PrintVersion(C, llvm::outs());
+
+// Print registered targets.
+llvm::outs() << '\n';
+llvm::TargetRegistry::printRegisteredTargetsForVersion(llvm::outs());
 return false;
   }
 


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r320755 - Don't trigger -Wuser-defined-literals for system headers

2017-12-14 Thread Dimitry Andric via cfe-commits

Author: dim
Date: Thu Dec 14 14:32:24 2017
New Revision: 320755

URL: http://llvm.org/viewvc/llvm-project?rev=320755&view=rev
Log:
Don't trigger -Wuser-defined-literals for system headers

Summary:
In 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 -std=c++14 -Wsystem-headers -Wall -Wextra -c test.cpp
In file included from test.cpp:1:
In file included from /usr/include/c++/v1/string:470:
/usr/include/c++/v1/string_view:763:29: warning: user-defined literal suffixes 
not starting with '_' are reserved [-Wuser-defined-literals]
basic_string_view operator "" sv(const char *__str, size_t __len)
^
/usr/include/c++/v1/string_view:769:32: warning: user-defined literal suffixes 
not starting with '_' are reserved [-Wuser-defined-literals]
basic_string_view operator "" sv(const wchar_t *__str, size_t 
__len)
   ^
/usr/include/c++/v1/string_view:775:33: warning: user-defined literal suffixes 
not starting with '_' are reserved [-Wuser-defined-literals]
basic_string_view operator "" sv(const char16_t *__str, size_t 
__len)
^
/usr/include/c++/v1/string_view:781:33: warning: user-defined literal suffixes 
not starting with '_' are reserved [-Wuser-defined-literals]
basic_string_view operator "" sv(const char32_t *__str, size_t 
__len)
^
In file included from test.cpp:1:
/usr/include/c++/v1/string:4012:24: warning: user-defined literal suffixes not 
starting with '_' are reserved [-Wuser-defined-literals]
basic_string operator "" s( const char *__str, size_t __len )
   ^
/usr/include/c++/v1/string:4018:27: warning: user-defined literal suffixes not 
starting with '_' are reserved [-Wuser-defined-literals]
basic_string operator "" s( const wchar_t *__str, size_t __len )
  ^
/usr/include/c++/v1/string:4024:28: warning: user-defined literal suffixes not 
starting with '_' are reserved [-Wuser-defined-literals]
basic_string operator "" s( const char16_t *__str, size_t __len )
   ^
/usr/include/c++/v1/string:4030:28: warning: user-defined literal suffixes not 
starting with '_' are reserved [-Wuser-defined-literals]
basic_string operator "" s( const char32_t *__str, size_t __len )
   ^
8 warnings generated.
```

Both @aaron.ballman and @mclow.lists felt that adding this workaround to
the libc++ headers was the wrong way, and it should be fixed in clang
instead.

Here is a proposal to do just that.  I verified that this suppresses the
warning, even when -Wsystem-headers is used, and that the warning is
still emitted for a declaration outside of system headers.

Reviewers: aaron.ballman, mclow.lists, rsmith

Reviewed By: aaron.ballman

Subscribers: mclow.lists, aaron.ballman, andrew, emaste, cfe-commits

Differential Revision: https://reviews.llvm.org/D41080

Added:
cfe/trunk/test/SemaCXX/no-warn-user-defined-literals-in-system-headers.cpp
cfe/trunk/test/SemaCXX/no-warn-user-defined-literals-in-system-headers.h
Modified:
cfe/trunk/lib/Sema/SemaDeclCXX.cpp

Modified: cfe/trunk/lib/Sema/SemaDeclCXX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclCXX.cpp?rev=320755&r1=320754&r2=320755&view=diff
==
--- cfe/trunk/lib/Sema/SemaDeclCXX.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDeclCXX.cpp Thu Dec 14 14:32:24 2017
@@ -13076,7 +13076,8 @@ bool Sema::CheckLiteralOperatorDeclarati
 
   StringRef LiteralName
 = FnDecl->getDeclName().getCXXLiteralIdentifier()->getName();
-  if (LiteralName[0] != '_') {
+  if (LiteralName[0] != '_' &&
+  !getSourceManager().isInSystemHeader(FnDecl->getLocation())) {
 // C++11 [usrlit.suffix]p1:
 //   Literal suffix identifiers that do not start with an underscore
 //   are reserved for future standardization.

Added: 
cfe/trunk/test/SemaCXX/no-warn-user-defined-literals-in-system-headers.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/no-warn-user-defined-literals-in-system-headers.cpp?rev=320755&view=auto
==
--- cfe/trunk/test/SemaCXX/no-warn-user-defined-literals-in-system-headers.cpp 
(added)
+++ cfe/trunk/test/SemaCXX/no-warn-user-defined-literals-in-system-headers.cpp 
Thu Dec 14 14:32:24 2017
@@ -0,0 +1,5 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c++11 -Wsystem-headers -isystem 
%S %s
+
+#include 
+
+void operator "" bar(long double); // expected-warning{{user-defined literal 
suffixes not starting with '_' are reserved}}

Added: cfe/trunk/test/SemaCXX/no-warn-user-defined-literals-in-system-headers.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/

[clang-tools-extra] r321016 - Fix more inconsistent line endings. NFC.

2017-12-18 Thread Dimitry Andric via cfe-commits

Author: dim
Date: Mon Dec 18 11:46:56 2017
New Revision: 321016

URL: http://llvm.org/viewvc/llvm-project?rev=321016&view=rev
Log:
Fix more inconsistent line endings. NFC.

Modified:
clang-tools-extra/trunk/docs/modularize.rst
clang-tools-extra/trunk/docs/pp-trace.rst

Modified: clang-tools-extra/trunk/docs/modularize.rst
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/docs/modularize.rst?rev=321016&r1=321015&r2=321016&view=diff
==
--- clang-tools-extra/trunk/docs/modularize.rst (original)
+++ clang-tools-extra/trunk/docs/modularize.rst Mon Dec 18 11:46:56 2017
@@ -172,40 +172,40 @@ For example, for the header list::
 
 The following module map will be generated::
 
-  // Output/NoProblemsAssistant.txt
+  // Output/NoProblemsAssistant.txt
   // Generated by: modularize -module-map-path=Output/NoProblemsAssistant.txt \
-   -root-module=Root NoProblemsAssistant.modularize
-  
-  module SomeTypes {
-header "SomeTypes.h"
-export *
-  }
-  module SomeDecls {
-header "SomeDecls.h"
-export *
-  }
-  module SubModule1 {
-module Header1 {
-  header "SubModule1/Header1.h"
-  export *
-}
-module Header2 {
-  header "SubModule1/Header2.h"
-  export *
-}
-  }
-  module SubModule2 {
-module Header3 {
-  header "SubModule2/Header3.h"
-  export *
-}
-module Header4 {
-  header "SubModule2/Header4.h"
-  export *
-}
-header "SubModule2.h"
-export *
-  }
+   -root-module=Root NoProblemsAssistant.modularize
+  
+  module SomeTypes {
+header "SomeTypes.h"
+export *
+  }
+  module SomeDecls {
+header "SomeDecls.h"
+export *
+  }
+  module SubModule1 {
+module Header1 {
+  header "SubModule1/Header1.h"
+  export *
+}
+module Header2 {
+  header "SubModule1/Header2.h"
+  export *
+}
+  }
+  module SubModule2 {
+module Header3 {
+  header "SubModule2/Header3.h"
+  export *
+}
+module Header4 {
+  header "SubModule2/Header4.h"
+  export *
+}
+header "SubModule2.h"
+export *
+  }
 
 An optional ``-root-module=`` option can be used to cause a root 
module
 to be created which encloses all the modules.
@@ -216,50 +216,50 @@ problem headers can be fixed.
 
 For example, with the same header list from above::
 
-  // Output/NoProblemsAssistant.txt
+  // Output/NoProblemsAssistant.txt
   // Generated by: modularize -module-map-path=Output/NoProblemsAssistant.txt \
-   -root-module=Root NoProblemsAssistant.modularize
-  
-  module Root {
-module SomeTypes {
-  header "SomeTypes.h"
-  export *
-}
-module SomeDecls {
-  header "SomeDecls.h"
-  export *
-}
-module SubModule1 {
-  module Header1 {
-header "SubModule1/Header1.h"
-export *
-  }
-  module Header2 {
-header "SubModule1/Header2.h"
-export *
-  }
-}
-module SubModule2 {
-  module Header3 {
-header "SubModule2/Header3.h"
-export *
-  }
-  module Header4 {
-header "SubModule2/Header4.h"
-export *
-  }
-  header "SubModule2.h"
-  export *
-}
-  }
-
-Note that headers with dependents will be ignored with a warning, as the
-Clang module mechanism doesn't support headers the rely on other headers
-to be included first.
-
-The module map format defines some keywords which can't be used in module
-names. If a header has one of these names, an underscore ('_') will be
+   -root-module=Root NoProblemsAssistant.modularize
+  
+  module Root {
+module SomeTypes {
+  header "SomeTypes.h"
+  export *
+}
+module SomeDecls {
+  header "SomeDecls.h"
+  export *
+}
+module SubModule1 {
+  module Header1 {
+header "SubModule1/Header1.h"
+export *
+  }
+  module Header2 {
+header "SubModule1/Header2.h"
+export *
+  }
+}
+module SubModule2 {
+  module Header3 {
+header "SubModule2/Header3.h"
+export *
+  }
+  module Header4 {
+header "SubModule2/Header4.h"
+export *
+  }
+  header "SubModule2.h"
+  export *
+}
+  }
+
+Note that headers with dependents will be ignored with a warning, as the
+Clang module mechanism doesn't support headers the rely on other headers
+to be included first.
+
+The module map format defines some keywords which can't be used in module
+names. If a header has one of these names, an underscore ('_') will be
 prepended to the name. For example, if the header name is ``header.h``,
 because ``header`` is a keyword, the module name will be ``_header``.
 For a list of the module map keywords, please see:
-`Lexical structure 
`_
+`Lexical structure 
`_

Modified: clang-tools-extra/t

r321016 - Fix more inconsistent line endings. NFC.

2017-12-18 Thread Dimitry Andric via cfe-commits

Author: dim
Date: Mon Dec 18 11:46:56 2017
New Revision: 321016

URL: http://llvm.org/viewvc/llvm-project?rev=321016&view=rev
Log:
Fix more inconsistent line endings. NFC.

Modified:
cfe/trunk/include/clang/AST/OperationKinds.def
cfe/trunk/lib/Parse/ParseTemplate.cpp
cfe/trunk/www/cxx_dr_status.html

Modified: cfe/trunk/include/clang/AST/OperationKinds.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/OperationKinds.def?rev=321016&r1=321015&r2=321016&view=diff
==
--- cfe/trunk/include/clang/AST/OperationKinds.def (original)
+++ cfe/trunk/include/clang/AST/OperationKinds.def Mon Dec 18 11:46:56 2017
@@ -327,7 +327,7 @@ CAST_OPERATION(ZeroToOCLQueue)
 // Convert a pointer to a different address space.
 CAST_OPERATION(AddressSpaceConversion)
 
-// Convert an integer initializer to an OpenCL sampler.
+// Convert an integer initializer to an OpenCL sampler.
 CAST_OPERATION(IntToOCLSampler)
 
 //===- Binary Operations  
-===//

Modified: cfe/trunk/lib/Parse/ParseTemplate.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Parse/ParseTemplate.cpp?rev=321016&r1=321015&r2=321016&view=diff
==
--- cfe/trunk/lib/Parse/ParseTemplate.cpp (original)
+++ cfe/trunk/lib/Parse/ParseTemplate.cpp Mon Dec 18 11:46:56 2017
@@ -1024,8 +1024,8 @@ bool Parser::AnnotateTemplateIdToken(Tem
 ? OO_None
 : TemplateName.OperatorFunctionId.Operator;
 
-TemplateIdAnnotation *TemplateId = TemplateIdAnnotation::Create(
-  SS, TemplateKWLoc, TemplateNameLoc, TemplateII, OpKind, Template, TNK,
+TemplateIdAnnotation *TemplateId = TemplateIdAnnotation::Create(
+  SS, TemplateKWLoc, TemplateNameLoc, TemplateII, OpKind, Template, TNK,
   LAngleLoc, RAngleLoc, TemplateArgs, TemplateIds);
 
 Tok.setAnnotationValue(TemplateId);

Modified: cfe/trunk/www/cxx_dr_status.html
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/www/cxx_dr_status.html?rev=321016&r1=321015&r2=321016&view=diff
==
--- cfe/trunk/www/cxx_dr_status.html (original)
+++ cfe/trunk/www/cxx_dr_status.html Mon Dec 18 11:46:56 2017
@@ -1292,7 +1292,7 @@
   
 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#209";>209
 NAD
-Must friend declaration names be
+Must friend declaration names be
 accessible?
 Yes
   
@@ -1653,7 +1653,7 @@ accessible?
   
 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#269";>269
 NAD
-Order of initialization of multiply-defined static data members
+Order of initialization of multiply-defined static data members
 of class templates
 N/A
   
@@ -3268,8 +3268,8 @@ of class templates
   
 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#538";>538
 CD1
-Definition and usage
-of structure, POD-struct, POD-union,
+Definition and usage
+of structure, POD-struct, POD-union,
 and POD class
 N/A
   


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r319736 - Land D28253 which fixes PR28929 (which we mistakenly marked as fixed before)

2018-01-06 Thread Dimitry Andric via cfe-commits

On 5 Dec 2017, at 05:09, Marshall Clow via cfe-commits 
 wrote:
> 
> Author: marshall
> Date: Mon Dec  4 20:09:49 2017
> New Revision: 319736
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=319736&view=rev
> Log:
> Land D28253 which fixes PR28929 (which we mistakenly marked as fixed before)
...
> --- libcxx/trunk/include/memory (original)
> +++ libcxx/trunk/include/memory Mon Dec  4 20:09:49 2017
...
> @@ -4357,6 +4362,7 @@ template shared_ptr<_Tp>
> shared_ptr<_Tp>::make_shared(_A0& __a0, _A1& __a1, _A2& __a2)
> {
> +static_assert((is_constructible<_Tp, _A0, _A1, _A2>::value), "Can't 
> construct object in make_shared" );
> typedef __shared_ptr_emplace<_Tp, allocator<_Tp> > _CntrlBlk;
> typedef allocator<_CntrlBlk> _Alloc2;
> typedef __allocator_destructor<_Alloc2> _D2;

This commit causes g++ to no longer be able to compile  in pre-C++11 
mode, giving errors in the static assertions, like the following:

$ g++7 -nostdinc++ -isystem /share/dim/src/libcxx/trunk/include -std=c++03 -c 
test.cpp
In file included from /share/dim/src/libcxx/trunk/include/memory:648:0,
 from test.cpp:1:
/share/dim/src/libcxx/trunk/include/memory: In static member function 'static 
std::__1::shared_ptr<_Tp> std::__1::shared_ptr<_Tp>::make_shared(_A0&, _A1&, 
_A2&)':
/share/dim/src/libcxx/trunk/include/memory:4365:5: error: wrong number of 
template arguments (4, should be at least 1)
 static_assert((is_constructible<_Tp, _A0, _A1, _A2>::value), "Can't 
construct object in make_shared" );
 ^
In file included from /share/dim/src/libcxx/trunk/include/memory:649:0,
 from test.cpp:1:
/share/dim/src/libcxx/trunk/include/type_traits:3193:29: note: provided for 
'template struct std::__1::is_constructible'
 struct _LIBCPP_TEMPLATE_VIS is_constructible
 ^~~~
In file included from /share/dim/src/libcxx/trunk/include/memory:648:0,
 from test.cpp:1:
/share/dim/src/libcxx/trunk/include/memory:4365:5: error: template argument 1 
is invalid
 static_assert((is_constructible<_Tp, _A0, _A1, _A2>::value), "Can't 
construct object in make_shared" );
 ^
/share/dim/src/libcxx/trunk/include/memory: In static member function 'static 
std::__1::shared_ptr<_Tp> std::__1::shared_ptr<_Tp>::allocate_shared(const 
_Alloc&, _A0&, _A1&, _A2&)':
/share/dim/src/libcxx/trunk/include/memory::5: error: wrong number of 
template arguments (4, should be at least 1)
 static_assert((is_constructible<_Tp, _A0, _A1, _A2>::value), "Can't 
construct object in allocate_shared" );
 ^
In file included from /share/dim/src/libcxx/trunk/include/memory:649:0,
 from test.cpp:1:
/share/dim/src/libcxx/trunk/include/type_traits:3193:29: note: provided for 
'template struct std::__1::is_constructible'
 struct _LIBCPP_TEMPLATE_VIS is_constructible
 ^~~~
In file included from /share/dim/src/libcxx/trunk/include/memory:648:0,
 from test.cpp:1:
/share/dim/src/libcxx/trunk/include/memory::5: error: template argument 1 
is invalid
 static_assert((is_constructible<_Tp, _A0, _A1, _A2>::value), "Can't 
construct object in allocate_shared" );
 ^

It could be a gcc problem, since clang does not complain about it, but hints on 
how to solve it would be welcome.

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libcxx] r321963 - Add pre-C++11 is_constructible wrappers for 3 arguments

2018-01-07 Thread Dimitry Andric via cfe-commits

Author: dim
Date: Sun Jan  7 08:45:11 2018
New Revision: 321963

URL: http://llvm.org/viewvc/llvm-project?rev=321963&view=rev
Log:
Add pre-C++11 is_constructible wrappers for 3 arguments

Summary:
After rL319736 for D28253 (which fixes PR28929), gcc cannot compile `` 
anymore in pre-C+11 modes, complaining:

```
In file included from /usr/include/c++/v1/memory:648:0,
 from test.cpp:1:
/usr/include/c++/v1/memory: In static member function 'static 
std::__1::shared_ptr<_Tp> std::__1::shared_ptr<_Tp>::make_shared(_A0&, _A1&, 
_A2&)':
/usr/include/c++/v1/memory:4365:5: error: wrong number of template arguments 
(4, should be at least 1)
 static_assert((is_constructible<_Tp, _A0, _A1, _A2>::value), "Can't 
construct object in make_shared" );
 ^
In file included from /usr/include/c++/v1/memory:649:0,
 from test.cpp:1:
/usr/include/c++/v1/type_traits:3198:29: note: provided for 'template struct std::__1::is_constructible'
 struct _LIBCPP_TEMPLATE_VIS is_constructible
 ^~~~
In file included from /usr/include/c++/v1/memory:648:0,
 from test.cpp:1:
/usr/include/c++/v1/memory:4365:5: error: template argument 1 is invalid
 static_assert((is_constructible<_Tp, _A0, _A1, _A2>::value), "Can't 
construct object in make_shared" );
 ^
/usr/include/c++/v1/memory: In static member function 'static 
std::__1::shared_ptr<_Tp> std::__1::shared_ptr<_Tp>::allocate_shared(const 
_Alloc&, _A0&, _A1&, _A2&)':
/usr/include/c++/v1/memory::5: error: wrong number of template arguments 
(4, should be at least 1)
 static_assert((is_constructible<_Tp, _A0, _A1, _A2>::value), "Can't 
construct object in allocate_shared" );
 ^
In file included from /usr/include/c++/v1/memory:649:0,
 from test.cpp:1:
/usr/include/c++/v1/type_traits:3198:29: note: provided for 'template struct std::__1::is_constructible'
 struct _LIBCPP_TEMPLATE_VIS is_constructible
 ^~~~
In file included from /usr/include/c++/v1/memory:648:0,
 from test.cpp:1:
/usr/include/c++/v1/memory::5: error: template argument 1 is invalid
 static_assert((is_constructible<_Tp, _A0, _A1, _A2>::value), "Can't 
construct object in allocate_shared" );
 ^
```

This is also reported in https://bugs.freebsd.org/224946 (FreeBSD is apparently 
one of the very few projects that regularly builds programs against libc++ with 
gcc).

The reason is that the static assertions are invoking `is_constructible` with 
three arguments, while gcc does not have the built-in `is_constructible` 
feature, and the pre-C++11 `is_constructible` wrappers in `` only 
provide up to two arguments.

I have added additional wrappers for three arguments, modified the 
`is_constructible` entry point to take three arguments instead, and added a 
simple test to is_constructible.pass.cpp.

Reviewers: EricWF, mclow.lists

Reviewed By: EricWF

Subscribers: krytarowski, cfe-commits, emaste

Differential Revision: https://reviews.llvm.org/D41805

Modified:
libcxx/trunk/include/type_traits

libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.prop/is_constructible.pass.cpp

Modified: libcxx/trunk/include/type_traits
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/type_traits?rev=321963&r1=321962&r2=321963&view=diff
==
--- libcxx/trunk/include/type_traits (original)
+++ libcxx/trunk/include/type_traits Sun Jan  7 08:45:11 2018
@@ -3172,6 +3172,14 @@ template 
 false_type
 __is_constructible2_test(__any, _A0&, _A1&);
 
+template 
+decltype((_Tp(_VSTD::declval<_A0>(), _VSTD::declval<_A1>(), 
_VSTD::declval<_A2>()), true_type()))
+__is_constructible3_test(_Tp&, _A0&, _A1&, _A2&);
+
+template 
+false_type
+__is_constructible3_test(__any, _A0&, _A1&, _A2&);
+
 template 
 struct __is_constructible0_imp // false, _Tp is not a scalar
 : public common_type
@@ -3196,6 +3204,14 @@ struct __is_constructible2_imp // false,
  >::type
 {};
 
+template 
+struct __is_constructible3_imp // false, _Tp is not a scalar
+: public common_type
+ <
+ decltype(__is_constructible3_test(declval<_Tp&>(), 
declval<_A0>(), declval<_A1>(), declval<_A2>()))
+ >::type
+{};
+
 //  handle scalars and reference types
 
 //  Scalars are default constructible, references are not
@@ -3215,6 +3231,11 @@ struct __is_constructible2_imp
+struct __is_constructible3_imp
+: public false_type
+{};
+
 //  Treat scalars and reference types separately
 
 template 
@@ -3235,6 +3256,12 @@ struct __is_constructible2_void_check
 _Tp, _A0, _A1>
 {};
 
+template 
+struct __is_constructible3_void_check
+: public __is_constructible3_imp::value || 
is_reference<_Tp>::value,
+_Tp, _A0, _A1, _A2>
+{};
+
 //  If any of T or Args is

Re: [libcxxabi] r308470 - Drop 'svn' suffix from version number.

2017-09-09 Thread Dimitry Andric via cfe-commits

On 19 Jul 2017, at 16:04, Hans Wennborg via cfe-commits 
 wrote:
> 
> Author: hans
> Date: Wed Jul 19 07:04:19 2017
> New Revision: 308470
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=308470&view=rev
> Log:
> Drop 'svn' suffix from version number.

[Replying to this commit, since I don't have r308469 (which does the same for 
llvm itself) in my mailboxes.]

Note this approach isn't effective anymore after Rafael's
https://reviews.llvm.org/rL306858, which turns on the LLVM_APPEND_VC_REV
option by default.

The handling of that option will overwrite the PACKAGE_VERSION value set
earlier in CMakeLists.txt, with the value returned from
add_version_info_from_vcs().  When using Subversion, that will always be
of the form X.Y.Zsvn-rNN.

I noticed this when preparing the 5.0.0 final import into FreeBSD, where
for example "opt -version" outputs:

LLVM (http://llvm.org/):
  LLVM version 5.0.0svn-r312559
  Optimized build with assertions.
  Default target: x86_64-unknown-freebsd12.0
  Host CPU: ivybridge

-Dimitry

signature.asc
Description: Message signed with OpenPGP
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libunwind] r364217 - Merging r360861:

2019-07-08 Thread Dimitry Andric via cfe-commits

On 24 Jun 2019, at 20:40, Tom Stellard via cfe-commits 
 wrote:
> 
> Author: tstellar
> Date: Mon Jun 24 11:40:58 2019
> New Revision: 364217
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=364217&view=rev
> Log:
> Merging r360861:
> 
> 
> r360861 | mstorsjo | 2019-05-15 23:49:13 -0700 (Wed, 15 May 2019) | 13 lines
> 
> [PPC64][libunwind] Fix r2 not properly restored

> Modified: libunwind/branches/release_80/src/assembly.h
> URL: 
> http://llvm.org/viewvc/llvm-project/libunwind/branches/release_80/src/assembly.h?rev=364217&r1=364216&r2=364217&view=diff
> ==
> --- libunwind/branches/release_80/src/assembly.h (original)
> +++ libunwind/branches/release_80/src/assembly.h Mon Jun 24 11:40:58 2019
> @@ -35,6 +35,20 @@
> #define SEPARATOR ;
> #endif
> 
> +#if defined(__powerpc64__) && (!defined(_CALL_ELF) || _CALL_ELF == 1)
> +#define PPC64_OPD1 .section .opd,"aw",@progbits SEPARATOR
> +#define PPC64_OPD2 SEPARATOR \
> +  .p2align 3 SEPARATOR \
> +  .quad .Lfunc_begin0 SEPARATOR \
> +  .quad .TOC.@tocbase SEPARATOR \
> +  .quad 0 SEPARATOR \
> +  .text SEPARATOR \
> +.Lfunc_begin0:
> +#else
> +#define PPC64_OPD1
> +#define PPC64_OPD2
> +#endif
> +
> #define GLUE2(a, b) a ## b
> #define GLUE(a, b) GLUE2(a, b)
> #define SYMBOL_NAME(name) GLUE(__USER_LABEL_PREFIX__, name)
> @@ -95,7 +109,9 @@
>   .globl SYMBOL_NAME(name) SEPARATOR  \
>   EXPORT_SYMBOL(name) SEPARATOR   \
>   SYMBOL_IS_FUNC(SYMBOL_NAME(name)) SEPARATOR \
> -  SYMBOL_NAME(name):
> +  PPC64_OPD1  \
> +  SYMBOL_NAME(name):  \
> +  PPC64_OPD2
> 
> #define DEFINE_LIBUNWIND_PRIVATE_FUNCTION(name)   \
>   .globl SYMBOL_NAME(name) SEPARATOR  \
> 

I think this merge missed that the DEFINE_LIBUNWIND_PRIVATE_FUNCTION
macro went away in r357640 ("[libunwind] Export the unw_* symbols as
weak symbols").

It looks like the PPC64_OPD1 and PPC64_OPD2 lines should also be added
to the expansion of DEFINE_LIBUNWIND_PRIVATE_FUNCTION?

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libunwind] r365539 - Revert merge of r360861:

2019-07-09 Thread Dimitry Andric via cfe-commits

Author: dim
Date: Tue Jul  9 12:14:43 2019
New Revision: 365539

URL: http://llvm.org/viewvc/llvm-project?rev=365539&view=rev
Log:
Revert merge of r360861:


r360861 | mstorsjo | 2019-05-15 23:49:13 -0700 (Wed, 15 May 2019) | 13 lines

[PPC64][libunwind] Fix r2 not properly restored

This change makes each unwind step inspect the instruction at the
return address and, if needed, read r2 from its saved location and
modify the context appropriately.

The unwind logic is able to handle both ELFv1 and ELFv2 stacks.

Reported by Bug 41050

Patch by Leandro Lupori!

Differential Revision: https://reviews.llvm.org/D59694


Modified:
libunwind/branches/release_80/src/DwarfInstructions.hpp
libunwind/branches/release_80/src/assembly.h
libunwind/branches/release_80/test/lit.cfg

Modified: libunwind/branches/release_80/src/DwarfInstructions.hpp
URL: 
http://llvm.org/viewvc/llvm-project/libunwind/branches/release_80/src/DwarfInstructions.hpp?rev=365539&r1=365538&r2=365539&view=diff
==
--- libunwind/branches/release_80/src/DwarfInstructions.hpp (original)
+++ libunwind/branches/release_80/src/DwarfInstructions.hpp Tue Jul  9 12:14:43 
2019
@@ -234,31 +234,6 @@ int DwarfInstructions::stepWithDwa
   }
 #endif
 
-#if defined(_LIBUNWIND_TARGET_PPC64)
-#define PPC64_ELFV1_R2_LOAD_INST_ENCODING 0xe8410028u // ld r2,40(r1)
-#define PPC64_ELFV1_R2_OFFSET 40
-#define PPC64_ELFV2_R2_LOAD_INST_ENCODING 0xe8410018u // ld r2,24(r1)
-#define PPC64_ELFV2_R2_OFFSET 24
-  // If the instruction at return address is a TOC (r2) restore,
-  // then r2 was saved and needs to be restored.
-  // ELFv2 ABI specifies that the TOC Pointer must be saved at SP + 24,
-  // while in ELFv1 ABI it is saved at SP + 40.
-  if (R::getArch() == REGISTERS_PPC64 && returnAddress != 0) {
-pint_t sp = newRegisters.getRegister(UNW_REG_SP);
-pint_t r2 = 0;
-switch (addressSpace.get32(returnAddress)) {
-case PPC64_ELFV1_R2_LOAD_INST_ENCODING:
-  r2 = addressSpace.get64(sp + PPC64_ELFV1_R2_OFFSET);
-  break;
-case PPC64_ELFV2_R2_LOAD_INST_ENCODING:
-  r2 = addressSpace.get64(sp + PPC64_ELFV2_R2_OFFSET);
-  break;
-}
-if (r2)
-  newRegisters.setRegister(UNW_PPC64_R2, r2);
-  }
-#endif
-
   // Return address is address after call site instruction, so setting IP 
to
   // that does simualates a return.
   newRegisters.setIP(returnAddress);

Modified: libunwind/branches/release_80/src/assembly.h
URL: 
http://llvm.org/viewvc/llvm-project/libunwind/branches/release_80/src/assembly.h?rev=365539&r1=365538&r2=365539&view=diff
==
--- libunwind/branches/release_80/src/assembly.h (original)
+++ libunwind/branches/release_80/src/assembly.h Tue Jul  9 12:14:43 2019
@@ -35,20 +35,6 @@
 #define SEPARATOR ;
 #endif
 
-#if defined(__powerpc64__) && (!defined(_CALL_ELF) || _CALL_ELF == 1)
-#define PPC64_OPD1 .section .opd,"aw",@progbits SEPARATOR
-#define PPC64_OPD2 SEPARATOR \
-  .p2align 3 SEPARATOR \
-  .quad .Lfunc_begin0 SEPARATOR \
-  .quad .TOC.@tocbase SEPARATOR \
-  .quad 0 SEPARATOR \
-  .text SEPARATOR \
-.Lfunc_begin0:
-#else
-#define PPC64_OPD1
-#define PPC64_OPD2
-#endif
-
 #define GLUE2(a, b) a ## b
 #define GLUE(a, b) GLUE2(a, b)
 #define SYMBOL_NAME(name) GLUE(__USER_LABEL_PREFIX__, name)
@@ -109,9 +95,7 @@
   .globl SYMBOL_NAME(name) SEPARATOR  \
   EXPORT_SYMBOL(name) SEPARATOR   \
   SYMBOL_IS_FUNC(SYMBOL_NAME(name)) SEPARATOR \
-  PPC64_OPD1  \
-  SYMBOL_NAME(name):  \
-  PPC64_OPD2
+  SYMBOL_NAME(name):
 
 #define DEFINE_LIBUNWIND_PRIVATE_FUNCTION(name)   \
   .globl SYMBOL_NAME(name) SEPARATOR  \

Modified: libunwind/branches/release_80/test/lit.cfg
URL: 
http://llvm.org/viewvc/llvm-project/libunwind/branches/release_80/test/lit.cfg?rev=365539&r1=365538&r2=365539&view=diff
==
--- libunwind/branches/release_80/test/lit.cfg (original)
+++ libunwind/branches/release_80/test/lit.cfg Tue Jul  9 12:14:43 2019
@@ -23,9 +23,6 @@ config.suffixes = ['.cpp', '.s']
 # test_source_root: The root path where tests are located.
 config.test_source_root = os.path.dirname(__file__)
 
-# needed to test libunwind with code that throws exceptions
-config.enable_exceptions = True
-
 # Infer the libcxx_test_source_root for configuration import.
 # If libcxx_source_root isn't specified in the config, assume that the libcxx
 # and libunwind source directories are sibling directories.

[libunwind] r365542 - Merging r360861, with an additional change to also add the PPC64_OPD1

2019-07-09 Thread Dimitry Andric via cfe-commits

Author: dim
Date: Tue Jul  9 12:22:59 2019
New Revision: 365542

URL: http://llvm.org/viewvc/llvm-project?rev=365542&view=rev
Log:
Merging r360861, with an additional change to also add the PPC64_OPD1
and PPC64_OPD2 lines to the DEFINE_LIBUNWIND_PRIVATE_FUNCTION() macro,
which was removed in r357640:


r360861 | mstorsjo | 2019-05-15 23:49:13 -0700 (Wed, 15 May 2019) | 13 lines

[PPC64][libunwind] Fix r2 not properly restored

This change makes each unwind step inspect the instruction at the
return address and, if needed, read r2 from its saved location and
modify the context appropriately.

The unwind logic is able to handle both ELFv1 and ELFv2 stacks.

Reported by Bug 41050

Patch by Leandro Lupori!

Differential Revision: https://reviews.llvm.org/D59694


Modified:
libunwind/branches/release_80/   (props changed)
libunwind/branches/release_80/src/DwarfInstructions.hpp
libunwind/branches/release_80/src/assembly.h
libunwind/branches/release_80/test/lit.cfg

Propchange: libunwind/branches/release_80/
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Tue Jul  9 12:22:59 2019
@@ -1 +1 @@
-/libunwind/trunk:352016
+/libunwind/trunk:352016,360861

Modified: libunwind/branches/release_80/src/DwarfInstructions.hpp
URL: 
http://llvm.org/viewvc/llvm-project/libunwind/branches/release_80/src/DwarfInstructions.hpp?rev=365542&r1=365541&r2=365542&view=diff
==
--- libunwind/branches/release_80/src/DwarfInstructions.hpp (original)
+++ libunwind/branches/release_80/src/DwarfInstructions.hpp Tue Jul  9 12:22:59 
2019
@@ -234,6 +234,31 @@ int DwarfInstructions::stepWithDwa
   }
 #endif
 
+#if defined(_LIBUNWIND_TARGET_PPC64)
+#define PPC64_ELFV1_R2_LOAD_INST_ENCODING 0xe8410028u // ld r2,40(r1)
+#define PPC64_ELFV1_R2_OFFSET 40
+#define PPC64_ELFV2_R2_LOAD_INST_ENCODING 0xe8410018u // ld r2,24(r1)
+#define PPC64_ELFV2_R2_OFFSET 24
+  // If the instruction at return address is a TOC (r2) restore,
+  // then r2 was saved and needs to be restored.
+  // ELFv2 ABI specifies that the TOC Pointer must be saved at SP + 24,
+  // while in ELFv1 ABI it is saved at SP + 40.
+  if (R::getArch() == REGISTERS_PPC64 && returnAddress != 0) {
+pint_t sp = newRegisters.getRegister(UNW_REG_SP);
+pint_t r2 = 0;
+switch (addressSpace.get32(returnAddress)) {
+case PPC64_ELFV1_R2_LOAD_INST_ENCODING:
+  r2 = addressSpace.get64(sp + PPC64_ELFV1_R2_OFFSET);
+  break;
+case PPC64_ELFV2_R2_LOAD_INST_ENCODING:
+  r2 = addressSpace.get64(sp + PPC64_ELFV2_R2_OFFSET);
+  break;
+}
+if (r2)
+  newRegisters.setRegister(UNW_PPC64_R2, r2);
+  }
+#endif
+
   // Return address is address after call site instruction, so setting IP 
to
   // that does simualates a return.
   newRegisters.setIP(returnAddress);

Modified: libunwind/branches/release_80/src/assembly.h
URL: 
http://llvm.org/viewvc/llvm-project/libunwind/branches/release_80/src/assembly.h?rev=365542&r1=365541&r2=365542&view=diff
==
--- libunwind/branches/release_80/src/assembly.h (original)
+++ libunwind/branches/release_80/src/assembly.h Tue Jul  9 12:22:59 2019
@@ -35,6 +35,20 @@
 #define SEPARATOR ;
 #endif
 
+#if defined(__powerpc64__) && (!defined(_CALL_ELF) || _CALL_ELF == 1)
+#define PPC64_OPD1 .section .opd,"aw",@progbits SEPARATOR
+#define PPC64_OPD2 SEPARATOR \
+  .p2align 3 SEPARATOR \
+  .quad .Lfunc_begin0 SEPARATOR \
+  .quad .TOC.@tocbase SEPARATOR \
+  .quad 0 SEPARATOR \
+  .text SEPARATOR \
+.Lfunc_begin0:
+#else
+#define PPC64_OPD1
+#define PPC64_OPD2
+#endif
+
 #define GLUE2(a, b) a ## b
 #define GLUE(a, b) GLUE2(a, b)
 #define SYMBOL_NAME(name) GLUE(__USER_LABEL_PREFIX__, name)
@@ -95,13 +109,17 @@
   .globl SYMBOL_NAME(name) SEPARATOR  \
   EXPORT_SYMBOL(name) SEPARATOR   \
   SYMBOL_IS_FUNC(SYMBOL_NAME(name)) SEPARATOR \
-  SYMBOL_NAME(name):
+  PPC64_OPD1  \
+  SYMBOL_NAME(name):  \
+  PPC64_OPD2
 
 #define DEFINE_LIBUNWIND_PRIVATE_FUNCTION(name)   \
   .globl SYMBOL_NAME(name) SEPARATOR  \
   HIDDEN_SYMBOL(SYMBOL_NAME(name)) SEPARATOR  \
   SYMBOL_IS_FUNC(SYMBOL_NAME(name)) SEPARATOR \
-  SYMBOL_NAME(name):
+  PPC64_OPD1  \
+  SYMBOL_NAME(name):  \
+  PPC64_OPD2
 
 #if defined(__arm__)
 #if !defined(__ARM_ARCH)

Modified: libunwind/branches/release_80/test/lit.cfg
URL: 
http://llvm.org/viewvc/llvm-p

Re: [libunwind] r364217 - Merging r360861:

2019-07-09 Thread Dimitry Andric via cfe-commits

On 9 Jul 2019, at 04:54, Tom Stellard  wrote:
> 
> On 07/08/2019 11:51 AM, Dimitry Andric wrote:
>> On 24 Jun 2019, at 20:40, Tom Stellard via cfe-commits 
>>  wrote:
>>> 
>>> Author: tstellar
>>> Date: Mon Jun 24 11:40:58 2019
>>> New Revision: 364217
>>> 
>>> URL: http://llvm.org/viewvc/llvm-project?rev=364217&view=rev
>>> Log:
>>> Merging r360861:
>>> 
>>> 
>>> r360861 | mstorsjo | 2019-05-15 23:49:13 -0700 (Wed, 15 May 2019) | 13 lines
>>> 
>>> [PPC64][libunwind] Fix r2 not properly restored
>> 
>>> Modified: libunwind/branches/release_80/src/assembly.h
>>> URL: 
>>> http://llvm.org/viewvc/llvm-project/libunwind/branches/release_80/src/assembly.h?rev=364217&r1=364216&r2=364217&view=diff
>>> ==
>>> --- libunwind/branches/release_80/src/assembly.h (original)
>>> +++ libunwind/branches/release_80/src/assembly.h Mon Jun 24 11:40:58 2019
>>> @@ -35,6 +35,20 @@
>>> #define SEPARATOR ;
>>> #endif
>>> 
>>> +#if defined(__powerpc64__) && (!defined(_CALL_ELF) || _CALL_ELF == 1)
>>> +#define PPC64_OPD1 .section .opd,"aw",@progbits SEPARATOR
>>> +#define PPC64_OPD2 SEPARATOR \
>>> +  .p2align 3 SEPARATOR \
>>> +  .quad .Lfunc_begin0 SEPARATOR \
>>> +  .quad .TOC.@tocbase SEPARATOR \
>>> +  .quad 0 SEPARATOR \
>>> +  .text SEPARATOR \
>>> +.Lfunc_begin0:
>>> +#else
>>> +#define PPC64_OPD1
>>> +#define PPC64_OPD2
>>> +#endif
>>> +
>>> #define GLUE2(a, b) a ## b
>>> #define GLUE(a, b) GLUE2(a, b)
>>> #define SYMBOL_NAME(name) GLUE(__USER_LABEL_PREFIX__, name)
>>> @@ -95,7 +109,9 @@
>>>  .globl SYMBOL_NAME(name) SEPARATOR  \
>>>  EXPORT_SYMBOL(name) SEPARATOR   \
>>>  SYMBOL_IS_FUNC(SYMBOL_NAME(name)) SEPARATOR \
>>> -  SYMBOL_NAME(name):
>>> +  PPC64_OPD1  \
>>> +  SYMBOL_NAME(name):  \
>>> +  PPC64_OPD2
>>> 
>>> #define DEFINE_LIBUNWIND_PRIVATE_FUNCTION(name)   \
>>>  .globl SYMBOL_NAME(name) SEPARATOR  \
>>> 
>> 
>> I think this merge missed that the DEFINE_LIBUNWIND_PRIVATE_FUNCTION
>> macro went away in r357640 ("[libunwind] Export the unw_* symbols as
>> weak symbols").
>> 
>> It looks like the PPC64_OPD1 and PPC64_OPD2 lines should also be added
>> to the expansion of DEFINE_LIBUNWIND_PRIVATE_FUNCTION?
>> 
> 
> Is someone else able to try to remerge and fix this up?  I don't have
> a good way to test this.  If we can't get this resolved by Wednesday,
> I am going to revert it, because it's the only thing blocking the release
> at this point.

I reverted the merge in https://reviews.llvm.org/rL365539, and reapplied
it with the additional lines in https://reviews.llvm.org/rL365542.  I
hope you don't mind.

This is also going to end up in the next merge to FreeBSD's libunwind.

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r372261 - On PowerPC, Secure-PLT by default for FreeBSD 13 and higher

2019-09-18 Thread Dimitry Andric via cfe-commits

Author: dim
Date: Wed Sep 18 13:58:03 2019
New Revision: 372261

URL: http://llvm.org/viewvc/llvm-project?rev=372261&view=rev
Log:
On PowerPC, Secure-PLT by default for FreeBSD 13 and higher

Summary:
In https://svnweb.freebsd.org/changeset/base/349351, FreeBSD 13 and
higher transitioned to Secure-PLT for PowerPC.  This part contains the
changes in clang's PPC architecture defaults.

Reviewers: emaste, jhibbits, hfinkel

Reviewed By: jhibbits

Subscribers: wuzish, nemanjai, krytarowski, kbarton, MaskRay, jsji, shchenz, 
steven.zhang, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D67119

Modified:
cfe/trunk/lib/Driver/ToolChains/Arch/PPC.cpp

Modified: cfe/trunk/lib/Driver/ToolChains/Arch/PPC.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Arch/PPC.cpp?rev=372261&r1=372260&r2=372261&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Arch/PPC.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Arch/PPC.cpp Wed Sep 18 13:58:03 2019
@@ -115,7 +115,8 @@ ppc::ReadGOTPtrMode ppc::getPPCReadGOTPt
   const ArgList &Args) {
   if (Args.getLastArg(options::OPT_msecure_plt))
 return ppc::ReadGOTPtrMode::SecurePlt;
-  if (Triple.isOSNetBSD() || Triple.isOSOpenBSD() || Triple.isMusl())
+  if ((Triple.isOSFreeBSD() && Triple.getOSMajorVersion() >= 13) ||
+  Triple.isOSNetBSD() || Triple.isOSOpenBSD() || Triple.isMusl())
 return ppc::ReadGOTPtrMode::SecurePlt;
   else
 return ppc::ReadGOTPtrMode::Bss;


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r313784 - Remove offset size check in nullptr arithmetic handling

2018-04-24 Thread Dimitry Andric via cfe-commits

On 20 Sep 2017, at 20:06, Andrew Kaylor via cfe-commits 
 wrote:
> 
> Author: akaylor
> Date: Wed Sep 20 11:06:44 2017
> New Revision: 313784
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=313784&view=rev
> Log:
> Remove offset size check in nullptr arithmetic handling
> 
> Differential Revision: https://reviews.llvm.org/D37042

Hi Andrew,

Interestingly, this change (and its related r313666) break PHP 5.6's opcache 
module, as reported in https://bugs.freebsd.org/227723.

PHP 5 uses a construct like to the following, to store multiple items in a 
'variable' struct [1]:

typedef struct TV {
  long tmp;
  char tmp3[30];
} temp_variable;

#define EX_TMP_VAR(ex, n)  ((temp_variable*)(((char*)(ex)) + 
((int)(n
#define EX_TMP_VAR_NUM(ex, n)  (EX_TMP_VAR(ex, 0) - (1 + (n)))
#define VAR_NUM(v) ((unsigned int)(EX_TMP_VAR_NUM(0, 0) - 
EX_TMP_VAR(0, v)))

Invoking the VAR_NUM() macro gives different answers before and after r313784, 
e.g. at r313783:

VAR_NUM(-100) -> 1

At r313784:

   VAR_NUM(-100) -> 0xf99c

I proposed a workaround which avoids the null pointer arithmetic, but can you 
shed any light as to why your changes seem to make matters worse for PHP, while 
they seem to have been intended to make this kind of construct work better 
instead?

-Dimitry

[1] See also: 
https://github.com/php/php-src/blob/PHP-5.6/Zend/zend_compile.h#L417
 and: 
https://github.com/php/php-src/blob/PHP-5.6/ext/opcache/Optimizer/zend_optimizer_internal.h#L28

signature.asc
Description: Message signed with OpenPGP
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r336008 - Request init/fini array on FreeBSD 12 and later

2018-06-29 Thread Dimitry Andric via cfe-commits

Author: dim
Date: Fri Jun 29 12:18:17 2018
New Revision: 336008

URL: http://llvm.org/viewvc/llvm-project?rev=336008&view=rev
Log:
Request init/fini array on FreeBSD 12 and later

Summary:
It seems a bad idea to change the default in the middle of a release
branch due to possible changes in global ctor / dtor ordering between
.ctors and .init_array. With FreeBSD 11.0's release imminent lets change
the default now for FreeBSD 12 (the current development stream) and
later.

FreeBSD rtld has supported .init_array / .fini_array for many years. As
of Jan 1 2017 all supported FreeBSD releases and branches will have
support.

Reviewers: dim, brooks, arichardson

Reviewed By: dim, brooks, arichardson

Subscribers: bsdjhb, krytarowski, emaste, cfe-commits

Differential Revision: https://reviews.llvm.org/D24867

Modified:
cfe/trunk/lib/Driver/ToolChains/Gnu.cpp
cfe/trunk/test/Driver/constructors.c

Modified: cfe/trunk/lib/Driver/ToolChains/Gnu.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Gnu.cpp?rev=336008&r1=336007&r2=336008&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Gnu.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Gnu.cpp Fri Jun 29 12:18:17 2018
@@ -2543,6 +2543,8 @@ void Generic_ELF::addClangTargetOptions(
   bool UseInitArrayDefault =
   getTriple().getArch() == llvm::Triple::aarch64 ||
   getTriple().getArch() == llvm::Triple::aarch64_be ||
+  (getTriple().getOS() == llvm::Triple::FreeBSD &&
+   getTriple().getOSMajorVersion() >= 12) ||
   (getTriple().getOS() == llvm::Triple::Linux &&
((!GCCInstallation.isValid() || !V.isOlderThan(4, 7, 0)) ||
 getTriple().isAndroid())) ||

Modified: cfe/trunk/test/Driver/constructors.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/constructors.c?rev=336008&r1=336007&r2=336008&view=diff
==
--- cfe/trunk/test/Driver/constructors.c (original)
+++ cfe/trunk/test/Driver/constructors.c Fri Jun 29 12:18:17 2018
@@ -80,6 +80,14 @@
 // RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1   \
 // RUN: -target arm64-none-none-eabi \
 // RUN:   | FileCheck --check-prefix=CHECK-INIT-ARRAY %s
+
+// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1   \
+// RUN: -target i386-unknown-freebsd11 \
+// RUN:   | FileCheck --check-prefix=CHECK-NO-INIT-ARRAY %s
+
+// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1   \
+// RUN: -target i386-unknown-freebsd12 \
+// RUN:   | FileCheck --check-prefix=CHECK-INIT-ARRAY %s
 //
 // RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1\
 // RUN: -target sparc-sun-solaris2.11 \


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 02cfa75 - Bump the default target CPU for i386-freebsd to i686

2020-07-12 Thread Dimitry Andric via cfe-commits


Author: Dimitry Andric
Date: 2020-07-12T23:45:22+02:00
New Revision: 02cfa7530d9e7cfd8ea940dab4173afb7938b831

URL: 
https://github.com/llvm/llvm-project/commit/02cfa7530d9e7cfd8ea940dab4173afb7938b831
DIFF: 
https://github.com/llvm/llvm-project/commit/02cfa7530d9e7cfd8ea940dab4173afb7938b831.diff

LOG: Bump the default target CPU for i386-freebsd to i686

Summary:
Similar to what we have done downstream, some time ago:
https://svnweb.freebsd.org/changeset/base/353936

This followed some discussions on the freebsd-arch mailing lists, and
most people agreed that it was a better default, and also it worked
around several issues where clang generated libcalls to 64 bit atomic
primitives, instead of using cmpxchg8b.

Reviewers: emaste, brooks, rsmith

Reviewed By: emaste

Subscribers: arichardson, krytarowski, jfb, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D83645

Added: 


Modified: 
clang/lib/Driver/ToolChains/Arch/X86.cpp

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Arch/X86.cpp 
b/clang/lib/Driver/ToolChains/Arch/X86.cpp
index aa95c4189d1e..2cc44c09917f 100644
--- a/clang/lib/Driver/ToolChains/Arch/X86.cpp
+++ b/clang/lib/Driver/ToolChains/Arch/X86.cpp
@@ -94,6 +94,7 @@ const char *x86::getX86TargetCPU(const ArgList &Args,
 
   switch (Triple.getOS()) {
   case llvm::Triple::FreeBSD:
+return "i686";
   case llvm::Triple::NetBSD:
   case llvm::Triple::OpenBSD:
 return "i486";



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D24867: Request init/fini array on FreeBSD 12 and later

2016-09-23 Thread Dimitry Andric via cfe-commits

dim accepted this revision.
dim added a comment.
This revision is now accepted and ready to land.

LGTM.


https://reviews.llvm.org/D24867



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D25389: Fix std::pair on FreeBSD

2016-10-10 Thread Dimitry Andric via cfe-commits

dim accepted this revision.
dim added a comment.
This revision is now accepted and ready to land.

Yes, this looks good to me.  For trunk r283783, this brought the number of 
unexpected failures down from 61 to 41.  Tests fixed by this change:

  libc++ :: std/algorithms/alg.sorting/alg.min.max/minmax.pass.cpp
  libc++ :: std/algorithms/alg.sorting/alg.min.max/minmax_comp.pass.cpp
  libc++ :: std/algorithms/alg.sorting/alg.min.max/minmax_element.pass.cpp
  libc++ :: std/algorithms/alg.sorting/alg.min.max/minmax_element_comp.pass.cpp
  libc++ :: std/algorithms/alg.sorting/alg.min.max/minmax_init_list.pass.cpp
  libc++ :: 
std/algorithms/alg.sorting/alg.min.max/minmax_init_list_comp.pass.cpp
  libc++ :: 
std/experimental/string.view/string.view.find/find_pointer_size.pass.cpp
  libc++ :: 
std/experimental/string.view/string.view.find/find_pointer_size_size.pass.cpp
  libc++ :: 
std/experimental/string.view/string.view.find/find_string_view_size.pass.cpp
  libc++ :: std/strings/string.view/string.view.find/find_pointer_size.pass.cpp
  libc++ :: 
std/strings/string.view/string.view.find/find_pointer_size_size.pass.cpp
  libc++ :: 
std/strings/string.view/string.view.find/find_string_view_size.pass.cpp
  libc++ :: 
std/thread/thread.mutex/thread.lock/thread.lock.shared/thread.lock.shared.cons/mutex_try_to_lock.pass.cpp
  libc++ :: std/utilities/tuple/tuple.tuple/tuple.apply/make_from_tuple.pass.cpp
  libc++ :: std/utilities/utility/pairs/pairs.pair/const_pair_U_V.pass.cpp
  libc++ :: std/utilities/utility/pairs/pairs.pair/copy_ctor.pass.cpp
  libc++ :: std/utilities/utility/pairs/pairs.pair/move_ctor.pass.cpp
  libc++ :: std/utilities/utility/pairs/pairs.pair/rv_pair_U_V.pass.cpp
  libc++ :: 
std/utilities/utility/pairs/pairs.pair/special_member_generation_test.pass.cpp
  libc++ :: std/utilities/utility/pairs/pairs.spec/make_pair.pass.cpp


https://reviews.llvm.org/D25389



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D25449: Disable trivial pair copy/move tests when unsupported

2016-10-10 Thread Dimitry Andric via cfe-commits

dim created this revision.
dim added reviewers: EricWF, emaste, rsmith, theraven.
dim added a subscriber: cfe-commits.

On FreeBSD, for ABI compatibility reasons, the pair trivial copy
constructor is disabled, using the aptly-named
`_LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR` define.

Disable the related tests when this define is on, so they don't fail
unexpectedly.


https://reviews.llvm.org/D25449

Files:
  test/std/utilities/utility/pairs/pairs.pair/trivial_copy_move.pass.cpp


Index: test/std/utilities/utility/pairs/pairs.pair/trivial_copy_move.pass.cpp
===
--- test/std/utilities/utility/pairs/pairs.pair/trivial_copy_move.pass.cpp
+++ test/std/utilities/utility/pairs/pairs.pair/trivial_copy_move.pass.cpp
@@ -32,19 +32,25 @@
 typedef std::pair P;
 {
 static_assert(std::is_copy_constructible::value, "");
+#if !defined(_LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR)
 static_assert(std::is_trivially_copy_constructible::value, "");
+#endif
 }
 #if TEST_STD_VER >= 11
 {
 static_assert(std::is_move_constructible::value, "");
+#if !defined(_LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR)
 static_assert(std::is_trivially_move_constructible::value, "");
+#endif
 }
 {
 using P1 = std::pair;
 static_assert(!std::is_copy_constructible::value, "");
 static_assert(!std::is_trivially_copy_constructible::value, "");
 static_assert(std::is_move_constructible::value, "");
+#if !defined(_LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR)
 static_assert(std::is_trivially_move_constructible::value, "");
+#endif
 }
 #endif
 }


Index: test/std/utilities/utility/pairs/pairs.pair/trivial_copy_move.pass.cpp
===
--- test/std/utilities/utility/pairs/pairs.pair/trivial_copy_move.pass.cpp
+++ test/std/utilities/utility/pairs/pairs.pair/trivial_copy_move.pass.cpp
@@ -32,19 +32,25 @@
 typedef std::pair P;
 {
 static_assert(std::is_copy_constructible::value, "");
+#if !defined(_LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR)
 static_assert(std::is_trivially_copy_constructible::value, "");
+#endif
 }
 #if TEST_STD_VER >= 11
 {
 static_assert(std::is_move_constructible::value, "");
+#if !defined(_LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR)
 static_assert(std::is_trivially_move_constructible::value, "");
+#endif
 }
 {
 using P1 = std::pair;
 static_assert(!std::is_copy_constructible::value, "");
 static_assert(!std::is_trivially_copy_constructible::value, "");
 static_assert(std::is_move_constructible::value, "");
+#if !defined(_LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR)
 static_assert(std::is_trivially_move_constructible::value, "");
+#endif
 }
 #endif
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libcxx] r284047 - Disable trivial pair copy/move tests when unsupported

2016-10-12 Thread Dimitry Andric via cfe-commits

Author: dim
Date: Wed Oct 12 15:26:47 2016
New Revision: 284047

URL: http://llvm.org/viewvc/llvm-project?rev=284047&view=rev
Log:
Disable trivial pair copy/move tests when unsupported

Summary:
On FreeBSD, for ABI compatibility reasons, the pair trivial copy
constructor is disabled, using the aptly-named
`_LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR` define.

Disable the related tests when this define is on, so they don't fail
unexpectedly.

Reviewers: emaste, rsmith, theraven, EricWF

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D25449

Modified:

libcxx/trunk/test/std/utilities/utility/pairs/pairs.pair/trivial_copy_move.pass.cpp

Modified: 
libcxx/trunk/test/std/utilities/utility/pairs/pairs.pair/trivial_copy_move.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/utilities/utility/pairs/pairs.pair/trivial_copy_move.pass.cpp?rev=284047&r1=284046&r2=284047&view=diff
==
--- 
libcxx/trunk/test/std/utilities/utility/pairs/pairs.pair/trivial_copy_move.pass.cpp
 (original)
+++ 
libcxx/trunk/test/std/utilities/utility/pairs/pairs.pair/trivial_copy_move.pass.cpp
 Wed Oct 12 15:26:47 2016
@@ -32,19 +32,25 @@ int main()
 typedef std::pair P;
 {
 static_assert(std::is_copy_constructible::value, "");
+#if !defined(_LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR)
 static_assert(std::is_trivially_copy_constructible::value, "");
+#endif
 }
 #if TEST_STD_VER >= 11
 {
 static_assert(std::is_move_constructible::value, "");
+#if !defined(_LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR)
 static_assert(std::is_trivially_move_constructible::value, "");
+#endif
 }
 {
 using P1 = std::pair;
 static_assert(!std::is_copy_constructible::value, "");
 static_assert(!std::is_trivially_copy_constructible::value, "");
 static_assert(std::is_move_constructible::value, "");
+#if !defined(_LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR)
 static_assert(std::is_trivially_move_constructible::value, "");
+#endif
 }
 #endif
 }


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D25593: [libcxx] Build with -fvisibility-inlines-hidden -- Remove 20 inline definitions from the dylib

2016-10-14 Thread Dimitry Andric via cfe-commits

dim accepted this revision.
dim added a comment.
This revision is now accepted and ready to land.

LGTM.


https://reviews.llvm.org/D25593



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [clang-tools-extra] r318840 - [FindAllSymbols] Cache regexes, creating them is expensive

2017-11-25 Thread Dimitry Andric via cfe-commits

Yeah, in the past libc++ broke its own ABI with 
http://llvm.org/viewvc/llvm-project?view=revision&revision=194536, which is why 
we had to add the _LIBCPP_TRIVIAL_PAIR_COPY_CTOR hack to our own libc++ 
__config, in https://svnweb.freebsd.org/base?view=revision&revision=261801.

(Afterwards, in 
http://llvm.org/viewvc/llvm-project?view=revision&revision=275749, that define 
was renamed to _LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR, but its 
functionality stayed the same.)

More recently, Eric Fiselier made the hack unnecessary with 
http://llvm.org/viewvc/llvm-project?view=revision&revision=283944, which I 
merged into FreeBSD 11-STABLE in 
https://svnweb.freebsd.org/base?view=revision&revision=315702.

After this, hacks for std::pair having trivial constructors should no longer be 
nessary, but the fix only made it into FreeBSD 11.1-RELEASE, so users with 
11.0-RELEASE are still SOL.

-Dimitry

> On 24 Nov 2017, at 00:01, Krzysztof Parzyszek  wrote:
> 
> +Dimitry.
> 
> 
> On 11/23/2017 12:50 PM, Benjamin Kramer wrote:
>> I'm afraid I can't really help you here. You can try twiddling the
>> code a bit by creating the pair explicitly and moving it into the
>> vector, just to avoid the brokenness in the standard library. Not sure
>> if that will help though.
>> On Thu, Nov 23, 2017 at 7:05 PM, Krzysztof Parzyszek
>>  wrote:
>>> There has been some problem with std::pair on FreeBSD (due to some ABI
>>> compatibility issue), but I don't know much about what it was.
>>> 
>>> Commenting the reserve doesn't help, unfortunately. The same problem is now
>>> flagged in emplace_back.
>>> 
>>> -Krzysztof
>>> 
>>> 
>>> 
>>> On 11/23/2017 11:47 AM, Benjamin Kramer wrote:
 
 That looks like a bug in the standard library. Does removing the call
 to reserve fix it? It's not really necessary, that code isn't
 performance sensitive at all.
 
 On Thu, Nov 23, 2017 at 6:36 PM, Krzysztof Parzyszek
  wrote:
> 
> Hi,
> This broke build on FreeBSD 11:
> 
> [100%] Building CXX object
> 
> tools/clang/tools/extra/include-fixer/find-all-symbols/CMakeFiles/findAllSymbols.dir/HeaderMapCollector.cpp.o
> cd /w/bld/org/tools/clang/tools/extra/include-fixer/find-all-symbols &&
> /w/c/clang+llvm-5.0.0-x86_64-unknown-freebsd11/bin/clang++
> -DGTEST_HAS_RTTI=0 -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS
> -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
> -I/w/bld/org/tools/clang/tools/extra/include-fixer/find-all-symbols
> -I/w/src/llvm.org/tools/clang/tools/extra/include-fixer/find-all-symbols
> -I/w/src/llvm.org/tools/clang/include -I/w/bld/org/tools/clang/include
> -I/w/bld/org/include -I/w/src/llvm.org/include -isystem
> /usr/local/include
> -stdlib=libc++ -fPIC -fvisibility-inlines-hidden -Werror=date-time
> -Werror=unguarded-availability-new -std=c++11 -Wall -W
> -Wno-unused-parameter
> -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic
> -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor
> -Wdelete-non-virtual-dtor -Wno-comment -Wstring-conversion
> -ffunction-sections -fdata-sections -fno-common -Woverloaded-virtual
> -Wno-nested-anon-types -O3-UNDEBUG -fno-exceptions -fno-rtti -o
> CMakeFiles/findAllSymbols.dir/HeaderMapCollector.cpp.o -c
> 
> /w/src/llvm.org/tools/clang/tools/extra/include-fixer/find-all-symbols/HeaderMapCollector.cpp
> In file included from
> 
> /w/src/llvm.org/tools/clang/tools/extra/include-fixer/find-all-symbols/HeaderMapCollector.cpp:10:
> In file included from
> 
> /w/src/llvm.org/tools/clang/tools/extra/include-fixer/find-all-symbols/HeaderMapCollector.h:13:
> In file included from /w/src/llvm.org/include/llvm/ADT/StringMap.h:17:
> In file included from /w/src/llvm.org/include/llvm/ADT/StringRef.h:13:
> In file included from /w/src/llvm.org/include/llvm/ADT/STLExtras.h:20:
> In file included from /w/src/llvm.org/include/llvm/ADT/Optional.h:22:
> In file included from
> /w/src/llvm.org/include/llvm/Support/type_traits.h:19:
> /usr/include/c++/v1/utility:315:11: error: call to deleted constructor of
> 'llvm::Regex'
>  : first(__p.first),
>^ ~
> /usr/include/c++/v1/memory:1747:31: note: in instantiation of member
> function 'std::__1::pair::pair' requested here
>  ::new((void*)__p) _Up(_VSTD::forward<_Args>(__args)...);
>^
> /usr/include/c++/v1/memory:1658:18: note: in instantiation of function
> template specialization 'std::__1::allocator const char *> >::construct,
> const
> std::__1::pair &>' requested here
>  {__a.construct(__p, _VSTD::forward<_Args>(__args)...);}
>   ^
> /usr/include/c++/v1/memory:1504:14: note: in instantiation of function
> template specialization
> 
> 'std::__1::allocator_traits const c

[clang] [clang][CodeGen] Always use CLANG_VENDOR as a quoted string (PR #75935)

2023-12-19 Thread Dimitry Andric via cfe-commits


https://github.com/DimitryAndric created 
https://github.com/llvm/llvm-project/pull/75935

In 9a38a72f1d482 `ProductId` was assigned from the stringified value of 
`CLANG_VENDOR`, if that macro was defined. However, `CLANG_VENDOR` is supposed 
to be a string, as it is defined (optionally) as such in the top-level clang 
`CMakeLists.txt`.

Move the addition of `-DCLANG_VENDOR` to the compiler flags from 
`clang/lib/Basic/CMakeLists.txt` to the top-level `CMakeLists.txt`, so it is 
consistent across the whole clang codebase. Then remove the stringification 
from `CodeGenModule.cpp`, to make it work correctly.

Fixes:  9a38a72f1d482

>From ce2f3105a5270a26fa3595313289dcbfa700abb9 Mon Sep 17 00:00:00 2001
From: Dimitry Andric 
Date: Tue, 19 Dec 2023 13:37:37 +0100
Subject: [PATCH] [clang][CodeGen] Always use CLANG_VENDOR as a quoted string

In 9a38a72f1d482 `ProductId` was assigned from the stringified value of
`CLANG_VENDOR`, if that macro was defined. However, `CLANG_VENDOR` is
supposed to be a string, as it is defined (optionally) as such in the
top-level clang `CMakeLists.txt`.

Move the addition of `-DCLANG_VENDOR` to the compiler flags from
`clang/lib/Basic/CMakeLists.txt` to the top-level `CMakeLists.txt`, so
it is consistent across the whole clang codebase. Then remove the
stringification from `CodeGenModule.cpp`, to make it work correctly.

Fixes:  9a38a72f1d482
---
 clang/CMakeLists.txt| 4 
 clang/lib/Basic/CMakeLists.txt  | 5 -
 clang/lib/CodeGen/CodeGenModule.cpp | 2 +-
 3 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/clang/CMakeLists.txt b/clang/CMakeLists.txt
index 2ca6db02e58791..c7461bc510e4ac 100644
--- a/clang/CMakeLists.txt
+++ b/clang/CMakeLists.txt
@@ -241,6 +241,10 @@ set(CLANG_SYSTEMZ_DEFAULT_ARCH "z10" CACHE STRING "SystemZ 
Default Arch")
 set(CLANG_VENDOR ${PACKAGE_VENDOR} CACHE STRING
   "Vendor-specific text for showing with version information.")
 
+if(CLANG_VENDOR)
+  add_definitions(-DCLANG_VENDOR="${CLANG_VENDOR}")
+endif()
+
 set(CLANG_REPOSITORY_STRING "" CACHE STRING
   "Vendor-specific text for showing the repository the source is taken from.")
 
diff --git a/clang/lib/Basic/CMakeLists.txt b/clang/lib/Basic/CMakeLists.txt
index 2e218ba7c84cca..6b6fde9b5a9a6b 100644
--- a/clang/lib/Basic/CMakeLists.txt
+++ b/clang/lib/Basic/CMakeLists.txt
@@ -49,11 +49,6 @@ set_source_files_properties("${version_inc}"
   PROPERTIES GENERATED TRUE
  HEADER_FILE_ONLY TRUE)
 
-if(CLANG_VENDOR)
-  set_source_files_properties(Version.cpp
-PROPERTIES COMPILE_DEFINITIONS "CLANG_VENDOR=\"${CLANG_VENDOR} \"")
-endif()
-
 add_clang_library(clangBasic
   Attributes.cpp
   Builtins.cpp
diff --git a/clang/lib/CodeGen/CodeGenModule.cpp 
b/clang/lib/CodeGen/CodeGenModule.cpp
index 7ad26ace328ab2..c8007aef675cb4 100644
--- a/clang/lib/CodeGen/CodeGenModule.cpp
+++ b/clang/lib/CodeGen/CodeGenModule.cpp
@@ -997,7 +997,7 @@ void CodeGenModule::Release() {
   uint32_t(CLANG_VERSION_PATCHLEVEL));
 std::string ProductId;
 #ifdef CLANG_VENDOR
-ProductId = #CLANG_VENDOR;
+ProductId = CLANG_VENDOR;
 #else
 ProductId = "clang";
 #endif

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][CodeGen] Always use CLANG_VENDOR as a quoted string (PR #75935)

2023-12-20 Thread Dimitry Andric via cfe-commits


https://github.com/DimitryAndric updated 
https://github.com/llvm/llvm-project/pull/75935

>From 4b3db6bdaf9f94277f23bf9a796f474a353e4d73 Mon Sep 17 00:00:00 2001
From: Dimitry Andric 
Date: Tue, 19 Dec 2023 13:37:37 +0100
Subject: [PATCH] [clang] Add getClangVendor() and use it in CodeGenModule.cpp

In 9a38a72f1d482 `ProductId` was assigned from the stringified value of
`CLANG_VENDOR`, if that macro was defined. However, `CLANG_VENDOR` is
supposed to be a string, as it is defined (optionally) as such in the
top-level clang `CMakeLists.txt`.

Furthermore, `CLANG_VENDOR` is only passed as a build-time define when
compiling `Version.cpp`, so add a `getClangVendor()` function to
`Version.h`, and use it in `CodegGenModule.cpp`, instead of relying on
the macro.

Fixes: 9a38a72f1d482
---
 clang/include/clang/Basic/Version.h |  3 +++
 clang/lib/Basic/Version.cpp | 19 +++
 clang/lib/CodeGen/CodeGenModule.cpp |  7 +--
 3 files changed, 15 insertions(+), 14 deletions(-)

diff --git a/clang/include/clang/Basic/Version.h 
b/clang/include/clang/Basic/Version.h
index 2881d8db954e0b..8e4e6928fded50 100644
--- a/clang/include/clang/Basic/Version.h
+++ b/clang/include/clang/Basic/Version.h
@@ -40,6 +40,9 @@ namespace clang {
   /// string as getClangRevision.
   std::string getLLVMRevision();
 
+  /// Retrieves the Clang vendor tag.
+  std::string getClangVendor();
+
   /// Retrieves the full repository version that is an amalgamation of
   /// the information in getClangRepositoryPath() and getClangRevision().
   std::string getClangFullRepositoryVersion();
diff --git a/clang/lib/Basic/Version.cpp b/clang/lib/Basic/Version.cpp
index e205da7adec1d8..67aa653770df93 100644
--- a/clang/lib/Basic/Version.cpp
+++ b/clang/lib/Basic/Version.cpp
@@ -57,6 +57,15 @@ std::string getLLVMRevision() {
 #endif
 }
 
+std::string getClangVendor()
+{
+#ifdef CLANG_VENDOR
+  return CLANG_VENDOR;
+#else
+  return "";
+#endif
+}
+
 std::string getClangFullRepositoryVersion() {
   std::string buf;
   llvm::raw_string_ostream OS(buf);
@@ -92,10 +101,7 @@ std::string getClangFullVersion() {
 std::string getClangToolFullVersion(StringRef ToolName) {
   std::string buf;
   llvm::raw_string_ostream OS(buf);
-#ifdef CLANG_VENDOR
-  OS << CLANG_VENDOR;
-#endif
-  OS << ToolName << " version " CLANG_VERSION_STRING;
+  OS << getClangVendor() << ToolName << " version " CLANG_VERSION_STRING;
 
   std::string repo = getClangFullRepositoryVersion();
   if (!repo.empty()) {
@@ -110,10 +116,7 @@ std::string getClangFullCPPVersion() {
   // the one we report on the command line.
   std::string buf;
   llvm::raw_string_ostream OS(buf);
-#ifdef CLANG_VENDOR
-  OS << CLANG_VENDOR;
-#endif
-  OS << "Clang " CLANG_VERSION_STRING;
+  OS << getClangVendor() << "Clang " CLANG_VERSION_STRING;
 
   std::string repo = getClangFullRepositoryVersion();
   if (!repo.empty()) {
diff --git a/clang/lib/CodeGen/CodeGenModule.cpp 
b/clang/lib/CodeGen/CodeGenModule.cpp
index 7ad26ace328ab2..b2e173d0d6949e 100644
--- a/clang/lib/CodeGen/CodeGenModule.cpp
+++ b/clang/lib/CodeGen/CodeGenModule.cpp
@@ -995,12 +995,7 @@ void CodeGenModule::Release() {
   uint32_t(CLANG_VERSION_MINOR));
 getModule().addModuleFlag(llvm::Module::Warning, "zos_product_patchlevel",
   uint32_t(CLANG_VERSION_PATCHLEVEL));
-std::string ProductId;
-#ifdef CLANG_VENDOR
-ProductId = #CLANG_VENDOR;
-#else
-ProductId = "clang";
-#endif
+std::string ProductId = getClangVendor() + "clang";
 getModule().addModuleFlag(llvm::Module::Error, "zos_product_id",
   llvm::MDString::get(VMContext, ProductId));
 

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Add getClangVendor() and use it in CodeGenModule.cpp (PR #75935)

2023-12-20 Thread Dimitry Andric via cfe-commits


https://github.com/DimitryAndric edited 
https://github.com/llvm/llvm-project/pull/75935
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Add getClangVendor() and use it in CodeGenModule.cpp (PR #75935)

2023-12-20 Thread Dimitry Andric via cfe-commits


https://github.com/DimitryAndric updated 
https://github.com/llvm/llvm-project/pull/75935

>From ab5263e77e19ede918faf517dd348018c1982590 Mon Sep 17 00:00:00 2001
From: Dimitry Andric 
Date: Tue, 19 Dec 2023 13:37:37 +0100
Subject: [PATCH] [clang] Add getClangVendor() and use it in CodeGenModule.cpp

In 9a38a72f1d482 `ProductId` was assigned from the stringified value of
`CLANG_VENDOR`, if that macro was defined. However, `CLANG_VENDOR` is
supposed to be a string, as it is defined (optionally) as such in the
top-level clang `CMakeLists.txt`.

Furthermore, `CLANG_VENDOR` is only passed as a build-time define when
compiling `Version.cpp`, so add a `getClangVendor()` function to
`Version.h`, and use it in `CodegGenModule.cpp`, instead of relying on
the macro.

Fixes: 9a38a72f1d482
---
 clang/include/clang/Basic/Version.h |  3 +++
 clang/lib/Basic/Version.cpp | 18 ++
 clang/lib/CodeGen/CodeGenModule.cpp |  7 +--
 3 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/clang/include/clang/Basic/Version.h 
b/clang/include/clang/Basic/Version.h
index 2881d8db954e0b..8e4e6928fded50 100644
--- a/clang/include/clang/Basic/Version.h
+++ b/clang/include/clang/Basic/Version.h
@@ -40,6 +40,9 @@ namespace clang {
   /// string as getClangRevision.
   std::string getLLVMRevision();
 
+  /// Retrieves the Clang vendor tag.
+  std::string getClangVendor();
+
   /// Retrieves the full repository version that is an amalgamation of
   /// the information in getClangRepositoryPath() and getClangRevision().
   std::string getClangFullRepositoryVersion();
diff --git a/clang/lib/Basic/Version.cpp b/clang/lib/Basic/Version.cpp
index e205da7adec1d8..4823f566bd7732 100644
--- a/clang/lib/Basic/Version.cpp
+++ b/clang/lib/Basic/Version.cpp
@@ -57,6 +57,14 @@ std::string getLLVMRevision() {
 #endif
 }
 
+std::string getClangVendor() {
+#ifdef CLANG_VENDOR
+  return CLANG_VENDOR;
+#else
+  return "";
+#endif
+}
+
 std::string getClangFullRepositoryVersion() {
   std::string buf;
   llvm::raw_string_ostream OS(buf);
@@ -92,10 +100,7 @@ std::string getClangFullVersion() {
 std::string getClangToolFullVersion(StringRef ToolName) {
   std::string buf;
   llvm::raw_string_ostream OS(buf);
-#ifdef CLANG_VENDOR
-  OS << CLANG_VENDOR;
-#endif
-  OS << ToolName << " version " CLANG_VERSION_STRING;
+  OS << getClangVendor() << ToolName << " version " CLANG_VERSION_STRING;
 
   std::string repo = getClangFullRepositoryVersion();
   if (!repo.empty()) {
@@ -110,10 +115,7 @@ std::string getClangFullCPPVersion() {
   // the one we report on the command line.
   std::string buf;
   llvm::raw_string_ostream OS(buf);
-#ifdef CLANG_VENDOR
-  OS << CLANG_VENDOR;
-#endif
-  OS << "Clang " CLANG_VERSION_STRING;
+  OS << getClangVendor() << "Clang " CLANG_VERSION_STRING;
 
   std::string repo = getClangFullRepositoryVersion();
   if (!repo.empty()) {
diff --git a/clang/lib/CodeGen/CodeGenModule.cpp 
b/clang/lib/CodeGen/CodeGenModule.cpp
index 7ad26ace328ab2..b2e173d0d6949e 100644
--- a/clang/lib/CodeGen/CodeGenModule.cpp
+++ b/clang/lib/CodeGen/CodeGenModule.cpp
@@ -995,12 +995,7 @@ void CodeGenModule::Release() {
   uint32_t(CLANG_VERSION_MINOR));
 getModule().addModuleFlag(llvm::Module::Warning, "zos_product_patchlevel",
   uint32_t(CLANG_VERSION_PATCHLEVEL));
-std::string ProductId;
-#ifdef CLANG_VENDOR
-ProductId = #CLANG_VENDOR;
-#else
-ProductId = "clang";
-#endif
+std::string ProductId = getClangVendor() + "clang";
 getModule().addModuleFlag(llvm::Module::Error, "zos_product_id",
   llvm::MDString::get(VMContext, ProductId));
 

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Add getClangVendor() and use it in CodeGenModule.cpp (PR #75935)

2023-12-20 Thread Dimitry Andric via cfe-commits



@@ -995,12 +995,7 @@ void CodeGenModule::Release() {
   uint32_t(CLANG_VERSION_MINOR));
 getModule().addModuleFlag(llvm::Module::Warning, "zos_product_patchlevel",
   uint32_t(CLANG_VERSION_PATCHLEVEL));
-std::string ProductId;
-#ifdef CLANG_VENDOR
-ProductId = #CLANG_VENDOR;
-#else
-ProductId = "clang";
-#endif
+std::string ProductId = getClangVendor() + "clang";

DimitryAndric wrote:

Note that this is the way you are supposed to get a "product-id-with-vendor", 
as the vendor tag itself normally does not contain the word "clang". For 
example, FreeBSD uses "FreeBSD " (so with a trailing space), and Apple uses 
"Apple " (also with trailing space). If any space is desired between the vendor 
tag and the word "clang", it has to be specified in the vendor tag, and not 
appended here in the string concatenation.

https://github.com/llvm/llvm-project/pull/75935
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Driver] Remove support for FreeBSD 11.x (PR #73392)

2023-11-30 Thread Dimitry Andric via cfe-commits


DimitryAndric wrote:

Yes, this should be fine.

https://github.com/llvm/llvm-project/pull/73392
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Add getClangVendor() and use it in CodeGenModule.cpp (PR #75935)

2023-12-20 Thread Dimitry Andric via cfe-commits


https://github.com/DimitryAndric closed 
https://github.com/llvm/llvm-project/pull/75935
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 5c1a41f - Revert "[clang] Add getClangVendor() and use it in CodeGenModule.cpp (#75935)"

2023-12-20 Thread Dimitry Andric via cfe-commits


Author: Dimitry Andric
Date: 2023-12-20T20:07:22+01:00
New Revision: 5c1a41f8ad0c02a24345efb4adc424396b7e446b

URL: 
https://github.com/llvm/llvm-project/commit/5c1a41f8ad0c02a24345efb4adc424396b7e446b
DIFF: 
https://github.com/llvm/llvm-project/commit/5c1a41f8ad0c02a24345efb4adc424396b7e446b.diff

LOG: Revert "[clang] Add getClangVendor() and use it in CodeGenModule.cpp 
(#75935)"

This reverts commit 9055519103eadfba0b48810be926883a71890c55, due to an
incorrectly chosen commit message.

Added: 


Modified: 
clang/include/clang/Basic/Version.h
clang/lib/Basic/Version.cpp
clang/lib/CodeGen/CodeGenModule.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/Version.h 
b/clang/include/clang/Basic/Version.h
index 8e4e6928fded50..2881d8db954e0b 100644
--- a/clang/include/clang/Basic/Version.h
+++ b/clang/include/clang/Basic/Version.h
@@ -40,9 +40,6 @@ namespace clang {
   /// string as getClangRevision.
   std::string getLLVMRevision();
 
-  /// Retrieves the Clang vendor tag.
-  std::string getClangVendor();
-
   /// Retrieves the full repository version that is an amalgamation of
   /// the information in getClangRepositoryPath() and getClangRevision().
   std::string getClangFullRepositoryVersion();

diff  --git a/clang/lib/Basic/Version.cpp b/clang/lib/Basic/Version.cpp
index 4823f566bd7732..e205da7adec1d8 100644
--- a/clang/lib/Basic/Version.cpp
+++ b/clang/lib/Basic/Version.cpp
@@ -57,14 +57,6 @@ std::string getLLVMRevision() {
 #endif
 }
 
-std::string getClangVendor() {
-#ifdef CLANG_VENDOR
-  return CLANG_VENDOR;
-#else
-  return "";
-#endif
-}
-
 std::string getClangFullRepositoryVersion() {
   std::string buf;
   llvm::raw_string_ostream OS(buf);
@@ -100,7 +92,10 @@ std::string getClangFullVersion() {
 std::string getClangToolFullVersion(StringRef ToolName) {
   std::string buf;
   llvm::raw_string_ostream OS(buf);
-  OS << getClangVendor() << ToolName << " version " CLANG_VERSION_STRING;
+#ifdef CLANG_VENDOR
+  OS << CLANG_VENDOR;
+#endif
+  OS << ToolName << " version " CLANG_VERSION_STRING;
 
   std::string repo = getClangFullRepositoryVersion();
   if (!repo.empty()) {
@@ -115,7 +110,10 @@ std::string getClangFullCPPVersion() {
   // the one we report on the command line.
   std::string buf;
   llvm::raw_string_ostream OS(buf);
-  OS << getClangVendor() << "Clang " CLANG_VERSION_STRING;
+#ifdef CLANG_VENDOR
+  OS << CLANG_VENDOR;
+#endif
+  OS << "Clang " CLANG_VERSION_STRING;
 
   std::string repo = getClangFullRepositoryVersion();
   if (!repo.empty()) {

diff  --git a/clang/lib/CodeGen/CodeGenModule.cpp 
b/clang/lib/CodeGen/CodeGenModule.cpp
index b2e173d0d6949e..7ad26ace328ab2 100644
--- a/clang/lib/CodeGen/CodeGenModule.cpp
+++ b/clang/lib/CodeGen/CodeGenModule.cpp
@@ -995,7 +995,12 @@ void CodeGenModule::Release() {
   uint32_t(CLANG_VERSION_MINOR));
 getModule().addModuleFlag(llvm::Module::Warning, "zos_product_patchlevel",
   uint32_t(CLANG_VERSION_PATCHLEVEL));
-std::string ProductId = getClangVendor() + "clang";
+std::string ProductId;
+#ifdef CLANG_VENDOR
+ProductId = #CLANG_VENDOR;
+#else
+ProductId = "clang";
+#endif
 getModule().addModuleFlag(llvm::Module::Error, "zos_product_id",
   llvm::MDString::get(VMContext, ProductId));
 



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 2c27013 - [clang] Add getClangVendor() and use it in CodeGenModule.cpp (#75935)

2023-12-20 Thread Dimitry Andric via cfe-commits


Author: Dimitry Andric
Date: 2023-12-20T20:09:39+01:00
New Revision: 2c27013fa918211816d24c9d2530469fd822bc00

URL: 
https://github.com/llvm/llvm-project/commit/2c27013fa918211816d24c9d2530469fd822bc00
DIFF: 
https://github.com/llvm/llvm-project/commit/2c27013fa918211816d24c9d2530469fd822bc00.diff

LOG: [clang] Add getClangVendor() and use it in CodeGenModule.cpp (#75935)

In 9a38a72f1d482 `ProductId` was assigned from the stringified value of
`CLANG_VENDOR`, if that macro was defined. However, `CLANG_VENDOR` is
supposed to be a string, as it is defined (optionally) as such in the
top-level clang `CMakeLists.txt`.

Furthermore, `CLANG_VENDOR` is only passed as a build-time define when
compiling `Version.cpp`, so add a `getClangVendor()` function to
`Version.h`, and use it in `CodegGenModule.cpp`, instead of relying on
the macro.

Fixes: 9a38a72f1d482

Added: 


Modified: 
clang/include/clang/Basic/Version.h
clang/lib/Basic/Version.cpp
clang/lib/CodeGen/CodeGenModule.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/Version.h 
b/clang/include/clang/Basic/Version.h
index 2881d8db954e0b..8e4e6928fded50 100644
--- a/clang/include/clang/Basic/Version.h
+++ b/clang/include/clang/Basic/Version.h
@@ -40,6 +40,9 @@ namespace clang {
   /// string as getClangRevision.
   std::string getLLVMRevision();
 
+  /// Retrieves the Clang vendor tag.
+  std::string getClangVendor();
+
   /// Retrieves the full repository version that is an amalgamation of
   /// the information in getClangRepositoryPath() and getClangRevision().
   std::string getClangFullRepositoryVersion();

diff  --git a/clang/lib/Basic/Version.cpp b/clang/lib/Basic/Version.cpp
index e205da7adec1d8..4823f566bd7732 100644
--- a/clang/lib/Basic/Version.cpp
+++ b/clang/lib/Basic/Version.cpp
@@ -57,6 +57,14 @@ std::string getLLVMRevision() {
 #endif
 }
 
+std::string getClangVendor() {
+#ifdef CLANG_VENDOR
+  return CLANG_VENDOR;
+#else
+  return "";
+#endif
+}
+
 std::string getClangFullRepositoryVersion() {
   std::string buf;
   llvm::raw_string_ostream OS(buf);
@@ -92,10 +100,7 @@ std::string getClangFullVersion() {
 std::string getClangToolFullVersion(StringRef ToolName) {
   std::string buf;
   llvm::raw_string_ostream OS(buf);
-#ifdef CLANG_VENDOR
-  OS << CLANG_VENDOR;
-#endif
-  OS << ToolName << " version " CLANG_VERSION_STRING;
+  OS << getClangVendor() << ToolName << " version " CLANG_VERSION_STRING;
 
   std::string repo = getClangFullRepositoryVersion();
   if (!repo.empty()) {
@@ -110,10 +115,7 @@ std::string getClangFullCPPVersion() {
   // the one we report on the command line.
   std::string buf;
   llvm::raw_string_ostream OS(buf);
-#ifdef CLANG_VENDOR
-  OS << CLANG_VENDOR;
-#endif
-  OS << "Clang " CLANG_VERSION_STRING;
+  OS << getClangVendor() << "Clang " CLANG_VERSION_STRING;
 
   std::string repo = getClangFullRepositoryVersion();
   if (!repo.empty()) {

diff  --git a/clang/lib/CodeGen/CodeGenModule.cpp 
b/clang/lib/CodeGen/CodeGenModule.cpp
index 7ad26ace328ab2..b2e173d0d6949e 100644
--- a/clang/lib/CodeGen/CodeGenModule.cpp
+++ b/clang/lib/CodeGen/CodeGenModule.cpp
@@ -995,12 +995,7 @@ void CodeGenModule::Release() {
   uint32_t(CLANG_VERSION_MINOR));
 getModule().addModuleFlag(llvm::Module::Warning, "zos_product_patchlevel",
   uint32_t(CLANG_VERSION_PATCHLEVEL));
-std::string ProductId;
-#ifdef CLANG_VENDOR
-ProductId = #CLANG_VENDOR;
-#else
-ProductId = "clang";
-#endif
+std::string ProductId = getClangVendor() + "clang";
 getModule().addModuleFlag(llvm::Module::Error, "zos_product_id",
   llvm::MDString::get(VMContext, ProductId));
 



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [lld] [llvm] [llvm-driver] Fix usage of `InitLLVM` on Windows (PR #76306)

2024-02-10 Thread Dimitry Andric via cfe-commits


DimitryAndric wrote:

Maybe I'm doing something wrong, but after this commit (and its merge to 18.x) 
I don't see to get stack traces from clang anymore after assertions?  How is 
this supposed to work?


https://github.com/llvm/llvm-project/pull/76306
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [lld] [llvm] [llvm-driver] Fix usage of `InitLLVM` on Windows (PR #76306)

2024-02-10 Thread Dimitry Andric via cfe-commits


DimitryAndric wrote:

Ah that was my error, I hadn't used the regenerated `*-driver.cpp` files. These 
indeed should contain the `InitLLVM` call.

https://github.com/llvm/llvm-project/pull/76306
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libcxx] [clang] [SemaCXX] Implement CWG2137 (list-initialization from objects of the same type) (PR #77768)

2024-01-28 Thread Dimitry Andric via cfe-commits


DimitryAndric wrote:

FWIW I think I just hit this when building llvm itself (though 15.0.6) with a 
recent clang, and getting:

```text
/wrkdirs/usr/ports/devel/llvm15/work-default/llvm-project-15.0.7.src/llvm/tools/sancov/sancov.cpp:532:44:
 error: chosen constructor is explicit in copy-initialization
  532 |   return SpecialCaseList::createOrDie({{ClBlacklist}},
  |^
/usr/include/c++/v1/string:1047:93: note: explicit constructor declared here
 1047 |   _LIBCPP_METHOD_TEMPLATE_IMPLICIT_INSTANTIATION_VIS 
_LIBCPP_CONSTEXPR_SINCE_CXX20 explicit basic_string(const _Tp& __t)
  | 
^
/usr/include/c++/v1/vector:509:91: note: passing argument to parameter '__il' 
here
  509 |   _LIBCPP_CONSTEXPR_SINCE_CXX20 _LIBCPP_HIDE_FROM_ABI 
vector(initializer_list __il);
  | 
  ^
/wrkdirs/usr/ports/devel/llvm15/work-default/llvm-project-15.0.7.src/llvm/tools/sancov/sancov.cpp:535:42:
 error: chosen constructor is explicit in copy-initialization
  535 | return SpecialCaseList::createOrDie({{ClIgnorelist}},
  |  ^~
/usr/include/c++/v1/string:1047:93: note: explicit constructor declared here
 1047 |   _LIBCPP_METHOD_TEMPLATE_IMPLICIT_INSTANTIATION_VIS 
_LIBCPP_CONSTEXPR_SINCE_CXX20 explicit basic_string(const _Tp& __t)
  | 
^
/usr/include/c++/v1/vector:509:91: note: passing argument to parameter '__il' 
here
  509 |   _LIBCPP_CONSTEXPR_SINCE_CXX20 _LIBCPP_HIDE_FROM_ABI 
vector(initializer_list __il);
  | 
  ^
2 errors generated.
```

I didn't managed to fully bisect it yet, but it looks very much like 
924701311aa79180e86ad8ce43d253f27d25ec7d for this issue is the culprit.

So has that now been reverted, and is the reversal also merged into the 18.x 
release branch?


https://github.com/llvm/llvm-project/pull/77768
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] fc2dac4 - [PPC] Fix platform definitions when compiling FreeBSD powerpc64 as LE

2020-08-29 Thread Dimitry Andric via cfe-commits


Author: Dimitry Andric
Date: 2020-08-29T12:03:20+02:00
New Revision: fc2dac4116df62c25396b15ec9730f67a0b1aac7

URL: 
https://github.com/llvm/llvm-project/commit/fc2dac4116df62c25396b15ec9730f67a0b1aac7
DIFF: 
https://github.com/llvm/llvm-project/commit/fc2dac4116df62c25396b15ec9730f67a0b1aac7.diff

LOG: [PPC] Fix platform definitions when compiling FreeBSD powerpc64 as LE

As a prerequisite to doing experimental buids of pieces of FreeBSD PowerPC64 as 
little-endian, allow actually targeting it.

This is needed so basic platform definitions are pulled in. Without it, the 
compiler will only run freestanding.

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D73425

Added: 


Modified: 
clang/lib/Basic/Targets.cpp
clang/test/CodeGen/target-data.c
clang/test/Driver/freebsd.c
clang/test/Driver/ppc-abi.c
clang/test/Preprocessor/init-ppc64.c

Removed: 




diff  --git a/clang/lib/Basic/Targets.cpp b/clang/lib/Basic/Targets.cpp
index 933b7b342891..c0187fd27842 100644
--- a/clang/lib/Basic/Targets.cpp
+++ b/clang/lib/Basic/Targets.cpp
@@ -358,6 +358,8 @@ TargetInfo *AllocateTarget(const llvm::Triple &Triple,
 switch (os) {
 case llvm::Triple::Linux:
   return new LinuxTargetInfo(Triple, Opts);
+case llvm::Triple::FreeBSD:
+  return new FreeBSDTargetInfo(Triple, Opts);
 case llvm::Triple::NetBSD:
   return new NetBSDTargetInfo(Triple, Opts);
 case llvm::Triple::OpenBSD:

diff  --git a/clang/test/CodeGen/target-data.c 
b/clang/test/CodeGen/target-data.c
index 4f2dbe7c8e10..0ba20d568a08 100644
--- a/clang/test/CodeGen/target-data.c
+++ b/clang/test/CodeGen/target-data.c
@@ -130,6 +130,10 @@
 // RUN: FileCheck %s -check-prefix=PPC64-FREEBSD
 // PPC64-FREEBSD: target datalayout = "E-m:e-i64:64-n32:64"
 
+// RUN: %clang_cc1 -triple powerpc64le-freebsd -o - -emit-llvm %s | \
+// RUN: FileCheck %s -check-prefix=PPC64LE-FREEBSD
+// PPC64LE-FREEBSD: target datalayout = "e-m:e-i64:64-n32:64"
+
 // RUN: %clang_cc1 -triple powerpc64-linux -o - -emit-llvm %s | \
 // RUN: FileCheck %s -check-prefix=PPC64-LINUX
 // PPC64-LINUX: target datalayout = "E-m:e-i64:64-n32:64"

diff  --git a/clang/test/Driver/freebsd.c b/clang/test/Driver/freebsd.c
index 5eb00ce65d71..769bb22da0dc 100644
--- a/clang/test/Driver/freebsd.c
+++ b/clang/test/Driver/freebsd.c
@@ -21,7 +21,15 @@
 // CHECK-PPC64: "-cc1" "-triple" "powerpc64-pc-freebsd8"
 // CHECK-PPC64: ld{{.*}}" "--sysroot=[[SYSROOT:[^"]+]]"
 // CHECK-PPC64: "--eh-frame-hdr" "-dynamic-linker" "{{.*}}ld-elf{{.*}}" "-o" 
"a.out" "{{.*}}crt1.o" "{{.*}}crti.o" "{{.*}}crtbegin.o" 
"-L[[SYSROOT]]/usr/lib" "{{.*}}.o" "-lgcc" "--as-needed" "-lgcc_s" 
"--no-as-needed" "-lc" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" 
"{{.*}}crtend.o" "{{.*}}crtn.o"
-//
+
+// RUN: %clang -no-canonical-prefixes \
+// RUN:   -target powerpc64le-unknown-freebsd13 %s \
+// RUN:   --sysroot=%S/Inputs/basic_freebsd64_tree -### 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-PPC64LE %s
+// CHECK-PPC64LE: "-cc1" "-triple" "powerpc64le-unknown-freebsd13"
+// CHECK-PPC64LE: ld{{.*}}" "--sysroot=[[SYSROOT:[^"]+]]"
+// CHECK-PPC64LE: "--eh-frame-hdr" "-dynamic-linker" "{{.*}}ld-elf{{.*}}" "-o" 
"a.out" "{{.*}}crt1.o" "{{.*}}crti.o" "{{.*}}crtbegin.o" 
"-L[[SYSROOT]]/usr/lib" "{{.*}}.o" "-lgcc" "--as-needed" "-lgcc_s" 
"--no-as-needed" "-lc" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" 
"{{.*}}crtend.o" "{{.*}}crtn.o"
+
 //
 // Check that -m32 properly adjusts the toolchain flags.
 //

diff  --git a/clang/test/Driver/ppc-abi.c b/clang/test/Driver/ppc-abi.c
index 491f9336a5c3..a74a19953ca2 100644
--- a/clang/test/Driver/ppc-abi.c
+++ b/clang/test/Driver/ppc-abi.c
@@ -20,6 +20,7 @@
 // RUN: %clang -target powerpc64-unknown-freebsd12 %s -### 2>&1 | FileCheck 
--check-prefix=CHECK-ELFv1 %s
 // RUN: %clang -target powerpc64-unknown-freebsd13 %s -### 2>&1 | FileCheck 
--check-prefix=CHECK-ELFv2-BE %s
 // RUN: %clang -target powerpc64-unknown-freebsd14 %s -### 2>&1 | FileCheck 
--check-prefix=CHECK-ELFv2-BE %s
+// RUN: %clang -target powerpc64le-unknown-freebsd13 %s -### 2>&1 | FileCheck 
--check-prefix=CHECK-ELFv2 %s
 // RUN: %clang -target powerpc64-unknown-openbsd %s -### 2>&1 | FileCheck 
--check-prefix=CHECK-ELFv2-BE-PIE %s
 // RUN: %clang -target powerpc64-linux-musl %s -### 2>&1 | FileCheck 
--check-prefix=CHECK-ELFv2-BE-PIE %s
 

diff  --git a/clang/test/Preprocessor/init-ppc64.c 
b/clang/test/Preprocessor/init-ppc64.c
index cffd82fdf3c5..b553d07183ec 100644
--- a/clang/test/Preprocessor/init-ppc64.c
+++ b/clang/test/Preprocessor/init-ppc64.c
@@ -1067,6 +1067,7 @@
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc64-unknown-freebsd11 
-target-abi elfv1 -xc /dev/null | FileCheck --check-prefix=PPC64-ELFv1 %s
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc64-unknown-freebsd12 
-target-abi elfv1 -xc /dev/null | FileCheck --check-prefix=PPC64-ELF

[clang] df08b2f - [AArch64] Avoid crashing on invalid -Wa, -march= values

2021-11-28 Thread Dimitry Andric via cfe-commits


Author: Dimitry Andric
Date: 2021-11-28T22:23:42+01:00
New Revision: df08b2fe8b35cb63dfb3b49738a3494b9b4e6f8e

URL: 
https://github.com/llvm/llvm-project/commit/df08b2fe8b35cb63dfb3b49738a3494b9b4e6f8e
DIFF: 
https://github.com/llvm/llvm-project/commit/df08b2fe8b35cb63dfb3b49738a3494b9b4e6f8e.diff

LOG: [AArch64] Avoid crashing on invalid -Wa,-march= values

As reported in https://bugs.freebsd.org/260078, the gnutls Makefiles
pass -Wa,-march=all to compile a number of assembly files. Clang does
not support this -march value, but because of a mistake in handling
the arguments, an unitialized Arg pointer is dereferenced, which can
cause a segfault.

Work around this by adding a check if the local WaMArch variable is
initialized, and if so, using its value in the diagnostic message.

Reviewed By: tschuett

Differential Revision: https://reviews.llvm.org/D114677

Added: 


Modified: 
clang/lib/Driver/ToolChains/Arch/AArch64.cpp
clang/test/Driver/aarch64-target-as-march.s

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Arch/AArch64.cpp 
b/clang/lib/Driver/ToolChains/Arch/AArch64.cpp
index 0b60d097b9ca3..abc32f22d2a1b 100644
--- a/clang/lib/Driver/ToolChains/Arch/AArch64.cpp
+++ b/clang/lib/Driver/ToolChains/Arch/AArch64.cpp
@@ -225,7 +225,7 @@ void aarch64::getAArch64TargetFeatures(const Driver &D,
   bool success = true;
   // Enable NEON by default.
   Features.push_back("+neon");
-  llvm::StringRef WaMArch = "";
+  llvm::StringRef WaMArch;
   if (ForAS)
 for (const auto *A :
  Args.filtered(options::OPT_Wa_COMMA, options::OPT_Xassembler))
@@ -235,7 +235,7 @@ void aarch64::getAArch64TargetFeatures(const Driver &D,
   // Call getAArch64ArchFeaturesFromMarch only if "-Wa,-march=" or
   // "-Xassembler -march" is detected. Otherwise it may return false
   // and causes Clang to error out.
-  if (WaMArch.size())
+  if (!WaMArch.empty())
 success = getAArch64ArchFeaturesFromMarch(D, WaMArch, Args, Features);
   else if ((A = Args.getLastArg(options::OPT_march_EQ)))
 success = getAArch64ArchFeaturesFromMarch(D, A->getValue(), Args, 
Features);
@@ -259,8 +259,15 @@ void aarch64::getAArch64TargetFeatures(const Driver &D,
 success = getAArch64MicroArchFeaturesFromMcpu(
 D, getAArch64TargetCPU(Args, Triple, A), Args, Features);
 
-  if (!success)
-D.Diag(diag::err_drv_clang_unsupported) << A->getAsString(Args);
+  if (!success) {
+auto Diag = D.Diag(diag::err_drv_clang_unsupported);
+// If "-Wa,-march=" is used, 'WaMArch' will contain the argument's value,
+// while 'A' is uninitialized. Only dereference 'A' in the other case.
+if (!WaMArch.empty())
+  Diag << "-march=" + WaMArch.str();
+else
+  Diag << A->getAsString(Args);
+  }
 
   if (Args.getLastArg(options::OPT_mgeneral_regs_only)) {
 Features.push_back("-fp-armv8");

diff  --git a/clang/test/Driver/aarch64-target-as-march.s 
b/clang/test/Driver/aarch64-target-as-march.s
index a9301ade43351..03c3e395230df 100644
--- a/clang/test/Driver/aarch64-target-as-march.s
+++ b/clang/test/Driver/aarch64-target-as-march.s
@@ -44,3 +44,12 @@
 // TARGET-FEATURE-3-NOT: "-target-feature" "+v8.4a"
 // TARGET-FEATURE-4: "-target-feature" "+v8.4a"
 // TARGET-FEATURE-4-NOT: "-target-feature" "+v8.3a"
+
+// Invalid -march settings
+// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Wa,-march=all %s 2>&1 | 
\
+// RUN: FileCheck --check-prefix=INVALID-ARCH-1 %s
+// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Wa,-march=foobar %s 
2>&1 | \
+// RUN: FileCheck --check-prefix=INVALID-ARCH-2 %s
+
+// INVALID-ARCH-1: error: the clang compiler does not support '-march=all'
+// INVALID-ARCH-2: error: the clang compiler does not support '-march=foobar'



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Driver] Silence stdlib warning when linking C on FreeBSD (PR #68011)

2023-10-06 Thread Dimitry Andric via cfe-commits


DimitryAndric wrote:

Does this only affect cases where one passes `-stdlib=libc++`? What happens if 
somebody passes `-stdlib=libstdc++`?


https://github.com/llvm/llvm-project/pull/68011
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] ee31adb - Populate CUDA flags on FreeBSD too, as many other toolchains do.

2019-11-18 Thread Dimitry Andric via cfe-commits


Author: Dimitry Andric
Date: 2019-11-18T21:54:25+01:00
New Revision: ee31adb7fa42f5b601d9612f23755b4604f83cac

URL: 
https://github.com/llvm/llvm-project/commit/ee31adb7fa42f5b601d9612f23755b4604f83cac
DIFF: 
https://github.com/llvm/llvm-project/commit/ee31adb7fa42f5b601d9612f23755b4604f83cac.diff

LOG: Populate CUDA flags on FreeBSD too, as many other toolchains do.

Summary:
This allows `clang` to be used to compile CUDA programs. Compiled
simple helloworld.cu with this.

Reviewers: dim, emaste, tra, yaxunl, ABataev

Reviewed By: tra

Subscribers: dim, emaste, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D69990

Added: 
clang/test/Driver/cuda-options-freebsd.cu

Modified: 
clang/lib/Driver/ToolChains/FreeBSD.cpp
clang/lib/Driver/ToolChains/FreeBSD.h

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/FreeBSD.cpp 
b/clang/lib/Driver/ToolChains/FreeBSD.cpp
index 5e2c4883290f..3e5e8a00652d 100644
--- a/clang/lib/Driver/ToolChains/FreeBSD.cpp
+++ b/clang/lib/Driver/ToolChains/FreeBSD.cpp
@@ -397,6 +397,11 @@ void FreeBSD::AddCXXStdlibLibArgs(const ArgList &Args,
   }
 }
 
+void FreeBSD::AddCudaIncludeArgs(const ArgList &DriverArgs,
+ ArgStringList &CC1Args) const {
+  CudaInstallation.AddCudaIncludeArgs(DriverArgs, CC1Args);
+}
+
 Tool *FreeBSD::buildAssembler() const {
   return new tools::freebsd::Assembler(*this);
 }

diff  --git a/clang/lib/Driver/ToolChains/FreeBSD.h 
b/clang/lib/Driver/ToolChains/FreeBSD.h
index 1d503a621d0e..53bc5265c9e2 100644
--- a/clang/lib/Driver/ToolChains/FreeBSD.h
+++ b/clang/lib/Driver/ToolChains/FreeBSD.h
@@ -64,6 +64,8 @@ class LLVM_LIBRARY_VISIBILITY FreeBSD : public Generic_ELF {
   llvm::opt::ArgStringList &CC1Args) const override;
   void AddCXXStdlibLibArgs(const llvm::opt::ArgList &Args,
llvm::opt::ArgStringList &CmdArgs) const override;
+  void AddCudaIncludeArgs(const llvm::opt::ArgList &DriverArgs,
+  llvm::opt::ArgStringList &CC1Args) const override;
 
   llvm::ExceptionHandling GetExceptionModel(
   const llvm::opt::ArgList &Args) const override;

diff  --git a/clang/test/Driver/cuda-options-freebsd.cu 
b/clang/test/Driver/cuda-options-freebsd.cu
new file mode 100644
index ..cee38e48b272
--- /dev/null
+++ b/clang/test/Driver/cuda-options-freebsd.cu
@@ -0,0 +1,289 @@
+// Tests CUDA compilation pipeline construction in Driver.
+// REQUIRES: clang-driver
+// REQUIRES: x86-registered-target
+// REQUIRES: nvptx-registered-target
+
+// Simple compilation case. Compile device-side to PTX assembly and make sure
+// we use it on the host side.
+// RUN: %clang -### -target x86_64-unknown-freebsd -c %s 2>&1 \
+// RUN: | FileCheck -check-prefix DEVICE -check-prefix DEVICE-NOSAVE \
+// RUN:-check-prefix HOST -check-prefix INCLUDES-DEVICE \
+// RUN:-check-prefix NOLINK %s
+
+// Typical compilation + link case.
+// RUN: %clang -### -target x86_64-unknown-freebsd %s 2>&1 \
+// RUN: | FileCheck -check-prefix DEVICE -check-prefix DEVICE-NOSAVE \
+// RUN:-check-prefix HOST -check-prefix INCLUDES-DEVICE \
+// RUN:-check-prefix LINK %s
+
+// Verify that --cuda-host-only disables device-side compilation, but doesn't
+// disable host-side compilation/linking.
+// RUN: %clang -### -target x86_64-unknown-freebsd --cuda-host-only %s 2>&1 \
+// RUN: | FileCheck -check-prefix NODEVICE -check-prefix HOST \
+// RUN:-check-prefix NOINCLUDES-DEVICE -check-prefix LINK %s
+
+// Verify that --cuda-device-only disables host-side compilation and linking.
+// RUN: %clang -### -target x86_64-unknown-freebsd --cuda-device-only %s 2>&1 \
+// RUN: | FileCheck -check-prefix DEVICE -check-prefix DEVICE-NOSAVE \
+// RUN:-check-prefix NOHOST -check-prefix NOLINK %s
+
+// Check that the last of --cuda-compile-host-device, --cuda-host-only, and
+// --cuda-device-only wins.
+
+// RUN: %clang -### -target x86_64-unknown-freebsd --cuda-device-only \
+// RUN:--cuda-host-only %s 2>&1 \
+// RUN: | FileCheck -check-prefix NODEVICE -check-prefix HOST \
+// RUN:-check-prefix NOINCLUDES-DEVICE -check-prefix LINK %s
+
+// RUN: %clang -### -target x86_64-unknown-freebsd --cuda-compile-host-device \
+// RUN:--cuda-host-only %s 2>&1 \
+// RUN: | FileCheck -check-prefix NODEVICE -check-prefix HOST \
+// RUN:-check-prefix NOINCLUDES-DEVICE -check-prefix LINK %s
+
+// RUN: %clang -### -target x86_64-unknown-freebsd --cuda-host-only \
+// RUN:--cuda-device-only %s 2>&1 \
+// RUN: | FileCheck -check-prefix DEVICE -check-prefix DEVICE-NOSAVE \
+// RUN:-check-prefix NOHOST -check-prefix NOLINK %s
+
+// RUN: %clang -### -target x86_64-unknown-freebsd --cuda-compile-host-device \
+// RUN:--cuda-device-only %s 2>&1 \
+// RUN: | FileCheck -check-prefix DEVICE -check-prefix DEVICE-NOSAVE \
+// RUN:-check-prefix NOHOST -check-prefix NOLINK %s
+
+// RU

[clang] 62654ca - Restore functionality of --sysroot on FreeBSD after b18cb9c47

2020-02-15 Thread Dimitry Andric via cfe-commits


Author: Dimitry Andric
Date: 2020-02-16T01:50:06+01:00
New Revision: 62654cab7e654384ba503d6b62b1054cde19a553

URL: 
https://github.com/llvm/llvm-project/commit/62654cab7e654384ba503d6b62b1054cde19a553
DIFF: 
https://github.com/llvm/llvm-project/commit/62654cab7e654384ba503d6b62b1054cde19a553.diff

LOG: Restore functionality of --sysroot on FreeBSD after b18cb9c47

After b18cb9c47, clang would sometimes prefer the host C++ includes
(e.g. in /usr/include/c++/v1) before those specified via --sysroot.
While this behavior may be desirable on Linux, it is not so on FreeBSD,
where we make extensive use of --sysroot during the build of the base
system.  In that case, clang must *not* search outside the sysroot,
except for its own internal headers.

Add an override addLibCxxIncludePaths() to restore the old behavior,
which is to simply append /usr/include/c++/v1 to the specified sysroot.
While here, apply clang-format to the FreeBSD specific toolchain files.

Fixes PR44923.

Added: 


Modified: 
clang/lib/Driver/ToolChains/FreeBSD.cpp
clang/lib/Driver/ToolChains/FreeBSD.h

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/FreeBSD.cpp 
b/clang/lib/Driver/ToolChains/FreeBSD.cpp
index 3f3d6e7c72eb..b2525e427cf9 100644
--- a/clang/lib/Driver/ToolChains/FreeBSD.cpp
+++ b/clang/lib/Driver/ToolChains/FreeBSD.cpp
@@ -99,7 +99,8 @@ void freebsd::Assembler::ConstructJob(Compilation &C, const 
JobAction &JA,
   case llvm::Triple::sparcel:
   case llvm::Triple::sparcv9: {
 std::string CPU = getCPUName(Args, getToolChain().getTriple());
-CmdArgs.push_back(sparc::getSparcAsmModeForCPU(CPU, 
getToolChain().getTriple()));
+CmdArgs.push_back(
+sparc::getSparcAsmModeForCPU(CPU, getToolChain().getTriple()));
 AddAssemblerKPIC(getToolChain(), Args, CmdArgs);
 break;
   }
@@ -388,6 +389,12 @@ unsigned FreeBSD::GetDefaultDwarfVersion() const {
   return 4;
 }
 
+void FreeBSD::addLibCxxIncludePaths(const llvm::opt::ArgList &DriverArgs,
+llvm::opt::ArgStringList &CC1Args) const {
+  addSystemInclude(DriverArgs, CC1Args,
+   getDriver().SysRoot + "/usr/include/c++/v1");
+}
+
 void FreeBSD::addLibStdCxxIncludePaths(
 const llvm::opt::ArgList &DriverArgs,
 llvm::opt::ArgStringList &CC1Args) const {

diff  --git a/clang/lib/Driver/ToolChains/FreeBSD.h 
b/clang/lib/Driver/ToolChains/FreeBSD.h
index 84bdbfd9a312..7e13f48b7167 100644
--- a/clang/lib/Driver/ToolChains/FreeBSD.h
+++ b/clang/lib/Driver/ToolChains/FreeBSD.h
@@ -59,16 +59,18 @@ class LLVM_LIBRARY_VISIBILITY FreeBSD : public Generic_ELF {
   bool IsObjCNonFragileABIDefault() const override { return true; }
 
   CXXStdlibType GetDefaultCXXStdlibType() const override;
-  void addLibStdCxxIncludePaths(
-  const llvm::opt::ArgList &DriverArgs,
-  llvm::opt::ArgStringList &CC1Args) const override;
+  void addLibCxxIncludePaths(const llvm::opt::ArgList &DriverArgs,
+ llvm::opt::ArgStringList &CC1Args) const override;
+  void
+  addLibStdCxxIncludePaths(const llvm::opt::ArgList &DriverArgs,
+   llvm::opt::ArgStringList &CC1Args) const override;
   void AddCXXStdlibLibArgs(const llvm::opt::ArgList &Args,
llvm::opt::ArgStringList &CmdArgs) const override;
   void AddCudaIncludeArgs(const llvm::opt::ArgList &DriverArgs,
   llvm::opt::ArgStringList &CC1Args) const override;
 
-  llvm::ExceptionHandling GetExceptionModel(
-  const llvm::opt::ArgList &Args) const override;
+  llvm::ExceptionHandling
+  GetExceptionModel(const llvm::opt::ArgList &Args) const override;
   bool IsUnwindTablesDefault(const llvm::opt::ArgList &Args) const override;
   bool isPIEDefault() const override;
   SanitizerMask getSupportedSanitizers() const override;



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] 58592f6 - Include for std::abort() in clangd

2020-01-24 Thread Dimitry Andric via cfe-commits


Author: Dimitry Andric
Date: 2020-01-24T20:52:37+01:00
New Revision: 58592f6c49249293f79698cfcb31dba532e12603

URL: 
https://github.com/llvm/llvm-project/commit/58592f6c49249293f79698cfcb31dba532e12603
DIFF: 
https://github.com/llvm/llvm-project/commit/58592f6c49249293f79698cfcb31dba532e12603.diff

LOG: Include  for std::abort() in clangd

This fixes a "not a member of 'std'" error with e.g. Fedora 32.

Closes: #105

Added: 


Modified: 
clang-tools-extra/clangd/Shutdown.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/Shutdown.cpp 
b/clang-tools-extra/clangd/Shutdown.cpp
index dfea46d8dfeb..36d977570a4f 100644
--- a/clang-tools-extra/clangd/Shutdown.cpp
+++ b/clang-tools-extra/clangd/Shutdown.cpp
@@ -9,6 +9,7 @@
 #include "Shutdown.h"
 
 #include 
+#include 
 #include 
 
 namespace clang {



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r329827 - Document -std= values for different languages

2018-04-11 Thread Dimitry Andric via cfe-commits

Author: dim
Date: Wed Apr 11 10:21:52 2018
New Revision: 329827

URL: http://llvm.org/viewvc/llvm-project?rev=329827&view=rev
Log:
Document -std= values for different languages

Summary:
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 exhaustively list those, for each available language.

I also documented the default standard for each language, if there was
more than one choice.

Reviewers: rsmith, dexonsmith, sylvestre.ledru, mgorny

Reviewed By: rsmith

Subscribers: fhahn, emaste, cfe-commits, krytarowski

Differential Revision: https://reviews.llvm.org/D45406

Modified:
cfe/trunk/docs/CommandGuide/clang.rst

Modified: cfe/trunk/docs/CommandGuide/clang.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/CommandGuide/clang.rst?rev=329827&r1=329826&r2=329827&view=diff
==
--- cfe/trunk/docs/CommandGuide/clang.rst (original)
+++ cfe/trunk/docs/CommandGuide/clang.rst Wed Apr 11 10:21:52 2018
@@ -98,10 +98,129 @@ Language Selection and Mode Options
 
  Treat subsequent input files as having type language.
 
-.. option:: -std=
+.. option:: -std=
 
  Specify the language standard to compile for.
 
+ Supported values for the C language are:
+
+  | ``c89``
+  | ``c90``
+  | ``iso9899:1990``
+
+   ISO C 1990
+
+  | ``iso9899:199409``
+
+   ISO C 1990 with amendment 1
+
+  | ``gnu89``
+  | ``gnu90``
+
+   ISO C 1990 with GNU extensions
+
+  | ``c99``
+  | ``iso9899:1999``
+
+   ISO C 1999
+
+  | ``gnu99``
+
+   ISO C 1999 with GNU extensions
+
+  | ``c11``
+  | ``iso9899:2011``
+
+   ISO C 2011
+
+  | ``gnu11``
+
+   ISO C 2011 with GNU extensions
+
+  | ``c17``
+  | ``iso9899:2017``
+
+   ISO C 2017
+
+  | ``gnu17``
+
+   ISO C 2017 with GNU extensions
+
+ The default C language standard is ``gnu11``, except on PS4, where it is
+ ``gnu99``.
+
+ Supported values for the C++ language are:
+
+  | ``c++98``
+  | ``c++03``
+
+   ISO C++ 1998 with amendments
+
+  | ``gnu++98``
+  | ``gnu++03``
+
+   ISO C++ 1998 with amendments and GNU extensions
+
+  | ``c++11``
+
+   ISO C++ 2011 with amendments
+
+  | ``gnu++11``
+
+ISO C++ 2011 with amendments and GNU extensions
+
+  | ``c++14``
+
+   ISO C++ 2014 with amendments
+
+  | ``gnu++14``
+
+   ISO C++ 2014 with amendments and GNU extensions
+
+  | ``c++17``
+
+   ISO C++ 2017 with amendments
+
+  | ``gnu++17``
+
+   ISO C++ 2017 with amendments and GNU extensions
+
+  | ``c++2a``
+
+   Working draft for ISO C++ 2020
+
+  | ``gnu++2a``
+
+   Working draft for ISO C++ 2020 with GNU extensions
+
+ The default C++ language standard is ``gnu++14``.
+
+ Supported values for the OpenCL language are:
+
+  | ``cl1.0``
+
+   OpenCL 1.0
+
+  | ``cl1.1``
+
+   OpenCL 1.1
+
+  | ``cl1.2``
+
+   OpenCL 1.2
+
+  | ``cl2.0``
+
+   OpenCL 2.0
+
+ The default OpenCL language standard is ``cl1.0``.
+
+ Supported values for the CUDA language are:
+
+  | ``cuda``
+
+   NVIDIA CUDA(tm)
+
 .. option:: -stdlib=
 
  Specify the C++ standard library to use; supported options are libstdc++ and


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] c1ee219 - arm_bf16.td: fix copy/paste typo in comment header

2023-04-20 Thread Dimitry Andric via cfe-commits


Author: Dimitry Andric
Date: 2023-04-20T19:43:51+02:00
New Revision: c1ee2192dd0f28cdf02a0544d25d0710c037bf9b

URL: 
https://github.com/llvm/llvm-project/commit/c1ee2192dd0f28cdf02a0544d25d0710c037bf9b
DIFF: 
https://github.com/llvm/llvm-project/commit/c1ee2192dd0f28cdf02a0544d25d0710c037bf9b.diff

LOG: arm_bf16.td: fix copy/paste typo in comment header

Added: 


Modified: 
clang/include/clang/Basic/arm_bf16.td

Removed: 




diff  --git a/clang/include/clang/Basic/arm_bf16.td 
b/clang/include/clang/Basic/arm_bf16.td
index d837a7666d403..f70c7221f8d6d 100644
--- a/clang/include/clang/Basic/arm_bf16.td
+++ b/clang/include/clang/Basic/arm_bf16.td
@@ -1,4 +1,4 @@
-//===--- arm_fp16.td - ARM BF16 compiler interface 
===//
+//===--- arm_bf16.td - ARM BF16 compiler interface 
===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] db49231 - [clang][BFloat] Avoid redefining bfloat16_t in arm_neon.h

2023-05-03 Thread Dimitry Andric via cfe-commits


Author: Dimitry Andric
Date: 2023-05-03T17:54:58+02:00
New Revision: db492316399a0edc26788265c7fce78c63a0f838

URL: 
https://github.com/llvm/llvm-project/commit/db492316399a0edc26788265c7fce78c63a0f838
DIFF: 
https://github.com/llvm/llvm-project/commit/db492316399a0edc26788265c7fce78c63a0f838.diff

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

As of https://reviews.llvm.org/D79708, clang-tblgen generates `arm_neon.h`,
`arm_sve.h` and `arm_bf16.h`, and all those generated files will contain a
typedef of `bfloat16_t`. However, `arm_neon.h` and `arm_sve.h` include
`arm_bf16.h` immediately before their own typedef:

#include 
typedef __bf16 bfloat16_t;

With a recent version of clang (I used 16.0.1) this results in warnings:

/usr/lib/clang/16/include/arm_neon.h:38:16: error: redefinition of typedef 
'bfloat16_t' is a C11 feature [-Werror,-Wtypedef-redefinition]

Since `arm_bf16.h` is very likely supposed to be the one true place where
`bfloat16_t` is defined, I propose to delete the duplicate typedefs from the
generated `arm_neon.h` and `arm_sve.h`.

Reviewed By: sdesmalen, simonbutcher

Differential Revision: https://reviews.llvm.org/D148822

Added: 


Modified: 
clang/utils/TableGen/NeonEmitter.cpp
clang/utils/TableGen/SveEmitter.cpp

Removed: 




diff  --git a/clang/utils/TableGen/NeonEmitter.cpp 
b/clang/utils/TableGen/NeonEmitter.cpp
index 51bb774c6da99..6ef5790731a6b 100644
--- a/clang/utils/TableGen/NeonEmitter.cpp
+++ b/clang/utils/TableGen/NeonEmitter.cpp
@@ -2353,7 +2353,6 @@ void NeonEmitter::run(raw_ostream &OS) {
   OS << "#include \n\n";
 
   OS << "#include \n";
-  OS << "typedef __bf16 bfloat16_t;\n";
 
   // Emit NEON-specific scalar typedefs.
   OS << "typedef float float32_t;\n";

diff  --git a/clang/utils/TableGen/SveEmitter.cpp 
b/clang/utils/TableGen/SveEmitter.cpp
index bc50cbad4b541..d5d3f5fe558a8 100644
--- a/clang/utils/TableGen/SveEmitter.cpp
+++ b/clang/utils/TableGen/SveEmitter.cpp
@@ -1103,7 +1103,6 @@ void SVEEmitter::createHeader(raw_ostream &OS) {
   OS << "typedef __SVBFloat16_t svbfloat16_t;\n";
 
   OS << "#include \n";
-  OS << "typedef __bf16 bfloat16_t;\n";
 
   OS << "typedef __SVFloat32_t svfloat32_t;\n";
   OS << "typedef __SVFloat64_t svfloat64_t;\n";



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 69d42ee - [Clang] Show type in enum out of range diagnostic

2023-06-14 Thread Dimitry Andric via cfe-commits


Author: Dimitry Andric
Date: 2023-06-14T20:34:19+02:00
New Revision: 69d42eef4bec208a2312bfa0d2194013817eeba0

URL: 
https://github.com/llvm/llvm-project/commit/69d42eef4bec208a2312bfa0d2194013817eeba0
DIFF: 
https://github.com/llvm/llvm-project/commit/69d42eef4bec208a2312bfa0d2194013817eeba0.diff

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

When the diagnostic for an out of range enum value is printed, it
currently does not show the actual enum type in question, for example:

v8/src/base/bit-field.h:43:29: error: integer value 7 is outside the valid 
range of values [0, 3] for this enumeration type [-Wenum-constexpr-conversion]
  static constexpr T kMax = static_cast(kNumValues - 1);
^

This can make it cumbersome to find the cause for the problem. Add the
enum type to the diagnostic message, to make it easier.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D152788

Added: 


Modified: 
clang/docs/ReleaseNotes.rst
clang/include/clang/Basic/DiagnosticASTKinds.td
clang/lib/AST/ExprConstant.cpp
clang/test/SemaCXX/constant-expression-cxx11.cpp
clang/test/SemaCXX/cxx2a-consteval.cpp

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 32cc7c94a3252..3cfacb07bbaa1 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -344,6 +344,9 @@ Improvements to Clang's diagnostics
   (`#42992: `_)
 - Clang now diagnoses unused const-qualified variable template as
   "unused variable template" rather than "unused variable".
+- When diagnosing a constant expression where an enum without a fixed 
underlying
+  type is set to a value outside the range of the enum's values, clang will now
+  print the name of the enum in question.
 
 Bug Fixes in This Version
 -

diff  --git a/clang/include/clang/Basic/DiagnosticASTKinds.td 
b/clang/include/clang/Basic/DiagnosticASTKinds.td
index eb13467317963..73118891c1899 100644
--- a/clang/include/clang/Basic/DiagnosticASTKinds.td
+++ b/clang/include/clang/Basic/DiagnosticASTKinds.td
@@ -395,8 +395,8 @@ def warn_fixedpoint_constant_overflow : Warning<
   "overflow in expression; result is %0 with type %1">,
   InGroup>;
 def warn_constexpr_unscoped_enum_out_of_range : Warning<
-  "integer value %0 is outside the valid range of values [%1, %2] for this "
-  "enumeration type">, DefaultError, 
InGroup>;
+  "integer value %0 is outside the valid range of values [%1, %2] for the "
+  "enumeration type %3">, DefaultError, 
InGroup>;
 
 // This is a temporary diagnostic, and shall be removed once our
 // implementation is complete, and like the preceding constexpr notes belongs

diff  --git a/clang/lib/AST/ExprConstant.cpp b/clang/lib/AST/ExprConstant.cpp
index b88b84a44af0e..5578dfc8f8743 100644
--- a/clang/lib/AST/ExprConstant.cpp
+++ b/clang/lib/AST/ExprConstant.cpp
@@ -13708,12 +13708,13 @@ bool IntExprEvaluator::VisitCastExpr(const CastExpr 
*E) {
   Info.Ctx.getDiagnostics().Report(
   E->getExprLoc(), diag::warn_constexpr_unscoped_enum_out_of_range)
   << llvm::toString(Result.getInt(), 10) << Min.getSExtValue()
-  << Max.getSExtValue();
+  << Max.getSExtValue() << ED;
 else if (!ED->getNumNegativeBits() && ConstexprVar &&
  Max.ult(Result.getInt().getZExtValue()))
-  Info.Ctx.getDiagnostics().Report(E->getExprLoc(),
-   
diag::warn_constexpr_unscoped_enum_out_of_range)
-   << llvm::toString(Result.getInt(),10) << Min.getZExtValue() << 
Max.getZExtValue();
+  Info.Ctx.getDiagnostics().Report(
+  E->getExprLoc(), diag::warn_constexpr_unscoped_enum_out_of_range)
+  << llvm::toString(Result.getInt(), 10) << Min.getZExtValue()
+  << Max.getZExtValue() << ED;
   }
 }
 

diff  --git a/clang/test/SemaCXX/constant-expression-cxx11.cpp 
b/clang/test/SemaCXX/constant-expression-cxx11.cpp
index fa9ad786b289e..f454bba5afd8c 100644
--- a/clang/test/SemaCXX/constant-expression-cxx11.cpp
+++ b/clang/test/SemaCXX/constant-expression-cxx11.cpp
@@ -2440,42 +2440,51 @@ E2 testDefaultArgForParam(E2 e2Param = (E2)-1) { // ok, 
not a constant expressio
 void testValueInRangeOfEnumerationValues() {
   constexpr E1 x1 = static_cast(-8);
   constexpr E1 x2 = static_cast(8);
-  // expected-error@-1 {{integer value 8 is outside the valid range of values 
[-8, 7] for this enumeration type}}
+  // expected-error@-1 {{integer value 8 is outside the valid range of values 
[-8, 7] for the enumeration type 'E1'}}
   E1 x2b = static_cast(8); // ok, not a constant expression context
 
   constexpr E2 x3 = static_cast(-8);
-  // expected-error@-1 {{integer value -8 is outside the valid range of values 
[0, 7] for this en

Re: r290169 - Revert r290149: Add the alloc_size attribute to clang.

2016-12-22 Thread Dimitry Andric via cfe-commits

On 20 Dec 2016, at 09:28, Chandler Carruth via cfe-commits 
 wrote:
> Author: chandlerc
> Date: Tue Dec 20 02:28:19 2016
> New Revision: 290169
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=290169&view=rev
> Log:
> Revert r290149: Add the alloc_size attribute to clang.
> 
> This commit fails MSan when running test/CodeGen/object-size.c in
> a confusing way. After some discussion with George, it isn't really
> clear what is going on here. We can make the MSan failure go away by
> testing for the invalid bit, but *why* things are invalid isn't clear.
> And yet, other code in the surrounding area is doing precisely this and
> testing for invalid.
> 
> George is going to take a closer look at this to better understand the
> nature of the failure and recommit it, for now backing it out to clean
> up MSan builds.

Hmm, was this reapplied later on?  I'm still getting the following 
AddressSanitizer failures on FreeBSD, and bisecting has pointed to r290149 as 
the cause:

FAIL: AddressSanitizer-Unit :: 
Asan-i386-inline-Test/AddressSanitizer.ReallocFreedPointerTest (2124 of 30204)
 TEST 'AddressSanitizer-Unit :: 
Asan-i386-inline-Test/AddressSanitizer.ReallocFreedPointerTest' FAILED 

Note: Google Test filter = AddressSanitizer.ReallocFreedPointerTest
[==] Running 1 test from 1 test case.
[--] Global test environment set-up.
[--] 1 test from AddressSanitizer
[ RUN  ] AddressSanitizer.ReallocFreedPointerTest
/share/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/tests/asan_test.cc:377: 
Failure
Death test: ptr = realloc(ptr, 77)
Result: failed to die.
 Error msg:
[  DEATH   ]
[  FAILED  ] AddressSanitizer.ReallocFreedPointerTest (30 ms)
[--] 1 test from AddressSanitizer (30 ms total)

[--] Global test environment tear-down
[==] 1 test from 1 test case ran. (31 ms total)
[  PASSED  ] 0 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] AddressSanitizer.ReallocFreedPointerTest

 1 FAILED TEST
  YOU HAVE 24 DISABLED TESTS



Testing: 0 .
FAIL: AddressSanitizer-Unit :: 
Asan-i386-with-calls-Test/AddressSanitizer.ReallocFreedPointerTest (2233 of 
30204)
 TEST 'AddressSanitizer-Unit :: 
Asan-i386-with-calls-Test/AddressSanitizer.ReallocFreedPointerTest' FAILED 

Note: Google Test filter = AddressSanitizer.ReallocFreedPointerTest
[==] Running 1 test from 1 test case.
[--] Global test environment set-up.
[--] 1 test from AddressSanitizer
[ RUN  ] AddressSanitizer.ReallocFreedPointerTest
/share/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/tests/asan_test.cc:377: 
Failure
Death test: ptr = realloc(ptr, 77)
Result: failed to die.
 Error msg:
[  DEATH   ]
[  FAILED  ] AddressSanitizer.ReallocFreedPointerTest (24 ms)
[--] 1 test from AddressSanitizer (24 ms total)

[--] Global test environment tear-down
[==] 1 test from 1 test case ran. (25 ms total)
[  PASSED  ] 0 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] AddressSanitizer.ReallocFreedPointerTest

 1 FAILED TEST
  YOU HAVE 24 DISABLED TESTS



Testing: 0 .
FAIL: AddressSanitizer-i386-freebsd :: TestCases/Posix/free_hook_realloc.cc 
(2399 of 30204)
 TEST 'AddressSanitizer-i386-freebsd :: 
TestCases/Posix/free_hook_realloc.cc' FAILED 
Script:
--
/home/dim/obj/llvm-290338-trunk-freebsd12-i386-ninja-rel-1/./bin/clang 
--driver-mode=g++ -fsanitize=address -mno-omit-leaf-frame-pointer 
-fno-omit-frame-pointer -fno-optimize-sibling-calls -gline-tables-only -m32 -O2 
/share/dim/src/llvm/trunk/projects/compiler-rt/test/asan/TestCases/Posix/free_hook_realloc.cc
 -o 
/home/dim/obj/llvm-290338-trunk-freebsd12-i386-ninja-rel-1/projects/compiler-rt/test/asan/I386FreeBSDConfig/TestCases/Posix/Output/free_hook_realloc.cc.tmp
/home/dim/obj/llvm-290338-trunk-freebsd12-i386-ninja-rel-1/projects/compiler-rt/test/asan/I386FreeBSDConfig/TestCases/Posix/Output/free_hook_realloc.cc.tmp
 2>&1 | FileCheck 
/share/dim/src/llvm/trunk/projects/compiler-rt/test/asan/TestCases/Posix/free_hook_realloc.cc
--
Exit Code: 2

Command Output (stderr):
--
FileCheck error: '-' is empty.
FileCheck command line:  FileCheck 
/share/dim/src/llvm/trunk/projects/compiler-rt/test/asan/TestCases/Posix/free_hook_realloc.cc

--


Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90..
Testing Time: 880.55s

Failing Tests (3):
AddressSanitizer-Unit :: 
Asan-i386-inline-Test/AddressSanitizer.ReallocFreedPointerTest
AddressSanitizer-Unit :: 
Asan-i386-with-calls-Test/AddressSanitizer.ReallocFreedPointerTest
AddressSanitizer-i386-freebsd :: TestCases/Posix/free_hook_realloc.cc

  Expected Passes: 26881
  Expected Failures  : 144
  Unsupported Tests  : 3176
  Unexpected Failures: 3

1 warning(s) in tests.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPG

Re: r290169 - Revert r290149: Add the alloc_size attribute to clang.

2016-12-22 Thread Dimitry Andric via cfe-commits

This is when running "ninja check-all", in a tree with llvm, clang and 
compiler-rt checked out.  The first program that shows a failure is 
projects/compiler-rt/lib/asan/tests/default/Asan-i386-inline-Test:

[==] Running 92 tests from 3 test cases.
[--] Global test environment set-up.
[--] 14 tests from AddressSanitizerInterface
...
[ RUN  ] AddressSanitizer.ReallocFreedPointerTest
/share/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/tests/asan_test.cc:377: 
Failure
Death test: ptr = realloc(ptr, 77)
Result: failed to die.
 Error msg:
[  DEATH   ]
[  FAILED  ] AddressSanitizer.ReallocFreedPointerTest (48 ms)

A similar failure shows when running 
projects/compiler-rt/lib/asan/tests/default/Asan-i386-with-calls-Test:

[==] Running 92 tests from 3 test cases.
[--] Global test environment set-up.
[--] 14 tests from AddressSanitizerInterface
...
[ RUN  ] AddressSanitizer.ReallocFreedPointerTest
/share/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/tests/asan_test.cc:377: 
Failure
Death test: ptr = realloc(ptr, 77)
Result: failed to die.
 Error msg:
[  DEATH   ]
[  FAILED  ] AddressSanitizer.ReallocFreedPointerTest (55 ms)

Interestingly, the Asan-i386-inline-Noinst-Test and 
Asan-i386-with-calls-Noinst-Test do not show this particular failure.

The other test that fails is 
projects/compiler-rt/test/asan/I386FreeBSDConfig/TestCases/Posix/Output/free_hook_realloc.cc.tmp,
 which simply returns 1 without printing any output. Debugging the program 
shows that it seems to be skipping completely over the realloc() call, and 
jumping directly to the _exit(1), but this may be due to optimization.

-Dimitry

> On 22 Dec 2016, at 20:27, George Burgess IV  
> wrote:
> 
> Yes, this was reapplied in r290297 with fixes for the msan issue we caught; 
> these asan unit test failures are news to me. Can you give me the command 
> that you're using to run these tests, please?
> 
> On Thu, Dec 22, 2016 at 11:10 AM, Dimitry Andric  wrote:
> On 20 Dec 2016, at 09:28, Chandler Carruth via cfe-commits 
>  wrote:
> > Author: chandlerc
> > Date: Tue Dec 20 02:28:19 2016
> > New Revision: 290169
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=290169&view=rev
> > Log:
> > Revert r290149: Add the alloc_size attribute to clang.
> >
> > This commit fails MSan when running test/CodeGen/object-size.c in
> > a confusing way. After some discussion with George, it isn't really
> > clear what is going on here. We can make the MSan failure go away by
> > testing for the invalid bit, but *why* things are invalid isn't clear.
> > And yet, other code in the surrounding area is doing precisely this and
> > testing for invalid.
> >
> > George is going to take a closer look at this to better understand the
> > nature of the failure and recommit it, for now backing it out to clean
> > up MSan builds.
> 
> Hmm, was this reapplied later on?  I'm still getting the following 
> AddressSanitizer failures on FreeBSD, and bisecting has pointed to r290149 as 
> the cause:
> 
> FAIL: AddressSanitizer-Unit :: 
> Asan-i386-inline-Test/AddressSanitizer.ReallocFreedPointerTest (2124 of 30204)
>  TEST 'AddressSanitizer-Unit :: 
> Asan-i386-inline-Test/AddressSanitizer.ReallocFreedPointerTest' FAILED 
> 
> Note: Google Test filter = AddressSanitizer.ReallocFreedPointerTest
> [==] Running 1 test from 1 test case.
> [--] Global test environment set-up.
> [--] 1 test from AddressSanitizer
> [ RUN  ] AddressSanitizer.ReallocFreedPointerTest
> /share/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/tests/asan_test.cc:377:
>  Failure
> Death test: ptr = realloc(ptr, 77)
> Result: failed to die.
>  Error msg:
> [  DEATH   ]
> [  FAILED  ] AddressSanitizer.ReallocFreedPointerTest (30 ms)
> [--] 1 test from AddressSanitizer (30 ms total)
> 
> [--] Global test environment tear-down
> [==] 1 test from 1 test case ran. (31 ms total)
> [  PASSED  ] 0 tests.
> [  FAILED  ] 1 test, listed below:
> [  FAILED  ] AddressSanitizer.ReallocFreedPointerTest
> 
>  1 FAILED TEST
>   YOU HAVE 24 DISABLED TESTS
> 
> 
> 
> Testing: 0 .
> FAIL: AddressSanitizer-Unit :: 
> Asan-i386-with-calls-Test/AddressSanitizer.ReallocFreedPointerTest (2233 of 
> 30204)
>  TEST 'AddressSanitizer-Unit :: 
> Asan-i386-with-calls-Test/AddressSanitizer.ReallocFreedPointerTest' FAILED 
> 
> Note: Google Test filter = AddressSanitizer.ReallocFreedPointerTest
> [==] Running 1 test from 1 test case.
> [--] Global test environment set-up.
> [--] 1 test from AddressSanitizer
> [ RUN  ] AddressSanitizer.ReallocFreedPointerTest
> /share/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/tests/asan_test.cc:377:
>  Failure
> Death test: ptr = realloc(ptr, 77)
> Result: failed to die.
>  Error msg:
> [  DEATH   ]
> [  FAILED  ] AddressSanitizer.ReallocFreedPointerTest

Re: r290169 - Revert r290149: Add the alloc_size attribute to clang.

2016-12-23 Thread Dimitry Andric via cfe-commits

I can confirm that r290169 indeed fixes the three test failures I got earlier.  
Thanks George!

-Dimitry

> On 23 Dec 2016, at 02:29, George Burgess IV  
> wrote:
> 
> It looks like the root of this is that we're treating calls to `allocsize` 
> functions as AllocLike (e.g. any allocation function type except realloc) 
> functions, which caused us to perform invalid optimizations. For example, in 
> ReallocFreedPointerTest, EarlyCSE DCE'd the realloc because 
> llvm::isInstructionTriviallyDead calls llvm::isAllocLikeFn, and isAllocLikeFn 
> would return true if it saw the allocsize attribute. It really shouldn't do 
> that.
> 
> r290397 should fix this behavior by making allocsize alone insufficient to 
> consider a function an allocation function.
> 
> Thanks for your help!
> 
> On Thu, Dec 22, 2016 at 1:10 PM, George Burgess IV 
> mailto:george.burgess...@gmail.com>> wrote:
> Okay, I'm seeing this failure now if I tag my system's `realloc` declaration 
> with `alloc_size`. (Which FreeBSD seems to do in their headers). Because all 
> that clang does with `alloc_size` is use it to answer `__builtin_object_size` 
> queries and lower it to LLVM's `allocsize` attribute, this is presumably a 
> latent bug in LLVM's `allocsize` attribute.
> 
> Let me mess around for a bit and see what I can dig up. :)
> 
> On Thu, Dec 22, 2016 at 11:59 AM, Dimitry Andric  > wrote:
> This is when running "ninja check-all", in a tree with llvm, clang and 
> compiler-rt checked out.  The first program that shows a failure is 
> projects/compiler-rt/lib/asan/tests/default/Asan-i386-inline-Test:
> 
> [==] Running 92 tests from 3 test cases.
> [--] Global test environment set-up.
> [--] 14 tests from AddressSanitizerInterface
> ...
> [ RUN  ] AddressSanitizer.ReallocFreedPointerTest
> /share/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/tests/asan_test.cc:377:
>  Failure
> Death test: ptr = realloc(ptr, 77)
> Result: failed to die.
>  Error msg:
> [  DEATH   ]
> [  FAILED  ] AddressSanitizer.ReallocFreedPointerTest (48 ms)
> 
> A similar failure shows when running 
> projects/compiler-rt/lib/asan/tests/default/Asan-i386-with-calls-Test:
> 
> [==] Running 92 tests from 3 test cases.
> [--] Global test environment set-up.
> [--] 14 tests from AddressSanitizerInterface
> ...
> [ RUN  ] AddressSanitizer.ReallocFreedPointerTest
> /share/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/tests/asan_test.cc:377:
>  Failure
> Death test: ptr = realloc(ptr, 77)
> Result: failed to die.
>  Error msg:
> [  DEATH   ]
> [  FAILED  ] AddressSanitizer.ReallocFreedPointerTest (55 ms)
> 
> Interestingly, the Asan-i386-inline-Noinst-Test and 
> Asan-i386-with-calls-Noinst-Test do not show this particular failure.
> 
> The other test that fails is 
> projects/compiler-rt/test/asan/I386FreeBSDConfig/TestCases/Posix/Output/free_hook_realloc.cc.tmp,
>  which simply returns 1 without printing any output. Debugging the program 
> shows that it seems to be skipping completely over the realloc() call, and 
> jumping directly to the _exit(1), but this may be due to optimization.
> 
> -Dimitry
> 
> > On 22 Dec 2016, at 20:27, George Burgess IV  > > wrote:
> >
> > Yes, this was reapplied in r290297 with fixes for the msan issue we caught; 
> > these asan unit test failures are news to me. Can you give me the command 
> > that you're using to run these tests, please?
> >
> > On Thu, Dec 22, 2016 at 11:10 AM, Dimitry Andric  > > wrote:
> > On 20 Dec 2016, at 09:28, Chandler Carruth via cfe-commits 
> > mailto:cfe-commits@lists.llvm.org>> wrote:
> > > Author: chandlerc
> > > Date: Tue Dec 20 02:28:19 2016
> > > New Revision: 290169
> > >
> > > URL: http://llvm.org/viewvc/llvm-project?rev=290169&view=rev 
> > > 
> > > Log:
> > > Revert r290149: Add the alloc_size attribute to clang.
> > >
> > > This commit fails MSan when running test/CodeGen/object-size.c in
> > > a confusing way. After some discussion with George, it isn't really
> > > clear what is going on here. We can make the MSan failure go away by
> > > testing for the invalid bit, but *why* things are invalid isn't clear.
> > > And yet, other code in the surrounding area is doing precisely this and
> > > testing for invalid.
> > >
> > > George is going to take a closer look at this to better understand the
> > > nature of the failure and recommit it, for now backing it out to clean
> > > up MSan builds.
> >
> > Hmm, was this reapplied later on?  I'm still getting the following 
> > AddressSanitizer failures on FreeBSD, and bisecting has pointed to r290149 
> > as the cause:
> >
> > FAIL: AddressSanitizer-Unit :: 
> > Asan-i386-inline-Test/AddressSanitizer.ReallocFreedPointerTest (2124 of 
> > 30204)
> >  TEST 'AddressSanitizer-Unit :: 
> > Asan-i386-inline-Test/AddressSanitizer.

[libcxx] r291476 - Move _PairT declaration out of __hash_combine to avoid warning under C++98

2017-01-09 Thread Dimitry Andric via cfe-commits

Author: dim
Date: Mon Jan  9 14:29:35 2017
New Revision: 291476

URL: http://llvm.org/viewvc/llvm-project?rev=291476&view=rev
Log:
Move _PairT declaration out of __hash_combine to avoid warning under C++98

Summary:
Some parts of the FreeBSD tree are still compiled with C++98, and until
rL288554 this has always worked fine.  After that, a complaint about the
newly introduced local _PairT is produced:

/usr/include/c++/v1/memory:3354:27: error: template argument uses local 
type '_PairT' [-Werror,-Wlocal-type-template-args]
typedef __scalar_hash<_PairT> _HashT;
  ^~
/usr/include/c++/v1/memory:3284:29: error: template argument uses local 
type '_PairT' [-Werror,-Wlocal-type-template-args]
: public unary_function<_Tp, size_t>
^~~
/usr/include/c++/v1/memory:3356:12: note: in instantiation of template 
class 'std::__1::__scalar_hash<_PairT, 2>' requested here
return _HashT()(__p);
   ^

As far as I can see, there should be no problem moving the _PairT
struct to just before the __hash_combine() function, which fixes this
particular warning.

Reviewers: mclow.lists, EricWF

Subscribers: cfe-commits, emaste

Differential Revision: https://reviews.llvm.org/D28472

Modified:
libcxx/trunk/include/memory

Modified: libcxx/trunk/include/memory
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/memory?rev=291476&r1=291475&r2=291476&view=diff
==
--- libcxx/trunk/include/memory (original)
+++ libcxx/trunk/include/memory Mon Jan  9 14:29:35 2017
@@ -3344,12 +3344,13 @@ struct __scalar_hash<_Tp, 4>
 }
 };
 
+struct _PairT {
+  size_t first;
+  size_t second;
+};
+
 _LIBCPP_INLINE_VISIBILITY
 inline size_t __hash_combine(size_t __lhs, size_t __rhs) _NOEXCEPT {
-struct _PairT {
-  size_t first;
-  size_t second;
-};
 typedef __scalar_hash<_PairT> _HashT;
 const _PairT __p = {__lhs, __rhs};
 return _HashT()(__p);


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r266775 - Pass dwarf-version to cc1as.

2016-08-16 Thread Dimitry Andric via cfe-commits

Hi Hans,

Can we please merge this one to release_39 too?  I forgot all about it, sorry.

Doug, can you please approve?

-Dimitry

> On 19 Apr 2016, at 19:43, Douglas Katzman via cfe-commits 
>  wrote:
> 
> Author: dougk
> Date: Tue Apr 19 12:43:54 2016
> New Revision: 266775
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=266775&view=rev
> Log:
> Pass dwarf-version to cc1as.
> 
> Fix PR26999 - crashing in cc1as with any '*bsd' target.
> 
> Modified:
>cfe/trunk/lib/Driver/Tools.cpp
>cfe/trunk/test/Driver/save-temps.c
> 
> Modified: cfe/trunk/lib/Driver/Tools.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=266775&r1=266774&r2=266775&view=diff
> ==
> --- cfe/trunk/lib/Driver/Tools.cpp (original)
> +++ cfe/trunk/lib/Driver/Tools.cpp Tue Apr 19 12:43:54 2016
> @@ -6314,6 +6314,12 @@ void ClangAs::ConstructJob(Compilation &
>   // FIXME: Stop lying and consume only the appropriate driver flags
>   Args.ClaimAllArgs(options::OPT_W_Group);
> 
> +  // Assemblers that want to know the dwarf version can't assume a value,
> +  // since the defaulting logic resides in the driver. Put in something
> +  // reasonable now, in case a subsequent "-Wa,-g" changes it.
> +  RenderDebugEnablingArgs(Args, CmdArgs, codegenoptions::NoDebugInfo,
> +  getToolChain().GetDefaultDwarfVersion(),
> +  llvm::DebuggerKind::Default);
>   CollectArgsForIntegratedAssembler(C, Args, CmdArgs,
> getToolChain().getDriver());
> 
> 
> Modified: cfe/trunk/test/Driver/save-temps.c
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/save-temps.c?rev=266775&r1=266774&r2=266775&view=diff
> ==
> --- cfe/trunk/test/Driver/save-temps.c (original)
> +++ cfe/trunk/test/Driver/save-temps.c Tue Apr 19 12:43:54 2016
> @@ -77,3 +77,8 @@
> // CHECK-OBJ-NOO: "-o" "save-temps.s"
> // CHECK-OBJ-NOO: "-o" "save-temps.o"
> // CHECK-OBJ-NOO: "-o" "a.out"
> +
> +// RUN: %clang -target i386-unknown-freebsd -save-temps -g -c %s -### 2>&1 \
> +// RUN:   | FileCheck %s -check-prefix=CHECK-SAVE-TEMPS
> +// CHECK-SAVE-TEMPS: "-cc1as"
> +// CHECK-SAVE-TEMPS: "-dwarf-version={{.}}"
> 
> 
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r266775 - Pass dwarf-version to cc1as.

2016-08-16 Thread Dimitry Andric via cfe-commits

Ah, I missed Doug's follow-up commit r266797, which moved the code again.  I 
noticed that the RenderDebugEnablingArgs() call was missing in the spot 
indicated below, but it was only moved.

-Dimitry

> On 17 Aug 2016, at 01:17, Hans Wennborg  wrote:
> 
> Looks like it was committed back in April, so unless I'm missing
> something it should already be in the branch (which was cut mid-July).
> 
> Thanks,
> Hans
> 
> On Tue, Aug 16, 2016 at 2:16 PM, Dimitry Andric  wrote:
>> Hi Hans,
>> 
>> Can we please merge this one to release_39 too?  I forgot all about it, 
>> sorry.
>> 
>> Doug, can you please approve?
>> 
>> -Dimitry
>> 
>>> On 19 Apr 2016, at 19:43, Douglas Katzman via cfe-commits 
>>>  wrote:
>>> 
>>> Author: dougk
>>> Date: Tue Apr 19 12:43:54 2016
>>> New Revision: 266775
>>> 
>>> URL: http://llvm.org/viewvc/llvm-project?rev=266775&view=rev
>>> Log:
>>> Pass dwarf-version to cc1as.
>>> 
>>> Fix PR26999 - crashing in cc1as with any '*bsd' target.
>>> 
>>> Modified:
>>>   cfe/trunk/lib/Driver/Tools.cpp
>>>   cfe/trunk/test/Driver/save-temps.c
>>> 
>>> Modified: cfe/trunk/lib/Driver/Tools.cpp
>>> URL: 
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=266775&r1=266774&r2=266775&view=diff
>>> ==
>>> --- cfe/trunk/lib/Driver/Tools.cpp (original)
>>> +++ cfe/trunk/lib/Driver/Tools.cpp Tue Apr 19 12:43:54 2016
>>> @@ -6314,6 +6314,12 @@ void ClangAs::ConstructJob(Compilation &
>>>  // FIXME: Stop lying and consume only the appropriate driver flags
>>>  Args.ClaimAllArgs(options::OPT_W_Group);
>>> 
>>> +  // Assemblers that want to know the dwarf version can't assume a value,
>>> +  // since the defaulting logic resides in the driver. Put in something
>>> +  // reasonable now, in case a subsequent "-Wa,-g" changes it.
>>> +  RenderDebugEnablingArgs(Args, CmdArgs, codegenoptions::NoDebugInfo,
>>> +  getToolChain().GetDefaultDwarfVersion(),
>>> +  llvm::DebuggerKind::Default);
>>>  CollectArgsForIntegratedAssembler(C, Args, CmdArgs,
>>>getToolChain().getDriver());
>>> 
>>> 
>>> Modified: cfe/trunk/test/Driver/save-temps.c
>>> URL: 
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/save-temps.c?rev=266775&r1=266774&r2=266775&view=diff
>>> ==
>>> --- cfe/trunk/test/Driver/save-temps.c (original)
>>> +++ cfe/trunk/test/Driver/save-temps.c Tue Apr 19 12:43:54 2016
>>> @@ -77,3 +77,8 @@
>>> // CHECK-OBJ-NOO: "-o" "save-temps.s"
>>> // CHECK-OBJ-NOO: "-o" "save-temps.o"
>>> // CHECK-OBJ-NOO: "-o" "a.out"
>>> +
>>> +// RUN: %clang -target i386-unknown-freebsd -save-temps -g -c %s -### 2>&1 
>>> \
>>> +// RUN:   | FileCheck %s -check-prefix=CHECK-SAVE-TEMPS
>>> +// CHECK-SAVE-TEMPS: "-cc1as"
>>> +// CHECK-SAVE-TEMPS: "-dwarf-version={{.}}"
>>> 
>>> 
>>> ___
>>> cfe-commits mailing list
>>> cfe-commits@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r278904 - Support allocators with explicit conversion constructors. Fixes bug #29000

2016-08-17 Thread Dimitry Andric via cfe-commits

Marshall, this is maybe a good candidate for merging to release_39?

-Dimitry

> On 17 Aug 2016, at 07:58, Marshall Clow via cfe-commits 
>  wrote:
> 
> Author: marshall
> Date: Wed Aug 17 00:58:40 2016
> New Revision: 278904
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=278904&view=rev
> Log:
> Support allocators with explicit conversion constructors. Fixes bug #29000
> 
> Modified:
>libcxx/trunk/include/map
>libcxx/trunk/include/unordered_map
>libcxx/trunk/test/std/containers/associative/map/map.cons/alloc.pass.cpp
>
> libcxx/trunk/test/std/containers/associative/map/map.cons/compare_alloc.pass.cpp
>
> libcxx/trunk/test/std/containers/associative/map/map.cons/copy_alloc.pass.cpp
>libcxx/trunk/test/std/containers/associative/map/map.cons/default.pass.cpp
>
> libcxx/trunk/test/std/containers/associative/map/map.cons/initializer_list_compare_alloc.pass.cpp
>
> libcxx/trunk/test/std/containers/associative/map/map.cons/iter_iter_comp_alloc.pass.cpp
>
> libcxx/trunk/test/std/containers/associative/map/map.cons/move_alloc.pass.cpp
>
> libcxx/trunk/test/std/containers/associative/multimap/multimap.cons/alloc.pass.cpp
>
> libcxx/trunk/test/std/containers/associative/multimap/multimap.cons/compare_alloc.pass.cpp
>
> libcxx/trunk/test/std/containers/associative/multimap/multimap.cons/copy_alloc.pass.cpp
>
> libcxx/trunk/test/std/containers/associative/multimap/multimap.cons/default.pass.cpp
>
> libcxx/trunk/test/std/containers/associative/multimap/multimap.cons/initializer_list_compare_alloc.pass.cpp
>
> libcxx/trunk/test/std/containers/associative/multimap/multimap.cons/iter_iter_comp_alloc.pass.cpp
>
> libcxx/trunk/test/std/containers/associative/multimap/multimap.cons/move_alloc.pass.cpp
>
> libcxx/trunk/test/std/containers/associative/multiset/multiset.cons/default.pass.cpp
>libcxx/trunk/test/std/containers/associative/set/set.cons/default.pass.cpp
>libcxx/trunk/test/std/containers/sequences/deque/deque.cons/alloc.pass.cpp
>
> libcxx/trunk/test/std/containers/sequences/forwardlist/forwardlist.cons/alloc.pass.cpp
>libcxx/trunk/test/std/containers/sequences/list/list.cons/default.pass.cpp
>
> libcxx/trunk/test/std/containers/sequences/vector.bool/construct_default.pass.cpp
>
> libcxx/trunk/test/std/containers/sequences/vector/vector.cons/construct_default.pass.cpp
>
> libcxx/trunk/test/std/containers/unord/unord.map/unord.map.cnstr/allocator.pass.cpp
>
> libcxx/trunk/test/std/containers/unord/unord.map/unord.map.cnstr/copy_alloc.pass.cpp
>
> libcxx/trunk/test/std/containers/unord/unord.map/unord.map.cnstr/default.pass.cpp
>
> libcxx/trunk/test/std/containers/unord/unord.map/unord.map.cnstr/init_size_hash_equal_allocator.pass.cpp
>
> libcxx/trunk/test/std/containers/unord/unord.map/unord.map.cnstr/move_alloc.pass.cpp
>
> libcxx/trunk/test/std/containers/unord/unord.map/unord.map.cnstr/range_size_hash_equal_allocator.pass.cpp
>
> libcxx/trunk/test/std/containers/unord/unord.map/unord.map.cnstr/size_hash_equal_allocator.pass.cpp
>
> libcxx/trunk/test/std/containers/unord/unord.multimap/unord.multimap.cnstr/allocator.pass.cpp
>
> libcxx/trunk/test/std/containers/unord/unord.multimap/unord.multimap.cnstr/copy_alloc.pass.cpp
>
> libcxx/trunk/test/std/containers/unord/unord.multimap/unord.multimap.cnstr/default.pass.cpp
>
> libcxx/trunk/test/std/containers/unord/unord.multimap/unord.multimap.cnstr/init_size_hash_equal_allocator.pass.cpp
>
> libcxx/trunk/test/std/containers/unord/unord.multimap/unord.multimap.cnstr/move_alloc.pass.cpp
>
> libcxx/trunk/test/std/containers/unord/unord.multimap/unord.multimap.cnstr/range_size_hash_equal_allocator.pass.cpp
>
> libcxx/trunk/test/std/containers/unord/unord.multimap/unord.multimap.cnstr/size_hash_equal_allocator.pass.cpp
>
> libcxx/trunk/test/std/containers/unord/unord.multiset/unord.multiset.cnstr/default.pass.cpp
>
> libcxx/trunk/test/std/containers/unord/unord.set/unord.set.cnstr/default.pass.cpp
>libcxx/trunk/test/std/strings/basic.string/string.cons/alloc.pass.cpp
>libcxx/trunk/test/support/min_allocator.h
> 
> Modified: libcxx/trunk/include/map
> URL: 
> http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/map?rev=278904&r1=278903&r2=278904&view=diff
> ==
> --- libcxx/trunk/include/map (original)
> +++ libcxx/trunk/include/map Wed Aug 17 00:58:40 2016
> @@ -873,7 +873,7 @@ public:
> 
> _LIBCPP_INLINE_VISIBILITY
> explicit map(const key_compare& __comp, const allocator_type& __a)
> -: __tree_(__vc(__comp), __a) {}
> +: __tree_(__vc(__comp), typename __base::allocator_type(__a)) {}
> 
> template 
> _LIBCPP_INLINE_VISIBILITY
> @@ -888,7 +888,7 @@ public:
> _LIBCPP_INLINE_VISIBILITY
> map(_InputIterator __f, _InputIterator __l,
> const key_compare& __comp, const allocator_type&

[PATCH] D23960: Avoid narrowing warnings in __bitset constructor

2016-08-27 Thread Dimitry Andric via cfe-commits

dim created this revision.
dim added reviewers: mclow.lists, EricWF.
dim added subscribers: emaste, cfe-commits.

When I compile  is compiled with warnings enabled, I get the
following error (which is interesting in itself, it should only be a
warning):

/usr/include/c++/v1/bitset:265:16: error: non-constant-expression cannot be 
narrowed from type 'unsigned long long' to '__storage_type' (aka 'unsigned 
int') in
  initializer list [-Wc++11-narrowing]
: __first_{__v, __v >> __bits_per_word}
   ^~~
/usr/include/c++/v1/bitset:676:52: note: in instantiation of member 
function 'std::__1::__bitset<2, 53>::__bitset' requested here
bitset(unsigned long long __v) _NOEXCEPT : base(__v) {}
   ^
/home/dim/src/llvm/trunk/include/llvm/IR/Attributes.h:455:9: note: in 
instantiation of member function 'std::__1::bitset<53>::bitset' requested here
  : Attrs(0), Alignment(0), StackAlignment(0), DerefBytes(0),
^
/usr/include/c++/v1/bitset:265:16: note: insert an explicit cast to silence 
this issue
: __first_{__v, __v >> __bits_per_word}
   ^~~

Note that this is on i386, so this uses the `#elif` part of the
`__bitset` constructor:

__bitset<_N_words, _Size>::__bitset(unsigned long long __v) _NOEXCEPT
#ifndef _LIBCPP_HAS_NO_CONSTEXPR
#if __SIZEOF_SIZE_T__ == 8
: __first_{__v}
#elif __SIZEOF_SIZE_T__ == 4
: __first_{__v, __v >> __bits_per_word}
#else
#error This constructor has not been ported to this platform
#endif
#endif

Indeed, `__first_` has type `__storage_type`, which is 32 bits on this
platform, so I think an explicit static_cast is required here.

https://reviews.llvm.org/D23960

Files:
  include/bitset

Index: include/bitset
===
--- include/bitset
+++ include/bitset
@@ -259,7 +259,7 @@
 #if __SIZEOF_SIZE_T__ == 8
 : __first_{__v}
 #elif __SIZEOF_SIZE_T__ == 4
-: __first_{__v, __v >> __bits_per_word}
+: __first_{static_cast<__storage_type>(__v), 
static_cast<__storage_type>(__v >> __bits_per_word)}
 #else
 #error This constructor has not been ported to this platform
 #endif


Index: include/bitset
===
--- include/bitset
+++ include/bitset
@@ -259,7 +259,7 @@
 #if __SIZEOF_SIZE_T__ == 8
 : __first_{__v}
 #elif __SIZEOF_SIZE_T__ == 4
-: __first_{__v, __v >> __bits_per_word}
+: __first_{static_cast<__storage_type>(__v), static_cast<__storage_type>(__v >> __bits_per_word)}
 #else
 #error This constructor has not been ported to this platform
 #endif
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D23961: Avoid embedded preprocessor directives in __tree

2016-08-27 Thread Dimitry Andric via cfe-commits

dim created this revision.
dim added reviewers: mclow.lists, EricWF.
dim added subscribers: emaste, cfe-commits.

When I compile  as part of clang, with -pedantic enabled, I get the
following warnings:

In file included from /usr/include/c++/v1/map:442:
/usr/include/c++/v1/__tree:874:2: warning: embedding a directive within 
macro arguments has undefined behavior [-Wembedded-directive]
#if _LIBCPP_STD_VER <= 11
 ^
/usr/include/c++/v1/__tree:877:2: warning: embedding a directive within 
macro arguments has undefined behavior [-Wembedded-directive]
#endif
 ^
/usr/include/c++/v1/__tree:1392:2: warning: embedding a directive within 
macro arguments has undefined behavior [-Wembedded-directive]
#if _LIBCPP_STD_VER <= 11
 ^
/usr/include/c++/v1/__tree:1395:2: warning: embedding a directive within 
macro arguments has undefined behavior [-Wembedded-directive]
#endif
 ^

This is because the `#if`s are within the parameter list of a
`_NOEXCEPT_()` macro invocation.  EricWF fixed something similar in
rL242623, by moving the `#if` outside the macro invocation.

https://reviews.llvm.org/D23961

Files:
  include/__tree

Index: include/__tree
===
--- include/__tree
+++ include/__tree
@@ -,14 +,15 @@
 void clear() _NOEXCEPT;
 
 void swap(__tree& __t)
+#if _LIBCPP_STD_VER <= 11
 _NOEXCEPT_(
 __is_nothrow_swappable::value
-#if _LIBCPP_STD_VER <= 11
 && (!__node_traits::propagate_on_container_swap::value ||
  __is_nothrow_swappable<__node_allocator>::value)
-#endif
 );
-
+#else
+_NOEXCEPT_(__is_nothrow_swappable::value);
+#endif
 
 #ifndef _LIBCPP_CXX03_LANG
 template 
@@ -1797,13 +1798,15 @@
 template 
 void
 __tree<_Tp, _Compare, _Allocator>::swap(__tree& __t)
+#if _LIBCPP_STD_VER <= 11
 _NOEXCEPT_(
 __is_nothrow_swappable::value
-#if _LIBCPP_STD_VER <= 11
 && (!__node_traits::propagate_on_container_swap::value ||
  __is_nothrow_swappable<__node_allocator>::value)
-#endif
 )
+#else
+_NOEXCEPT_(__is_nothrow_swappable::value)
+#endif
 {
 using _VSTD::swap;
 swap(__begin_node_, __t.__begin_node_);


Index: include/__tree
===
--- include/__tree
+++ include/__tree
@@ -,14 +,15 @@
 void clear() _NOEXCEPT;
 
 void swap(__tree& __t)
+#if _LIBCPP_STD_VER <= 11
 _NOEXCEPT_(
 __is_nothrow_swappable::value
-#if _LIBCPP_STD_VER <= 11
 && (!__node_traits::propagate_on_container_swap::value ||
  __is_nothrow_swappable<__node_allocator>::value)
-#endif
 );
-
+#else
+_NOEXCEPT_(__is_nothrow_swappable::value);
+#endif
 
 #ifndef _LIBCPP_CXX03_LANG
 template 
@@ -1797,13 +1798,15 @@
 template 
 void
 __tree<_Tp, _Compare, _Allocator>::swap(__tree& __t)
+#if _LIBCPP_STD_VER <= 11
 _NOEXCEPT_(
 __is_nothrow_swappable::value
-#if _LIBCPP_STD_VER <= 11
 && (!__node_traits::propagate_on_container_swap::value ||
  __is_nothrow_swappable<__node_allocator>::value)
-#endif
 )
+#else
+_NOEXCEPT_(__is_nothrow_swappable::value)
+#endif
 {
 using _VSTD::swap;
 swap(__begin_node_, __t.__begin_node_);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libcxx] r279926 - Avoid embedded preprocessor directives in __tree

2016-08-27 Thread Dimitry Andric via cfe-commits

Author: dim
Date: Sat Aug 27 14:32:03 2016
New Revision: 279926

URL: http://llvm.org/viewvc/llvm-project?rev=279926&view=rev
Log:
Avoid embedded preprocessor directives in __tree

Similar to rL242623, move C++ version checks outside of _NOEXCEPT_()
macro invocation argument lists, to avoid "embedding a directive within
macro arguments has undefined behavior" warnings.

Differential Revision: https://reviews.llvm.org/D23961

Modified:
libcxx/trunk/include/__tree

Modified: libcxx/trunk/include/__tree
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__tree?rev=279926&r1=279925&r2=279926&view=diff
==
--- libcxx/trunk/include/__tree (original)
+++ libcxx/trunk/include/__tree Sat Aug 27 14:32:03 2016
@@ -,14 +,15 @@ public:
 void clear() _NOEXCEPT;
 
 void swap(__tree& __t)
+#if _LIBCPP_STD_VER <= 11
 _NOEXCEPT_(
 __is_nothrow_swappable::value
-#if _LIBCPP_STD_VER <= 11
 && (!__node_traits::propagate_on_container_swap::value ||
  __is_nothrow_swappable<__node_allocator>::value)
-#endif
 );
-
+#else
+_NOEXCEPT_(__is_nothrow_swappable::value);
+#endif
 
 #ifndef _LIBCPP_CXX03_LANG
 template 
@@ -1797,13 +1798,15 @@ __tree<_Tp, _Compare, _Allocator>::destr
 template 
 void
 __tree<_Tp, _Compare, _Allocator>::swap(__tree& __t)
+#if _LIBCPP_STD_VER <= 11
 _NOEXCEPT_(
 __is_nothrow_swappable::value
-#if _LIBCPP_STD_VER <= 11
 && (!__node_traits::propagate_on_container_swap::value ||
  __is_nothrow_swappable<__node_allocator>::value)
-#endif
 )
+#else
+_NOEXCEPT_(__is_nothrow_swappable::value)
+#endif
 {
 using _VSTD::swap;
 swap(__begin_node_, __t.__begin_node_);


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D23961: Avoid embedded preprocessor directives in __tree

2016-08-27 Thread Dimitry Andric via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rL279926: Avoid embedded preprocessor directives in __tree 
(authored by dim).

Changed prior to commit:
  https://reviews.llvm.org/D23961?vs=69492&id=69496#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D23961

Files:
  libcxx/trunk/include/__tree

Index: libcxx/trunk/include/__tree
===
--- libcxx/trunk/include/__tree
+++ libcxx/trunk/include/__tree
@@ -,14 +,15 @@
 void clear() _NOEXCEPT;
 
 void swap(__tree& __t)
+#if _LIBCPP_STD_VER <= 11
 _NOEXCEPT_(
 __is_nothrow_swappable::value
-#if _LIBCPP_STD_VER <= 11
 && (!__node_traits::propagate_on_container_swap::value ||
  __is_nothrow_swappable<__node_allocator>::value)
-#endif
 );
-
+#else
+_NOEXCEPT_(__is_nothrow_swappable::value);
+#endif
 
 #ifndef _LIBCPP_CXX03_LANG
 template 
@@ -1797,13 +1798,15 @@
 template 
 void
 __tree<_Tp, _Compare, _Allocator>::swap(__tree& __t)
+#if _LIBCPP_STD_VER <= 11
 _NOEXCEPT_(
 __is_nothrow_swappable::value
-#if _LIBCPP_STD_VER <= 11
 && (!__node_traits::propagate_on_container_swap::value ||
  __is_nothrow_swappable<__node_allocator>::value)
-#endif
 )
+#else
+_NOEXCEPT_(__is_nothrow_swappable::value)
+#endif
 {
 using _VSTD::swap;
 swap(__begin_node_, __t.__begin_node_);


Index: libcxx/trunk/include/__tree
===
--- libcxx/trunk/include/__tree
+++ libcxx/trunk/include/__tree
@@ -,14 +,15 @@
 void clear() _NOEXCEPT;
 
 void swap(__tree& __t)
+#if _LIBCPP_STD_VER <= 11
 _NOEXCEPT_(
 __is_nothrow_swappable::value
-#if _LIBCPP_STD_VER <= 11
 && (!__node_traits::propagate_on_container_swap::value ||
  __is_nothrow_swappable<__node_allocator>::value)
-#endif
 );
-
+#else
+_NOEXCEPT_(__is_nothrow_swappable::value);
+#endif
 
 #ifndef _LIBCPP_CXX03_LANG
 template 
@@ -1797,13 +1798,15 @@
 template 
 void
 __tree<_Tp, _Compare, _Allocator>::swap(__tree& __t)
+#if _LIBCPP_STD_VER <= 11
 _NOEXCEPT_(
 __is_nothrow_swappable::value
-#if _LIBCPP_STD_VER <= 11
 && (!__node_traits::propagate_on_container_swap::value ||
  __is_nothrow_swappable<__node_allocator>::value)
-#endif
 )
+#else
+_NOEXCEPT_(__is_nothrow_swappable::value)
+#endif
 {
 using _VSTD::swap;
 swap(__begin_node_, __t.__begin_node_);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D23961: Avoid embedded preprocessor directives in __tree

2016-08-28 Thread Dimitry Andric via cfe-commits

dim added a comment.

In https://reviews.llvm.org/D23961#527284, @vitalybuka wrote:

> PPC bots are broken by this patch 
>  http://lab.llvm.org:8011/builders/sanitizer-ppc64be-linux/builds/3547
>  http://lab.llvm.org:8011/builders/sanitizer-ppc64le-linux/builds/2353

I saw some mails about it, but also that the failures were all in 
timing-related tests. The next runs seem to have succeeded, so these were false 
positives.

Repository:
  rL LLVM

https://reviews.llvm.org/D23961

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D23921: Remove va_start diagnostic false positive with enumerations

2016-08-28 Thread Dimitry Andric via cfe-commits

dim added a subscriber: dim.
dim added a comment.

This works for me.  I had two test cases from the FreeBSD source tree which 
resulted in warnings, e.g.:

  cddl/contrib/opensolaris/lib/libnvpair/libnvpair.c:388:15: error: passing an 
object that undergoes default argument promotion to 'va_start' has undefined 
behavior
[-Werror,-Wvarargs]
  va_start(ap, which);
   ^
  cddl/contrib/opensolaris/lib/libnvpair/libnvpair.c:382:66: note: parameter of 
type 'enum nvlist_prtctl_fmt' is declared here
  nvlist_prtctl_dofmt(nvlist_prtctl_t pctl, enum nvlist_prtctl_fmt which, ...)
   ^
  1 error generated.

This fix resolves both of them.


https://reviews.llvm.org/D23921



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D23960: Avoid narrowing warnings in __bitset constructor

2016-09-01 Thread Dimitry Andric via cfe-commits

dim added a comment.

Ping...


https://reviews.llvm.org/D23960



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D23960: Avoid narrowing warnings in __bitset constructor

2016-09-01 Thread Dimitry Andric via cfe-commits

dim added inline comments.


Comment at: include/bitset:262
@@ -261,3 +261,3 @@
 #elif __SIZEOF_SIZE_T__ == 4
-: __first_{__v, __v >> __bits_per_word}
+: __first_{static_cast<__storage_type>(__v), 
static_cast<__storage_type>(__v >> __bits_per_word)}
 #else

EricWF wrote:
> Only the first one actually requires a cast, correct? The second should never 
> be a potentially narrowing conversion.
No, originally I got two separate warnings for this:
```
/usr/include/c++/v1/bitset:265:16: error: non-constant-expression cannot be 
narrowed from type 'unsigned long long' to '__storage_type' (aka 'unsigned 
int') in initializer list [-Wc++11-narrowing]
: __first_{__v, __v >> __bits_per_word}
   ^~~
/usr/include/c++/v1/bitset:676:52: note: in instantiation of member function 
'std::__1::__bitset<2, 53>::__bitset' requested here
bitset(unsigned long long __v) _NOEXCEPT : base(__v) {}
   ^
contrib/llvm/include/llvm/IR/Attributes.h:455:9: note: in instantiation of 
member function 'std::__1::bitset<53>::bitset' requested here
  : Attrs(0), Alignment(0), StackAlignment(0), DerefBytes(0),
^
/usr/include/c++/v1/bitset:265:16: note: insert an explicit cast to silence 
this issue
: __first_{__v, __v >> __bits_per_word}
   ^~~
/usr/include/c++/v1/bitset:265:21: error: non-constant-expression cannot be 
narrowed from type 'unsigned long long' to '__storage_type' (aka 'unsigned 
int') in initializer list [-Wc++11-narrowing]
: __first_{__v, __v >> __bits_per_word}
^~
/usr/include/c++/v1/bitset:265:21: note: insert an explicit cast to silence 
this issue
: __first_{__v, __v >> __bits_per_word}
^~
```



https://reviews.llvm.org/D23960



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D23960: Avoid narrowing warnings in __bitset constructor

2016-09-02 Thread Dimitry Andric via cfe-commits

dim added a comment.

@mclow.lists, I tested code generation (on i386-freebsd) with this small sample 
program:

  #include 
  
  void f(const std::bitset<53>&);
  
  void g(void)
  {
std::bitset<53> bs(0x1234567890abcdef);
f(bs);
  }

The assembly doesn't change at all after this fix:

  g():  # @g()
  .cfi_startproc
  # BB#0: # %entry
  pushl   %ebp
  .Ltmp0:
  .cfi_def_cfa_offset 8
  .Ltmp1:
  .cfi_offset %ebp, -8
  movl%esp, %ebp
  .Ltmp2:
  .cfi_def_cfa_register %ebp
  andl$-8, %esp
  subl$16, %esp
  movl$-1867788817, 8(%esp)   # imm = 0x90ABCDEF
  movl$305419896, 12(%esp)# imm = 0x12345678
  leal8(%esp), %eax
  movl%eax, (%esp)
  calll   f(std::__1::bitset<53u> const&)
  movl%ebp, %esp
  popl%ebp
  retl


https://reviews.llvm.org/D23960



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libcxx] r280543 - Avoid narrowing warnings in __bitset constructor

2016-09-02 Thread Dimitry Andric via cfe-commits

Author: dim
Date: Fri Sep  2 16:02:11 2016
New Revision: 280543

URL: http://llvm.org/viewvc/llvm-project?rev=280543&view=rev
Log:
Avoid narrowing warnings in __bitset constructor

When  is compiled with warnings enabled, on a platform where
size_t is 4 bytes, it results in errors similar to:

bitset:265:16: error: non-constant-expression cannot be narrowed
from type 'unsigned long long' to '__storage_type' (aka 'unsigned
int') in initializer list [-Wc++11-narrowing]
: __first_{__v, __v >> __bits_per_word}
   ^~~
bitset:676:52: note: in instantiation of member function
'std::__1::__bitset<2, 53>::__bitset' requested here
bitset(unsigned long long __v) _NOEXCEPT : base(__v) {}
   ^

Fix these by casting the initializer list elements to __storage_type.

Reviewers: mclow.lists, EricWF
Differential Revision: https://reviews.llvm.org/D23960

Modified:
libcxx/trunk/include/bitset

Modified: libcxx/trunk/include/bitset
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/bitset?rev=280543&r1=280542&r2=280543&view=diff
==
--- libcxx/trunk/include/bitset (original)
+++ libcxx/trunk/include/bitset Fri Sep  2 16:02:11 2016
@@ -259,7 +259,7 @@ __bitset<_N_words, _Size>::__bitset(unsi
 #if __SIZEOF_SIZE_T__ == 8
 : __first_{__v}
 #elif __SIZEOF_SIZE_T__ == 4
-: __first_{__v, __v >> __bits_per_word}
+: __first_{static_cast<__storage_type>(__v), 
static_cast<__storage_type>(__v >> __bits_per_word)}
 #else
 #error This constructor has not been ported to this platform
 #endif


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D23960: Avoid narrowing warnings in __bitset constructor

2016-09-02 Thread Dimitry Andric via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rL280543: Avoid narrowing warnings in __bitset constructor 
(authored by dim).

Changed prior to commit:
  https://reviews.llvm.org/D23960?vs=69489&id=70231#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D23960

Files:
  libcxx/trunk/include/bitset

Index: libcxx/trunk/include/bitset
===
--- libcxx/trunk/include/bitset
+++ libcxx/trunk/include/bitset
@@ -259,7 +259,7 @@
 #if __SIZEOF_SIZE_T__ == 8
 : __first_{__v}
 #elif __SIZEOF_SIZE_T__ == 4
-: __first_{__v, __v >> __bits_per_word}
+: __first_{static_cast<__storage_type>(__v), 
static_cast<__storage_type>(__v >> __bits_per_word)}
 #else
 #error This constructor has not been ported to this platform
 #endif


Index: libcxx/trunk/include/bitset
===
--- libcxx/trunk/include/bitset
+++ libcxx/trunk/include/bitset
@@ -259,7 +259,7 @@
 #if __SIZEOF_SIZE_T__ == 8
 : __first_{__v}
 #elif __SIZEOF_SIZE_T__ == 4
-: __first_{__v, __v >> __bits_per_word}
+: __first_{static_cast<__storage_type>(__v), static_cast<__storage_type>(__v >> __bits_per_word)}
 #else
 #error This constructor has not been ported to this platform
 #endif
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libunwind] r280669 - Add missing _US_ACTION_MASK constant to unwind.h

2016-09-05 Thread Dimitry Andric via cfe-commits

Author: dim
Date: Mon Sep  5 13:01:13 2016
New Revision: 280669

URL: http://llvm.org/viewvc/llvm-project?rev=280669&view=rev
Log:
Add missing _US_ACTION_MASK constant to unwind.h

Summary:
During building of recent compiler-rt sources on FreeBSD for arm, I
noticed that our unwind.h (which originates in libunwind) was missing
the `_US_ACTION_MASK` constant:

compiler-rt/lib/builtins/gcc_personality_v0.c:187:18: error: use of 
undeclared identifier '_US_ACTION_MASK'
if ((state & _US_ACTION_MASK) != _US_UNWIND_FRAME_STARTING)
 ^

It appears that both clang's internal unwind.h, and libgcc's unwind.h
define this constant as 3, so let's add this to libunwind's version too.

Reviewers: logan, kledzik, davide, emaste

Subscribers: joerg, davide, aemerson, emaste, llvm-commits

Differential Revision: https://reviews.llvm.org/D24222

Modified:
libunwind/trunk/include/unwind.h

Modified: libunwind/trunk/include/unwind.h
URL: 
http://llvm.org/viewvc/llvm-project/libunwind/trunk/include/unwind.h?rev=280669&r1=280668&r2=280669&view=diff
==
--- libunwind/trunk/include/unwind.h (original)
+++ libunwind/trunk/include/unwind.h Mon Sep  5 13:01:13 2016
@@ -57,6 +57,7 @@ typedef uint32_t _Unwind_State;
 static const _Unwind_State _US_VIRTUAL_UNWIND_FRAME   = 0;
 static const _Unwind_State _US_UNWIND_FRAME_STARTING  = 1;
 static const _Unwind_State _US_UNWIND_FRAME_RESUME= 2;
+static const _Unwind_State _US_ACTION_MASK= 3;
 /* Undocumented flag for force unwinding. */
 static const _Unwind_State _US_FORCE_UNWIND   = 8;
 


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D23921: Remove va_start diagnostic false positive with enumerations

2016-09-14 Thread Dimitry Andric via cfe-commits

dim added a comment.

FWIW, I have already imported this fix into FreeBSD two weeks ago: 
https://svnweb.freebsd.org/changeset/base/304960
It has been working fine for us.


https://reviews.llvm.org/D23921



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r284890 - DR583, DR1512: Implement a rewrite to C++'s 'composite pointer type' rules.

2017-01-13 Thread Dimitry Andric via cfe-commits

On 22 Oct 2016, at 00:00, Richard Smith via cfe-commits 
 wrote:
> 
> Author: rsmith
> Date: Fri Oct 21 17:00:42 2016
> New Revision: 284890
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=284890&view=rev
> Log:
> DR583, DR1512: Implement a rewrite to C++'s 'composite pointer type' rules.
> This has two significant effects:
> 
> 1) Direct relational comparisons between null pointer constants (0 and 
> nullopt)
>   and pointers are now ill-formed. This was always the case for C, and it
>   appears that C++ only ever permitted by accident. For instance, cases like
> nullptr < &a
>   are now rejected.
> 
> 2) Comparisons and conditional operators between differently-cv-qualified
>   pointer types now work, and produce a composite type that both source
>   pointer types can convert to (when possible). For instance, comparison
>   between 'int **' and 'const int **' is now valid, and uses an intermediate
>   type of 'const int *const *'.
> 
> Clang previously supported #2 as an extension.
> 
> We do not accept the cases in #1 as an extension. I've tested a fair amount of
> code to check that this doesn't break it, but if it turns out that someone is
> relying on this, we can easily add it back as an extension.
> 
> This is a re-commit of r284800.

Hi Richard,

This indeed leads to a bit of breakage when we compile lots of FreeBSD ports, 
for example openjdk7 (https://bugs.freebsd.org/216016), ptlib 
(https://bugs.freebsd.org/216019), spidermonkey24 
(https://bugs.freebsd.org/216010), and webkit-qt4 
(https://bugs.freebsd.org/216015) will now produce errors similar to:

vidinput_v4l.cxx:981:23: error: ordered comparison between pointer and zero 
('BYTE *' (aka 'unsigned char *') and 'int')
  if (videoBuffer < 0) {
  ~~~ ^ ~

There will probably be more of these.  Is it the intent of this change that 
such software must now be patched up?

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r292032 - Fix PR31644 introduced by r287138 and add a regression test.

2017-01-14 Thread Dimitry Andric via cfe-commits

On 14 Jan 2017, at 22:12, Yaron Keren via cfe-commits 
 wrote:
> Author: yrnkrn
> Date: Sat Jan 14 15:12:08 2017
> New Revision: 292032
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=292032&view=rev
> Log:
> Fix PR31644 introduced by r287138 and add a regression test.
> Thanks Dimitry Andric for the report and fix!

Please merge this to the release_40 branch too. :)

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r292276 - Fix std::string assignment ambiguity from braced initializer lists.

2017-01-23 Thread Dimitry Andric via cfe-commits


> On 17 Jan 2017, at 23:10, Eric Fiselier via cfe-commits 
>  wrote:
> 
> Author: ericwf
> Date: Tue Jan 17 16:10:32 2017
> New Revision: 292276
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=292276&view=rev
> Log:
> Fix std::string assignment ambiguity from braced initializer lists.
> 
> When support for `basic_string_view` was added to string it also
> added new assignment operators from `basic_string_view`. These caused
> ambiguity when assigning from a braced initializer. This patch fixes
> that regression by making the basic_string_view assignment operator
> rank lower in overload resolution by making it a template.
> 
> Added:
>
> libcxx/trunk/test/std/strings/basic.string/string.cons/brace_assignment.pass.cpp
> Modified:
>libcxx/trunk/include/string
>libcxx/trunk/test/std/strings/basic.string/string.cons/string_view.pass.cpp
> 
> Modified: libcxx/trunk/include/string
> URL: 
> http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/string?rev=292276&r1=292275&r2=292276&view=diff
> ==
> --- libcxx/trunk/include/string (original)
> +++ libcxx/trunk/include/string Tue Jan 17 16:10:32 2017
> @@ -818,6 +818,7 @@ public:
> operator __self_view() const _NOEXCEPT { return __self_view(data(), 
> size()); }
> 
> basic_string& operator=(const basic_string& __str);
> +template 
> _LIBCPP_INLINE_VISIBILITY
> basic_string& operator=(__self_view __sv)  {return assign(__sv);}
> #ifndef _LIBCPP_HAS_NO_RVALUE_REFERENCES

Hi Eric,

This fix has one side effect that shows up in https://bugs.freebsd.org/216404 
now: gcc has until recently defaulted to -std=gnu++98, and this makes it 
complain about the default template argument:

In file included from /usr/include/c++/v1/__locale:15:0,
 from /usr/include/c++/v1/ios:216,
 from /usr/include/c++/v1/iostream:38,
 from a.cc:1:
/usr/include/c++/v1/string:823:45: error: default template arguments may not be 
used in function templates without -std=c++11 or -std=gnu++11
 basic_string& operator=(__self_view __sv)  {return assign(__sv);}
 ^

Maybe the defaulted template argument can be surrounded with _LIBCPP_CXX03_LANG?

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libcxx] r293197 - Disable thread safety analysis for some functions in __thread_support

2017-01-26 Thread Dimitry Andric via cfe-commits

Author: dim
Date: Thu Jan 26 12:37:18 2017
New Revision: 293197

URL: http://llvm.org/viewvc/llvm-project?rev=293197&view=rev
Log:
Disable thread safety analysis for some functions in __thread_support

Many thread-related libc++ test cases fail on FreeBSD, due to the
following -Werror warnings:

In file included from 
test/std/thread/thread.threads/thread.thread.this/sleep_until.pass.cpp:17:
In file included from include/thread:97:
In file included from include/__mutex_base:17:
include/__threading_support:222:1: error: mutex '__m' is still held at the 
end of function [-Werror,-Wthread-safety-analysis]
}
^
include/__threading_support:221:10: note: mutex acquired here
  return pthread_mutex_lock(__m);
 ^
include/__threading_support:231:10: error: releasing mutex '__m' that was 
not held [-Werror,-Wthread-safety-analysis]
  return pthread_mutex_unlock(__m);
 ^
include/__threading_support:242:1: error: mutex '__m' is still held at the 
end of function [-Werror,-Wthread-safety-analysis]
}
^
include/__threading_support:241:10: note: mutex acquired here
  return pthread_mutex_lock(__m);
 ^
include/__threading_support:251:10: error: releasing mutex '__m' that was 
not held [-Werror,-Wthread-safety-analysis]
  return pthread_mutex_unlock(__m);
 ^
include/__threading_support:272:10: error: calling function 
'pthread_cond_wait' requires holding mutex '__m' exclusively 
[-Werror,-Wthread-safety-analysis]
  return pthread_cond_wait(__cv, __m);
 ^
include/__threading_support:278:10: error: calling function 
'pthread_cond_timedwait' requires holding mutex '__m' exclusively 
[-Werror,-Wthread-safety-analysis]
  return pthread_cond_timedwait(__cv, __m, __ts);
 ^
6 errors generated.

This is because on FreeBSD, the pthread functions have lock annotations.
Since the functions in __thread_support are internal to libc++ only, add
no_thread_safety_analysis attributes to suppress these warnings.

Reviewers: mclow.lists, EricWF, delesley, aaron.ballman
Reviewed By: aaron.ballman
Subscribers: ed, aaron.ballman, joerg, emaste, cfe-commits
Differential Revision: https://reviews.llvm.org/D28520

Modified:
libcxx/trunk/include/__threading_support

Modified: libcxx/trunk/include/__threading_support
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__threading_support?rev=293197&r1=293196&r2=293197&view=diff
==
--- libcxx/trunk/include/__threading_support (original)
+++ libcxx/trunk/include/__threading_support Thu Jan 26 12:37:18 2017
@@ -40,6 +40,12 @@
 #define _LIBCPP_THREAD_ABI_VISIBILITY inline _LIBCPP_INLINE_VISIBILITY
 #endif
 
+#if defined(__FreeBSD__) && defined(__clang__) && 
__has_attribute(no_thread_safety_analysis)
+#define _LIBCPP_NO_THREAD_SAFETY_ANALYSIS 
__attribute__((no_thread_safety_analysis))
+#else
+#define _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
+#endif
+
 _LIBCPP_BEGIN_NAMESPACE_STD
 
 #if defined(_LIBCPP_HAS_THREAD_API_PTHREAD)
@@ -102,25 +108,25 @@ typedef DWORD __libcpp_tls_key;
 _LIBCPP_THREAD_ABI_VISIBILITY
 int __libcpp_recursive_mutex_init(__libcpp_recursive_mutex_t *__m);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
 int __libcpp_recursive_mutex_lock(__libcpp_recursive_mutex_t *__m);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
 bool __libcpp_recursive_mutex_trylock(__libcpp_recursive_mutex_t *__m);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
 int __libcpp_recursive_mutex_unlock(__libcpp_recursive_mutex_t *__m);
 
 _LIBCPP_THREAD_ABI_VISIBILITY
 int __libcpp_recursive_mutex_destroy(__libcpp_recursive_mutex_t *__m);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
 int __libcpp_mutex_lock(__libcpp_mutex_t *__m);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
 bool __libcpp_mutex_trylock(__libcpp_mutex_t *__m);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
 int __libcpp_mutex_unlock(__libcpp_mutex_t *__m);
 
 _LIBCPP_THREAD_ABI_VISIBILITY
@@ -133,10 +139,10 @@ int __libcpp_condvar_signal(__libcpp_con
 _LIBCPP_THREAD_ABI_VISIBILITY
 int __libcpp_condvar_broadcast(__libcpp_condvar_t* __cv);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
 int __libcpp_condvar_wait(__libcpp_condvar_t* __cv, __libcpp_mutex_t* __m);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
 int __libcpp_condvar_timedwait(__libcpp_condvar_t *__cv, __libcpp_mutex_t *__m,
timespec *__ts);
 


___
cfe-commits mailing list

Re: [libcxx] r293197 - Disable thread safety analysis for some functions in __thread_support

2017-01-29 Thread Dimitry Andric via cfe-commits

I'd like to merge this to the release_40 branch.  Eric, you OK with that?

-Dimitry

> On 26 Jan 2017, at 19:37, Dimitry Andric via cfe-commits 
>  wrote:
> 
> Author: dim
> Date: Thu Jan 26 12:37:18 2017
> New Revision: 293197
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=293197&view=rev
> Log:
> Disable thread safety analysis for some functions in __thread_support
> 
> Many thread-related libc++ test cases fail on FreeBSD, due to the
> following -Werror warnings:
> 
>In file included from 
> test/std/thread/thread.threads/thread.thread.this/sleep_until.pass.cpp:17:
>In file included from include/thread:97:
>In file included from include/__mutex_base:17:
>include/__threading_support:222:1: error: mutex '__m' is still held at the 
> end of function [-Werror,-Wthread-safety-analysis]
>}
>^
>include/__threading_support:221:10: note: mutex acquired here
>  return pthread_mutex_lock(__m);
> ^
>include/__threading_support:231:10: error: releasing mutex '__m' that was 
> not held [-Werror,-Wthread-safety-analysis]
>  return pthread_mutex_unlock(__m);
> ^
>include/__threading_support:242:1: error: mutex '__m' is still held at the 
> end of function [-Werror,-Wthread-safety-analysis]
>}
>^
>include/__threading_support:241:10: note: mutex acquired here
>  return pthread_mutex_lock(__m);
> ^
>include/__threading_support:251:10: error: releasing mutex '__m' that was 
> not held [-Werror,-Wthread-safety-analysis]
>  return pthread_mutex_unlock(__m);
> ^
>include/__threading_support:272:10: error: calling function 
> 'pthread_cond_wait' requires holding mutex '__m' exclusively 
> [-Werror,-Wthread-safety-analysis]
>  return pthread_cond_wait(__cv, __m);
> ^
>include/__threading_support:278:10: error: calling function 
> 'pthread_cond_timedwait' requires holding mutex '__m' exclusively 
> [-Werror,-Wthread-safety-analysis]
>  return pthread_cond_timedwait(__cv, __m, __ts);
> ^
>6 errors generated.
> 
> This is because on FreeBSD, the pthread functions have lock annotations.
> Since the functions in __thread_support are internal to libc++ only, add
> no_thread_safety_analysis attributes to suppress these warnings.
> 
> Reviewers: mclow.lists, EricWF, delesley, aaron.ballman
> Reviewed By: aaron.ballman
> Subscribers: ed, aaron.ballman, joerg, emaste, cfe-commits
> Differential Revision: https://reviews.llvm.org/D28520
> 
> Modified:
>libcxx/trunk/include/__threading_support
> 
> Modified: libcxx/trunk/include/__threading_support
> URL: 
> http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__threading_support?rev=293197&r1=293196&r2=293197&view=diff
> ==
> --- libcxx/trunk/include/__threading_support (original)
> +++ libcxx/trunk/include/__threading_support Thu Jan 26 12:37:18 2017
> @@ -40,6 +40,12 @@
> #define _LIBCPP_THREAD_ABI_VISIBILITY inline _LIBCPP_INLINE_VISIBILITY
> #endif
> 
> +#if defined(__FreeBSD__) && defined(__clang__) && 
> __has_attribute(no_thread_safety_analysis)
> +#define _LIBCPP_NO_THREAD_SAFETY_ANALYSIS 
> __attribute__((no_thread_safety_analysis))
> +#else
> +#define _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
> +#endif
> +
> _LIBCPP_BEGIN_NAMESPACE_STD
> 
> #if defined(_LIBCPP_HAS_THREAD_API_PTHREAD)
> @@ -102,25 +108,25 @@ typedef DWORD __libcpp_tls_key;
> _LIBCPP_THREAD_ABI_VISIBILITY
> int __libcpp_recursive_mutex_init(__libcpp_recursive_mutex_t *__m);
> 
> -_LIBCPP_THREAD_ABI_VISIBILITY
> +_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
> int __libcpp_recursive_mutex_lock(__libcpp_recursive_mutex_t *__m);
> 
> -_LIBCPP_THREAD_ABI_VISIBILITY
> +_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
> bool __libcpp_recursive_mutex_trylock(__libcpp_recursive_mutex_t *__m);
> 
> -_LIBCPP_THREAD_ABI_VISIBILITY
> +_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
> int __libcpp_recursive_mutex_unlock(__libcpp_recursive_mutex_t *__m);
> 
> _LIBCPP_THREAD_ABI_VISIBILITY
> int __libcpp_recursive_mutex_destroy(__libcpp_recursive_mutex_t *__m);
> 
> -_LIBCPP_THREAD_ABI_VISIBILITY
> +_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
> int __libcpp_mutex_lock(__libcpp_mutex_t *__m);
> 
> -_LIBCPP_THREAD_ABI_VISIBILITY
> +_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
> bool __libcpp_mutex_trylock(__libcpp_mutex_t *__m);
> 
> -_LIBCPP_THREAD_

[libcxx] r293443 - Merging r293197:

2017-01-29 Thread Dimitry Andric via cfe-commits

Author: dim
Date: Sun Jan 29 14:30:51 2017
New Revision: 293443

URL: http://llvm.org/viewvc/llvm-project?rev=293443&view=rev
Log:
Merging r293197:

r293197 | dim | 2017-01-26 19:37:18 +0100 (Thu, 26 Jan 2017) | 43 lines

Disable thread safety analysis for some functions in __thread_support

Many thread-related libc++ test cases fail on FreeBSD, due to the
following -Werror warnings:

In file included from 
test/std/thread/thread.threads/thread.thread.this/sleep_until.pass.cpp:17:
In file included from include/thread:97:
In file included from include/__mutex_base:17:
include/__threading_support:222:1: error: mutex '__m' is still held at the 
end of function [-Werror,-Wthread-safety-analysis]
}
^
include/__threading_support:221:10: note: mutex acquired here
  return pthread_mutex_lock(__m);
 ^
include/__threading_support:231:10: error: releasing mutex '__m' that was 
not held [-Werror,-Wthread-safety-analysis]
  return pthread_mutex_unlock(__m);
 ^
include/__threading_support:242:1: error: mutex '__m' is still held at the 
end of function [-Werror,-Wthread-safety-analysis]
}
^
include/__threading_support:241:10: note: mutex acquired here
  return pthread_mutex_lock(__m);
 ^
include/__threading_support:251:10: error: releasing mutex '__m' that was 
not held [-Werror,-Wthread-safety-analysis]
  return pthread_mutex_unlock(__m);
 ^
include/__threading_support:272:10: error: calling function 
'pthread_cond_wait' requires holding mutex '__m' exclusively 
[-Werror,-Wthread-safety-analysis]
  return pthread_cond_wait(__cv, __m);
 ^
include/__threading_support:278:10: error: calling function 
'pthread_cond_timedwait' requires holding mutex '__m' exclusively 
[-Werror,-Wthread-safety-analysis]
  return pthread_cond_timedwait(__cv, __m, __ts);
 ^
6 errors generated.

This is because on FreeBSD, the pthread functions have lock annotations.
Since the functions in __thread_support are internal to libc++ only, add
no_thread_safety_analysis attributes to suppress these warnings.

Reviewers: mclow.lists, EricWF, delesley, aaron.ballman
Reviewed By: aaron.ballman
Subscribers: ed, aaron.ballman, joerg, emaste, cfe-commits
Differential Revision: https://reviews.llvm.org/D28520



Modified:
libcxx/branches/release_40/   (props changed)
libcxx/branches/release_40/include/__threading_support

Propchange: libcxx/branches/release_40/
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Sun Jan 29 14:30:51 2017
@@ -1,2 +1,2 @@
 /libcxx/branches/apple:136569-137939
-/libcxx/trunk:292013,292091,292607,292990,293154
+/libcxx/trunk:292013,292091,292607,292990,293154,293197

Modified: libcxx/branches/release_40/include/__threading_support
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/branches/release_40/include/__threading_support?rev=293443&r1=293442&r2=293443&view=diff
==
--- libcxx/branches/release_40/include/__threading_support (original)
+++ libcxx/branches/release_40/include/__threading_support Sun Jan 29 14:30:51 
2017
@@ -40,6 +40,12 @@
 #define _LIBCPP_THREAD_ABI_VISIBILITY inline _LIBCPP_INLINE_VISIBILITY
 #endif
 
+#if defined(__FreeBSD__) && defined(__clang__) && 
__has_attribute(no_thread_safety_analysis)
+#define _LIBCPP_NO_THREAD_SAFETY_ANALYSIS 
__attribute__((no_thread_safety_analysis))
+#else
+#define _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
+#endif
+
 _LIBCPP_BEGIN_NAMESPACE_STD
 
 #if defined(_LIBCPP_HAS_THREAD_API_PTHREAD)
@@ -98,25 +104,25 @@ typedef DWORD __libcpp_tls_key;
 _LIBCPP_THREAD_ABI_VISIBILITY
 int __libcpp_recursive_mutex_init(__libcpp_recursive_mutex_t *__m);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
 int __libcpp_recursive_mutex_lock(__libcpp_recursive_mutex_t *__m);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
 int __libcpp_recursive_mutex_trylock(__libcpp_recursive_mutex_t *__m);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
 int __libcpp_recursive_mutex_unlock(__libcpp_recursive_mutex_t *__m);
 
 _LIBCPP_THREAD_ABI_VISIBILITY
 int __libcpp_recursive_mutex_destroy(__libcpp_recursive_mutex_t *__m);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
 int __libcpp_mutex_lock(__libcpp_mutex_t *__m);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
 int __libcpp_mutex_trylock(__libcpp_mutex_t *__m);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
 int __l

Re: [libcxx] r293197 - Disable thread safety analysis for some functions in __thread_support

2017-01-29 Thread Dimitry Andric via cfe-commits

Thanks, merged in r293443.

-Dimitry

> On 29 Jan 2017, at 19:55, Eric Fiselier  wrote:
> 
> I'm OK with this.
> 
> On Sun, Jan 29, 2017 at 10:18 AM, Dimitry Andric  <mailto:dimi...@andric.com>> wrote:
> I'd like to merge this to the release_40 branch.  Eric, you OK with that?
> 
> -Dimitry
> 
> > On 26 Jan 2017, at 19:37, Dimitry Andric via cfe-commits 
> > mailto:cfe-commits@lists.llvm.org>> wrote:
> >
> > Author: dim
> > Date: Thu Jan 26 12:37:18 2017
> > New Revision: 293197
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=293197&view=rev 
> > <http://llvm.org/viewvc/llvm-project?rev=293197&view=rev>
> > Log:
> > Disable thread safety analysis for some functions in __thread_support
> >
> > Many thread-related libc++ test cases fail on FreeBSD, due to the
> > following -Werror warnings:
> >
> >In file included from 
> > test/std/thread/thread.threads/thread.thread.this/sleep_until.pass.cpp:17:
> >In file included from include/thread:97:
> >In file included from include/__mutex_base:17:
> >include/__threading_support:222:1: error: mutex '__m' is still held at 
> > the end of function [-Werror,-Wthread-safety-analysis]
> >}
> >^
> >include/__threading_support:221:10: note: mutex acquired here
> >  return pthread_mutex_lock(__m);
> > ^
> >include/__threading_support:231:10: error: releasing mutex '__m' that 
> > was not held [-Werror,-Wthread-safety-analysis]
> >  return pthread_mutex_unlock(__m);
> > ^
> >include/__threading_support:242:1: error: mutex '__m' is still held at 
> > the end of function [-Werror,-Wthread-safety-analysis]
> >}
> >^
> >include/__threading_support:241:10: note: mutex acquired here
> >  return pthread_mutex_lock(__m);
> > ^
> >include/__threading_support:251:10: error: releasing mutex '__m' that 
> > was not held [-Werror,-Wthread-safety-analysis]
> >  return pthread_mutex_unlock(__m);
> > ^
> >include/__threading_support:272:10: error: calling function 
> > 'pthread_cond_wait' requires holding mutex '__m' exclusively 
> > [-Werror,-Wthread-safety-analysis]
> >  return pthread_cond_wait(__cv, __m);
> > ^
> >include/__threading_support:278:10: error: calling function 
> > 'pthread_cond_timedwait' requires holding mutex '__m' exclusively 
> > [-Werror,-Wthread-safety-analysis]
> >  return pthread_cond_timedwait(__cv, __m, __ts);
> > ^
> >6 errors generated.
> >
> > This is because on FreeBSD, the pthread functions have lock annotations.
> > Since the functions in __thread_support are internal to libc++ only, add
> > no_thread_safety_analysis attributes to suppress these warnings.
> >
> > Reviewers: mclow.lists, EricWF, delesley, aaron.ballman
> > Reviewed By: aaron.ballman
> > Subscribers: ed, aaron.ballman, joerg, emaste, cfe-commits
> > Differential Revision: https://reviews.llvm.org/D28520 
> > <https://reviews.llvm.org/D28520>
> >
> > Modified:
> >libcxx/trunk/include/__threading_support
> >
> > Modified: libcxx/trunk/include/__threading_support
> > URL: 
> > http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__threading_support?rev=293197&r1=293196&r2=293197&view=diff
> >  
> > <http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__threading_support?rev=293197&r1=293196&r2=293197&view=diff>
> > ==
> > --- libcxx/trunk/include/__threading_support (original)
> > +++ libcxx/trunk/include/__threading_support Thu Jan 26 12:37:18 2017
> > @@ -40,6 +40,12 @@
> > #define _LIBCPP_THREAD_ABI_VISIBILITY inline _LIBCPP_INLINE_VISIBILITY
> > #endif
> >
> > +#if defined(__FreeBSD__) && defined(__clang__) && 
> > __has_attribute(no_thread_safety_analysis)
> > +#define _LIBCPP_NO_THREAD_SAFETY_ANALYSIS 
> > __attribute__((no_thread_safety_analysis))
> > +#else
> > +#define _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
> > +#endif
> > +
> > _LIBCPP_BEGIN_NAMESPACE_STD
> >
> > #if defined(_LIBCPP_HAS_THREAD_API_PTHREAD)
> > @@ -102,25 +108,25 @@ typedef DWORD __libcpp_tls_key;
> > _LIBCPP_THREAD_ABI_VISIBILITY
> > int __libcpp_recursive_mutex_init(__libcpp_recursive_mutex_t *__m);
> >
> > -_LI

Re: r290539 - [inline-asm]No error for conflict between inputs\outputs and clobber list

2017-01-31 Thread Dimitry Andric via cfe-commits

On 26 Dec 2016, at 13:23, Marina Yatsina via cfe-commits 
 wrote:
> 
> Author: myatsina
> Date: Mon Dec 26 06:23:42 2016
> New Revision: 290539
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=290539&view=rev
> Log:
> [inline-asm]No error for conflict between inputs\outputs and clobber list
> 
> According to extended asm syntax, a case where the clobber list includes a 
> variable from the inputs or outputs should be an error - conflict.
> for example:
> 
> const long double a = 0.0;
> int main()
> {
> 
> char b;
> double t1 = a;
> __asm__ ("fucompp": "=a" (b) : "u" (t1), "t" (t1) : "cc", "st", "st(1)");
> 
> return 0;
> }
> 
> This should conflict with the output - t1 which is st, and st which is st 
> aswell.

In FreeBSD ports, we are now getting this new error message when compiling 
svgalib (see https://bugs.freebsd.org/216154), when compiling with clang 4.0.0.

While fixing it, we noticed something strange (or interesting, depending on 
your point of view), namely that it does not seem to handle the first input or 
output operand, e.g. "0".  For example, svgalib has this inline function:

/* Always 32-bit align destination, even for a small number of bytes. */
static inline void *
 __memcpy_aligndest(void *dest, const void *src, int n)
{
__asm__ __volatile__("cmpl $3, %%ecx\n\t"
 "ja 1f\n\t"
 "call * __memcpy_jumptable (, %%ecx, 4)\n\t"
 "jmp 2f\n\t"
 "1:call __memcpyasm_regargs\n\t"
 "2:":
 :"S"(dest), "d"(src), "c"(n)
 :"ax", "0", "1", "2");
return dest;
}

The error produced for this is:

svgalib-1.4.3/gl/inlstring.h:281:17: error: asm-specifier for input or output 
variable conflicts with asm clobber list
 :"ax", "0", "1", "2");
 ^

And indeed, removing the "1" and "2" input operands fixes the error.  However, 
by definition, "0" is always an input or output operand, so should it not 
produce an error too?

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] r323040 - Assume the shared library path variable is LD_LIBRARY_PATH on systems

2018-01-20 Thread Dimitry Andric via cfe-commits

Author: dim
Date: Sat Jan 20 06:34:33 2018
New Revision: 323040

URL: http://llvm.org/viewvc/llvm-project?rev=323040&view=rev
Log:
Assume the shared library path variable is LD_LIBRARY_PATH on systems
except Darwin and Windows.  This prevents inserting an environment
variable with an empty name (which is illegal and leads to a Python
exception) on any of the BSDs.

Modified:
clang-tools-extra/trunk/test/Unit/lit.cfg

Modified: clang-tools-extra/trunk/test/Unit/lit.cfg
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/Unit/lit.cfg?rev=323040&r1=323039&r2=323040&view=diff
==
--- clang-tools-extra/trunk/test/Unit/lit.cfg (original)
+++ clang-tools-extra/trunk/test/Unit/lit.cfg Sat Jan 20 06:34:33 2018
@@ -19,13 +19,12 @@ config.test_exec_root = config.test_sour
 # ;-separated list of subdirectories).
 config.test_format = lit.formats.GoogleTest('.', 'Tests')
 
-shlibpath_var = ''
-if platform.system() == 'Linux':
-shlibpath_var = 'LD_LIBRARY_PATH'
-elif platform.system() == 'Darwin':
+if platform.system() == 'Darwin':
 shlibpath_var = 'DYLD_LIBRARY_PATH'
 elif platform.system() == 'Windows':
 shlibpath_var = 'PATH'
+else:
+shlibpath_var = 'LD_LIBRARY_PATH'
 
 # Point the dynamic loader at dynamic libraries in 'lib'.
 shlibpath = os.path.pathsep.join((config.shlibdir, config.llvm_libs_dir,


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libcxx] r302362 - Ensure showbase does not overflow do_put buffers

2017-05-06 Thread Dimitry Andric via cfe-commits

Author: dim
Date: Sat May  6 15:58:50 2017
New Revision: 302362

URL: http://llvm.org/viewvc/llvm-project?rev=302362&view=rev
Log:
Ensure showbase does not overflow do_put buffers

Summary:
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.

To ensure this does not happen, add one additional character to the
do_put buffers if std::showbase is on.  Also add a test case.

Reviewers: EricWF, mclow.lists

Reviewed By: EricWF

Subscribers: cfe-commits, emaste

Differential Revision: https://reviews.llvm.org/D32670

Added:

libcxx/trunk/test/std/input.output/iostream.format/output.streams/ostream.formatted/ostream.inserters.arithmetic/minmax_showbase.pass.cpp
Modified:
libcxx/trunk/include/locale

Modified: libcxx/trunk/include/locale
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/locale?rev=302362&r1=302361&r2=302362&view=diff
==
--- libcxx/trunk/include/locale (original)
+++ libcxx/trunk/include/locale Sat May  6 15:58:50 2017
@@ -1402,6 +1402,7 @@ num_put<_CharT, _OutputIterator>::do_put
 this->__format_int(__fmt+1, __len, true, __iob.flags());
 const unsigned __nbuf = (numeric_limits::digits / 3)
   + ((numeric_limits::digits % 3) != 0)
+  + ((__iob.flags() & ios_base::showbase) != 0)
   + 2;
 char __nar[__nbuf];
 int __nc = __libcpp_snprintf_l(__nar, sizeof(__nar), _LIBCPP_GET_C_LOCALE, 
__fmt, __v);
@@ -1428,6 +1429,7 @@ num_put<_CharT, _OutputIterator>::do_put
 this->__format_int(__fmt+1, __len, true, __iob.flags());
 const unsigned __nbuf = (numeric_limits::digits / 3)
   + ((numeric_limits::digits % 3) != 0)
+  + ((__iob.flags() & ios_base::showbase) != 0)
   + 2;
 char __nar[__nbuf];
 int __nc = __libcpp_snprintf_l(__nar, sizeof(__nar), _LIBCPP_GET_C_LOCALE, 
__fmt, __v);
@@ -1454,6 +1456,7 @@ num_put<_CharT, _OutputIterator>::do_put
 this->__format_int(__fmt+1, __len, false, __iob.flags());
 const unsigned __nbuf = (numeric_limits::digits / 3)
   + ((numeric_limits::digits % 3) != 0)
+  + ((__iob.flags() & ios_base::showbase) != 0)
   + 1;
 char __nar[__nbuf];
 int __nc = __libcpp_snprintf_l(__nar, sizeof(__nar), _LIBCPP_GET_C_LOCALE, 
__fmt, __v);
@@ -1480,6 +1483,7 @@ num_put<_CharT, _OutputIterator>::do_put
 this->__format_int(__fmt+1, __len, false, __iob.flags());
 const unsigned __nbuf = (numeric_limits::digits / 3)
   + ((numeric_limits::digits % 3) 
!= 0)
+  + ((__iob.flags() & ios_base::showbase) != 0)
   + 1;
 char __nar[__nbuf];
 int __nc = __libcpp_snprintf_l(__nar, sizeof(__nar), _LIBCPP_GET_C_LOCALE, 
__fmt, __v);

Added: 
libcxx/trunk/test/std/input.output/iostream.format/output.streams/ostream.formatted/ostream.inserters.arithmetic/minmax_showbase.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/input.output/iostream.format/output.streams/ostream.formatted/ostream.inserters.arithmetic/minmax_showbase.pass.cpp?rev=302362&view=auto
==
--- 
libcxx/trunk/test/std/input.output/iostream.format/output.streams/ostream.formatted/ostream.inserters.arithmetic/minmax_showbase.pass.cpp
 (added)
+++ 
libcxx/trunk/test/std/input.output/iostream.format/output.streams/ostream.formatted/ostream.inserters.arithmetic/minmax_showbase.pass.cpp
 Sat May  6 15:58:50 2017
@@ -0,0 +1,97 @@
+//===--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+
+// 
+
+// template  >
+//   class basic_ostream;
+
+// operator<<(short n);
+// operator<<(unsigned short n);
+// operator<<(int n);
+// operator<<(unsigned int n);
+// operator<<(long n);
+// operator<<(unsigned long n);
+// operator<<(long long n);
+// operator<<(unsigned long long n);
+
+//  Testing to make sure that the max length values are correctly inserted when
+//  using std::showbase
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+template 
+static void test(std::ios_base::fmtflags fmt, const char *expected)
+{
+std::stringstream ss;
+ss.setf(fmt, std::ios_base::basefield);
+ss << std::showbase << (std::is_signed::value ? 
std::numeric_limits::min() : std::numeric_limits::max());
+assert(ss.str

Re: r286129 - [OPENMP] Fixed codegen for real/imag expressions in atomic

2016-11-07 Thread Dimitry Andric via cfe-commits

Hi Alexey,

Does this look like a good candidate for 3.9.1?

-Dimitry

> On 07 Nov 2016, at 19:15, Alexey Bataev via cfe-commits 
>  wrote:
> 
> Author: abataev
> Date: Mon Nov  7 12:15:02 2016
> New Revision: 286129
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=286129&view=rev
> Log:
> [OPENMP] Fixed codegen for __real/__imag expressions in atomic
> constructs.
> 
> For __real/__imag unary expressions clang emits lvalue with the
> associated type from the original complex expression, but not the
> underlying builtin integer or float type. This causes crash in codegen
> for atomic constructs, if __real/__imag expression are used in atomic
>  constructs.
> 
> Modified:
>cfe/trunk/lib/CodeGen/CGExpr.cpp
>cfe/trunk/test/OpenMP/atomic_write_codegen.c
> 
> Modified: cfe/trunk/lib/CodeGen/CGExpr.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGExpr.cpp?rev=286129&r1=286128&r2=286129&view=diff
> ==
> --- cfe/trunk/lib/CodeGen/CGExpr.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGExpr.cpp Mon Nov  7 12:15:02 2016
> @@ -2276,13 +2276,15 @@ LValue CodeGenFunction::EmitUnaryOpLValu
>   return LV;
> }
> 
> -assert(E->getSubExpr()->getType()->isAnyComplexType());
> +QualType T = ExprTy->castAs()->getElementType();
> 
> Address Component =
>   (E->getOpcode() == UO_Real
>  ? emitAddrOfRealComponent(LV.getAddress(), LV.getType())
>  : emitAddrOfImagComponent(LV.getAddress(), LV.getType()));
> -return MakeAddrLValue(Component, ExprTy, LV.getAlignmentSource());
> +LValue ElemLV = MakeAddrLValue(Component, T, LV.getAlignmentSource());
> +ElemLV.getQuals().addQualifiers(LV.getQuals());
> +return ElemLV;
>   }
>   case UO_PreInc:
>   case UO_PreDec: {
> 
> Modified: cfe/trunk/test/OpenMP/atomic_write_codegen.c
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/OpenMP/atomic_write_codegen.c?rev=286129&r1=286128&r2=286129&view=diff
> ==
> --- cfe/trunk/test/OpenMP/atomic_write_codegen.c (original)
> +++ cfe/trunk/test/OpenMP/atomic_write_codegen.c Mon Nov  7 12:15:02 2016
> @@ -78,6 +78,9 @@ float2 float2x;
> register int rix __asm__("esp");
> 
> int main() {
> +// CHECK: store atomic i32 1, i32* getelementptr inbounds ({ i32, i32 }, { 
> i32, i32 }* @civ, i32 0, i32 1) monotonic,
> +#pragma omp atomic write
> + __imag(civ) = 1;
> // CHECK: load i8, i8*
> // CHECK: store atomic i8
> #pragma omp atomic write
> 
> 
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D13051: Add placeholder __libcpp_relaxed_store() for when atomic builtins are not available.

2015-09-22 Thread Dimitry Andric via cfe-commits

dim created this revision.
dim added reviewers: EricWF, mclow.lists.
dim added subscribers: majnemer, jroelofs, cfe-commits.
Herald added a subscriber: aemerson.

In rL241532, atomic_support.h was added, which provides handling of
atomic operations for libc++.  When atomic builtins are not available,
it emits a warning about being unsupported, but it still provides a
number of stubs for the required functions.

However, it misses a stub for __libcpp_relaxed_store().  Add it, by
using the same implementation as for __libcpp_atomic_store().

(Note that I encountered this on arm-freebsd, which still defaults to
armv4, and does not have the runtime libcalls to support atomic
builtins.  For now, I have simply disabled using them.)

http://reviews.llvm.org/D13051

Files:
  src/include/atomic_support.h

Index: src/include/atomic_support.h
===
--- src/include/atomic_support.h
+++ src/include/atomic_support.h
@@ -103,6 +103,13 @@
 *__dest = __val;
 }
 
+template 
+inline _LIBCPP_INLINE_VISIBILITY
+void __libcpp_relaxed_store(_ValueType* __dest, _FromType __val)
+{
+*__dest = __val;
+}
+
 template 
 inline _LIBCPP_INLINE_VISIBILITY
 _ValueType __libcpp_atomic_load(_ValueType const* __val,


Index: src/include/atomic_support.h
===
--- src/include/atomic_support.h
+++ src/include/atomic_support.h
@@ -103,6 +103,13 @@
 *__dest = __val;
 }
 
+template 
+inline _LIBCPP_INLINE_VISIBILITY
+void __libcpp_relaxed_store(_ValueType* __dest, _FromType __val)
+{
+*__dest = __val;
+}
+
 template 
 inline _LIBCPP_INLINE_VISIBILITY
 _ValueType __libcpp_atomic_load(_ValueType const* __val,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D13051: Add placeholder __libcpp_relaxed_store() for when atomic builtins are not available.

2015-09-22 Thread Dimitry Andric via cfe-commits

dim added a comment.

In http://reviews.llvm.org/D13051#250836, @EricWF wrote:

> Does anything actually need this? This interface was never really meant to be 
> complete, just want was needed.

I need it at least for FreeBSD/arm, since it defaults to armv4, and it does not 
yet have a full set of atomic ops as libcalls.  In any case, if stub functions 
are provided, they should at least compile. :-)

http://reviews.llvm.org/D13051

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libcxx] r248313 - Add placeholder __libcpp_relaxed_store() for when atomic builtins are not available.

2015-09-22 Thread Dimitry Andric via cfe-commits

Author: dim
Date: Tue Sep 22 13:55:37 2015
New Revision: 248313

URL: http://llvm.org/viewvc/llvm-project?rev=248313&view=rev
Log:
Add placeholder __libcpp_relaxed_store() for when atomic builtins are not 
available.

Summary:
In rL241532, atomic_support.h was added, which provides handling of
atomic operations for libc++.  When atomic builtins are not available,
it emits a warning about being unsupported, but it still provides a
number of stubs for the required functions.

However, it misses a stub for `__libcpp_relaxed_store()`.  Add it, by
using the same implementation as for `__libcpp_atomic_store()`.

(Note that I encountered this on arm-freebsd, which still defaults to
armv4, and does not have the runtime libcalls to support atomic
builtins.  For now, I have simply disabled using them.)

Reviewers: mclow.lists, EricWF

Subscribers: theraven, cfe-commits, jroelofs, majnemer, aemerson

Differential Revision: http://reviews.llvm.org/D13051

Modified:
libcxx/trunk/src/include/atomic_support.h

Modified: libcxx/trunk/src/include/atomic_support.h
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/src/include/atomic_support.h?rev=248313&r1=248312&r2=248313&view=diff
==
--- libcxx/trunk/src/include/atomic_support.h (original)
+++ libcxx/trunk/src/include/atomic_support.h Tue Sep 22 13:55:37 2015
@@ -103,6 +103,13 @@ void __libcpp_atomic_store(_ValueType* _
 *__dest = __val;
 }
 
+template 
+inline _LIBCPP_INLINE_VISIBILITY
+void __libcpp_relaxed_store(_ValueType* __dest, _FromType __val)
+{
+*__dest = __val;
+}
+
 template 
 inline _LIBCPP_INLINE_VISIBILITY
 _ValueType __libcpp_atomic_load(_ValueType const* __val,


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r244063 - Add missing atomic libcall support.

2015-09-22 Thread Dimitry Andric via cfe-commits

On 05 Aug 2015, at 18:57, James Y Knight  wrote:
> Author: jyknight
> Date: Wed Aug  5 11:57:36 2015
> New Revision: 244063
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=244063&view=rev
> Log:
> Add missing atomic libcall support.
> 
> Support for emitting libcalls for __atomic_fetch_nand and
> __atomic_{add,sub,and,or,xor,nand}_fetch was missing; add it, and some
> test cases.
> 
> Differential Revision: http://reviews.llvm.org/D10847

Hi James, is this OK to merge to the 3.7 branch, targeting 3.7.1?

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D13051: Add placeholder __libcpp_relaxed_store() for when atomic builtins are not available.

2015-09-22 Thread Dimitry Andric via cfe-commits

dim added a comment.

In http://reviews.llvm.org/D13051#250921, @jroelofs wrote:

> In http://reviews.llvm.org/D13051#250910, @EricWF wrote:
>
> > @jroelofs @dim, could we fallback to the __sync_* builtins on arm?
>

The actual implementations of these __sync builtins should still come from 
somewhere, as they will also be libcalls, right?

> @dim would need armv4-flavored implementations of them in compiler-rt (if 
> that's what he's using)... the existing ones use instructions that v4 doesn't 
> have.

Andrew Turner, a fellow FreeBSD developer, has added them pretty quickly, in 
https://svnweb.freebsd.org/base?view=revision&revision=288125.  So I have now 
reverted the ugly workaround in FreeBSD that disabled 
_LIBCPP_HAS_ATOMIC_BUILTINS for arm < v6.

http://reviews.llvm.org/D13051

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r239883 - Update the intel intrinsic headers to use the target attribute support.

2015-08-17 Thread Dimitry Andric via cfe-commits

[Re-sending, used the old cfe-commits address by accident]

Where is the other thread?  This problem still exists, for both trunk and the 
upcoming 3.7.0 RC3.  I'll try to submit a patch tomorrow to partially restore 
the include guards, so we won't have a broken release.

-Dimitry

> On 03 Aug 2015, at 18:48, Eric Christopher  > wrote:
> 
> 
> 
> Where are the negative test cases? Diagnosing uses of these functions
> when they aren't valid is really important - it's a pretty serious
> regression if we don't.
> 
> Two threads, I'm going to take this in the other thread. :)
> 
> -eric
> 
> 
> ___
> cfe-commits mailing list
> cfe-comm...@cs.uiuc.edu 
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r239883 - Update the intel intrinsic headers to use the target attribute support.

2015-08-18 Thread Dimitry Andric via cfe-commits

The problems from my earlier mail still stand, even with trunk r245199.

1) Various configure scripts (e.g. lame and others) try to check for intrinsics 
using fragments similar to the following:

#include 

then running that through "clang -E".  If preprocessing succeeds, the 
intrinsics are assumed to be available, otherwise they are not.

The changes in r239883 break this assumption.  In my opinion, intrinsics 
headers should always cause a compilation error, when the specific intrinsics 
asked for are not available.  Of course configure scripts can always be hacked 
up to cope, but this is really the wrong way around.

2) When those configure scripts erroneously assume specific intrinsics are 
available, while they really are not, and the program attempts to use them, 
clang dies with a fatal backend error, for example:

SplitVectorResult #0: 0x2bbd2f3c: v4f32 = llvm.x86.sse.sqrt.ps 0x2bbd53a8, 
0x2bbd2ea0 [ORD=11] [ID=0]

fatal error: error in backend: Do not know how to split the result of this 
operator!

This problem is reported in https://llvm.org/bugs/show_bug.cgi?id=24335 .

-Dimitry

> On 18 Aug 2015, at 00:08, Eric Christopher  wrote:
> 
> There is nothing broken about not having the include guards there, it's just 
> not helpful. I'm working on the infrastructure for an error if you call a 
> function from within an incompatible routine at the moment (without 
> duplicating a lot of code it's actually a bit annoying), but there's nothing 
> actually wrong with the code. It's just the same as basically saying 
> asm("invalid_instruction") in a random function.
> 
> Any configure script that was depending on error conditions from this is 
> already broken by gcc as well, and likely icc.
> 
> -eric
> 
> On Mon, Aug 17, 2015 at 3:04 PM Dimitry Andric  > wrote:
> [Re-sending, used the old cfe-commits address by accident]
> 
> Where is the other thread?  This problem still exists, for both trunk and the 
> upcoming 3.7.0 RC3.  I'll try to submit a patch tomorrow to partially restore 
> the include guards, so we won't have a broken release.
> 
> -Dimitry
> 
>> On 03 Aug 2015, at 18:48, Eric Christopher > > wrote:
>> 
> 
>> 
>> 
>> Where are the negative test cases? Diagnosing uses of these functions
>> when they aren't valid is really important - it's a pretty serious
>> regression if we don't.
>> 
>> Two threads, I'm going to take this in the other thread. :)
>> 
>> -eric
>> 
>> 
> 
>> ___
>> cfe-commits mailing list
>> cfe-comm...@cs.uiuc.edu 
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits 
>> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r239883 - Update the intel intrinsic headers to use the target attribute support.

2015-08-18 Thread Dimitry Andric via cfe-commits

No, it does not occur in the 3.7 branch, thanks for reverting those changes. :)

-Dimitry

> On 18 Aug 2015, at 01:09, Hans Wennborg  wrote:
> 
> The 3.7 branch does have the include guards; they were re-added in
> http://llvm.org/viewvc/llvm-project?rev=243925&view=rev. That happened
> after rc2, but it will be in rc3.
> 
> Can you double check if you're still running into problems on the 3.7 branch?
> 
> - Hans
> 
> 
> On Mon, Aug 17, 2015 at 3:04 PM, Dimitry Andric  wrote:
>> [Re-sending, used the old cfe-commits address by accident]
>> 
>> Where is the other thread?  This problem still exists, for both trunk and
>> the upcoming 3.7.0 RC3.  I'll try to submit a patch tomorrow to partially
>> restore the include guards, so we won't have a broken release.
>> 
>> -Dimitry
>> 
>> On 03 Aug 2015, at 18:48, Eric Christopher  wrote:
>> 
>>> 
>>> 
>>> Where are the negative test cases? Diagnosing uses of these functions
>>> when they aren't valid is really important - it's a pretty serious
>>> regression if we don't.
>> 
>> 
>> Two threads, I'm going to take this in the other thread. :)
>> 
>> -eric
>> 
>> 
>> ___
>> cfe-commits mailing list
>> cfe-comm...@cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>> 
>> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r239883 - Update the intel intrinsic headers to use the target attribute support.

2015-08-18 Thread Dimitry Andric via cfe-commits

> On 18 Aug 2015, at 19:52, Eric Christopher  wrote:
> 
> 
> 
> On Tue, Aug 18, 2015 at 10:51 AM Dimitry Andric  wrote:
> The problems from my earlier mail still stand, even with trunk r245199.
> 
> 1) Various configure scripts (e.g. lame and others) try to check for 
> intrinsics using fragments similar to the following:
> 
> #include 
> 
> then running that through "clang -E".  If preprocessing succeeds, the 
> intrinsics are assumed to be available, otherwise they are not.
> 
> The changes in r239883 break this assumption.  In my opinion, intrinsics 
> headers should always cause a compilation error, when the specific intrinsics 
> asked for are not available.  Of course configure scripts can always be 
> hacked up to cope, but this is really the wrong way around.
> 
> 
> I fundamentally disagree with you. As does everyone else that ships these 
> headers these days.

Aha, I see now what you mean:

$ cat simple-detect.c
#include 

$ gcc47 -c simple-detect.c
In file included from simple-detect.c:1:0:
/usr/local/lib/gcc47/gcc/i386-portbld-freebsd11.0/4.7.4/include/xmmintrin.h:32:3:
 error: #error "SSE instruction set not enabled"

$ gcc48 -c simple-detect.c
In file included from simple-detect.c:1:0:
/usr/local/lib/gcc48/gcc/i386-portbld-freebsd11.0/4.8.5/include/xmmintrin.h:31:3:
 error: #error "SSE instruction set not enabled"
 # error "SSE instruction set not enabled"
   ^

$ gcc49 -c simple-detect.c


E.g., somewhere between gcc 4.8 and 4.9, they also removed the include guards 
from their intrinsics headers.  (It seems to be this commit: 
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=200349 )

So since this old method of just attempting to include certain intrinsics 
headers is not working anymore, what would be the correct new method of 
detecting whether certain classes of intrinsic are available with the current 
compilation flags?  For example, actually trying to call such an intrinsic?  Or 
maybe even attempt to link the program, and see if linking fails?


>  2) When those configure scripts erroneously assume specific intrinsics are 
> available, while they really are not, and the program attempts to use them, 
> clang dies with a fatal backend error, for example:
> 
> SplitVectorResult #0: 0x2bbd2f3c: v4f32 = llvm.x86.sse.sqrt.ps 0x2bbd53a8, 
> 0x2bbd2ea0 [ORD=11] [ID=0]
> 
> fatal error: error in backend: Do not know how to split the result of this 
> operator!
> 
> This problem is reported in https://llvm.org/bugs/show_bug.cgi?id=24335 .
> 
> 
> This will be a better error soon (next day or so) and come out of the front 
> end.

Thank you.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D11394: Fix warnings about pessimizing return moves for C++11 and higher

2015-08-18 Thread Dimitry Andric via cfe-commits

dim added a comment.

@ericwf, no, this just dropped off my radar, sorry.  I will commit it now. :)


http://reviews.llvm.org/D11394



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libcxx] r245421 - Fix warnings about pessimizing return moves for C++11 and higher

2015-08-18 Thread Dimitry Andric via cfe-commits

Author: dim
Date: Wed Aug 19 01:43:33 2015
New Revision: 245421

URL: http://llvm.org/viewvc/llvm-project?rev=245421&view=rev
Log:
Fix warnings about pessimizing return moves for C++11 and higher

Summary:
Throughout the libc++ headers, there are a few instances where
_VSTD::move() is used to return a local variable.  Howard commented in
r189039 that these were there "for non-obvious reasons such as to help
things limp along in C++03 language mode".

However, when compiling these headers with warnings on, and in C++11 or
higher mode (like we do in FreeBSD), they cause the following complaints
about pessimizing moves:

In file included from tests.cpp:26:
In file included from tests.hpp:29:
/usr/include/c++/v1/map:1368:12: error: moving a local object in a return 
statement prevents copy elision [-Werror,-Wpessimizing-move]
return _VSTD::move(__h);  // explicitly moved for C++03
   ^
/usr/include/c++/v1/__config:368:15: note: expanded from macro '_VSTD'
#define _VSTD std::_LIBCPP_NAMESPACE
  ^

Attempt to fix this by adding a _LIBCPP_EXPLICIT_MOVE() macro to
__config, which gets defined to _VSTD::move for pre-C++11, and to
nothing for C++11 and later.

I am not completely satisfied with the macro name (I also considered
_LIBCPP_COMPAT_MOVE and some other variants), so suggestions are
welcome. :)

Reviewers: mclow.lists, howard.hinnant, EricWF

Subscribers: arthur.j.odwyer, cfe-commits

Differential Revision: http://reviews.llvm.org/D11394

Modified:
libcxx/trunk/include/__config
libcxx/trunk/include/__hash_table
libcxx/trunk/include/__tree
libcxx/trunk/include/algorithm
libcxx/trunk/include/ext/hash_map
libcxx/trunk/include/map
libcxx/trunk/include/unordered_map

Modified: libcxx/trunk/include/__config
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__config?rev=245421&r1=245420&r2=245421&view=diff
==
--- libcxx/trunk/include/__config (original)
+++ libcxx/trunk/include/__config Wed Aug 19 01:43:33 2015
@@ -716,6 +716,12 @@ template  struct __static_asse
 #define _LIBCPP_CONSTEXPR_AFTER_CXX11
 #endif
 
+#ifdef _LIBCPP_HAS_NO_RVALUE_REFERENCES
+#  define _LIBCPP_EXPLICIT_MOVE(x) _VSTD::move(x)
+#else
+#  define _LIBCPP_EXPLICIT_MOVE(x) (x)
+#endif
+
 #ifndef _LIBCPP_HAS_NO_ASAN
 extern "C" void __sanitizer_annotate_contiguous_container(
   const void *, const void *, const void *, const void *);

Modified: libcxx/trunk/include/__hash_table
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__hash_table?rev=245421&r1=245420&r2=245421&view=diff
==
--- libcxx/trunk/include/__hash_table (original)
+++ libcxx/trunk/include/__hash_table Wed Aug 19 01:43:33 2015
@@ -2108,7 +2108,7 @@ __hash_table<_Tp, _Hash, _Equal, _Alloc>
 __h.get_deleter().__value_constructed = true;
 __h->__hash_ = hash_function()(__h->__value_);
 __h->__next_ = nullptr;
-return _VSTD::move(__h);  // explicitly moved for C++03
+return _LIBCPP_EXPLICIT_MOVE(__h);  // explicitly moved for C++03
 }
 
 #endif  // _LIBCPP_HAS_NO_RVALUE_REFERENCES
@@ -2124,7 +2124,7 @@ __hash_table<_Tp, _Hash, _Equal, _Alloc>
 __h.get_deleter().__value_constructed = true;
 __h->__hash_ = __hash;
 __h->__next_ = nullptr;
-return _VSTD::move(__h);  // explicitly moved for C++03
+return _LIBCPP_EXPLICIT_MOVE(__h);  // explicitly moved for C++03
 }
 
 template 

Modified: libcxx/trunk/include/__tree
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__tree?rev=245421&r1=245420&r2=245421&view=diff
==
--- libcxx/trunk/include/__tree (original)
+++ libcxx/trunk/include/__tree Wed Aug 19 01:43:33 2015
@@ -1843,7 +1843,7 @@ __tree<_Tp, _Compare, _Allocator>::__con
 __node_holder __h(__node_traits::allocate(__na, 1), _Dp(__na));
 __node_traits::construct(__na, _VSTD::addressof(__h->__value_), __v);
 __h.get_deleter().__value_constructed = true;
-return _VSTD::move(__h);  // explicitly moved for C++03
+return _LIBCPP_EXPLICIT_MOVE(__h);  // explicitly moved for C++03
 }
 
 #endif  // _LIBCPP_HAS_NO_RVALUE_REFERENCES

Modified: libcxx/trunk/include/algorithm
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/algorithm?rev=245421&r1=245420&r2=245421&view=diff
==
--- libcxx/trunk/include/algorithm (original)
+++ libcxx/trunk/include/algorithm Wed Aug 19 01:43:33 2015
@@ -851,7 +851,7 @@ for_each(_InputIterator __first, _InputI
 {
 for (; __first != __last; ++__first)
 __f(*__first);
-return _VSTD::move(__f);  // explicitly moved for (emulated) C++03
+return _LIBCPP_EXPLICIT_MOVE(__f);  // explicitly moved for (emulated) 
C++03
 }
 
 // find

Modified: libcxx/trunk/include/

Re: [Diffusion] rL244063: Add missing atomic libcall support.

2015-10-14 Thread Dimitry Andric via cfe-commits

dim added a subscriber: dim.
dim added auditors: 3.7-release, cfe-commits, tstellarAMD, jyknight, compnerd, 
majnemer.
dim added a comment.

This is a change that was required to be able to use clang 3.7.0 for FreeBSD on 
arm.  Please merge this to the 3.7 branch.  (I already mailed this to James 
earlier, and he said it looked good to him.)


Users:
  jyknight (Author, Auditor)
  3.7-release (Auditor)
  cfe-commits (Auditor)
  tstellarAMD (Auditor)
  compnerd (Auditor)
  majnemer (Auditor)

http://reviews.llvm.org/rL244063



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D13822: Support linking against OpenMP runtime on FreeBSD.

2015-10-16 Thread Dimitry Andric via cfe-commits

dim created this revision.
dim added reviewers: emaste, joerg, theraven.
dim added a subscriber: cfe-commits.

Similar to rL248426 (which was a followup to rL248379 and rL248424), add the
required libraries for OpenMP on the linker command line, and update the test
case.

http://reviews.llvm.org/D13822

Files:
  lib/Driver/Tools.cpp
  test/Driver/fopenmp.c

Index: test/Driver/fopenmp.c
===
--- test/Driver/fopenmp.c
+++ test/Driver/fopenmp.c
@@ -4,6 +4,9 @@
 // RUN: %clang -target x86_64-apple-darwin -fopenmp=libomp -c %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-CC1-OPENMP
 // RUN: %clang -target x86_64-apple-darwin -fopenmp=libgomp -c %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-CC1-NO-OPENMP
 // RUN: %clang -target x86_64-apple-darwin -fopenmp=libiomp5 -c %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-CC1-OPENMP
+// RUN: %clang -target x86_64-freebsd -fopenmp=libomp -c %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-CC1-OPENMP
+// RUN: %clang -target x86_64-freebsd -fopenmp=libgomp -c %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-CC1-NO-OPENMP
+// RUN: %clang -target x86_64-freebsd -fopenmp=libiomp5 -c %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-CC1-OPENMP
 // RUN: %clang -target x86_64-netbsd -fopenmp=libomp -c %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-CC1-OPENMP
 // RUN: %clang -target x86_64-netbsd -fopenmp=libgomp -c %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-CC1-NO-OPENMP
 // RUN: %clang -target x86_64-netbsd -fopenmp=libiomp5 -c %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-CC1-OPENMP
@@ -34,6 +37,10 @@
 // RUN: %clang -target x86_64-netbsd -fopenmp=libgomp %s -o %t -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-LD-GOMP
 // RUN: %clang -target x86_64-netbsd -fopenmp=libiomp5 %s -o %t -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-LD-IOMP5
 //
+// RUN: %clang -nostdlib -target x86_64-freebsd -fopenmp=libomp %s -o %t -### 
2>&1 | FileCheck %s --check-prefix=CHECK-NO-OMP
+// RUN: %clang -nostdlib -target x86_64-freebsd -fopenmp=libgomp %s -o %t -### 
2>&1 | FileCheck %s --check-prefix=CHECK-NO-GOMP
+// RUN: %clang -nostdlib -target x86_64-freebsd -fopenmp=libiomp5 %s -o %t 
-### 2>&1 | FileCheck %s --check-prefix=CHECK-NO-IOMP5
+//
 // RUN: %clang -nostdlib -target x86_64-netbsd -fopenmp=libomp %s -o %t -### 
2>&1 | FileCheck %s --check-prefix=CHECK-NO-OMP
 // RUN: %clang -nostdlib -target x86_64-netbsd -fopenmp=libgomp %s -o %t -### 
2>&1 | FileCheck %s --check-prefix=CHECK-NO-GOMP
 // RUN: %clang -nostdlib -target x86_64-netbsd -fopenmp=libiomp5 %s -o %t -### 
2>&1 | FileCheck %s --check-prefix=CHECK-NO-IOMP5
@@ -64,6 +71,7 @@
 //
 // RUN: %clang -target x86_64-linux-gnu -fopenmp %s -o %t -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-LD-ANY
 // RUN: %clang -target x86_64-darwin -fopenmp %s -o %t -### 2>&1 | FileCheck 
%s --check-prefix=CHECK-LD-ANY
+// RUN: %clang -target x86_64-freebsd -fopenmp %s -o %t -### 2>&1 | FileCheck 
%s --check-prefix=CHECK-LD-ANY
 // RUN: %clang -target x86_64-netbsd -fopenmp %s -o %t -### 2>&1 | FileCheck 
%s --check-prefix=CHECK-LD-ANY
 //
 // CHECK-LD-ANY: "{{.*}}ld{{(.exe)?}}"
Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -7612,6 +7612,7 @@
 
   if (!Args.hasArg(options::OPT_nostdlib) &&
   !Args.hasArg(options::OPT_nodefaultlibs)) {
+addOpenMPRuntime(CmdArgs, ToolChain, Args);
 if (D.CCCIsCXX()) {
   ToolChain.AddCXXStdlibLibArgs(Args, CmdArgs);
   if (Args.hasArg(options::OPT_pg))


Index: test/Driver/fopenmp.c
===
--- test/Driver/fopenmp.c
+++ test/Driver/fopenmp.c
@@ -4,6 +4,9 @@
 // RUN: %clang -target x86_64-apple-darwin -fopenmp=libomp -c %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-CC1-OPENMP
 // RUN: %clang -target x86_64-apple-darwin -fopenmp=libgomp -c %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-CC1-NO-OPENMP
 // RUN: %clang -target x86_64-apple-darwin -fopenmp=libiomp5 -c %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-CC1-OPENMP
+// RUN: %clang -target x86_64-freebsd -fopenmp=libomp -c %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-CC1-OPENMP
+// RUN: %clang -target x86_64-freebsd -fopenmp=libgomp -c %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-CC1-NO-OPENMP
+// RUN: %clang -target x86_64-freebsd -fopenmp=libiomp5 -c %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-CC1-OPENMP
 // RUN: %clang -target x86_64-netbsd -fopenmp=libomp -c %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-CC1-OPENMP
 // RUN: %clang -target x86_64-netbsd -fopenmp=libgomp -c %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-CC1-NO-OPENMP
 // RUN: %clang -target x86_64-netbsd -fopenmp=libiomp5 -c %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-CC1-OPENMP
@@ -34,6 +37,10 @@
 // RUN: %clang -target x86_64-netbsd -fopenmp=libgomp %s -o %t -### 2>&1 | FileCheck %s --check-prefix=CH

Re: r250473 - Add an error when calling a builtin that requires features that don't

2015-10-17 Thread Dimitry Andric via cfe-commits

On 16 Oct 2015, at 01:47, Eric Christopher via cfe-commits 
 wrote:
> 
> Author: echristo
> Date: Thu Oct 15 18:47:11 2015
> New Revision: 250473
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=250473&view=rev
> Log:
> Add an error when calling a builtin that requires features that don't
> match the feature set of the function that they're being called from.
...
> +def err_builtin_needs_feature : Error<"%0 needs target feature %1">;

Thanks.  Note, a typical error message now becomes something pretty terse, like 
this:

'__builtin_foo' needs target feature bar

It would be helpful if the error message gave some sort of hint on what the 
actual problem is (wrong -march parameter, probably?), and how to fix it.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r250657 - Support linking against OpenMP runtime on FreeBSD.

2015-10-18 Thread Dimitry Andric via cfe-commits

Author: dim
Date: Sun Oct 18 08:32:20 2015
New Revision: 250657

URL: http://llvm.org/viewvc/llvm-project?rev=250657&view=rev
Log:
Support linking against OpenMP runtime on FreeBSD.

Summary:
Similar to rL248426 (which was a followup to rL248379 and rL248424), add the
required libraries for OpenMP on the linker command line, and update the test
case.

Reviewers: emaste, theraven, joerg

Subscribers: cfe-commits

Differential Revision: http://reviews.llvm.org/D13822

Modified:
cfe/trunk/lib/Driver/Tools.cpp
cfe/trunk/test/Driver/fopenmp.c

Modified: cfe/trunk/lib/Driver/Tools.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=250657&r1=250656&r2=250657&view=diff
==
--- cfe/trunk/lib/Driver/Tools.cpp (original)
+++ cfe/trunk/lib/Driver/Tools.cpp Sun Oct 18 08:32:20 2015
@@ -7612,6 +7612,7 @@ void freebsd::Linker::ConstructJob(Compi
 
   if (!Args.hasArg(options::OPT_nostdlib) &&
   !Args.hasArg(options::OPT_nodefaultlibs)) {
+addOpenMPRuntime(CmdArgs, ToolChain, Args);
 if (D.CCCIsCXX()) {
   ToolChain.AddCXXStdlibLibArgs(Args, CmdArgs);
   if (Args.hasArg(options::OPT_pg))

Modified: cfe/trunk/test/Driver/fopenmp.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/fopenmp.c?rev=250657&r1=250656&r2=250657&view=diff
==
--- cfe/trunk/test/Driver/fopenmp.c (original)
+++ cfe/trunk/test/Driver/fopenmp.c Sun Oct 18 08:32:20 2015
@@ -4,6 +4,9 @@
 // RUN: %clang -target x86_64-apple-darwin -fopenmp=libomp -c %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-CC1-OPENMP
 // RUN: %clang -target x86_64-apple-darwin -fopenmp=libgomp -c %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-CC1-NO-OPENMP
 // RUN: %clang -target x86_64-apple-darwin -fopenmp=libiomp5 -c %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-CC1-OPENMP
+// RUN: %clang -target x86_64-freebsd -fopenmp=libomp -c %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-CC1-OPENMP
+// RUN: %clang -target x86_64-freebsd -fopenmp=libgomp -c %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-CC1-NO-OPENMP
+// RUN: %clang -target x86_64-freebsd -fopenmp=libiomp5 -c %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-CC1-OPENMP
 // RUN: %clang -target x86_64-netbsd -fopenmp=libomp -c %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-CC1-OPENMP
 // RUN: %clang -target x86_64-netbsd -fopenmp=libgomp -c %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-CC1-NO-OPENMP
 // RUN: %clang -target x86_64-netbsd -fopenmp=libiomp5 -c %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-CC1-OPENMP
@@ -34,6 +37,10 @@
 // RUN: %clang -target x86_64-netbsd -fopenmp=libgomp %s -o %t -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-LD-GOMP
 // RUN: %clang -target x86_64-netbsd -fopenmp=libiomp5 %s -o %t -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-LD-IOMP5
 //
+// RUN: %clang -nostdlib -target x86_64-freebsd -fopenmp=libomp %s -o %t -### 
2>&1 | FileCheck %s --check-prefix=CHECK-NO-OMP
+// RUN: %clang -nostdlib -target x86_64-freebsd -fopenmp=libgomp %s -o %t -### 
2>&1 | FileCheck %s --check-prefix=CHECK-NO-GOMP
+// RUN: %clang -nostdlib -target x86_64-freebsd -fopenmp=libiomp5 %s -o %t 
-### 2>&1 | FileCheck %s --check-prefix=CHECK-NO-IOMP5
+//
 // RUN: %clang -nostdlib -target x86_64-netbsd -fopenmp=libomp %s -o %t -### 
2>&1 | FileCheck %s --check-prefix=CHECK-NO-OMP
 // RUN: %clang -nostdlib -target x86_64-netbsd -fopenmp=libgomp %s -o %t -### 
2>&1 | FileCheck %s --check-prefix=CHECK-NO-GOMP
 // RUN: %clang -nostdlib -target x86_64-netbsd -fopenmp=libiomp5 %s -o %t -### 
2>&1 | FileCheck %s --check-prefix=CHECK-NO-IOMP5
@@ -64,6 +71,7 @@
 //
 // RUN: %clang -target x86_64-linux-gnu -fopenmp %s -o %t -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-LD-ANY
 // RUN: %clang -target x86_64-darwin -fopenmp %s -o %t -### 2>&1 | FileCheck 
%s --check-prefix=CHECK-LD-ANY
+// RUN: %clang -target x86_64-freebsd -fopenmp %s -o %t -### 2>&1 | FileCheck 
%s --check-prefix=CHECK-LD-ANY
 // RUN: %clang -target x86_64-netbsd -fopenmp %s -o %t -### 2>&1 | FileCheck 
%s --check-prefix=CHECK-LD-ANY
 //
 // CHECK-LD-ANY: "{{.*}}ld{{(.exe)?}}"


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [Diffusion] rL248426: Support linking against OpenMP runtime on NetBSD.

2015-10-18 Thread Dimitry Andric via cfe-commits

dim added a subscriber: dim.
dim added auditors: 3.7-release, cfe-commits, tstellarAMD, joerg.
dim added a comment.

Should be merged together with http://reviews.llvm.org/rL248379, 
http://reviews.llvm.org/rL248424, and http://reviews.llvm.org/rL250657.  
Together, these add support for linking against OpenMP on FreeBSD and NetBSD.


Users:
  joerg (Author, Auditor)
  3.7-release (Auditor)
  cfe-commits (Auditor)
  tstellarAMD (Auditor)

http://reviews.llvm.org/rL248426



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [Diffusion] rL248424: Push OpenMP linker flags after linker input on Darwin. Don't add any

2015-10-18 Thread Dimitry Andric via cfe-commits

dim added a subscriber: dim.
dim added auditors: 3.7-release, cfe-commits, tstellarAMD, joerg.
dim added a comment.

Should be merged together with http://reviews.llvm.org/rL248379, 
http://reviews.llvm.org/rL248426, and http://reviews.llvm.org/rL250657.  
Together, these add support for linking against OpenMP on FreeBSD and NetBSD.


Users:
  joerg (Author, Auditor)
  3.7-release (Auditor)
  cfe-commits (Auditor)
  tstellarAMD (Auditor)

http://reviews.llvm.org/rL248424



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [Diffusion] rL248379: Refactor library decision for -fopenmp support from Darwin into a

2015-10-18 Thread Dimitry Andric via cfe-commits

dim added a subscriber: dim.
dim added auditors: 3.7-release, cfe-commits, tstellarAMD, joerg.
dim added a comment.

Should be merged together with http://reviews.llvm.org/rL248424, 
http://reviews.llvm.org/rL248426, and http://reviews.llvm.org/rL250657.  
Together, these add support for linking against OpenMP on FreeBSD and NetBSD.


Users:
  joerg (Author, Auditor)
  3.7-release (Auditor)
  cfe-commits (Auditor)
  tstellarAMD (Auditor)

http://reviews.llvm.org/rL248379



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

1 2 >

1 - 100 of 167 matches

Mail list logo