Undeclared __isoc99...scanf() functions in output

[PHHargrove]

It looks like clang-upc2c is converting calls to certain stdio scanf-family functions to some internal name.
These names are now declared anywhere, resulting in implcit decl warnings from non-clang backends.
Some examples from the many test failures appear below.

/scratch/upcnightly/cupc2c-suncc/runtime/inst/bin/upcc -Ww,-Wno-duplicate-decl-specifier -Ww,-Werror=pointer-arith -g  -network=smp -pthreads -nolink-cache -lm -T 8 -o cg_st08 cg.upc mmio.c
"cg.upc", line 185: warning: implicit function declaration: __isoc99_fscanf (E_NO_IMPLICIT_DECL_ALLOWED)
"mmio.c", line 136: warning: implicit function declaration: __isoc99_fscanf (E_NO_IMPLICIT_DECL_ALLOWED)
"mmio.c", line 175: warning: implicit function declaration: __isoc99_sscanf (E_NO_IMPLICIT_DECL_ALLOWED)

/scratch/upcnightly/cupc2c-suncc/runtime/inst/bin/upcc -Ww,-Wno-duplicate-decl-specifier -Ww,-Werror=pointer-arith -g  -network=smp -pthreads -nolink-cache  -o bug3210 bug3210.c
"bug3210.c", line 75: warning: implicit function declaration: __isoc99_vfscanf (E_NO_IMPLICIT_DECL_ALLOWED)
"bug3210.c", line 81: warning: implicit function declaration: __isoc99_vscanf (E_NO_IMPLICIT_DECL_ALLOWED)
"bug3210.c", line 87: warning: implicit function declaration: __isoc99_vsscanf (E_NO_IMPLICIT_DECL_ALLOWED)

[nenadv]

On our system it is probably coming from this:

# 443 "/usr/include/stdio.h" 3 4
extern int fscanf (FILE *__restrict __stream, const char *__restrict __format, ...) __asm__ ("" "__isoc99_fscanf") ;

and in the source:

#if defined __USE_ISOC99 && !defined __USE_GNU \
    && (!defined __LDBL_COMPAT || !defined __REDIRECT) \
    && (defined __STRICT_ANSI__ || defined __USE_XOPEN2K)
# ifdef __REDIRECT
/* For strict ISO C99 or POSIX compliance disallow %as, %aS and %a[
   GNU extension which conflicts with valid %a followed by letter
   s, S or [.  */
extern int __REDIRECT (fscanf, (FILE *__restrict __stream,
                                const char *__restrict __format, ...),
                       __isoc99_fscanf) __wur;
extern int __REDIRECT (scanf, (const char *__restrict __format, ...),
                       __isoc99_scanf) __wur;
extern int __REDIRECT_NTH (sscanf, (const char *__restrict __s,
                                    const char *__restrict __format, ...),
                           __isoc99_sscanf);
# else
extern int __isoc99_fscanf (FILE *__restrict __stream,
                            const char *__restrict __format, ...) __wur;
extern int __isoc99_scanf (const char *__restrict __format, ...) __wur;
extern int __isoc99_sscanf (const char *__restrict __s,
                            const char *__restrict __format, ...) __THROW;
#  define fscanf __isoc99_fscanf
#  define scanf __isoc99_scanf
#  define sscanf __isoc99_sscanf
# endif
#endif

[PHHargrove]

Nenad,

Thanks for looking into this.
So, no that I see where the #defines come from, I wonder why is the back-end preprocess different?

I am guessing that one or more the of the tests in the following are different:

#if defined __USE_ISOC99 && !defined __USE_GNU \
    && (!defined __LDBL_COMPAT || !defined __REDIRECT) \
    && (defined __STRICT_ANSI__ || defined __USE_XOPEN2K)
# ifdef __REDIRECT

So, probably this is something that upcc needs to deal with by ensuring consistent preprocess environments for the translation and compilation stages. So, I'll take assignment on this one.

-Paul

[nenadv]

I also checked the 3.4.1-1 version and it does produce the same code as
3.5. Is this some new configuration that we haven't tested before?

On 2/9/15 4:05 PM, Paul H. Hargrove wrote:

Nenad,

Thanks for looking into this.
So, no that I see where the #defines come from, I wonder why is the
back-end preprocess different?

I am guessing that one or more the of the tests in the following are
different:

|#if defined USE_ISOC99 && !defined __USE_GNU
&& (!defined __LDBL_COMPAT || !defined __REDIRECT)
&& (defined __STRICT_ANSI || defined __USE_XOPEN2K)

ifdef __REDIRECT

|
|
|

ensuring consistent preprocess environments for the translation and
compilation stages. So, I'll take assignment on this one.

-Paul

—
Reply to this email directly or view it on GitHub
#111 (comment).

[PHHargrove]

Nenad,

This is not a new configuration.
The problem appears to go back to when the host "tesla" was rebuilt (and I don't know why I've not taken note of it before).

-Paul

[PHHargrove]

I am certain now of the difference between initial and final pre-process.
Initially __REDIRECT is not defined, leading to the portion of the code that contains the prototypes.
However, in the final pre-process (of the .trans.s) __REDIRECT is defined, leading down the path without the prototypes.

I have yet to determine why __REDIRECT is defined in only one of the two phases, let alone how to prevent it from differing.

[PHHargrove]

The definition of __REDIRECT comes from the Oracle (nee Sun) compiler's private sys/cdefs.h.
It expands to a compiler-specific _Pragma() to perform the renaming.
There is not an obvious way to disable it without including our own wrapper.

-Paul