[Bug libstdc++/82039] New: -Wzero-as-null-pointer-constant triggers when calling std::allocate<...>::allocate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82039 Bug ID: 82039 Summary: -Wzero-as-null-pointer-constant triggers when calling std::allocate<...>::allocate Product: gcc Version: 7.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: max at maxbruckner dot de Target Milestone: --- Created attachment 42087 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42087=edit Code to reproduce the problem gcc 7.1.1 emits a warning when enabling -Wzero-as-null-pointer-constant and calling the allocate member function of std::allocator provided by libstdc++. This only happens when calling allocate with only one parameter. So a workaround is calling it with the second parameter set to nullptr. I think this is due to the default parameter for the second parameter being a 0 instead of nullptr (not sure though, since I couldn't find the actual implementation in the header files.
[Bug libstdc++/81749] std::align: runtime error: negation of 8 cannot be represented in type 'size_t'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81749 --- Comment #10 from Max Bruckner --- (In reply to Jakub Jelinek from comment #9) > (In reply to Max Bruckner from comment #8) > > Nevertheless I disagree that there is no "overflow" or "underflow". It's a > > question of how you define the two words, in a way, but being defined > > doesn't make less of an underflow/overflow. > > > > This is no bug, since std::align exhibits totally defined behavior, but I > > still think that having a runtime check for unsigned overflow is quite > > useful, because although it might not be undefined, it might still be > > unintended behavior in many cases. > > I don't see how something like that can be ever useful. unsigned integral > types don't have negative values, so if you want to sometimes subtract and > sometimes add some value, but the condition when that happens is done e.g. > in another function, you just use one of the operations and use negated > numbers. That triggers this misdesigned sanitizer though of course. First let me define unsigned integer overflow: In my definition, overflow occurs when either an addition or multiplication (maybe left shift as well?) of/with a positive number yields a result that is smaller than the result would be with non-modular math. For example ((size_t)SIZE_MAX) + ((size_t)1U) which is 0, not SIZE_MAX + 1. Simple example: Something like calloc. If you calculate the size of a buffer with a multiplication, you might overflow it (or almost overflow it and later add something that overflows it). When you then go ahead and allocate some space for that buffer without checking, your caller might think that enough space was allocated and start using it, not knowing that it will go out of the bounds of the allocated memory region. This discussion is kind of off-topic, but I just couldn't let the following stand, because I find unsigned overflow detection very useful. > Yeah, it is IMHO a very big mistake clang added that, we have conciously > added only signed-integer-overflow sanitizer, but not unsigned.
[Bug libstdc++/81749] std::align: runtime error: negation of 8 cannot be represented in type 'size_t'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81749 --- Comment #8 from Max Bruckner --- I understand how unsigned integers work and that they are defined by the standard to have modular arithmetic. In this case I just didn't add 1 and 1 together I guess. Nevertheless I disagree that there is no "overflow" or "underflow". It's a question of how you define the two words, in a way, but being defined doesn't make less of an underflow/overflow. This is no bug, since std::align exhibits totally defined behavior, but I still think that having a runtime check for unsigned overflow is quite useful, because although it might not be undefined, it might still be unintended behavior in many cases.
[Bug libstdc++/81749] std::align: runtime error: negation of 8 cannot be represented in type 'size_t'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81749 --- Comment #6 from Max Bruckner --- Oh, you're right, unsigned overflow is defined of course. I guess I should report a bug with UBSan then to get a suppression included for libstdc++.
[Bug libstdc++/81749] std::align: runtime error: negation of 8 cannot be represented in type 'size_t'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81749 --- Comment #3 from Max Bruckner --- Created attachment 41946 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41946=edit Suppression file as a workaround. Add to UBSAN_OPTIONS=supressions=...
[Bug libstdc++/81749] std::align: runtime error: negation of 8 cannot be represented in type 'size_t'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81749 --- Comment #2 from Max Bruckner --- This is on x86_64
[Bug libstdc++/81749] std::align: runtime error: negation of 8 cannot be represented in type 'size_t'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81749 --- Comment #1 from Max Bruckner --- Created attachment 41945 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41945=edit Makefile to reproduce the error
[Bug libstdc++/81749] New: std::align: runtime error: negation of 8 cannot be represented in type 'size_t'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81749 Bug ID: 81749 Summary: std::align: runtime error: negation of 8 cannot be represented in type 'size_t' Product: gcc Version: 7.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: max at maxbruckner dot de Target Milestone: --- Created attachment 41944 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41944=edit C++ file to reproduce the error When compiling code with clangs undefined behavior sanitizer (clang++ 4.0.1 -fsanitize=unsigned-integer-overflow) that uses std::align, a runtime error occurs: /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../include/c++/7.1.1/memory:117:54: runtime error: negation of 8 cannot be represented in type 'size_t' (aka 'unsigned long') The issue can be reproduced with the C++ and Makefile from the attachments. The full output of my test: alignof(intmax_t) = 8 alloced = 0x5606f17e7c21 /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../include/c++/7.1.1/memory:117:54: runtime error: negation of 8 cannot be represented in type 'size_t' (aka 'unsigned long') address = 0x5606f17e7c28 space = 92
[Bug c/80097] internal compiler error in c_fully_fold_internal with std=c89 and -fsanitize=float-divide-by-zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80097 Max Bruckner changed: What|Removed |Added CC||max at maxbruckner dot de --- Comment #3 from Max Bruckner --- I already created a bug report in the Archlinux bug tracker here: https://bugs.archlinux.org/task/53368 but I could also reproduce the bug on Ubuntu 16.04.2 with GCC 5.4.0
[Bug c/80097] internal compiler error in c_fully_fold_internal with std=c89 and -fsanitize=float-divide-by-zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80097 --- Comment #2 from Max Bruckner --- I already created a bug report in the Archlinux bug tracker here: https://bugs.archlinux.org/task/53368 but I could also reproduce the bug on Ubuntu 16.04.2 with GCC 5.4.0
[Bug c/80097] internal compiler error in c_fully_fold_internal with std=c89 and -fsanitize=float-divide-by-zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80097 --- Comment #1 from Max Bruckner --- Created attachment 41000 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41000=edit Makefile with the compiler options necessary to reproduce the bug
[Bug c/80097] New: internal compiler error in c_fully_fold_internal with std=c89 and -fsanitize=float-divide-by-zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80097 Bug ID: 80097 Summary: internal compiler error in c_fully_fold_internal with std=c89 and -fsanitize=float-divide-by-zero Product: gcc Version: 6.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: max at maxbruckner dot de Target Milestone: --- Created attachment 40999 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40999=edit C file to reproduce the bug When building the attached C source file with GCC 6.3.1 or GCC 5.4.0 on an x86 (32bit) system and the compiler flags '-std=c89 -fsanitize=float-divide-by-zero', an internal compiler error happens. It doesn't happen on x86_64, ppc or armv7 from what I tested. Output for GCC 5.4.0: gcc-5 -std=c89 -fsanitize=float-divide-by-zero bug.c -c bug.c: In function ‘bug’: bug.c:3:2: internal compiler error: in c_fully_fold_internal, at c-family/c-common.c:1545 int test = (1 / number >= 1); ^ Please submit a full bug report, with preprocessed source if appropriate. See <https://bugs.archlinux.org/> for instructions. make: *** [Makefile:2: bug] Error 1 Output for GCC 6.0.3: cc -std=c89 -fsanitize=float-divide-by-zero bug.c -c bug.c: In function ‘bug’: bug.c:3:2: internal compiler error: in c_fully_fold_internal, at c/c-fold.c:558 int test = (1 / number >= 1); ^~~ Please submit a full bug report, with preprocessed source if appropriate. See <https://bugs.archlinux.org/> for instructions. make: *** [Makefile:2: bug] Error 1
[Bug c/79881] New: -Wc++-compat should warn about sizeof character literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79881
Bug ID: 79881
Summary: -Wc++-compat should warn about sizeof character
literals
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: max at maxbruckner dot de
Target Milestone: ---
The c++-compat warning should warn about uses of sizeof when used with
character literals, because in C++ sizeof(' ') is the same as sizeof(char)
whereas it is sizeof(int) in C, therefore this is not part of the common subset
between C and C++ and should be warned about.
