[PATCH] D27123: Add AVR target and toolchain to Clang

2017-01-04 Thread Dylan McKay via Phabricator via cfe-commits 
This revision was automatically updated to reflect the committed changes.
Closed by commit rL291082: Add AVR target and toolchain to Clang (authored by 
dylanmckay).

Changed prior to commit:
  https://reviews.llvm.org/D27123?vs=80721=83191#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D27123

Files:
  cfe/trunk/lib/Basic/Targets.cpp
  cfe/trunk/lib/Driver/Driver.cpp
  cfe/trunk/lib/Driver/ToolChains.cpp
  cfe/trunk/lib/Driver/ToolChains.h
  cfe/trunk/lib/Driver/Tools.cpp
  cfe/trunk/lib/Driver/Tools.h
  cfe/trunk/test/Driver/avr-toolchain.c
  cfe/trunk/test/Preprocessor/init.c

Index: cfe/trunk/lib/Driver/ToolChains.h
===
--- cfe/trunk/lib/Driver/ToolChains.h
+++ cfe/trunk/lib/Driver/ToolChains.h
@@ -1349,6 +1349,16 @@
   SanitizerMask getSupportedSanitizers() const override;
 };
 
+class LLVM_LIBRARY_VISIBILITY AVRToolChain : public Generic_ELF {
+protected:
+  Tool *buildLinker() const override;
+public:
+  AVRToolChain(const Driver , const llvm::Triple ,
+   const llvm::opt::ArgList );
+  bool IsIntegratedAssemblerDefault() const override { return true; }
+};
+
+
 } // end namespace toolchains
 } // end namespace driver
 } // end namespace clang
Index: cfe/trunk/lib/Driver/Tools.h
===
--- cfe/trunk/lib/Driver/Tools.h
+++ cfe/trunk/lib/Driver/Tools.h
@@ -990,6 +990,19 @@
 
 }  // end namespace NVPTX
 
+namespace AVR {
+class LLVM_LIBRARY_VISIBILITY Linker : public GnuTool {
+public:
+  Linker(const ToolChain ) : GnuTool("AVR::Linker", "avr-ld", TC) {}
+  bool hasIntegratedCPP() const override { return false; }
+  bool isLinkJob() const override { return true; }
+  void ConstructJob(Compilation , const JobAction ,
+const InputInfo , const InputInfoList ,
+const llvm::opt::ArgList ,
+const char *LinkingOutput) const override;
+};
+} // end namespace AVR
+
 } // end namespace tools
 } // end namespace driver
 } // end namespace clang
Index: cfe/trunk/lib/Driver/ToolChains.cpp
===
--- cfe/trunk/lib/Driver/ToolChains.cpp
+++ cfe/trunk/lib/Driver/ToolChains.cpp
@@ -5318,3 +5318,12 @@
 Res |= SanitizerKind::SafeStack;
   return Res;
 }
+
+/// AVR Toolchain
+AVRToolChain::AVRToolChain(const Driver , const llvm::Triple ,
+   const ArgList )
+  : Generic_ELF(D, Triple, Args) { }
+Tool *AVRToolChain::buildLinker() const {
+  return new tools::AVR::Linker(*this);
+}
+// End AVR
Index: cfe/trunk/lib/Driver/Tools.cpp
===
--- cfe/trunk/lib/Driver/Tools.cpp
+++ cfe/trunk/lib/Driver/Tools.cpp
@@ -12191,3 +12191,19 @@
   const char *Exec = Args.MakeArgString(TC.GetProgramPath("fatbinary"));
   C.addCommand(llvm::make_unique(JA, *this, Exec, CmdArgs, Inputs));
 }
+
+void AVR::Linker::ConstructJob(Compilation , const JobAction ,
+   const InputInfo ,
+   const InputInfoList ,
+   const ArgList ,
+   const char *LinkingOutput) const {
+
+  std::string Linker = getToolChain().GetProgramPath(getShortName());
+  ArgStringList CmdArgs;
+  AddLinkerInputs(getToolChain(), Inputs, Args, CmdArgs, JA);
+  CmdArgs.push_back("-o");
+  CmdArgs.push_back(Output.getFilename());
+  C.addCommand(llvm::make_unique(JA, *this, Args.MakeArgString(Linker),
+  CmdArgs, Inputs));
+}
+// AVR tools end.
Index: cfe/trunk/lib/Driver/Driver.cpp
===
--- cfe/trunk/lib/Driver/Driver.cpp
+++ cfe/trunk/lib/Driver/Driver.cpp
@@ -3764,6 +3764,9 @@
   case llvm::Triple::wasm64:
 TC = new toolchains::WebAssembly(*this, Target, Args);
 break;
+  case llvm::Triple::avr:
+TC = new toolchains::AVRToolChain(*this, Target, Args);
+break;
   default:
 if (Target.getVendor() == llvm::Triple::Myriad)
   TC = new toolchains::MyriadToolChain(*this, Target, Args);
Index: cfe/trunk/lib/Basic/Targets.cpp
===
--- cfe/trunk/lib/Basic/Targets.cpp
+++ cfe/trunk/lib/Basic/Targets.cpp
@@ -8385,6 +8385,97 @@
   }
 };
 
+
+// AVR Target
+class AVRTargetInfo : public TargetInfo {
+public:
+  AVRTargetInfo(const llvm::Triple , const TargetOptions &)
+  : TargetInfo(Triple) {
+TLSSupported = false;
+PointerWidth = 16;
+PointerAlign = 8;
+IntWidth = 16;
+IntAlign = 8;
+LongWidth = 32;
+LongAlign = 8;
+LongLongWidth = 64;
+LongLongAlign = 8;
+SuitableAlign = 8;
+DefaultAlignForAttributeAligned = 8;
+HalfWidth = 16;
+HalfAlign = 8;
+FloatWidth = 32;
+FloatAlign = 8;
+DoubleWidth = 32;
+DoubleAlign = 8;
+DoubleFormat =

[PATCH] D27123: Add AVR target and toolchain to Clang

2017-01-04 Thread Dylan McKay via Phabricator via cfe-commits 
dylanmckay added a comment.

Signed off by Jonathan Roelofs via cfe-commits


https://reviews.llvm.org/D27123



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

Re: [PATCH] D27123: Add AVR target and toolchain to Clang

2017-01-04 Thread Dylan McKay via cfe-commits 
I've just raised a bug here

https://llvm.org/bugs/show_bug.cgi?id=31530

> What's necessary for sign-off? Should I ping the reviewer (Richard Smith)
again?

I think so long as Richard or someone else who actively works on Clang
signs off. Perhaps somebody else is keen to review?

On the other hand, I can review it and then ask if there aren't any
objections to it being in-tree within a few days, I can commit it.

On Wed, Jan 4, 2017 at 7:20 PM, Senthil Kumar Selvaraj <
senthilkumar.selva...@microchip.com> wrote:

>
> Dylan McKay writes:
>
> > Did you get the BugZilla account sorted Senthil?
>
> Nope, direct email also didn't help. Can you please file a bug with
>
> Title:
>
> UINT16_TYPE and INT16_TYPE are defined as short instead of int for AVR
>
> Description:
>
>UINT16_TYPE and INT16_TYPE are implicitly defined by the preprocessor
>to the short type, rather than int. While shorts and ints are both
>16 bits wide on the avr, gcc picks ints to represent 16 bits wherever
>possible, and picking short can cause issues with C++ name mangling
>(see https://reviews.llvm.org/D27123#615854). Therefore, clang should
>define the two types to short.
>
>Clang's lib/Frontend/InitPreprocessor.cpp::DefineExactWidthIntType
> does not
>use TargetInfo::getIntTypeByWidth. Instead,
>InitializePredefinedMacros calls
>the function with the specific type (SignedShort/UnsignedShort), because
>getShortWidth() > getCharWidth(), but getIntWidth() ==
>getShortWidth().
>
>
> What's necessary for sign-off? Should I ping the reviewer (Richard Smith)
> again?
>
> Regards
> Senthil
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D27123: Add AVR target and toolchain to Clang

2017-01-04 Thread Dylan McKay via cfe-commits 
Did you get the BugZilla account sorted Senthil?

On Thu, Dec 22, 2016 at 10:47 AM, Nico Weber  wrote:

> On Wed, Dec 21, 2016 at 6:42 AM, Senthil Kumar Selvaraj via Phabricator
> via cfe-commits  wrote:
>
>> saaadhu added a comment.
>>
>> Would someone with a llvm bugzilla account please file the PR for me? New
>> user registration is disabled, and I've been waiting for
>> llvm-ad...@lists.llvm.org to respond for nearly a week now.
>>
>
> Email to...@nondot.org directly, see http://lists.llvm.org/
> pipermail/cfe-dev/2016-December/051921.html
>
>
>>
>> And how should I proceed after that? Would one of the reviewers commit
>> the patch for me?
>>
>>
>> https://reviews.llvm.org/D27123
>>
>>
>>
>> ___
>> 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

Re: [PATCH] D27123: Add AVR target and toolchain to Clang

2017-01-04 Thread Jonathan Roelofs via cfe-commits 



On 1/4/17 2:52 AM, Dylan McKay wrote:

I've just raised a bug here

https://llvm.org/bugs/show_bug.cgi?id=31530

> What's necessary for sign-off? Should I ping the reviewer (Richard 
Smith) again?


I think so long as Richard or someone else who actively works on Clang 
signs off. Perhaps somebody else is keen to review?


On the other hand, I can review it and then ask if there aren't any 
objections to it being in-tree within a few days, I can commit it.


LGTM


Jon



On Wed, Jan 4, 2017 at 7:20 PM, Senthil Kumar Selvaraj 
> wrote:



Dylan McKay writes:

> Did you get the BugZilla account sorted Senthil?

Nope, direct email also didn't help. Can you please file a bug with

Title:

UINT16_TYPE and INT16_TYPE are defined as short instead of int for AVR

Description:

   UINT16_TYPE and INT16_TYPE are implicitly defined by the
preprocessor
   to the short type, rather than int. While shorts and ints are both
   16 bits wide on the avr, gcc picks ints to represent 16 bits
wherever
   possible, and picking short can cause issues with C++ name mangling
   (see https://reviews.llvm.org/D27123#615854
). Therefore, clang should
   define the two types to short.

   Clang's
lib/Frontend/InitPreprocessor.cpp::DefineExactWidthIntType does not
   use TargetInfo::getIntTypeByWidth. Instead,
   InitializePredefinedMacros calls
   the function with the specific type
(SignedShort/UnsignedShort), because
   getShortWidth() > getCharWidth(), but getIntWidth() ==
   getShortWidth().


What's necessary for sign-off? Should I ping the reviewer (Richard
Smith) again?

Regards
Senthil




--
Jon Roelofs
jonat...@codesourcery.com
CodeSourcery / Mentor Embedded

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

Re: [PATCH] D27123: Add AVR target and toolchain to Clang

2017-01-03 Thread Senthil Kumar Selvaraj via cfe-commits 

Dylan McKay writes:

> Did you get the BugZilla account sorted Senthil?

Nope, direct email also didn't help. Can you please file a bug with

Title:

UINT16_TYPE and INT16_TYPE are defined as short instead of int for AVR

Description:

   UINT16_TYPE and INT16_TYPE are implicitly defined by the preprocessor
   to the short type, rather than int. While shorts and ints are both
   16 bits wide on the avr, gcc picks ints to represent 16 bits wherever
   possible, and picking short can cause issues with C++ name mangling
   (see https://reviews.llvm.org/D27123#615854). Therefore, clang should
   define the two types to short.

   Clang's lib/Frontend/InitPreprocessor.cpp::DefineExactWidthIntType does not
   use TargetInfo::getIntTypeByWidth. Instead,
   InitializePredefinedMacros calls
   the function with the specific type (SignedShort/UnsignedShort), because
   getShortWidth() > getCharWidth(), but getIntWidth() ==
   getShortWidth().


What's necessary for sign-off? Should I ping the reviewer (Richard Smith) again?

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

Re: [PATCH] D27123: Add AVR target and toolchain to Clang

2016-12-21 Thread Nico Weber via cfe-commits 
On Wed, Dec 21, 2016 at 6:42 AM, Senthil Kumar Selvaraj via Phabricator via
cfe-commits  wrote:

> saaadhu added a comment.
>
> Would someone with a llvm bugzilla account please file the PR for me? New
> user registration is disabled, and I've been waiting for
> llvm-ad...@lists.llvm.org to respond for nearly a week now.
>

Email to...@nondot.org directly, see
http://lists.llvm.org/pipermail/cfe-dev/2016-December/051921.html


>
> And how should I proceed after that? Would one of the reviewers commit the
> patch for me?
>
>
> https://reviews.llvm.org/D27123
>
>
>
> ___
> 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

Re: [PATCH] D27123: Add AVR target and toolchain to Clang

2016-12-21 Thread Dylan McKay via cfe-commits 
I'm happy to file a bug if you give me a description

> Would one of the reviewers commit the patch for me?

I'm happy to commit it, so long as somebody else signs off on it.

On Thu, Dec 22, 2016 at 12:42 AM, Senthil Kumar Selvaraj via Phabricator <
revi...@reviews.llvm.org> wrote:

> saaadhu added a comment.
>
> Would someone with a llvm bugzilla account please file the PR for me? New
> user registration is disabled, and I've been waiting for
> llvm-ad...@lists.llvm.org to respond for nearly a week now.
>
> And how should I proceed after that? Would one of the reviewers commit the
> patch for me?
>
>
> https://reviews.llvm.org/D27123
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D27123: Add AVR target and toolchain to Clang

2016-12-21 Thread Senthil Kumar Selvaraj via Phabricator via cfe-commits 
saaadhu added a comment.

Would someone with a llvm bugzilla account please file the PR for me? New user 
registration is disabled, and I've been waiting for llvm-ad...@lists.llvm.org 
to respond for nearly a week now.

And how should I proceed after that? Would one of the reviewers commit the 
patch for me?


https://reviews.llvm.org/D27123



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

[PATCH] D27123: Add AVR target and toolchain to Clang

2016-12-14 Thread Jonathan Roelofs via Phabricator via cfe-commits 
jroelofs added a comment.

In https://reviews.llvm.org/D27123#617118, @jroelofs wrote:

> In https://reviews.llvm.org/D27123#616887, @saaadhu wrote:
>
> > Make defines for CHAR16_TYPE, {U,}INT_{LEAST,FAST}16_TYPE use int instead 
> > of short.
> >
> > {U,}INT16_TYPE still gets defined as short though - 
> > lib/Frontend/InitPreprocessor.cpp::DefineExactWidthIntType does not use 
> > TargetInfo::getIntTypeByWidth. Instead, InitializePredefinedMacros calls 
> > the function with the specific type (SignedShort/UnsignedShort), as 
> > getShortWidth() > getCharWidth(), but getIntWidth() == getShortWidth(). Not 
> > sure what the best way to fix that is - should I make DefineExactWidthType 
> > use TargetInfo::getIntTypeByWidth?
>


If you do, it might break other things. Might be better to leave this alone, 
and leave a comment with a PR for it, explaining where the differences are.

> I'm not sure either. I think it's a good question for @rengolin.




https://reviews.llvm.org/D27123



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

[PATCH] D27123: Add AVR target and toolchain to Clang

2016-12-14 Thread Renato Golin via Phabricator via cfe-commits 
rengolin added a comment.

In https://reviews.llvm.org/D27123#617118, @jroelofs wrote:

> In https://reviews.llvm.org/D27123#616887, @saaadhu wrote:
>
> > Make defines for CHAR16_TYPE, {U,}INT_{LEAST,FAST}16_TYPE use int instead 
> > of short.
> >
> > {U,}INT16_TYPE still gets defined as short though - 
> > lib/Frontend/InitPreprocessor.cpp::DefineExactWidthIntType does not use 
> > TargetInfo::getIntTypeByWidth. Instead, InitializePredefinedMacros calls 
> > the function with the specific type (SignedShort/UnsignedShort), as 
> > getShortWidth() > getCharWidth(), but getIntWidth() == getShortWidth(). Not 
> > sure what the best way to fix that is - should I make DefineExactWidthType 
> > use TargetInfo::getIntTypeByWidth?
>
>
> I'm not sure either. I think it's a good question for @rengolin.


Hum, sorry, can't answer that one. :)

I find it confusing that you define `CHAR16` as `int` and `INT16` as `short`, 
with whatever `INT_FAST16` is as `int`.

I don't know much about AVR, but the C standard predicts that `short` and `int` 
can have the same size, so Clang should be able to cope with it.

cheers,
--renato




Comment at: lib/Basic/Targets.cpp:8543
+  case llvm::Triple::avr:
+return new AVRTargetInfo(Triple, Opts);
   case llvm::Triple::bpfeb:

dylanmckay wrote:
> If we build clang without `LLVM_EXPERIMENTAL_TARGETS_TO_BUILD=AVR`, how will 
> this work?
> 
> Will it fail compilation? Will `clang` report that AVR is supported? Will it 
> crash if you try and run `clang`?
AFAIK, Clang support for targets is independent of LLVM. A standard Clang build 
supports all targets up to LLVM IR (so all ABIs, PCSs, type descriptions, 
etc.), but it will fail if the back-end is not available and Clang is invoked 
beyond IR.

This is why we can only have IR tests in Clang. As long as all your tests stop 
at IR, this should be fine.


https://reviews.llvm.org/D27123



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

[PATCH] D27123: Add AVR target and toolchain to Clang

2016-12-10 Thread Dylan McKay via Phabricator via cfe-commits 
dylanmckay added inline comments.



Comment at: lib/Basic/Targets.cpp:8543
+  case llvm::Triple::avr:
+return new AVRTargetInfo(Triple, Opts);
   case llvm::Triple::bpfeb:

If we build clang without `LLVM_EXPERIMENTAL_TARGETS_TO_BUILD=AVR`, how will 
this work?

Will it fail compilation? Will `clang` report that AVR is supported? Will it 
crash if you try and run `clang`?


https://reviews.llvm.org/D27123



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

[PATCH] D27123: Add AVR target and toolchain to Clang

2016-12-08 Thread Jonathan Roelofs via Phabricator via cfe-commits 
jroelofs added a subscriber: rengolin.
jroelofs added a comment.

In https://reviews.llvm.org/D27123#616887, @saaadhu wrote:

> Make defines for CHAR16_TYPE, {U,}INT_{LEAST,FAST}16_TYPE use int instead of 
> short.
>
> {U,}INT16_TYPE still gets defined as short though - 
> lib/Frontend/InitPreprocessor.cpp::DefineExactWidthIntType does not use 
> TargetInfo::getIntTypeByWidth. Instead, InitializePredefinedMacros calls the 
> function with the specific type (SignedShort/UnsignedShort), as 
> getShortWidth() > getCharWidth(), but getIntWidth() == getShortWidth(). Not 
> sure what the best way to fix that is - should I make DefineExactWidthType 
> use TargetInfo::getIntTypeByWidth?


I'm not sure either. I think it's a good question for @rengolin.


https://reviews.llvm.org/D27123



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

[PATCH] D27123: Add AVR target and toolchain to Clang

2016-12-07 Thread Senthil Kumar Selvaraj via Phabricator via cfe-commits 
saaadhu updated this revision to Diff 80721.
saaadhu added a comment.

Make defines for CHAR16_TYPE, {U,}INT_{LEAST,FAST}16_TYPE use int instead of 
short.

{U,}INT16_TYPE still gets defined as short though - 
lib/Frontend/InitPreprocessor.cpp::DefineExactWidthIntType does not use 
TargetInfo::getIntTypeByWidth. Instead, InitializePredefinedMacros calls the 
function with the specific type (SignedShort/UnsignedShort), as getShortWidth() 
> getCharWidth(), but getIntWidth() == getShortWidth(). Not sure what the best 
way to fix that is - should I make DefineExactWidthType use 
TargetInfo::getIntTypeByWidth?


https://reviews.llvm.org/D27123

Files:
  lib/Basic/Targets.cpp
  lib/Driver/Driver.cpp
  lib/Driver/ToolChains.cpp
  lib/Driver/ToolChains.h
  lib/Driver/Tools.cpp
  lib/Driver/Tools.h
  test/Driver/avr-toolchain.c
  test/Preprocessor/init.c

Index: test/Preprocessor/init.c
===
--- test/Preprocessor/init.c
+++ test/Preprocessor/init.c
@@ -9189,3 +9189,174 @@
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple x86_64-windows-cygnus < /dev/null | FileCheck -match-full-lines -check-prefix CYGWIN-X64 %s
 // CYGWIN-X64: #define __USER_LABEL_PREFIX__
 
+// RUN: %clang_cc1 -E -dM -ffreestanding -triple=avr \
+// RUN:   < /dev/null \
+// RUN:   | FileCheck -match-full-lines -check-prefix=AVR %s
+//
+// AVR:#define __ATOMIC_ACQUIRE 2
+// AVR:#define __ATOMIC_ACQ_REL 4
+// AVR:#define __ATOMIC_CONSUME 1
+// AVR:#define __ATOMIC_RELAXED 0
+// AVR:#define __ATOMIC_RELEASE 3
+// AVR:#define __ATOMIC_SEQ_CST 5
+// AVR:#define __AVR__ 1
+// AVR:#define __BIGGEST_ALIGNMENT__ 1
+// AVR:#define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
+// AVR:#define __CHAR16_TYPE__ unsigned int
+// AVR:#define __CHAR32_TYPE__ long unsigned int
+// AVR:#define __CHAR_BIT__ 8
+// AVR:#define __DBL_DECIMAL_DIG__ 9
+// AVR:#define __DBL_DENORM_MIN__ 1.40129846e-45
+// AVR:#define __DBL_DIG__ 6
+// AVR:#define __DBL_EPSILON__ 1.19209290e-7
+// AVR:#define __DBL_HAS_DENORM__ 1
+// AVR:#define __DBL_HAS_INFINITY__ 1
+// AVR:#define __DBL_HAS_QUIET_NAN__ 1
+// AVR:#define __DBL_MANT_DIG__ 24
+// AVR:#define __DBL_MAX_10_EXP__ 38
+// AVR:#define __DBL_MAX_EXP__ 128
+// AVR:#define __DBL_MAX__ 3.40282347e+38
+// AVR:#define __DBL_MIN_10_EXP__ (-37)
+// AVR:#define __DBL_MIN_EXP__ (-125)
+// AVR:#define __DBL_MIN__ 1.17549435e-38
+// AVR:#define __FINITE_MATH_ONLY__ 0
+// AVR:#define __FLT_DECIMAL_DIG__ 9
+// AVR:#define __FLT_DENORM_MIN__ 1.40129846e-45F
+// AVR:#define __FLT_DIG__ 6
+// AVR:#define __FLT_EPSILON__ 1.19209290e-7F
+// AVR:#define __FLT_EVAL_METHOD__ 0
+// AVR:#define __FLT_HAS_DENORM__ 1
+// AVR:#define __FLT_HAS_INFINITY__ 1
+// AVR:#define __FLT_HAS_QUIET_NAN__ 1
+// AVR:#define __FLT_MANT_DIG__ 24
+// AVR:#define __FLT_MAX_10_EXP__ 38
+// AVR:#define __FLT_MAX_EXP__ 128
+// AVR:#define __FLT_MAX__ 3.40282347e+38F
+// AVR:#define __FLT_MIN_10_EXP__ (-37)
+// AVR:#define __FLT_MIN_EXP__ (-125)
+// AVR:#define __FLT_MIN__ 1.17549435e-38F
+// AVR:#define __FLT_RADIX__ 2
+// AVR:#define __GCC_ATOMIC_BOOL_LOCK_FREE 1
+// AVR:#define __GCC_ATOMIC_CHAR16_T_LOCK_FREE 1
+// AVR:#define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 1
+// AVR:#define __GCC_ATOMIC_CHAR_LOCK_FREE 1
+// AVR:#define __GCC_ATOMIC_INT_LOCK_FREE 1
+// AVR:#define __GCC_ATOMIC_LLONG_LOCK_FREE 1
+// AVR:#define __GCC_ATOMIC_LONG_LOCK_FREE 1
+// AVR:#define __GCC_ATOMIC_POINTER_LOCK_FREE 1
+// AVR:#define __GCC_ATOMIC_SHORT_LOCK_FREE 1
+// AVR:#define __GCC_ATOMIC_TEST_AND_SET_TRUEVAL 1
+// AVR:#define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 1
+// AVR:#define __GXX_ABI_VERSION 1002
+// AVR:#define __INT16_C_SUFFIX__ 
+// AVR:#define __INT16_MAX__ 32767
+// AVR:#define __INT16_TYPE__ short
+// AVR:#define __INT32_C_SUFFIX__ L
+// AVR:#define __INT32_MAX__ 2147483647L
+// AVR:#define __INT32_TYPE__ long int
+// AVR:#define __INT64_C_SUFFIX__ LL
+// AVR:#define __INT64_MAX__ 9223372036854775807LL
+// AVR:#define __INT64_TYPE__ long long int
+// AVR:#define __INT8_C_SUFFIX__ 
+// AVR:#define __INT8_MAX__ 127
+// AVR:#define __INT8_TYPE__ signed char
+// AVR:#define __INTMAX_C_SUFFIX__ LL
+// AVR:#define __INTMAX_MAX__ 9223372036854775807LL
+// AVR:#define __INTMAX_TYPE__ long long int
+// AVR:#define __INTPTR_MAX__ 32767
+// AVR:#define __INTPTR_TYPE__ int
+// AVR:#define __INT_FAST16_MAX__ 32767
+// AVR:#define __INT_FAST16_TYPE__ int
+// AVR:#define __INT_FAST32_MAX__ 2147483647L
+// AVR:#define __INT_FAST32_TYPE__ long int
+// AVR:#define __INT_FAST64_MAX__ 9223372036854775807LL
+// AVR:#define __INT_FAST64_TYPE__ long long int
+// AVR:#define __INT_FAST8_MAX__ 127
+// AVR:#define __INT_FAST8_TYPE__ signed char
+// AVR:#define __INT_LEAST16_MAX__ 32767
+// AVR:#define __INT_LEAST16_TYPE__ int
+// AVR:#define __INT_LEAST32_MAX__ 2147483647L
+// AVR:#define __INT_LEAST32_TYPE__ long int
+// AVR:#define __INT_LEAST64_MAX__ 9223372036854775807LL
+// AVR:#define __INT_LEAST64_TYPE__ long long int
+// AVR:#define __INT_LEAST8_MAX__

[PATCH] D27123: Add AVR target and toolchain to Clang

2016-12-07 Thread Jonathan Roelofs via Phabricator via cfe-commits 
jroelofs added a comment.

In https://reviews.llvm.org/D27123#615738, @saaadhu wrote:

> Thanks, setting DoubleFormat and LongDoubleFormat fixed the __DBL_ and 
> __LDBL_ differences. Also, setting SigAtomicType fixed the __SIG_ATOMIC_ 
> differences as well. I've added those defines to the test. Unrelated, but I 
> also removed a redundant set of LongLongAlign and overriding of 
> GetDefaultDwarfVersion (returning 2 wasn't necessary).
>
> The only remaining  (textually) conflicting defines between "avr-gcc -dM -E" 
> and "clang -dM -E" are
>
> 1. short vs int for a bunch of __xxx_TYPE__ defines, like say 
> __CHAR16_TYPE__. short and int are both 2 bytes for the avr, so I think 
> either one is ok.


This will bite you when it comes to C++. Those two types are mangled 
differently, so you'll get an ABI mismatch in overloads that use those typedefs.

> 2. Casts vs plain literals in the defines for double MIN, MAX values.  
> avr-gcc, for example, defines #define __DBL_MAX__ ((double)3.40282347e+38L), 
> whereas clang does  #define __DBL_MAX__ 3.40282347e+38. Again, I think this 
> shouldn't matter - I've added the literals sans the cast to the test.

That should be fine.


https://reviews.llvm.org/D27123



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

[PATCH] D27123: Add AVR target and toolchain to Clang

2016-12-07 Thread Senthil Kumar Selvaraj via Phabricator via cfe-commits 
saaadhu updated this revision to Diff 80575.
saaadhu added a comment.

Thanks, setting DoubleFormat and LongDoubleFormat fixed the __DBL_ and __LDBL_ 
differences. Also, setting SigAtomicType fixed the __SIG_ATOMIC_ differences as 
well. I've added those defines to the test. Unrelated, but I also removed a 
redundant set of LongLongAlign and overriding of GetDefaultDwarfVersion 
(returning 2 wasn't necessary).

The only remaining  (textually) conflicting defines between "avr-gcc -dM -E" 
and "clang -dM -E" are

1. short vs int for a bunch of __xxx_TYPE__ defines, like say __CHAR16_TYPE__. 
short and int are both 2 bytes for the avr, so I think either one is ok.
2. Casts vs plain literals in the defines for double MIN, MAX values.  avr-gcc, 
for example, defines #define __DBL_MAX__ ((double)3.40282347e+38L), whereas 
clang does  #define __DBL_MAX__ 3.40282347e+38. Again, I think this shouldn't 
matter - I've added the literals sans the cast to the test.


https://reviews.llvm.org/D27123

Files:
  lib/Basic/Targets.cpp
  lib/Driver/Driver.cpp
  lib/Driver/ToolChains.cpp
  lib/Driver/ToolChains.h
  lib/Driver/Tools.cpp
  lib/Driver/Tools.h
  test/Driver/avr-toolchain.c
  test/Preprocessor/init.c

Index: test/Preprocessor/init.c
===
--- test/Preprocessor/init.c
+++ test/Preprocessor/init.c
@@ -9189,3 +9189,174 @@
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple x86_64-windows-cygnus < /dev/null | FileCheck -match-full-lines -check-prefix CYGWIN-X64 %s
 // CYGWIN-X64: #define __USER_LABEL_PREFIX__
 
+// RUN: %clang_cc1 -E -dM -ffreestanding -triple=avr \
+// RUN:   < /dev/null \
+// RUN:   | FileCheck -match-full-lines -check-prefix=AVR %s
+//
+// AVR:#define __ATOMIC_ACQUIRE 2
+// AVR:#define __ATOMIC_ACQ_REL 4
+// AVR:#define __ATOMIC_CONSUME 1
+// AVR:#define __ATOMIC_RELAXED 0
+// AVR:#define __ATOMIC_RELEASE 3
+// AVR:#define __ATOMIC_SEQ_CST 5
+// AVR:#define __AVR__ 1
+// AVR:#define __BIGGEST_ALIGNMENT__ 1
+// AVR:#define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
+// AVR:#define __CHAR16_TYPE__ unsigned short
+// AVR:#define __CHAR32_TYPE__ long unsigned int
+// AVR:#define __CHAR_BIT__ 8
+// AVR:#define __DBL_DECIMAL_DIG__ 9
+// AVR:#define __DBL_DENORM_MIN__ 1.40129846e-45
+// AVR:#define __DBL_DIG__ 6
+// AVR:#define __DBL_EPSILON__ 1.19209290e-7
+// AVR:#define __DBL_HAS_DENORM__ 1
+// AVR:#define __DBL_HAS_INFINITY__ 1
+// AVR:#define __DBL_HAS_QUIET_NAN__ 1
+// AVR:#define __DBL_MANT_DIG__ 24
+// AVR:#define __DBL_MAX_10_EXP__ 38
+// AVR:#define __DBL_MAX_EXP__ 128
+// AVR:#define __DBL_MAX__ 3.40282347e+38
+// AVR:#define __DBL_MIN_10_EXP__ (-37)
+// AVR:#define __DBL_MIN_EXP__ (-125)
+// AVR:#define __DBL_MIN__ 1.17549435e-38
+// AVR:#define __FINITE_MATH_ONLY__ 0
+// AVR:#define __FLT_DECIMAL_DIG__ 9
+// AVR:#define __FLT_DENORM_MIN__ 1.40129846e-45F
+// AVR:#define __FLT_DIG__ 6
+// AVR:#define __FLT_EPSILON__ 1.19209290e-7F
+// AVR:#define __FLT_EVAL_METHOD__ 0
+// AVR:#define __FLT_HAS_DENORM__ 1
+// AVR:#define __FLT_HAS_INFINITY__ 1
+// AVR:#define __FLT_HAS_QUIET_NAN__ 1
+// AVR:#define __FLT_MANT_DIG__ 24
+// AVR:#define __FLT_MAX_10_EXP__ 38
+// AVR:#define __FLT_MAX_EXP__ 128
+// AVR:#define __FLT_MAX__ 3.40282347e+38F
+// AVR:#define __FLT_MIN_10_EXP__ (-37)
+// AVR:#define __FLT_MIN_EXP__ (-125)
+// AVR:#define __FLT_MIN__ 1.17549435e-38F
+// AVR:#define __FLT_RADIX__ 2
+// AVR:#define __GCC_ATOMIC_BOOL_LOCK_FREE 1
+// AVR:#define __GCC_ATOMIC_CHAR16_T_LOCK_FREE 1
+// AVR:#define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 1
+// AVR:#define __GCC_ATOMIC_CHAR_LOCK_FREE 1
+// AVR:#define __GCC_ATOMIC_INT_LOCK_FREE 1
+// AVR:#define __GCC_ATOMIC_LLONG_LOCK_FREE 1
+// AVR:#define __GCC_ATOMIC_LONG_LOCK_FREE 1
+// AVR:#define __GCC_ATOMIC_POINTER_LOCK_FREE 1
+// AVR:#define __GCC_ATOMIC_SHORT_LOCK_FREE 1
+// AVR:#define __GCC_ATOMIC_TEST_AND_SET_TRUEVAL 1
+// AVR:#define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 1
+// AVR:#define __GXX_ABI_VERSION 1002
+// AVR:#define __INT16_C_SUFFIX__ 
+// AVR:#define __INT16_MAX__ 32767
+// AVR:#define __INT16_TYPE__ short
+// AVR:#define __INT32_C_SUFFIX__ L
+// AVR:#define __INT32_MAX__ 2147483647L
+// AVR:#define __INT32_TYPE__ long int
+// AVR:#define __INT64_C_SUFFIX__ LL
+// AVR:#define __INT64_MAX__ 9223372036854775807LL
+// AVR:#define __INT64_TYPE__ long long int
+// AVR:#define __INT8_C_SUFFIX__ 
+// AVR:#define __INT8_MAX__ 127
+// AVR:#define __INT8_TYPE__ signed char
+// AVR:#define __INTMAX_C_SUFFIX__ LL
+// AVR:#define __INTMAX_MAX__ 9223372036854775807LL
+// AVR:#define __INTMAX_TYPE__ long long int
+// AVR:#define __INTPTR_MAX__ 32767
+// AVR:#define __INTPTR_TYPE__ int
+// AVR:#define __INT_FAST16_MAX__ 32767
+// AVR:#define __INT_FAST16_TYPE__ short
+// AVR:#define __INT_FAST32_MAX__ 2147483647L
+// AVR:#define __INT_FAST32_TYPE__ long int
+// AVR:#define __INT_FAST64_MAX__ 9223372036854775807LL
+// AVR:#define __INT_FAST64_TYPE__ long long int
+// AVR:#define __INT_FAST8_MAX__ 127
+//

[PATCH] D27123: Add AVR target and toolchain to Clang

2016-12-06 Thread Jonathan Roelofs via Phabricator via cfe-commits 
jroelofs added a comment.

In https://reviews.llvm.org/D27123#614313, @saaadhu wrote:

> Add testcases to test/Preprocessor/init.c


Awesome, thanks!

> Correct types for WChar and WInt
> 
> The ABI is documented in the avr-gcc wiki (https://gcc.gnu.org/wiki/avr-gcc)
>  I took the output of a trunk build of avr-gcc -dM -E and put that in the 
> Preprocessor/init.c testcase, removing everything clang does not define.

Good plan.

> The conflicting defines were
> 
> 1. DBL and LDBL related defines - clang appears to consider doubles as 64 bit 
> even if DoubleWidth is 32 bit

I /think/ you need to set LongDoubleFormat for that to work.

> 2. SIG_ATOMIC defines.

What are the differences there?


https://reviews.llvm.org/D27123



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