https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86377

--- Comment #5 from U.Mutlu <um at mutluit dot com> ---
The configure scripts in the subdirs/libs (like libiberty) do compile some test
codes to populate the config.h of the subdir.
And there the difference happens if -Wuninitialized is treated as error, 
ie. if user sets -Werror=uninitialized either explicitly or implicitly thru
-Werror or a similar option:

Example for the libiberty subdir: once w/o -Werror and once with -Werror:

< conftest.c:53:7: warning: 't' is used uninitialized in this function
[-Wuninitialized]
---
> conftest.c:53:7: error: 't' is used uninitialized in this function 
> [-Werror=uninitialized]
361c361
< conftest.c:75:13: warning: 'cs[0]' is used uninitialized in this function
[-Wuninitialized]
---
> conftest.c:75:13: error: 'cs[0]' is used uninitialized in this function 
> [-Werror=uninitialized]
364,365c364,447
< configure:4686: $? = 0
< configure:4693: result: yes
...
> configure:4693: result: no

And in the 2nd case (>) from there on this causes many things in the config.h's
to be set differently, incl. the said NEED_DECLARATION_ERRNO ...

So, I think if the warnings in the stanza-codes could be eliminated then the
compilation would go further. It is the following code that generates the above
warnings: the variables t and cs should be initialized:

> | /* end confdefs.h.  */
> | 
> | int
> | main ()
> | {
> | /* FIXME: Include the comments suggested by Paul. */
> | #ifndef __cplusplus
> |   /* Ultrix mips cc rejects this.  */
> |   typedef int charset[2];
> |   const charset cs;
> |   /* SunOS 4.1.1 cc rejects this.  */
> |   char const *const *pcpcc;
> |   char **ppc;
> |   /* NEC SVR4.0.2 mips cc rejects this.  */
> |   struct point {int x, y;};
> |   static struct point const zero = {0,0};
> |   /* AIX XL C 1.02.0.0 rejects this.
> |      It does not let you subtract one const X* pointer from another in
> |      an arm of an if-expression whose if-part is not a constant
> |      expression */
> |   const char *g = "string";
> |   pcpcc = &g + (g ? g-g : 0);
> |   /* HPUX 7.0 cc rejects these. */
> |   ++pcpcc;
> |   ppc = (char**) pcpcc;
> |   pcpcc = (char const *const *) ppc;
> |   { /* SCO 3.2v4 cc rejects this.  */
> |     char *t;
> |     char const *s = 0 ? (char *) 0 : (char const *) 0;
> | 
> |     *t++ = 0;
> |     if (s) return 0;
> |   }
> |   { /* Someone thinks the Sun supposedly-ANSI compiler will reject this.  */
> |     int x[] = {25, 17};
> |     const int *foo = &x[0];
> |     ++foo;
> |   }
> |   { /* Sun SC1.0 ANSI compiler rejects this -- but not the above. */
> |     typedef const int *iptr;
> |     iptr p = 0;
> |     ++p;
> |   }
> |   { /* AIX XL C 1.02.0.0 rejects this saying
> |        "k.c", line 2.27: 1506-025 (S) Operand must be a modifiable lvalue. 
> */
> |     struct s { int j; const int *ap[3]; };
> |     struct s *b; b->j = 5;
> |   }
> |   { /* ULTRIX-32 V3.1 (Rev 9) vcc rejects this */
> |     const int foo = 10;
> |     if (!foo) return 0;
> |   }
> |   return !cs[0] && !zero.x;
> | #endif
> | 
> |   ;
> |   return 0;
> | }

As this code is just for test-compilation by the configure script, then it
makes sense to fix the warnings.

I will try this for all occurrences of that code and similar ones, and if the
result is satisfactory, then post a patch to the mailing list for review.

Reply via email to