[Bug c/61118] New: Spurious -Wclobbered warning generated by gcc 4.9.0 for pthread_cleanup_push

[Bug c/61118] New: Spurious -Wclobbered warning generated by gcc 4.9.0 for pthread_cleanup_push

[tavianator at gmail dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 4176 bytes --]

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

            Bug ID: 61118
           Summary: Spurious -Wclobbered warning generated by gcc 4.9.0
                    for pthread_cleanup_push
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: tavianator at gmail dot com

Created attachment 32762
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32762&action=edit
Source file

On gcc 4.9.0 (but not on 4.8.2 or earlier), the attached code gives two
spurious warnings:

$ gcc -std=gnu99 -Wclobbered -O2 -c clobber_warning.c -pthread -save-temps
clobber_warning.c: In function ‘dmnsn_future_wait’:
clobber_warning.c:23:54: warning: variable ‘__cancel_routine’ might be
clobbered by ‘longjmp’ or ‘vfork’ [-Wclobbered]
     pthread_cleanup_push(cleanup_fn, &future->mutex);
                                                      ^
clobber_warning.c:23:103: warning: variable ‘__cancel_arg’ might be clobbered
by ‘longjmp’ or ‘vfork’ [-Wclobbered]
     pthread_cleanup_push(cleanup_fn, &future->mutex);

Those variables come from the expansion of the pthread_cleanup_{push,pop}
macros, which look like this (reformatted a little):

do {
  __pthread_unwind_buf_t __cancel_buf;
  void (*__cancel_routine) (void *) = (cleanup_fn);
  void *__cancel_arg = (&future->mutex);
  int __not_first_call = __sigsetjmp ((struct __jmp_buf_tag *) (void *)
__cancel_buf.__cancel_jmp_buf, 0);
  if (__builtin_expect ((__not_first_call), 0)) {
    __cancel_routine (__cancel_arg);
    __pthread_unwind_next (&__cancel_buf);
  }
  __pthread_register_cancel (&__cancel_buf);
  do {;
    pthread_cond_wait(&future->cond, &future->mutex);
    do { } while (0);
  } while (0);
  __pthread_unregister_cancel (&__cancel_buf);
  if (0)
    __cancel_routine (__cancel_arg);
} while (0);

The __cancel_routine and __cancel_arg variables are never modified, so I don't
see how they can be clobbered.
>From gcc-bugs-return-451055-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu May 08 20:46:14 2014
Return-Path: <gcc-bugs-return-451055-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 16130 invoked by alias); 8 May 2014 20:46: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 16097 invoked by uid 48); 8 May 2014 20:46:11 -0000
From: "tavianator at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/61118] Spurious -Wclobbered warning generated by gcc 4.9.0 for pthread_cleanup_push
Date: Thu, 08 May 2014 20:46:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
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: tavianator 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: attachments.created
Message-ID: <bug-61118-4-uSoq9zw6jJ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61118-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61118-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-05/txt/msg00747.txt.bz2
Content-length: 240

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

--- Comment #1 from Tavian Barnes <tavianator at gmail dot com> ---
Created attachment 32763
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id2763&actioníit
Preprocessed source file

[Bug middle-end/61118] Spurious -Wclobbered warning generated by gcc 4.9.0 for pthread_cleanup_push

[douzzer at mega dot nu]

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

--- Comment #2 from Daniel Pouzzner <douzzer at mega dot nu> ---
Alas still there in 4.9.1 as bundled with Ubuntu 14.10.

[Bug middle-end/61118] Spurious -Wclobbered warning generated by gcc 4.9.0 for pthread_cleanup_push

[lambertarthur22 at gmail dot com]

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

Arthur LAMBERT <lambertarthur22 at gmail dot com> changed:

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

--- Comment #3 from Arthur LAMBERT <lambertarthur22 at gmail dot com> ---
Same problem for me after updating my gcc version from 4.8.4 to 4.9.3.

I have a piece of code using pthread_clean_push/pop which lead to the same
warning :

error: variable ‘x’ might be clobbered by ‘longjmp’ or ‘vfork’
[-Werror=clobbered]
error: variable ‘y’ might be clobbered by ‘longjmp’ or ‘vfork’
[-Werror=clobbered]
error: variable ‘__cancel_routine’ might be clobbered by ‘longjmp’ or ‘vfork’
[-Werror=clobbered]

Just need to comment the pthread_clean_X call to remove the warning.

Any update on this ?
>From gcc-bugs-return-496852-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Sep 10 10:19:37 2015
Return-Path: <gcc-bugs-return-496852-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 54680 invoked by alias); 10 Sep 2015 10:19:37 -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 54608 invoked by uid 48); 10 Sep 2015 10:19:32 -0000
From: "kkojima at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/67506] [5/6 Regression][SH]: error: unrecognizable insn when compiling texlive-binaries
Date: Thu, 10 Sep 2015 10:19:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: kkojima at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
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:
Message-ID: <bug-67506-4-UAWP3gdcVz@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-67506-4@http.gcc.gnu.org/bugzilla/>
References: <bug-67506-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: 2015-09/txt/msg00830.txt.bz2
Content-length: 328

https://gcc.gnu.org/bugzilla/show_bug.cgi?idg506

--- Comment #5 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #4)
> Could you please test it?

It fixes all test cases for the cross trunk sh4-unknown-linux-gnu compiler.
There is no new failures with the top level "make -k check".

[Bug middle-end/61118] [9/10/11/12 Regression] Indirect call generated for pthread_cleanup_push with constant cleanup function

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|8.5                         |9.4

--- Comment #27 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 8 branch is being closed.

[Bug middle-end/61118] [9/10/11/12 Regression] Indirect call generated for pthread_cleanup_push with constant cleanup function

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #28 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 9.4 is being released, retargeting bugs to GCC 9.5.

[Bug middle-end/61118] [10/11/12/13 Regression] Indirect call generated for pthread_cleanup_push with constant cleanup function

[rguenth at gcc dot gnu.org]

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

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

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

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

[Bug middle-end/61118] [10/11/12/13 Regression] Indirect call generated for pthread_cleanup_push with constant cleanup function

[jakub at gcc dot gnu.org]

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

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

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

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

[Bug middle-end/61118] [11/12/13/14 Regression] Indirect call generated for pthread_cleanup_push with constant cleanup function

[rguenth at gcc dot gnu.org]

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

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

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

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

[Bug middle-end/61118] [11/12/13/14/15 Regression] Indirect call generated for pthread_cleanup_push with constant cleanup function

[eggert at cs dot ucla.edu]

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

Paul Eggert <eggert at cs dot ucla.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |eggert at cs dot ucla.edu

--- Comment #32 from Paul Eggert <eggert at cs dot ucla.edu> ---
Created attachment 58065
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58065&action=edit
Run "gunzip t.i.gz; gcc -O2 -S -Wclobbered t.i" to reproduce the false
positives

I ran into this bug today when compiling GNU Emacs with gcc (GCC) 14.0.1
20240411 (Red Hat 14.0.1-0) on x86-64 (Fedora 40). I didn't see it with earlier
GCC releases so I thought I'd attach a test case, derived from Emacs. Compile
with:

gunzip t.i
gcc -O2 -S -Wclobbered t.i

and the incorrect diagnostics are:

t.i: In function ‘internal_lisp_condition_case’:
t.i:7969:15: warning: variable ‘sym’ might be clobbered by ‘longjmp’ or ‘vfork’
[-Wclobbered]
 7969 |   Lisp_Object sym = XSYMBOL_WITH_POS (a)->sym;
      |               ^~~
t.i:94273:43: warning: argument ‘var’ might be clobbered by ‘longjmp’ or
‘vfork’ [-Wclobbered]
94273 | internal_lisp_condition_case (Lisp_Object var, Lisp_Object bodyform,
      |                               ~~~~~~~~~~~~^~~

[Bug middle-end/61118] [11/12/13/14/15 Regression] Indirect call generated for pthread_cleanup_push with constant cleanup function

[pinskia at gcc dot gnu.org]

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

--- Comment #33 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Paul Eggert from comment #32)
> Created attachment 58065 [details]
> Run "gunzip t.i.gz; gcc -O2 -S -Wclobbered t.i" to reproduce the false
> positives
> 
> I ran into this bug today when compiling GNU Emacs with gcc (GCC) 14.0.1
> 20240411 (Red Hat 14.0.1-0) on x86-64 (Fedora 40). I didn't see it with
> earlier GCC releases so I thought I'd attach a test case, derived from
> Emacs. Compile with:

It is there for GCC 11.4.1 for me:
[apinski@xeond2 upstream-gcc-new]$ gcc ~/src/t.i -S -O2 -S -Wclobbered
-fdump-tree-optimized
/home/apinski/src/t.i: In function ‘internal_lisp_condition_case’:
/home/apinski/src/t.i:7969:15: warning: variable ‘sym’ might be clobbered by
‘longjmp’ or ‘vfork’ [-Wclobbered]
 7969 |   Lisp_Object sym = XSYMBOL_WITH_POS (a)->sym;
      |               ^~~
/home/apinski/src/t.i:94273:43: warning: argument ‘var’ might be clobbered by
‘longjmp’ or ‘vfork’ [-Wclobbered]
94273 | internal_lisp_condition_case (Lisp_Object var, Lisp_Object bodyform,
      |                               ~~~~~~~~~~~~^~~
[apinski@xeond2 upstream-gcc-new]$ gcc ~/src/t.i -S -O2 -S -Wclobbered
-fdump-tree-optimized --version
gcc (GCC) 11.4.1 20231218 (Red Hat 11.4.1-3)
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.