[Bug c/88584] GCC thinks that the type is complete dispite shaddowing.

[joseph at codesourcery dot com]

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

--- Comment #8 from joseph at codesourcery dot com  ---
Yes, I consider this a confirmed (and, strictly, regression from 3.4) bug.

[Bug c/88584] GCC thinks that the type is complete dispite shaddowing.

[anders.granlund.0 at gmail dot com]

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

--- Comment #7 from Anders Granlund  ---
(In reply to jos...@codesourcery.com from comment #6)
> This looks like a case that was missed in, or broken by, my fix for bug 
> 13801, which was supposed to address such cases of entities with different 
> (compatible) types in different scopes.  It seems GCC handled this 
> correctly (i.e. produced an error) in the 3.4 release series only.

Does this mean that we can change the status for this bug report from
UNCONFIRMED to NEW?

[Bug c/88584] GCC thinks that the type is complete dispite shaddowing.

[joseph at codesourcery dot com]

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

--- Comment #6 from joseph at codesourcery dot com  ---
This looks like a case that was missed in, or broken by, my fix for bug 
13801, which was supposed to address such cases of entities with different 
(compatible) types in different scopes.  It seems GCC handled this 
correctly (i.e. produced an error) in the 3.4 release series only.

[Bug c/88584] GCC thinks that the type is complete dispite shaddowing.

[sch...@linux-m68k.org]

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

--- Comment #5 from Andreas Schwab  ---
The examples in the DR only show identifiers with linkage and with compatible
types, but the shadowing decl in the example above has no linkage and an
incompatible type.

[Bug c/88584] GCC thinks that the type is complete dispite shaddowing.

[anders.granlund.0 at gmail dot com]

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

--- Comment #4 from Anders Granlund  ---
(In reply to Andrew Pinski from comment #3)
> http://www.open-std.org/jtc1/sc22/wg14/docs/rr/dr_011.html

To me it looks like the resolution of that defect report (and the current
wording of the standard) indicates that the current behaviour of GCC for my
test program (prog.c) is not correct.

The declaration  int a[1] = { 0 };  is not visible (because of shaddowing by  
int a; ) to  the declaration extern int a[];

[Bug c/88584] GCC thinks that the type is complete dispite shaddowing.

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
http://www.open-std.org/jtc1/sc22/wg14/docs/rr/dr_011.html

[Bug c/88584] GCC thinks that the type is complete dispite shaddowing.

[anders.granlund.0 at gmail dot com]

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

--- Comment #2 from Anders Granlund  ---
By "merging" i suppose you mean the process described at 6.2.7.4 in the
standard:

"For an identifier with internal or external linkage declared in a scope in
which
 a prior declaration of that identifier is visible, if the prior declaration
 specifies internal or external linkage, the type of the identifier at the
later
 declaration becomes the composite type."

Note that the declaration  int a[1] = { 0 };  is not visible to the declaration
extern int a[];  because of the shaddowing done by the declaration  int a; .

Therefore the "merging" is not done and  a  have the incomplete type  int [] 
in  sizeof (a) .

Becuase of this I still think that GCC is wrong here.

[Bug c/88584] GCC thinks that the type is complete dispite shaddowing.

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
>  extern int a[];
Is already have the completed type in the global scope and the declaration
merged with it:
  int a[1] = { 0 };



So I think GCC is correct here.