[Bug c/48088] New: -Werror=frame-larger-than=100 does not work as expected

[Bug c/48088] New: -Werror=frame-larger-than=100 does not work as expected

[cgd at google dot com]

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

           Summary: -Werror=frame-larger-than=100 does not work as
                    expected
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: cgd@google.com


the gcc manual says:

Note that specifying @option{-Werror=}@var{foo} automatically implies
@option{-W}@var{foo}.  However, @option{-Wno-error=}@var{foo} does not
imply anything.

That's easily understood to mean that, for instance:
   -Werror=frame-larger-than=500
implies
   -Wframe-larger-than=500

however, it doesn't.  it seems to imply -Wframe-larger-than=1.

Worse, -Werror=frame-larger-than= clobbers any previous -Wframe-larger-than=
value.


/tmp/x.c:
int x() {
  int x[5];
}


$ gcc-svn/inst/bin/gcc -Wframe-larger-than=100 /tmp/x.c -c
$ 

-> OK, the frame is smaller than 100.


$ gcc-svn/inst/bin/gcc -Werror=frame-larger-than=100 /tmp/x.c -c
/tmp/x.c: In function 'x':
/tmp/x.c:3:1: error: the frame size of 32 bytes is larger than 1 bytes
[-Werror=frame-larger-than=]
cc1: some warnings being treated as errors

$ 

-> OK, that's kinda odd.


$ gcc-svn/inst/bin/gcc -Wframe-larger-than=100 -Werror=frame-larger-than=100
/tmp/x.c -c
/tmp/x.c: In function 'x':
/tmp/x.c:3:1: error: the frame size of 32 bytes is larger than 1 bytes
[-Werror=frame-larger-than=]
cc1: some warnings being treated as errors

$ 

-> eh?


$ gcc-svn/inst/bin/gcc -Wframe-larger-than=100 -Werror=frame-larger-than=
/tmp/x.c -c
/tmp/x.c: In function 'x':
/tmp/x.c:3:1: error: the frame size of 32 bytes is larger than 1 bytes
[-Werror=frame-larger-than=]
cc1: some warnings being treated as errors

$ 

-> eh?


$ gcc-svn/inst/bin/gcc -Werror=frame-larger-than= -Wframe-larger-than=100
/tmp/x.c -c
$ 

-> order apparently matters.

[Bug c/48088] -Werror=frame-larger-than=100 does not work as expected

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

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

--- Comment #1 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2011-03-12 13:45:09 UTC ---
I think in general Werror= doesn't work for options that take arguments.

[Bug c/48088] -Werror=frame-larger-than=100 does not work as expected

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011.03.14 10:29:28
     Ever Confirmed|0                           |1

--- Comment #2 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-03-14 10:29:28 UTC ---
Yeah.  Confirmed.

You need -Wframe-larger-than=500 -Werror=frame-larger-than which hopefully
doesn't reset the value to 1.

[Bug c/48088] -Werror=frame-larger-than=100 does not work as expected

[cgd at google dot com]

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

--- Comment #3 from Chris Demetriou <cgd at google dot com> 2011-03-14 22:56:06 UTC ---
(In reply to comment #2)
> Yeah.  Confirmed.
> 
> You need -Wframe-larger-than=500 -Werror=frame-larger-than which hopefully
> doesn't reset the value to 1.

It doesn't, but not for the reason you would hope.  8-)

[cgd@cgda gcc-svn]$ inst/bin/gcc --version | head -1
gcc (GCC) 4.6.0 20110311 (experimental)
[cgd@cgda gcc-svn]$ inst/bin/gcc -Wframe-larger-than=500
-Werror=frame-larger-than -c /tmp/x.c
cc1: error: -Werror=frame-larger-than: no option -Wframe-larger-than

IMO this suggestion disagrees with my reading of the usage -Werror in the
manual (before or my after my recent change), and also disagrees with the
warning name output by -fdiagnostics-show-option:

/tmp/x.c:3:1: error: the frame size of 32 bytes is larger than 1 bytes
[-Werror=frame-larger-than=]


[note that this compiler is a few days old -- my assumption is that this
behaviour didn't change since then, given the relative lockdown of GCC sources
in prep for the 4.6 branch.  Sorry if my assumption was incorrect.]

[Bug c/48088] -Werror=frame-larger-than=100 does not work as expected

[manu at gcc dot gnu.org]

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

--- Comment #4 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2011-03-15 09:20:47 UTC ---
(In reply to comment #3)
> (In reply to comment #2)
> > Yeah.  Confirmed.
> > 
> > You need -Wframe-larger-than=500 -Werror=frame-larger-than which hopefully
> > doesn't reset the value to 1.
> 
> It doesn't, but not for the reason you would hope.  8-)

These are indeed several bugs related to not handling W options with parameters
properly. Check in options.c (enable_warning_as_error) for how -Werror=option
is handled and...

> /tmp/x.c:3:1: error: the frame size of 32 bytes is larger than 1 bytes
> [-Werror=frame-larger-than=]

diagnostics.c for how this is printed. This should print
-Werror=frame-larger-than=1 (without -Werror, does it print
[-Wframe-larger-than=1]) ?

I guess similar problems arise with Wlarger-than=, Woverflow= and
Wstrict-aliasing= (but perhaps the two latter are handled differently).

Fixing it should be fairly trivial.

[Bug c/48088] -Werror=frame-larger-than=100 does not work as expected

[slyfox at inbox dot ru]

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

Sergei Trofimovich <slyfox at inbox dot ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |slyfox at inbox dot ru

--- Comment #5 from Sergei Trofimovich <slyfox at inbox dot ru> ---
Stumbled on this bug today. I tried to use it in more intricate way:

    -Wframe-larger-than=4096 -Werror=frame-larger-than=32768

which would only warn about any stack more than 4096+, but would fail on
32768+.

Does it make sense to implement desired behaviour?
I guess it's not many '>=number' style options in gcc.

[Bug c/48088] -Werror=frame-larger-than=100 does not work as expected

[manu at gcc dot gnu.org]

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

--- Comment #6 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Sergei Trofimovich from comment #5)
> Does it make sense to implement desired behaviour?

Probably not. We also don't accept two different values for
-Wframe-larger-than. But it would make sense to diagnose
-Werror=frame-larger-than=500 and only accept -Werror=frame-larger-than and
also fix the option printing issues.
>From gcc-bugs-return-423214-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon May 27 11:45:29 2013
Return-Path: <gcc-bugs-return-423214-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 31305 invoked by alias); 27 May 2013 11:45:29 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 31047 invoked by uid 48); 27 May 2013 11:45:24 -0000
From: "ysrumyan at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/57430] New: Redundant move instruction is produced after function inlining
Date: Mon, 27 May 2013 11:45:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ysrumyan at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-57430-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-05/txt/msg01887.txt.bz2
Content-length: 1183

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW430

            Bug ID: 57430
           Summary: Redundant move instruction is produced after function
                    inlining
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ysrumyan at gmail dot com

This is based on performance analysis of eembc2.0 suite on Atom processor in
comparison with clang compiler.

I prepared a simple reproducer that exhibits the issue.

Hottest loop (from function "remove") consists of 7 instructions if inlining
was applied:
.L48:
    movl    %edx, %ebp   <<--  it is redundant!!
    movl    %ecx, %edx
.L39:
    cmpl    %edx, %eax
    je    .L24
    movl    16(%edx), %ecx
    testl    %ecx, %ecx
    jne    .L48

but without inlining it consists of 6 instructions:

.L5:
    cmpl    %eax, %ecx
    je    .L4
    movl    %eax, %edx
.L7:
    movl    16(%edx), %eax
    testl    %eax, %eax
    jne    .L5

In result we can see performance drop on 4% (Atom 32-bit mode).

The reproducer will be attached.