Related bugreport (no resolution)
http://www.freebsd.org/cgi/query-pr.cgi?pr=167805

gethostbyname_r is declared to take 6 arguments:

       int gethostbyname_r(const char *name,
               struct hostent *ret, char *buf, size_t buflen,
               struct hostent **result, int *h_errnop);

but it is only being passed 5 arguments:

#define my_gethostbyname_r(A,B,C,D,E) gethostbyname_r((A),(B),(C),(D),(E))           

So the clang error message "error: too few arguments to function call, expected
6, have 5" seems to be correct (no value passed for errnop).

In short, this looks like a MySQL bug.

I just nailed down that it's related to different results of checking gethostbyname style in `configure`:

In clang 3.0, the config.log snippet is:
> configure:39208: checking style of gethostbyname_r routines
> configure:39257: clang++ -use-gold-plugin -flto -c  -g -O0   -fno-implicit-templates -fno-exceptions -fno-rtti -Werror  conftest.cpp >&5
> clang: warning: argument unused during compilation: '-fno-implicit-templates'
> configure:39264: $? = 0
> configure:39279: result: glibc2
So the detection result is glibc2


But in clang 3.2, the snippet is:

> configure:39208: checking style of gethostbyname_r routines
> configure:39257: clang++ -use-gold-plugin -flto -c  -g -O0   -fno-implicit-templates -fno-exceptions -fno-rtti -Werror  conftest.cpp >&5
> clang: error: argument unused during compilation: '-fno-implicit-templates'
> configure:39264: $? = 1
> configure: failed program was:
> | /* confdefs.h.  */
> | #define PACKAGE_NAME "MySQL Server"
> | #define PACKAGE_TARNAME "mysql"
> ...
> | #define HAVE_DECL_MADVISE 1
> | /* end confdefs.h.  */
> | #undef inline
> | #if !defined(SCO) && !defined(__osf__) && !defined(_REENTRANT)
> | #define _REENTRANT
> | #endif
> | #include <pthread.h>
> | #include <sys/types.h>
> | #include <sys/socket.h>
> | #include <netinet/in.h>
> | #include <arpa/inet.h>
> | #include <netdb.h>
> | int
> | main ()
> | {
> | int skr;
> | 
> |  skr = gethostbyname_r((const char *) 0,
> |   (struct hostent*) 0, (char*) 0, 0, (struct hostent **) 0, &skr);
> |   ;
> |   return 0;
> | }
> configure:39279: result: other

The detection result becomes other.

Is it because the unused option "-fno-implicit-templates" became an error 
in 3.2 as opposed to warning in 3.0? 


Thanks!
(In reply to comment #2)
> gethostbyname_r is declared to take 6 arguments:
> 
>        int gethostbyname_r(const char *name,
>                struct hostent *ret, char *buf, size_t buflen,
>                struct hostent **result, int *h_errnop);
> 
> but it is only being passed 5 arguments:
> 
> #define my_gethostbyname_r(A,B,C,D,E) gethostbyname_r((A),(B),(C),(D),(E))  
> 
> 
> So the clang error message "error: too few arguments to function call,
> expected
> 6, have 5" seems to be correct (no value passed for errnop).
> 
> In short, this looks like a MySQL bug.

Created attachment 9987 [details]
reduced test case

This is a reduced test case for the different behaviors of clang 3.0 and 3.2.

clang++ -use-gold-plugin -flto -c  -g -O0   -fno-implicit-templates -fno-exceptions -fno-rtti -Werror gethostname.cc


In 3.0:
clang: warning: argument unused during compilation: '-fno-implicit-templates'
echo $?
0

In 3.2
clang: error: argument unused during compilation: '-fno-implicit-templates'
echo $?
1

In my opinion, Clang 3.2 is correct.  It does what the user asked: promotes warnings to errors.

Closing per comment 5.

Reopening as I believe the bug is not INVALID.

The problem here is that clang defines __GNUC__ but isn't 100% compatible with gcc. If clang pretends to be GNUC then it has to accept all flags that would be accepted by gcc. The only sane resolution I can see is to implement functionality of the missing flags or if not feasible do not promote those specific flags to errors even if -Werror is set.

Again, clang is already doing the wrong thing by defining __GNUC__ (probably for compatibility reasons). For the same reasons "-Werror -fno-implicit-templates" should not produce errors.

We are not going to stop defining __GNUC__.

It is of course acceptable. This bug is not about stopping defining __GNUC__.

This bug is about compatibility issues as a result of defining __GNUC__ and what could be done to reduce the negative impact of this #define.

(In reply to comment #9)
> It is of course acceptable. This bug is not about stopping defining __GNUC__.
> 
> This bug is about compatibility issues as a result of defining __GNUC__ and
> what could be done to reduce the negative impact of this #define.
Defining __GNUC__ is not connected with supporting all possible knobs and options of gcc (some of them are essentially implementation-defined), after all, different gcc versions have different cmdline options.

Even more, the option in question does not influence the results of the test, so it should not be there after all (and it's somehow strange to use C++ compiler for C-level checks... what's about different inline semantics?). clang is not going to emulate MySQL configure checks' bugs, really.

> For the same reasons "-Werror -fno-implicit-templates" should not produce errors.
It should. You explicitly ask for warning here. You got the warning. It's upgraded to error. This is how -Werror works.

Please move such discussion to llvm-dev, bugzilla is an inappropriate place for this.