https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304
--- Comment #32 from Jonathan Wakely ---
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304
--- Comment #31 from Harald van Dijk ---
(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 find
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304
--- Comment #29 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:f049cda373d29ea1bce4065b24cbb392cdc5b172
commit r11-2985-gf049cda373d29ea1bce4065b24cbb392cdc5b172
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304
Jonathan Wakely changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304
--- Comment #27 from Jonathan Wakely ---
The original testcase gets a warning even for -std=c++98 now, thanks to
dmalcolm's r268589 (included in GCC 9.1).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304
--- Comment #26 from Jonathan Wakely ---
(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 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #25
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304
--- Comment #24 from Jonathan Wakely ---
(In reply to Martin Sebor from comment #23)
> What doesn't work correctly is including in the test case and
> compiling it in C++ 98 mode. The test case below shows there's still no
> warning there. Thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304
Martin Sebor changed:
What|Removed |Added
Last reconfirmed|2014-10-06 00:00:00 |2016-1-4
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304
--- Comment #22 from Manuel López-Ibáñez ---
(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.
>
> is a "
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304
--- Comment #21 from Jonathan Wakely ---
(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.
is a "header" which is C++ standardese for a standard library
heade
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304
--- Comment #19 from Manuel López-Ibáñez ---
(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 uni
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304
--- Comment #20 from Manuel López-Ibáñez ---
(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 mac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304
--- Comment #18 from Jonathan Wakely ---
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
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304
--- Comment #17 from Manuel López-Ibáñez ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304
--- Comment #16 from Manuel López-Ibáñez ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304
--- Comment #15 from Jonathan Wakely ---
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304
--- Comment #14 from Jakub Jelinek ---
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 n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304
--- Comment #12 from Jonathan Wakely ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304
--- Comment #11 from Paolo Carlini ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304
--- Comment #10 from Manuel López-Ibáñez ---
(In reply to Manuel López-Ibáñez from comment #9)
> (In reply to Paolo Carlini from comment #5)
> > Well, of course the user can always explicitly include, eg, , thus
> > it seems that the real underly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304
--- Comment #9 from Manuel López-Ibáñez ---
(In reply to Paolo Carlini from comment #5)
> Well, of course the user can always explicitly include, eg, , thus
> it seems that the real underlying issue is that the system-headers machinery
> should n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304
--- Comment #8 from Jonathan Wakely ---
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 th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304
--- Comment #7 from Paolo Carlini ---
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
==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304
--- Comment #6 from Jonathan Wakely ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304
Paolo Carlini changed:
What|Removed |Added
CC||dodji at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304
Paolo Carlini changed:
What|Removed |Added
CC||jwakely.gcc at gmail dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304
Manuel López-Ibáñez changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCO
30 matches
Mail list logo
