[Bug preprocessor/60304] New: Including <atomic> disables -Wconversion-null

[Bug preprocessor/60304] New: Including <atomic> disables -Wconversion-null

[bug-reports at psdtechnologies dot com]

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

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

            Bug ID: 60304
           Summary: Including <atomic> disables -Wconversion-null
           Product: gcc
           Version: 4.8.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: preprocessor
          Assignee: unassigned at gcc dot gnu.org
          Reporter: bug-reports at psdtechnologies dot com

Created attachment 32190
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32190&action=edit
Minimal example of bug (does not emit warning)

Compiling any code with '#include <atomic>' disables the conversion-null
warning, but only when compiling directly from source; preprocessing separately
does not reproduce the bug.

I've attached minimal examples, reproduced here since they're so short (1-2
lines)


This file behaves as expected (warning.cpp):
"""
int * foo() {return false;}
"""

$ g++-4.8 -std=c++11 -c warning.cpp 
warning.cpp: In function ‘int* foo()’:
warning.cpp:1:21: warning: converting ‘false’ to pointer type ‘int*’
[-Wconversion-null]
 int * foo() {return false;}
                     ^

This warning is expected since -Wconversion-null is enabled by default. It also
can be made to error as expected using -Wall or by inserting 

"""
#pragma GCC diagnostic error "-Wconversion-null" 
"""

in the source prior to the function.



This file (differing only by the inclusion of <atomic> does not issue the
warning, and cannot be made to error or warn even with the pragma:

"""
#include <atomic>
int * foo() {return false;}
"""

g++-4.8 -std=c++11 -c nowarning.cpp # success

Compiling incrementally, though, restores the expected behavior:

g++-4.8 -std=c++11 -E nowarning.cpp -o nowarning.i # success
g++-4.8 -std=c++11 -c nowarning.i
nowarning.cpp: In function ‘int* foo()’:
nowarning.cpp:2:21: warning: converting ‘false’ to pointer type ‘int*’
[-Wconversion-null]
 int * foo() {return false;}
                     ^

As does using -save-temps:

g++-4.8 -std=c++11 -save-temps -c nowarning.cpp
nowarning.cpp: In function ‘int* foo()’:
nowarning.cpp:2:21: warning: converting ‘false’ to pointer type ‘int*’
[-Wconversion-null]
 int * foo() {return false;}
                     ^




Version information:
g++-4.8 -std=c++11 -v -c nowarning.cpp
Using built-in specs.
COLLECT_GCC=g++-4.8
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.8.1-2ubuntu1~12.04' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.1 (Ubuntu 4.8.1-2ubuntu1~12.04) 
COLLECT_GCC_OPTIONS='-std=c++11' '-v' '-c' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/4.8/cc1plus -quiet -v -imultilib . -imultiarch
x86_64-linux-gnu -D_GNU_SOURCE nowarning.cpp -quiet -dumpbase nowarning.cpp
-mtune=generic -march=x86-64 -auxbase nowarning -std=c++11 -version
-fstack-protector -o /tmp/ccCyoaqJ.s
GNU C++ (Ubuntu 4.8.1-2ubuntu1~12.04) version 4.8.1 (x86_64-linux-gnu)
    compiled by GNU C version 4.8.1, GMP version 5.0.2, MPFR version 3.1.0-p3,
MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/4.8"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/4.8
 /usr/include/x86_64-linux-gnu/c++/4.8/.
 /usr/include/c++/4.8/backward
 /usr/lib/gcc/x86_64-linux-gnu/4.8/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/4.8/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
GNU C++ (Ubuntu 4.8.1-2ubuntu1~12.04) version 4.8.1 (x86_64-linux-gnu)
    compiled by GNU C version 4.8.1, GMP version 5.0.2, MPFR version 3.1.0-p3,
MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 227d7ccf008db5ae401be7ddcc6b4746
COLLECT_GCC_OPTIONS='-std=c++11' '-v' '-c' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 as -v --64 -o nowarning.o /tmp/ccCyoaqJ.s
GNU assembler version 2.22 (x86_64-linux-gnu) using BFD version (GNU Binutils
for Ubuntu) 2.22
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.8/:/usr/lib/gcc/x86_64-linux-gnu/4.8/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.8/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.8/:/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-std=c++11' '-v' '-c' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
>From gcc-bugs-return-444520-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Feb 21 16:00:01 2014
Return-Path: <gcc-bugs-return-444520-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 3795 invoked by alias); 21 Feb 2014 16:00:01 -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 3769 invoked by uid 48); 21 Feb 2014 15:59:58 -0000
From: "bug-reports at psdtechnologies dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug preprocessor/60304] Including <atomic> disables -Wconversion-null
Date: Fri, 21 Feb 2014 16:00:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: preprocessor
X-Bugzilla-Version: 4.8.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: bug-reports at psdtechnologies 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-60304-4-GNwatGETx3@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60304-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60304-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-02/txt/msg02277.txt.bz2
Content-length: 244

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

--- Comment #1 from bug-reports at psdtechnologies dot com ---
Created attachment 32191
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id2191&actioníit
Similar code behaving as expected

[Bug preprocessor/60304] Including <atomic> disables -Wconversion-null

[harald at gigawatt dot nl]

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

Harald van Dijk <harald at gigawatt dot nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |harald at gigawatt dot nl

--- Comment #2 from Harald van Dijk <harald at gigawatt dot nl> ---
The warning is suppressed because it is supposedly from a system header (even
though clearly, that is not the case) and including -Wsystem-headers on the
command-line shows:

$ gcc-run/bin/g++ -std=c++11 -c test.cc -Wsystem-headers
In file included from
/home/harald/gcc-run/include/c++/4.9.0/bits/atomic_base.h:36:0,
                 from /home/harald/gcc-run/include/c++/4.9.0/atomic:41,
                 from test.cc:2:
test.cc: In function ‘int* foo()’:
test.cc:3:21: warning: converting ‘false’ to pointer type ‘int*’
[-Wconversion-null]
 int * foo() {return false;}
                     ^
>From gcc-bugs-return-444523-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Feb 21 18:51:53 2014
Return-Path: <gcc-bugs-return-444523-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 2718 invoked by alias); 21 Feb 2014 18:51:52 -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 2674 invoked by uid 48); 21 Feb 2014 18:51:49 -0000
From: "jason at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/60241] [4.7/4.8/4.9 Regression] internal compiler error: in finish_member_declaration, at cp/semantics.c:2617
Date: Fri, 21 Feb 2014 18:51: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.7.2
X-Bugzilla-Keywords: accepts-invalid, ice-on-invalid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jason at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: jason at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.7.4
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status assigned_to
Message-ID: <bug-60241-4-lqGoBtiuVK@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60241-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60241-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-02/txt/msg02280.txt.bz2
Content-length: 374

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

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |jason at gcc dot gnu.org

[Bug c++/60304] Including <atomic> disables -Wconversion-null

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jwakely.gcc at gmail dot com,
                   |                            |paolo.carlini at oracle dot com

--- Comment #4 from Paolo Carlini <paolo.carlini at oracle dot com> ---
This weird issue has to do with <atomic> including <stdbool.h> via
atomic_base.h. I don't know why it does that. (minor, unrelated, nit I also
noticed: when <atomic> sees __cplusplus < 201103L it should *only* include
c++0x_warning.h).

Jon, any idea about <stdbool.h>? Out of curiousity, want to see if something
breaks if I simply comment it out...

[Bug c++/60304] Including <atomic> disables -Wconversion-null

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

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

--- Comment #5 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Well, of course the user can always explicitly include, eg, <cstdbool>, thus it
seems that the real underlying issue is that the system-headers machinery
should not be fooled by things like this in a system header... or should it?
The define is rather interesting...

#define false false

I'm adding in CC Dodji too...

[Bug c++/60304] Including <atomic> disables -Wconversion-null

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Paolo Carlini from comment #5)
> #define false false

No idea what's going on, but I think I have a patch somewhere to disable that
macro for C++, it's very explicitly non-conforming:

[support.runtime]/8

"The header <cstdbool> and the header <stdbool.h> shall not define macros named
bool, true, or false."

Let me dig out the old patch. I also remember some discussion with Joseph IIRC.

[Bug c++/60304] Including <atomic> disables -Wconversion-null

[paolo.carlini at oracle dot com]

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

--- Comment #7 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Ah, that makes a lot of sense! If testing goes well, I mean to commit the
below, which in any case shouldn't hurt:

Index: include/bits/atomic_base.h
===================================================================
--- include/bits/atomic_base.h  (revision 216624)
+++ include/bits/atomic_base.h  (working copy)
@@ -33,7 +33,6 @@
 #pragma GCC system_header

 #include <bits/c++config.h>
-#include <stdbool.h>
 #include <stdint.h>
 #include <bits/atomic_lockfree_defines.h>

Index: include/std/atomic
===================================================================
--- include/std/atomic  (revision 216624)
+++ include/std/atomic  (working copy)
@@ -36,7 +36,7 @@

 #if __cplusplus < 201103L
 # include <bits/c++0x_warning.h>
-#endif
+#else

 #include <bits/atomic_base.h>

@@ -1129,4 +1129,6 @@
 _GLIBCXX_END_NAMESPACE_VERSION
 } // namespace

-#endif
+#endif // C++11
+
+#endif // _GLIBCXX_ATOMIC

[Bug c++/60304] Including <atomic> disables -Wconversion-null

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
See https://gcc.gnu.org/ml/gcc-patches/2012-01/msg00375.html

Gerald objected to the patch saying the dumb macros should be defined for C++98
mode or it will break code. Not sure I agree, but I'll adjust the patch to only
define them when __cplusplus < 201103L

[Bug c++/60304] Including <atomic> disables -Wconversion-null

[paolo.carlini at oracle dot com]

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

--- Comment #11 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Ah I see, then Dodji finally has the testcase he was looking for ;) Well, an
equivalent one not using stdbool, which Jon is going to patch. Over the next
week I will be mostly offline, unfortunately, please make sure Dodji sees it!

[Bug c++/60304] Including <atomic> disables -Wconversion-null

[redi at gcc dot gnu.org]

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

--- Comment #12 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #9)
> however, we do not do it in the case of 'false' (because we do not think it
> should be a macro, but it actually is). Perhaps we should do it, is there a
> downside to it?

The C++ standard explicitly forbids false from being a macro, it's a bug in
stdbool.h and IMHO the front-end should not be changed to accommodate the bug.
>From gcc-bugs-return-464917-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Oct 24 12:01:06 2014
Return-Path: <gcc-bugs-return-464917-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 997 invoked by alias); 24 Oct 2014 12:01:06 -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 926 invoked by uid 48); 24 Oct 2014 12:00:59 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/60304] Including <atomic> disables -Wconversion-null
Date: Fri, 24 Oct 2014 12:09: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.8.1
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: NEW
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: cc
Message-ID: <bug-60304-4-VD2WUqGg9B@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60304-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60304-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-10/txt/msg01938.txt.bz2
Content-length: 573

https://gcc.gnu.org/bugzilla/show_bug.cgi?id`304

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

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

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
But the C standard requires that it is a macro.  So, shouldn't just <cstdbool>
#undef false and #undef true, or does C++ behave a particular behavior also for
a header it doesn't own (stdbool.h)?

[Bug c++/60304] Including <atomic> disables -Wconversion-null

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Ah, as stdbool.h documents, using it in C++ (apparently meant C++98) is a GNU
extension, and for that I bet having those macros is desirable.
And then there is C++11 [support.runtime]/8 that requires it is not done:
"The header <cstdbool> and the header <stdbool.h> shall not define macros named
bool, true, or false."
So, perhaps those macros should be conditional on C++ version?

[Bug c++/60304] Including <atomic> disables -Wconversion-null

[redi at gcc dot gnu.org]

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

--- Comment #15 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Yes, that's what the patch I'm testing does.

IMHO we should only define it for -std=gnu++98 and not any other -std mode, but
I'll be conservative and leave it defined for -std=c++98 as well.

[Bug c++/60304] Including <atomic> disables -Wconversion-null

[manu at gcc dot gnu.org]

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

--- Comment #16 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #15)
> Yes, that's what the patch I'm testing does.
> 
> IMHO we should only define it for -std=gnu++98 and not any other -std mode,
> but I'll be conservative and leave it defined for -std=c++98 as well.

Thus, the warning also needs fixing. Since the same behavior will occur if the
user directly or indirectly includes stdbool.h.

A testcase:

# 1 "false.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "false.c"
# 1 "sys.h" 1

# 2 "sys.h" 3
# 2 "false.c" 2
int * foo() {return 
# 2 "false.c" 3
                   false
# 2 "false.c"
                        ;}
# 1 "nonsys.h" 1
# 4 "false.c" 2
int * bar() {return false;}
>From gcc-bugs-return-464922-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Oct 24 13:23:16 2014
Return-Path: <gcc-bugs-return-464922-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 5798 invoked by alias); 24 Oct 2014 13:23:15 -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 5727 invoked by uid 48); 24 Oct 2014 13:23:07 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/60304] Including <atomic> disables -Wconversion-null
Date: Fri, 24 Oct 2014 13:34: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.8.1
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: NEW
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-60304-4-kyuw8Z2nfL@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60304-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60304-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg01943.txt.bz2
Content-length: 533

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

--- Comment #17 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #16)
> A testcase:

==> sys.h <==
#pragma GCC system_header
#if defined false
#undef false
#endif
#define false false


==> nonsys.h <==
#if defined false
#undef false
#endif
#define false false


==> false.c <==
#include "sys.h"
int * foo() {return false;}
#include "nonsys.h"
int * bar() {return false;}
>From gcc-bugs-return-464923-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Oct 24 13:34:56 2014
Return-Path: <gcc-bugs-return-464923-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 16055 invoked by alias); 24 Oct 2014 13:34:56 -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 16013 invoked by uid 48); 24 Oct 2014 13:34:52 -0000
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/60304] Including <atomic> disables -Wconversion-null
Date: Fri, 24 Oct 2014 13:45: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.8.1
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi at gcc dot gnu.org
X-Bugzilla-Status: NEW
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-60304-4-DaMdap5XLJ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60304-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60304-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-10/txt/msg01944.txt.bz2
Content-length: 464

https://gcc.gnu.org/bugzilla/show_bug.cgi?id`304

--- Comment #18 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I assume that testcase is meant to be C++ (because it isn't valid C) but it's
not valid C++ either:

17.6.4.3.1 [macro.names]
"A translation unit that includes a header shall not contain any macros that
define names declared or defined in that header. Nor shall such a translation
unit define macros for names lexically identical to keywords."

[Bug c++/60304] Including <atomic> disables -Wconversion-null

[manu at gcc dot gnu.org]

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

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

--- Comment #19 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #18)
> I assume that testcase is meant to be C++ (because it isn't valid C) but
> it's not valid C++ either:
> 
> 17.6.4.3.1 [macro.names]
> "A translation unit that includes a header shall not contain any macros that
> define names declared or defined in that header. Nor shall such a
> translation unit define macros for names lexically identical to keywords."

This is exactly what G++'s stdbool.h is doing with -std=gnu++98 and -std=c++98.

(Also, why is this not an error with -std=c++11 -pedantic-errors?)
>From gcc-bugs-return-464925-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Oct 24 13:49:04 2014
Return-Path: <gcc-bugs-return-464925-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 25444 invoked by alias); 24 Oct 2014 13:49:03 -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 25416 invoked by uid 48); 24 Oct 2014 13:49:00 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/60304] Including <atomic> disables -Wconversion-null
Date: Fri, 24 Oct 2014 14:15: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.8.1
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: NEW
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-60304-4-ZFq6RIcq46@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60304-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60304-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg01946.txt.bz2
Content-length: 707

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

--- Comment #20 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #19)
> (In reply to Jonathan Wakely from comment #18)
> > 17.6.4.3.1 [macro.names]
> > "A translation unit that includes a header shall not contain any macros that
> > define names declared or defined in that header. Nor shall such a
> > translation unit define macros for names lexically identical to keywords."
> (Also, why is this not an error with -std=c++11 -pedantic-errors?)

In fact, if that quote appears in C++98, then it should be an error with
-pedantic-errors in any C++ -std= mode.
>From gcc-bugs-return-464927-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Oct 24 14:17:03 2014
Return-Path: <gcc-bugs-return-464927-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 29933 invoked by alias); 24 Oct 2014 14:17:02 -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 29867 invoked by uid 48); 24 Oct 2014 14:16:59 -0000
From: "gjl at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/63633] [avr] internal compiler error: unrecognizable insn with mult insns
Date: Fri, 24 Oct 2014 14:17:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 4.9.1
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: gjl at gcc dot gnu.org
X-Bugzilla-Status: NEW
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-63633-4-YxX92byaUq@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63633-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63633-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-10/txt/msg01948.txt.bz2
Content-length: 258

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

--- Comment #1 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
Created attachment 33801
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id3801&actioníit
C test case that also generates wrong code

[Bug c++/60304] Including <atomic> disables -Wconversion-null

[redi at gcc dot gnu.org]

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

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

--- Comment #21 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #19) 
> This is exactly what G++'s stdbool.h is doing with -std=gnu++98 and
> -std=c++98.

<stdbool.h> is a "header" which is C++ standardese for a standard library
header. The rule only applies to user code, not std::lib headers. In your
testcase sys.h is OK but nonsys.h is not.

Although you can argue that since <stdbool.h> is not defined by the C++98
standard it is not a "header" and must not define the macro in __STRICT_ANSI__
mode.

> (Also, why is this not an error with -std=c++11 -pedantic-errors?)

Because noone has ever implemented the diagnostic. Note that it only applies to
user-code that includes a "header" so it's OK to define macros using the names
of keywords as long as you never include a standard header. That makes it a bit
more complicated to implement the diagnostic.
>From gcc-bugs-return-464931-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Oct 24 14:51:36 2014
Return-Path: <gcc-bugs-return-464931-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 26415 invoked by alias); 24 Oct 2014 14:51:36 -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 26360 invoked by uid 48); 24 Oct 2014 14:51:33 -0000
From: "y.gribov at samsung dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug sanitizer/63638] [4.9 Regression] internal compiler error: in asan_expand_check_ifn (with -fsanitize­dress)
Date: Fri, 24 Oct 2014 14:58:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: sanitizer
X-Bugzilla-Version: 4.9.2
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: y.gribov at samsung 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: cc attachments.created
Message-ID: <bug-63638-4-OeWaGieiqi@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63638-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63638-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-10/txt/msg01952.txt.bz2
Content-length: 760

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

Yury Gribov <y.gribov at samsung dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |y.gribov at samsung dot com

--- Comment #1 from Yury Gribov <y.gribov at samsung dot com> ---
Created attachment 33803
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id3803&actioníit
Proposed patch

Thanks, I was aware of this problem. For GCC 5.0 Maxim is going to fix this
with his dont-sanitize-builtins patch (currently reviewed in gcc-patches). Here
is a trivial patch for 4.9 but I only had time to perform short regtesting
(make check RUNTESTFLAGS=asan.exp).

[Bug c++/60304] Including <atomic> disables -Wconversion-null

[manu at gcc dot gnu.org]

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

--- Comment #22 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #21)
> (In reply to Manuel López-Ibáñez from comment #19) 
> > This is exactly what G++'s stdbool.h is doing with -std=gnu++98 and
> > -std=c++98.
> 
> <stdbool.h> is a "header" which is C++ standardese for a standard library
> header. The rule only applies to user code, not std::lib headers. In your
> testcase sys.h is OK but nonsys.h is not.

We can drop the nonsys.h case. It is only testing that the no system_headers
case also works (according to your other comment, it will be valid if no
system_header is included).

My point is that the fix cannot be only limited to tweaking stdbool.h, as long
as any C++ mode still defines false as a macro.
>From gcc-bugs-return-464940-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Oct 24 16:20:49 2014
Return-Path: <gcc-bugs-return-464940-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 25488 invoked by alias); 24 Oct 2014 16:20:49 -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 25420 invoked by uid 48); 24 Oct 2014 16:20:44 -0000
From: "evstupac at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
Date: Fri, 24 Oct 2014 16:28: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: 5.0
X-Bugzilla-Keywords: ice-on-valid-code, wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: evstupac at gmail dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63534-4-AcrKiwkjy5@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63534-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63534-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg01961.txt.bz2
Content-length: 785

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

--- Comment #43 from Stupachenko Evgeny <evstupac at gmail dot com> ---
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #42)
> > --- Comment #41 from Stupachenko Evgeny <evstupac at gmail dot com> ---
> > (In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #40)
> [...]
> > That should be not "EBX enablig" issue as pointed in comments 17 and 35.
> > I'm testing bootstrap like in comment 34 and it passed.
> 
> Adding --with-arch=core2 --with-cpu=core2 didn't make any difference.
> 
> 	Rainer

The core thing in comment 34 is "patch in comment 33 applied on top of
r216304".

Most likely after r216304 someone broke darwin bootstrap again.
So to test my changes I use revision r216304 with patch from commnet 33.
>From gcc-bugs-return-464941-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Oct 24 16:28:22 2014
Return-Path: <gcc-bugs-return-464941-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 32573 invoked by alias); 24 Oct 2014 16:28:21 -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 32514 invoked by uid 48); 24 Oct 2014 16:28:18 -0000
From: "iains at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
Date: Fri, 24 Oct 2014 16:30: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: 5.0
X-Bugzilla-Keywords: ice-on-valid-code, wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: iains at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63534-4-awst8aHfLu@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63534-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63534-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg01962.txt.bz2
Content-length: 1177

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

--- Comment #44 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Stupachenko Evgeny from comment #43)
> (In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #42)
> > > --- Comment #41 from Stupachenko Evgeny <evstupac at gmail dot com> ---
> > > (In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #40)
> > [...]
> > > That should be not "EBX enablig" issue as pointed in comments 17 and 35.
> > > I'm testing bootstrap like in comment 34 and it passed.
> > 
> > Adding --with-arch=core2 --with-cpu=core2 didn't make any difference.
> > 
> > 	Rainer
> 
> The core thing in comment 34 is "patch in comment 33 applied on top of
> r216304".
> 
> Most likely after r216304 someone broke darwin bootstrap again.
> So to test my changes I use revision r216304 with patch from commnet 33.

there were at one point this week 4 concurrent bootstrap breaks on dariwn.

this PR.
the ipa-icf series
requiring non-weak aliases
and the iconv dep on libcpp.

I don't know how many of those have been fixed so far - but I suspect that not
all have.  Unfortunately, not able to be more explict right now.
>From gcc-bugs-return-464943-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Oct 24 16:31:14 2014
Return-Path: <gcc-bugs-return-464943-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 7430 invoked by alias); 24 Oct 2014 16:31:13 -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 7381 invoked by uid 55); 24 Oct 2014 16:31:10 -0000
From: "ro at CeBiTec dot Uni-Bielefeld.DE" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
Date: Fri, 24 Oct 2014 16:31: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: 5.0
X-Bugzilla-Keywords: ice-on-valid-code, wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ro at CeBiTec dot Uni-Bielefeld.DE
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63534-4-eM9394cVvo@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63534-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63534-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-10/txt/msg01964.txt.bz2
Content-length: 824

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

--- Comment #45 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #44 from Iain Sandoe <iains at gcc dot gnu.org> ---
> (In reply to Stupachenko Evgeny from comment #43)
[...]
> there were at one point this week 4 concurrent bootstrap breaks on dariwn.
>
> this PR.
> the ipa-icf series
> requiring non-weak aliases
> and the iconv dep on libcpp.
>
> I don't know how many of those have been fixed so far - but I suspect that not
> all have.  Unfortunately, not able to be more explict right now.

Thanks for the update.  As I said, I'd completely lost track of what's
going on here.

I'm now testing the rev before Evgeny's patch to check if that
bootstraps on 10.10.  If not, we may have yet another issue here.

    Rainer

[Bug c++/60304] Including <stdbool.h> disables -Wconversion-null in C++ 98 mode

[redi at gcc dot gnu.org]

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

--- Comment #26 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #22)
> My point is that the fix cannot be only limited to tweaking stdbool.h, as
> long as any C++ mode still defines false as a macro.

As I said in comment 18, C++ programs can't do that. Ever.

I'm going to try again to remove those macros from <stdbool.h> for C++ ...

[Bug c++/60304] Including <stdbool.h> disables -Wconversion-null in C++ 98 mode

[redi at gcc dot gnu.org]

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

--- Comment #27 from Jonathan Wakely <redi at gcc dot gnu.org> ---
The original testcase gets a warning even for -std=c++98 now, thanks to
dmalcolm's r268589 (included in GCC 9.1).

[Bug c++/60304] Including <stdbool.h> disables -Wconversion-null in C++ 98 mode

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

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

--- Comment #28 from Jonathan Wakely <redi at gcc dot gnu.org> ---
However, the preprocessed version doesn't warn even with current trunk:

# 1 "b.C"
# 1 "/home/jwakely/gcc/9/lib/gcc/x86_64-pc-linux-gnu/9.3.1/include/stdbool.h" 1
3 4
# 2 "b.C" 2
int * foo() {return 
# 2 "b.C" 3 4
                   false
# 2 "b.C"
                        ;}

Dave, any idea why your fix for PR 71302 causes us to warn for the following,
but not when it's already been preprocessed (as above)?

#include <stdbool.h>
int* foo() {return false;}

It's not a big deal, since we do issue the expected warning during normal
compilation, and I'm going to try to remove the macros from <stdbool.h> anyway.

[Bug c++/60304] Including <stdbool.h> disables -Wconversion-null in C++ 98 mode

[cvs-commit at gcc dot gnu.org]

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

--- Comment #29 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jonathan Wakely <redi@gcc.gnu.org>:

https://gcc.gnu.org/g:f049cda373d29ea1bce4065b24cbb392cdc5b172

commit r11-2985-gf049cda373d29ea1bce4065b24cbb392cdc5b172
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Wed Sep 2 18:51:28 2020 +0100

    c++: Stop defining true, false and bool as macros in <stdbool.h>

    Since r216679 these macros have only been defined in C++98 mode, rather
    than all modes. That is permitted as a GNU extension because that header
    doesn't exist in the C++ standard until C++11, so we can make it do
    whatever we want for C++98. But as discussed in the PR c++/60304
    comments, these macros shouldn't ever be defined for C++.

    This patch removes the macro definitions for C++98 too.

    The new test already passed for C++98 (and the conversion is ill-formed
    in C++11 and later) so this new test is arguably unnecessary.

    gcc/ChangeLog:

            PR c++/60304
            * ginclude/stdbool.h (bool, false, true): Never define for C++.

    gcc/testsuite/ChangeLog:

            PR c++/60304
            * g++.dg/warn/Wconversion-null-5.C: New test.

[Bug c++/60304] Including <stdbool.h> disables -Wconversion-null in C++ 98 mode

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #30 from Jonathan Wakely <redi at gcc dot gnu.org> ---
The testcase warns in C++98 mode (and is ill-formed in other modes) and the
macros are gone now anyway. While I'm curious why the preprocessed code in
comment 28 doesn't warn, I think we can call this fixed now.

[Bug c++/60304] Including <stdbool.h> disables -Wconversion-null in C++ 98 mode

[harald at gigawatt dot nl]

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

--- Comment #31 from Harald van Dijk <harald at gigawatt dot nl> ---
(In reply to Jonathan Wakely from comment #30)
> I'm curious why the preprocessed code in comment 28 doesn't warn,

This was still bugging me, so I looked into it a little bit, and since I had
trouble finding this written down somewhere I thought it would be worth
including here. The line "# 2 "b.C" 3 4" means that what follows is line 2 of
b.C, and b.C is a C system header. The relevant bits of GCC code to see this
are

 
https://github.com/gcc-mirror/gcc/blob/releases/gcc-10.2.0/libcpp/directives.c#L1061
 
https://github.com/gcc-mirror/gcc/blob/releases/gcc-10.2.0/libcpp/internal.h#L358

So this means that "false" is coming from a system header. It is: it is coming
from the macro expansion of "false", and the macro definition was in a system
header. So far, so good.

However, during normal operation, with the integrated preprocessor, when a
warning would be emitted in a system header, that
get_location_for_expr_unwinding_for_system_header function added by the commit
you were asking about,
https://github.com/gcc-mirror/gcc/blob/releases/gcc-10.2.0/gcc/cp/call.c#L7146,
would change the warning location to that of the macro expansion point, if the
warning location was actually inside a macro definition from a system header.
Such macro unwinding is not possible when the preprocessor is invoked
separately, as this information is missing in the -E output. A
non-system-header effect of this can be seen in this test:

test.h:

  #define FALSE false

test.cc:

  #include "test.h"
  void *p = FALSE;

g++ -std=c++03 -c test.cc:

In file included from test.cc:1:
test.h:1:15: warning: converting ‘false’ to pointer type ‘void*’
[-Wconversion-null]
    1 | #define FALSE false
      |               ^~~~~
test.cc:2:11: note: in expansion of macro ‘FALSE’
    2 | void *p = FALSE;
      |           ^~~~~

g++ -std=c++03 -c test.cc -save-temps
test.cc:2:11: warning: converting ‘false’ to pointer type ‘void*’
[-Wconversion-null]
    2 | void *p = FALSE;
      |           ^~~~~

The addition of -save-temps causes the "note: in expansion of macro ‘FALSE’" to
go missing, because the information needed to produce that note is gone by the
time the warning is emitted: the macro expansion tracking is only available at
preprocessing time. It was that macro expansion tracking functionality that GCC
needs to determine that really, the warning should be treated as *not* coming
from a system header, even though it really was.

In short: I think there is no lingering bug here, this is just an unfortunate
result of the current design. However, if you disagree, if you think the macro
expansion tracking state should be included somehow in the preprocessor output
so that the compiler always has access to it, I can report that as a new bug if
you like.

[Bug c++/60304] Including <stdbool.h> disables -Wconversion-null in C++ 98 mode

[redi at gcc dot gnu.org]

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

--- Comment #32 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Nice analysis. Personally I dislike when you get different results from
separate preprocessing, but I don't know if it should be considered a bug.