[Bug libstdc++/101794] std::lerp with NaN input does not result in NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101794 Andrew Pinski changed: What|Removed |Added See Also||https://github.com/microsof ||t/STL/issues/65#issuecommen ||t-563811523 --- Comment #2 from Andrew Pinski --- Discussion around MSVC's implementation is at https://github.com/microsoft/STL/issues/65#issuecomment-563811523 https://gcc.gnu.org/pipermail/gcc-patches/2019-March/518269.html The midpoint and lerp functions for floating point types come straight from the P0811R3 proposal, with no attempt at optimization. The paper: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0811r3.html >From everything, both libstdc++v3 and libc++ implementations are still correct but I am going to leave it up to someone else to decide that.
[Bug libstdc++/101794] std::lerp with NaN input does not result in NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101794 --- Comment #1 from Andrew Pinski --- The section of std::lerp in the standard does not define what value should be returned if t is nan. I have not tried to find out what other parts of the standard say but I think this might be just unspecified area of the standard ...
[Bug c++/101795] (x > QNaNf) is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101795 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection --- Comment #2 from Andrew Pinski --- Seems to be fixed in GCC 12+.
[Bug c++/96862] -frounding-math -std=c++2a error: '(1.29e+2 * 6.9314718055994529e-1)' is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96862 Andrew Pinski changed: What|Removed |Added Known to work||10.3.0, 11.1.0, 9.4.0 Known to fail||10.2.0, 9.3.0 Target Milestone|--- |9.4
[Bug c++/99801] Address sanitizer false positive with pointer to member function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99801 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2021-03-30 00:00:00 |2022-12-24 --- Comment #5 from Andrew Pinski --- -O0 -fsanitize=address
[Bug c++/99801] Address sanitizer false positive with pointer to member function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99801 --- Comment #4 from Andrew Pinski --- Created attachment 54155 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54155=edit Original testcase
[Bug c++/70885] Use MSB/LSB pointer-tagging for pointer-to-member representation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70885 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug target/101804] float_vector_all_ones_operand should be used more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101804 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0
[Bug rtl-optimization/101806] Extra zero extends for some arguments in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101806
--- Comment #3 from Andrew Pinski ---
Even a simple:
unsigned char g(unsigned char a, unsigned char b)
{
return ((~a) & b)&1;
}
Produces the extra zero extend.
But it is ok with:
unsigned char g(unsigned char *a, unsigned char *b)
{
return ((~*a) & *b)&1;
}
It looks like it is hard register related too ...
[Bug tree-optimization/101856] match_arith_overflow checks only mulv4_optab/umulv4_optab tables when smul_highpart_optab/umul_highpart_optab can produce decent code too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101856 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2022-12-25 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug target/108220] ICE: maximum number of generated reload insns per insn achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108220 Andrew Pinski changed: What|Removed |Added Keywords||inline-asm --- Comment #1 from Andrew Pinski --- I wonder if this inline-asm with the register is valid or not.
[Bug target/108220] New: ICE: maximum number of generated reload insns per insn achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108220 Bug ID: 108220 Summary: ICE: maximum number of generated reload insns per insn achieved (90) Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- Target: powerpc-e300c3-linux-gnu gcc 13.0.0 20221218 snapshot (g:fd69977febf399d1992bbf8d66ae9170e0a4dc9f) ICEs when compiling gcc/testsuite/gcc.target/powerpc/pr106550_1.c w/ -m32: % powerpc-e300c3-linux-gnu-gcc-13 -m32 -c gcc/testsuite/gcc.target/powerpc/pr106550_1.c during RTL pass: reload gcc/testsuite/gcc.target/powerpc/pr106550_1.c: In function 'foo': gcc/testsuite/gcc.target/powerpc/pr106550_1.c:17:1: internal compiler error: maximum number of generated reload insns per insn achieved (90) 17 | } | ^ 0xc8e805 lra_constraints(bool) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20221218/work/gcc-13-20221218/gcc/lra-constraints.cc:5137 0xc79e72 lra(_IO_FILE*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20221218/work/gcc-13-20221218/gcc/lra.cc:2375 0xc2fc29 do_reload /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20221218/work/gcc-13-20221218/gcc/ira.cc:5941 0xc2fc29 execute /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20221218/work/gcc-13-20221218/gcc/ira.cc:6127
[Bug tree-optimization/105327] Bogus use-after-free warning new in GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105327 --- Comment #2 from Andrew Pinski --- Switching around the order to do: g.p_ = 0; P p (new (v) T); Fixes the warning and I think correctly.
[Bug tree-optimization/105327] Bogus use-after-free warning new in GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105327 --- Comment #1 from Andrew Pinski --- I don't think this is a bogus one. std::shared_ptr owns the pointer once it is passed, not before. So when you do: mem_guard g (v); ... P p (new (v) T); ... the constructor of p might cause operator new to be called with a throw (after already taking the ownership of the argument) and the deconstructor of P is called and you get a delete called on the argument.
[Bug tree-optimization/101912] -Wmaybe-uninitialized false alarm in tzdb localtime.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101912 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection --- Comment #7 from Andrew Pinski --- Seems to be fixed on the trunk; that is there is no uninitialized warning on the trunk.
[Bug target/101922] mips: illegal instruction at -O3 with -mmsa -mloongson-mmi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101922 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0
[Bug c++/108219] [12/13 Regression] requirement fails on a valid expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108219 Andrew Pinski changed: What|Removed |Added Known to work||11.3.0 Last reconfirmed||2022-12-24 Target Milestone|--- |12.3 Keywords||needs-bisection, ||rejects-valid Ever confirmed|0 |1 Summary|requirement fails on a |[12/13 Regression] |valid expression|requirement fails on a ||valid expression Known to fail||12.1.0 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c++/108218] [12/13 Regression] Constant arguments in the new expression is not checked in unevaluated operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108218 --- Comment #7 from Steven Sun --- I got one simple idea as a workaround. I do not have the resources to do the tests. I agree anyone to take the following patch or the idea. >From 35b4186a0ed3671de603bed6df5fb1156f087581 Mon Sep 17 00:00:00 2001 From: Steven Sun Date: Sun, 25 Dec 2022 06:44:43 +0800 Subject: [PATCH] c++: escape unevaluated context in new-expression --- gcc/cp/init.cc | 5 + 1 file changed, 5 insertions(+) diff --git a/gcc/cp/init.cc b/gcc/cp/init.cc index b49a7ca9169..974ea95959e 100644 --- a/gcc/cp/init.cc +++ b/gcc/cp/init.cc @@ -3929,7 +3929,12 @@ build_new (location_t loc, vec **placement, tree type, /* Try to determine the constant value only for the purposes of the diagnostic below but continue to use the original value and handle const folding later. */ + /* Escape the possible unevaluated context. Constant folding does + not work in unevaluated context, but is required in nelts. */ + int old_cp_unevaluated_operand = cp_unevaluated_operand; + cp_unevaluated_operand = false; const_tree cst_nelts = fold_non_dependent_expr (nelts, complain); + cp_unevaluated_operand = old_cp_unevaluated_operand; /* The expression in a noptr-new-declarator is erroneous if it's of non-class type and its value before converting to std::size_t is -- 2.34.1
[Bug target/107548] STV doesn't consider vec_select
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107548 --- Comment #2 from CVS Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:3cf6d0e1830231dd47740e66926499db600b9ae4 commit r13-4886-g3cf6d0e1830231dd47740e66926499db600b9ae4 Author: Roger Sayle Date: Sat Dec 24 22:07:11 2022 + [Committed] Tweak new gcc.target/i386/pr107548-1.c for -march=cascadelake. My recently added testcases gcc.target/i386/pr107548-[12].c need to be tweaked slightly for -march=cascadelake. Committed as obvious. 2022-12-24 Roger Sayle gcc/testsuite/ChangeLog PR target/107548 * gcc.target/i386/pr107548-1.c: Match both vmovd and movd. * gcc.target/i386/pr107548-2.c: Match both vpaddq and paddq.
[Bug c++/108219] New: requirement fails on a valid expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108219
Bug ID: 108219
Summary: requirement fails on a valid expression
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vanyacpp at gmail dot com
Target Milestone: ---
This code compiles OK on clang, MSVC and GCC prior to 12:
template
concept test = requires
{
new T[1]{{ 42 }};
};
struct foobar
{
foobar(int);
};
int main()
{
static_assert(test);
new foobar[1]{{ 42 }};
}
But on GCC 12 it produces an error:
:14:19: error: static assertion failed
14 | static_assert(test);
| ^~~~
:14:19: note: constraints not satisfied
:2:9: required by the constraints of 'template concept test'
:2:16: in requirements [with T = foobar]
:4:5: note: the required expression 'new T(1)' is invalid, because
4 | new T[1]{{ 42 }};
| ^~~~
:4:5: error: could not convert '()'
from '' to 'foobar'
4 | new T[1]{{ 42 }};
| ^~~~
| |
|
I believe the error is incorrect and that this is a regression in GCC 12.
[Bug target/105116] ICE in lra_split_hard_reg_for, at lra-assigns.cc:1870 (error: unable to find a register to spill)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105116 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2022-12-24 Ever confirmed|0 |1 Keywords||ra --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug libstdc++/100806] deadlock in std::counting_semaphore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100806 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.2
[Bug c/105294] restrict pointer - disagreement with specification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105294
Matthew House changed:
What|Removed |Added
CC||mattlloydhouse at gmail dot com
--- Comment #2 from Matthew House ---
Isn't this example invalid per the spec? At `*r = 42;`, `&*r` is based on `s`.
However, `*p = 13;` modifies the same object that `*r` refers to, and `&*p` is
not based on `s`, so the behavior is undefined.
I've recently found another example which is valid under the current spec as
well as the two new proposed definitions in N3025 and N3058.
https://godbolt.org/z/ezvMfPd78
static int x;
__attribute__ ((noinline))
int f(int * restrict p) {
*p = 1;
if (p == ) {
*p = 2;
}
return *p;
}
int main(void) {
return f();
}
At `*p = 2;`, `&*p` is based on `p` under every definition. However, both GCC
and Clang incorrectly assume that the write to `*p` inside the `if` block
cannot affect the return value.
[Bug c++/108218] [12/13 Regression] Constant arguments in the new expression is not checked in unevaluated operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108218 --- Comment #6 from Steven Sun --- g:4df7f8c79835d56928f51f9e674d326300936e8e c++: don't do constexpr folding in unevaluated context The implicit constexpr patch revealed that we were doing constant evaluation of arbitrary expressions in unevaluated contexts, leading to failure when we tried to evaluate e.g. a call to declval. This is wrong more generally; only manifestly-constant-evaluated expressions should be evaluated within an unevaluated operand. Making this change revealed a case we were failing to mark as manifestly constant-evaluated. gcc/cp/ChangeLog: * constexpr.c (maybe_constant_value): Don't evaluate in an unevaluated operand unless manifestly const-evaluated. (fold_non_dependent_expr_template): Likewise. * decl.c (compute_array_index_type_loc): This context is manifestly constant-evaluated.
[Bug c++/108218] [12/13 Regression] Constant arguments in the new expression is not checked in unevaluated operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108218 --- Comment #5 from Steven Sun --- h:4df7f8c79835d56928f51f9e674d326300936e8e sorry, copied wrong hash code
[Bug c++/108218] [12/13 Regression] Constant arguments in the new expression is not checked in unevaluated operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108218 --- Comment #4 from Andrew Pinski --- (In reply to Steven Sun from comment #3) > Bisecting tells me: > > 2551cd4f9bc1afee444a56e03c1cee6899593da9 is bad > adcfd2c45c3523d74279b5fcac1d7c6c34dd1382 is good > > > > I think commit ddd25bd1a7c8f456bc914e34b77d43f39a1062d4 might be the root > cause. r12-2230-gddd25bd1a7c8f4
[Bug tree-optimization/86318] const local aggregates can be assumed not to be modified even when escaped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86318 Andrew Pinski changed: What|Removed |Added CC||jhaberman at gmail dot com --- Comment #3 from Andrew Pinski --- *** Bug 108217 has been marked as a duplicate of this bug. ***
[Bug middle-end/108217] bogus -Warray-bounds with pointer to constant local
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108217 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #5 from Andrew Pinski --- Then it is a dup of bug 86318. *** This bug has been marked as a duplicate of bug 86318 ***
[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 Bug 56456 depends on bug 108217, which changed state. Bug 108217 Summary: bogus -Warray-bounds with pointer to constant local https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108217 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/108218] [12/13 Regression] Constant arguments in the new expression is not checked in unevaluated operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108218 --- Comment #3 from Steven Sun --- Bisecting tells me: 2551cd4f9bc1afee444a56e03c1cee6899593da9 is bad adcfd2c45c3523d74279b5fcac1d7c6c34dd1382 is good I think commit ddd25bd1a7c8f456bc914e34b77d43f39a1062d4 might be the root cause.
[Bug middle-end/108217] bogus -Warray-bounds with pointer to constant local
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108217
--- Comment #4 from Andrew Pinski ---
The problem with const is GCC does not have an idea of a store once and then
become constant.
an example of that would be:
```
void ExternFunc(const int*);
int f();
int Bad() {
const int i = f();
const int* pi =
ExternFunc(pi);
return *pi;
}
int Good() {
const int i = f();
ExternFunc();
return i;
}
```
This is similar to LLVM/clang really because this does not come up that much.
[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 Bug 56456 depends on bug 108217, which changed state. Bug 108217 Summary: bogus -Warray-bounds with pointer to constant local https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108217 What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE |---
[Bug middle-end/108217] bogus -Warray-bounds with pointer to constant local
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108217
Josh Haberman changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|DUPLICATE |---
--- Comment #3 from Josh Haberman ---
> That being said there is a missed optimization but that is the same as PR
> 23384 .
> The const part is a misleading you really.
I think there are two issues here.
1. Escape analysis is not flow sensitive. I agree that aspect of my bug report
is a dup of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23384, and closing as
a dup is appropriate there.
2. Escape analysis does not take 'const-ness' of the underlying object into
account.
Let me illustrate (2) with an example that isolates that issue (Godbolt:
https://godbolt.org/z/16cv87s9d)
void ExternFunc(const int*);
int Bad() {
const int i = 0;
const int* pi =
ExternFunc(pi);
return *pi;
}
int Good() {
const int i = 0;
ExternFunc();
return i;
}
These two functions are effectively the same, but in Bad() GCC does not perform
constant propagation across the external function call. While it's true that
the pointer escapes, the underlying object is const and cannot change, so
constant propagation should work here, as it does in Good().
Currently GCC re-loads `i` from the stack in Bad(), even though we know
statically that the value must be zero.
The same missed optimization is present in Clang:
https://github.com/llvm/llvm-project/issues/59694
[Bug c++/108206] [12/13 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'error_mark' in merge_default_template_args, at cp/decl.cc:1563 since r12-7562-gfe548eb8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108206 Andrew Pinski changed: What|Removed |Added Severity|normal |trivial Summary|ICE: tree check: expected |[12/13 Regression] ICE: |tree that contains 'decl|tree check: expected tree |minimal' structure, have|that contains 'decl |'error_mark' in |minimal' structure, have |merge_default_template_args |'error_mark' in |, at cp/decl.cc:1563 since |merge_default_template_args |r12-7562-gfe548eb8436f3906 |, at cp/decl.cc:1563 since ||r12-7562-gfe548eb8436f3906
[Bug target/65568] ptrmem8.C:9:9: internal compiler error: in build_ptrmemfunc, at cp/typeck.c:7940
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65568 Andrew Pinski changed: What|Removed |Added CC||nightstrike at gmail dot com --- Comment #4 from Andrew Pinski --- *** Bug 108207 has been marked as a duplicate of this bug. ***
[Bug c++/108207] ICE in testcase g++.dg/other/ptrmem8.C on mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108207 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- Dup of bug 65568. *** This bug has been marked as a duplicate of bug 65568 ***
[Bug tree-optimization/108215] Does not optimize trivial case with bit operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108215 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Severity|normal |enhancement Last reconfirmed||2022-12-24 --- Comment #1 from Andrew Pinski --- Confirmed. Note GCC only started to optimize firewall3 in GCC 11 via jump threading.
[Bug middle-end/108217] bogus -Warray-bounds with pointer to constant local
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108217 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- clang does not warn even at all. That being said there is a missed optimization but that is the same as PR 23384 . The const part is a misleading you really. *** This bug has been marked as a duplicate of bug 23384 ***
[Bug tree-optimization/23384] escaped set should be flow sensitive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23384 Andrew Pinski changed: What|Removed |Added CC||jhaberman at gmail dot com --- Comment #11 from Andrew Pinski --- *** Bug 108217 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 Bug 56456 depends on bug 108217, which changed state. Bug 108217 Summary: bogus -Warray-bounds with pointer to constant local https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108217 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug middle-end/108217] bogus -Warray-bounds with pointer to constant local
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108217 Andrew Pinski changed: What|Removed |Added Keywords|diagnostic |missed-optimization --- Comment #1 from Andrew Pinski --- Well with -fno-inline, GCC warns too so
[Bug c++/108218] [12/13 Regression] Constant arguments in the new expression is not checked in unevaluated operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108218
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2022-12-24
Known to work||11.3.0
Ever confirmed|0 |1
Summary|[12 Regression] Constant|[12/13 Regression] Constant
|arguments in the new|arguments in the new
|expression is not checked |expression is not checked
|in unevaluated operand |in unevaluated operand
Known to fail||12.1.0
Target Milestone|--- |12.3
Keywords||needs-bisection,
||rejects-valid
--- Comment #2 from Andrew Pinski ---
Confirmed.
Here is a rejects valid code:
template
concept C = requires
{
new int[(int)sizeof(T) - 4];
};
template
class CC {
CC() requires C {
new int[(int)sizeof(T) - 4];
}
CC() {
}
};
template class CC;
[Bug target/106959] [13 Regression] ICE in curr_insn_transform, at lra-constraints.cc:4168 (error: unable to generate reloads), or ICE in simplify_subreg, at simplify-rtx.cc:7405 since r13-2100-g5cccc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106959 Roger Sayle changed: What|Removed |Added CC||roger at nextmovesoftware dot com Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Roger Sayle --- This should now be fixed on mainline. Thanks HJ and Uros.
[Bug tree-optimization/108197] [12/13 Regression] -Wstringop-overread emitted on simple boost small_vector code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108197 --- Comment #2 from Stephen --- Richard, are you saying this a bug in the boost code? It's not quite clear to me from your message. Can you be more specific about what the bug is in that case?
[Bug modula2/108183] wrong code generated in the modula2 scaffold mechanism
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108183
--- Comment #14 from Iain Sandoe ---
coming back to this code:
===
extern "C" void
_M2_termios_init (int, char *[], char *[])
{
}
extern "C" void
_M2_termios_fini (int, char *[], char *[])
{
}
extern "C" void
_M2_termios_dep (void)
{
}
struct _M2_termios_ctor { _M2_termios_ctor (); } _M2_termios_ctor;
_M2_termios_ctor::_M2_termios_ctor (void)
{
// M2RTS_RegisterModule ("termios", _M2_termios_init, _M2_termios_fini,
// _M2_termios_dep);
}
I think this is not currently doing what is expected (it's certainly
inconsistent with the compiler's PoV .. from my debugging).
The declaration in the compiler thinks that _M2_termios_ctor is the symbol for
a function. Where (because of the way this shim is written) it's actually the
name of a static variable. Which means if it was ever called "boom".
However, my current understanding us that M2_link() is just a mechanism to
ensure that all the library code is pulled in (so perhaps it would never be
called). Actually, that should not be necessary if the decls are correctly
marked as "used".
Furthermore, the initialisation code for the static instance will be entered
automatically into the startup (so it's out of your control).
=
What about, instead:
extern "C" void
_M2_termios_init (int, char *[], char *[])
{
}
extern "C" void
_M2_termios_fini (int, char *[], char *[])
{
}
extern "C" void
_M2_termios_dep (void)
{
}
extern "C" void
_M2_termios_ctor (void)
{
M2RTS_RegisterModule ("termios", _M2_termios_init, _M2_termios_fini,
_M2_termios_dep);
}
== now the symbol will indeed refer to the CTOR that causes the module to be
registered. As it is written that CTOR will not be called unless you do it.
IFF you want it to be called "automatically" at program startup .. you can mark
it
__attribute__((constructor))
[Bug target/106933] [13 Regression] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn) since r13-2049-g6f94923dea21bd92
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106933 Roger Sayle changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Roger Sayle --- This should now be fixed on mainline. Thanks HJ and Uros.
[Bug c++/108218] [12 Regression] Constant arguments in the new expression is not checked in unevaluated operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108218
--- Comment #1 from Steven Sun ---
My concern is that, expressions within the require expressions are also
considered as "unevaluated operands".
Thus, the following concept is evaluated as true, but the program is ill-formed
and does not compile (since gcc 12)
https://godbolt.org/z/bcc398chG
```
template
concept C = requires
{
new int[(int)sizeof(T) - 4];
};
template requires C
class CC {
CC() {
new int[(int)sizeof(T) - 4];
}
};
template class CC;
```
: In instantiation of 'CC::CC() [with T = char]':
:16:16: required from here
:12:32: error: size '-3' of array is negative
12 | new int[(int)sizeof(T) - 4];
| ~~~^~~
[Bug c++/108218] New: [12 Regression] Constant arguments in the new expression is not checked in unevaluated operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108218
Bug ID: 108218
Summary: [12 Regression] Constant arguments in the new
expression is not checked in unevaluated operand
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: StevenSun2021 at hotmail dot com
Target Milestone: ---
```
int main() {
decltype(new int[-1]) a; // compiles with g++-12! <- regression here
// does not compile with g++-11
auto b = new int[-1];// does not compile with g++-12
// does not compile with g++-11
}
```
https://godbolt.org/z/aMGMrbfrd
expected behavior:
if, after conversion to std::size_t, the first dimension is a core constant
expression and it is potentially evaluated, the program is ill-formed.
https://en.cppreference.com/w/cpp/language/new
gcc(<=11.3 (current version)) and clang(>=3) does this check.
[Bug c++/81051] virtual base access during construction crashes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81051
Matthew House changed:
What|Removed |Added
CC||mattlloydhouse at gmail dot com
--- Comment #4 from Matthew House ---
Both of these example programs result in undefined behavior.
The cited subclause, C++14 12.7 [class.dtor] p3, does not apply, since the call
expression neither forms a pointer to a member nor accesses the value of a
member. Instead, the relevant subclause is C++14 12.6.2 [class.base.init] p14.
The example for that subclause demonstrates that a member function inherited
from an initialized base class may not be called directly from the derived
object until all base class subobjects are initialized.
In the first program, this->Func() calls the inherited member function Func of
Derived, but the initializer for B has not completed yet, so the behavior is
undefined. The same applies to the p->Func() call in the second program.
However, this segfault persists if this->Func() or p->Func() is replaced with
((A*)this)->Func() or ((A*)p)->Func() in either example. The conversion doesn't
result in UB, since the construction of Derived has started, and the function
call doesn't result in UB, since the A subobject is already initialized. Thus,
the behavior of GCC is still erroneous in this case.
struct A
{
int Func () { return x++; }
int x = 5;
};
struct B { B (int) {} };
struct Derived : virtual A, B
{
friend int f (Derived *p) { return ((A *) p)->Func (); }
Derived () : A (), B (f (this)) {}
};
int main()
{
Derived d;
}
[Bug middle-end/108217] New: bogus -Warray-bounds with pointer to constant local
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108217
Bug ID: 108217
Summary: bogus -Warray-bounds with pointer to constant local
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: jhaberman at gmail dot com
Target Milestone: ---
Repro:
void ExternFunc1();
void ExternFunc2(const int*);
char mem[32];
static void StaticFunc(const int* i) {
void* ptr = (void*)0;
switch (*i) {
case 0:
ExternFunc2(i);
return;
case 1:
__builtin_memcpy(mem, , sizeof(ptr));
return;
case 2: {
__builtin_memcpy(mem, , 32);
return;
}
}
}
void Bad() {
const int i = 1;
ExternFunc1();
StaticFunc();
}
This reproduces on trunk according to Godbolt: https://godbolt.org/z/vYGo1z6bG
Godbolt also indicates a missed optimization, which is probably related to the
bogus warning. Clang correctly performs constant propagation of the local `i`,
whereas GCC seems to think that all cases of the switch() are reachable.
It is true that escapes, but mutating `i` is UB because it is const, so it
should be legal to perform constant propagation here.
Additionally, even if ExternFunc2() mutated `i`, it would be too late to change
its value in time to affect the switch().
[Bug middle-end/108102] rust bootstrap comparison failure on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102 --- Comment #7 from Stefan Schulze Frielinghaus --- The difference in the assembly output shown in comment 2 happens in function void AssociatedImplTrait::setup_associated_types ( const TyTy::BaseType *self, const TyTy::TypeBoundPredicate )
[Bug middle-end/108102] rust bootstrap comparison failure on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102 --- Comment #6 from Stefan Schulze Frielinghaus --- Created attachment 54154 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54154=edit preprocessed rust-hir-trait-resolve.cc
