[Bug c/54561] New: incorrect setjmp -Wclobber diagnostics

[Bug c/54561] New: incorrect setjmp -Wclobber diagnostics

[eggert at gnu dot org]

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

             Bug #: 54561
           Summary: incorrect setjmp -Wclobber diagnostics
    Classification: Unclassified
           Product: gcc
           Version: 4.7.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: eggert@gnu.org


Created attachment 28180
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28180
generates incorrect diagnostics with gcc -O2 -Wclobbered

If I compile the attached program via the command "gcc -S -Wclobbered
-O2 w.i" (GCC 4.7.1, x86-64, Fedora 17), the output is:

w.i: In function 'png_load_body':
w.i:37:13: warning: variable 'info_ptr' might be clobbered by 'longjmp' or
'vfork' [-Wclobbered]
w.i:38:9: warning: variable 'fp' might be clobbered by 'longjmp' or 'vfork'
[-Wclobbered]

Both warnings are incorrect, because info_ptr and fp are not live
across any possible longjmp.  If longjmp munges these variables,
setjmp must return a nonzero value, and no uses of these variables are
reachable in that case.

Like Bug#48968, I ran into this problem when building Emacs.  This test
case is much shorter, though (I whittled it down), so it should be
easier to debug.

[Bug middle-end/54561] incorrect setjmp -Wclobber diagnostics

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-09-12 21:02:37 UTC ---
Both info_ptr and fp are alive across the setjmp.  GCC does not do fancy
detection of alive on one of branches of the result of setjmp.  It just warns
if it is alive across on either branch on setjmp.

[Bug middle-end/54561] incorrect setjmp -Wclobber diagnostics

[eggert at gnu dot org]

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

--- Comment #2 from eggert at gnu dot org 2012-09-12 23:39:16 UTC ---
> GCC ... warns if it is alive across on either branch on setjmp.

OK, thanks, that's the bug then.  GCC should warn only about the
longjmp branch, not about the non-lonjmp branch.

Can GCC model the longjmp branch as assigning garbage to all the
nonvolatile locals, and then use the algorithm it's already using
when it warns about use of uninitialized locals?  Something like
that should do the trick.

[Bug middle-end/54561] incorrect setjmp -Wclobber diagnostics

[mat at matws dot net]

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

Matthieu Patou <mat at matws dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mat at matws dot net

--- Comment #3 from Matthieu Patou <mat at matws dot net> ---
I have more issues with Gcc generating wrong warning.
When trying to compile new dissectors with gcc 4.8.8 in wireshark I got:

/home/mat/workspace/wireshark/epan/dissectors/packet-dcerpc-dnsserver.c: In
function ‘dnsserver_dissect_struct_DNS_RPC_NAME_LIST’:

/home/mat/workspace/wireshark/epan/dissectors/packet-dcerpc-dnsserver.c:1902:23:
warning: variable ‘tmptree’ might be clobbered by ‘longjmp’ or ‘vfork’
[-Wclobbered]
  volatile proto_tree *tmptree = NULL;

/home/mat/workspace/wireshark/epan/dissectors/packet-dcerpc-dnsserver.c:1903:23:
warning: variable ‘tmpitem’ might be clobbered by ‘longjmp’ or ‘vfork’
[-Wclobbered]
  volatile proto_item *tmpitem = NULL;

The manpage of longjmp states that 

"The values of automatic variables are unspecified after a call to longjmp() if
they meet all the following criteria:

       ·  they are local to the function that made the corresponding setjmp(3)
call;
       ·  their values are changed between the calls to setjmp(3) and
longjmp(); and
       ·  they are not declared as volatile."

So without the volatile keyword the warning would valid but I explicitly
specified volatile to avoid this warning, unless I mis-understood something I
think this warning shouldn't be emitted.
>From gcc-bugs-return-446808-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Mar 19 05:17:15 2014
Return-Path: <gcc-bugs-return-446808-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 26033 invoked by alias); 19 Mar 2014 05:17:14 -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 26004 invoked by uid 48); 19 Mar 2014 05:17:10 -0000
From: "su at cs dot ucdavis.edu" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/60578] New: wrong code (that hangs) at -O0 on x86_64-linux-gnu (affecting all gcc versions)
Date: Wed, 19 Mar 2014 05:17:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: su at cs dot ucdavis.edu
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-60578-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: 2014-03/txt/msg01677.txt.bz2
Content-length: 1490

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`578

            Bug ID: 60578
           Summary: wrong code (that hangs) at -O0 on x86_64-linux-gnu
                    (affecting all gcc versions)
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: su at cs dot ucdavis.edu

The current gcc trunk miscompiles the following code on x86_64-linux at -O0 in
64-bit mode (but not 32-bit).

It affects all GCC versions and seems to do with wrong integer promotion in the
expression "(c ^ 0L) < -1".

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 4.9.0 20140318 (experimental) [trunk revision 208631] (GCC)
$
$ gcc-trunk -m32 -O0 small.c
$ a.out
$ gcc-trunk -m64 -O1 small.c
$ a.out
$
$ gcc-trunk -m64 -O0 small.c
$ a.out
^C
$


--------------------------


int a, *b = &a;

unsigned c;

int
foo ()
{
  return 0;
}

int
bar ()
{
  int i, j, m, n;
  *b = foo ();
  for (i = 0; i;)
    for (; j;)
      m = 0;
  if ((c ^ 0L) < -1)
    return 0;
  for (; n;)
    ;
  return 0;
}

int
main ()
{
  bar ();
  return 0;
}

[Bug middle-end/54561] incorrect setjmp -Wclobber diagnostics

[mikpelinux at gmail dot com]

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

--- Comment #4 from Mikael Pettersson <mikpelinux at gmail dot com> ---
(In reply to Matthieu Patou from comment #3)
>   volatile proto_tree *tmptree = NULL;

Try

    proto_tree * volatile tmptree = NULL;

It's the variable itself that needs to be volatile, not the memory it points
to.