Re: r316046 - Basic: fix __{,U}INTPTR_TYPE__ on ARM

[Joerg Sonnenberger via cfe-commits]

On Wed, Oct 18, 2017 at 12:00:51AM -, Saleem Abdulrasool via cfe-commits 
wrote:
> Author: compnerd
> Date: Tue Oct 17 17:00:50 2017
> New Revision: 316046
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=316046&view=rev
> Log:
> Basic: fix __{,U}INTPTR_TYPE__ on ARM
> 
> Darwin and OpenBSD are the only platforms which use `long int` for
> `__INTPTR_TYPE__`.  The other platforms use `int` in 32-bit, and `long
> int` on 64-bit (except for VMS and Windows which are LLP64).  Adjust the
> type definitions to match the platform definitions.  We now generate the
> same definition as GCC on all the targets.

This is false as the test changes show.

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

Re: r341475 - Fix arm_neon.h and arm_fp16.h generation for compiling with std=c89

[Joerg Sonnenberger via cfe-commits]

On Wed, Sep 05, 2018 at 02:56:21PM -, Diogo N. Sampaio via cfe-commits 
wrote:
> Author: dnsampaio
> Date: Wed Sep  5 07:56:21 2018
> New Revision: 341475
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=341475&view=rev
> Log:
> Fix arm_neon.h and arm_fp16.h generation for compiling with std=c89

As I wrote on the differential, this is just wrong. __inline is *not* a
keyword.

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

Re: [PATCH] D43203: [Driver] Generate .eh_frame_hdr for static executables too.

[Joerg Sonnenberger via cfe-commits]

On Mon, Feb 12, 2018 at 08:54:56PM +, Stephen Hines via Phabricator via 
cfe-commits wrote:
> srhines added a comment.
> 
> LGTM, but we should make sure that there are no objections, especially since 
> there is no rationale for why this was present to begin with.

Older versions of the GNU unwinder couldn't use it.

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

Re: r303317 - The constant expression evaluator should examine function arguments for non-constexpr function calls unless the EvalInfo says to stop.

[Joerg Sonnenberger via cfe-commits]

On Wed, May 17, 2017 at 11:56:55PM -, Nick Lewycky via cfe-commits wrote:
> Author: nicholas
> Date: Wed May 17 18:56:54 2017
> New Revision: 303317
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=303317&view=rev
> Log:
> The constant expression evaluator should examine function arguments for 
> non-constexpr function calls unless the EvalInfo says to stop.

Crashes with -std=c++11 on:

enum SizeHint { MinimumSize, MaximumSize };
class QSizeF {
public:
  constexpr QSizeF();
  QSizeF m_fn1(QSizeF);
  double wd;
  double ht;
};
constexpr QSizeF::QSizeF() : wd(), ht() {}
class A {
  void m_fn2();
  QSizeF m_fn3(SizeHint, const QSizeF & = QSizeF());
};
void A::m_fn2() { m_fn3(MinimumSize).m_fn1(m_fn3(MaximumSize)); }

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

Re: r297702 - [CodeGen][ObjC] Fix a bug where the type of an ivar wasn't encoded

[Joerg Sonnenberger via cfe-commits]

On Tue, Mar 14, 2017 at 04:00:53AM -, Akira Hatanaka via cfe-commits wrote:
> Author: ahatanak
> Date: Mon Mar 13 23:00:52 2017
> New Revision: 297702
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=297702&view=rev
> Log:
> [CodeGen][ObjC] Fix a bug where the type of an ivar wasn't encoded
> correctly.

This results in asserts on the attached test case. Can you have a look,
please?

Joerg
typedef BOOL;
@interface FormatScanner {
  BOOL : 1;
}
@end
@implementation FormatScanner
@end
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r303317 - The constant expression evaluator should examine function arguments for non-constexpr function calls unless the EvalInfo says to stop.

[Joerg Sonnenberger via cfe-commits]

On Tue, May 30, 2017 at 07:01:22PM -0700, Nick Lewycky wrote:
> Joerg Sonnenberger wrote:
> > On Wed, May 17, 2017 at 11:56:55PM -, Nick Lewycky via cfe-commits 
> > wrote:
> > > Author: nicholas
> > > Date: Wed May 17 18:56:54 2017
> > > New Revision: 303317
> > > 
> > > URL: http://llvm.org/viewvc/llvm-project?rev=303317&view=rev
> > > Log:
> > > The constant expression evaluator should examine function arguments for 
> > > non-constexpr function calls unless the EvalInfo says to stop.
> > 
> > Crashes with -std=c++11 on:
> > 
> > enum SizeHint { MinimumSize, MaximumSize };
> > class QSizeF {
> > public:
> >constexpr QSizeF();
> >QSizeF m_fn1(QSizeF);
> >double wd;
> >double ht;
> > };
> > constexpr QSizeF::QSizeF() : wd(), ht() {}
> > class A {
> >void m_fn2();
> >QSizeF m_fn3(SizeHint, const QSizeF&  = QSizeF());
> > };
> > void A::m_fn2() { m_fn3(MinimumSize).m_fn1(m_fn3(MaximumSize)); }
> 
> Did you run this with assertions disabled? This looks like another testcase
> for PR33140, but it should hit an assertion first.

Right, same problem as the second test case. This is somewhat
high-profile for me as it affects Qt5.

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

Re: r297702 - [CodeGen][ObjC] Fix a bug where the type of an ivar wasn't encoded

[Joerg Sonnenberger via cfe-commits]

On Thu, Jun 01, 2017 at 05:58:41PM -0700, Akira Hatanaka wrote:
> It crashes when there is an anonymous ivar of a bitfield type.
> 
> @interface FormatScanner {
>   int : 1;
> }
> @end
> 
> @implementation FormatScanner
> @end
> 
> I'm not sure if the code above is valid or not, but out of curiosity,
> why would you want an anonymous bitfield variable?

It's a reduced test case. The original test case has a variable name in
it.

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

Re: r305600 - [Driver] Do a PATH lookup if needed when using -no-canonical-prefixes

[Joerg Sonnenberger via cfe-commits]

On Fri, Jun 16, 2017 at 10:40:18PM -, Petr Hosek via cfe-commits wrote:
> @@ -53,8 +53,15 @@ using namespace clang::driver;
>  using namespace llvm::opt;
>  
>  std::string GetExecutablePath(const char *Argv0, bool CanonicalPrefixes) {
> -  if (!CanonicalPrefixes)
> -return Argv0;
> +  if (!CanonicalPrefixes) {
> +SmallString<128> ExecutablePath(Argv0);
> +// Do a PATH lookup if Argv0 isn't a valid path.
> +if (!llvm::sys::fs::exists(ExecutablePath))
> +  if (llvm::ErrorOr P =
> +  llvm::sys::findProgramByName(ExecutablePath))
> +ExecutablePath = *P;
> +return ExecutablePath.str();
> +  }
>  
>// This just needs to be some symbol in the binary; C++ doesn't
>// allow taking the address of ::main however.

This will fail if the current directory contains a file with the name of
the program, won't it? I think the correct order here would be to check
if ExecutablePath contains a path separator and if it doesn't, call
findProgramByName.

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

Re: r297702 - [CodeGen][ObjC] Fix a bug where the type of an ivar wasn't encoded

[Joerg Sonnenberger via cfe-commits]

On Mon, Jun 12, 2017 at 09:03:10PM +0200, Joerg Sonnenberger wrote:
> On Thu, Jun 01, 2017 at 05:58:41PM -0700, Akira Hatanaka wrote:
> > It crashes when there is an anonymous ivar of a bitfield type.
> > 
> > @interface FormatScanner {
> >   int : 1;
> > }
> > @end
> > 
> > @implementation FormatScanner
> > @end
> > 
> > I'm not sure if the code above is valid or not, but out of curiosity,
> > why would you want an anonymous bitfield variable?
> 
> It's a reduced test case. The original test case has a variable name in
> it.

Ping?

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

Re: r297702 - [CodeGen][ObjC] Fix a bug where the type of an ivar wasn't encoded

[Joerg Sonnenberger via cfe-commits]

On Thu, Jun 22, 2017 at 11:09:48AM -0700, Akira Hatanaka wrote:
> Do you want the same encoding for the bitfield “int : 1” you saw before 
> r297792, which is just “i"?
> 
> The encoding for bitfield is normally bN where N is the number of bits,
> but the comment in function EncodeBitField says GNU runtime encodes it 
> differently.

Sorry, can't answer that. I primarily care about a new clang crash that
didn't exist before, cut I can't answer what the correct behavior should
be.

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

Re: r350776 - [Sema] Mark target of __attribute__((alias("target"))) used for C

[Joerg Sonnenberger via cfe-commits]

On Thu, Jan 10, 2019 at 09:58:39AM -0800, Nick Desaulniers via cfe-commits 
wrote:
> On Thu, Jan 10, 2019 at 7:26 AM Nico Weber  wrote:
> >
> > Aren't C names sometimes slightly mangled too? For example, on macOS 
> > they're prefixed by a _, doesn't that have to be undone there?
> 
> Sure, but short of instantiating a demangler in Sema or rewriting how
> Clang checks for unused variables, this quickly cuts down on tens of
> false negatives when building the Linux kernel with various driver
> configurations enabled.  The code review points out this is
> suboptimal.

Can't you build a map of mangled names to function instances instead?
That should be pretty cheap to do any avoids the whole unmangling dance.
It would also fix cases like functions explicitly being renamed.

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

Re: [PATCH] D53922: [clangd] fix non linux build

[Joerg Sonnenberger via cfe-commits]

On Wed, Oct 31, 2018 at 08:53:03AM +, Sam McCall via Phabricator via 
cfe-commits wrote:
> sammccall accepted this revision.
> sammccall added a comment.
> This revision is now accepted and ready to land.
> 
> Thanks!
> We should work out what to do on BSD+Mac (and windows at some point), but 
> no-op is good for now.

Is this really a good idea in general? It means that on a busy system,
the thread will never run...

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

r354937 - Fix inline assembler constraint validation

[Joerg Sonnenberger via cfe-commits]

Author: joerg
Date: Tue Feb 26 16:40:59 2019
New Revision: 354937

URL: http://llvm.org/viewvc/llvm-project?rev=354937&view=rev
Log:
Fix inline assembler constraint validation

The current constraint logic is both too lax and too strict. It fails
for input outside the [INT_MIN..INT_MAX] range, but it also implicitly
accepts 0 as value when it should not. Adjust logic to handle both
correctly.

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

Modified:
cfe/trunk/include/clang/Basic/TargetInfo.h
cfe/trunk/test/Sema/inline-asm-validate-x86.c

Modified: cfe/trunk/include/clang/Basic/TargetInfo.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/TargetInfo.h?rev=354937&r1=354936&r2=354937&view=diff
==
--- cfe/trunk/include/clang/Basic/TargetInfo.h (original)
+++ cfe/trunk/include/clang/Basic/TargetInfo.h Tue Feb 26 16:40:59 2019
@@ -816,6 +816,7 @@ public:
 struct {
   int Min;
   int Max;
+  bool isConstrained;
 } ImmRange;
 llvm::SmallSet ImmSet;
 
@@ -826,6 +827,7 @@ public:
 : Flags(0), TiedOperand(-1), ConstraintStr(ConstraintStr.str()),
   Name(Name.str()) {
   ImmRange.Min = ImmRange.Max = 0;
+  ImmRange.isConstrained = false;
 }
 
 const std::string &getConstraintStr() const { return ConstraintStr; }
@@ -854,8 +856,9 @@ public:
   return (Flags & CI_ImmediateConstant) != 0;
 }
 bool isValidAsmImmediate(const llvm::APInt &Value) const {
-  return (Value.sge(ImmRange.Min) && Value.sle(ImmRange.Max)) ||
- ImmSet.count(Value.getZExtValue()) != 0;
+  if (!ImmSet.empty())
+return ImmSet.count(Value.getZExtValue()) != 0;
+  return !ImmRange.isConstrained || (Value.sge(ImmRange.Min) && 
Value.sle(ImmRange.Max));
 }
 
 void setIsReadWrite() { Flags |= CI_ReadWrite; }
@@ -867,6 +870,7 @@ public:
   Flags |= CI_ImmediateConstant;
   ImmRange.Min = Min;
   ImmRange.Max = Max;
+  ImmRange.isConstrained = true;
 }
 void setRequiresImmediate(llvm::ArrayRef Exacts) {
   Flags |= CI_ImmediateConstant;
@@ -879,8 +883,6 @@ public:
 }
 void setRequiresImmediate() {
   Flags |= CI_ImmediateConstant;
-  ImmRange.Min = INT_MIN;
-  ImmRange.Max = INT_MAX;
 }
 
 /// Indicate that this is an input operand that is tied to

Modified: cfe/trunk/test/Sema/inline-asm-validate-x86.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/inline-asm-validate-x86.c?rev=354937&r1=354936&r2=354937&view=diff
==
--- cfe/trunk/test/Sema/inline-asm-validate-x86.c (original)
+++ cfe/trunk/test/Sema/inline-asm-validate-x86.c Tue Feb 26 16:40:59 2019
@@ -55,6 +55,7 @@ void K(int i, int j) {
 void L(int i, int j) {
   static const int Invalid1 = 1;
   static const int Invalid2 = 42;
+  static const int Invalid3 = 0;
   static const int Valid1 = 0xff;
   static const int Valid2 = 0x;
   static const int Valid3 = 0x;
@@ -69,6 +70,9 @@ void L(int i, int j) {
   : "0"(i), "L"(Invalid2)); // expected-error{{value '42' out of range 
for constraint 'L'}}
   __asm__("xorl %0,%2"
   : "=r"(i)
+  : "0"(i), "L"(Invalid3)); // expected-error{{value '0' out of range 
for constraint 'L'}}
+  __asm__("xorl %0,%2"
+  : "=r"(i)
   : "0"(i), "L"(Valid1)); // expected-no-error
   __asm__("xorl %0,%2"
   : "=r"(i)


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

r355033 - Use Secure PLT as default on NetBSD/PowerPC.

[Joerg Sonnenberger via cfe-commits]

Author: joerg
Date: Wed Feb 27 13:46:01 2019
New Revision: 355033

URL: http://llvm.org/viewvc/llvm-project?rev=355033&view=rev
Log:
Use Secure PLT as default on NetBSD/PowerPC.

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

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=355033&r1=355032&r2=355033&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Arch/PPC.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Arch/PPC.cpp Wed Feb 27 13:46:01 2019
@@ -115,7 +115,7 @@ ppc::ReadGOTPtrMode ppc::getPPCReadGOTPt
   const ArgList &Args) {
   if (Args.getLastArg(options::OPT_msecure_plt))
 return ppc::ReadGOTPtrMode::SecurePlt;
-  if (Triple.isOSOpenBSD())
+  if (Triple.isOSNetBSD() || Triple.isOSOpenBSD())
 return ppc::ReadGOTPtrMode::SecurePlt;
   else
 return ppc::ReadGOTPtrMode::Bss;

Modified: cfe/trunk/test/Driver/netbsd.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/netbsd.c?rev=355033&r1=355032&r2=355033&view=diff
==
--- cfe/trunk/test/Driver/netbsd.c (original)
+++ cfe/trunk/test/Driver/netbsd.c Wed Feb 27 13:46:01 2019
@@ -446,3 +446,8 @@
 // PTHREAD-NOT: _POSIX_THREADS
 // PTHREAD: _REENTRANT
 // PTHREAD-NOT: _POSIX_THREADS
+
+// Check PowerPC for Secure PLT
+// RUN: %clang -target powerpc-unknown-netbsd -### -c %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=POWERPC-SECUREPLT %s
+// POWERPC-SECUREPLT: "-target-feature" "+secure-plt"


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

r355058 - Ensure that set constrained asm operands are not affected by truncation.

[Joerg Sonnenberger via cfe-commits]

Author: joerg
Date: Wed Feb 27 16:55:09 2019
New Revision: 355058

URL: http://llvm.org/viewvc/llvm-project?rev=355058&view=rev
Log:
Ensure that set constrained asm operands are not affected by truncation.

Modified:
cfe/trunk/include/clang/Basic/TargetInfo.h
cfe/trunk/test/Sema/inline-asm-validate-x86.c

Modified: cfe/trunk/include/clang/Basic/TargetInfo.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/TargetInfo.h?rev=355058&r1=355057&r2=355058&view=diff
==
--- cfe/trunk/include/clang/Basic/TargetInfo.h (original)
+++ cfe/trunk/include/clang/Basic/TargetInfo.h Wed Feb 27 16:55:09 2019
@@ -857,8 +857,10 @@ public:
 }
 bool isValidAsmImmediate(const llvm::APInt &Value) const {
   if (!ImmSet.empty())
-return ImmSet.count(Value.getZExtValue()) != 0;
-  return !ImmRange.isConstrained || (Value.sge(ImmRange.Min) && 
Value.sle(ImmRange.Max));
+return Value.isSignedIntN(32) &&
+   ImmSet.count(Value.getZExtValue()) != 0;
+  return !ImmRange.isConstrained ||
+ (Value.sge(ImmRange.Min) && Value.sle(ImmRange.Max));
 }
 
 void setIsReadWrite() { Flags |= CI_ReadWrite; }

Modified: cfe/trunk/test/Sema/inline-asm-validate-x86.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/inline-asm-validate-x86.c?rev=355058&r1=355057&r2=355058&view=diff
==
--- cfe/trunk/test/Sema/inline-asm-validate-x86.c (original)
+++ cfe/trunk/test/Sema/inline-asm-validate-x86.c Wed Feb 27 16:55:09 2019
@@ -56,6 +56,7 @@ void L(int i, int j) {
   static const int Invalid1 = 1;
   static const int Invalid2 = 42;
   static const int Invalid3 = 0;
+  static const long long Invalid4 = 0x100ff;
   static const int Valid1 = 0xff;
   static const int Valid2 = 0x;
   static const int Valid3 = 0x;
@@ -73,6 +74,9 @@ void L(int i, int j) {
   : "0"(i), "L"(Invalid3)); // expected-error{{value '0' out of range 
for constraint 'L'}}
   __asm__("xorl %0,%2"
   : "=r"(i)
+  : "0"(i), "L"(Invalid4)); // expected-error{{value '4294967551' out 
of range for constraint 'L'}}
+  __asm__("xorl %0,%2"
+  : "=r"(i)
   : "0"(i), "L"(Valid1)); // expected-no-error
   __asm__("xorl %0,%2"
   : "=r"(i)


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

Re: [PATCH] D60728: [clang] [test] Add a (xfailing) test for PR41027

[Joerg Sonnenberger via cfe-commits]

On Wed, Apr 17, 2019 at 05:34:04PM +, Kamil Rytarowski via Phabricator 
wrote:
> Right now this blocks upgrades on NetBSD as a number of CPUs is affected (but 
> not x86, so it was overlooked before 8.0 by others than @joerg).

Note that this is not about anything really specific to NetBSD, the kind
of conditional asm statements are pretty popular.

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

Re: r312595 - [Darwin] Enable -fstack-protector (back) by default with -ffreestanding

[Joerg Sonnenberger via cfe-commits]

On Tue, Sep 05, 2017 at 11:50:58PM -, Bruno Cardoso Lopes via cfe-commits 
wrote:
> Modified: cfe/trunk/lib/Driver/ToolChains/Clang.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Clang.cpp?rev=312595&r1=312594&r2=312595&view=diff
> ==
> --- cfe/trunk/lib/Driver/ToolChains/Clang.cpp (original)
> +++ cfe/trunk/lib/Driver/ToolChains/Clang.cpp Tue Sep  5 16:50:58 2017
> @@ -2302,11 +2302,6 @@ static void RenderSSPOptions(const ToolC
>  else if (A->getOption().matches(options::OPT_fstack_protector_all))
>StackProtectorLevel = LangOptions::SSPReq;
>} else {
> -// Only use a default stack protector on Darwin in case -ffreestanding is
> -// not specified.
> -if (EffectiveTriple.isOSDarwin() && !IsHosted)
> -  StackProtectorLevel = 0;
> -else
>StackProtectorLevel = DefaultStackProtectorLevel;
>}

Indentation?

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

Re: [PATCH] D34158: For Linux/gnu compatibility, preinclude if the file is available

[Joerg Sonnenberger via cfe-commits]

On Tue, Sep 12, 2017 at 08:12:26PM +, Blower, Melanie via cfe-commits wrote:
> How is platform opt-in accomplished, is it part of the configure step?

It is part of the Linux toolchain, other platforms interested in this or
equivalent functionality would have to duplicate the hook.

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

Re: [PATCH] D55828: [clang] [Driver] Disable -faddrsig by default on NetBSD

[Joerg Sonnenberger via cfe-commits]

On Tue, Dec 18, 2018 at 04:35:54PM +, Michał Górny via Phabricator via 
cfe-commits wrote:
> mgorny created this revision.
> mgorny added reviewers: krytarowski, pcc.
> 
> Avoid passing -faddrsig by default on NetBSD.  This platform is still
> using old GNU binutils that crashes on executables containing those
> sections.

I find that a strange claim, given that many Linux distributions in the
wild have much older GNU binutils.

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

Re: r349752 - Replace getOS() == llvm::Triple::*BSD with isOS*BSD() [NFCI]

[Joerg Sonnenberger via cfe-commits]

On Thu, Dec 20, 2018 at 01:09:30PM -, Michal Gorny via cfe-commits wrote:
> Author: mgorny
> Date: Thu Dec 20 05:09:30 2018
> New Revision: 349752
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=349752&view=rev
> Log:
> Replace getOS() == llvm::Triple::*BSD with isOS*BSD() [NFCI]
> 
> Replace multiple comparisons of getOS() value with FreeBSD, NetBSD,
> OpenBSD and DragonFly with matching isOS*BSD() methods.  This should
> improve the consistency of coding style without changing the behavior.
> Direct getOS() comparisons were left whenever used in switch or switch-
> like context.

Personally, I consider this a step backwards and I hugely dislike the
pointless proliferation of isOS* methods.

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

Re: [PATCH] D56044: [Driver] Support object files in addition to static and shared libraries in compiler-rt

[Joerg Sonnenberger via cfe-commits]

On Sat, Dec 22, 2018 at 03:22:11AM +, Petr Hosek via Phabricator via 
cfe-commits wrote:
> phosek created this revision.
> phosek added a reviewer: echristo.
> Herald added subscribers: cfe-commits, atanasyan, jrtc27, dberris, sdardis.
> 
> This change introduces support for object files in addition to static
> and shared libraries which were already supported which requires
> changing the type of the argument from boolean to an enum.

Not really a fan of this at all. Why isn't the normal -B path lookup
enough?

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

Re: [PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Joerg Sonnenberger via cfe-commits]

On Thu, Jan 03, 2019 at 06:34:22PM +, Kamil Rytarowski via Phabricator via 
cfe-commits wrote:
> krytarowski added a comment.
> 
> Actually I find it frustrating and unfair as GNU ld doesn't have builtin
> knowledge either.. it's passed with gross 'super hack' comments from build 
> scripts... but we are forced to push it to lld in order to move on.

I'm puzzled. Seriously, when was the last time you actually checked how
much customization contains on a per-OS base in GNU ld? Yes, I'm
including the various build scripts because GNU ld is generally build by
a mix of hard-coded logic in the tool itself and various adjustments in
the linker scripts it is shipped with. But they are all a builtin part
of GNU ld as far as the end user is concerned. It is pretty much
irrelevant from a point of functionality where that logic is, but
skipping is a serious usability issue.

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

Re: [PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Joerg Sonnenberger via cfe-commits]

On Thu, Jan 03, 2019 at 06:58:41PM +, Kamil Rytarowski via Phabricator 
wrote:
> But the result is that we don't have GNU gold either and are stuck with
> 40min linking times of LLVM. It's destructive to productivity and
> damages any LLVM related development.

The reason noone cared much about GNU gold is that it supports only a
limited set of platforms and forces a lot of modern GNU "innovations"
without any chance of fixing them. To a degree, both concerns apply to
lld as well, but reasonable well integrated LTO support with Clang
provides at least something in return. I have no idea about your link
times, the only situation where linking is taking a really significant
chunk of time is for full debug builds and the general solution for that
is DWARF fission.

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

Re: [PATCH] D17741: adds __FILE_BASENAME__ builtin macro

[Joerg Sonnenberger via cfe-commits]

On Thu, Jan 03, 2019 at 05:01:00PM +, Ximin Luo via cfe-commits wrote:
> My patch that Roman quoted in the email below was an additional
> mechanism to set -fmacro-prefix-map and -fdebug-prefix-map via an
> environment variable. This was not accepted into GCC because they are
> (in summary) allergic against using environment variables to set anything.

The main problem here is that GCC insists on leaking the full command
line into the output and that makes it difficult to impossible to
actually provide sane mappings without using the environment.

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

Re: [PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Joerg Sonnenberger via cfe-commits]

On Thu, Jan 03, 2019 at 08:31:53PM +, Kamil Rytarowski via Phabricator via 
cfe-commits wrote:
> krytarowski added a comment.
> 
> On 03.01.2019 21:19, Joerg Sonnenberger wrote:
> 
> > On Thu, Jan 03, 2019 at 06:34:22PM +, Kamil Rytarowski via Phabricator 
> > via cfe-commits wrote:
> > 
> >> krytarowski added a comment.
> >> 
> >> Actually I find it frustrating and unfair as GNU ld doesn't have builtin
> >>  knowledge either.. it's passed with gross 'super hack' comments from 
> >> build scripts... but we are forced to push it to lld in order to move on.
> > 
> > I'm puzzled. Seriously, when was the last time you actually checked how
> >  much customization contains on a per-OS base in GNU ld? Yes, I'm
> >  including the various build scripts because GNU ld is generally build by
> >  a mix of hard-coded logic in the tool itself and various adjustments in
> >  the linker scripts it is shipped with. But they are all a builtin part
> >  of GNU ld as far as the end user is concerned. It is pretty much
> >  irrelevant from a point of functionality where that logic is, but
> >  skipping is a serious usability issue.
> > 
> > Joerg
> 
> I'm referring to code '/usr/src/external/gpl3/binutils/usr.bin/ld/Makefile':

I think that's a left over from old times before the emulparams/* logic
was done properly. But that's more a case of GNU ld's build system being
gross than anything else.

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

Re: [PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Joerg Sonnenberger via cfe-commits]

On Thu, Jan 03, 2019 at 09:38:49PM +, Kamil Rytarowski via Phabricator via 
cfe-commits wrote:
> I think that this place is not the right place to bash GNU ld for performance 
> issues.

I didn't.

> I will refer just to slides and paper from Ian Lance Taylor to get overview 
> why it is unacceptably slow:
> 
> https://www.airs.com/ian/gold-slides.pdf
> https://ai.google/research/pubs/pub34417.pdf

We all know that gold and lld are faster. It's a huge step from
"somewhat faster" to "unacceptably slow". But that's again a completely
separate topic.

> I will add that (unless nothing changed recently) ignoring lack of
> features (like thinlto) GNU ld cannot produce >=4GB executables and
> this makes it even more unusable.

That sounds seriously like a troll. I already mentioned DWARF fission
for the one reasonable case for > 100MB binaries and that's in short
"don't touch most of the data"...

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

Re: [PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Joerg Sonnenberger via cfe-commits]

On Thu, Jan 03, 2019 at 10:26:38PM +, Rui Ueyama via Phabricator via 
cfe-commits wrote:
> I see there are pros and cons to not have host-specific config in ld.
> That said, if other operating systems can live without host-specific
> config in lld, why can't NetBSD do? I really don't like to be in a
> situation where only one operating system have a host-specific config
> while others don't.

They might not care because they use the thousand monkey approach to
software patching. At least for NetBSD, that's certainly man power
that's better spend elsewhere. They might simply have ignored lld so far
for any of the more interesting cases (like supporting multi-abi).
Lots of possible reasons :)

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

Re: [PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Joerg Sonnenberger via cfe-commits]

On Fri, Jan 04, 2019 at 05:52:46AM +, Michał Górny via Phabricator via 
llvm-commits wrote:
> mgorny added a comment.
> 
> For the record, another option is to actually fix other software not to call 
> LD directly.

See thousand monkeys. It doesn't really scale.

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

Re: [PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Joerg Sonnenberger via cfe-commits]

On Fri, Jan 04, 2019 at 02:48:35PM +, Alexander Richardson via Phabricator 
wrote:
> Or if you really need to call the linker directly without specifying
> search paths you could also install a shell script as /usr/bin/ld that
> passes the appropriate flags to /usr/bin/ld.lld?

That's not a honest suggestion, is it?

> I don't think ifdefs in the source code are a good idea. Cross linking
> should just work as expected. But you could look at the OS field in the
> first input ELF file to choose default config options/a different
> emulation for NetBSD.

No, #if is certainly wrong. Using the OS field doesn't work though,
because it is typically not set. I think only FreeBSD ever did.

> The approach we are using in CheriBSD to differentiate between MIPS and
> CHERI pure-capability to either pass an explicitly
> `-m elf_btsmip_cheri_fbsd`/ `-m elf_btsmip_fbsd` or infer whether it is
> CHERI or MIPS based on the e_flags field of the first input file.

Yeah, but introducing new emulation names goes back to having to modify
things, which would defeat the purpose just as well.

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

Re: [PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Joerg Sonnenberger via cfe-commits]

On Tue, Jan 08, 2019 at 10:58:37PM +, Alexander Richardson via Phabricator 
via cfe-commits wrote:
> arichardson added inline comments.
> 
> 
> 
> Comment at: ELF/Driver.cpp:770
> +  // Start with a default initial triple
> +  Config->TargetTriple = llvm::Triple(getDefaultTargetTriple());
> +
> 
> If I invoke an unprefixed ld.lld on NetBSD but want to target a
> different operating system, this will cause all the NetBSD defaults to
> apply to that binary and will possibly cause it to crash at runtime.

...which no different from clang.

> I think any config changes based on a triple would need to use an
> explicit --target= flag instead. As @ruiu says, LLD's behaviour should
> not change depending on the host OS/default LLVM triple. Given the same
> input files and command line options the resulting binary should be
> identical on any host.

That boils down to either "lld is unusable out of the box" or "your
system must look similar enough to a GNU/Linux environment for lld to
work". I don't consider that useful behavior at all.

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

Re: [PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Joerg Sonnenberger via cfe-commits]

On Wed, Jan 09, 2019 at 12:20:06AM +, Kamil Rytarowski via Phabricator via 
llvm-commits wrote:
> krytarowski added inline comments.
> 
> 
> 
> Comment at: ELF/Driver.cpp:781
> +  }
> +}
> +
> 
> There is need to add a fallback for a native triple.

Not really. That's what the default target is.

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

r336947 - Support linking static PIE binaries on NetBSD

[Joerg Sonnenberger via cfe-commits]

Author: joerg
Date: Thu Jul 12 14:21:29 2018
New Revision: 336947

URL: http://llvm.org/viewvc/llvm-project?rev=336947&view=rev
Log:
Support linking static PIE binaries on NetBSD

Modified:
cfe/trunk/lib/Driver/ToolChains/NetBSD.cpp
cfe/trunk/test/Driver/netbsd.c

Modified: cfe/trunk/lib/Driver/ToolChains/NetBSD.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/NetBSD.cpp?rev=336947&r1=336946&r2=336947&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains/NetBSD.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/NetBSD.cpp Thu Jul 12 14:21:29 2018
@@ -122,6 +122,10 @@ void netbsd::Linker::ConstructJob(Compil
   CmdArgs.push_back("--eh-frame-hdr");
   if (Args.hasArg(options::OPT_static)) {
 CmdArgs.push_back("-Bstatic");
+if (Args.hasArg(options::OPT_pie)) {
+  Args.AddAllArgs(CmdArgs, options::OPT_pie);
+  CmdArgs.push_back("--no-dynamic-linker");
+}
   } else {
 if (Args.hasArg(options::OPT_rdynamic))
   CmdArgs.push_back("-export-dynamic");

Modified: cfe/trunk/test/Driver/netbsd.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/netbsd.c?rev=336947&r1=336946&r2=336947&view=diff
==
--- cfe/trunk/test/Driver/netbsd.c (original)
+++ cfe/trunk/test/Driver/netbsd.c Thu Jul 12 14:21:29 2018
@@ -5,6 +5,9 @@
 // RUN: -pie --sysroot=%S/Inputs/basic_netbsd_tree %s -### 2>&1 \
 // RUN: | FileCheck -check-prefix=PIE %s
 // RUN: %clang -no-canonical-prefixes -target x86_64--netbsd \
+// RUN: -static -pie --sysroot=%S/Inputs/basic_netbsd_tree %s -### 2>&1 \
+// RUN: | FileCheck -check-prefix=STATIC-PIE %s
+// RUN: %clang -no-canonical-prefixes -target x86_64--netbsd \
 // RUN: -shared --sysroot=%S/Inputs/basic_netbsd_tree %s -### 2>&1 \
 // RUN: | FileCheck -check-prefix=SHARED %s
 
@@ -139,6 +142,16 @@
 // STATIC: "{{.*}}/usr/lib{{/|}}crti.o" 
"{{.*}}/usr/lib{{/|}}crtbegin.o"
 // STATIC: "{{.*}}/usr/lib{{/|}}crtend.o" "{{.*}}/usr/lib{{/|}}crtn.o"
 
+// STATIC-PIE: ld{{.*}}" "--eh-frame-hdr"
+// STATIC-PIE-NOT: "-dynamic-linker" "/libexec/ld.elf_so"
+// STATIC-PIE-NOT: "-Bshareable"
+// STATIC-PIE: "-pie"
+// STATIC-PIE-NOT: "-dynamic-linker" "/libexec/ld.elf_so"
+// STATIC-PIE-NOT: "-Bshareable"
+// STATIC-PIE: "{{.*}}/usr/lib{{/|}}crt0.o"
+// STATIC-PIE: "{{.*}}/usr/lib{{/|}}crti.o" 
"{{.*}}/usr/lib{{/|}}crtbeginS.o"
+// STATIC-PIE: "{{.*}}/usr/lib{{/|}}crtendS.o" 
"{{.*}}/usr/lib{{/|}}crtn.o"
+
 // SHARED: ld{{.*}}" "--eh-frame-hdr"
 // SHARED-NOT: "-pie"
 // SHARED-NOT: "-dynamic-linker"


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

r337271 - By popular demand, switch in64_t on NetBSD/AArch64 and NetBSD/PowerPC64

[Joerg Sonnenberger via cfe-commits]

Author: joerg
Date: Tue Jul 17 05:33:19 2018
New Revision: 337271

URL: http://llvm.org/viewvc/llvm-project?rev=337271&view=rev
Log:
By popular demand, switch in64_t on NetBSD/AArch64 and NetBSD/PowerPC64
to long for consistency with other 64bit platforms.

Modified:
cfe/trunk/lib/Basic/Targets/AArch64.cpp
cfe/trunk/lib/Basic/Targets/PPC.h
cfe/trunk/test/Preprocessor/init.c
cfe/trunk/test/Preprocessor/stdint.c

Modified: cfe/trunk/lib/Basic/Targets/AArch64.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets/AArch64.cpp?rev=337271&r1=337270&r2=337271&view=diff
==
--- cfe/trunk/lib/Basic/Targets/AArch64.cpp (original)
+++ cfe/trunk/lib/Basic/Targets/AArch64.cpp Tue Jul 17 05:33:19 2018
@@ -35,14 +35,11 @@ const Builtin::Info AArch64TargetInfo::B
 AArch64TargetInfo::AArch64TargetInfo(const llvm::Triple &Triple,
  const TargetOptions &Opts)
 : TargetInfo(Triple), ABI("aapcs") {
-  if (getTriple().getOS() == llvm::Triple::NetBSD ||
-  getTriple().getOS() == llvm::Triple::OpenBSD) {
-// NetBSD apparently prefers consistency across ARM targets to
-// consistency across 64-bit targets.
+  if (getTriple().getOS() == llvm::Triple::OpenBSD) {
 Int64Type = SignedLongLong;
 IntMaxType = SignedLongLong;
   } else {
-if (!getTriple().isOSDarwin())
+if (!getTriple().isOSDarwin() && getTriple().getOS() != 
llvm::Triple::NetBSD)
   WCharType = UnsignedInt;
 
 Int64Type = SignedLong;

Modified: cfe/trunk/lib/Basic/Targets/PPC.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets/PPC.h?rev=337271&r1=337270&r2=337271&view=diff
==
--- cfe/trunk/lib/Basic/Targets/PPC.h (original)
+++ cfe/trunk/lib/Basic/Targets/PPC.h Tue Jul 17 05:33:19 2018
@@ -366,10 +366,6 @@ public:
   LongDoubleWidth = LongDoubleAlign = 64;
   LongDoubleFormat = &llvm::APFloat::IEEEdouble();
   break;
-case llvm::Triple::NetBSD:
-  IntMaxType = SignedLongLong;
-  Int64Type = SignedLongLong;
-  break;
 default:
   break;
 }

Modified: cfe/trunk/test/Preprocessor/init.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Preprocessor/init.c?rev=337271&r1=337270&r2=337271&view=diff
==
--- cfe/trunk/test/Preprocessor/init.c (original)
+++ cfe/trunk/test/Preprocessor/init.c Tue Jul 17 05:33:19 2018
@@ -724,21 +724,21 @@
 // AARCH64-NETBSD:#define __INT32_FMTi__ "i"
 // AARCH64-NETBSD:#define __INT32_MAX__ 2147483647
 // AARCH64-NETBSD:#define __INT32_TYPE__ int
-// AARCH64-NETBSD:#define __INT64_C_SUFFIX__ LL
-// AARCH64-NETBSD:#define __INT64_FMTd__ "lld"
-// AARCH64-NETBSD:#define __INT64_FMTi__ "lli"
-// AARCH64-NETBSD:#define __INT64_MAX__ 9223372036854775807LL
-// AARCH64-NETBSD:#define __INT64_TYPE__ long long int
+// AARCH64-NETBSD:#define __INT64_C_SUFFIX__ L
+// AARCH64-NETBSD:#define __INT64_FMTd__ "ld"
+// AARCH64-NETBSD:#define __INT64_FMTi__ "li"
+// AARCH64-NETBSD:#define __INT64_MAX__ 9223372036854775807L
+// AARCH64-NETBSD:#define __INT64_TYPE__ long int
 // AARCH64-NETBSD:#define __INT8_C_SUFFIX__
 // AARCH64-NETBSD:#define __INT8_FMTd__ "hhd"
 // AARCH64-NETBSD:#define __INT8_FMTi__ "hhi"
 // AARCH64-NETBSD:#define __INT8_MAX__ 127
 // AARCH64-NETBSD:#define __INT8_TYPE__ signed char
-// AARCH64-NETBSD:#define __INTMAX_C_SUFFIX__ LL
-// AARCH64-NETBSD:#define __INTMAX_FMTd__ "lld"
-// AARCH64-NETBSD:#define __INTMAX_FMTi__ "lli"
-// AARCH64-NETBSD:#define __INTMAX_MAX__ 9223372036854775807LL
-// AARCH64-NETBSD:#define __INTMAX_TYPE__ long long int
+// AARCH64-NETBSD:#define __INTMAX_C_SUFFIX__ L
+// AARCH64-NETBSD:#define __INTMAX_FMTd__ "ld"
+// AARCH64-NETBSD:#define __INTMAX_FMTi__ "li"
+// AARCH64-NETBSD:#define __INTMAX_MAX__ 9223372036854775807L
+// AARCH64-NETBSD:#define __INTMAX_TYPE__ long int
 // AARCH64-NETBSD:#define __INTMAX_WIDTH__ 64
 // AARCH64-NETBSD:#define __INTPTR_FMTd__ "ld"
 // AARCH64-NETBSD:#define __INTPTR_FMTi__ "li"
@@ -824,15 +824,15 @@
 // AARCH64-NETBSD:#define __UINT32_C_SUFFIX__ U
 // AARCH64-NETBSD:#define __UINT32_MAX__ 4294967295U
 // AARCH64-NETBSD:#define __UINT32_TYPE__ unsigned int
-// AARCH64-NETBSD:#define __UINT64_C_SUFFIX__ ULL
-// AARCH64-NETBSD:#define __UINT64_MAX__ 18446744073709551615ULL
-// AARCH64-NETBSD:#define __UINT64_TYPE__ long long unsigned int
+// AARCH64-NETBSD:#define __UINT64_C_SUFFIX__ UL
+// AARCH64-NETBSD:#define __UINT64_MAX__ 18446744073709551615UL
+// AARCH64-NETBSD:#define __UINT64_TYPE__ long unsigned int
 // AARCH64-NETBSD:#define __UINT8_C_SUFFIX__
 // AARCH64-NETBSD:#define __UINT8_MAX__ 255
 // AARCH64-NETBSD:#define __UINT8_TYPE__ unsigned char
-// AARCH64-NETBSD:#define __UINTMAX_C_SUFFIX__ ULL
-// AARCH64-NETBSD:#define __UINTMAX_MAX__ 18446744073709551615ULL
-// AARCH64-NE

r337274 - For NetBSD, unwind data is emitted by default, so also enable frame

[Joerg Sonnenberger via cfe-commits]

Author: joerg
Date: Tue Jul 17 05:38:57 2018
New Revision: 337274

URL: http://llvm.org/viewvc/llvm-project?rev=337274&view=rev
Log:
For NetBSD, unwind data is emitted by default, so also enable frame
pointer optimisation by default when using optimisation.

Modified:
cfe/trunk/lib/Driver/ToolChains/Clang.cpp
cfe/trunk/test/Driver/frame-pointer-elim.c

Modified: cfe/trunk/lib/Driver/ToolChains/Clang.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Clang.cpp?rev=337274&r1=337273&r2=337274&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Clang.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Clang.cpp Tue Jul 17 05:38:57 2018
@@ -524,6 +524,10 @@ static bool useFramePointerForTargetByDe
 break;
   }
 
+  if (Triple.getOS() == llvm::Triple::NetBSD) {
+return !areOptimizationsEnabled(Args);
+  }
+
   if (Triple.isOSLinux() || Triple.getOS() == llvm::Triple::CloudABI) {
 switch (Triple.getArch()) {
 // Don't use a frame pointer on linux if optimizing for certain targets.

Modified: cfe/trunk/test/Driver/frame-pointer-elim.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/frame-pointer-elim.c?rev=337274&r1=337273&r2=337274&view=diff
==
--- cfe/trunk/test/Driver/frame-pointer-elim.c (original)
+++ cfe/trunk/test/Driver/frame-pointer-elim.c Tue Jul 17 05:38:57 2018
@@ -17,6 +17,15 @@
 // RUN:   FileCheck --check-prefix=CLOUDABI %s
 // CLOUDABI-NOT: "-momit-leaf-frame-pointer"
 
+// NetBSD follows the same rules as Linux.
+// RUN: %clang -### -target x86_64-unknown-netbsd -S -O1 %s 2>&1 | \
+// RUN:   FileCheck --check-prefix=NETBSD-OPT %s
+// NETBSD-OPT: "-momit-leaf-frame-pointer"
+
+// RUN: %clang -### -target x86_64-unknown-netbsd -S %s 2>&1 | \
+// RUN:   FileCheck --check-prefix=NETBSD %s
+// NETBSD-NOT: "-momit-leaf-frame-pointer"
+
 // Darwin disables omitting the leaf frame pointer even under optimization
 // unless the command lines are given.
 // RUN: %clang -### -target i386-apple-darwin -S %s 2>&1 | \


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

r337277 - Always use __mcount on NetBSD. Some platforms don't provide _mcount.

[Joerg Sonnenberger via cfe-commits]

Author: joerg
Date: Tue Jul 17 06:13:34 2018
New Revision: 337277

URL: http://llvm.org/viewvc/llvm-project?rev=337277&view=rev
Log:
Always use __mcount on NetBSD. Some platforms don't provide _mcount.

Modified:
cfe/trunk/lib/Basic/Targets/OSTargets.h
cfe/trunk/test/CodeGen/mcount.c
cfe/trunk/test/Frontend/gnu-mcount.c

Modified: cfe/trunk/lib/Basic/Targets/OSTargets.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets/OSTargets.h?rev=337277&r1=337276&r2=337277&view=diff
==
--- cfe/trunk/lib/Basic/Targets/OSTargets.h (original)
+++ cfe/trunk/lib/Basic/Targets/OSTargets.h Tue Jul 17 06:13:34 2018
@@ -369,7 +369,7 @@ protected:
 public:
   NetBSDTargetInfo(const llvm::Triple &Triple, const TargetOptions &Opts)
   : OSTargetInfo(Triple, Opts) {
-this->MCountName = "_mcount";
+this->MCountName = "__mcount";
   }
 };
 

Modified: cfe/trunk/test/CodeGen/mcount.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/mcount.c?rev=337277&r1=337276&r2=337277&view=diff
==
--- cfe/trunk/test/CodeGen/mcount.c (original)
+++ cfe/trunk/test/CodeGen/mcount.c Tue Jul 17 06:13:34 2018
@@ -3,20 +3,20 @@
 // RUN: %clang_cc1 -pg -triple powerpc-unknown-gnu-linux -emit-llvm -o - %s | 
FileCheck -check-prefixes=CHECK-PREFIXED,NO-MCOUNT1 %s
 // RUN: %clang_cc1 -pg -triple powerpc64-unknown-gnu-linux -emit-llvm -o - %s 
| FileCheck -check-prefixes=CHECK-PREFIXED,NO-MCOUNT1 %s
 // RUN: %clang_cc1 -pg -triple powerpc64le-unknown-gnu-linux -emit-llvm -o - 
%s | FileCheck -check-prefixes=CHECK-PREFIXED,NO-MCOUNT1 %s
-// RUN: %clang_cc1 -pg -triple i386-netbsd -emit-llvm -o - %s | FileCheck 
-check-prefixes=CHECK-PREFIXED,NO-MCOUNT1 %s
-// RUN: %clang_cc1 -pg -triple x86_64-netbsd -emit-llvm -o - %s | FileCheck 
-check-prefixes=CHECK-PREFIXED,NO-MCOUNT1 %s
-// RUN: %clang_cc1 -pg -triple arm-netbsd-eabi -emit-llvm -o - %s | FileCheck 
-check-prefixes=CHECK-PREFIXED,NO-MCOUNT1 %s
-// RUN: %clang_cc1 -pg -triple aarch64-netbsd -emit-llvm -o - %s | FileCheck 
-check-prefixes=CHECK-PREFIXED,NO-MCOUNT1 %s
-// RUN: %clang_cc1 -pg -triple mips-netbsd -emit-llvm -o - %s | FileCheck 
-check-prefixes=CHECK-PREFIXED,NO-MCOUNT1 %s
+// RUN: %clang_cc1 -pg -triple i386-netbsd -emit-llvm -o - %s | FileCheck 
-check-prefixes=CHECK-DOUBLE-PREFIXED,NO-MCOUNT1 %s
+// RUN: %clang_cc1 -pg -triple x86_64-netbsd -emit-llvm -o - %s | FileCheck 
-check-prefixes=CHECK-DOUBLE-PREFIXED,NO-MCOUNT1 %s
+// RUN: %clang_cc1 -pg -triple arm-netbsd-eabi -emit-llvm -o - %s | FileCheck 
-check-prefixes=CHECK-DOUBLE-PREFIXED,NO-MCOUNT1 %s
+// RUN: %clang_cc1 -pg -triple aarch64-netbsd -emit-llvm -o - %s | FileCheck 
-check-prefixes=CHECK-DOUBLE-PREFIXED,NO-MCOUNT1 %s
+// RUN: %clang_cc1 -pg -triple mips-netbsd -emit-llvm -o - %s | FileCheck 
-check-prefixes=CHECK-DOUBLE-PREFIXED,NO-MCOUNT1 %s
 // RUN: %clang_cc1 -pg -triple mips-unknown-gnu-linux -emit-llvm -o - %s | 
FileCheck -check-prefixes=CHECK-PREFIXED,NO-MCOUNT1 %s
 // RUN: %clang_cc1 -pg -triple mipsel-unknown-gnu-linux -emit-llvm -o - %s | 
FileCheck -check-prefixes=CHECK-PREFIXED,NO-MCOUNT1 %s
 // RUN: %clang_cc1 -pg -triple mips64-unknown-gnu-linux -emit-llvm -o - %s | 
FileCheck -check-prefixes=CHECK-PREFIXED,NO-MCOUNT1 %s
 // RUN: %clang_cc1 -pg -triple mips64el-unknown-gnu-linux -emit-llvm -o - %s | 
FileCheck -check-prefixes=CHECK-PREFIXED,NO-MCOUNT1 %s
-// RUN: %clang_cc1 -pg -triple powerpc-netbsd -emit-llvm -o - %s | FileCheck 
-check-prefixes=CHECK-PREFIXED,NO-MCOUNT1 %s
-// RUN: %clang_cc1 -pg -triple powerpc64-netbsd -emit-llvm -o - %s | FileCheck 
-check-prefixes=CHECK-PREFIXED,NO-MCOUNT1 %s
-// RUN: %clang_cc1 -pg -triple powerpc64le-netbsd -emit-llvm -o - %s | 
FileCheck -check-prefixes=CHECK-PREFIXED,NO-MCOUNT1 %s
-// RUN: %clang_cc1 -pg -triple sparc-netbsd -emit-llvm -o - %s | FileCheck 
-check-prefixes=CHECK-PREFIXED,NO-MCOUNT1 %s
-// RUN: %clang_cc1 -pg -triple sparc64-netbsd -emit-llvm -o - %s | FileCheck 
-check-prefixes=CHECK-PREFIXED,NO-MCOUNT1 %s
+// RUN: %clang_cc1 -pg -triple powerpc-netbsd -emit-llvm -o - %s | FileCheck 
-check-prefixes=CHECK-DOUBLE-PREFIXED,NO-MCOUNT1 %s
+// RUN: %clang_cc1 -pg -triple powerpc64-netbsd -emit-llvm -o - %s | FileCheck 
-check-prefixes=CHECK-DOUBLE-PREFIXED,NO-MCOUNT1 %s
+// RUN: %clang_cc1 -pg -triple powerpc64le-netbsd -emit-llvm -o - %s | 
FileCheck -check-prefixes=CHECK-DOUBLE-PREFIXED,NO-MCOUNT1 %s
+// RUN: %clang_cc1 -pg -triple sparc-netbsd -emit-llvm -o - %s | FileCheck 
-check-prefixes=CHECK-DOUBLE-PREFIXED,NO-MCOUNT1 %s
+// RUN: %clang_cc1 -pg -triple sparc64-netbsd -emit-llvm -o - %s | FileCheck 
-check-prefixes=CHECK-DOUBLE-PREFIXED,NO-MCOUNT1 %s
 // RUN: %clang_cc1 -emit-llvm -o - %s | FileCheck %s -check-prefix=NO-MCOUNT
 
 int bar(void) {
@@ -39,5 +39,7 @@ int main(void) {
 // CHECK: attributes #1 = { {{.*}} }
 // CHECK-PREFIXED: attribu

[libunwind] r337312 - The semantics of DW_CFA_GNU_args_size have changed subtile over the

[Joerg Sonnenberger via cfe-commits]

Author: joerg
Date: Tue Jul 17 12:00:51 2018
New Revision: 337312

URL: http://llvm.org/viewvc/llvm-project?rev=337312&view=rev
Log:
The semantics of DW_CFA_GNU_args_size have changed subtile over the
years. Adopt the new convention that it is call-site specific and that
it should be applied before moving the IP by personality routines, but
not during normal unwinding.

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

Modified:
libunwind/trunk/src/UnwindCursor.hpp
libunwind/trunk/src/libunwind.cpp

Modified: libunwind/trunk/src/UnwindCursor.hpp
URL: 
http://llvm.org/viewvc/llvm-project/libunwind/trunk/src/UnwindCursor.hpp?rev=337312&r1=337311&r2=337312&view=diff
==
--- libunwind/trunk/src/UnwindCursor.hpp (original)
+++ libunwind/trunk/src/UnwindCursor.hpp Tue Jul 17 12:00:51 2018
@@ -1411,8 +1411,6 @@ int UnwindCursor::step() {
 this->setInfoBasedOnIPRegister(true);
 if (_unwindInfoMissing)
   return UNW_STEP_END;
-if (_info.gp)
-  setReg(UNW_REG_SP, getReg(UNW_REG_SP) + _info.gp);
   }
 
   return result;

Modified: libunwind/trunk/src/libunwind.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libunwind/trunk/src/libunwind.cpp?rev=337312&r1=337311&r2=337312&view=diff
==
--- libunwind/trunk/src/libunwind.cpp (original)
+++ libunwind/trunk/src/libunwind.cpp Tue Jul 17 12:00:51 2018
@@ -188,8 +188,20 @@ _LIBUNWIND_EXPORT int unw_set_reg(unw_cu
 co->setReg(regNum, (pint_t)value);
 // specical case altering IP to re-find info (being called by personality
 // function)
-if (regNum == UNW_REG_IP)
+if (regNum == UNW_REG_IP) {
+  unw_proc_info_t info;
+  // First, get the FDE for the old location and then update it.
+  co->getInfo(&info);
   co->setInfoBasedOnIPRegister(false);
+  // If the original call expects stack adjustment, perform this now.
+  // Normal frame unwinding would have included the offset already in the
+  // CFA computation.
+  // Note: for PA-RISC and other platforms where the stack grows up,
+  // this should actually be - info.gp. LLVM doesn't currently support
+  // any such platforms and Clang doesn't export a macro for them.
+  if (info.gp)
+co->setReg(UNW_REG_SP, co->getReg(UNW_REG_SP) + info.gp);
+}
 return UNW_ESUCCESS;
   }
   return UNW_EBADREG;


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

r374742 - Improve __builtin_constant_p lowering

[Joerg Sonnenberger via cfe-commits]

Author: joerg
Date: Sun Oct 13 15:33:46 2019
New Revision: 374742

URL: http://llvm.org/viewvc/llvm-project?rev=374742&view=rev
Log:
Improve __builtin_constant_p lowering

__builtin_constant_p used to be short-cut evaluated to false when
building with -O0. This is undesirable as it means that constant folding
in the front-end can give different results than folding in the back-end.
It can also create conditional branches on constant conditions that don't
get folded away. With the pending improvements to the llvm.is.constant
handling on the LLVM side, the short-cut is no longer useful.

Adjust various codegen tests to not depend on the short-cut or the
backend optimisations.

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

Modified:
cfe/trunk/lib/CodeGen/CGBuiltin.cpp
cfe/trunk/test/CodeGen/builtin-constant-p.c
cfe/trunk/test/CodeGen/ppc-emmintrin.c
cfe/trunk/test/CodeGen/ppc-tmmintrin.c

Modified: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBuiltin.cpp?rev=374742&r1=374741&r2=374742&view=diff
==
--- cfe/trunk/lib/CodeGen/CGBuiltin.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp Sun Oct 13 15:33:46 2019
@@ -2101,10 +2101,6 @@ RValue CodeGenFunction::EmitBuiltinExpr(
 
   case Builtin::BI__builtin_constant_p: {
 llvm::Type *ResultType = ConvertType(E->getType());
-if (CGM.getCodeGenOpts().OptimizationLevel == 0)
-  // At -O0, we don't perform inlining, so we don't need to delay the
-  // processing.
-  return RValue::get(ConstantInt::get(ResultType, 0));
 
 const Expr *Arg = E->getArg(0);
 QualType ArgType = Arg->getType();

Modified: cfe/trunk/test/CodeGen/builtin-constant-p.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/builtin-constant-p.c?rev=374742&r1=374741&r2=374742&view=diff
==
--- cfe/trunk/test/CodeGen/builtin-constant-p.c (original)
+++ cfe/trunk/test/CodeGen/builtin-constant-p.c Sun Oct 13 15:33:46 2019
@@ -1,12 +1,8 @@
-// RUN: %clang_cc1 -triple x86_64-unknown-unknown -emit-llvm -o - %s -O2 | 
FileCheck %s
-// RUN: %clang_cc1 -triple x86_64-unknown-unknown -emit-llvm -o - %s -O0 | 
FileCheck --check-prefix=O0 %s
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -emit-llvm 
-disable-llvm-optzns -o - %s -O2 | FileCheck %s
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -emit-llvm 
-disable-llvm-optzns -o - %s -O0 | FileCheck %s
 
 int a = 42;
 
-inline int bcp(int x) {
-  return __builtin_constant_p(x);
-}
-
 /* --- Compound literals */
 
 struct foo { int x, y; };
@@ -15,85 +11,56 @@ int y;
 struct foo f = (struct foo){ __builtin_constant_p(y), 42 };
 
 struct foo test0(int expr) {
-  // CHECK: define i64 @test0(i32 %expr)
-  // CHECK: call i1 @llvm.is.constant.i32(i32 %expr)
+  // CHECK-LABEL: test0
+  // CHECK: call i1 @llvm.is.constant.i32
   struct foo f = (struct foo){ __builtin_constant_p(expr), 42 };
   return f;
 }
 
 /* --- Pointer types */
 
-inline int test1_i(int *x) {
-  return *x;
-}
-
 int test1() {
-  // CHECK: define i32 @test1
-  // CHECK: add nsw i32 %0, -13
-  // CHECK-NEXT: call i1 @llvm.is.constant.i32(i32 %sub)
-  return bcp(test1_i(&a) - 13);
-}
-
-int test2() {
-  // CHECK: define i32 @test2
+  // CHECK-LABEL: test1
   // CHECK: ret i32 0
   return __builtin_constant_p(&a - 13);
 }
 
-inline int test3_i(int *x) {
-  return 42;
-}
-
-int test3() {
-  // CHECK: define i32 @test3
-  // CHECK: ret i32 1
-  return bcp(test3_i(&a) - 13);
-}
-
 /* --- Aggregate types */
 
 int b[] = {1, 2, 3};
 
-int test4() {
-  // CHECK: define i32 @test4
+int test2() {
+  // CHECK-LABEL: test2
   // CHECK: ret i32 0
   return __builtin_constant_p(b);
 }
 
-const char test5_c[] = {1, 2, 3, 0};
+const char test3_c[] = {1, 2, 3, 0};
 
-int test5() {
-  // CHECK: define i32 @test5
+int test3() {
+  // CHECK-LABEL: test3
   // CHECK: ret i32 0
-  return __builtin_constant_p(test5_c);
+  return __builtin_constant_p(test3_c);
 }
 
-inline char test6_i(const char *x) {
+inline char test4_i(const char *x) {
   return x[1];
 }
 
-int test6() {
-  // CHECK: define i32 @test6
+int test4() {
+  // CHECK: define i32 @test4
   // CHECK: ret i32 0
-  return __builtin_constant_p(test6_i(test5_c));
-}
-
-/* --- Non-constant global variables */
-
-int test7() {
-  // CHECK: define i32 @test7
-  // CHECK: call i1 @llvm.is.constant.i32(i32 %0)
-  return bcp(a);
+  return __builtin_constant_p(test4_i(test3_c));
 }
 
 /* --- Constant global variables */
 
 const int c = 42;
 
-int test8() {
-  // CHECK: define i32 @test8
+int test5() {
+  // CHECK-LABEL: test5
   // CHECK: ret i32 1
-  return bcp(c);
+  return __builtin_constant_p(c);
 }
 
 /* --- Array types */
@@ -101,34 +68,34 @@ int test8() {
 int arr[] = { 1, 2, 3 };
 const int c_arr[] = { 1, 2, 3 };
 
-int test9() {
-  // CHECK: define i32 @test9
-  // CHECK: call i1 @ll

r375468 - Fix -fuse-init-array decision logic on NetBSD

[Joerg Sonnenberger via cfe-commits]

Author: joerg
Date: Mon Oct 21 16:35:33 2019
New Revision: 375468

URL: http://llvm.org/viewvc/llvm-project?rev=375468&view=rev
Log:
Fix -fuse-init-array decision logic on NetBSD

For NetBSD 9 and later, it is the default. On older versions, only ARM
and AArch64 use it by default.

Modified:
cfe/trunk/lib/Driver/ToolChains/NetBSD.cpp
cfe/trunk/test/Driver/netbsd.c

Modified: cfe/trunk/lib/Driver/ToolChains/NetBSD.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/NetBSD.cpp?rev=375468&r1=375467&r2=375468&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains/NetBSD.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/NetBSD.cpp Mon Oct 21 16:35:33 2019
@@ -489,10 +489,23 @@ SanitizerMask NetBSD::getSupportedSaniti
   return Res;
 }
 
-void NetBSD::addClangTargetOptions(const ArgList &,
+void NetBSD::addClangTargetOptions(const ArgList &DriverArgs,
ArgStringList &CC1Args,
Action::OffloadKind) const {
   const SanitizerArgs &SanArgs = getSanitizerArgs();
   if (SanArgs.hasAnySanitizer())
 CC1Args.push_back("-D_REENTRANT");
+
+  unsigned Major, Minor, Micro;
+  getTriple().getOSVersion(Major, Minor, Micro);
+  bool UseInitArrayDefault =
+Major >= 9 || Major == 0 ||
+getTriple().getArch() == llvm::Triple::aarch64 ||
+getTriple().getArch() == llvm::Triple::aarch64_be ||
+getTriple().getArch() == llvm::Triple::arm ||
+getTriple().getArch() == llvm::Triple::armeb;
+
+  if (DriverArgs.hasFlag(options::OPT_fuse_init_array,
+ options::OPT_fno_use_init_array, UseInitArrayDefault))
+CC1Args.push_back("-fuse-init-array");
 }

Modified: cfe/trunk/test/Driver/netbsd.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/netbsd.c?rev=375468&r1=375467&r2=375468&view=diff
==
--- cfe/trunk/test/Driver/netbsd.c (original)
+++ cfe/trunk/test/Driver/netbsd.c Mon Oct 21 16:35:33 2019
@@ -169,12 +169,14 @@
 // PIE: "{{.*}}/usr/lib{{/|}}crtn.o"
 
 // X86_64: clang{{.*}}" "-cc1" "-triple" "x86_64-unknown-netbsd"
+// X86_64: "-fuse-init-array"
 // X86_64: ld{{.*}}" "--eh-frame-hdr" "-dynamic-linker" "/libexec/ld.elf_so"
 // X86_64: "-o" "a.out" "{{.*}}/usr/lib{{/|}}crt0.o" 
"{{.*}}/usr/lib{{/|}}crti.o"
 // X86_64: "{{.*}}/usr/lib{{/|}}crtbegin.o" "{{.*}}.o" "-lc"
 // X86_64: "{{.*}}/usr/lib{{/|}}crtend.o" "{{.*}}/usr/lib{{/|}}crtn.o"
 
 // X86_64-7: clang{{.*}}" "-cc1" "-triple" "x86_64-unknown-netbsd7.0.0"
+// X86_64-7-NOT: "-fuse-init-array"
 // X86_64-7: ld{{.*}}" "--eh-frame-hdr" "-dynamic-linker" "/libexec/ld.elf_so"
 // X86_64-7: "-o" "a.out" "{{.*}}/usr/lib{{/|}}crt0.o" 
"{{.*}}/usr/lib{{/|}}crti.o"
 // X86_64-7:  "{{.*}}/usr/lib{{/|}}crtbegin.o" "{{.*}}.o" "-lc"
@@ -187,30 +189,35 @@
 // X86_64-6: "{{.*}}/usr/lib{{/|}}crtend.o" 
"{{.*}}/usr/lib{{/|}}crtn.o"
 
 // AARCH64: clang{{.*}}" "-cc1" "-triple" "aarch64-unknown-netbsd"
+// AARCH64: "-fuse-init-array"
 // AARCH64: ld{{.*}}" "--eh-frame-hdr" "-dynamic-linker" "/libexec/ld.elf_so"
 // AARCH64: "-o" "a.out" "{{.*}}/usr/lib{{/|}}crt0.o" 
"{{.*}}/usr/lib{{/|}}crti.o"
 // AARCH64: "{{.*}}/usr/lib{{/|}}crtbegin.o" "{{.*}}.o" "-lc"
 // AARCH64: "{{.*}}/usr/lib{{/|}}crtend.o" "{{.*}}/usr/lib{{/|}}crtn.o"
 
 // AARCH64-7: clang{{.*}}" "-cc1" "-triple" "aarch64-unknown-netbsd7.0.0"
+// AARCH64-7: "-fuse-init-array"
 // AARCH64-7: ld{{.*}}" "--eh-frame-hdr" "-dynamic-linker" "/libexec/ld.elf_so"
 // AARCH64-7: "-o" "a.out" "{{.*}}/usr/lib{{/|}}crt0.o" 
"{{.*}}/usr/lib{{/|}}crti.o"
 // AARCH64-7:  "{{.*}}/usr/lib{{/|}}crtbegin.o" "{{.*}}.o" "-lc"
 // AARCH64-7: "{{.*}}/usr/lib{{/|}}crtend.o" 
"{{.*}}/usr/lib{{/|}}crtn.o"
 
 // AARCH64_BE: clang{{.*}}" "-cc1" "-triple" "aarch64_be-unknown-netbsd"
+// AARCH64_BE: "-fuse-init-array"
 // AARCH64_BE: ld{{.*}}" "--eh-frame-hdr" "-dynamic-linker" 
"/libexec/ld.elf_so"
 // AARCH64_BE: "-o" "a.out" "{{.*}}/usr/lib{{/|}}crt0.o" 
"{{.*}}/usr/lib{{/|}}crti.o"
 // AARCH64_BE: "{{.*}}/usr/lib{{/|}}crtbegin.o" "{{.*}}.o" "-lc"
 // AARCH64_BE: "{{.*}}/usr/lib{{/|}}crtend.o" 
"{{.*}}/usr/lib{{/|}}crtn.o"
 
 // AARCH64_BE-7: clang{{.*}}" "-cc1" "-triple" "aarch64_be-unknown-netbsd7.0.0"
+// AARCH64_BE-7: "-fuse-init-array"
 // AARCH64_BE-7: ld{{.*}}" "--eh-frame-hdr" "-dynamic-linker" 
"/libexec/ld.elf_so"
 // AARCH64_BE-7: "-o" "a.out" "{{.*}}/usr/lib{{/|}}crt0.o" 
"{{.*}}/usr/lib{{/|}}crti.o"
 // AARCH64_BE-7:  "{{.*}}/usr/lib{{/|}}crtbegin.o" "{{.*}}.o" "-lc"
 // AARCH64_BE-7: "{{.*}}/usr/lib{{/|}}crtend.o" 
"{{.*}}/usr/lib{{/|}}crtn.o"
 
 // ARM: clang{{.*}}" "-cc1" "-triple" "armv5e-unknown-netbsd-eabi"
+// ARM: "-fuse-init-array"
 // ARM: as{{.*}}" "-mcpu=arm926ej-s" "-o"
 // ARM: ld{{.*}}" "--eh-frame-hdr" "-dyna

Re: [clang] b670ab7 - recommit 1b978ddba05c [CUDA][HIP][OpenMP] Emit deferred diagnostics by a post-parsing AST travese

[Joerg Sonnenberger via cfe-commits]

On Mon, Mar 23, 2020 at 09:09:31AM -0700, Yaxun Liu via cfe-commits wrote:
> 
> Author: Yaxun (Sam) Liu
> Date: 2020-03-23T12:09:07-04:00
> New Revision: b670ab7b6b3d2f26179213be1da1d4ba376f50a3
> 
> URL: 
> https://github.com/llvm/llvm-project/commit/b670ab7b6b3d2f26179213be1da1d4ba376f50a3
> DIFF: 
> https://github.com/llvm/llvm-project/commit/b670ab7b6b3d2f26179213be1da1d4ba376f50a3.diff
> 
> LOG: recommit 1b978ddba05c [CUDA][HIP][OpenMP] Emit deferred diagnostics by a 
> post-parsing AST travese

This change is responsible for a significant performance regression.
Somewhat reduced example is attached. With -fopenmp, it needs ~5s,
without 0.02s.

Joerg
   ;
;
namespace std {
   inline namespace __1 {
  template struct char_traits;
  template  class basic_ostream;
  typedef basic_ostream ostream;
  template basic_ostream<_Traits>& 
operator<<(basic_ostream<_Traits>& __os, const char* __str) ;
  extern ostream cerr;
  }
   ;
   }
template class flet {
   public: flet(T , const T )  ;
   };
;
   template class _scoped_numeral {
   typedef typename Manager::numeral numeral;
   public: _scoped_numeral(Manager ) ;
 operator numeral&() ;


   };
template class 
buffer {
   public: ;
 unsigned size() const ;
 ;
  ;
 T & operator[](unsigned idxT ) ;
 };
template class buffer ;
template class sbuffer : public 
buffer {
   };
class mpz {
public: mpz(int v) ;
   };
  template class mpz_manager {
   public:  ;
 typedef mpz numeral;




  void mul2k(mpz , 
unsigned k, mpz r) ;
  };
typedef mpz_manager unsynch_mpz_manager;
typedef _scoped_numeral scoped_mpz;
class mpq {
};
  template class mpq_manager : public mpz_manager {
public: typedef mpq numeral;
  bool is_zero;
 void mul( mpq b, mpq ) ;



   void set(mpq 
, mpq source) ;



   };
typedef mpq_manager unsynch_mpq_manager;
typedef _scoped_numeral scoped_mpq;
;
template class interval_manager {
   public: ;
   typedef typename C::interval interval;

   bool is_P(interval n) const ;
  void set(interval , interval s);
  void neg(interval 
a, interval );
 void add(interval a, interval b, interval );
   void 
mul(interval a, interval b, interval );

 };
template class _scoped_interval {
   typedef typename Manager::interval interval;
   public: _scoped_interval(Manager ) ;
 operator interval&() ;
   };
namespace realclosure {
   class num;
   ;
   class manager {
  struct imp;
  typedef num numeral;






};
   struct value;
   class num {
  friend class manager

Re: [clang] 246398e - [clang][Parse] properly parse asm-qualifiers, asm inline

[Joerg Sonnenberger via cfe-commits]

On Thu, Mar 12, 2020 at 03:25:49PM -0700, Nick Desaulniers via cfe-commits 
wrote:
> 
> Author: Nick Desaulniers
> Date: 2020-03-12T15:13:59-07:00
> New Revision: 246398ece7115b57a02dbe7876d86ae8e72406ef
> 
> URL: 
> https://github.com/llvm/llvm-project/commit/246398ece7115b57a02dbe7876d86ae8e72406ef
> DIFF: 
> https://github.com/llvm/llvm-project/commit/246398ece7115b57a02dbe7876d86ae8e72406ef.diff
> 
> LOG: [clang][Parse] properly parse asm-qualifiers, asm inline
> 
> Summary:
> The parsing of GNU C extended asm statements was a little brittle and
> had a few issues:

I find it very questionable that this change drops a warning flag making
IMO benign code differences like marking a global asm as volatile an
unconditional error. This strongly seems to be something that we
shouldn't blindly follow GCC on.

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

[clang] 9d2d6e7 - Emit Objective-C constructors as writable

[Joerg Sonnenberger via cfe-commits]

Author: Joerg Sonnenberger
Date: 2020-04-14T22:32:34+02:00
New Revision: 9d2d6e71f096ad43b178c576adf94fc922034c73

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

LOG: Emit Objective-C constructors as writable

They end up as .init_array sections and those need to be writable,
otherwise bad merging will happen.

Added: 


Modified: 
clang/lib/CodeGen/CGObjCGNU.cpp
clang/test/CodeGenObjC/gnu-init.m

Removed: 




diff  --git a/clang/lib/CodeGen/CGObjCGNU.cpp b/clang/lib/CodeGen/CGObjCGNU.cpp
index 35b926808492..3dbb3be5a5e0 100644
--- a/clang/lib/CodeGen/CGObjCGNU.cpp
+++ b/clang/lib/CodeGen/CGObjCGNU.cpp
@@ -1564,7 +1564,7 @@ class CGObjCGNUstep2 : public CGObjCGNUstep {
 // We have to do this by hand, rather than with @llvm.ctors, so that the
 // linker can remove the duplicate invocations.
 auto *InitVar = new llvm::GlobalVariable(TheModule, 
LoadFunction->getType(),
-/*isConstant*/true, llvm::GlobalValue::LinkOnceAnyLinkage,
+/*isConstant*/false, llvm::GlobalValue::LinkOnceAnyLinkage,
 LoadFunction, ".objc_ctor");
 // Check that this hasn't been renamed.  This shouldn't happen, because
 // this function should be called precisely once.

diff  --git a/clang/test/CodeGenObjC/gnu-init.m 
b/clang/test/CodeGenObjC/gnu-init.m
index 076e08112d81..6be999b6d64a 100644
--- a/clang/test/CodeGenObjC/gnu-init.m
+++ b/clang/test/CodeGenObjC/gnu-init.m
@@ -39,8 +39,8 @@ @implementation X @end
 // CHECK-NEW: @.objc_init = linkonce_odr hidden global { i64, i8**, i8**, 
i8**, i8**, i8**, i8**, i8**, i8**, i8**, i8**, i8**, i8**, i8**, i8**, i8**, 
i8** } { i64 0, i8** @__start___objc_selectors, i8** @__stop___objc_selectors, 
i8** @__start___objc_classes, i8** @__stop___objc_classes, i8** 
@__start___objc_class_refs, i8** @__stop___objc_class_refs, i8** 
@__start___objc_cats, i8** @__stop___objc_cats, i8** @__start___objc_protocols, 
i8** @__stop___objc_protocols, i8** @__start___objc_protocol_refs, i8** 
@__stop___objc_protocol_refs, i8** @__start___objc_class_aliases, i8** 
@__stop___objc_class_aliases, i8** @__start___objc_constant_string, i8** 
@__stop___objc_constant_string }, comdat, align 8
 
 // Check that the load function is manually inserted into .ctors.
-// CHECK-NEW: @.objc_ctor = linkonce hidden constant void ()* 
@.objcv2_load_function, section ".ctors", comdat
-// CHECK-INIT_ARRAY: @.objc_ctor = linkonce hidden constant void ()* 
@.objcv2_load_function, section ".init_array", comdat
+// CHECK-NEW: @.objc_ctor = linkonce hidden global void ()* 
@.objcv2_load_function, section ".ctors", comdat
+// CHECK-INIT_ARRAY: @.objc_ctor = linkonce hidden global void ()* 
@.objcv2_load_function, section ".init_array", comdat
 
 
 // Make sure that we provide null versions of everything so the __start /
@@ -91,7 +91,7 @@ @implementation X @end
 // CHECK-WIN-DAG: @.objc_init = linkonce_odr hidden global { i64, 
%.objc_section_sentinel*, %.objc_section_sentinel*, %.objc_section_sentinel*, 
%.objc_section_sentinel*, %.objc_section_sentinel*, %.objc_section_sentinel*, 
%.objc_section_sentinel*, %.objc_section_sentinel*, %.objc_section_sentinel*, 
%.objc_section_sentinel*, %.objc_section_sentinel*, %.objc_section_sentinel*, 
%.objc_section_sentinel*, %.objc_section_sentinel*, %.objc_section_sentinel*, 
%.objc_section_sentinel* } { i64 0, %.objc_section_sentinel* 
@"__start_.objcrt$SEL", %.objc_section_sentinel* @"__stop.objcrt$SEL", 
%.objc_section_sentinel* @"__start_.objcrt$CLS", %.objc_section_sentinel* 
@"__stop.objcrt$CLS", %.objc_section_sentinel* @"__start_.objcrt$CLR", 
%.objc_section_sentinel* @"__stop.objcrt$CLR", %.objc_section_sentinel* 
@"__start_.objcrt$CAT", %.objc_section_sentinel* @"__stop.objcrt$CAT", 
%.objc_section_sentinel* @"__start_.objcrt$PCL", %.objc_section_sentinel* 
@"__stop.objcrt$PCL", %.objc_section_sentinel* @"__start_.objcrt$PCR", 
%.objc_section_sentinel* @"__stop.objcrt$PCR", %.objc_section_sentinel* 
@"__start_.objcrt$CAL", %.objc_section_sentinel* @"__stop.objcrt$CAL", 
%.objc_section_sentinel* @"__start_.objcrt$STR", %.objc_section_sentinel* 
@"__stop.objcrt$STR" }, comdat, align 8
 
 // Make sure our init variable is in the correct section for late library init.
-// CHECK-WIN: @.objc_ctor = linkonce hidden constant void ()* 
@.objcv2_load_function, section ".CRT$XCLz", comdat
+// CHECK-WIN: @.objc_ctor = linkonce hidden global void ()* 
@.objcv2_load_function, section ".CRT$XCLz", comdat
 
 // We shouldn't have emitted any null placeholders on Windows.
 // CHECK-WIN: @llvm.used = appending global [2 x i8*] [i8* bitcast ({ { i8*, 
i8*, i8*, i32, i32, i32, i8*, i8*, i8*, i8*, i8*, i8*, i8*, i8*, i8*, i32, i8* 
}*, i8*, i8*, i32, i32, i32, i8*, i8*, i8*, i8*, i8*, i8*, i8*, i8*, i8*, i32, 
i8* }** @"$_OBJC_INIT_

Re: r281277 - [Sema] Fix PR30346: relax __builtin_object_size checks.

[Joerg Sonnenberger via cfe-commits]

On Mon, Sep 19, 2016 at 09:21:33PM -0700, George Burgess IV wrote:
> I'm entirely unfamiliar with struct-path-tbaa, so Hal, do you see a reason
> why struct-path-tbaa wouldn't play nicely with flexible arrays at the end
> of types? Glancing at it, I don't think it should cause problems, but a
> more authoritative answer would really be appreciated. :) If it might cause
> issues now or in the future, I'm happy to be conservative here if
> -fno-strict-path-tbaa is given, too.

Please don't call them flexible types. That's a misname. The standard
provides a clear mechanism for arrays with statically undefined size --
which is providing no size at all. We do provide the same support for
array size of 1 for legacy compat. Any other size is basically abuse.

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

Re: [libcxx] r282483 - [cmake] Add linker option "-Wl, -z, defs" in standalone build

[Joerg Sonnenberger via cfe-commits]

On Tue, Sep 27, 2016 at 12:15:35PM -, Michal Gorny via cfe-commits wrote:
> Author: mgorny
> Date: Tue Sep 27 07:15:35 2016
> New Revision: 282483
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=282483&view=rev
> Log:
> [cmake] Add linker option "-Wl,-z,defs" in standalone build
> 
> Add the "-Wl,-z,defs" linker option that is used to prevent
> underlinking. It is already used by LLVM itself but does not get
> propagated into stand-alone build of libc++. This patch ensures
> that the option is passed in independently of whether libc++ is built
> in-tree or out-of-tree.

Can we turn this into a positive list on platforms where it is known to
work? While I generally find it useful, linker and (GCC) spec stupidity
can easily break it.

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

Re: [PATCH] D24861: [Sema] extend Wshift-op-parentheses so it warns for multiplicative operators

[Joerg Sonnenberger via cfe-commits]

joerg added a subscriber: joerg.
joerg added a comment.

I think the comment from Daniel shows the crux of the issue. A left shift is by 
nature a multiplication operation, so I don't see why it should get the 
warning. A right shift works like a division and order is quite significant for 
that.


Repository:
  rL LLVM

https://reviews.llvm.org/D24861



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

Re: [PATCH] D24861: [Sema] extend Wshift-op-parentheses so it warns for multiplicative operators

[Joerg Sonnenberger via cfe-commits]

On Fri, Sep 30, 2016 at 03:41:53PM -0700, Richard Trieu via cfe-commits wrote:
> Currently, this warning is on by default.  As you said, the results you
> found look intentional in many cases, so there is a high false positive
> rate.  For on by default warnings, we expect a high true positive rate and
> intend for users to not disable the warning.  From my analysis on a
> separate codebase, I found less than 10% true positive rate out of 200
> warnings.  One option might be to move this warning to a subgroup, which
> would leave it discoverable from either -Wall or -Wparentheses, but not
> have it on by default.

We are now only talking about the right shift version, are we? That
seems to me to be much less intrusive, but should belong into the same
subgroup as the add checks.

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

Re: r278483 - This patch implements PR#22821.

[Joerg Sonnenberger via cfe-commits]

On Fri, Aug 12, 2016 at 08:04:13AM -, Roger Ferrer Ibanez via cfe-commits 
wrote:
> Author: rogfer01
> Date: Fri Aug 12 03:04:13 2016
> New Revision: 278483
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=278483&view=rev
> Log:
> This patch implements PR#22821.
> 
> Taking the address of a packed member is dangerous since the reduced
> alignment of the pointee is lost. This can lead to memory alignment
> faults in some architectures if the pointer value is dereferenced.

This triggers on LVM in a rather obvious false positive:

(uintptr_t) &lh->offset_xl

Given that one correct use case is to take the address and cast it to
void * (or uintptr_t) for use without caring about alignment, the
warning clearly needs to be refined.

I'm also missing a test case in this commit. Most importantly, it should
test, whether it correctly handles the case of packed+align where
align > alignof(field).

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

Re: r278483 - This patch implements PR#22821.

[Joerg Sonnenberger via cfe-commits]

On Sat, Oct 01, 2016 at 11:28:39PM +0200, Joerg Sonnenberger via cfe-commits 
wrote:
> On Fri, Aug 12, 2016 at 08:04:13AM -, Roger Ferrer Ibanez via cfe-commits 
> wrote:
> > Author: rogfer01
> > Date: Fri Aug 12 03:04:13 2016
> > New Revision: 278483
> > 
> > URL: http://llvm.org/viewvc/llvm-project?rev=278483&view=rev
> > Log:
> > This patch implements PR#22821.
> > 
> > Taking the address of a packed member is dangerous since the reduced
> > alignment of the pointee is lost. This can lead to memory alignment
> > faults in some architectures if the pointer value is dereferenced.
> 
> This triggers on LVM in a rather obvious false positive:
> 
> (uintptr_t) &lh->offset_xl
> 
> Given that one correct use case is to take the address and cast it to
> void * (or uintptr_t) for use without caring about alignment, the
> warning clearly needs to be refined.

Looking more at it, I request this warning to be disabled by default. In
the current form it is useless and just makes it impossible to use
packed structures at all. Before reenabling, it should handling:
(1) Assignment to pointer with reduced alignment
(2) Casts to pointer with reduced alignment
(3) Use as function argument with implicit cast like (2).

at the very least to cover normal use of packed member pointers.

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

[PATCH] D25161: [cmake] Install 'clang-cpp' symlink

[Joerg Sonnenberger via cfe-commits]

joerg accepted this revision.
joerg added a reviewer: joerg.
joerg added a comment.
This revision is now accepted and ready to land.

LGTM, have been doing that in NetBSD for ages as well.

Side note, someone from Apple please make sure that xcode gets a similar link.


https://reviews.llvm.org/D25161



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

Re: r278483 - This patch implements PR#22821.

[Joerg Sonnenberger via cfe-commits]

On Mon, Oct 03, 2016 at 07:10:08AM +, Roger Ferrer Ibanez wrote:
> Hi Joerg,
> 
> thanks for your comments. I agree that these false positives are annoying.
> 
> I submitted a while ago a patch to address those false positives in
> https://reviews.llvm.org/D23657 but it is pending approval.

I'm trying this patch now. Two instances here show false positives. Some
others are misuse/overuse of __packed, it is time consuming to check all
of them.

--- sbin/route

https://nxr.netbsd.org/xref/src/sbin/route/route.c#1009
triggers the warning:
union mpls_shim *ms = &su->smpls.smpls_addr;
where su is defined as:
union sockunion {
...
struct  sockaddr_mpls smpls;
};

and sockaddr_mpls in turn is
https://nxr.netbsd.org/xref/src/sys/netmpls/mpls.h#66 

struct sockaddr_mpls {
uint8_t smpls_len;
uint8_t smpls_family;
uint8_t smpls_pad[2];
union mpls_shim smpls_addr;
} __packed;

smpls_addr is a union of a uint32_t and matching bit field. The
alignment of sockunion and the explicit padding ensures that all fields
can be accessed correctly.

--- sbin/ifconfig

Member access is
https://nxr.netbsd.org/xref/src/sbin/ifconfig/ieee80211.c#969
The macro is defined at
https://nxr.netbsd.org/xref/src/sbin/ifconfig/ieee80211.c#928

Most importantly, this effective casts immediately to (unsigned) char
and therefore doesn't care about any misalignment.

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

[PATCH] D23657: Remove some false positives when taking the address of packed members

[Joerg Sonnenberger via cfe-commits]

joerg added a comment.

The following is from my comment on the original commit.

I'm trying this patch now. Two instances here show false positives. Some
others are misuse/overuse of __packed, it is time consuming to check all
of them.

- sbin/route

https://nxr.netbsd.org/xref/src/sbin/route/route.c#1009 triggers the warning:

  union mpls_shim *ms = &su->smpls.smpls_addr;

where su is defined as:

  union sockunion {
  ...
  struct  sockaddr_mpls smpls;
  };

and sockaddr_mpls in turn is 
https://nxr.netbsd.org/xref/src/sys/netmpls/mpls.h#66

  struct sockaddr_mpls {
  uint8_t smpls_len;
  uint8_t smpls_family;
  uint8_t smpls_pad[2];
  union mpls_shim smpls_addr;
  } __packed;

smpls_addr is a union of a uint32_t and matching bit field. The alignment of 
sockunion and the explicit padding ensures that all fields can be accessed 
correctly.

- sbin/ifconfig

Member access is https://nxr.netbsd.org/xref/src/sbin/ifconfig/ieee80211.c#969
The macro is defined at 
https://nxr.netbsd.org/xref/src/sbin/ifconfig/ieee80211.c#928

Most importantly, this effective casts immediately to (unsigned) char and 
therefore doesn't care about any misalignment.


https://reviews.llvm.org/D23657



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

[PATCH] D23657: Remove some false positives when taking the address of packed members

[Joerg Sonnenberger via cfe-commits]

joerg added a comment.

Seems to work for the false positives I have identified so far.


https://reviews.llvm.org/D23657



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

[PATCH] D25402: [Driver] Pass -lunwind when using libc++ + compiler-rt

[Joerg Sonnenberger via cfe-commits]

joerg added a comment.

So, what's the test change that matches the difference in output this creates?


https://reviews.llvm.org/D25402



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

[PATCH] D25402: [Driver] Pass -lunwind when using libc++ + compiler-rt

[Joerg Sonnenberger via cfe-commits]

joerg added a comment.

No, they are not desirable, in fact, they pretty much break clang. That's why I 
wanted to see the test diff...


https://reviews.llvm.org/D25402



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

[PATCH] D25402: [Driver] Pass -lunwind when using libc++ + compiler-rt

[Joerg Sonnenberger via cfe-commits]

joerg added a comment.

I don't agree with the motivation for this change, BTW. Whether -lunwind is 
needed or not is an implementation detail of the way the ABI implementation is 
linked. That's why libc++ is now a linker script, to hide this kinds of 
implementation details.


https://reviews.llvm.org/D25402



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

[PATCH] D25402: [Driver] Pass -lunwind when using libc++ + compiler-rt on Linux

[Joerg Sonnenberger via cfe-commits]

joerg added a comment.

It's difficult to say whether if one change to certain driver functions affect 
some target or not. That's one reason why the test change is so important.

Looking at the latest version, I still don't understand why the change for 
Linux is needed. libc++ should provide a linker script now and that should 
include -lunwind as appropriate.


https://reviews.llvm.org/D25402



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

[PATCH] D23657: Remove some false positives when taking the address of packed members

[Joerg Sonnenberger via cfe-commits]

joerg added a comment.

A simple case that still seems to fail:

  #include 
  
  struct foo {
uint32_t x;
uint8_t y[2];
uint16_t z;
  } __attribute__((__packed__));
  
  typedef struct foo __attribute__((__aligned__(16))) aligned_foo;
  
  int main(void) {
struct foo x;
struct foo __attribute__((__aligned__(4))) y;
aligned_foo z;
  
uint32_t *p32;
p32 = &x.x;
p32 = &y.x;
p32 = &z.x;
  }

Only the first assignment to p32 should warn, the others are all correctly 
aligned.


https://reviews.llvm.org/D23657



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

[PATCH] D23657: Remove some false positives when taking the address of packed members

[Joerg Sonnenberger via cfe-commits]

joerg added inline comments.



Comment at: lib/Sema/SemaChecking.cpp:11370
+// we are here such increase has not been enough. So pointing the first
+// FieldDecl that either is packed orelse its RecordDecl is,
+// seems reasonable.

Missing space.


https://reviews.llvm.org/D23657



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

Re: [libunwind] r284125 - [libunwind] Add missing include. NFC.

[Joerg Sonnenberger via cfe-commits]

On Thu, Oct 13, 2016 at 02:32:24PM -, Asiri Rathnayake via cfe-commits 
wrote:
> This missing include seems to cause compilation failures on older MacOS
> versions (< 10.9). This is because r270692 has introduced uint64_t into
> config.h without including this header.

But that would be inttypes.h, wouldn't it be?

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

[PATCH] D23657: Remove some false positives when taking the address of packed members

[Joerg Sonnenberger via cfe-commits]

joerg added a comment.

It seems like on-stack arrays still don't work?

  #include 
  
  struct test {
uint32_t x;
  } __attribute__((__packed__));
  
  int main(void) {
struct test __attribute__((__aligned__(4))) a[4];
uint32_t *p32;
p32 = &a[0].x;
  }


https://reviews.llvm.org/D23657



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

Re: [clang] c149ff3 - [Driver] Link Flang runtime on FreeBSD, NetBSD, OpenBSD, DragonFly and Haiku (#69817)

[Joerg Sonnenberger via cfe-commits]

On Friday, October 27, 2023 10:43:23 AM CEST via cfe-commits wrote:
> Author: Brad Smith
> Date: 2023-10-27T04:43:19-04:00
> New Revision: c149ff3d372a70e7d9de838a1ff0357394b8d017
> 
> URL:
> https://github.com/llvm/llvm-project/commit/c149ff3d372a70e7d9de838a1ff0357
> 394b8d017 DIFF:
> https://github.com/llvm/llvm-project/commit/c149ff3d372a70e7d9de838a1ff0357
> 394b8d017.diff
> 
> LOG: [Driver] Link Flang runtime on FreeBSD, NetBSD, OpenBSD, DragonFly and
> Haiku (#69817)
> 
> Added:
> 
> 
> Modified:
> clang/lib/Driver/ToolChains/DragonFly.cpp
> clang/lib/Driver/ToolChains/FreeBSD.cpp
> clang/lib/Driver/ToolChains/Haiku.cpp
> clang/lib/Driver/ToolChains/NetBSD.cpp
> clang/lib/Driver/ToolChains/OpenBSD.cpp
> flang/test/Driver/linker-flags.f90
> 
> Removed:
> 
> 
> 
> 
>  diff  --git a/clang/lib/Driver/ToolChains/DragonFly.cpp
> b/clang/lib/Driver/ToolChains/DragonFly.cpp index
> 9dc8d9d4363bd71..500dd98665075b1 100644
> --- a/clang/lib/Driver/ToolChains/DragonFly.cpp
> +++ b/clang/lib/Driver/ToolChains/DragonFly.cpp
> @@ -144,6 +144,16 @@ void dragonfly::Linker::ConstructJob(Compilation &C,
> const JobAction &JA, CmdArgs.push_back("-lm");
>  }
> 
> +// Additional linker set-up and flags for Fortran. This is required in
> order +// to generate executables. As Fortran runtime depends on the C
> runtime, +// these dependencies need to be listed before the C runtime
> below (i.e. +// AddRuntTimeLibs).
> +if (D.IsFlangMode()) {
> +  addFortranRuntimeLibraryPath(ToolChain, Args, CmdArgs);
> +  addFortranRuntimeLibs(ToolChain, CmdArgs);
> +  CmdArgs.push_back("-lm");
> +}
> +
>  if (Args.hasArg(options::OPT_pthread))
>CmdArgs.push_back("-lpthread");
> 
> 

Shouldn't that be "AddRunTimeLibs" without the extra t?

Joerg


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

Re: [PATCH] D66361: Improve behavior in the case of stack exhaustion.

[Joerg Sonnenberger via cfe-commits]

On Tue, Sep 03, 2019 at 06:02:28PM +, Richard Smith - zygoloid via 
Phabricator via cfe-commits wrote:
> rsmith added a comment.
> 
> In D66361#1655903 , @krytarowski 
> wrote:
> 
> > This change broke on NetBSD.
> >
> > http://lab.llvm.org:8011/builders/netbsd-amd64/builds/22003/steps/run%20unit%20tests/logs/FAIL%3A%20Clang%3A%3Astack-exhaustion.cpp
> 
> 
> Test disabled for NetBSD in r370801. If you're interested in investigating 
> why this isn't working there, feel free, but this is only a best-effort 
> mitigation for the case where things have already gone wrong, so there are 
> limits to how much effort it makes sense to resolve this.
> 
> Does NetBSD set a hard stack rlimit of less than 8MB by any chance?

4MB soft limit by default, hard limit depends on the architecture, e.g.
128MB on amd64.

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

Re: [PATCH] D67200: Add -static-openmp driver option

[Joerg Sonnenberger via cfe-commits]

On Wed, Sep 04, 2019 at 11:28:34PM +, Pirama Arumuga Nainar via Phabricator 
via cfe-commits wrote:
> pirama created this revision.
> pirama added reviewers: Hahnfeld, danalbert, srhines, joerg.
> Herald added a subscriber: guansong.
> Herald added a reviewer: jdoerfert.
> Herald added a project: clang.
> 
> This option forces linking with the static OpenMP host runtime (similar
> to -static-libgcc and -static-libstdcxx).
> 
> Android's NDK will start the shared OpenMP runtime in addition to the static
> libomp.  In this scenario, the linker will prefer to use the shared library by
> default.  Add this option to enable linking with the static libomp.

Needs testing for the -static interaction?

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

Re: r371437 - [Driver] Add -static-openmp driver option

[Joerg Sonnenberger via cfe-commits]

On Mon, Sep 09, 2019 at 06:31:41PM -, Pirama Arumuga Nainar via cfe-commits 
wrote:
> Author: pirama
> Date: Mon Sep  9 11:31:41 2019
> New Revision: 371437
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=371437&view=rev
> Log:
> [Driver] Add -static-openmp driver option

This still needs testing for the interaction with -static.

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

Re: r309940 - [mips] Implement -muninit-const-in-rodata

[Joerg Sonnenberger via cfe-commits]

On Thu, Aug 03, 2017 at 02:01:17PM -, Simon Dardis via cfe-commits wrote:
> Author: sdardis
> Date: Thu Aug  3 07:01:17 2017
> New Revision: 309940
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=309940&view=rev
> Log:
> [mips] Implement -muninit-const-in-rodata
> 
> This option when combined with -mgpopt and -membedded-data places all
> uninitialized constant variables in the read-only section.

I don't get it. Why is this preferable to just forbidding the use of
common variables in first placce?

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

[libcxx] r311156 - Spelling

[Joerg Sonnenberger via cfe-commits]

Author: joerg
Date: Fri Aug 18 05:57:36 2017
New Revision: 311156

URL: http://llvm.org/viewvc/llvm-project?rev=311156&view=rev
Log:
Spelling

Modified:
libcxx/trunk/include/__tree

Modified: libcxx/trunk/include/__tree
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__tree?rev=311156&r1=311155&r2=311156&view=diff
==
--- libcxx/trunk/include/__tree (original)
+++ libcxx/trunk/include/__tree Fri Aug 18 05:57:36 2017
@@ -84,7 +84,7 @@ __tree_is_left_child(_NodePtr __x) _NOEX
 return __x == __x->__parent_->__left_;
 }
 
-// Determintes if the subtree rooted at __x is a proper red black subtree.  If
+// Determines if the subtree rooted at __x is a proper red black subtree.  If
 //__x is a proper subtree, returns the black height (null counts as 1).  If
 //__x is an improper subtree, returns 0.
 template 
@@ -119,7 +119,7 @@ __tree_sub_invariant(_NodePtr __x)
 return __h + __x->__is_black_;  // return black height of this node
 }
 
-// Determintes if the red black tree rooted at __root is a proper red black 
tree.
+// Determines if the red black tree rooted at __root is a proper red black 
tree.
 //__root == nullptr is a proper tree.  Returns true is __root is a proper
 //red black tree, else returns false.
 template 


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

[clang] 2628e91 - [NetBSD] Use cortex-a8 as default CPU for ARMv7

[Joerg Sonnenberger via cfe-commits]

Author: Joerg Sonnenberger
Date: 2021-02-18T01:53:04+01:00
New Revision: 2628e9146120507b2cf025f5c4ccc857cc3724c4

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

LOG: [NetBSD] Use cortex-a8 as default CPU for ARMv7

This matches the platform default for GCC. It primarily matters when the
integrated assembler is not used as there is no default CPU defined for
ARMv7-A and GNU as is upset with -mcpu=generic.

Added: 


Modified: 
clang/test/Driver/netbsd.c
llvm/lib/Support/Triple.cpp

Removed: 




diff  --git a/clang/test/Driver/netbsd.c b/clang/test/Driver/netbsd.c
index 83486c73d281..812889309a0f 100644
--- a/clang/test/Driver/netbsd.c
+++ b/clang/test/Driver/netbsd.c
@@ -236,6 +236,7 @@
 // ARMEB: "{{.*}}/usr/lib{{/|}}eabi{{/|}}crti.o"
 // ARMEB: "{{.*}}/usr/lib{{/|}}crtbegin.o" "{{.*}}.o" "-lc"
 // ARMEB: "{{.*}}/usr/lib{{/|}}crtend.o" "{{.*}}/usr/lib{{/|}}crtn.o"
+// ARMV7EB: as{{.*}}" "-mcpu=cortex-a8"
 // ARMV7EB: ld{{.*}}" "--eh-frame-hdr" "-dynamic-linker" "/libexec/ld.elf_so"
 // ARMV7EB: "--be8" "-m" "armelfb_nbsd_eabi"
 

diff  --git a/llvm/lib/Support/Triple.cpp b/llvm/lib/Support/Triple.cpp
index 40c4f3db8b53..2ec123fcca73 100644
--- a/llvm/lib/Support/Triple.cpp
+++ b/llvm/lib/Support/Triple.cpp
@@ -1699,6 +1699,8 @@ StringRef Triple::getARMCPUForArch(StringRef MArch) const 
{
   case llvm::Triple::NetBSD:
 if (!MArch.empty() && MArch == "v6")
   return "arm1176jzf-s";
+if (!MArch.empty() && MArch == "v7")
+  return "cortex-a8";
 break;
   case llvm::Triple::Win32:
 // FIXME: this is invalid for WindowsCE



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

Re: [clang] e6629be - [AIX] Define __STDC_NO_ATOMICS__ and __STDC_NO_THREADS__ predefined macros

[Joerg Sonnenberger via cfe-commits]

On Mon, Jun 07, 2021 at 07:04:36PM -0700, via cfe-commits wrote:
> 
> Author: =Jake Egan
> Date: 2021-06-07T22:04:18-04:00
> New Revision: e6629be31e67190f0a524f009752d73410894560
> 
> URL: 
> https://github.com/llvm/llvm-project/commit/e6629be31e67190f0a524f009752d73410894560
> DIFF: 
> https://github.com/llvm/llvm-project/commit/e6629be31e67190f0a524f009752d73410894560.diff
> 
> LOG: [AIX] Define __STDC_NO_ATOMICS__ and __STDC_NO_THREADS__ predefined 
> macros

I find the justification for this a bit strange. Neither one has to be
implemented in libc. compiler-rt implements the former with the mixing
caveats applied and there are portable implementations of the latter
based on pthread. I would expect them to work well enough on AIX, too.
So this seems to do more harm than good?

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

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Joerg Sonnenberger via cfe-commits]

Am Thu, Nov 17, 2022 at 10:58:52AM -0800 schrieb Paul Eggert via cfe-commits:
> On 2022-11-16 10:59, Zack Weinberg wrote:
> > I'm generally in agreement with Rich Felker's argument 
> > (inhttps://ewontfix.com/13/) that AC_CHECK_FUNC*should not*  just probe for 
> > linkability of a symbol
> 
> So am I. I'm not saying Autoconf should never change here, only that the
> change would not be trivial. It would require changing many configure.ac
> scripts scattered over many software projects, because Autoconf cannot be
> expected to know every signature of every function in every library.

For all practical purpose, it can't change as there is enough legacy
software out in the wild that will never be updated accordingly.

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

[libunwind] [libunwind] Pass -Wl,--export-dynamic on all supported platforms (PR #67205)

[Joerg Sonnenberger via cfe-commits]

jsonn wrote:

Is this really desirable? It can actually break applications as it changes ELF 
semantics.

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

[libunwind] [libunwind] Pass -Wl,--export-dynamic on all supported platforms (PR #67205)

[Joerg Sonnenberger via cfe-commits]

jsonn wrote:

Can you as a small follow-up just update the comment to include that part? E.g.
```
# On ELF platforms, link tests with -Wl,--export-dynamic if supported by the 
linker.
```

Side note: the much older way for doing this is actually `-rdynamic`.

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

[clang] 09d4021 - Fix compatibility for __builtin_stdarg_start

[Joerg Sonnenberger via cfe-commits]

Author: Joerg Sonnenberger
Date: 2020-03-28T23:24:13+01:00
New Revision: 09d402185394fdbf1f60233a7f42a4a1108c2cd3

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

LOG: Fix compatibility for __builtin_stdarg_start

The __builtin_stdarg_start is the legacy spelling of __builtin_va_start.
It should behave exactly the same, but for the last 9 years it would
behave subtly different for diagnostics. Follow the change from
29ad95b23217 to require custom type checking.

Added: 


Modified: 
clang/include/clang/Basic/Builtins.def
clang/test/SemaCXX/vararg-non-pod.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/Builtins.def 
b/clang/include/clang/Basic/Builtins.def
index 85f775a7cad8..9613f312d52d 100644
--- a/clang/include/clang/Basic/Builtins.def
+++ b/clang/include/clang/Basic/Builtins.def
@@ -472,7 +472,7 @@ BUILTIN(__builtin___NSStringMakeConstantString, "FC*cC*", 
"nc")
 BUILTIN(__builtin_va_start, "vA.", "nt")
 BUILTIN(__builtin_va_end, "vA", "n")
 BUILTIN(__builtin_va_copy, "vAA", "n")
-BUILTIN(__builtin_stdarg_start, "vA.", "n")
+BUILTIN(__builtin_stdarg_start, "vA.", "nt")
 BUILTIN(__builtin_assume_aligned, "v*vC*z.", "nc")
 BUILTIN(__builtin_bcmp, "ivC*vC*z", "Fn")
 BUILTIN(__builtin_bcopy, "vv*v*z", "n")

diff  --git a/clang/test/SemaCXX/vararg-non-pod.cpp 
b/clang/test/SemaCXX/vararg-non-pod.cpp
index 1b7f3b68dc97..a1bbe748d12d 100644
--- a/clang/test/SemaCXX/vararg-non-pod.cpp
+++ b/clang/test/SemaCXX/vararg-non-pod.cpp
@@ -164,6 +164,13 @@ void t6(Foo somearg, ... ) {
   __builtin_va_start(list, somearg);
 }
 
+// __builtin_stdarg_start is a compatibility alias for __builtin_va_start,
+// it should behave the same
+void t6b(Foo somearg, ... ) {
+  __builtin_va_list list;
+  __builtin_stdarg_start(list, somearg); // second argument to 'va_start' is 
not the last named parameter [-Wvarargs]
+}
+
 void t7(int n, ...) {
   __builtin_va_list list;
   __builtin_va_start(list, n);



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

[clang] eb812ef - Explicitly include when using assert

[Joerg Sonnenberger via cfe-commits]

Author: Joerg Sonnenberger
Date: 2020-03-02T22:45:28+01:00
New Revision: eb812efa12fb82ca338794fa18b610ca9581aef5

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

LOG: Explicitly include  when using assert

Depending on the OS used, a module-enabled build can fail due to the
special handling  gets as textual header.

Added: 


Modified: 
clang/lib/AST/CommentCommandTraits.cpp
llvm/lib/Support/APSInt.cpp
llvm/lib/Support/FormatVariadic.cpp
llvm/lib/Support/IntEqClasses.cpp
llvm/lib/Support/IntervalMap.cpp
llvm/lib/Support/KnownBits.cpp
llvm/lib/Support/PrettyStackTrace.cpp
llvm/lib/Support/Regex.cpp
llvm/lib/Support/StringPool.cpp
llvm/lib/Support/Triple.cpp
llvm/lib/Support/VersionTuple.cpp
llvm/lib/TableGen/TableGenBackend.cpp
llvm/lib/Target/AArch64/AArch64StackOffset.h
llvm/lib/Target/PowerPC/MCTargetDesc/PPCMCAsmInfo.cpp
llvm/utils/TableGen/CodeGenHwModes.h
llvm/utils/TableGen/CodeGenInstruction.h

Removed: 




diff  --git a/clang/lib/AST/CommentCommandTraits.cpp 
b/clang/lib/AST/CommentCommandTraits.cpp
index b306fcbb154f..bdc0dd47fb7d 100644
--- a/clang/lib/AST/CommentCommandTraits.cpp
+++ b/clang/lib/AST/CommentCommandTraits.cpp
@@ -8,6 +8,7 @@
 
 #include "clang/AST/CommentCommandTraits.h"
 #include "llvm/ADT/STLExtras.h"
+#include 
 
 namespace clang {
 namespace comments {

diff  --git a/llvm/lib/Support/APSInt.cpp b/llvm/lib/Support/APSInt.cpp
index 7c48880f96ea..6805e06df333 100644
--- a/llvm/lib/Support/APSInt.cpp
+++ b/llvm/lib/Support/APSInt.cpp
@@ -14,6 +14,7 @@
 #include "llvm/ADT/APSInt.h"
 #include "llvm/ADT/FoldingSet.h"
 #include "llvm/ADT/StringRef.h"
+#include 
 
 using namespace llvm;
 

diff  --git a/llvm/lib/Support/FormatVariadic.cpp 
b/llvm/lib/Support/FormatVariadic.cpp
index f9e89f69b528..0d61fae22323 100644
--- a/llvm/lib/Support/FormatVariadic.cpp
+++ b/llvm/lib/Support/FormatVariadic.cpp
@@ -6,6 +6,7 @@
 
//===--===//
 
 #include "llvm/Support/FormatVariadic.h"
+#include 
 
 using namespace llvm;
 

diff  --git a/llvm/lib/Support/IntEqClasses.cpp 
b/llvm/lib/Support/IntEqClasses.cpp
index 4a976dcefc65..ebb02e6c01e5 100644
--- a/llvm/lib/Support/IntEqClasses.cpp
+++ b/llvm/lib/Support/IntEqClasses.cpp
@@ -18,6 +18,7 @@
 
//===--===//
 
 #include "llvm/ADT/IntEqClasses.h"
+#include 
 
 using namespace llvm;
 

diff  --git a/llvm/lib/Support/IntervalMap.cpp 
b/llvm/lib/Support/IntervalMap.cpp
index f15c7c9403c3..674e0f962fa1 100644
--- a/llvm/lib/Support/IntervalMap.cpp
+++ b/llvm/lib/Support/IntervalMap.cpp
@@ -11,6 +11,7 @@
 
//===--===//
 
 #include "llvm/ADT/IntervalMap.h"
+#include 
 
 namespace llvm {
 namespace IntervalMapImpl {

diff  --git a/llvm/lib/Support/KnownBits.cpp b/llvm/lib/Support/KnownBits.cpp
index 8f3f4aa8caea..2f1cff7914bc 100644
--- a/llvm/lib/Support/KnownBits.cpp
+++ b/llvm/lib/Support/KnownBits.cpp
@@ -12,6 +12,7 @@
 
//===--===//
 
 #include "llvm/Support/KnownBits.h"
+#include 
 
 using namespace llvm;
 

diff  --git a/llvm/lib/Support/PrettyStackTrace.cpp 
b/llvm/lib/Support/PrettyStackTrace.cpp
index bfb238cc8539..30a12f65966a 100644
--- a/llvm/lib/Support/PrettyStackTrace.cpp
+++ b/llvm/lib/Support/PrettyStackTrace.cpp
@@ -22,6 +22,7 @@
 #include "llvm/Support/raw_ostream.h"
 
 #include 
+#include 
 #include 
 #include 
 #include 

diff  --git a/llvm/lib/Support/Regex.cpp b/llvm/lib/Support/Regex.cpp
index 615e48a5df7e..f065adadc62b 100644
--- a/llvm/lib/Support/Regex.cpp
+++ b/llvm/lib/Support/Regex.cpp
@@ -14,6 +14,7 @@
 #include "llvm/ADT/SmallVector.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/ADT/Twine.h"
+#include 
 #include 
 
 // Important this comes last because it defines "_REGEX_H_". At least on

diff  --git a/llvm/lib/Support/StringPool.cpp b/llvm/lib/Support/StringPool.cpp
index 82351017b8cc..27465389 100644
--- a/llvm/lib/Support/StringPool.cpp
+++ b/llvm/lib/Support/StringPool.cpp
@@ -12,6 +12,7 @@
 
 #include "llvm/Support/StringPool.h"
 #include "llvm/ADT/StringRef.h"
+#include 
 
 using namespace llvm;
 

diff  --git a/llvm/lib/Support/Triple.cpp b/llvm/lib/Support/Triple.cpp
index e09abd24eb5b..79f31efefb78 100644
--- a/llvm/lib/Support/Triple.cpp
+++ b/llvm/lib/Support/Triple.cpp
@@ -14,6 +14,7 @@
 #include "llvm/Support/Host.h"
 #include "llvm/Support/SwapByteOrder.h"
 #include "llvm/Support/TargetParser.h"
+#include 
 #include 
 using namespace llvm;
 

diff  --git a/llvm/lib/Support/VersionTuple.cpp 
b/llvm/lib/Support/VersionTuple.cpp
index 60b59424fbb4..

Re: r328040 - Set dso_local on string literals.

[Joerg Sonnenberger via cfe-commits]

On Tue, Mar 20, 2018 at 08:42:55PM -, Rafael Espindola via cfe-commits 
wrote:
> Author: rafael
> Date: Tue Mar 20 13:42:55 2018
> New Revision: 328040
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=328040&view=rev
> Log:
> Set dso_local on string literals.

I wonder if unnamed_addr shouldn't imply that in general?

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

Re: r328040 - Set dso_local on string literals.

[Joerg Sonnenberger via cfe-commits]

On Tue, Mar 20, 2018 at 05:01:24PM -0700, Rafael Avila de Espindola wrote:
> Joerg Sonnenberger via cfe-commits  writes:
> 
> > On Tue, Mar 20, 2018 at 08:42:55PM -, Rafael Espindola via cfe-commits 
> > wrote:
> >> Author: rafael
> >> Date: Tue Mar 20 13:42:55 2018
> >> New Revision: 328040
> >> 
> >> URL: http://llvm.org/viewvc/llvm-project?rev=328040&view=rev
> >> Log:
> >> Set dso_local on string literals.
> >
> > I wonder if unnamed_addr shouldn't imply that in general?
> 
> I don't think so. For example, a language where functions cannot be
> compared for equality could mark all functions unnamed_addr. It could
> still support interposition, which requires that they are not dso_local.

I don't think that argument makes sense. The address is not named, that
strongly implies that can't be interpositioned either.

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

r289744 - Use PIC relocation mode by default for PowerPC64 ELF

[Joerg Sonnenberger via cfe-commits]

Author: joerg
Date: Wed Dec 14 18:02:57 2016
New Revision: 289744

URL: http://llvm.org/viewvc/llvm-project?rev=289744&view=rev
Log:
Use PIC relocation mode by default for PowerPC64 ELF

Most of the PowerPC64 code generation already creates PIC access. This
changes to a full PIC default, similar to what GCC is doing.

Overall, a monolithic clang binary shrinks by 600KB (about 1%). This can
be a slight regression for TLS access and will use the TOC more
aggressively instead of synthesizing immediates. It is expected to be
performance neutral.

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

Modified:
cfe/trunk/lib/Driver/ToolChains.cpp
cfe/trunk/test/Driver/ppc-abi.c

Modified: cfe/trunk/lib/Driver/ToolChains.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains.cpp?rev=289744&r1=289743&r2=289744&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains.cpp Wed Dec 14 18:02:57 2016
@@ -2879,7 +2879,15 @@ bool Generic_GCC::IsUnwindTablesDefault(
 }
 
 bool Generic_GCC::isPICDefault() const {
-  return getArch() == llvm::Triple::x86_64 && getTriple().isOSWindows();
+  switch (getArch()) {
+  case llvm::Triple::x86_64:
+return getTriple().isOSWindows();
+  case llvm::Triple::ppc64:
+  case llvm::Triple::ppc64le:
+return !getTriple().isOSBinFormatMachO() && !getTriple().isMacOSX();
+  default:
+return false;
+  }
 }
 
 bool Generic_GCC::isPIEDefault() const { return false; }

Modified: cfe/trunk/test/Driver/ppc-abi.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/ppc-abi.c?rev=289744&r1=289743&r2=289744&view=diff
==
--- cfe/trunk/test/Driver/ppc-abi.c (original)
+++ cfe/trunk/test/Driver/ppc-abi.c Wed Dec 14 18:02:57 2016
@@ -24,7 +24,10 @@
 // RUN: %clang -target powerpc64le-unknown-linux-gnu %s -### -o %t.o 2>&1 \
 // RUN:   -mabi=altivec | FileCheck -check-prefix=CHECK-ELFv2 %s
 
+// CHECK-ELFv1: "-mrelocation-model" "pic" "-pic-level" "2"
 // CHECK-ELFv1: "-target-abi" "elfv1"
+// CHECK-ELFv1-QPX: "-mrelocation-model" "pic" "-pic-level" "2"
 // CHECK-ELFv1-QPX: "-target-abi" "elfv1-qpx"
+// CHECK-ELFv2: "-mrelocation-model" "pic" "-pic-level" "2"
 // CHECK-ELFv2: "-target-abi" "elfv2"
 


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

Re: r290533 - Driver: warn on -fPIC/-fpic/-fPIE/-fpie on Windows

[Joerg Sonnenberger via cfe-commits]

On Mon, Dec 26, 2016 at 03:35:25AM -, Saleem Abdulrasool via cfe-commits 
wrote:
> Driver: warn on -fPIC/-fpic/-fPIE/-fpie on Windows

Can we please invert this behavior? Complain if the effective PIC mode
is not level 2 and silently ignore it otherwise? I find the MinGW
warnings to be highly annoying and verbose.

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

Re: r290533 - Driver: warn on -fPIC/-fpic/-fPIE/-fpie on Windows

[Joerg Sonnenberger via cfe-commits]

On Tue, Dec 27, 2016 at 12:41:08PM -0800, Saleem Abdulrasool wrote:
> Id really rather not change the behavior.  We would generate ELF style PIC,
> which obviously doesn't work.

That's not what I mean. I simply say that we should ignore
-fPIC/-fpic/-fPIE/-fpie on Windows, silently. The relality is that the
majority of the code triggering the warning wants to created PIC, which
is the default. So creating a warning for that seems silly at best.

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

r291148 - Typo

[Joerg Sonnenberger via cfe-commits]

Author: joerg
Date: Thu Jan  5 11:59:44 2017
New Revision: 291148

URL: http://llvm.org/viewvc/llvm-project?rev=291148&view=rev
Log:
Typo

Modified:
cfe/trunk/unittests/Format/FormatTestJS.cpp

Modified: cfe/trunk/unittests/Format/FormatTestJS.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Format/FormatTestJS.cpp?rev=291148&r1=291147&r2=291148&view=diff
==
--- cfe/trunk/unittests/Format/FormatTestJS.cpp (original)
+++ cfe/trunk/unittests/Format/FormatTestJS.cpp Thu Jan  5 11:59:44 2017
@@ -541,8 +541,8 @@ TEST_F(FormatTestJS, FunctionLiterals) {
"  foo();\n"
"  bar();\n"
"},\n"
-   "this, arg1IsReallyLongAndNeeedsLineBreaks,\n"
-   "arg3IsReallyLongAndNeeedsLineBreaks);");
+   "this, arg1IsReallyLongAndNeedsLineBreaks,\n"
+   "arg3IsReallyLongAndNeedsLineBreaks);");
   verifyFormat("var closure = goog.bind(function() {  // comment\n"
"  foo();\n"
"  bar();\n"


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

r291436 - Extend NetBSD/AArch64 to cover Big Endian as well.

[Joerg Sonnenberger via cfe-commits]

Author: joerg
Date: Mon Jan  9 05:22:14 2017
New Revision: 291436

URL: http://llvm.org/viewvc/llvm-project?rev=291436&view=rev
Log:
Extend NetBSD/AArch64 to cover Big Endian as well.

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

Modified: cfe/trunk/lib/Driver/ToolChains.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains.cpp?rev=291436&r1=291435&r2=291436&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains.cpp Mon Jan  9 05:22:14 2017
@@ -3812,6 +3812,7 @@ ToolChain::CXXStdlibType NetBSD::GetDefa
   if (Major >= 7 || Major == 0) {
 switch (getArch()) {
 case llvm::Triple::aarch64:
+case llvm::Triple::aarch64_be:
 case llvm::Triple::arm:
 case llvm::Triple::armeb:
 case llvm::Triple::thumb:

Modified: cfe/trunk/lib/Driver/Tools.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=291436&r1=291435&r2=291436&view=diff
==
--- cfe/trunk/lib/Driver/Tools.cpp (original)
+++ cfe/trunk/lib/Driver/Tools.cpp Mon Jan  9 05:22:14 2017
@@ -9644,6 +9644,7 @@ void netbsd::Linker::ConstructJob(Compil
   if (Major >= 7 || Major == 0) {
 switch (getToolChain().getArch()) {
 case llvm::Triple::aarch64:
+case llvm::Triple::aarch64_be:
 case llvm::Triple::arm:
 case llvm::Triple::armeb:
 case llvm::Triple::thumb:

Modified: cfe/trunk/test/Driver/netbsd.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/netbsd.c?rev=291436&r1=291435&r2=291436&view=diff
==
--- cfe/trunk/test/Driver/netbsd.c (original)
+++ cfe/trunk/test/Driver/netbsd.c Mon Jan  9 05:22:14 2017
@@ -23,6 +23,12 @@
 // RUN: %clang -no-canonical-prefixes -target aarch64--netbsd7.0.0 \
 // RUN: --sysroot=%S/Inputs/basic_netbsd_tree %s -### 2>&1 \
 // RUN: | FileCheck -check-prefix=AARCH64-7 %s
+// RUN: %clang -no-canonical-prefixes -target aarch64_be--netbsd \
+// RUN: --sysroot=%S/Inputs/basic_netbsd_tree %s -### 2>&1 \
+// RUN: | FileCheck -check-prefix=AARCH64_BE %s
+// RUN: %clang -no-canonical-prefixes -target aarch64_be--netbsd7.0.0 \
+// RUN: --sysroot=%S/Inputs/basic_netbsd_tree %s -### 2>&1 \
+// RUN: | FileCheck -check-prefix=AARCH64_BE-7 %s
 // RUN: %clang -no-canonical-prefixes -target arm--netbsd-eabi \
 // RUN: -no-integrated-as --sysroot=%S/Inputs/basic_netbsd_tree %s -### 2>&1 \
 // RUN: | FileCheck -check-prefix=ARM %s
@@ -84,6 +90,12 @@
 // RUN: %clang -no-canonical-prefixes -target aarch64--netbsd7.0.0 -static \
 // RUN: --sysroot=%S/Inputs/basic_netbsd_tree %s -### 2>&1 \
 // RUN: | FileCheck -check-prefix=S-AARCH64-7 %s
+// RUN: %clang -no-canonical-prefixes -target aarch64_be--netbsd -static \
+// RUN: --sysroot=%S/Inputs/basic_netbsd_tree %s -### 2>&1 \
+// RUN: | FileCheck -check-prefix=S-AARCH64_BE %s
+// RUN: %clang -no-canonical-prefixes -target aarch64_be--netbsd7.0.0 -static \
+// RUN: --sysroot=%S/Inputs/basic_netbsd_tree %s -### 2>&1 \
+// RUN: | FileCheck -check-prefix=S-AARCH64_BE-7 %s
 // RUN: %clang -no-canonical-prefixes -target arm--netbsd-eabi -static \
 // RUN: --sysroot=%S/Inputs/basic_netbsd_tree %s -### 2>&1 \
 // RUN: | FileCheck -check-prefix=S-ARM %s
@@ -171,6 +183,18 @@
 // AARCH64-7:  "{{.*}}/usr/lib{{/|}}crtbegin.o" "{{.*}}.o" "-lc"
 // AARCH64-7: "{{.*}}/usr/lib{{/|}}crtend.o" 
"{{.*}}/usr/lib{{/|}}crtn.o"
 
+// AARCH64_BE: clang{{.*}}" "-cc1" "-triple" "aarch64_be--netbsd"
+// AARCH64_BE: ld{{.*}}" "--eh-frame-hdr" "-dynamic-linker" 
"/libexec/ld.elf_so"
+// AARCH64_BE: "-o" "a.out" "{{.*}}/usr/lib{{/|}}crt0.o" 
"{{.*}}/usr/lib{{/|}}crti.o"
+// AARCH64_BE: "{{.*}}/usr/lib{{/|}}crtbegin.o" "{{.*}}.o" "-lc"
+// AARCH64_BE: "{{.*}}/usr/lib{{/|}}crtend.o" 
"{{.*}}/usr/lib{{/|}}crtn.o"
+
+// AARCH64_BE-7: clang{{.*}}" "-cc1" "-triple" "aarch64_be--netbsd7.0.0"
+// AARCH64_BE-7: ld{{.*}}" "--eh-frame-hdr" "-dynamic-linker" 
"/libexec/ld.elf_so"
+// AARCH64_BE-7: "-o" "a.out" "{{.*}}/usr/lib{{/|}}crt0.o" 
"{{.*}}/usr/lib{{/|}}crti.o"
+// AARCH64_BE-7:  "{{.*}}/usr/lib{{/|}}crtbegin.o" "{{.*}}.o" "-lc"
+// AARCH64_BE-7: "{{.*}}/usr/lib{{/|}}crtend.o" 
"{{.*}}/usr/lib{{/|}}crtn.o"
+
 // ARM: clang{{.*}}" "-cc1" "-triple" "armv5e--netbsd-eabi"
 // ARM: as{{.*}}" "-mcpu=arm926ej-s" "-o"
 // ARM: ld{{.*}}" "--eh-frame-hdr" "-dynamic-linker" "/libexec/ld.elf_so"
@@ -311,6 +335,18 @@
 // S-AARCH64-7: "{{.*}}/usr/lib{{/|}}crtbegin.o" "{{.*}}.o" "-lc"
 // S-AARCH64-7: "{{.*}}/usr/lib{{/|}}crtend.o" 
"{{.*}}/usr/lib{{/|}}crtn.o"
 
+// S-AARCH64_BE: clang{{.*}}" "-cc1" "-triple" "aarch64_be--netbsd"
+// S-AARCH64_BE: ld{{.*}}" "--eh-frame-hdr" "-Bstatic"
+// S-AARCH64_BE: "-o"

r291437 - Use the same ABI logic for AArch64 Big Endian as in other places

[Joerg Sonnenberger via cfe-commits]

Author: joerg
Date: Mon Jan  9 05:40:41 2017
New Revision: 291437

URL: http://llvm.org/viewvc/llvm-project?rev=291437&view=rev
Log:
Use the same ABI logic for AArch64 Big Endian as in other places
covering polys.

Modified:
cfe/trunk/lib/Sema/SemaChecking.cpp

Modified: cfe/trunk/lib/Sema/SemaChecking.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaChecking.cpp?rev=291437&r1=291436&r2=291437&view=diff
==
--- cfe/trunk/lib/Sema/SemaChecking.cpp (original)
+++ cfe/trunk/lib/Sema/SemaChecking.cpp Mon Jan  9 05:40:41 2017
@@ -1242,7 +1242,8 @@ bool Sema::CheckNeonBuiltinFunctionCall(
 QualType RHSTy = RHS.get()->getType();
 
 llvm::Triple::ArchType Arch = 
Context.getTargetInfo().getTriple().getArch();
-bool IsPolyUnsigned = Arch == llvm::Triple::aarch64;
+bool IsPolyUnsigned = Arch == llvm::Triple::aarch64 ||
+  Arch == llvm::Triple::aarch64_be;
 bool IsInt64Long =
 Context.getTargetInfo().getInt64Type() == TargetInfo::SignedLong;
 QualType EltTy =


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

Re: r278882 - If possible, set the stack rlimit to at least 8MiB on cc1 startup, and work

[Joerg Sonnenberger via cfe-commits]

On Wed, Aug 17, 2016 at 01:05:08AM -, Richard Smith via cfe-commits wrote:
> Author: rsmith
> Date: Tue Aug 16 20:05:07 2016
> New Revision: 278882
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=278882&view=rev
> Log:
> If possible, set the stack rlimit to at least 8MiB on cc1 startup, and work
> around a Linux kernel bug where the actual amount of available stack may be a
> *lot* lower than the rlimit.

Can you please restrict this to Linux? I'm quite opposed to overriding
system default limits, they exist for a reason.

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

Re: r278882 - If possible, set the stack rlimit to at least 8MiB on cc1 startup, and work

[Joerg Sonnenberger via cfe-commits]

On Thu, Aug 18, 2016 at 11:33:49AM -0700, Richard Smith wrote:
> On Wed, Aug 17, 2016 at 6:35 AM, Joerg Sonnenberger via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
> 
> > On Wed, Aug 17, 2016 at 01:05:08AM -, Richard Smith via cfe-commits
> > wrote:
> > > Author: rsmith
> > > Date: Tue Aug 16 20:05:07 2016
> > > New Revision: 278882
> > >
> > > URL: http://llvm.org/viewvc/llvm-project?rev=278882&view=rev
> > > Log:
> > > If possible, set the stack rlimit to at least 8MiB on cc1 startup, and
> > work
> > > around a Linux kernel bug where the actual amount of available stack may
> > be a
> > > *lot* lower than the rlimit.
> >
> > Can you please restrict this to Linux? I'm quite opposed to overriding
> > system default limits, they exist for a reason.
> 
> 
> No, that wouldn't make any sense. It's not up to the operating system how
> an application decides to allocate memory (on the heap versus on the
> stack), and Clang's stack usage isn't going to be significantly lower on
> other kernels. If some BSD kernel's VM is unable to cope with this, we
> could spawn a thread with a suitable amount of stack space instead.

This is not about kernel bugs. It is about POLA -- programs are not
supposed to alter process limits. If GCC does it, it is a GCC bug.
That's no reason to introduce the same bug here. Using excessive stack
space due to deep recursion might be a QoI issue, but it is
fundamentally no different from any other out of memory condition. Those
kill clang just as easily.

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

Re: r278882 - If possible, set the stack rlimit to at least 8MiB on cc1 startup, and work

[Joerg Sonnenberger via cfe-commits]

On Fri, Aug 19, 2016 at 01:03:51PM -0700, Richard Smith wrote:
> On Fri, Aug 19, 2016 at 12:58 PM, Joerg Sonnenberger via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
> 
> > On Thu, Aug 18, 2016 at 11:33:49AM -0700, Richard Smith wrote:
> > > On Wed, Aug 17, 2016 at 6:35 AM, Joerg Sonnenberger via cfe-commits <
> > > cfe-commits@lists.llvm.org> wrote:
> > >
> > > > On Wed, Aug 17, 2016 at 01:05:08AM -, Richard Smith via cfe-commits
> > > > wrote:
> > > > > Author: rsmith
> > > > > Date: Tue Aug 16 20:05:07 2016
> > > > > New Revision: 278882
> > > > >
> > > > > URL: http://llvm.org/viewvc/llvm-project?rev=278882&view=rev
> > > > > Log:
> > > > > If possible, set the stack rlimit to at least 8MiB on cc1 startup,
> > and
> > > > work
> > > > > around a Linux kernel bug where the actual amount of available stack
> > may
> > > > be a
> > > > > *lot* lower than the rlimit.
> > > >
> > > > Can you please restrict this to Linux? I'm quite opposed to overriding
> > > > system default limits, they exist for a reason.
> > >
> > >
> > > No, that wouldn't make any sense. It's not up to the operating system how
> > > an application decides to allocate memory (on the heap versus on the
> > > stack), and Clang's stack usage isn't going to be significantly lower on
> > > other kernels. If some BSD kernel's VM is unable to cope with this, we
> > > could spawn a thread with a suitable amount of stack space instead.
> >
> > This is not about kernel bugs. It is about POLA -- programs are not
> > supposed to alter process limits. If GCC does it, it is a GCC bug.
> > That's no reason to introduce the same bug here. Using excessive stack
> > space due to deep recursion might be a QoI issue, but it is
> > fundamentally no different from any other out of memory condition. Those
> > kill clang just as easily.
> 
> 
> Hitting this limit does not imply that memory was exhausted, it instead
> means the OS killed a process that was functioning just fine, for no good
> reason.

You are allocating too much stack space. There is no difference to heap
allocations which are bound by different flags. It is just a different
allocation mechanism. Even hitting a 4MB stack space limit on 64bit
platforms takes quite a bit -- not even boost does that by default. As
such, I hardly find it normal.

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

Re: r278882 - If possible, set the stack rlimit to at least 8MiB on cc1 startup, and work

[Joerg Sonnenberger via cfe-commits]

On Fri, Aug 19, 2016 at 01:16:59PM -0700, Richard Smith wrote:
> On Fri, Aug 19, 2016 at 1:10 PM, Joerg Sonnenberger via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
> 
> > On Fri, Aug 19, 2016 at 01:03:51PM -0700, Richard Smith wrote:
> > > On Fri, Aug 19, 2016 at 12:58 PM, Joerg Sonnenberger via cfe-commits <
> > > cfe-commits@lists.llvm.org> wrote:
> > >
> > > > On Thu, Aug 18, 2016 at 11:33:49AM -0700, Richard Smith wrote:
> > > > > On Wed, Aug 17, 2016 at 6:35 AM, Joerg Sonnenberger via cfe-commits <
> > > > > cfe-commits@lists.llvm.org> wrote:
> > > > >
> > > > > > On Wed, Aug 17, 2016 at 01:05:08AM -, Richard Smith via
> > cfe-commits
> > > > > > wrote:
> > > > > > > Author: rsmith
> > > > > > > Date: Tue Aug 16 20:05:07 2016
> > > > > > > New Revision: 278882
> > > > > > >
> > > > > > > URL: http://llvm.org/viewvc/llvm-project?rev=278882&view=rev
> > > > > > > Log:
> > > > > > > If possible, set the stack rlimit to at least 8MiB on cc1
> > startup,
> > > > and
> > > > > > work
> > > > > > > around a Linux kernel bug where the actual amount of available
> > stack
> > > > may
> > > > > > be a
> > > > > > > *lot* lower than the rlimit.
> > > > > >
> > > > > > Can you please restrict this to Linux? I'm quite opposed to
> > overriding
> > > > > > system default limits, they exist for a reason.
> > > > >
> > > > >
> > > > > No, that wouldn't make any sense. It's not up to the operating
> > system how
> > > > > an application decides to allocate memory (on the heap versus on the
> > > > > stack), and Clang's stack usage isn't going to be significantly
> > lower on
> > > > > other kernels. If some BSD kernel's VM is unable to cope with this,
> > we
> > > > > could spawn a thread with a suitable amount of stack space instead.
> > > >
> > > > This is not about kernel bugs. It is about POLA -- programs are not
> > > > supposed to alter process limits. If GCC does it, it is a GCC bug.
> > > > That's no reason to introduce the same bug here. Using excessive stack
> > > > space due to deep recursion might be a QoI issue, but it is
> > > > fundamentally no different from any other out of memory condition.
> > Those
> > > > kill clang just as easily.
> > >
> > >
> > > Hitting this limit does not imply that memory was exhausted, it instead
> > > means the OS killed a process that was functioning just fine, for no good
> > > reason.
> >
> > You are allocating too much stack space.
> 
> 
> Whether we choose to put data on the heap or stack is not up to you or the
> operating system.

How is that relevant to honoring system limits? At the very least your
commit says "clang knows better than the system administrator".

> > There is no difference to heap
> > allocations which are bound by different flags. It is just a different
> > allocation mechanism. Even hitting a 4MB stack space limit on 64bit
> > platforms takes quite a bit -- not even boost does that by default. As
> > such, I hardly find it normal.
> 
> It's not normal; that's why we're explicitly opting into it here, using the
> mechanism that POSIX provides to do so.

Read again. Input triggering such deep stack case is not normal. Just
because POSIX provides mechanisms for a shell to implement ulimit
doesn't mean that it is considered bad form for *applications* to
override them, especially increasing them. Shall we raise the address
space limits next, because there is input that easily requires more than
16GB of memory to compile? What about bumping the CPU time limit,
because we have input where clang needs hours to compile a single file?

All your commit has done is introduce another funny way to screw users.
There are users of the clang libraries that are not the clang driver.
They don't get this magic stack size boost. Now we have source files
that can be handled by clang but not by library consumers. Lovely edge
case. It all comes back to "raise limits for exceptional programs".
Just like users of compilers for functional languages have learned:
if you write source that triggers such limits, make sure your system is
up for handling them.

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

Re: r278882 - If possible, set the stack rlimit to at least 8MiB on cc1 startup, and work

[Joerg Sonnenberger via cfe-commits]

On Fri, Aug 19, 2016 at 03:30:42PM -0700, Richard Smith wrote:
> It typically does; the default stack ulimit is likely tuned for "normal"
> applications that are not expected (by an ISO standard) to cope with
> recursing a thousand levels deep. If the system administrator really wants
> to control the stack space for some stupid reason, they can set a hard
> ulimit. If people actually do that, and then file bugs on clang crashing
> (which they do today), we may want to resort to spawning a separate thread
> with a higher ulimit if we detect the problem.

Thread stacks by default are even smaller and for good reason.
Especially on 32bit platforms, it would be unusable otherwise. To put
this into perspective: if you need to support a recursion level of 1000
and can't do that with a 4MB stack, it means you are using more than 4KB
per recursion level. That's a very high stack use and certainly
something that qualifies as the kind of abusive behavior the process
limit is designed for in first place.

> It *is* unreasonable to expect them to fiddle with stack ulimits to get the
> compiler to accept programs that, say, use certain components of boost (and
> fit within the standard's recommended limits).

I fundamentally disagree with this statement. Effectively, this seems to
me to be papering over excessive stack use and nothing else.

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

Re: r278882 - If possible, set the stack rlimit to at least 8MiB on cc1 startup, and work

[Joerg Sonnenberger via cfe-commits]

On Sat, Aug 20, 2016 at 12:45:59AM +, Chandler Carruth wrote:
> I feel like this thread has two very unrelated concerns and it might be
> useful to separate them.
> 
> 1) Should an application be changing the stack limit, or should the system
> be able to enforce this?
> 
> Fortunately, there are two limits. One an application is allowed to change,
> one it isn't. It seems like the mechanism has been provided for system
> administrators to impose firm limits and neither Clang nor another
> application will perturb them. I don't see any reason to preclude an
> application from changing the one it is explicitly permitted to change.
> That seems to be WAI from a permissions and ACL model.

The only application processes that normally change process limits are
the shells or certain network processes that change the file limit
according to the configured number of connections. The soft limit exists
to allow a user to adjust his/her own limits within bounds. That's why
the first category has appropiate syntax for it. The second category on
the other hand knows pretty precisely what it wants to consume in terms
of ressources and plans accordingly. Clang falls into neither category.
The existing bugs are even evidence of that, e.g. 15560 says 8MB is not
enough either. So this is a patchy band aid at most, it doesn't even solve
the problem.

> 2) Should Clang be using the stack to allocate significant portions of its
> memory, or should it be assiduously keeping allocations on the heap and
> removing recursive algorithms?
> 
> I actually think this is the crux of the issue, and #1 is largely coming up
> as a proxy for "Clang should use less stack space".

I fully agree that there would be no request for fiddling with the stack
limit from within clang without clang blowing up the stack.

> However, I'll point out that this commit does not change how much stack
> space Clang uses. It just changes the nature of errors that occur to make
> the experience of today's Clang more friendly for users. So this commit
> seems like a fine thing even if we decide that Clang should work to lower
> this number over time and reduce what it sets it to. In fact, if you want
> to reduce Clang's stack usage, you almost certainly want it to explicitly
> set a limit so that we consistently hit errors when bugs creep into Clang.
> 
> Past that, while I think Clang's current allocation and recursion pattern
> is fine, I don't actually have a terribly strong opinion. But it seems odd
> to suddenly want to make a dramatic change in the design of Clang now... It
> doesn't seem like this was an accidental or unconsidered design decision.

Correct, this commit does nothing about the reducing the stack use by
clang. But let's look at one of the few bug reports that actually seem
to contain some numbers: 20635. This shows 3200 stack frames consuing
the 2MB default stack on 32bit FreeBSD. Similar defaults limits can be
found on most 32bit platforms, 64bit platforms typically have twice that
limit. This means the average stack frame is 600 Bytes for something
that is *intended* to recurse deeply. It seems pretty obvious to me that
this is the real problem and something that should be fixed. The LLVM
are much more conversative here. Many of the deep recursion places
either use very little stack space or follow the more typical work queue
approach. Setting a higher stack limit is I said earlier is just a
bandaid to paper over implementation issues.

Setting an explicit limit in the test suite would be fine by me. The
only problem in this area is that the kind of limits you want to set can
be difficult to do consistently across platforms, i.e. I would certainly
welcome it if no test case is supposed to require more than 1GB of VA
and 1MB/2MB of stack. That's a slightly different question though.

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

r280607 - PR 27200: Fix names of the atomic lock-free macros.

[Joerg Sonnenberger via cfe-commits]

Author: joerg
Date: Sat Sep  3 19:44:10 2016
New Revision: 280607

URL: http://llvm.org/viewvc/llvm-project?rev=280607&view=rev
Log:
PR 27200: Fix names of the atomic lock-free macros.

Modified:
cfe/trunk/lib/Headers/stdatomic.h

Modified: cfe/trunk/lib/Headers/stdatomic.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/stdatomic.h?rev=280607&r1=280606&r2=280607&view=diff
==
--- cfe/trunk/lib/Headers/stdatomic.h (original)
+++ cfe/trunk/lib/Headers/stdatomic.h Sat Sep  3 19:44:10 2016
@@ -45,18 +45,18 @@ extern "C" {
 #define ATOMIC_CHAR16_T_LOCK_FREE   __GCC_ATOMIC_CHAR16_T_LOCK_FREE
 #define ATOMIC_CHAR32_T_LOCK_FREE   __GCC_ATOMIC_CHAR32_T_LOCK_FREE
 #define ATOMIC_WCHAR_T_LOCK_FREE__GCC_ATOMIC_WCHAR_T_LOCK_FREE
-#define ATOMIC_SHORT_T_LOCK_FREE__GCC_ATOMIC_SHORT_T_LOCK_FREE
-#define ATOMIC_INT_T_LOCK_FREE  __GCC_ATOMIC_INT_T_LOCK_FREE
-#define ATOMIC_LONG_T_LOCK_FREE __GCC_ATOMIC_LONG_T_LOCK_FREE
-#define ATOMIC_LLONG_T_LOCK_FREE__GCC_ATOMIC_LLONG_T_LOCK_FREE
-#define ATOMIC_POINTER_T_LOCK_FREE  __GCC_ATOMIC_POINTER_T_LOCK_FREE
+#define ATOMIC_SHORT_LOCK_FREE  __GCC_ATOMIC_SHORT_LOCK_FREE
+#define ATOMIC_INT_LOCK_FREE__GCC_ATOMIC_INT_LOCK_FREE
+#define ATOMIC_LONG_LOCK_FREE   __GCC_ATOMIC_LONG_LOCK_FREE
+#define ATOMIC_LLONG_LOCK_FREE  __GCC_ATOMIC_LLONG_LOCK_FREE
+#define ATOMIC_POINTER_LOCK_FREE__GCC_ATOMIC_POINTER_LOCK_FREE
 
 /* 7.17.2 Initialization */
 
 #define ATOMIC_VAR_INIT(value) (value)
 #define atomic_init __c11_atomic_init
 
-/* 7.17.3 Order and consistency */
+/* 7.17.3 Order and consistency */.
 
 typedef enum memory_order {
   memory_order_relaxed = __ATOMIC_RELAXED,


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

Re: r280607 - PR 27200: Fix names of the atomic lock-free macros.

[Joerg Sonnenberger via cfe-commits]

Hi Tom,
can I merge this into 3.8 and 3.9?

Joerg

On Sun, Sep 04, 2016 at 12:44:10AM -, Joerg Sonnenberger via cfe-commits 
wrote:
> Author: joerg
> Date: Sat Sep  3 19:44:10 2016
> New Revision: 280607
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=280607&view=rev
> Log:
> PR 27200: Fix names of the atomic lock-free macros.
> 
> Modified:
> cfe/trunk/lib/Headers/stdatomic.h
> 
> Modified: cfe/trunk/lib/Headers/stdatomic.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/stdatomic.h?rev=280607&r1=280606&r2=280607&view=diff
> ==
> --- cfe/trunk/lib/Headers/stdatomic.h (original)
> +++ cfe/trunk/lib/Headers/stdatomic.h Sat Sep  3 19:44:10 2016
> @@ -45,18 +45,18 @@ extern "C" {
>  #define ATOMIC_CHAR16_T_LOCK_FREE   __GCC_ATOMIC_CHAR16_T_LOCK_FREE
>  #define ATOMIC_CHAR32_T_LOCK_FREE   __GCC_ATOMIC_CHAR32_T_LOCK_FREE
>  #define ATOMIC_WCHAR_T_LOCK_FREE__GCC_ATOMIC_WCHAR_T_LOCK_FREE
> -#define ATOMIC_SHORT_T_LOCK_FREE__GCC_ATOMIC_SHORT_T_LOCK_FREE
> -#define ATOMIC_INT_T_LOCK_FREE  __GCC_ATOMIC_INT_T_LOCK_FREE
> -#define ATOMIC_LONG_T_LOCK_FREE __GCC_ATOMIC_LONG_T_LOCK_FREE
> -#define ATOMIC_LLONG_T_LOCK_FREE__GCC_ATOMIC_LLONG_T_LOCK_FREE
> -#define ATOMIC_POINTER_T_LOCK_FREE  __GCC_ATOMIC_POINTER_T_LOCK_FREE
> +#define ATOMIC_SHORT_LOCK_FREE  __GCC_ATOMIC_SHORT_LOCK_FREE
> +#define ATOMIC_INT_LOCK_FREE__GCC_ATOMIC_INT_LOCK_FREE
> +#define ATOMIC_LONG_LOCK_FREE   __GCC_ATOMIC_LONG_LOCK_FREE
> +#define ATOMIC_LLONG_LOCK_FREE  __GCC_ATOMIC_LLONG_LOCK_FREE
> +#define ATOMIC_POINTER_LOCK_FREE__GCC_ATOMIC_POINTER_LOCK_FREE
>  
>  /* 7.17.2 Initialization */
>  
>  #define ATOMIC_VAR_INIT(value) (value)
>  #define atomic_init __c11_atomic_init
>  
> -/* 7.17.3 Order and consistency */
> +/* 7.17.3 Order and consistency */.
>  
>  typedef enum memory_order {
>memory_order_relaxed = __ATOMIC_RELAXED,
> 
> 
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r280609 - Trailing dot that shouldn't have been committed.

[Joerg Sonnenberger via cfe-commits]

Author: joerg
Date: Sat Sep  3 19:51:02 2016
New Revision: 280609

URL: http://llvm.org/viewvc/llvm-project?rev=280609&view=rev
Log:
Trailing dot that shouldn't have been committed.

Modified:
cfe/trunk/lib/Headers/stdatomic.h

Modified: cfe/trunk/lib/Headers/stdatomic.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/stdatomic.h?rev=280609&r1=280608&r2=280609&view=diff
==
--- cfe/trunk/lib/Headers/stdatomic.h (original)
+++ cfe/trunk/lib/Headers/stdatomic.h Sat Sep  3 19:51:02 2016
@@ -56,7 +56,7 @@ extern "C" {
 #define ATOMIC_VAR_INIT(value) (value)
 #define atomic_init __c11_atomic_init
 
-/* 7.17.3 Order and consistency */.
+/* 7.17.3 Order and consistency */
 
 typedef enum memory_order {
   memory_order_relaxed = __ATOMIC_RELAXED,


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

Re: r280607 - PR 27200: Fix names of the atomic lock-free macros.

[Joerg Sonnenberger via cfe-commits]

On Sat, Sep 03, 2016 at 05:56:43PM -0700, Richard Smith wrote:
>  /* 7.17.2 Initialization */
> 
>  #define ATOMIC_VAR_INIT(value) (value)
>  #define atomic_init __c11_atomic_init
> 
> -/* 7.17.3 Order and consistency */
> +/* 7.17.3 Order and consistency */.
> 
> 
> Stray period here. Do we not have any tests that include this header? 

We do. Pre-commit editor snafu. Sorry about that.

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

r280622 - Test case for r280607 to check presence and sanity of the *_LOCK_FREE

[Joerg Sonnenberger via cfe-commits]

Author: joerg
Date: Sun Sep  4 06:21:27 2016
New Revision: 280622

URL: http://llvm.org/viewvc/llvm-project?rev=280622&view=rev
Log:
Test case for r280607 to check presence and sanity of the *_LOCK_FREE
macros.

Added:
cfe/trunk/test/Headers/stdatomic.c

Added: cfe/trunk/test/Headers/stdatomic.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Headers/stdatomic.c?rev=280622&view=auto
==
--- cfe/trunk/test/Headers/stdatomic.c (added)
+++ cfe/trunk/test/Headers/stdatomic.c Sun Sep  4 06:21:27 2016
@@ -0,0 +1,32 @@
+// RUN: %clang_cc1 -std=c11 -E %s | FileCheck %s
+#include 
+
+int bool_lock_free = ATOMIC_BOOL_LOCK_FREE;
+// CHECK: bool_lock_free = {{ *[012] *;}}
+
+int char_lock_free = ATOMIC_CHAR_LOCK_FREE;
+// CHECK: char_lock_free = {{ *[012] *;}}
+
+int char16_t_lock_free = ATOMIC_CHAR16_T_LOCK_FREE;
+// CHECK: char16_t_lock_free = {{ *[012] *;}}
+
+int char32_t_lock_free = ATOMIC_CHAR32_T_LOCK_FREE;
+// CHECK: char32_t_lock_free = {{ *[012] *;}}
+
+int wchar_t_lock_free = ATOMIC_WCHAR_T_LOCK_FREE;
+// CHECK: wchar_t_lock_free = {{ *[012] *;}}
+
+int short_lock_free = ATOMIC_SHORT_LOCK_FREE;
+// CHECK: short_lock_free = {{ *[012] *;}}
+
+int int_lock_free = ATOMIC_INT_LOCK_FREE;
+// CHECK: int_lock_free = {{ *[012] *;}}
+
+int long_lock_free = ATOMIC_LONG_LOCK_FREE;
+// CHECK: long_lock_free = {{ *[012] *;}}
+
+int llong_lock_free = ATOMIC_LLONG_LOCK_FREE;
+// CHECK: llong_lock_free = {{ *[012] *;}}
+
+int pointer_lock_free = ATOMIC_POINTER_LOCK_FREE;
+// CHECK: pointer_lock_free = {{ *[012] *;}}


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

Re: r280607 - PR 27200: Fix names of the atomic lock-free macros.

[Joerg Sonnenberger via cfe-commits]

On Sat, Sep 03, 2016 at 10:06:48PM -0700, Richard Smith wrote:
> Thanks for the fix. Can you add a simple test that we provide macros with
> the right name? Other than that, it makes sense to me for this to go to the
> release branches.

Done.

> (I'm not sure whether we're doing more 3.8 point releases
> now that 3.9 is out though.)

There are still downstream consumers of 3.8, so merging fixes generally
make it easier for them.

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

Re: [PATCH] D24448: [atomics] New warning -Watomic-libcall when atomic operation expands to a library call

[Joerg Sonnenberger via cfe-commits]

joerg added a subscriber: joerg.
joerg added a comment.

While I agree with the general sentiment, the check doesn't work at all. For 
example, ARMv4 always has to use libcalls. It's not even true that libcalls are 
slow, i.e. on true non-parallel architectures, the libcall can be as simple as 
a restartable atomic sequence and is almost cost free beyond the function call 
overhead.


https://reviews.llvm.org/D24448



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

Re: [PATCH] D24448: [atomics] New warning -Watomic-libcall when atomic operation expands to a library call

[Joerg Sonnenberger via cfe-commits]

joerg added a comment.

More precisely, this should re-use the logic from __atomic_is_lock_free and not 
reinvent it.


https://reviews.llvm.org/D24448



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

Re: r281277 - [Sema] Fix PR30346: relax __builtin_object_size checks.

[Joerg Sonnenberger via cfe-commits]

On Mon, Sep 12, 2016 at 11:50:36PM -, George Burgess IV via cfe-commits 
wrote:
> Author: gbiv
> Date: Mon Sep 12 18:50:35 2016
> New Revision: 281277
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=281277&view=rev
> Log:
> [Sema] Fix PR30346: relax __builtin_object_size checks.
> 
> This patch makes us act more conservatively when trying to determine
> the objectsize for an array at the end of an object. This is in
> response to code like the following:
> 
> ```
> struct sockaddr {
>   /* snip */
>   char sa_data[14];
> };
> 
> void foo(const char *s) {
>   size_t slen = strlen(s) + 1;
>   size_t added_len = slen <= 14 ? 0 : slen - 14;
>   struct sockaddr *sa = malloc(sizeof(struct sockaddr) + added_len);
>   strcpy(sa->sa_data, s);
>   // ...
> }
> ```
> 
> `__builtin_object_size(sa->sa_data, 1)` would return 14, when there
> could be more than 14 bytes at `sa->sa_data`.
> 
> Code like this is apparently not uncommon. FreeBSD's manual even
> explicitly mentions this pattern:
> https://www.freebsd.org/doc/en/books/developers-handbook/sockets-essential-functions.html
> (section 7.5.1.1.2).
> 
> In light of this, we now just give up on any array at the end of an
> object if we can't find the object's initial allocation.
> 
> I lack numbers for how much more conservative we actually become as a
> result of this change, so I chose the fix that would make us as
> compatible with GCC as possible. If we want to be more aggressive, I'm
> happy to consider some kind of whitelist or something instead.

IMO this should be restricted to code that explicitly disables C/C++
aliasing rules.

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

Re: r281277 - [Sema] Fix PR30346: relax __builtin_object_size checks.

[Joerg Sonnenberger via cfe-commits]

On Tue, Sep 13, 2016 at 12:51:52PM -0700, Richard Smith wrote:
> On Tue, Sep 13, 2016 at 10:44 AM, Joerg Sonnenberger via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
> 
> > IMO this should be restricted to code that explicitly disables C/C++
> > aliasing rules.
> 
> 
> Do you mean -fno-strict-aliasing or -fno-struct-path-tbaa or something else
> here? (I think we're not doing anyone any favours by making _FORTIFY_SOURCE
> say that a pattern is OK in cases when LLVM will in fact optimize on the
> assumption that it's UB, but I don't recall how aggressive
> -fstruct-path-tbaa is for trailing array members.)

The former immediately, the latter potentially as well. I can't think of
many use cases for this kind of idiom that don't involve type prunning
and socket code is notoriously bad in that regard by necessity.

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

Re: [PATCH] D30700: [Driver] Always add arch-specific-subdir to -rpath

[Joerg Sonnenberger via cfe-commits]

On Mon, Mar 13, 2017 at 10:37:41PM +, Reid Kleckner via Phabricator via 
cfe-commits wrote:
> I don't agree. If we want to be good citizens on Linux, what's supposed
> to happen is that we install our shared libraries into
> /usr/lib/${distro_target}, which is what GCC does with its shared
> compiler runtime libraries. GCC does not add system-specific absolute
> rpaths to the binaries it produces.

That only applies if you install into /usr directly. There are many use
cases for which this is not the case. GCC generally handles them abysmal
and I'd prefer if we didn't go that way. In short: if you can reasonably
expect the rtlib path to be part of the system default, no rpath is
necessary. Otherwise, the driver should add it and make it easy for
clang builds to provide them. A compile-time flag is fine that though.

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

r291814 - Add entry for -MJ.

[Joerg Sonnenberger via cfe-commits]

Author: joerg
Date: Thu Jan 12 15:11:55 2017
New Revision: 291814

URL: http://llvm.org/viewvc/llvm-project?rev=291814&view=rev
Log:
Add entry for -MJ.

Modified:
cfe/trunk/docs/ReleaseNotes.rst

Modified: cfe/trunk/docs/ReleaseNotes.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ReleaseNotes.rst?rev=291814&r1=291813&r2=291814&view=diff
==
--- cfe/trunk/docs/ReleaseNotes.rst (original)
+++ cfe/trunk/docs/ReleaseNotes.rst Thu Jan 12 15:11:55 2017
@@ -65,6 +65,8 @@ The option -Og has been added to optimiz
 For now, this option is exactly the same as -O1. However, in the future,
 some other optimizations might be enabled or disabled.
 
+The option -MJ has been added to simplify adding JSON compilation
+database output into existing build systems.
 
 The option 
 


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

r292119 - Ensure that clang -pthread creates the right macro. -D_POSIX_THREADS

[Joerg Sonnenberger via cfe-commits]

Author: joerg
Date: Mon Jan 16 08:07:24 2017
New Revision: 292119

URL: http://llvm.org/viewvc/llvm-project?rev=292119&view=rev
Log:
Ensure that clang -pthread creates the right macro. -D_POSIX_THREADS
seems to have been a C&P error from old GCC specs for OpenBSD.

Modified:
cfe/trunk/lib/Basic/Targets.cpp
cfe/trunk/test/Driver/netbsd.c

Modified: cfe/trunk/lib/Basic/Targets.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=292119&r1=292118&r2=292119&view=diff
==
--- cfe/trunk/lib/Basic/Targets.cpp (original)
+++ cfe/trunk/lib/Basic/Targets.cpp Mon Jan 16 08:07:24 2017
@@ -512,7 +512,7 @@ protected:
 Builder.defineMacro("__unix__");
 Builder.defineMacro("__ELF__");
 if (Opts.POSIXThreads)
-  Builder.defineMacro("_POSIX_THREADS");
+  Builder.defineMacro("_REENTRANT");
 
 switch (Triple.getArch()) {
 default:

Modified: cfe/trunk/test/Driver/netbsd.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/netbsd.c?rev=292119&r1=292118&r2=292119&view=diff
==
--- cfe/trunk/test/Driver/netbsd.c (original)
+++ cfe/trunk/test/Driver/netbsd.c Mon Jan 16 08:07:24 2017
@@ -126,6 +126,8 @@
 // RUN: %clang -no-canonical-prefixes -target powerpc64--netbsd -static \
 // RUN: --sysroot=%S/Inputs/basic_netbsd_tree %s -### 2>&1 \
 // RUN: | FileCheck -check-prefix=S-POWERPC64 %s
+// RUN: %clang -target x86_64--netbsd -pthread -dM -E %s \
+// RUN: | FileCheck -check-prefix=PTHREAD %s
 
 // STATIC: ld{{.*}}" "--eh-frame-hdr"
 // STATIC-NOT: "-pie"
@@ -427,3 +429,7 @@
 // S-POWERPC64: "{{.*}}/usr/lib{{/|}}crti.o"
 // S-POWERPC64: "{{.*}}/usr/lib{{/|}}crtbegin.o" "{{.*}}.o" "-lc"
 // S-POWERPC64: "{{.*}}/usr/lib{{/|}}crtend.o" 
"{{.*}}/usr/lib{{/|}}crtn.o"
+
+// PTHREAD-NOT: _POSIX_THREADS
+// PTHREAD: _REENTRANT
+// PTHREAD-NOT: _POSIX_THREADS


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

[libcxx] r294585 - Use protected name for the prototype arguments.

[Joerg Sonnenberger via cfe-commits]

Author: joerg
Date: Thu Feb  9 08:12:29 2017
New Revision: 294585

URL: http://llvm.org/viewvc/llvm-project?rev=294585&view=rev
Log:
Use protected name for the prototype arguments.

Modified:
libcxx/trunk/include/__threading_support
libcxx/trunk/include/thread

Modified: libcxx/trunk/include/__threading_support
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__threading_support?rev=294585&r1=294584&r2=294585&view=diff
==
--- libcxx/trunk/include/__threading_support (original)
+++ libcxx/trunk/include/__threading_support Thu Feb  9 08:12:29 2017
@@ -184,7 +184,7 @@ _LIBCPP_THREAD_ABI_VISIBILITY
 void __libcpp_thread_yield();
 
 _LIBCPP_THREAD_ABI_VISIBILITY
-void __libcpp_thread_sleep_for(const chrono::nanoseconds& ns);
+void __libcpp_thread_sleep_for(const chrono::nanoseconds& __ns);
 
 // Thread local storage
 _LIBCPP_THREAD_ABI_VISIBILITY

Modified: libcxx/trunk/include/thread
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/thread?rev=294585&r1=294584&r2=294585&view=diff
==
--- libcxx/trunk/include/thread (original)
+++ libcxx/trunk/include/thread Thu Feb  9 08:12:29 2017
@@ -424,7 +424,7 @@ void swap(thread& __x, thread& __y) _NOE
 namespace this_thread
 {
 
-_LIBCPP_FUNC_VIS void sleep_for(const chrono::nanoseconds& ns);
+_LIBCPP_FUNC_VIS void sleep_for(const chrono::nanoseconds& __ns);
 
 template 
 void


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