[Bug c/105180] New: K&R style definition does not evaluate array size

[Bug c/105180] New: K&R style definition does not evaluate array size

[gcc at emil dot codes]

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

            Bug ID: 105180
           Summary: K&R style definition does not evaluate array size
           Product: gcc
           Version: 11.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gcc at emil dot codes
  Target Milestone: ---

GCC doesn't evaluates the size of an array when declared as a parameter in K&R
style declaration.


Example program:

    #include <stdio.h>

    int crime(s, c)
        char *s;
        char c[static printf("%s\n", s)];
    {
        return 0;
    }

    int accomplice(s) char *s;
    {
        return crime(s, s);
    }

    int main(void)
    {
        return accomplice("Hello");
    }

This should print "Hello\n". When using an ANSI definition, it does, but in
K&R-style, nothing is printed, `printf` isn't evaluated at all.

According to godbolt's compiler explorer, it is a regression which appeared
after GCC 4.6.4 and before or in GCC 4.7.1
It works correctly in clang but not in modern GCC.

[Bug c/105180] K&R style definition does not evaluate array size

[egallager at gcc dot gnu.org]

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

Eric Gallager <egallager at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager <egallager at gcc dot gnu.org> ---
I mean... that's some pretty suspect code right there...

[Bug c/105180] [9/10/11/12 Regression] K&R style definition does not evaluate array size

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers <jsm28 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|K&R style definition does   |[9/10/11/12 Regression] K&R
                   |not evaluate array size     |style definition does not
                   |                            |evaluate array size
             Status|UNCONFIRMED                 |NEW
   Target Milestone|---                         |9.5
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2022-04-21

[Bug c/105180] [10/11/12/13 Regression] K&R style definition does not evaluate array size

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|9.5                         |10.4

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 9 branch is being closed

[Bug c/105180] [10/11/12/13 Regression] K&R style definition does not evaluate array size

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.4                        |10.5

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 10.4 is being released, retargeting bugs to GCC 10.5.

[Bug c/105180] [10/11/12/13 Regression] K&R style definition does not evaluate array size

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I am suspecting r0-108564-ga04a722b88baf5 .

[Bug c/105180] [10/11/12/13 Regression] K&R style definition does not evaluate array size

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #4)
> I am suspecting r0-108564-ga04a722b88baf5 .

That is https://gcc.gnu.org/legacy-ml/gcc-patches/2011-05/msg00319.html .

I suspect there was a missing old style part to the parser but I am not 100%
sure.

[Bug c/105180] [10/11/12/13 Regression] K&R style definition does not evaluate array size

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Here is a self contained tester:
int global = 0;
int func(void)
{
  global++;
  return global;
}
void crime(s, c)
    char *s;
    char c[static func()];
{
}

int main(void)
{
    crime("1", "1");
    if (global != 1)
      __builtin_abort();
    return 0;
}

[Bug c/105180] [10/11/12/13 Regression] K&R style definition does not evaluate array size

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org,
                   |                            |jsm28 at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
int global = 0;

int
foo (void)
{
  ++global;
  return 1;
}

void
baz (void)
{
  void
  bar (s, c)
    char *s;
    char c[static foo ()];
  {
  }
  bar ("1", "1");
  bar ("1", "1");
  bar ("1", "1");
}

int
main ()
{
  baz ();
  if (global != 3)
    __builtin_abort ();
  return 0;
}

shows that for nested functions those side-effects are emitted, but at a wrong
location.
The side-effects in that case are evaluated when passing through the definition
of bar inside of the baz function,
rather than when bar is called.  So above, foo () is called just once, not 3
times.
If standard C declarations are used:
int global = 0;

int
foo (void)
{
  return ++global;
}

void
bar (char *s, char c[static foo ()])
{
}

int
main ()
{
  bar ("1", "1");
  if (global != 1)
    __builtin_abort ();
  return 0;
}
then it works properly, in that case the pending sizes are recorded by
c_parser_parms_list_declarator -> push_parm_decl -> grokdeclarator and queued
by get_parm_info called from c_parser_parms_list_declarator.
But in case of K&R argument declarations, those are done by:
              while (c_parser_next_token_is_not (parser, CPP_EOF)
                     && c_parser_next_token_is_not (parser, CPP_OPEN_BRACE))
                c_parser_declaration_or_fndef (parser, false, false, false,
                                               true, false);
in c_parser_declaration_or_fndef and in that case that nested
c_parser_declaration_or_fndef calls start_decl which after
calling grokdeclarator which collects the pending expressions just does:
  if (expr)
    add_stmt (fold_convert (void_type_node, expr));
and so it is unclear where exactly it is pushed for the non-nested functions,
for nested ones at the current statement location (the definition of nested
function).
Bet we need to arrange for those side-effects to be instead remembered
somewhere and queued into pending_sizes later.

[Bug c/105180] [10/11/12/13 Regression] K&R style definition does not evaluate array size

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2

[Bug c/105180] [11/12/13/14 Regression] K&R style definition does not evaluate array size

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.5                        |11.5

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 10 branch is being closed.