[Bug c++/68052] New: No printf format warnings in C++ code for macro in system headers

[Bug c++/68052] New: No printf format warnings in C++ code for macro in system headers

[gcc at blino dot org]

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

            Bug ID: 68052
           Summary: No printf format warnings in C++ code for macro in
                    system headers
           Product: gcc
           Version: 5.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gcc at blino dot org
  Target Milestone: ---

In gcc versions starting from 4.8, it seems that printf format warnings in
macros are inconsistent, depending on whether the header defining the macro is
included as a system header or not, and on the build mode (C or C++).

With gcc < 4.8 (tried gcc 4.6.3 and 4.7.2), there are printf format warnings
for both C and C++ languages, when the macro is in a system header or not.

With gcc >= 4.8 (tried 4.8.2 and 5.2.1 snapshot), there are no printf format
warnings when the build mode is C++ *and* when the macro is in a system header.
If the build mode is C or if the macro is in a non-system header, the printf
format warnings are emitted.

Here is a sample test case:
$ mkdir -p syshdr_dir
$ cat <<EOF > syshdr_dir/myprintf.h
#include <stdio.h>
#define MY_PRINTF(x, ...) printf(x, ## __VA_ARGS__);
EOF

$ cat <<EOF > test-format-printf.c
#include <myprintf.h>
int main(void) {
    long long ll = 0;
    MY_PRINTF("%ld", ll);
    return 0;
}
EOF

With gcc 4.6.3 and 4.7.2, I get printf format warnings for both C and C++
languages.

$ gcc -isystem $PWD/syshdr_dir -Wall -Werror -x c++ -c test-format-printf.c -o
/dev/null
test-format-printf.c: In function ‘int main()’:
test-format-printf.c:4:5: error: format ‘%ld’ expects argument of type ‘long
int’, but argument 2 has type ‘long long int’ [-Werror=format]
cc1plus: all warnings being treated as errors

$ gcc -isystem $PWD/syshdr_dir -Wall -Werror -x c -c test-format-printf.c -o
/dev/null
test-format-printf.c: In function ‘main’:
test-format-printf.c:4:5: error: format ‘%ld’ expects argument of type ‘long
int’, but argument 2 has type ‘long long int’ [-Werror=format]
cc1: all warnings being treated as errors


With gcc 4.8.2 and a 5.2.1 snapshot, there is a warning for C, but no warning
for C++ when the macro is in a system header.

$ gcc -isystem $PWD/syshdr_dir -Wall -Werror -x c++ -c test-format-printf.c -o
/dev/null

$ gcc -isystem $PWD/syshdr_dir -Wall -Werror -x c -c test-format-printf.c -o
/dev/null
In file included from test-format-printf.c:1:0:
test-format-printf.c: In function ‘main’:
test-format-printf.c:4:15: error: format ‘%ld’ expects argument of type ‘long
int’, but argument 2 has type ‘long long int’ [-Werror=format=]
     MY_PRINTF("%ld", ll);
               ^
cc1: all warnings being treated as errors

$ gcc -I $PWD/syshdr_dir -Wall -Werror -x c++ -c test-format-printf.c -o
/dev/null
In file included from test-format-printf.c:1:0:
test-format-printf.c: In function ‘int main()’:
/home/sah0146/dev/workspaces/bcm7252/hgw/build/MAIN/syshdr_dir/myprintf.h:2:51:
error: format ‘%ld’ expects argument of type ‘long int’, but argument 2 has
type ‘long long int’ [-Werror=format=]
 #define MY_PRINTF(x, ...) printf(x, ## __VA_ARGS__);
                                                   ^
test-format-printf.c:4:5: note: in expansion of macro ‘MY_PRINTF’
     MY_PRINTF("%ld", ll);
     ^
cc1plus: all warnings being treated as errors
>From gcc-bugs-return-500319-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Oct 22 17:12:50 2015
Return-Path: <gcc-bugs-return-500319-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 77286 invoked by alias); 22 Oct 2015 17:12:50 -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 77239 invoked by uid 48); 22 Oct 2015 17:12:47 -0000
From: "ktkachov at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/67989] [4.9/5/6 Regression] g++ ICE on armel valid code
Date: Thu, 22 Oct 2015 17:12:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 5.2.1
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ktkachov at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: ktkachov at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.3
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-67989-4-jYSraWUW9A@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-67989-4@http.gcc.gnu.org/bugzilla/>
References: <bug-67989-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-10/txt/msg01874.txt.bz2
Content-length: 182

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

--- Comment #10 from ktkachov at gcc dot gnu.org ---
Proposed patch at:
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg02299.html

[Bug c++/68052] No printf format warnings in C++ code for macro in system headers

[gcc at blino dot org]

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

Olivier Blin <gcc at blino dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|DUPLICATE                   |---

--- Comment #2 from Olivier Blin <gcc at blino dot org> ---
No, the difference that I observe is that, in this specific case involving a
macro in system header, there is a warning in C, and none in C++.
This has been discussed with Martin Sebor on the gcc-help mailing list.

[Bug c++/68052] No printf format warnings in C++ code for macro in system headers

[gcc at blino dot org]

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

--- Comment #3 from Olivier Blin <gcc at blino dot org> ---
Quoting Martin Sebor's answer from the gcc-help mailing list:
https://gcc.gnu.org/ml/gcc-help/2015-10/msg00128.html

> I'm inclined to say it's a bug. I recommend opening it in Bugzilla.
> The only way I was able to work around it is by changing MY_PRINTF
> from a function-like macro to an object macro like so:
> 
>   #define MY_PRINTF printf
> 
> The problem isn't specific to -Wformat but can be reproduced with
> other warnings as well. For example, replacing the contents of
> the header in the test case with this:
> 
>   #pragma GCC system_header
> 
>   static inline void __attribute__ ((deprecated)) foobar (void) { }
> 
>   #define foo foobar
>   #define bar() foobar()
> 
> and the body of main with
> 
>   foo ();
>   bar ();
> 
> emits a warning for each of foo() and bar() in C but just one,
> for foo(), in C++.
> 
> While stepping through the code that checks to see whether or not
> a diagnostic should be issued (diagnostic_issue_diagnostic) I see
> that the difference in the bar() case is in the return value of
> the linemap_macro_expansion_map_p() function which is documented
> to
> 
>   Return TRUE if MAP encodes locations coming from a macro
>   replacement-list at macro expansion point.
> 
> and implemented by testing the location MAP's REASON member for
> equality to the LC_ENTER_MACRO constant. In C, the REASON member
> is set to LC_LEAVE while in C++ to LC_ENTER_MACRO. In C, the
> call to bar is then treated as an ordinary token whose location
> (i.e., bar's invocation) determines whether or not to issue the
> diagnostic. In C++ the reference to bar is recognized as a macro
> expansion and the function proceeds to find the token it expands
> to and use that to determine whether or not to diagnose it. And
> since the token bar() expands to is defined in a system header,
> C++ doesn't issue the warning.
> 
> In the case of foo(), the REASON is LC_LEAVE in both front-ends
> and so they both diagnose it.
> 
> Martin

[Bug c++/68052] No printf format warnings in C++ code for macro in system headers

[manu at gcc dot gnu.org]

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

--- Comment #4 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Olivier Blin from comment #2)
> No, the difference that I observe is that, in this specific case involving a
> macro in system header, there is a warning in C, and none in C++.
> This has been discussed with Martin Sebor on the gcc-help mailing list.

What you observe is only a manifestation of something else. The reason for that
is that the warning for C is given at ", which is a token that does not come
from the system header, while the warning for C++ is given at ), which is a
token that comes from the system header, hence, the warning is suppressed. If
you move the "%lld" within the macro definition, you'll see the same behavior
for both (minus the column numbers).

But you can keep the bug reports separated if that pleases you, if makes not
difference on whether they will get fixed either way, it just makes less likely
that you will get notified if the bug gets eventually fixed through the other
report.
>From gcc-bugs-return-500373-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Oct 23 09:21:27 2015
Return-Path: <gcc-bugs-return-500373-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 36594 invoked by alias); 23 Oct 2015 09:21:27 -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 36549 invoked by uid 48); 23 Oct 2015 09:21:24 -0000
From: "pinskia at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/68067] Wrong constant folding
Date: Fri, 23 Oct 2015 09:21: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: trans-mem
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: pinskia at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: INVALID
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_status resolution
Message-ID: <bug-68067-4-1aDR0euHKz@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-68067-4@http.gcc.gnu.org/bugzilla/>
References: <bug-68067-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-10/txt/msg01928.txt.bz2
Content-length: 550

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Try with -fsantize=undefined?  This is a signed integer overflow as -1
--2147483648 is undefined due to - -2147483648 overflows.

[Bug c++/68052] No printf format warnings in C++ code for macro in system headers

[manu at gcc dot gnu.org]

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

--- Comment #5 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Olivier Blin from comment #3)
> Quoting Martin Sebor's answer from the gcc-help mailing list:
> https://gcc.gnu.org/ml/gcc-help/2015-10/msg00128.html

What Martin describes there is a different bug that occurs when there is a
whole stack of macro expansions (which is not the case in the original
testcase). My guess is that it is https://gcc.gnu.org/PR52998

Most of the bugs in the macro unwinder are known and triaged, but no one has
stepped up to fix them. See I) at https://gcc.gnu.org/wiki/Better_Diagnostics
>From gcc-bugs-return-500376-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Oct 23 09:35:42 2015
Return-Path: <gcc-bugs-return-500376-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 70103 invoked by alias); 23 Oct 2015 09:35:41 -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 70079 invoked by uid 48); 23 Oct 2015 09:35:37 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/68067] Wrong constant folding
Date: Fri, 23 Oct 2015 09:35: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: trans-mem
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: INVALID
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-68067-4-TxOx53PPqv@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-68067-4@http.gcc.gnu.org/bugzilla/>
References: <bug-68067-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-10/txt/msg01931.txt.bz2
Content-length: 315

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

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Yep.  Btw, what happens is that we see

 if (tem - 1 != 2147483647)

and that is obviously always true unless tem - 1 wraps from -2147483648 to
2147483647 which would invoke undefined behavior.