[cfe-dev] Random small issues

[Timo Sirainen]

On Sat, 2008-10-18 at 19:19 -0700, Daniel Dunbar wrote:
> Thanks for the reports Timo!
> 
> On Sat, Oct 18, 2008 at 1:05 PM, Timo Sirainen <tss at iki.fi> wrote:
>         I tried compiling Dovecot using clang. The blocker problem was
>         that
>         va_arg() isn't implemented. Other than that there are a few
>         other small
>         issues:
> 
> 
> va_arg of structures, I presume? va_arg should sort of work for other
> things. 

No. Looks like this is again a difference between OS X and Debian. This
assert-crashes llc on Debian:

#include <stdarg.h>
void foo(const char *fmt, va_list va) {
	va_arg(va, int);
}
int main(int argc, char *argv[]) { return 0; }

llc: X86ISelLowering.cpp:5453: llvm::SDValue
llvm::X86TargetLowering::LowerVAARG(llvm::SDValue, llvm::SelectionDAG&):
Assertion `0 && "VAArgInst is not yet implemented for x86-64!"' failed.

Since it's an assert which says this isn't implemented, I thought it
wasn't implemented anywhere.. If I make foo static, it works. Backtrace
shows:

#2  0x00007f1b31110dc9 in __assert_fail () from /lib/libc.so.6
#3  0x0000000000bbc9b2 in llvm::X86TargetLowering::LowerVAARG
(this=0x15cde78, 
    Op={Node = 0x15e1068, ResNo = 0}, DAG=@0x15e0450)
    at X86ISelLowering.cpp:5453
#4  0x0000000000be5ac1 in llvm::X86TargetLowering::LowerOperation (
    this=0x15cde78, Op={Node = 0x15e1068, ResNo = 0}, DAG=@0x15e0450)
    at X86ISelLowering.cpp:6134
#5  0x0000000000d40f4d in LegalizeOp (this=0x7fff3a217f70, Op=
      {Node = 0x15e1068, ResNo = 0}) at LegalizeDAG.cpp:3296
#6  0x0000000000d60cb4 in HandleOp (this=0x7fff3a217f70, Op=
      {Node = 0x15e1068, ResNo = 0}) at LegalizeDAG.cpp:412
#7  0x0000000000d60ebd in LegalizeDAG (this=0x7fff3a217f70)
    at LegalizeDAG.cpp:291
#8  0x0000000000d60fdf in llvm::SelectionDAG::Legalize (this=0x15e0450)
    at LegalizeDAG.cpp:7415
#9  0x0000000000d0553d in llvm::SelectionDAGISel::CodeGenAndEmitDAG (
    this=0x15df5f0) at SelectionDAGISel.cpp:598
#10 0x0000000000d079ba in llvm::SelectionDAGISel::SelectBasicBlock (
    this=0x15df5f0, LLVMBB=0x15cb0f0, Begin=
      {<bidirectional_iterator<llvm::Instruction, long int>> =
{<std::iterator<std::bidirectional_iterator_tag, llvm::Instruction, long
int, llvm::Instruction*, llvm::Instruction&>> = {<No data fields>}, <No
data fields>}, NodePtr = 0x15cc1e8}, End=
      {<bidirectional_iterator<llvm::Instruction, long int>> =
{<std::iterator<std::bidirectional_iterator_tag, llvm::Instruction, long
int, llvm::Instruction*, llvm::Instruction&>> = {<No data fields>}, <No
data fields>}, NodePtr = 0x15cc240}) at SelectionDAGISel.cpp:488
#11 0x0000000000d08331 in llvm::SelectionDAGISel::SelectAllBasicBlocks (
    this=0x15df5f0, Fn=@0x15cbfc0, MF=@0x15f75f0, MMI=0x15ef730, 
    TII=@0x15cdd58) at SelectionDAGISel.cpp:826
#12 0x0000000000d09042 in llvm::SelectionDAGISel::runOnFunction (
    this=0x15df5f0, Fn=@0x15cbfc0) at SelectionDAGISel.cpp:317
#13 0x0000000000f7b1fd in llvm::FPPassManager::runOnFunction
(this=0x15ccc00, 
    F=@0x15cbfc0) at PassManager.cpp:1321
#14 0x0000000000f7bd40 in llvm::FunctionPassManagerImpl::run
(this=0x15cc660, 
    F=@0x15cbfc0) at PassManager.cpp:1279
#15 0x0000000000f7be9e in llvm::FunctionPassManager::run
(this=0x7fff3a2186a0, 
    F=@0x15cbfc0) at PassManager.cpp:1224
#16 0x0000000000801508 in main (argc=1, argv=0x7fff3a2188c8) at
llc.cpp:313

>         1. automake's dependency tracking doesn't work with ccc for
>         some reason.
>         It always recompiles everything. I didn't bother trying to
>         figure out
>         why.
> 
> 
> I'm not sure what "automake's dependency tracking" translates to.
> clang/ccc doesn't support -MM and friends yet, http://llvm.org/PR2618,
> which could very well be the problem.

Looks like configure doesn't detect any usable way to track dependencies
so it sets depmode=none. Maybe the -MM would help.

> Fixed here:
> http://llvm.org/viewvc/llvm-project?view=rev&revision=57778,
> confirmation appreciated.

Works.
 
>         // clang gives a warning, gcc doesn't. I guess gcc figures out
>         that
>         // a format argument is going in so it should also be coming
>         out.
>         // That's how I also prefer it (unless there's another way to
>         // prevent the warning?)
>         static const char * __attribute__((format_arg(1)))
>         printf_format_fix(const char *format)
>         {
>                // maybe modify format
>                return format;
>         }
>         
>         int main(void) {
>                printf(printf_format_fix("%s"), "hello");
>                return 0;
>         }
> 
> 
> Honestly I'm not sure what is going on here. Note that by default
> clang applies more stringent default warnings than (my) gcc, however I
> do see gcc as not warning on this code. Feel free to file a bug on
> this, but I'm not really sure what the desired behavior is.

I wouldn't mind if clang did things differently, just as long as there
was some way to avoid this warning. Like perhaps a new attribute that
said the return value was a safe format string.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20081019/baf1ad53/attachment.sig>