[Bug tree-optimization/102622] [9/10/12 Regression] Wrong code with -O1 and above due to phiopt and signed one bit integer types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102622 Andrew Pinski changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2021-October ||/581251.html --- Comment #19 from Andrew Pinski --- Trunk patch submitted https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581251.html
[Bug tree-optimization/102676] New: Failure to optimize out malloc/nothrow allocation that's only used for bool checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102676
Bug ID: 102676
Summary: Failure to optimize out malloc/nothrow allocation
that's only used for bool checking
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
#include
#include
bool f()
{
return new(std::nothrow) int;
}
bool g()
{
return malloc(1);
}
Both these functions can be optimized to `return true;`. This optimization is
done by LLVM, but not by GCC.
[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486
--- Comment #16 from Óscar Fuentes ---
With g++ 11.2 mingw-w64-i686 a simple test like this crashes:
int main() {
try {
throw 13;
}
catch(...) {
return 1;
}
return 0;
}
$ g++ foo.cpp
$ ./a.exe
terminate called after throwing an instance of 'int'
terminate called recursively
The configure command is the same mentioned in comment 5, sans Ada.
[Bug tree-optimization/102622] [9/10/12 Regression] Wrong code with -O1 and above due to phiopt and signed one bit integer types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102622 --- Comment #18 from Andrew Pinski --- Created attachment 51579 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51579=edit Patch which I am testing Patch which I am testing, it works for the testcase but I have not done a full bootstrap/test yet.
[Bug tree-optimization/102622] [9/10/12 Regression] Wrong code with -O1 and above due to phiopt and signed one bit integer types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102622 Andrew Pinski changed: What|Removed |Added Target Milestone|12.0|9.5 Known to work|9.3.0 |11.1.0, 4.9.2, 7.1.0, 8.5.0 Known to fail||10.3.0, 9.1.0, 9.4.0 Summary|[12 Regression] Wrong code |[9/10/12 Regression] Wrong |with -O3 for skylake-avx512 |code with -O1 and above due |and icelake-server by |to phiopt and signed one |r12-3903|bit integer types --- Comment #17 from Andrew Pinski --- So the reason why we didn't hit it in GCC 11 (and before) was the order of the following was swapped in phiopt compared to what it is in match.pd now: a ? -1 : 0 -> -a a ? powerof2cst : 0 -> a << (log2(powerof2cst)) That is did the powerof2cst case before it did the -1 case. I am going to test that to see if it works here which I think it does. In fact my new testcase fails in GCC 9.1.0-10.3.0 :). I am going to fix this for the trunk and come up with a fix for the other branches later on. And yes the regression markers are a bit off right now but that is because the bug is not latent on the 12 branch.
[Bug bootstrap/102675] [12 regression] Bootstrap fails in libsanitizer: 'MD5_DIGEST_STRING_LENGTH' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102675 H.J. Lu changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-10-09 Status|UNCONFIRMED |NEW --- Comment #1 from H.J. Lu --- (In reply to Gerald Pfeifer from comment #0) > This happens on all FreeBSD platforms and versions: > > I believe the problem is that this adds #include and some > dependencies on constants defined in FreeBSD's /usr/include/md5.h, > where GCC features it's on $GCC_SOURCE/include/md5.h which does not > provide the required constants and types. That file is FreeBSD specific. Can you use a local patch to force /usr/include/md5.h, like #include_next
[Bug bootstrap/102675] New: [12 regression] Bootstrap fails in libsanitizer: 'MD5_DIGEST_STRING_LENGTH' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102675 Bug ID: 102675 Summary: [12 regression] Bootstrap fails in libsanitizer: 'MD5_DIGEST_STRING_LENGTH' was not declared in this scope Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: gerald at pfeifer dot com CC: hjl.tools at gmail dot com Target Milestone: --- Host: *-*-freebsd* Target: *-*-freebsd* Build: *-*-freebsd* This happens on all FreeBSD platforms and versions: CC-HEAD/libsanitizer/sanitizer_common/sanitizer_platform_limits_freebsd.cpp:370 :36: error: 'MD5_CTX' was not declared in this scope 370 | const unsigned MD5_CTX_sz = sizeof(MD5_CTX); |^~~ GCC-HEAD/libsanitizer/sanitizer_common/sanitizer_platform_limits_freebsd.cpp:371 :36: error: 'MD5_DIGEST_STRING_LENGTH' was not declared in this scope; did you mean 'SHA256_DIGEST_STRING_LENGTH'? 371 | const unsigned MD5_return_length = MD5_DIGEST_STRING_LENGTH; |^~~~ |SHA256_DIGEST_STRING_LENGTH It was introduced by commit 2e3d50c09519d1b4899845b21843bae66ecffc2f Author: H.J. Lu Date: Wed Oct 6 10:24:24 2021 -0700 libsanitizer: Merge with upstream Merged revision: fdf4c035225de52f596899931b1f6100e5e3e928 I believe the problem is that this adds #include and some dependencies on constants defined in FreeBSD's /usr/include/md5.h, where GCC features it's on $GCC_SOURCE/include/md5.h which does not provide the required constants and types.
[Bug tree-optimization/102622] [12 Regression] Wrong code with -O3 for skylake-avx512 and icelake-server by r12-3903
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102622
--- Comment #16 from Andrew Pinski ---
Here is a testcase without avx-512f usage:
struct f{signed t:1;};
int g(struct f *a, int t) __attribute__((noipa));
int g(struct f *a, int t)
{
if (t)
a->t = -1;
else
a->t = 0;
int t1 = a->t;
if (t1) return 1;
return t1;
}
int main(void)
{
struct f a;
if (!g(, 1)) __builtin_abort();
return 0;
}
[Bug tree-optimization/102666] Wrong loop optimization for unsigned types after r9-4145
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102666 --- Comment #3 from Andrew Pinski --- *** Bug 102673 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/102673] [9 Regression] Wrong code with -O due to adjust_cond_for_loop_until_wrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102673 Andrew Pinski changed: What|Removed |Added Resolution|FIXED |DUPLICATE --- Comment #5 from Andrew Pinski --- *** This bug has been marked as a duplicate of bug 102666 ***
[Bug middle-end/102674] internal compiler error: on fpclassify(_Decimal32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102674 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-10-09 --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug middle-end/102674] internal compiler error: on fpclassify(_Decimal32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102674 Andrew Pinski changed: What|Removed |Added Known to fail||4.4.7 --- Comment #1 from Andrew Pinski --- Not a regression.
[Bug tree-optimization/102673] [9 Regression] Wrong code with -O due to adjust_cond_for_loop_until_wrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102673 ibuclaw at gcc dot gnu.org changed: What|Removed |Added Resolution|DUPLICATE |FIXED --- Comment #4 from ibuclaw at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #3) > exact dup of bug 102666 :). > > *** This bug has been marked as a duplicate of bug 102666 *** Excellent, I just saw it hit my queue for the D front-end, with no context of where they got it from. :-)
[Bug c/102674] New: internal compiler error: on fpclassify(_Decimal32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102674
Bug ID: 102674
Summary: internal compiler error: on fpclassify(_Decimal32)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: kamilcukrowski at gmail dot com
Target Milestone: ---
Created attachment 51578
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51578=edit
The preprocessed file
The following source file:
```
# define FP_NAN 0
# define FP_INFINITE 1
# define FP_ZERO 2
# define FP_SUBNORMAL 3
# define FP_NORMAL 4
#define fpclassify(x) __builtin_fpclassify(FP_NAN, FP_INFINITE, \
FP_NORMAL, FP_SUBNORMAL, FP_ZERO, x)
int func(_Decimal32 val) {
const int valclass = fpclassify(val);
return valclass == FP_NAN;
}
```
Results in:
```
$ gcc file.c
during RTL pass: expand
file.c: In function ‘func’:
file.c:8:5: internal compiler error: in decimal_to_decnumber, at dfp.c:134
8 | int func(_Decimal32 val) {
| ^~~~
0x1614f98 internal_error(char const*, ...)
???:0
0x6538a1 fancy_abort(char const*, int, char const*)
???:0
0x1477f0d encode_decimal32(real_format const*, long*, real_value const*)
???:0
0xb0a245 real_to_target(long*, real_value const*, format_helper)
???:0
0xb74a44 native_encode_rtx(machine_mode, rtx_def*, vec&, unsigned int, unsigned int)
???:0
0xb81e28 simplify_context::simplify_subreg(machine_mode, rtx_def*,
machine_mode, poly_int<1u, unsigned long>)
???:0
0xb846c9 simplify_context::simplify_gen_subreg(machine_mode, rtx_def*,
machine_mode, poly_int<1u, unsigned long>)
???:0
0x894d83 emit_move_insn_1(rtx_def*, rtx_def*)
???:0
0x8950ad emit_move_insn(rtx_def*, rtx_def*)
???:0
0x76f578 emit_library_call_value_1(int, rtx_def*, rtx_def*, libcall_type,
machine_mode, int, std::pair*)
???:0
0xa900f3 emit_cmp_and_jump_insns(rtx_def*, rtx_def*, rtx_code, rtx_def*,
machine_mode, int, rtx_def*, profile_probability)
???:0
0x7f4db7 do_compare_rtx_and_jump(rtx_def*, rtx_def*, rtx_code, int,
machine_mode, rtx_def*, rtx_code_label*, rtx_code_label*, profile_probability)
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/102666] Wrong loop optimization for unsigned types after r9-4145
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102666 Andrew Pinski changed: What|Removed |Added CC||ibuclaw at gcc dot gnu.org --- Comment #2 from Andrew Pinski --- *** Bug 102673 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/102673] [9 Regression] Wrong code with -O due to adjust_cond_for_loop_until_wrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102673 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Andrew Pinski --- exact dup of bug 102666 :). *** This bug has been marked as a duplicate of bug 102666 ***
[Bug tree-optimization/102673] [9 Regression] Wrong code with -O due to adjust_cond_for_loop_until_wrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102673 --- Comment #2 from ibuclaw at gcc dot gnu.org --- (In reply to ibuclaw from comment #0) > Bisected, and the commit that changed behaviour was the fix for pr84648. Commit was r9-4145.
[Bug tree-optimization/102673] [9 Regression] Wrong code with -O due to adjust_cond_for_loop_until_wrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102673 --- Comment #1 from ibuclaw at gcc dot gnu.org --- Since pr101145, the function this now happens in is number_of_iterations_until_wrap.
[Bug tree-optimization/102673] New: [9 Regression] Wrong code with -O due to adjust_cond_for_loop_until_wrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102673
Bug ID: 102673
Summary: [9 Regression] Wrong code with -O due to
adjust_cond_for_loop_until_wrap
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ibuclaw at gcc dot gnu.org
Target Milestone: ---
Reduced test, when compiled with -O, optimizes the loop into `return 1;`.
---
int main()
{
for (unsigned a = 0, b = 0; a < 6; a += 1, b += 2)
{
if (b < a)
return 1;
}
return 0;
}
---
https://godbolt.org/z/YM7aYrY8v
Bisected, and the commit that changed behaviour was the fix for pr84648.
[Bug tree-optimization/41244] "[i] - data" isn't converted to "i"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41244 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org --- Comment #7 from Andrew Pinski --- Mine.
[Bug target/102672] [AArch64] Failure to optimize to using stp instead of 2 strs when possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102672 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug target/102672] [AArch64] Failure to optimize to using stp instead of 2 strs when possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102672 --- Comment #2 from Andrew Pinski --- There might be another bugs similar to this already too.
[Bug target/102672] [AArch64] Failure to optimize to using stp instead of 2 strs when possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102672 --- Comment #1 from Andrew Pinski --- Padding bytes are not zero in some cases and this is the case here.
[Bug target/102672] New: [AArch64] Failure to optimize to using stp instead of 2 strs when possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102672
Bug ID: 102672
Summary: [AArch64] Failure to optimize to using stp instead of
2 strs when possible
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
struct X {
int i;
void *p;
};
void foo(struct X *q, void *p)
{
struct X b{};
b.p = p;
*q = b;
}
With -O3, GCC outputs this:
foo(X*, void*):
str wzr, [x0]
str x1, [x0, 8]
ret
LLVM instead outputs this:
foo(X*, void*):
stp xzr, x1, [x0]
ret
[Bug objc++/56604] Missing obj-c++.srcman target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56604 --- Comment #4 from Eric Gallager --- Pushed to my GitHub mirror while I'm still trying to get my ssh keys sorted out: https://github.com/cooljeanius/gcc/commit/19caef57e59207d8131bf2db59519ac45fdab6aa
[Bug fortran/65454] Extending both forms of relational operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65454 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |12.0 Status|ASSIGNED|RESOLVED --- Comment #8 from anlauf at gcc dot gnu.org --- Fixed for gcc-12. Closing. Thanks for the report!
[Bug fortran/65454] Extending both forms of relational operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65454 --- Comment #7 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:b2713e9f16d3f3597d71e4be6384ecd788684936 commit r12-4274-gb2713e9f16d3f3597d71e4be6384ecd788684936 Author: Harald Anlauf Date: Sat Oct 9 21:16:32 2021 +0200 Fortran: accept both old and new-style relational operators in USE, ONLY F2018:10.1.5.5.1(2) requires the same interpretation of old and new-style relational operators. As gfortran internally distinguishes between these versions, we must match equivalent notations in USE module, ONLY: OPERATOR(op) statements when reading modules. gcc/fortran/ChangeLog: PR fortran/65454 * module.c (read_module): Handle old and new-style relational operators when used in USE module, ONLY: OPERATOR(op). gcc/testsuite/ChangeLog: PR fortran/65454 * gfortran.dg/interface_operator_3.f90: New test.
[Bug c/87447] Missing -Wconversion warning in implicit conversion of unsigned long long to double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87447 --- Comment #4 from Vincent Lefèvre --- After some tests, only the comparison operators seem to be affected.
[Bug c/87447] Missing -Wconversion warning in implicit conversion of unsigned long long to double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87447
--- Comment #3 from Vincent Lefèvre ---
This is probably related to the == operator (and other ones), since gcc warns
on the following codes:
double foo (void)
{
double x = (1ULL << 63) + 1;
return x;
}
and
double foo (void)
{
return (1ULL << 63) + 1;
}
[Bug analyzer/102671] New: -Wanalyzer-null-dereference false positive when compiling GNU Emacs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102671
Bug ID: 102671
Summary: -Wanalyzer-null-dereference false positive when
compiling GNU Emacs
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: eggert at cs dot ucla.edu
Target Milestone: ---
Created attachment 51577
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51577=edit
Compile with -fanalyzer -O2 -S on x86-64 to illustrate the bug
I ran into this problem when compiling GNU Emacs with gcc (GCC) 11.2.1 20210728
(Red Hat 11.2.1-1) on x86-64. Compile with:
gcc -fanalyzer -O2 -S analyzer-null-defererence-bug.i
and the output will be the diagnostic at the end of this bug report, which is a
false alarm. Removing the unrelated function wset_buffer suppresses the false
alarm, which suggests that the analysis of wset_buffer is somehow messing up
the analysis of delete_all_child_windows.
I do not observe this problem when compiling with gcc (Ubuntu 10.3.0-1ubuntu1)
10.3.0.
analyzer-null-defererence-bug.i: In function 'PSEUDOVECTORP.part.0':
analyzer-null-defererence-bug.i:23:13: warning: dereference of NULL 'a'
[CWE-476] [-Wanalyzer-null-dereference]
23 | return ((a->size & (PSEUDOVECTOR_FLAG | PVEC_TYPE_MASK))
|~^~
'delete_all_child_windows': events 1-4
|
| 155 | delete_all_child_windows (struct lisp *window)
| | ^~~~
| | |
| | (1) entry to 'delete_all_child_windows'
|..
| 158 | if (!NILP (w->next))
| | ~
| | |
| | (2) following 'true' branch...
| 159 | delete_all_child_windows (w->next);
| | ~~
| | |
| | (3) ...to here
| | (4) calling 'delete_all_child_windows' from
'delete_all_child_windows'
|
+--> 'delete_all_child_windows': events 5-8
|
| 155 | delete_all_child_windows (struct lisp *window)
| | ^~~~
| | |
| | (5) entry to 'delete_all_child_windows'
|..
| 158 | if (!NILP (w->next))
| | ~
| | |
| | (6) following 'true' branch...
| 159 | delete_all_child_windows (w->next);
| | ~~
| | |
| | (7) ...to here
| | (8) calling 'delete_all_child_windows' from
'delete_all_child_windows'
|
+--> 'delete_all_child_windows': events 9-14
|
| 155 | delete_all_child_windows (struct lisp *window)
| | ^~~~
| | |
| | (9) entry to 'delete_all_child_windows'
|..
| 158 | if (!NILP (w->next))
| | ~
| | |
| | (10) following 'false' branch...
| 159 | delete_all_child_windows (w->next);
| 160 | if (WINDOWP (w->contents))
| | ~~
| | ||
| | |(11) ...to here
| | (12) following 'true' branch...
| 161 | {
| 162 | delete_all_child_windows (w->contents);
| | ~~
| | |
| | (13) ...to here
| | (14) calling 'delete_all_child_windows' from
'delete_all_child_windows'
|
+--> 'delete_all_child_windows': events 15-19
|
| 155 | delete_all_child_windows (struct lisp
*window)
| | ^~~~
| | |
| | (15) entry to 'delete_all_child_windows'
|..
| 158 | if (!NILP (w->next))
| | ~
| | |
| | (16) following 'false' branch...
| 159 | delete_all_child_windows (w->next);
| 160 | if (WINDOWP (w->contents))
| | ~~
| | ||
| | |(17) ...to here
| | (18) following 'false' branch...
|..
|
[Bug c++/102670] New: Erroneous "missing template arguments" message for wrapper of ADL function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102670
Bug ID: 102670
Summary: Erroneous "missing template arguments" message for
wrapper of ADL function template
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: friedkeenan at protonmail dot com
Target Milestone: ---
With the following code, GCC outputs an erroneous error message of "missing
template arguments":
#include
namespace ns {
struct S { };
template
constexpr int adl(const S &) {
return I;
}
}
namespace redirect {
template
concept can_call_adl = requires(T &) {
adl(std::forward(t));
};
template
struct adl_fn {
template T>
constexpr decltype(auto) operator ()(T &) const {
return adl(std::forward(t));
}
};
namespace {
template
constexpr inline adl_fn adl{};
}
}
static_assert(redirect::can_call_adl);
int main() {
// return adl<3>(ns::S{});
return redirect::adl<3>(ns::S{});
}
Godbolt link: https://godbolt.org/z/or5n8EM6q
As you can see, even though ns::S satisfies the redirect::can_call_adl concept,
when the templated call operator is instantiated, it thinks the code is
invalid. If you remove the indirection, no error message is presented and
everything works as expected. Additionally, Clang handles this code just fine.
If you however use the following code, everything works fine:
#include
namespace ns {
struct S { };
template
constexpr int adl(const S &) {
return I;
}
}
namespace redirect {
namespace _adl {
/* Poison pill. */
template
void adl() = delete;
template
concept can_call_adl = requires(T &) {
adl(std::forward(t));
};
template
struct adl_fn {
template T>
constexpr decltype(auto) operator ()(T &) const {
return adl(std::forward(t));
}
};
}
namespace {
template
constexpr inline _adl::adl_fn adl{};
}
}
static_assert(redirect::_adl::can_call_adl);
int main() {
// return adl<3>(ns::S{});
return redirect::adl<3>(ns::S{});
}
Godbolt link: https://godbolt.org/z/jocaKrjbW
This sort of functionality is desirable for making a wrapper that handles both
ADL-discovered `get` functions and `get` member functions (as structured
binding allows both), similar to the std::ranges::begin etc. wrappers.
[Bug middle-end/102630] [12 Regression] Spurious -Warray-bounds with named address space
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102630 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #6 from Martin Sebor --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581243.html
[Bug middle-end/102669] New: [12 Regression] FAIL: gnat.dg/unroll1.adb scan-rtl-dump-times loop2_unroll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102669 Bug ID: 102669 Summary: [12 Regression] FAIL: gnat.dg/unroll1.adb scan-rtl-dump-times loop2_unroll Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- I noticed the following test failure in today's x86_64 build of the top of GCC 12 trunk: gcc/testsuite/gnat/gnat.log:PASS: gnat.dg/unroll1.adb (test for excess errors) gcc/testsuite/gnat/gnat.log:PASS: gnat.dg/unroll1.adb scan-tree-dump-times cunrolli "Not unrolling loop .: user didn't want it unrolled completely" 2 gcc/testsuite/gnat/gnat.log:gnat.dg/unroll1.adb: pattern found 0 times gcc/testsuite/gnat/gnat.log:FAIL: gnat.dg/unroll1.adb scan-rtl-dump-times loop2_unroll "Not unrolling loop, user didn't want it unrolled" 2
[Bug libstdc++/102667] Inconsistent result of std::regex_match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102667 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2021-10-09 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org --- Comment #1 from Jonathan Wakely --- The match_results sequence contains extra "hidden" elements at the end, which should not be visible when traversing the container using begin() and end(). The bug is in the end() function, which returns the position after the hidden elements, not after the (zero length) sequence of matches.
[Bug other/102664] contrib/gcc-git-customization.sh uses echo -n, which isn't portable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102664 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-10-09 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- https://pubs.opengroup.org/onlinepubs/009604599/utilities/echo.html Confirmed. The informative part of the documentation recommands using printf instead.
[Bug analyzer/102662] [12 Regression] ICE in validate, at analyzer/constraint-manager.cc:581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102662 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0
[Bug libgomp/102668] New: [12 regression] several libgomp alloc test case failures after r12-3976
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102668
Bug ID: 102668
Summary: [12 regression] several libgomp alloc test case
failures after r12-3976
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: seurer at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
g:b38a4bd10249b5070ea1f4708a0fd228df268c26, r12-3976
This was on a power 7 BE machine. I did not see it on LE.
FAIL: libgomp.fortran/alloc-1.F90 -O execution test
FAIL: libgomp.fortran/alloc-2.F90 -O execution test
FAIL: libgomp.fortran/alloc-3.F -O execution test
spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/./gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/./gcc/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/bin/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/lib/
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/include
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/sys-include
/home/seurer/gcc/git/gcc-test/libgomp/testsuite/libgomp.fortran/alloc-1.F90
-m32
-B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/32/libgomp/
-B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/32/libgomp/.libs
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/32/libgomp
-I/home/seurer/gcc/git/gcc-test/libgomp/testsuite/../../include
-I/home/seurer/gcc/git/gcc-test/libgomp/testsuite/.. -fmessage-length=0
-fno-diagnostics-show-caret -fdiagnostics-color=never -fopenmp
-B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/32/libgomp/../libquadmath/.libs/
-O -Wall -Wextra -Wno-maybe-uninitialized
-B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/32/libgomp/../libgfortran/.libs
-fintrinsic-modules-path=/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/32/libgomp
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/32/libgomp/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/32/libgomp/../libquadmath/.libs/
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/32/libgomp/../libgfortran/.libs
-lgfortran -foffload=-lgfortran -lquadmath -lm -o ./alloc-1.exe^M
PASS: libgomp.fortran/alloc-1.F90 -O (test for excess errors)
Setting LD_LIBRARY_PATH to
.:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/32/libgomp/.libs:/home/seurer/gcc/git/build/gcc-test/gcc:/home/seurer/gcc/git/build/gcc-test/gcc/32:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/32/libgomp/../libgfortran/.libs:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/32/libgomp/../libquadmath/.libs:/home/seurer/gcc/git/build/gcc-test/./gcc:/home/seurer/gcc/git/build/gcc-test/./gcc/32:.:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/32/libgomp/.libs:/home/seurer/gcc/git/build/gcc-test/gcc:/home/seurer/gcc/git/build/gcc-test/gcc/32:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/32/libgomp/../libgfortran/.libs:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/32/libgomp/../libquadmath/.libs:/home/seurer/gcc/git/build/gcc-test/./gcc:/home/seurer/gcc/git/build/gcc-test/./gcc/32:/home/seurer/gcc/git/build/gcc-test/./gmp/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-gmp/.libs:/home/seurer/gcc/git/build/gcc-test/./mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-test/./mpc/src/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-mpc/src/.libs:/home/seurer/gcc/git/build/gcc-test/./isl/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-isl/.libs:/home/seurer/gcc/install/gcc-8.3.0/lib64
Execution timeout is: 300
spawn [open ...]^M
STOP 13
FAIL: libgomp.fortran/alloc-1.F90 -O execution test
The other two were also "STOP 13"s
commit b38a4bd10249b5070ea1f4708a0fd228df268c26
Author: Jakub Jelinek
Date: Thu Sep 30 09:30:18 2021 +0200
openmp: Add omp_aligned_{,c}alloc and omp_{c,re}alloc
[Bug libstdc++/102667] New: Inconsistent result of std::regex_match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102667
Bug ID: 102667
Summary: Inconsistent result of std::regex_match
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: fchelnokov at gmail dot com
Target Milestone: ---
This program:
```
#include
#include
#include
#include
int main()
{
std::string input("4321");
std::regex rg("^([0-9])");
std::smatch sm;
bool found = std::regex_match(input, sm, rg);
assert(!sm.size() == sm.empty());
std::cout << "ready: " << sm.ready() << ", found: " <<
found << ", size: " << sm.size() << std::endl;
for (auto it = sm.begin(); it != sm.end(); ++it)
{
std::cout << "iterate '" << *it << "'\n";
}
}
```
prints rather unexpected:
```
ready: 1, found: 0, size: 0
iterate ''
iterate ''
iterate ''
```
So std::smatch contains 3 entries while its size is zero.
Expected result:
```
ready: 1, found: 0, size: 0
```
Demo: https://gcc.godbolt.org/z/Wfh1vaPqq
Related discussion: https://stackoverflow.com/q/66611132/7325599
[Bug tree-optimization/100740] [9/10/11/12 Regression] wrong code at -O1 and above on x86_64-linux-gnu since r9-4145
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100740 Andrew Pinski changed: What|Removed |Added CC||davidsondfgl at gmail dot com --- Comment #6 from Andrew Pinski --- *** Bug 102666 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/102666] Wrong loop optimization for unsigned types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102666 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup of bug 100740 (or PR 101508 or PR 101972). *** This bug has been marked as a duplicate of bug 100740 ***
[Bug target/98189] [SH] ICE and segmentation fault with -O2 and without -fno-guess-branch-probability when building gdal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98189 Eric Gallager changed: What|Removed |Added Keywords||ice-on-valid-code CC||egallager at gcc dot gnu.org --- Comment #5 from Eric Gallager --- assuming that since this is from gdal, it's an ice-on-valid
[Bug c/87447] Missing -Wconversion warning in implicit conversion of unsigned long long to double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87447 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #2 from Eric Gallager --- (In reply to Manuel López-Ibáñez from comment #1) > C++ warns: > > :5:3: warning: conversion from 'long long unsigned int' to 'double' > changes value from '9223372036854775809' to '9.2233720368547758e+18' > [-Wfloat-conversion] Hm, any idea what the difference is between the C and C++ frontends that causes this warning to only be printed for C++?
[Bug tree-optimization/102666] New: Wrong loop optimization for unsigned types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102666
Bug ID: 102666
Summary: Wrong loop optimization for unsigned types
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: davidsondfgl at gmail dot com
Target Milestone: ---
The code below produces incorrect result when any optimizations (-O1/-O2/-O3)
are enabled:
$ cat unsigned-bug.c
int main(void) {
for (unsigned a = 0, b = 0; a < 6; a += 1, b += 2)
if (b < a)
return 1;
return 0;
}
$ gcc -Wall -Wextra unsigned-bug.c; ./a.out; echo $?
0
$ gcc -Wall -Wextra unsigned-bug.c -O1; ./a.out; echo $?
1
$ gcc -Wall -Wextra unsigned-bug.c -O2; ./a.out; echo $?
1
$ gcc -Wall -Wextra unsigned-bug.c -O3; ./a.out; echo $?
1
This affects all releases as of 9.1, including the master branch (commit
2b30143).
A bisect between v9.1 and v8.3 indicates that this may have been introduced in
r266171, as I can revert this commit (a81e2c6) in all releases up to v11.2 and
get the expected behavior.
It is also worthwhile to note that this only occurs for unsigned types.
[Bug other/102665] ELF-specific configure flags should be rejected on non-ELF platforms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102665 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=34422 --- Comment #1 from Eric Gallager --- bug 34422 is semi-related, since it's also a case of a configure flag that should be rejected where it won't work.
[Bug other/102665] New: ELF-specific configure flags should be rejected on non-ELF platforms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102665 Bug ID: 102665 Summary: ELF-specific configure flags should be rejected on non-ELF platforms Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: egallager at gcc dot gnu.org Target Milestone: --- Specifically, --enable-gnu-unique-object and --enable-secureplt are ELF-specific configure flags, and yet are accepted anyways by the top-level configure script on non-ELF platforms with no complaint. The help string for --enable-gnu-unique-object at least mentions that it's ELF-specific, but the one for --enable-secureplt doesn't, so that's another thing that could be updated.
[Bug c/102661] signed integer overflow not detected in comparison since gcc-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102661 --- Comment #3 from lrspam at sfr dot fr --- Thank you Andrew for you answer. I will therefore use -fwrapv, in order to implement overflow detection the same way I did with gcc 7.
[Bug other/102664] New: contrib/gcc-git-customization.sh uses echo -n, which isn't portable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102664 Bug ID: 102664 Summary: contrib/gcc-git-customization.sh uses echo -n, which isn't portable Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: egallager at gcc dot gnu.org Target Milestone: --- Specifically, in ask(), it does: echo -n $question "["$default"]? " which results in the "-n" being included literally on systems whose echo doesn't support that flag: -n Local name for upstream repository [origin]?
[Bug libstdc++/21549] Configure options hard to find
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21549 --- Comment #7 from Eric Gallager --- (In reply to Andrew Pinski from comment #1) > Confirmed, --with-pic being documented would be very nice even though it is > a generic libtool > configure option, it is most used with libstdc++ as shown by the bug reports > about the using static > libstdc++ in a shared library. Note that documenting it has the risk of leading people to think that --with-pic (or --without-pic) is ok to use even in situations when it's not; e.g. x86_64 must always be PIC. If the flag is going to be documented, any such restrictions should be documented as well.
[Bug c++/102654] [11/12 Regression] undefined reference to `std::variant::variant(std::string_view&&)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102654
Patrick Palka changed:
What|Removed |Added
Component|libstdc++ |c++
CC||jason at gcc dot gnu.org,
||ppalka at gcc dot gnu.org
--- Comment #1 from Patrick Palka ---
Started with r11-6736.
Reduced valid testcase which fails to link:
struct basic_string_view {
basic_string_view() {}
};
struct variant {
template constexpr variant(_Tp) {}
};
struct my_variant : variant {};
int main() {
basic_string_view s;
my_variant v{s};
}
/usr/bin/ld: /tmp/ccFVb3Nc.o: in function `main':
102654.ii:(.text+0x1c): undefined reference to
`variant::variant(basic_string_view)'
Changing component from libstdc++ to c++ since this appears to be a frontend
problem.
[Bug libstdc++/98677] std::regex constructor triggers valgrind under clang++ with undefined sanitizer; possible use-after-move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98677 --- Comment #5 from Jonathan Wakely --- Yes, I used both ubsan and valgrind, and couldn't reproduce it with any version of GCC or clang I tried, including with the headers from GCC 10.2 I might try to reproduce it on Ubuntu, but if it's specific to Ubuntu then it should be reported to them, not here. Upstream GCC doesn't reproduce the problem.
[Bug other/102663] New: add an install-dvi Makefile target to the toplevel Makefile and all subdirectories
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102663 Bug ID: 102663 Summary: add an install-dvi Makefile target to the toplevel Makefile and all subdirectories Product: gcc Version: 12.0 URL: https://gcc.gnu.org/legacy-ml/gcc-patches/2016-10/msg0 0380.html Status: UNCONFIRMED Keywords: documentation, patch Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: egallager at gcc dot gnu.org Target Milestone: --- Some subdirectories have dvi targets that allow building of dvi-formatted documentation, but they don't have install-dvi targets, meaning the dvi files have to be copied to the docdir manually. I had a patch for this at one point, but it never got reviewed, and I'm not sure if it applies any longer: https://gcc.gnu.org/legacy-ml/gcc-patches/2016-10/msg00380.html
[Bug other/102657] libcody makefile is missing a mostlyclean target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102657 --- Comment #1 from Eric Gallager --- It looks like it's also missing a dvi target: Doing dvi in libcody make[2]: *** No rule to make target `dvi'. Stop. make[1]: *** [dvi-libcody] Error 1 make: *** [do-dvi] Error 2
[Bug analyzer/102662] New: [12 Regression] ICE in validate, at analyzer/constraint-manager.cc:581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102662
Bug ID: 102662
Summary: [12 Regression] ICE in validate, at
analyzer/constraint-manager.cc:581
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-checking, ice-on-valid-code
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
g++-12.0.0-alpha20211003 snapshot (g:d91056851c5c60f226e3192fb955d018b53eb66f)
ICEs when compiling the following piece of C code w/ -fanalyzer -fstrict-enums:
enum OpCode {
OP_MOVE,
OP_LOADK,
OP_LOADBOOL,
OP_LOADNIL,
OP_GETUPVAL,
OP_SETUPVAL
};
enum OpArg {
OpArgN,
OpArgU,
OpArgR,
OpArgK
};
void
symbexec_lastpc (enum OpCode symbexec_lastpc_op, enum OpArg luaP_opmodes)
{
switch (luaP_opmodes)
{
case OpArgN:
case OpArgK:
{
switch (symbexec_lastpc_op)
{
case OP_LOADNIL:
case OP_SETUPVAL:
break;
default:
break;
}
}
default:
break;
}
}
% g++-12.0.0 -fanalyzer -fstrict-enums -c c5smosbk.c
during IPA pass: analyzer
In function 'void symbexec_lastpc(OpCode, OpArg)':
cc1plus: internal compiler error: in validate, at
analyzer/constraint-manager.cc:581
0x91ca2d ana::bounded_ranges::validate() const
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211003/work/gcc-12-20211003/gcc/analyzer/constraint-manager.cc:581
0x1f62159
ana::bounded_ranges_manager::get_or_create_union(vec const&)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211003/work/gcc-12-20211003/gcc/analyzer/constraint-manager.cc:760
0x1f663ea ana::bounded_ranges_manager::make_case_label_ranges(gswitch const*,
tree_node*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211003/work/gcc-12-20211003/gcc/analyzer/constraint-manager.cc:937
0x1f6650d
ana::bounded_ranges_manager::create_ranges_for_switch(ana::switch_cfg_superedge
const&, gswitch const*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211003/work/gcc-12-20211003/gcc/analyzer/constraint-manager.cc:889
0x1f666ce
ana::bounded_ranges_manager::get_or_create_ranges_for_switch(ana::switch_cfg_superedge
const*, gswitch const*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211003/work/gcc-12-20211003/gcc/analyzer/constraint-manager.cc:867
0x1539ec8
ana::region_model::apply_constraints_for_gswitch(ana::switch_cfg_superedge
const&, gswitch const*, ana::region_model_context*, ana::rejected_constraint**)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211003/work/gcc-12-20211003/gcc/analyzer/region-model.cc:3341
0x152cab1 ana::program_state::on_edge(ana::exploded_graph&,
ana::exploded_node*, ana::superedge const*, ana::uncertainty_t*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211003/work/gcc-12-20211003/gcc/analyzer/program-state.cc:1018
0x151a9aa ana::exploded_graph::process_node(ana::exploded_node*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211003/work/gcc-12-20211003/gcc/analyzer/engine.cc:3575
0x151befa ana::exploded_graph::process_worklist()
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211003/work/gcc-12-20211003/gcc/analyzer/engine.cc:2788
0x151e395 ana::impl_run_checkers(ana::logger*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211003/work/gcc-12-20211003/gcc/analyzer/engine.cc:5364
0x151f240 ana::run_checkers()
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211003/work/gcc-12-20211003/gcc/analyzer/engine.cc:5435
0x150efe8 execute
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211003/work/gcc-12-20211003/gcc/analyzer/analyzer-pass.cc:87
[Bug bootstrap/84402] [meta] GCC build system: parallelism bottleneck
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402 --- Comment #42 from Eric Gallager --- Is this just about parallelism bottlenecks for the main build target (e.g. just `make` or `make all`), or does it apply to other Makefile targets, too? (e.g. the testsuite via `make check`, or docs via `make pdf` or something)
[Bug libstdc++/98677] std::regex constructor triggers valgrind under clang++ with undefined sanitizer; possible use-after-move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98677 --- Comment #4 from Egor Suvorov --- Note that the issue requires both UBSanitizer and Valgrind enabled simultaneously. Running with just one of them does not result in an error. The versions are ones installed in Ubuntu 20.04.3 Focal Fossa (amd64) by running `sudo apt install clang-10 valgrind` (you can get VM image from https://www.osboxes.org/ubuntu-server/) https://launchpad.net/ubuntu/focal/amd64/clang-10/1:10.0.0-4ubuntu1 https://launchpad.net/ubuntu/focal/amd64/valgrind/1:3.15.0-1ubuntu9.1 Unfortunately, I was unable to get more verbose output from either clang or Valgrind. So it may be Ubuntu-specific issue. Actually, the problem is not reproducible with clang-12, so it may be already be fixed.
[Bug testsuite/102658] [12 regression] Many test case failures after r12-4240
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102658 --- Comment #4 from Kewen Lin --- Created attachment 51576 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51576=edit rs6000-test-Adjust-test-cases-due-to-O2-vect Tested successfully on P9LE, note that it relies on r12-4273. Still checking force-parallel-8.c is one target specific failure or not.
[Bug c/102661] signed integer overflow not detected in comparison since gcc-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102661 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski --- Signed integer overflow is undefined. You need to either use -fwrapv which defines it as wrapping or you need to use unsigned typea to do the arithmetical operations or you need to do the overflow detection differently.
[Bug c/102661] signed integer overflow not detected in comparison since gcc-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102661 lrspam at sfr dot fr changed: What|Removed |Added Version|9.3.0 |8.4.0 --- Comment #1 from lrspam at sfr dot fr --- The behavior is observed with gcc 8.4 and 9.3, and may be later. It is not observed with gcc 7.5.
[Bug c/102661] New: signed integer overflow not detected in comparison since gcc-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102661
Bug ID: 102661
Summary: signed integer overflow not detected in comparison
since gcc-8
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: lrspam at sfr dot fr
Target Milestone: ---
$ uname -srmpio
Linux 5.4.0-88-generic x86_64 x86_64 x86_64 GNU/Linux
$ cat ioverflow.c
#include
#include
int
main (void)
{
int ia, ib, one;
one = 1;
ia = INT_MAX;
ib = ia;
printf ("%i %i %i\n", ia, ia + one, ia < ia + one);
ia += one;
printf ("%i %i %i\n", ib, ia, ib < ia);
}
$ gcc-8 -v
Using built-in specs.
COLLECT_GCC=gcc-8
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 8.4.0-3ubuntu2'
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib=auto --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.4.0 (Ubuntu 8.4.0-3ubuntu2)
RESULT observed:
$ gcc-8 ioverflow.c -o ioverflow
$ ./ioverflow
2147483647 -2147483648 1
2147483647 -2147483648 0
RESULT expected (as for gcc-7):
$ gcc-7 ioverflow.c -o ioverflow
$ ./ioverflow
2147483647 -2147483648 0
2147483647 -2147483648 0
[Bug c++/102660] Valid template default parameter of a friend function is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102660 Andrew Pinski changed: What|Removed |Added Keywords||rejects-valid --- Comment #1 from Andrew Pinski --- It might be a dup of bug 70608.
[Bug c++/102660] New: Valid template default parameter of a friend function is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102660
Bug ID: 102660
Summary: Valid template default parameter of a friend function
is rejected
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fchelnokov at gmail dot com
Target Milestone: ---
This is a presumably valid program:
```
struct A{
template
friend void show();
private:
int c;
};
template
void show(){
}
int main(){
show<>();
}
```
It is accepted by Clang, MSVC, but rejected in GCC, which complains about
default parameter of R (asking for forward declaration of the function). Demo:
https://gcc.godbolt.org/z/q1r1a9Ycn
Related discussion: https://stackoverflow.com/q/69341936/7325599
[Bug testsuite/100748] [12 regression] 30_threads/jthread/95989.cc fails after r12-843
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100748 --- Comment #7 from Jonathan Wakely --- Yes but the point of the test (and the change it is meant to be testing) is to verify it works before those changes.
