NetBSD Problem Report #51955

From wiz@yt.nih.at  Mon Feb  6 14:53:11 2017
Return-Path: <wiz@yt.nih.at>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (verified OK))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 0E2A77A220
	for <gnats-bugs@gnats.NetBSD.org>; Mon,  6 Feb 2017 14:53:11 +0000 (UTC)
Message-Id: <20170206134311.719152AC556@yt.nih.at>
Date: Mon,  6 Feb 2017 14:43:11 +0100 (CET)
From: Thomas Klausner <wiz@NetBSD.org>
Reply-To: Thomas Klausner <wiz@NetBSD.org>
To: gnats-bugs@NetBSD.org
Subject: incorrect varargs warning
X-Send-Pr-Version: 3.95

>Number:         51955
>Category:       toolchain
>Synopsis:       incorrect varargs warning
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    toolchain-manager
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Feb 06 14:55:00 +0000 2017
>Closed-Date:    Tue May 10 06:01:57 +0000 2022
>Last-Modified:  Tue May 10 06:01:57 +0000 2022
>Originator:     Thomas Klausner
>Release:        NetBSD 7.99.59
>Organization:
Curiosity is the very basis of education and if you tell me that 
curiosity killed the cat, I say only that the cat died nobly.
- Arnold Edinborough
>Environment:


Architecture: x86_64
Machine: amd64
>Description:
When compiling varargs code, gcc sometimes reports incorrect varargs warnings.
It seems to be connected to -std=gnu++14.
>How-To-Repeat:
$ cat >> example.cc

#include <stdio.h>
#include <stdlib.h>
#include <stdarg.h>

char* myprintf (const char *fmt, ...) {
    va_list ap;

    va_start (ap, fmt);
    va_end (ap);
    return NULL;
}
CTRL-D
$ g++   -std=gnu++14  -c -o example.o example.cc
example.cc: In function ‘char* myprintf(const char*, ...)’:
example.cc:8:23: warning: second parameter of ‘va_start’ not last named argument [-Wvarargs]
     va_start (ap, fmt);
                       ^


$ g++   -std=gnu++11  -c -o example.o example.cc
$
>Fix:
Please.

>Release-Note:

>Audit-Trail:
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: toolchain/51955: incorrect varargs warning
Date: Sat, 11 Feb 2017 16:36:16 +0100

 Looking at the preprocessor output (which does not differ for std=gnu++14
 vs. std=gnu++11), our headers generate:

 	__builtin_va_start(( ap ), ( fmt ))

 while it would work w/o the extra paranthesises:

 	__builtin_va_start( ap , fmt )

 Language lawyers?

 Martin

From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: toolchain/51955: incorrect varargs warning
Date: Sat, 11 Feb 2017 16:48:35 +0100

 I have reported it upstream:

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

 Martin

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: toolchain/51955: incorrect varargs warning
Date: Tue, 14 Mar 2017 07:43:42 +0000

 On Sat, Feb 11, 2017 at 03:40:01PM +0000, Martin Husemann wrote:
  >  Looking at the preprocessor output (which does not differ for std=gnu++14
  >  vs. std=gnu++11), our headers generate:
  >  
  >  	__builtin_va_start(( ap ), ( fmt ))
  >  
  >  while it would work w/o the extra paranthesises:
  >  
  >  	__builtin_va_start( ap , fmt )
  >  
  >  Language lawyers?

 It's a gcc-defined construct so it's up to them to decide what works;
 that said, it seems strange that extra parens would break it and I'd
 certainly call it gcc's bug.

  >  I have reported it upstream:
  >  
  >  	https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79466

 The upstream report contains a reference to a commit that reportedly
 makes it go away, if anyone wants to tinker.

 -- 
 David A. Holland
 dholland@netbsd.org

From: Thomas Klausner <wiz@NetBSD.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: toolchain/51955: incorrect varargs warning
Date: Tue, 14 Mar 2017 08:47:30 +0100

 On Tue, Mar 14, 2017 at 07:45:01AM +0000, David Holland wrote:
 >   >  	https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79466
 >  
 >  The upstream report contains a reference to a commit that reportedly
 >  makes it go away, if anyone wants to tinker.

 I already tried. It changes that code that does not even exist in our
 version of gcc yet.
  Thomas

State-Changed-From-To: open->feedback
State-Changed-By: rillig@NetBSD.org
State-Changed-When: Mon, 09 May 2022 23:21:49 +0000
State-Changed-Why:
Still relevant? GCC 10 from NetBSD-9.99.x no longer complains.


State-Changed-From-To: feedback->closed
State-Changed-By: wiz@NetBSD.org
State-Changed-When: Tue, 10 May 2022 06:01:57 +0000
State-Changed-Why:
Fixed upstream, it seems


>Unformatted:

Home	PR Database Search