[Bug c/29970] mixing ({...}) with VLA leads to massive breakage

[Bug c/29970] mixing ({...}) with VLA leads to massive breakage

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tunagul29 at icloud dot com

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 99736 has been marked as a duplicate of this bug. ***

[Bug c/29970] mixing ({...}) with VLA leads to massive breakage

[tunagul29 at icloud dot com]

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

--- Comment #7 from Tuna Gül <tunagul29 at icloud dot com> ---
I guess i can post a workaround here

This code doesnt compile:
"""
int main() {
        ({
                unsigned int len = 10;
                struct {
                        int array[len];
                } new_object;
                new_object;
        });
}
"""

But this does:

"""
unsigned int foo(unsigned int rv) { return rv; }

int main() {
        ({
                unsigned int len = 10;
                struct {
                        int array[foo(len)];
                } new_object;
                new_object;
        });
}
"""

[Bug c/29970] mixing ({...}) with VLA leads to massive breakage

[muecker at gwdg dot de]

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

Martin Uecker <muecker at gwdg dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |muecker at gwdg dot de

--- Comment #8 from Martin Uecker <muecker at gwdg dot de> ---
So according to my amateurish analysis, there seem to be at least three
underlying issues:

- gimplify_compound_lval size expressions are gimplified too early. This
patch attempts to address this:

https://gcc.gnu.org/pipermail/gcc-patches/2021-August/576484.html

- inside sizeof, this seems to be a FE problem as the information from the
statement expression is lost.

- and then there is another issue, when a variably-sized object (but not a
pointer to it) is returned from the statement expression

[Bug c/29970] mixing ({...}) with VLA leads to massive breakage

[muecker at gwdg dot de]

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

--- Comment #9 from Martin Uecker <muecker at gwdg dot de> ---
The sizeof problem is that in c_expr_sizeof_expr the argument of sizeof is only
evaluated for VLAs but not for structs of variable size. The information about
the size is then lost. Changing this fixes some more cases.

A third problem seems to be that in gimplify_target_expr the size expressions
are also gimplified to early. Fixing this also seems to fix some of the cases,
but then triggers some other down stream problems...

[Bug c/29970] mixing ({...}) with VLA leads to massive breakage

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Martin Uecker <uecker@gcc.gnu.org>:

https://gcc.gnu.org/g:0631faf87a197145acd833249bf8f20a1c4aaabf

commit r12-2830-g0631faf87a197145acd833249bf8f20a1c4aaabf
Author: Martin Uecker <muecker@gwdg.de>
Date:   Tue Aug 10 07:42:51 2021 +0200

    Evaluate arguments of sizeof that are structs of variable size.

    Evaluate arguments of sizeof for all types of variable size
    and not just for VLAs. This fixes some issues related to
    [PR29970] where statement expressions need to be evaluated
    so that the size is well defined.

    2021-08-10  Martin Uecker  <muecker@gwdg.de>

    gcc/c/
            PR c/29970
            * c-typeck.c (c_expr_sizeof_expr): Evaluate
            size expressions for structs of variable size.

    gcc/testsuite/
            PR c/29970
            * gcc.dg/vla-stexp-1.c: New test.

[Bug c/29970] mixing ({...}) with VLA leads to massive breakage

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Martin Uecker <uecker@gcc.gnu.org>:

https://gcc.gnu.org/g:d2ba65ab6010f0d507bf5512a0223692e6653b23

commit r12-2882-gd2ba65ab6010f0d507bf5512a0223692e6653b23
Author: Martin Uecker <muecker@gwdg.de>
Date:   Thu Aug 12 20:32:16 2021 +0200

    Evaluate type arguments of sizeof that are structs of variable size
[PR101838]

    Evaluate type arguments of sizeof for all types of variable size
    and not just for VLAs. This fixes PR101838 and some issues related
    to PR29970 where statement expressions need to be evaluated so that
    the size is well defined.

    2021-08-12  Martin Uecker  <muecker@gwdg.de>

    gcc/c/
            PR c/101838
            PR c/29970
            * c-typeck.c (c_expr_sizeof_type): Evaluate
            size expressions for structs of variable size.

    gcc/testsuite/
            PR c/101838
            * gcc.dg/vla-stexp-2.c: New test.

[Bug c/29970] mixing ({...}) with VLA leads to massive breakage

[muecker at gwdg dot de]

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

--- Comment #12 from Martin Uecker <muecker at gwdg dot de> ---
Another version of the patch:

https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577402.html

[Bug c/29970] mixing ({...}) with VLA leads to massive breakage

[muecker at gwdg dot de]

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

--- Comment #13 from Martin Uecker <muecker at gwdg dot de> ---
The remaining problem with constant index 0 for the patch mentioned above,
appears to be related to fold_binary_loc which transforms (a + (x, 0)) to (x,
a) which breaks if 'x' depends on something in 'a'.

[Bug c/29970] mixing ({...}) with VLA leads to massive breakage

[muecker at gwdg dot de]

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

--- Comment #14 from Martin Uecker <muecker at gwdg dot de> ---

Another version of the patch:

https://gcc.gnu.org/pipermail/gcc-patches/2021-September/578844.html

[Bug c/29970] mixing ({...}) with VLA leads to massive breakage

[muecker at gwdg dot de]

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

--- Comment #15 from Martin Uecker <muecker at gwdg dot de> ---
Another version of the patch:

https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583593.html

[Bug c/29970] mixing ({...}) with VLA leads to massive breakage

[cvs-commit at gcc dot gnu.org]

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

--- Comment #16 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Martin Uecker <uecker@gcc.gnu.org>:

https://gcc.gnu.org/g:4e6bf0b9dd5585df1a1472d6a93b9fff72fe2524

commit r12-5338-g4e6bf0b9dd5585df1a1472d6a93b9fff72fe2524
Author: Martin Uecker <uecker@gcc.gnu.org>
Date:   Wed Nov 17 14:20:59 2021 +0100

    Fix ICE when mixing VLAs and statement expressions [PR91038]

    When returning VM-types from statement expressions, this can
    lead to an ICE when declarations from the statement expression
    are referred to later. Most of these issues can be addressed by
    gimplifying the base expression earlier in gimplify_compound_lval.
    Another issue is fixed by wrapping the pointer expression in
    pointer_int_sum. This fixes PR91038 and some of the test cases
    from PR29970 (structs with VLA members need further work).

    gcc/
            PR c/91038
            PR c/29970
            * gimplify.c (gimplify_var_or_parm_decl): Update comment.
            (gimplify_compound_lval): Gimplify base expression first.
            (gimplify_target_expr): Add comment.

    gcc/c-family/
            PR c/91038
            PR c/29970
            * c-common.c (pointer_int_sum): Make sure pointer expressions
            are evaluated first when the size expression depends on for
            variably-modified types.

    gcc/testsuite/
            PR c/91038
            PR c/29970
            * gcc.dg/vla-stexp-3.c: New test.
            * gcc.dg/vla-stexp-4.c: New test.
            * gcc.dg/vla-stexp-5.c: New test.
            * gcc.dg/vla-stexp-6.c: New test.
            * gcc.dg/vla-stexp-7.c: New test.
            * gcc.dg/vla-stexp-8.c: New test.
            * gcc.dg/vla-stexp-9.c: New test.

[Bug c/29970] mixing ({...}) with VLA leads to massive breakage

[egallager at gcc dot gnu.org]

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

--- Comment #17 from Eric Gallager <egallager at gcc dot gnu.org> ---
(In reply to CVS Commits from comment #16)
> The master branch has been updated by Martin Uecker <uecker@gcc.gnu.org>:
> 
> https://gcc.gnu.org/g:4e6bf0b9dd5585df1a1472d6a93b9fff72fe2524
> 
> commit r12-5338-g4e6bf0b9dd5585df1a1472d6a93b9fff72fe2524
> Author: Martin Uecker <uecker@gcc.gnu.org>
> Date:   Wed Nov 17 14:20:59 2021 +0100
> 
>     Fix ICE when mixing VLAs and statement expressions [PR91038]
>     
>     When returning VM-types from statement expressions, this can
>     lead to an ICE when declarations from the statement expression
>     are referred to later. Most of these issues can be addressed by
>     gimplifying the base expression earlier in gimplify_compound_lval.
>     Another issue is fixed by wrapping the pointer expression in
>     pointer_int_sum. This fixes PR91038 and some of the test cases
>     from PR29970 (structs with VLA members need further work).
>     
>     gcc/
>             PR c/91038
>             PR c/29970
>             * gimplify.c (gimplify_var_or_parm_decl): Update comment.
>             (gimplify_compound_lval): Gimplify base expression first.
>             (gimplify_target_expr): Add comment.
>     
>     gcc/c-family/
>             PR c/91038
>             PR c/29970
>             * c-common.c (pointer_int_sum): Make sure pointer expressions
>             are evaluated first when the size expression depends on for
>             variably-modified types.
>     
>     gcc/testsuite/
>             PR c/91038
>             PR c/29970
>             * gcc.dg/vla-stexp-3.c: New test.
>             * gcc.dg/vla-stexp-4.c: New test.
>             * gcc.dg/vla-stexp-5.c: New test.
>             * gcc.dg/vla-stexp-6.c: New test.
>             * gcc.dg/vla-stexp-7.c: New test.
>             * gcc.dg/vla-stexp-8.c: New test.
>             * gcc.dg/vla-stexp-9.c: New test.

Is this fixed now, or is it staying open for backports?

[Bug c/29970] mixing ({...}) with VLA leads to massive breakage

[muecker at gwdg dot de]

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

--- Comment #18 from Martin Uecker <muecker at gwdg dot de> ---
What is not fixed is returning structs with VLA members as in the first three
test cases, e.g. the second one still ICEs.

[Bug c/29970] mixing ({...}) with VLA leads to massive breakage

[gabravier at gmail dot com]

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

Gabriel Ravier <gabravier at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gabravier at gmail dot com

--- Comment #19 from Gabriel Ravier <gabravier at gmail dot com> ---
Can also confirm this myself as I've also encountered this ICE in this code:

#include <stdio.h>

#define each(item, array) \
(typeof(*(array)) *foreach_p = (array), *foreach_p2 = foreach_p, (item) = {}; \
foreach_p < &((foreach_p2)[sizeof(array)/sizeof(*array)]); \
++foreach_p)if((__builtin_memcpy(&(item), foreach_p, sizeof((item)))), 0){}else

#define range1(_stop) (({ \
        typeof(_stop) stop = _stop; \
        struct{typeof((stop)) array[stop];}p = {}; \
        if(stop < 0){ \
                for(size_t i = 0; i > stop; --i) \
                        p.array[-i] = i; \
        }else{ \
                for(size_t i = 0; i < stop; ++i) \
                        p.array[i] = i; \
        } \
        p; \
}).array)

int main(){
        char group[][4] = {
                "egg",
                "one",
                "two",
                "moo",
        };
        for each(x, group){
                puts(x);
        }
        return sizeof(range1(6));
}

which I was able to minify to:

void f()
{
  (void)({
    int x = 1;
    struct {
      int array[x];
    } p;
    p;
  });
}

which roughly matches what testcase 2 does.

[Bug c/29970] mixing ({...}) with VLA leads to massive breakage

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2006-11-25 01:55 -------
testcase 2 and 3 are a front-end issue as far as I can tell:
in .orginal:
    int n = 0;  // not there for 2 which causes the ICE
  return (int) ((long unsigned int) SAVE_EXPR <n> * 4);


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29970

[Bug c/29970] mixing ({...}) with VLA leads to massive breakage

[aviro at redhat dot com]

------- Comment #2 from aviro at redhat dot com  2006-11-24 15:25 -------
27301 looks similar to what the first one trips, but passing pointers
as suggested by #3 there is not a panacea - testcases 4 and 5
actually deal with that variant.  It really looks as if part (but not
all) information about the type dies when we leave the scope and
we end up stepping into that when working with object afterwards.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29970

[Bug c/29970] mixing ({...}) with VLA leads to massive breakage

[joseph at codesourcery dot com]

------- Comment #1 from joseph at codesourcery dot com  2006-11-24 13:56 -------
Subject: Re:   New: mixing ({...}) with VLA leads to massive
 breakage

This looks much the same as bug 27301, though the additional testcases are 
useful.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29970