[Bug c++/107461] [12 Regression] ambiguity error for friend with templated constexpr argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107461
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7 from Jakub Jelinek ---
Reduced testcase:
template T foo ();
template using A = int;
template
auto operator| (T, U) -> decltype (U() (T()));
template struct B {
template () (0, foo
()))>>
void operator() (U);
};
struct {
template
B operator() (T, U) { return B (); }
} c;
struct D {
D() {
c([] {}, 0);
}
struct E {
};
void bar ()
{
E f;
f | c ([] (int, E) {}, 0);
}
};
[Bug c++/107461] [12 Regression] ambiguity error for friend with templated constexpr argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107461 Jakub Jelinek changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #8 from Jakub Jelinek --- .
[Bug c++/107461] [12/13 Regression] ambiguity error for friend with templated constexpr argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107461 Jakub Jelinek changed: What|Removed |Added Priority|P2 |P1 Summary|[12 Regression] ambiguity |[12/13 Regression] |error for friend with |ambiguity error for friend |templated constexpr |with templated constexpr |argument|argument
[Bug middle-end/108657] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108657 --- Comment #5 from David Binderman --- (In reply to David Binderman from comment #0) > Also, the possible bug seems to have first occurred sometime before 20230103 Also before 20221201: $ /home/dcb36/gcc/results.20221201/bin/gcc -w -O3 -ftrivial-auto-var-init=zero bug880.c $ ./a.out checksum = BCC02729 $ /home/dcb36/gcc/results.20221201/bin/gcc -v 2>&1 | fgrep exp gcc version 13.0.0 20221130 (experimental) (d0a3d55ae4a2656f) $
[Bug middle-end/108657] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108657 --- Comment #6 from David Binderman --- (In reply to David Binderman from comment #5) > (In reply to David Binderman from comment #0) > > Also, the possible bug seems to have first occurred sometime before 20230103 > > Also before 20221201: And before 20221101: $ /home/dcb36/gcc/results.20221101/bin/gcc -w -O3 -ftrivial-auto-var-init=zero bug880.c $ ./a.out checksum = BCC02729 $ /home/dcb36/gcc/results.20221101/bin/gcc -v 2>&1 | fgrep exp gcc version 13.0.0 20221101 (experimental) (4acc4c2be84d6607) $
[Bug middle-end/108657] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108657 --- Comment #7 from David Binderman --- I can only go back as far as 20221028, when the git tree was installed. $ /home/dcb36/gcc/results.20221028/bin/gcc -w -O3 -ftrivial-auto-var-init=zero bug880.c $ ./a.out checksum = BCC02729 $ /home/dcb36/gcc/results.20221028/bin/gcc -v 2>&1 | fgrep exp gcc version 13.0.0 20221028 (experimental) (8f2358724fa4) $ I will have a look at how to get at dates before the clone date.
[Bug target/108673] New: ICE with -fstack-clash-protection and noreturn attribute on x86_64-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108673
Bug ID: 108673
Summary: ICE with -fstack-clash-protection and noreturn
attribute on x86_64-w64-mingw32
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: lh_mouse at 126 dot com
Target Milestone: ---
Original reported by Théo Cavignac here:
https://sourceforge.net/p/mingw-w64/mailman/message/37773946/
The ICE is only reproducible on x86_64-w64-mingw32, not on i686-w64-mingw32.
Original testcase follows:
```
/*
/usr/bin/x86_64-w64-mingw32-gcc \
-O2 -fstack-clash-protection -c \
-freport-bug \
-o f.o f.c
*/
void exit(int) __attribute__((noreturn));
void foo(int p) {
exit(p);
}
```
```
# gcc -O2 -fstack-clash-protection f.c
during RTL pass: final
f.c: In function 'foo':
f.c:11:4: internal compiler error: in seh_emit_stackalloc, at
config/i386/winnt.cc:1055
11 |}
|^
libbacktrace could not find executable to open
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See for instructions.
```
[Bug fortran/108453] [10/11/12/13 Regression] ICE in gfc_trans_use_stmts, at fortran/trans-decl.cc:5361 since r6-3704-g2b3f52a2d0fb22ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108453 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:be8003ffcfb02dd8ef49ffec01bf96da2d973bc2 commit r11-10500-gbe8003ffcfb02dd8ef49ffec01bf96da2d973bc2 Author: Harald Anlauf Date: Sat Jan 28 17:59:23 2023 +0100 Fortran: diagnose USE associated symbols in COMMON blocks [PR108453] gcc/fortran/ChangeLog: PR fortran/108453 * match.c (gfc_match_common): A USE associated name shall not appear in a COMMON block (F2018:C8121). gcc/testsuite/ChangeLog: PR fortran/108453 * gfortran.dg/common_27.f90: New test. (cherry picked from commit aba9ff8f30d4245294ea2583de1dc28f1c7ccf7b)
[Bug fortran/108421] ICE in get_expr_storage_size, at fortran/interface.cc:2862
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108421 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:2235737a967c9eeabe7b02ffb014d8efef3276af commit r11-10502-g2235737a967c9eeabe7b02ffb014d8efef3276af Author: Harald Anlauf Date: Mon Jan 16 21:30:56 2023 +0100 Fortran: fix ICE in get_expr_storage_size [PR108421] gcc/fortran/ChangeLog: PR fortran/108421 * interface.c (get_expr_storage_size): Check that we actually have an integer value before trying to extract it with mpz_get_si. gcc/testsuite/ChangeLog: PR fortran/108421 * gfortran.dg/pr108421.f90: New test. (cherry picked from commit a75760374ee54768e5fd6a27080698bfbbd041ab)
[Bug fortran/108502] ICE in gfc_check_dependency, at fortran/dependency.cc:1295
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108502 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:d7ec0bdfeae883d852d7c0dfc67766a3793f5892 commit r11-10503-gd7ec0bdfeae883d852d7c0dfc67766a3793f5892 Author: Harald Anlauf Date: Mon Jan 23 22:13:44 2023 +0100 Fortran: fix NULL pointer dereference in gfc_check_dependency [PR108502] gcc/fortran/ChangeLog: PR fortran/108502 * dependency.c (gfc_check_dependency): Prevent NULL pointer dereference while recursively checking expressions. gcc/testsuite/ChangeLog: PR fortran/108502 * gfortran.dg/pr108502.f90: New test. (cherry picked from commit 51767f31878a95161142254dca7119b409699670)
[Bug fortran/108501] [13 Regression] ICE in get_expr_storage_size, at fortran/interface.cc:2941
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108501 --- Comment #8 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:76a6f8470c8c786b271cb0d897de891fe0d4043f commit r11-10504-g76a6f8470c8c786b271cb0d897de891fe0d4043f Author: Harald Anlauf Date: Mon Jan 23 21:19:03 2023 +0100 Fortran: avoid ICE on invalid array subscript triplets [PR108501] gcc/fortran/ChangeLog: PR fortran/108501 * interface.c (get_expr_storage_size): Check array subscript triplets that we actually have integer values before trying to extract with mpz_get_si. gcc/testsuite/ChangeLog: PR fortran/108501 * gfortran.dg/pr108501.f90: New test. (cherry picked from commit 771d793df1622a476e1cf8d05f0a6aee350fa56b)
[Bug fortran/108420] [13 Regression] ICE in check_charlen_present, at fortran/iresolve.cc:98 since r13-4394-g3832c6f7e672e76b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108420 --- Comment #7 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:c3985fd624053502b0aad85132982b4f8970811a commit r11-10501-gc3985fd624053502b0aad85132982b4f8970811a Author: Harald Anlauf Date: Mon Jan 16 21:41:09 2023 +0100 Fortran: fix ICE in check_charlen_present [PR108420] gcc/fortran/ChangeLog: PR fortran/108420 * iresolve.c (check_charlen_present): Preserve character length if there is no array constructor. gcc/testsuite/ChangeLog: PR fortran/108420 * gfortran.dg/pr108420.f90: New test. (cherry picked from commit e6669c0a50ed8aee9e5997d61e6271668d149218)
[Bug fortran/106209] ICE in add_init_expr_to_sym, at fortran/decl.cc:2132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106209 --- Comment #7 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:8e58d94ac56127ebca3a893284455032a707d948 commit r11-10505-g8e58d94ac56127ebca3a893284455032a707d948 Author: Harald Anlauf Date: Thu Jul 14 22:24:55 2022 +0200 Fortran: error recovery for bad initializers of implied-shape arrays [PR106209] gcc/fortran/ChangeLog: PR fortran/106209 * decl.c (add_init_expr_to_sym): Handle bad initializers for implied-shape arrays. gcc/testsuite/ChangeLog: PR fortran/106209 * gfortran.dg/pr106209.f90: New test. Co-authored-by: Steven G. Kargl (cherry picked from commit 748f8a8b145dde59c7b63aa68b5a59515b7efc49)
[Bug fortran/108529] [10/11/12 Regression] ICE in transformational_result, at fortran/simplify.cc:478
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108529 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:60032329cde87a7505b7784e1dcfb09574ee2e90 commit r11-10506-g60032329cde87a7505b7784e1dcfb09574ee2e90 Author: Harald Anlauf Date: Tue Jan 24 21:39:43 2023 +0100 Fortran: ICE in transformational_result [PR108529] gcc/fortran/ChangeLog: PR fortran/108529 * simplify.c (simplify_transformation): Do not try to simplify transformational intrinsic when the ARRAY argument has a NULL shape. gcc/testsuite/ChangeLog: PR fortran/108529 * gfortran.dg/pr108529.f90: New test. (cherry picked from commit 6c96382eed96a9285611f2e3e2e59557094172b8)
[Bug target/108673] ICE with -fstack-clash-protection and noreturn attribute on x86_64-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108673
Christian Franke changed:
What|Removed |Added
CC||franke at computer dot org
--- Comment #1 from Christian Franke ---
Could also be reproduced with x86_64-pc-cygwin-gcc 11.3.0 and
x86_64-w64-mingw32-gcc 11.3.0 from current Cygwin distribution:
$ gcc -O1 -fstack-clash-protection -S f.c
during RTL pass: final
x.c: In function ‘foo’:
x.c:5:1: internal compiler error: in seh_emit_stackalloc, at
config/i386/winnt.c:1056
5 | }
| ^
...
The error does not occur if -fipa-pure-const ("Discover which functions are
pure or constant") is disabled:
$ gcc -O3 -fno-ipa-pure-const -fstack-clash-protection -S f.c; echo $?
0
Assembly output looks sane then.
[Bug fortran/107721] Lost typespec with constant expressions using array constructors and parentheses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107721 --- Comment #7 from Jerry DeLisle --- I should mention, this also fails: print *, [real:: ((/2, 3/))] ** 2 So we also have to deal with this. I think I have it figured out.
[Bug c++/70536] g++ doesn't emit DW_AT_name for DW_TAG_GNU_formal_parameter_pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70536 --- Comment #6 from Ed Catmur --- Resubmitted: https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611366.html Hopefully this time I'll remember to save the email for pinging.
[Bug c++/107461] [12/13 Regression] ambiguity error for friend with templated constexpr argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107461
--- Comment #9 from Patrick Palka ---
(In reply to Jakub Jelinek from comment #7)
> Reduced testcase:
Interestingly Clang also rejects this testcase, so I'm not sure if we were
correct to accept it previously.
Here's a more reduced testcase that seems clearly valid:
template T foo ();
template struct A { };
template struct B {
template () (U()))>>
static void bar(U);
};
int main() {
B b;
B::bar(0);
}
: In function ‘int main()’:
:12:23: error: no matching function for call to ‘B::bar(int)’
:7:15: note: candidate: ‘template static void
B::bar(U) [with = U; T = void (*)(int)]’
:7:15: note: template argument deduction/substitution failed:
:6:54: error: expression cannot be used as a function
If we remove the line #1 then this bogus error disappears.
[Bug c++/107461] [12/13 Regression] ambiguity error for friend with templated constexpr argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107461 --- Comment #10 from Patrick Palka --- (In reply to Patrick Palka from comment #9) > If we remove the line #1 then this bogus error disappears. The line 'B b;' rather.
[Bug c++/107461] [12/13 Regression] ambiguity error for friend with templated constexpr argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107461 --- Comment #11 from Jakub Jelinek --- (In reply to Patrick Palka from comment #9) > (In reply to Jakub Jelinek from comment #7) > > Reduced testcase: > > Interestingly Clang also rejects this testcase, so I'm not sure if we were > correct to accept it previously. Note, the reduction was done purely with a test that it compiles without errors before your commit and with 1-3 errors "no matching function for call to" after it. Another thing is whether harfbuzz full source is valid or not, but that might be more difficult to find out because clang doesn't support the same builtins/traits etc.
[Bug libstdc++/108672] [13 Regression] g++.dg/modules/xtreme-header-2_a.H, _b.C, _c.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108672 --- Comment #1 from CVS Commits --- The master branch has been updated by Hans-Peter Nilsson : https://gcc.gnu.org/g:72058eea9d407edc85558efc76cde5ceb1d06b0a commit r13-5702-g72058eea9d407edc85558efc76cde5ceb1d06b0a Author: Hans-Peter Nilsson Date: Sat Feb 4 18:38:45 2023 +0100 libstdc++: Avoid use of naked int32_t in unseq_backend_simd.h, PR108672 The use of a "naked" int32_t (i.e. without a fitting #include: stdint.h or cstdint or inttypes.h or an equivalent internal header), in libstdc++-v3/include/pstl/unseq_backend_simd.h, caused an error for cris-elf and apparently pru-elf and I guess all "newlib targets". (Unfortunately, there's a lack of other *-elf targets in recent months of gcc-testresults archives.) This does not manifest on e.g. native x86_64-pc-linux-gnu, because there, a definition is included as an effect of including stdlib.h in cstdlib (following the trace in native xtreme-header-2_a.ii with glibc-2.31-13+deb11u5). Maybe better than chasing the right #includes is to directly use the built-in type, like so: libstdc++-v3: PR libstdc++/108672 * include/pstl/unseq_backend_simd.h (__simd_or): Use __INT32_TYPE__ instead of int32_t.
[Bug target/108673] ICE with -fstack-clash-protection and noreturn attribute on x86_64-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108673 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Dup of bug 90458. *** This bug has been marked as a duplicate of bug 90458 ***
[Bug target/90458] [10/11/12/13 Regression] mingw64: ICE in i386_pe_seh_unwind_emit, at config/i386/winnt.c:1258 with -fstack-clash-protection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90458 Andrew Pinski changed: What|Removed |Added CC||lh_mouse at 126 dot com --- Comment #7 from Andrew Pinski --- *** Bug 108673 has been marked as a duplicate of this bug. ***
[Bug c/108671] spurious "defined but not used" warning with static call back function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108671 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-02-04 Status|UNCONFIRMED |WAITING --- Comment #1 from Andrew Pinski --- Can you provide the preprocessed source?
[Bug libstdc++/108674] New: [wish] *Please* silence *intentional* (non-UB!) unsigned overflow in an libstdc++ header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108674
Bug ID: 108674
Summary: [wish] *Please* silence *intentional* (non-UB!)
unsigned overflow in an libstdc++ header
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: lebedev.ri at gmail dot com
Target Milestone: ---
Dear maintainer.
As everyone knows, unsigned integer overflow is well-defined in C and C++.
However, there are situations where you *know* that a particular code
should not have any overflows. To catch them, there's Integer Sanitizer
in clang (`-fsanitize=integer`).
Unfortunately as one would expect, while some might want to have no
unsigned overflows, others may very well depend on the defined behavior.
As is the case, the GCC, and in particular libstdc++ fall into the
latter category.
I believe in the version 12, a new instance of such intentional wraparound
was introduced into libstdc++: https://godbolt.org/z/rq153fxKW
Running this on a debian machine, we get:
```
/usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/basic_string.h:483:51:
runtime error: unsigned integer overflow: 4 - 6 cannot be represented in type
'size_type' (aka 'unsigned long')
#0 0x55e69e5b6818 in std::__cxx11::basic_string, std::allocator>::_S_compare(unsigned long,
unsigned long)
/usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/basic_string.h:483:51
#1 0x55e69e5b6818 in std::__cxx11::basic_string,
std::allocator>::compare(std::__cxx11::basic_string, std::allocator> const&) const
/usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/basic_string.h:3150:10
<...>
```
I understand that there is no UB there.
I understand that you are doing this intentionally.
The problem is that it is happening in a header,
so it's effectively dictating everyone
that they should not use that sanitizer.
Silencing this kind of thing from user side is possible,
but it's somewhat cumbersome: it requires compiling with
`-fsanitize-recover=integer`, and supplying a run-time suppressions file.
On the other hand, suppressing this in-source is trivial:
https://godbolt.org/z/E7sEnvvrT
... all it would take is applying
`__attribute__((no_sanitize("unsigned-integer-overflow")))`
to `_S_compare` on line 483 in `basic_string.h`.
I have tried that locally, and it works, but it seems it needs to be
wrapped into `#if defined(__clang__)` preprocessor check:
https://godbolt.org/z/5a7ox4EWv
Forwarded from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029970
[Bug libstdc++/108674] [wish] *Please* silence *intentional* (non-UB!) unsigned overflow in an libstdc++ header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108674 --- Comment #1 from Andrew Pinski --- I think this is a bug in clang in the first place for enabling unsigned-integer-overflow at all. I would file a bug with clang to disable unsigned-integer-overflow by default when using -fsanitize=undefined . GCC has already decided to never implement unsigned-integer-overflow even because of how broken this is.
[Bug libstdc++/108674] [wish] *Please* silence *intentional* (non-UB!) unsigned overflow in an libstdc++ header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108674 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=91547, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=81749 Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- Exact dup of bug 97844. *** This bug has been marked as a duplicate of bug 97844 ***
[Bug libstdc++/97844] Unsigned Integer Overflow when comparing strings (|s1|<|s2|)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97844 --- Comment #4 from Andrew Pinski --- *** Bug 108674 has been marked as a duplicate of this bug. ***
[Bug libstdc++/108674] [wish] *Please* silence *intentional* (non-UB!) unsigned overflow in an libstdc++ header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108674 Roman Lebedev changed: What|Removed |Added Resolution|DUPLICATE |--- Status|RESOLVED|UNCONFIRMED --- Comment #3 from Roman Lebedev --- (In reply to Andrew Pinski from comment #1) > I think this is a bug in clang in the first place for enabling > unsigned-integer-overflow at all. > I would file a bug with clang to disable unsigned-integer-overflow by > default when using -fsanitize=undefined . This is incorrect. unsigned-integer-overflow is *NOT* enabled by -fsanitize=undefined It is enabled by -fsanitize=integer, separately. I'm not enabling it erroneously, but very intentionally. > GCC has already decided to never implement unsigned-integer-overflow even > because of how broken this is. This is quite the hot take. I understand that the behaviours it diagnoses are well-defined by the C and C++ standards, and are well-used in various codebases, however not all of those behaviors are desired by everyone. For example, ((signed char)127)+1 is not a signed overflow, even though you really can't tell me that the effective wraparound is the semantics *everyone* expects there. :) However, that is not the question here. I really don't care whether or not you rely on the wraparound semantics of the unsigned types in the library. I really don't. This is only a problem because it happens in a public header. All i'm asking is to improve the UX of the user-facing side of the C++ standard library implementation, and make it more usable by wider variety of the scenarios. In fact, this is a regression. This was not happening in libstdc++-11, or ever before.
[Bug libstdc++/108674] [wish] *Please* silence *intentional* (non-UB!) unsigned overflow in an libstdc++ header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108674 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Andrew Pinski --- Still is exact dup of bug 97844. Does not matter if it was not happening in gcc 11 or not. Still a dup. *** This bug has been marked as a duplicate of bug 97844 ***
[Bug libstdc++/97844] Unsigned Integer Overflow when comparing strings (|s1|<|s2|)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97844 --- Comment #5 from Andrew Pinski --- *** Bug 108674 has been marked as a duplicate of this bug. ***
[Bug libstdc++/108674] [wish] *Please* silence *intentional* (non-UB!) unsigned overflow in an libstdc++ header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108674 --- Comment #5 from Andrew Pinski --- > This is quite the hot take. Hot take from 5 years ago. See te other bugs I referenced and even the mailing list emails that are referenced from there. Rather clang is the one who decided this breaking behavior.
[Bug libstdc++/108674] [wish] *Please* silence *intentional* (non-UB!) unsigned overflow in an libstdc++ header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108674 --- Comment #6 from Andrew Pinski --- See https://gcc.gnu.org/legacy-ml/gcc/2016-07/msg00051.html . Sorry when I said 5 years I meant 7 years.
[Bug libstdc++/108674] [wish] *Please* silence *intentional* (non-UB!) unsigned overflow in an libstdc++ header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108674
--- Comment #7 from Jonathan Wakely ---
(In reply to Roman Lebedev from comment #0)
> I believe in the version 12, a new instance of such intentional wraparound
> was introduced into libstdc++: https://godbolt.org/z/rq153fxKW
No, that code is from 2014-12-19.
> I understand that there is no UB there.
> I understand that you are doing this intentionally.
> The problem is that it is happening in a header,
> so it's effectively dictating everyone
> that they should not use that sanitizer.
Well, they shouldn't use it *and expect everybody else's code to never rely on
unsigned wraparound*. If they want to write their own code to never rely on
that guaranteed feature of the language, that's fine. They don't get to force
that choice on everybody else.
> Silencing this kind of thing from user side is possible,
> but it's somewhat cumbersome: it requires compiling with
> `-fsanitize-recover=integer`, and supplying a run-time suppressions file.
>
> On the other hand, suppressing this in-source is trivial:
> https://godbolt.org/z/E7sEnvvrT
> ... all it would take is applying
> `__attribute__((no_sanitize("unsigned-integer-overflow")))`
> to `_S_compare` on line 483 in `basic_string.h`.
>
> I have tried that locally, and it works, but it seems it needs to be
> wrapped into `#if defined(__clang__)` preprocessor check:
> https://godbolt.org/z/5a7ox4EWv
>
> Forwarded from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029970
So provide a patch then, instead of asking other people to work around this
sanitizer for you.
[Bug libstdc++/108674] [wish] *Please* silence *intentional* (non-UB!) unsigned overflow in an libstdc++ header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108674 --- Comment #8 from Jonathan Wakely --- (In reply to Roman Lebedev from comment #3) > This is incorrect. > unsigned-integer-overflow is *NOT* enabled by -fsanitize=undefined > It is enabled by -fsanitize=integer, separately. > I'm not enabling it erroneously, but very intentionally. But it still incorrectly claims there is undefined behaviour. Your own godbolt link shows: UndefinedBehaviorSanitizer: undefined-behavior ... We've talked about this before, see PR 97844. > All i'm asking is to improve the UX of the user-facing side > of the C++ standard library implementation, > and make it more usable by wider variety of the scenarios. Please stop asking other people to work around broken tools that they don't use themselves. You want a workaround, propose a patch. > In fact, this is a regression. > This was not happening in libstdc++-11, or ever before. The code is nearly a decade old, and you even commented on PR 97844 about it happening in gcc 10. So I don't know where you get the idea it's new in gcc-12.
[Bug libstdc++/108674] [wish] *Please* silence *intentional* (non-UB!) unsigned overflow in an libstdc++ header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108674
--- Comment #9 from Roman Lebedev ---
(In reply to Jonathan Wakely from comment #7)
> (In reply to Roman Lebedev from comment #0)
> > I believe in the version 12, a new instance of such intentional wraparound
> > was introduced into libstdc++: https://godbolt.org/z/rq153fxKW
>
> No, that code is from 2014-12-19.
I agree that the _S_compare is rather old.
What i'm saying is that i have never seen this issue before v12,
so std::map implementation must have been refactored
to use the function in question, and that "introduced" the issue.
> > I understand that there is no UB there.
> > I understand that you are doing this intentionally.
> > The problem is that it is happening in a header,
> > so it's effectively dictating everyone
> > that they should not use that sanitizer.
>
> Well, they shouldn't use it *and expect everybody else's code to never rely
> on unsigned wraparound*. If they want to write their own code to never rely
> on that guaranteed feature of the language, that's fine. They don't get to
> force that choice on everybody else.
Right, of course. As i have said, if i was compiling gcc/libstdc++ itself
with that "broken" sanitizer, closing as WONTFIX would be totally justified,
but here we are in a bit of a gray area, because while that is for sure
a part of implementation, it's rather a user-facing one.
> > Silencing this kind of thing from user side is possible,
> > but it's somewhat cumbersome: it requires compiling with
> > `-fsanitize-recover=integer`, and supplying a run-time suppressions file.
> >
> > On the other hand, suppressing this in-source is trivial:
> > https://godbolt.org/z/E7sEnvvrT
> > ... all it would take is applying
> > `__attribute__((no_sanitize("unsigned-integer-overflow")))`
> > to `_S_compare` on line 483 in `basic_string.h`.
> >
> > I have tried that locally, and it works, but it seems it needs to be
> > wrapped into `#if defined(__clang__)` preprocessor check:
> > https://godbolt.org/z/5a7ox4EWv
> >
> > Forwarded from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029970
>
> So provide a patch then, instead of asking other people to work around this
> sanitizer for you.
:)
[Bug libstdc++/108674] [wish] *Please* silence *intentional* (non-UB!) unsigned overflow in an libstdc++ header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108674 --- Comment #10 from Roman Lebedev --- Created attachment 54409 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54409&action=edit the patch I'm not at all familiar with the GCC's preferred patch protocol, this is the result of `git format-patch origin/master`, with commit message mimicking the ones of the recent commits. Please let me know what i got wrong this time.
[Bug testsuite/108675] New: FAIL: gcc.c-torture/execute/builtins/*printf.c when stdio.h includes definitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108675
Bug ID: 108675
Summary: FAIL: gcc.c-torture/execute/builtins/*printf.c when
stdio.h includes definitions
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
Target Milestone: ---
Failing tests:
gcc.c-torture/execute/builtins/printf.c
gcc.c-torture/execute/builtins/fprintf.c
gcc.c-torture/execute/builtins/sprintf.c
On mingw-w64, the gcc.c-torture/execute/builtins/*printf.c tests fail. We
include definitions of various functions in stdio.h instead of just
declarations, leading to redefinition errors. For example,
https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-headers/crt/stdio.h:
__mingw_ovr
__attribute__((__format__ (gnu_printf, 2, 3))) __MINGW_ATTRIB_NONNULL(2)
int fprintf (FILE *__stream, const char *__format, ...)
{
int __retval;
__builtin_va_list __local_argv; __builtin_va_start( __local_argv, __format );
__retval = __mingw_vfprintf( __stream, __format, __local_argv );
__builtin_va_end( __local_argv );
return __retval;
}
This causes the test to fail to compile at all optimization levels:
gcc.c-torture/execute/builtins/lib/fprintf.c:8:1: error: redefinition of
'fprintf'
mingw13/x86_64-w64-mingw32/include/stdio.h:357:5: note: previous definition of
'fprintf' with type 'int(FILE *, const char *, ...)' {aka 'int(struct _iobuf *,
const char *, ...)'}
The tests were originally added in r38065, r38788, and r48335. They were later
moved in r84044 and tweaked a bit.
Is there a better way to verify that the builtin was used instead of mingw
version?
