dylanmckay marked 3 inline comments as done.
dylanmckay added a comment.

> I'm not certain if it will be possible to devise test cases for the two 
> diagnostics I pointed out or not

I don't think it will be. The compile warning logic works by directly querying 
the physical filesystem using the `llvm::sys::fs` APIs 
<http://llvm.org/doxygen/namespacellvm_1_1sys_1_1fs.html>, which don't appear 
to support mocking or virtual filesystems. The only way for the pragmatically 
trigger the warnings is to dangerously manipulate the filesystem, potentially 
destroying the user's avr-gcc installation.

> I don't know enough about AVR to sign off on whether the patch logic is 
> correct or not.

I've added some review comments to the AVR logic referencing the GCC manual and 
how this patch matches it. I've also added the only two LLVM reviewers I know 
have AVR experience so hopefully they will be able to comment on the accuracy 
of the AVR logic.



================
Comment at: lib/Driver/ToolChains/AVR.cpp:35
+  return llvm::StringSwitch<llvm::Optional<StringRef>>(MCU)
+      .Case("atmega328", Optional<StringRef>("avr5"))
+      .Case("atmega328p", Optional<StringRef>("avr5"))
----------------
Here is the avr-gcc list of devices and their architectures

`atmega328` and `atmega328p` are a part of the `avr5` family.

> avr5
>
>    “Enhanced” devices with 16 KiB up to 64 KiB of program memory.
>    mcu = ata5702m322, ata5782, ata5790, ata5790n, ata5791, ata5795, ata5831, 
> ata6613c, ata6614q, ata8210, ata8510, atmega16, atmega16a, atmega16hva, 
> atmega16hva2, atmega16hvb, atmega16hvbrevb, atmega16m1, atmega16u4, 
> atmega161, atmega162, atmega163, atmega164a, atmega164p, atmega164pa, 
> atmega165, atmega165a, atmega165p, atmega165pa, atmega168, atmega168a, 
> atmega168p, atmega168pa, atmega168pb, atmega169, atmega169a, atmega169p, 
> atmega169pa, atmega32, atmega32a, atmega32c1, atmega32hvb, atmega32hvbrevb, 
> atmega32m1, atmega32u4, atmega32u6, atmega323, atmega324a, atmega324p, 
> atmega324pa, atmega325, atmega325a, atmega325p, atmega325pa, atmega3250, 
> atmega3250a, atmega3250p, atmega3250pa, atmega328, atmega328p, atmega328pb, 
> atmega329, atmega329a, atmega329p, atmega329pa, atmega3290, atmega3290a, 
> atmega3290p, atmega3290pa, atmega406, atmega64, atmega64a, atmega64c1, 
> atmega64hve, atmega64hve2, atmega64m1, atmega64rfr2, atmega640, atmega644, 
> atmega644a, atmega644p, atmega644pa, atmega644rfr2, atmega645, atmega645a, 
> atmega645p, atmega6450, atmega6450a, atmega6450p, atmega649, atmega649a, 
> atmega649p, atmega6490, atmega6490a, atmega6490p, at90can32, at90can64, 
> at90pwm161, at90pwm216, at90pwm316, at90scr100, at90usb646, at90usb647, 
> at94k, m3000.


https://gcc.gnu.org/onlinedocs/gcc/AVR-Options.html


================
Comment at: lib/Driver/ToolChains/AVR.cpp:139
+    // Add the link library specific to the MCU.
+    CmdArgs.push_back(Args.MakeArgString(std::string("-l") + CPU));
+
----------------
Here is the avr-gcc manual documenting the filename of this particular 
libary[1].

> Options:
>
> -nodevicelib
>
>     Don’t link against AVR-LibC’s device specific library lib<mcu>.a. 

This patch follows the same conventions as avr-gcc and thus can link the same 
libraries as avr-gcc.

[1] - https://gcc.gnu.org/onlinedocs/gcc/AVR-Options.html


================
Comment at: lib/Driver/ToolChains/AVR.cpp:143
+    // This is almost always required because otherwise avr-ld
+    // will assume 'avr2' and warn about the program being larger
+    // than the bare minimum supports.
----------------
This is an existing piece of avr-gcc logic also implemented by the LLVM AVR 
backend


> -mmcu=mcu
>
>    Specify Atmel AVR instruction set architectures (ISA) or MCU type. 
> The default for this option is ‘avr2’. 

https://gcc.gnu.org/onlinedocs/gcc/AVR-Options.html


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D54334/new/

https://reviews.llvm.org/D54334



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

Reply via email to