[Bug c/52632] New: GCC compfail on O0

[Bug c/52632] New: GCC compfail on O0

[vbyakovl23 at gmail dot com]

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

             Bug #: 52632
           Summary: GCC compfail on O0
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: vbyakovl23@gmail.com


Test case a.c gives following compfail when compiling with O0

gcc –O0 –c a.c
a.c: In function 'foo':
a.c:4:1: error: size of unnamed array is negative

For higher opt level it's ok.
gcc version 4.8.0 20120319 (experimental) (GCC)

The failure happened because FE on –O0 replaces builtin call by zero if it is
not folded. See gcc/builtins.c, fold_builtin_1(), line 10270
  switch (fcode)
    {
    case BUILT_IN_CONSTANT_P:
      { 
        tree val = fold_builtin_constant_p (arg0);

        /* Gimplification will pull the CALL_EXPR for the builtin out of
           an if condition.  When not optimizing, we'll not CSE it back.
           To avoid link error types of regressions, return false now.  */
        if (!val && !optimize)
          val = integer_zero_node;

        return val;
      }

It may be fixed by a patch that disabled error message in case of not optimize. 

diff --git a/gcc/c-decl.c b/gcc/c-decl.c
index 160d393..1ba3f51 100644
--- a/gcc/c-decl.c
+++ b/gcc/c-decl.c
@@ -5345,7 +5345,7 @@ grokdeclarator (const struct c_declarator *declarator,
                if (TREE_CODE (size) == INTEGER_CST && size_maybe_const)
                  {
                    constant_expression_warning (size);
-                   if (tree_int_cst_sgn (size) < 0)
+                   if ((pedantic || optimize) && tree_int_cst_sgn (size) < 0)
                      {
                        if (name)
                          error_at (loc, "size of array %qE is negative",
name);

[Bug c/52632] GCC compfail on O0

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-03-20 09:09:14 UTC ---
Testcase?

[Bug c/52632] GCC compfail on O0

[vbyakovl23 at gmail dot com]

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

--- Comment #2 from Vladimir Yakovlev <vbyakovl23 at gmail dot com> 2012-03-20 10:03:47 UTC ---
Created attachment 26929
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26929
Test case

[Bug c/52632] GCC compfail on O0

[mikpe at it dot uu.se]

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

--- Comment #3 from Mikael Pettersson <mikpe at it dot uu.se> 2012-03-20 10:55:49 UTC ---
The test case, obviously based on the Linux kernel's BUILD_BUG_ON() macro,
behaves exactly as intended: since `offset' is not in fact a constant it causes
either a compile-time error or a link-time error (the latter because gcc
erroneously omits the compile-time error for an invalid type in an unused
sizeof() when optimizing).

[Bug c/52632] GCC compfail on O0

[joseph at codesourcery dot com]

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

--- Comment #4 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2012-03-20 11:09:43 UTC ---
On Tue, 20 Mar 2012, mikpe at it dot uu.se wrote:

> either a compile-time error or a link-time error (the latter because gcc
> erroneously omits the compile-time error for an invalid type in an unused
> sizeof() when optimizing).

I'm not aware of such a bug.  Please file a separate bug report in 
Bugzilla with a testcase for this "erroneously omits the compile-time 
error for an invalid type in an unused sizeof() when optimizing".

[Bug c/52632] GCC compfail on O0

[mikpe at it dot uu.se]

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

--- Comment #5 from Mikael Pettersson <mikpe at it dot uu.se> 2012-03-20 13:18:00 UTC ---
(In reply to comment #4)
> I'm not aware of such a bug.  Please file a separate bug report in 
> Bugzilla with a testcase for this "erroneously omits the compile-time 
> error for an invalid type in an unused sizeof() when optimizing".

Done, see PR52635.

[Bug c/52632] GCC compfail on O0

[izamyatin at gmail dot com]

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

Igor Zamyatin <izamyatin at gmail dot com> changed:

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

--- Comment #6 from Igor Zamyatin <izamyatin at gmail dot com> 2012-03-21 07:52:46 UTC ---
So is it ok that compiler behaves differently with and without optimizations?

[Bug c/52632] GCC compfail on O0

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-03-21 08:27:13 UTC ---
Yes.  Actually, with __builtin_constant_p, it does so pretty often.
Starting from trivial int foo () { int a; a = 1; return __builtin_constant_p
(a); }
or when __builtin_constant_p is used in an inline function on its arguments or
expressions involving those arguments (then it even depends on whether the
compiler decides to inline or clone the function or not).

BTW, for GCC 4.3+ kernel.h could very well use the __attribute__((error
("message"))).

[Bug c/52632] GCC compfail on O0

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |mpolacek at gcc dot gnu.org
         Resolution|---                         |INVALID

--- Comment #8 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Then this looks as invalid.