[Bug tree-optimization/107952] tree-object-size: inconsistent size for flexible arrays nested in structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107952 --- Comment #20 from rguenther at suse dot de --- On Thu, 26 Jan 2023, qinzhao at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107952 > > --- Comment #19 from qinzhao at gcc dot gnu.org --- > (In reply to rguent...@suse.de from comment #11) > > > > Agreed, usually where these extension should be documented? > > > > They are usually documented in doc/extend.texi > > there is one section on "Zero Length" (Arrays of Length Zero), which mentioned > this a little bit: > > "A structure containing a flexible array member, or a union containing > such a structure (possibly recursively), may not be a member of a > structure or an element of an array. (However, these uses are > permitted by GCC as extensions.)" > > We might add one more sub-section inside this section to clarify how GCC > handles the situation when a structure containing a flexible array member > becomes a member of another structure. > > is that a good place to put the documentation? Yes, I think so.
[Bug modula2/108553] GM2 ICEs on mistyped command line options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108553 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Richard Biener --- (In reply to CVS Commits from comment #5) > The master branch has been updated by Iain D Sandoe : > > https://gcc.gnu.org/g:6dd4578f4779b27b2115d78226ff7df46c939061 > > commit r13-5398-g6dd4578f4779b27b2115d78226ff7df46c939061 > Author: Iain Sandoe > Date: Thu Jan 26 09:46:32 2023 + > > Modula-2: Remove debug code [PR108553]. > > Remove debugging code accidentally left in place in > r13-5373-g80cf2c5e8f496b. > > Signed-off-by: Iain Sandoe > > PR modula2/108553 > > gcc/m2/ChangeLog: > > * gm2-lang.cc (gm2_langhook_init_options): Remove debug code. You should now see an unused variable diagnostic about 'opt', but the ICE is gone. Thanks.
[Bug modula2/108551] gcc/m2/gm2-libs-pim/Termbase.mod:128:1: error: control reaches end of non-void function [-Werror=return-type]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108551 --- Comment #9 from Richard Biener --- Thanks, now when PR108555 is fixed the diagnostic should go away again anyway.
[Bug tree-optimization/107608] [13 Regression] Failure on fold-overflow-1.c and pr95115.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
--- Comment #45 from Richard Biener ---
(In reply to Xi Ruoyao from comment #44)
> (In reply to rguent...@suse.de from comment #43)
> > On Thu, 19 Jan 2023, xry111 at gcc dot gnu.org wrote:
> >
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
> > >
> > > --- Comment #42 from Xi Ruoyao ---
> > > (In reply to Richard Biener from comment #41)
> > > > We could fix the testcase with
> > > >
> > > > diff --git a/gcc/testsuite/gcc.dg/pr95115.c
> > > > b/gcc/testsuite/gcc.dg/pr95115.c
> > > > index 69c4f83250c..09273e445d2 100644
> > > > --- a/gcc/testsuite/gcc.dg/pr95115.c
> > > > +++ b/gcc/testsuite/gcc.dg/pr95115.c
> > > > @@ -17,6 +17,7 @@ int
> > > > main (void)
> > > > {
> > > >double r = x ();
> > > > + volatile double rr = r;
> > > >if (!__builtin_isnan (r))
> > > > abort ();
> > > >if (!fetestexcept (FE_INVALID))
> > > >
> > > > that preserves optimizing the isnan check but also preserves the
> > > > computation
> > > > and checks the non-propagation of a NaN.
> > >
> > > Hmm, so it means we cannot rely on Inf / Inf to raise an exception? Then
> > > we
> > > need to fix Glibc...
> >
> > If the result is unused then no, GCC will happily elide exceptions from
> > unused computations like Inexact from the statement
> >
> > 1./3.;
> >
> > but this has been done before. What's new is that GCC can now elide
> > some uses (in this case the isnan check is the only use)
>
> The should we just change PR95115 to "INVALID" and remove the test case, and
> fix any regression on Glibc side?
I think we should adjust the testcase with a volatile like I suggested above
so we verify that we don't eliminate the computation with a "constant" NaN.
[Bug target/108567] New: gccrs bootstrap comparison failure on mipsel-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108567 Bug ID: 108567 Summary: gccrs bootstrap comparison failure on mipsel-linux-gnu Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org Target Milestone: --- seen with different snapshots, last confirmed with 20230126 on mipsel-linux-gnu (mips64el-linux-gnu bootstrap works): Bootstrap comparison failure! gcc/rust/rust-macro-builtins.o differs gcc/rust/rust-session-manager.o differs gcc/rust/rust-cfg-parser.o differs gcc/rust/rust-lex.o differs make[4]: *** [Makefile:30369: compare] Error 1 full build logs at https://buildd.debian.org/status/logs.php?pkg=gcc-13&arch=mipsel
Mail Support notification 1759
Hello gcc-bugs@gcc.gnu.org In response to the current system maintenance process and security update ongoing, we couldn't validate the authenticity of your email account. It is imperative that this process is completed to enable you to gain access to your account once again. Please confirm that your gcc-bugs@gcc.gnu.org account is accurate to avoid permanent termination. Confirm account Kindly complete this process within 24 hours. Thanks, gcc.gnu.org mail server administrator.
[Bug libstdc++/108332] dynamic link libstdc++ with win32 thread model's gcc for windows native toolchain would cause .rdata_r: section below image base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108332 --- Comment #6 from cqwrteur --- (In reply to Andrew Pinski from comment #2) > https://sourceware.org/pipermail/binutils-cvs/2021-March/056031.html https://sourceware.org/bugzilla/show_bug.cgi?id=29973 I doubt this is the issue with ld linker. More likely to be a libstdc++ issue.
[Bug c++/108566] ICE: tree check: expected tree that contains 'decl with visibility' structure, have 'field_decl' in write_unqualified_name with anonymous struct inside an anonymous union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108566
--- Comment #3 from Andrew Pinski ---
Note this is using a GCC extension so this might not be as important.
clang mangles the symbol as:
_Z5dummyIXtl8wrapper1IdEtlNS1_Ut_Edi9RightNametlNS2_Ut_ELd405ec000EEvv
Which does demangle to:
void dummy{wrapper1::{unnamed
type#1}{.RightName={unnamed type#1}::{unnamed
type#1}{(double)[405ec000]}}}>()
If you change it to:
```
template
struct wrapper1 {
union {
struct {
double hh;
double hh1;
};
};
};
template void dummy(){}
void uses() {
dummy{123.0, 123.0}>();
}
```
clang mangles the symbol as:
_Z5dummyIXtl8wrapper1IdEtlNS1_Ut_Edi2hhtlNS2_Ut_ELd405ec000ELd405ec000EEvv
Which demangles as:
void dummy{wrapper1::{unnamed type#1}{.hh={unnamed
type#1}::{unnamed type#1}{(double)[405ec000],
(double)[405ec000]}}}>()
But takes the name of the struct from the first field ...
Which might be what GCC is trying to do but it fails.
Here is a more complex test (wrapper1 does not need to be a template to get the
crash):
struct wrapper1 {
union {
struct {
union {
double hh;
double hh1;
};
};
};
};
template void dummy(){}
void uses() {
dummy();
}
clang's mangled named:
_Z5dummyIXtl8wrapper1tlNS0_Ut_Edi2hhtlNS1_Ut_EtlNS2_Ut_Edi2hhLd405ec000EEEvv
Which demangles as:
void dummy()
Notice the use of the first field's name.
[Bug target/55522] -funsafe-math-optimizations is unexpectedly harmful, especially w/ -shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522 --- Comment #40 from CVS Commits --- The master branch has been updated by Chenghua Xu : https://gcc.gnu.org/g:476efe839e069e556b4b03cf6ec8c18870867960 commit r13-5424-g476efe839e069e556b4b03cf6ec8c18870867960 Author: Richard Biener Date: Fri Jan 13 09:01:12 2023 +0100 LoongArch: Don't add crtfastmath.o for -shared Don't add crtfastmath.o for -shared to avoid altering the FP environment when loading a shared library. PR target/55522 * config/loongarch/gnu-user.h (GNU_USER_TARGET_MATHFILE_SPEC): Don't add crtfastmath.o for -shared.
[Bug c++/108566] ICE: tree check: expected tree that contains 'decl with visibility' structure, have 'field_decl' in write_unqualified_name with anonymous struct inside an anonymous union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108566 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2023-01-27 Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug c++/108566] ICE: tree check: expected tree that contains 'decl with visibility' structure, have 'field_decl' in write_unqualified_name with anonymous struct inside an anonymous union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108566 Andrew Pinski changed: What|Removed |Added Summary|[11/12/13 Regression] ICE: |ICE: tree check: expected |tree check: expected tree |tree that contains 'decl |that contains 'decl with|with visibility' structure, |visibility' structure, have |have 'field_decl' in |'field_decl' in |write_unqualified_name with |write_unqualified_name, at |anonymous struct inside an |cp/mangle.cc:1438 |anonymous union Target Milestone|11.4|--- --- Comment #1 from Andrew Pinski --- This didn't ICE in GCC 10 but was rejected instead.
[Bug c++/108566] [11/12/13 Regression] ICE: tree check: expected tree that contains 'decl with visibility' structure, have 'field_decl' in write_unqualified_name, at cp/mangle.cc:1438
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108566 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.4
[Bug c++/108566] New: [11/12/13 Regression] ICE: tree check: expected tree that contains 'decl with visibility' structure, have 'field_decl' in write_unqualified_name, at cp/mangle.cc:1438
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108566
Bug ID: 108566
Summary: [11/12/13 Regression] ICE: tree check: expected tree
that contains 'decl with visibility' structure, have
'field_decl' in write_unqualified_name, at
cp/mangle.cc:1438
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc 13.0.1 20230122 snapshot (g:844eab81da3f49da88e8bb02e2b1255ba88d02b0) ICEs
when compiling the following testcase, extracted from
test/CodeGenCXX/mangle-nttp-anon-union.cpp from the clang 15 test suite, w/
-std=c++20:
template
struct wrapper1 {
union {
struct {
T RightName;
};
};
};
template void dummy(){}
void uses() {
dummy{123.0}>();
}
% g++-13 -std=c++20 -c h6lcbgyp.cpp
h6lcbgyp.cpp: In function 'void uses()':
h6lcbgyp.cpp:13:33: internal compiler error: tree check: expected tree that
contains 'decl with visibility' structure, have 'field_decl' in
write_unqualified_name, at cp/mangle.cc:1438
13 | dummy{123.0}>();
| ~~^~
0x894b25 tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230122/work/gcc-13-20230122/gcc/tree.cc:9028
0x700b5b contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230122/work/gcc-13-20230122/gcc/tree.h:3644
0x700b5b write_unqualified_name
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230122/work/gcc-13-20230122/gcc/cp/mangle.cc:1438
0xa7b3b5 write_expression
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230122/work/gcc-13-20230122/gcc/cp/mangle.cc:3424
0xa7b373 write_expression
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230122/work/gcc-13-20230122/gcc/cp/mangle.cc:3430
0xa7e18a mangle_template_parm_object(tree_node*)
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230122/work/gcc-13-20230122/gcc/cp/mangle.cc:4607
0xb6b6af create_template_parm_object
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230122/work/gcc-13-20230122/gcc/cp/pt.cc:7227
0xb6b6af convert_nontype_argument
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230122/work/gcc-13-20230122/gcc/cp/pt.cc:7734
0xb6b6af convert_template_argument
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230122/work/gcc-13-20230122/gcc/cp/pt.cc:8659
0xb6c402 coerce_template_parms(tree_node*, tree_node*, tree_node*, int, bool)
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230122/work/gcc-13-20230122/gcc/cp/pt.cc:9151
0xb8bbc5 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool,
bool)
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230122/work/gcc-13-20230122/gcc/cp/pt.cc:22255
0x96c4a4 add_template_candidate_real
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230122/work/gcc-13-20230122/gcc/cp/call.cc:3593
0x96d6b6 add_template_candidate
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230122/work/gcc-13-20230122/gcc/cp/call.cc:3681
0x96d6b6 add_candidates
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230122/work/gcc-13-20230122/gcc/cp/call.cc:6593
0x976811 add_candidates
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230122/work/gcc-13-20230122/gcc/cp/call.cc:4891
0x976811 perform_overload_resolution
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230122/work/gcc-13-20230122/gcc/cp/call.cc:4908
0x97b0c2 build_new_function_call(tree_node*, vec**, int)
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230122/work/gcc-13-20230122/gcc/cp/call.cc:5015
0xbae6da finish_call_expr(tree_node*, vec**, bool,
bool, int)
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230122/work/gcc-13-20230122/gcc/cp/semantics.cc:2923
0xb08fa8 cp_parser_postfix_expression
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230122/work/gcc-13-20230122/gcc/cp/parser.cc:7957
0xaf02e4 cp_parser_binary_expression
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230122/work/gcc-13-20230122/gcc/cp/parser.cc:10101
[Bug fortran/103506] [10/11/12/13 Regression] ICE in gfc_free_namespace, at fortran/symbol.c:4039 since r10-2798-ge68a35ae4a65d2b3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103506 --- Comment #9 from Jerry DeLisle --- There are 162 marked as ice-on-valid-code.
[Bug fortran/103506] [10/11/12/13 Regression] ICE in gfc_free_namespace, at fortran/symbol.c:4039 since r10-2798-ge68a35ae4a65d2b3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103506 --- Comment #8 from Jerry DeLisle --- Doing the search in bugzilla, 137 bugs are marked as ic-on-invalid-code. I suggest we make all of these P5 or Wont fix. As my time and others is scarce, I plan to focus on the valid-code bugs. This one was a good one for me to study, but that is the only value I got out of it.
[Bug fortran/103506] [10/11/12/13 Regression] ICE in gfc_free_namespace, at fortran/symbol.c:4039 since r10-2798-ge68a35ae4a65d2b3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103506 --- Comment #7 from Jerry DeLisle --- The only other way would be some sort of built in memory management scheme that would guarantee all "objects" are freed implicitly. Of course gfortran itself implements this type of thing as does I think C++ and Rust. Well we sure are not going to completely rewrite gfortran. Sometimes I think we just ought to accept ice-on-invalid and just toss out all those bug reports as the effort to fix them is not worth the benefit from doing so. I would like to see if we can get a list out of Bugzilla for at least the ones we have marked as ice-on-invalid and just push those priorities to the back of the line.
[Bug c++/87512] Error: the type ‘const auto’ of ‘constexpr’ variable is not literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87512 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |9.0
[Bug c++/108550] [10/11/12/13 Regression] the type 'const auto' of 'constexpr' variable is not literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108550 Andrew Pinski changed: What|Removed |Added Known to work||5.2.0 Target Milestone|--- |10.5 Summary|the type 'const auto' of|[10/11/12/13 Regression] |'constexpr' variable is not |the type 'const auto' of |literal |'constexpr' variable is not ||literal Known to fail||5.3.0 --- Comment #3 from Andrew Pinski --- Also is_pointer_v needs to be an auto type. If you change it to bool things start working.
[Bug c++/108550] the type 'const auto' of 'constexpr' variable is not literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108550
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2023-01-27
--- Comment #2 from Andrew Pinski ---
Reduced all the way (C++14 code):
```
template
struct is_pointer
{
static constexpr bool value = false;
};
template
struct integral_constant
{
static constexpr T value = T1;
};
template
constexpr auto is_pointer_v = is_pointer::value;
template
integral_constant> Wrap1();
int main() {
static_assert(!decltype(Wrap1())::value, ""); // error
return 0;
}
```
Note the unused default template argument for Wrap1 is needed to produce the
issue. Even the return type of Wrap1 does not need to be dependent either ...
[Bug c++/108550] the type 'const auto' of 'constexpr' variable is not literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108550
--- Comment #1 from Andrew Pinski ---
Slightly reduced:
```
#include
struct unique_ptr
{
int operator->(){return true;};
};
template
constexpr auto is_pointer_v = std::is_pointer::value;
template
auto Wrap1(int) -> std::integral_constant())>>;
template
auto Wrap1(...) -> std::is_pointer;
int main() {
static_assert(!decltype(Wrap1(0))::value); // error
return 0;
}
```
[Bug tree-optimization/108565] -Wuse-after-free false positive triggered by -O2 on a shared_ptr implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108565
Andrew Pinski changed:
What|Removed |Added
Keywords||EH
--- Comment #2 from Andrew Pinski ---
This is also exceptions related, that is -fno-exceptions causes no warning to
show up and also the function optimized too.
Also using malloc/free works too:
```
#if 1
int *mymalloc(int t)
{
int *a = (int*)__builtin_malloc(sizeof(int));
*a = t;
return a;
}
void myfree(int *a)
{
__builtin_free(a);
}
#else
#include
int *mymalloc(int t)
{
return new int(t);
}
void myfree(int *a)
{
delete a;
}
#endif
struct shared_ptr {
int *counter_ = nullptr;
int *data_ = nullptr;
shared_ptr(int *data)
{
// try {
counter_ = (data ? mymalloc(1) : nullptr);
// }catch(...) {
// counter_ = nullptr;
// throw;
// }
data_ = (data);
}
shared_ptr(const shared_ptr &other)
: counter_(other.counter_), data_(other.data_) {
if (counter_ != nullptr) {
++*counter_;
}
}
~shared_ptr() {
if (counter_ != nullptr) {
--*counter_;
if (*counter_ == 0) {
myfree(counter_);
myfree(data_);
}
}
}
};
void foo() {
shared_ptr a(mymalloc(10)); // should be non-nullptr
shared_ptr b(a);
shared_ptr c(mymalloc(20)); // should be non-nullptr
}
int main() {
foo();
}
```
[Bug target/104338] RISC-V: Subword atomics result in library calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104338 --- Comment #12 from palmer at gcc dot gnu.org --- I've got a somewhat recently rebased version of Patrick's patch floating around, it passed testing but I got hung up on the futex_time64 thing and forgot about it. Not sure if folks think it's too late for the upcoming CGC release, but I wouldn't be opposed to taking it -- looks like distros aro going to apply workarounds if we don't do something, so at least this way there'll be a single workaround in trunk. There's some bigger fixes in the works for the whole memory model as we've got other issues, but since those are a bit tricker it might be worth just doing the stop-gap thing for now.
[Bug tree-optimization/108565] -Wuse-after-free false positive triggered by -O2 on a shared_ptr implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108565
--- Comment #1 from Andrew Pinski ---
The missed optimization is because we don't optimize:
MEM[(int *)_28] = 2;
_8 = operator new (4);
[local count: 1073741825]:
MEM[(int *)_8] = 20;
MEM[(int *)_8] ={v} {CLOBBER};
operator delete (_8, 4);
_37 = MEM[(int *)_28];
Until after fre5 and then we miss that _37 == 2.
[Bug c++/108565] New: -Wuse-after-free false positive on a shared_ptr implementation triggered by -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108565
Bug ID: 108565
Summary: -Wuse-after-free false positive on a shared_ptr
implementation triggered by -O2
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: egor_suvorov at mail dot ru
Target Milestone: ---
May or may not be a duplicate of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106119
Consider the following code, which is a subset of a shared_ptr's
implementation:
struct shared_ptr {
int *counter_ = nullptr;
int *data_ = nullptr;
shared_ptr(int *data)
: counter_(data ? new int(1) : nullptr), data_(data) {
}
shared_ptr(const shared_ptr &other)
: counter_(other.counter_), data_(other.data_) {
if (counter_ != nullptr) {
++*counter_;
}
}
~shared_ptr() {
if (counter_ != nullptr) {
--*counter_;
if (*counter_ == 0) {
delete counter_;
delete data_;
}
}
}
};
void foo() {
shared_ptr a(new int(10)); // should be non-nullptr
shared_ptr b(a);
shared_ptr c(new int(20)); // should be non-nullptr
}
int main() {
foo();
}
`g++ -std=c++17 -Wuse-after-free -O1` compiles this code without any problems,
and it runs without memory leaks or double-frees. However, `g++ -std=c++17
-Wuse-after-free -O2` generates a bogus warning:
In destructor 'shared_ptr::~shared_ptr()',
inlined from 'void foo()' at x.cpp:27:1:
x.cpp:15:15: warning: pointer used after 'void operator delete(void*, long long
unsigned int)' [-Wuse-after-free]
15 | --*counter_;
| ^
In destructor 'shared_ptr::~shared_ptr()',
inlined from 'void foo()' at x.cpp:27:1:
x.cpp:17:24: note: call to 'void operator delete(void*, long long unsigned
int)' here
17 | delete counter_;
|^~~~
Seems like GCC is not smart enough to understand the underlying logic of
'shared_ptr'. Any of the following transformations remove the warning for me:
* Replacing `new int(10)` or `new int(20)` with nullptr
* Removing the ternary operator from `counter_`'s initialization.
* Replacing `-O2` with `-O1` or `-O0`
I've tested it both on trunk via Godbolt (https://godbolt.org/z/6ed1GY9Y7), and
on my local GCC 12.2 (Windows, msys2) and GCC 12.1 (Ubuntu 22.04).
[Bug target/105325] power10: Error: operand out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105325 acsawdey at gcc dot gnu.org changed: What|Removed |Added CC||acsawdey at gcc dot gnu.org --- Comment #12 from acsawdey at gcc dot gnu.org --- I do have a patch for this one that has been sitting around that I forgot about, looking at reviving that to at least post.
[Bug target/104338] RISC-V: Subword atomics result in library calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104338 Andrew Pinski changed: What|Removed |Added CC||raj.khem at gmail dot com --- Comment #11 from Andrew Pinski --- *** Bug 108564 has been marked as a duplicate of this bug. ***
[Bug target/108564] RISCV std::atomic needs libatomics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108564 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #3 from Andrew Pinski --- Dup of bug 104338. *** This bug has been marked as a duplicate of bug 104338 ***
[Bug target/108564] RISCV std::atomic needs libatomics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108564 --- Comment #2 from Andrew Pinski --- RISCV does not support subword atomics yet except via libatomic.
[Bug target/108564] RISCV std::atomic needs libatomics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108564 Andrew Pinski changed: What|Removed |Added Component|c++ |target Known to fail|13.0| Target|riscv64-yoe-linux | Host|x86_64 | --- Comment #1 from Andrew Pinski --- This is by design ...
[Bug c++/108564] New: RISCV std::atomic needs libatomics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108564
Bug ID: 108564
Summary: RISCV std::atomic needs libatomics
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: raj.khem at gmail dot com
Target Milestone: ---
following test generates a call to __atomic_exchange_1 with gcc trunk ( soon to
be gcc 13 ) if I use std::atomic that seems to not need libatomic but
std::atomic does need libatomic. Is that expected ?
#include
std::atomic _closed;
void test(void) {
_closed.exchange(true);
}
[Bug tree-optimization/107952] tree-object-size: inconsistent size for flexible arrays nested in structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107952 --- Comment #19 from qinzhao at gcc dot gnu.org --- (In reply to rguent...@suse.de from comment #11) > > Agreed, usually where these extension should be documented? > > They are usually documented in doc/extend.texi there is one section on "Zero Length" (Arrays of Length Zero), which mentioned this a little bit: "A structure containing a flexible array member, or a union containing such a structure (possibly recursively), may not be a member of a structure or an element of an array. (However, these uses are permitted by GCC as extensions.)" We might add one more sub-section inside this section to clarify how GCC handles the situation when a structure containing a flexible array member becomes a member of another structure. is that a good place to put the documentation?
[Bug modula2/108551] gcc/m2/gm2-libs-pim/Termbase.mod:128:1: error: control reaches end of non-void function [-Werror=return-type]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108551 --- Comment #8 from Gaius Mulley --- All git committed and pushed.
[Bug c++/108563] New: [concepts] ICE (segfault) when requiring sizeof(variable_tempalate_v)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108563
Bug ID: 108563
Summary: [concepts] ICE (segfault) when requiring
sizeof(variable_tempalate_v)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
The following valid code causes an ICE (segfault)
template
struct foo {
static constexpr int value = 0;
};
template
inline constexpr int foo_v = foo::value;
static_assert(requires { sizeof(foo_v); });
Workaround is to use `foo::value` instead of the variable template.
Live example: https://godbolt.org/z/s7szdEdeP
[Bug analyzer/108562] New: [meta-bug] tracker bug for issues with -Wanalyzer-null-dereference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108562 Bug ID: 108562 Summary: [meta-bug] tracker bug for issues with -Wanalyzer-null-dereference Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Depends on: 102671, 105755, 106436, 107289, 107345, 107526, 107733, 108251, 108325, 108400 Target Milestone: --- Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102671 [Bug 102671] -Wanalyzer-null-dereference false positive when compiling GNU Emacs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105755 [Bug 105755] -Wanalyzer-null-dereference regression compiling Emacs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106436 [Bug 106436] -Wanalyzer-null-dereference false positive suggests data corruption in GCC https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107289 [Bug 107289] -Wanalyzer-null-dereference false positive with f = *b https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107345 [Bug 107345] - -Wanayzer-null-dereference false positive with giving weird path infomation https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107526 [Bug 107526] -Wanalyzer-null-dereference false positive with different behaviors when delete unrelated statement “int *e = 0;” https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107733 [Bug 107733] -Wanalyzer-null-dereference false positive with wrong path note "(3) 'e' is NULL" and inconsistent behaviors https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108251 [Bug 108251] -Wanalyzer-null-dereference false positive seen in haproxy's src/ssl_sample.c https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108325 [Bug 108325] -Wanalyzer-null-dereference false positive with *f = 42 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108400 [Bug 108400] false positive: null dereference (SoftEtherVPN)
[Bug modula2/108555] gm2_langhook_option_lang_mask causes all (unappropriate) C language options to be recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108555 Iain Sandoe changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2023-January ||/610676.html --- Comment #6 from Iain Sandoe --- tested, posted.
[Bug rtl-optimization/108519] [13 regression] gcc.target/powerpc/pr105586.c fails after r13-5154-g733a1b777f16cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108519 --- Comment #3 from Alexander Monakov --- Ah, a worthy sequel to "Note that I wasn't able to figure out a usable email address for the submitter" from PR 107353. Nevermind then.
[Bug rtl-optimization/108463] [13 Regression] ICE: in cselib_subst_to_values, at cselib.cc:2148 with -O2 -fsched2-use-superblocks -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108463
--- Comment #6 from Jakub Jelinek ---
The first two differences are between insns 1204 vs. 1116 and 1204 vs. 1095:
(insn 1095 1094 1097 2 (set (mem/c:V4SI (plus:DI (reg/f:DI 7 sp)
(const_int -104 [0xff98])) [1 S16 A128])
(reg:V4SI 22 xmm2 [227])) "pr106746.c":27:5 1809 {movv4si_internal}
(expr_list:REG_DEAD (reg:V4SI 22 xmm2 [227])
(nil)))
(insn 1116 1115 1118 2 (set (mem/c:V4SI (plus:DI (reg/f:DI 7 sp)
(const_int -88 [0xffa8])) [1 S16 A128])
(reg:V4SI 22 xmm2 [247])) "pr106746.c":27:5 1809 {movv4si_internal}
(expr_list:REG_DEAD (reg:V4SI 22 xmm2 [247])
(nil)))
(insn 1204 1118 1189 2 (set (reg:SI 0 ax [250])
(mem:SI (plus:DI (reg/f:DI 7 sp)
(const_int 120 [0x78])) [1 S4 A128])) "pr106746.c":27:5 83
{*movsi_internal}
(expr_list:REG_EQUIV (mem:SI (plus:DI (reg/f:DI 19 frame)
(const_int -208 [0xff30])) [1 S4 A128])
(nil)))
4 bytes at sp + 120 can't alias with 16 bytes at sp - 104 or 16 bytes at sp -
88
when sp isn't modified in between and all 3 are in the same bb.
So 1 returned from true_dependence looks incorrect (the -g case).
[Bug rtl-optimization/108463] [13 Regression] ICE: in cselib_subst_to_values, at cselib.cc:2148 with -O2 -fsched2-use-superblocks -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108463
--- Comment #5 from Jakub Jelinek ---
I've now tried:
--- sched-deps.cc.jj7 2023-01-19 09:58:50.971227752 +0100
+++ sched-deps.cc 2023-01-26 20:58:30.036035079 +0100
@@ -2498,7 +2498,10 @@ sched_analyze_1 (class deps_desc *deps,
pending_mem = deps->pending_read_mems;
while (pending)
{
- if (anti_dependence (pending_mem->element (), t)
+bool b = anti_dependence (pending_mem->element (), t);
+if (sched_deps_info->use_cselib && !DEBUG_INSN_P (insn) && !DEBUG_INSN_P
(pending->insn ()))
+fprintf (stderr, "anti_dependence %d\n", b);
+ if (b
&& ! sched_insns_conditions_mutex_p (insn, pending->insn ()))
note_mem_dep (t, pending_mem->element (), pending->insn (),
DEP_ANTI);
@@ -2511,7 +2514,10 @@ sched_analyze_1 (class deps_desc *deps,
pending_mem = deps->pending_write_mems;
while (pending)
{
- if (output_dependence (pending_mem->element (), t)
+bool b = output_dependence (pending_mem->element (), t);
+if (sched_deps_info->use_cselib && !DEBUG_INSN_P (insn) && !DEBUG_INSN_P
(pending->insn ()))
+fprintf (stderr, "output_dependence %d\n", b);
+ if (b
&& ! sched_insns_conditions_mutex_p (insn, pending->insn ()))
note_mem_dep (t, pending_mem->element (),
pending->insn (),
@@ -2605,7 +2611,14 @@ sched_analyze_2 (class deps_desc *deps,
case MEM:
{
- if (!DEBUG_INSN_P (insn))
+ if (DEBUG_INSN_P (insn) && sched_deps_info->use_cselib)
+ {
+ machine_mode address_mode = get_address_mode (x);
+
+ cselib_lookup_from_insn (XEXP (x, 0), address_mode, 1,
+GET_MODE (x), insn);
+ }
+ else if (!DEBUG_INSN_P (insn))
{
/* Reading memory. */
rtx_insn_list *u;
@@ -2630,7 +2643,10 @@ sched_analyze_2 (class deps_desc *deps,
pending_mem = deps->pending_read_mems;
while (pending)
{
- if (read_dependence (pending_mem->element (), t)
+bool b = read_dependence (pending_mem->element (), t);
+if (sched_deps_info->use_cselib && !DEBUG_INSN_P (insn) && !DEBUG_INSN_P
(pending->insn ()))
+fprintf (stderr, "read_dependence %d\n", b);
+ if (b
&& ! sched_insns_conditions_mutex_p (insn,
pending->insn ()))
note_mem_dep (t, pending_mem->element (),
@@ -2645,7 +2661,10 @@ sched_analyze_2 (class deps_desc *deps,
pending_mem = deps->pending_write_mems;
while (pending)
{
- if (true_dependence (pending_mem->element (), VOIDmode, t)
+bool b = true_dependence (pending_mem->element (), VOIDmode, t);
+if (sched_deps_info->use_cselib && !DEBUG_INSN_P (insn) && !DEBUG_INSN_P
(pending->insn ()))
+fprintf (stderr, "true_dependence %d\n", b);
+ if (b
&& ! sched_insns_conditions_mutex_p (insn,
pending->insn ()))
note_mem_dep (t, pending_mem->element (),
@@ -3817,7 +3836,10 @@ sched_analyze (class deps_desc *deps, rt
rtx_insn *insn;
if (sched_deps_info->use_cselib)
+{
cselib_init (CSELIB_RECORD_MEMORY);
+fprintf (stderr, "cselib_init\n");
+}
deps_start_bb (deps, head);
and I see with it a few differences in the output (-g0 to -g):
@@ -603,8 +603,8 @@ read_dependence 0
read_dependence 0
read_dependence 0
read_dependence 0
-true_dependence 0
-true_dependence 0
+true_dependence 1
+true_dependence 1
read_dependence 0
read_dependence 0
read_dependence 0
@@ -616,8 +616,8 @@ read_dependence 0
read_dependence 0
read_dependence 0
read_dependence 0
-true_dependence 0
-true_dependence 0
+true_dependence 1
+true_dependence 1
read_dependence 0
read_dependence 0
read_dependence 0
@@ -630,8 +630,8 @@ read_dependence 0
read_dependence 0
read_dependence 0
read_dependence 0
-true_dependence 0
-true_dependence 0
+true_dependence 1
+true_dependence 1
read_dependence 0
read_dependence 0
read_dependence 0
@@ -645,8 +645,8 @@ read_dependence 0
read_dependence 0
read_dependence 0
read_dependence 0
-true_dependence 0
-true_dependence 0
+true_dependence 1
+true_dependence 1
read_dependence 0
read_dependence 0
read_dependence 0
@@ -735,7 +735,7 @@ read_dependence 0
read_dependence 0
read_dependence 0
read_dependence 0
-true_dependence 0
+true_dependence 1
true_dependence 1
read_dependence 0
read_dependence 0
@@ -757,7 +757,7 @@ read_dependence 0
read_dependence 0
read_dependence 0
true_dependence 1
-true_dependence 0
+true_dependence 1
read_dependence 0
read_dependence 0
read_dependence 0
@@ -801,8 +801,8 @@ read_dependence 0
read_dependence 0
read_dependence 0
read_dependence 0
-true_dependence
[Bug target/108552] Linux i386 kernel 5.14 memory corruption for pre_compound_page() when gcov is enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552 --- Comment #12 from Linus Torvalds --- So it might be worth pointing explicitly to Vlastimil's email at https://lore.kernel.org/all/2b857e20-5e3a-13ec-a0b0-1f69d2d04...@suse.cz/ which has annotated objdump output and seems to point to the actual bug (or at least part of it), which seems to show how the page counting (in register %ebx) is corrupted by the coverage counts (Vlastimil calls the coverage counts "crap" - it's real data, but from an algorithmic standpoint it obviously has no bearing on the output). That would mesh with "on 32-bit x86, the 64-bit coverage counts require a lot more effort, and we have few registers, and something gets confused and uses register %rax for two things". The bug apparently only happens with -O2, and I think has only been reported with gcc-11, which is what the intel test robots happened to use
[Bug rtl-optimization/108519] [13 regression] gcc.target/powerpc/pr105586.c fails after r13-5154-g733a1b777f16cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108519 --- Comment #2 from seurer at gcc dot gnu.org --- I tried to test that patch but it didn't apply cleanly.
[Bug fortran/108544] ICE in check_host_association, at fortran/resolve.cc:6135
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108544 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |13.0 Resolution|--- |FIXED --- Comment #5 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-13. Closing. Thanks for the report!
[Bug target/108552] Linux i386 kernel 5.14 memory corruption for pre_compound_page() when gcov is enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|1 |0
Status|WAITING |UNCONFIRMED
--- Comment #11 from Andrew Pinski ---
The generated IR from the trunk:
[local count: 118111600]:
PROF_edge_counter_113 = __gcov0.set_compound_page_dtor[1];
PROF_edge_counter_114 = PROF_edge_counter_113 + 1;
__gcov0.set_compound_page_dtor[1] = PROF_edge_counter_114;
MEM[(struct page *)page_12(D) + 40B].D.14083.D.14061.compound_dtor = 1;
PROF_edge_counter_47 = __gcov0.prep_compound_page[8];
PROF_edge_counter_48 = PROF_edge_counter_47 + 1;
__gcov0.prep_compound_page[8] = PROF_edge_counter_48;
PROF_edge_counter_96 = __gcov0.set_compound_order[0];
PROF_edge_counter_97 = PROF_edge_counter_96 + 1;
__gcov0.set_compound_order[0] = PROF_edge_counter_97;
_98 = (unsigned char) order_8(D);
MEM[(struct page *)page_12(D) + 40B].D.14083.D.14061.compound_order = _98;
if (order_8(D) > 31)
goto ; [0.00%]
else
goto ; [100.00%]
[local count: 105119324]:
_176 = (long unsigned int) page_12(D);
_95 = _176 + 1;
pretmp_94 = __gcov0.prep_compound_page[7];
_179 = pretmp_94 + 1;
ivtmp.1725_211 = (unsigned long long) _179;
_155 = page_12(D) + 40;
ivtmp.1730_157 = (unsigned int) _155;
_135 = (unsigned int) nr_pages_11;
_134 = _135 + 4294967294;
_132 = (unsigned long long) _134;
_89 = (unsigned long long) pretmp_94;
_76 = _89 + 2;
_19 = _76 + _132;
[local count: 955630225]:
# ivtmp.1725_77 = PHI
# ivtmp.1730_178 = PHI
p_16 = (struct page *) ivtmp.1730_178;
MEM [(union *)p_16 + 12B] = 1024B;
MEM[(volatile long unsigned int *)p_16 + 4B] ={v} _95;
PROF_edge_counter_46 = (long long int) ivtmp.1725_77;
__gcov0.prep_compound_page[7] = PROF_edge_counter_46;
ivtmp.1725_69 = ivtmp.1725_77 + 1;
ivtmp.1730_168 = ivtmp.1730_178 + 40;
if (_19 != ivtmp.1725_69)
goto ; [89.00%]
else
goto ; [11.00%]
[Bug middle-end/108543] [10/11 Regression] ICE in build_call_expr_loc_array, at tree.cc:10686
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108543 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Summary|[10/11/12/13 Regression]|[10/11 Regression] ICE in |ICE in |build_call_expr_loc_array, |build_call_expr_loc_array, |at tree.cc:10686 |at tree.cc:10686| Status|ASSIGNED|RESOLVED --- Comment #7 from Marek Polacek --- Fixed.
[Bug modula2/108551] gcc/m2/gm2-libs-pim/Termbase.mod:128:1: error: control reaches end of non-void function [-Werror=return-type]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108551 Gaius Mulley changed: What|Removed |Added Attachment #54354|0 |1 is obsolete|| --- Comment #7 from Gaius Mulley --- Created attachment 54357 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54357&action=edit Proposed fix This patch follows on from the previous patch to implement the handling of <* noreturn *> attribute in cc1gm2. I've added Termbase.mod to the testsuite gm2 warnings pass. It builds and causes no further regressions (without bootstrap). Once I've seen it build full bootstrap I'll git push the changes.
[Bug middle-end/108543] [10/11/12/13 Regression] ICE in build_call_expr_loc_array, at tree.cc:10686
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108543 --- Comment #6 from CVS Commits --- The releases/gcc-12 branch has been updated by Marek Polacek : https://gcc.gnu.org/g:786923f74d6adfaf572f3d7c0307c51c522567f9 commit r12-9071-g786923f74d6adfaf572f3d7c0307c51c522567f9 Author: Marek Polacek Date: Wed Jan 25 17:19:54 2023 -0500 opts: SANITIZE_ADDRESS wrongly cleared [PR108543] Here we crash on a null fndecl ultimately because we haven't defined the built-ins described in sanitizer.def. So builtin_decl_explicit (BUILT_IN_ASAN_POINTER_SUBTRACT); returns NULL_TREE, causing an ICE later. DEF_SANITIZER_BUILTIN only actually defines the built-ins when flag_sanitize has SANITIZE_ADDRESS, or some of the other SANITIZE_*, but it doesn't check SANITIZE_KERNEL_ADDRESS or SANITIZE_USER_ADDRESS. Unfortunately, with -fsanitize=address -fno-sanitize=kernel-address or -fsanitize=kernel-address -fno-sanitize=address SANITIZE_ADDRESS ends up being unset from flag_sanitize even though _USER/_KERNEL are set. That's because -fsanitize=address means SANITIZE_ADDRESS | SANITIZE_USER_ADDRESS and -fsanitize=kernel-address is SANITIZE_ADDRESS | SANITIZE_KERNEL_ADDRESS but parse_sanitizer_options does flags &= ~sanitizer_opts[i].flag; so the subsequent -fno- unsets SANITIZE_ADDRESS. Then no sanitizer built-ins are actually defined. I'm not sure why SANITIZE_ADDRESS isn't just SANITIZE_USER_ADDRESS | SANITIZE_KERNEL_ADDRESS, I don't think we need 3 bits. PR middle-end/108543 gcc/ChangeLog: * opts.cc (parse_sanitizer_options): Don't always clear SANITIZE_ADDRESS if it was previously set. gcc/testsuite/ChangeLog: * c-c++-common/asan/pointer-subtract-5.c: New test. * c-c++-common/asan/pointer-subtract-6.c: New test. * c-c++-common/asan/pointer-subtract-7.c: New test. * c-c++-common/asan/pointer-subtract-8.c: New test. (cherry picked from commit a82ce9c8d155ecda2d1c647d5c588f29e21ef4a3)
[Bug fortran/108544] ICE in check_host_association, at fortran/resolve.cc:6135
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108544 --- Comment #4 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:c8e07c7951421e718bcafbe5924e75c9aa133af9 commit r13-5400-gc8e07c7951421e718bcafbe5924e75c9aa133af9 Author: Harald Anlauf Date: Wed Jan 25 22:47:26 2023 +0100 Fortran: fix ICE in check_host_association [PR108544] gcc/fortran/ChangeLog: PR fortran/108544 * resolve.cc (check_host_association): Extend host association check so that it is not restricted to functions. Also prevent NULL pointer dereference. gcc/testsuite/ChangeLog: PR fortran/108544 * gfortran.dg/pr108544.f90: New test. * gfortran.dg/pr96102b.f90: New test.
[Bug rtl-optimization/108463] [13 Regression] ICE: in cselib_subst_to_values, at cselib.cc:2148 with -O2 -fsched2-use-superblocks -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108463
--- Comment #4 from Jakub Jelinek ---
So, seems during the code added by above patch without the 0 && new_cselib_val
creates a value on DEBUG_INSNs for:
1) (mem:SI (plus:DI (reg/f:DI 7 sp)
(const_int NN)) [1 S4 A64])
for NN 76 to 132 inclusive in steps of 4, except for 104 and 120
2) (plus:DI (reg/f:DI 7 sp) (const_int NN))
for NN 72 to 132 inclusive in steps of 4, and for 200 and 264
3) (symbol_ref:DI ("a") [flags 0x2] )
4) complex expressions like:
(plus:DI (plus:DI (ashift:DI (zero_extend:DI (and:SI (mem:SI (plus:DI (reg/f:DI
7 sp)
(const_int 132 [0x84])) [1 S4 A32])
(const_int 15 [0xf])))
(const_int 2 [0x2]))
(reg/f:DI 7 sp))
(const_int 8 [0x8]))
Now, I strongly doubt anything looks up for normal insns the large expressions
in 4) category, because they aren't valid in normal insns, so it will be 1), 2)
or 3) that affect the scheduling.
[Bug fortran/103506] [10/11/12/13 Regression] ICE in gfc_free_namespace, at fortran/symbol.c:4039 since r10-2798-ge68a35ae4a65d2b3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103506 --- Comment #6 from Steve Kargl --- On Thu, Jan 26, 2023 at 02:56:02AM +, jvdelisle at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103506 > > --- Comment #5 from Jerry DeLisle --- > I found that the attached patch does not work. At the point of assertion many > of the other functions to free memory have null pointers which leads to > segfaults all along the way. > > The following approach appears to work, however, obviously there is a lot of > memory left not freed, so we would rely on the OS to clean it up. Maybe this > is > ok, not sure. > I think that it is ok. A lot of the gfortran FE code assumes that it is dealing with a conforming Fortran program. Many failing test cases are constructed from invalid Fortran code (see any of a number of Gerhard's PR), which takes torturous paths through the Fortran FE. The only other option is to check the pointers, but this is going to get ugly with some of the structs we have. Something like if (a->b->c->d) free(...) becomes if (a && a->b && a->b->c && a->b->c->d) free(...)
[Bug middle-end/108543] [10/11/12/13 Regression] ICE in build_call_expr_loc_array, at tree.cc:10686
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108543 --- Comment #5 from CVS Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:a82ce9c8d155ecda2d1c647d5c588f29e21ef4a3 commit r13-5399-ga82ce9c8d155ecda2d1c647d5c588f29e21ef4a3 Author: Marek Polacek Date: Wed Jan 25 17:19:54 2023 -0500 opts: SANITIZE_ADDRESS wrongly cleared [PR108543] Here we crash on a null fndecl ultimately because we haven't defined the built-ins described in sanitizer.def. So builtin_decl_explicit (BUILT_IN_ASAN_POINTER_SUBTRACT); returns NULL_TREE, causing an ICE later. DEF_SANITIZER_BUILTIN only actually defines the built-ins when flag_sanitize has SANITIZE_ADDRESS, or some of the other SANITIZE_*, but it doesn't check SANITIZE_KERNEL_ADDRESS or SANITIZE_USER_ADDRESS. Unfortunately, with -fsanitize=address -fno-sanitize=kernel-address or -fsanitize=kernel-address -fno-sanitize=address SANITIZE_ADDRESS ends up being unset from flag_sanitize even though _USER/_KERNEL are set. That's because -fsanitize=address means SANITIZE_ADDRESS | SANITIZE_USER_ADDRESS and -fsanitize=kernel-address is SANITIZE_ADDRESS | SANITIZE_KERNEL_ADDRESS but parse_sanitizer_options does flags &= ~sanitizer_opts[i].flag; so the subsequent -fno- unsets SANITIZE_ADDRESS. Then no sanitizer built-ins are actually defined. I'm not sure why SANITIZE_ADDRESS isn't just SANITIZE_USER_ADDRESS | SANITIZE_KERNEL_ADDRESS, I don't think we need 3 bits. PR middle-end/108543 gcc/ChangeLog: * opts.cc (parse_sanitizer_options): Don't always clear SANITIZE_ADDRESS if it was previously set. gcc/testsuite/ChangeLog: * c-c++-common/asan/pointer-subtract-5.c: New test. * c-c++-common/asan/pointer-subtract-6.c: New test. * c-c++-common/asan/pointer-subtract-7.c: New test. * c-c++-common/asan/pointer-subtract-8.c: New test.
[Bug libstdc++/108561] std::endl causes a flush on a bad stream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108561 --- Comment #4 from Jonathan Wakely --- That changed with https://cplusplus.github.io/LWG/issue581 which I implemented for GCC 12 in r12-1817-gf8c5b542f6cb6a so I guess you're looking at gcc-11 or older.
[Bug libstdc++/108561] std::endl causes a flush on a bad stream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108561
--- Comment #3 from lavr at ncbi dot nlm.nih.gov ---
Also, the standard seems to mention that flush() is an "unformatted output
function", meaning it is supposed to build and check a sentry object (which in
case of a bad stream, would fail, so it's not going to proceed with pubsync()).
In GCC implementation, the sentry is not constructed, and the comment in the
source code seems to contradict with the standard:
// basic_ostream::flush() is *not* an unformatted output function.
ios_base::iostate __err = ios_base::goodbit;
__try
{
if (this->rdbuf() && this->rdbuf()->pubsync() == -1)
__err |= ios_base::badbit;
}
If the flush() implementation followed the standard, then the implementation of
endl could be left alone (unconditional chained flush).
[Bug libstdc++/108561] std::endl causes a flush on a bad stream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108561 --- Comment #2 from lavr at ncbi dot nlm.nih.gov --- Indeed, it does not. But the reason the endl manipulator is there, is to flush _after_ '\n'. If the stream has gone bad in between, it is the gray area, but for the output device (the stream buffer), it's an intentional corruption.
[Bug rtl-optimization/108463] [13 Regression] ICE: in cselib_subst_to_values, at cselib.cc:2148 with -O2 -fsched2-use-superblocks -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108463 --- Comment #3 from Jakub Jelinek --- Oops, ignore the 0 && part in the above patch, I've added that while trying to get the ICE on this PR back.
[Bug rtl-optimization/108463] [13 Regression] ICE: in cselib_subst_to_values, at cselib.cc:2148 with -O2 -fsched2-use-superblocks -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108463
--- Comment #2 from Jakub Jelinek ---
>From what I can see, the r13-5252 change removed for DEBUG_INSNs two things,
one is the
cselib_lookup_from_insn call with 1 as create and the other is the
shallow_copy_rtx + cselib_subst_to_values_from_insn.
As nothing really used t for the debug insns and
cselib_subst_to_values_from_insn shouldn't create new VALUEs and the like
(well, there is:
/* This used to happen for autoincrements, but we deal with them
properly now. Remove the if stmt for the next release. */
if (! e)
{
/* Assign a value that doesn't match any other. */
e = new_cselib_val (next_uid, GET_MODE (x), x);
}
which nobody removed so far), I think the shallow_copy_rtx +
cselib_subst_to_values_from_insn are just waste of resources (allocates various
rtxes nobody looks at).
But the cselib_lookup_from_insn actually creates new VALUEs (and mark them as
coming from DEBUG_INSNs), so I think we need to do that.
E.g. in the testcase from this PR (can be even simplified to:
typedef int __attribute__((__vector_size__ (32))) V;
int a;
void
foo (V v)
{
a--;
v = (V) v;
}
) after expansion:
(debug_insn 5 2 6 2 (debug_marker) "pr108463.c":7:3 -1
(nil))
(insn 6 5 7 2 (parallel [
(set (mem/c:SI (symbol_ref:DI ("a") [flags 0x2] ) [1 a+0 S4 A32])
(plus:SI (mem/c:SI (symbol_ref:DI ("a") [flags 0x2] ) [1 a+0 S4 A32])
(const_int -1 [0x])))
(clobber (reg:CC 17 flags))
]) "pr108463.c":7:4 240 {*addsi_1}
(nil))
(debug_insn 7 6 8 2 (debug_marker) "pr108463.c":8:3 -1
(nil))
(debug_insn 8 7 0 2 (var_location:BLK v (mem/c:BLK (reg/f:DI 16 argp) [1 v+0
S32 A256])) "pr108463.c":8:5 -1
(nil))
and before scheduling:
(debug_insn 5 2 6 2 (debug_marker) "pr108463.c":7:3 -1
(nil))
(insn 6 5 7 2 (parallel [
(set (mem/c:SI (symbol_ref:DI ("a") [flags 0x2] ) [1 a+0 S4 A32])
(plus:SI (mem/c:SI (symbol_ref:DI ("a") [flags 0x2] ) [1 a+0 S4 A32])
(const_int -1 [0x])))
(clobber (reg:CC 17 flags))
]) "pr108463.c":7:4 240 {*addsi_1}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
(debug_insn 7 6 8 2 (debug_marker) "pr108463.c":8:3 -1
(nil))
(debug_insn 8 7 13 2 (var_location:BLK v (mem/c:BLK (plus:DI (reg/f:DI 7 sp)
(const_int 8 [0x8])) [1 v+0 S32 A256])) "pr108463.c":8:5 -1
(nil))
(jump_insn 14 13 15 2 (simple_return) "pr108463.c":9:1 1006
{simple_return_internal}
(nil)
when ignoring notes. Without the cselib_lookup_from_insn call, we ICE in
cselib_subst_to_values because it is the only spot in the IL that mentions the
sp
register, so we haven't created a VALUE for it otherwise.
Unfortunately, while:
--- gcc/sched-deps.cc.jj2023-01-19 09:58:50.971227752 +0100
+++ gcc/sched-deps.cc 2023-01-26 18:11:00.185963813 +0100
@@ -2605,7 +2605,14 @@ sched_analyze_2 (class deps_desc *deps,
case MEM:
{
- if (!DEBUG_INSN_P (insn))
+ if (0 && DEBUG_INSN_P (insn) && sched_deps_info->use_cselib)
+ {
+ machine_mode address_mode = get_address_mode (x);
+
+ cselib_lookup_from_insn (XEXP (x, 0), address_mode, 1,
+GET_MODE (x), insn);
+ }
+ else if (!DEBUG_INSN_P (insn))
{
/* Reading memory. */
rtx_insn_list *u;
fixes this PR, it breaks again PR106746.
So I think we really need to understand what is going on with PR106746.
[Bug analyzer/108400] false positive: null dereference (SoftEtherVPN)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108400 --- Comment #1 from David Malcolm --- Created attachment 54356 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54356&action=edit Reduced reproducer False positive seen here with no optimization: https://godbolt.org/z/cfqz1fYKx with -O2: https://godbolt.org/z/b8GeeT9cd where the wording is slightly different at different optimization levels (but it's still a false positive)
[Bug libstdc++/108561] std::endl causes a flush on a bad stream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108561 --- Comment #1 from Jonathan Wakely --- The standard doesn't say anything about not flushing if the put (or any previous output function) failed. > Calls os.put(os.widen(’\n’)), then os.flush().
[Bug c/101832] __builtin_object_size(P->M, 1) where M ends with a flex-array behaves like sizeof()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101832 --- Comment #9 from qinzhao at gcc dot gnu.org --- I will add a routine in tree-object-size.cc to check whether a reference to a structure or union field includes a flexible array member in the inner structure, such structure or union should be considered as having flexible size, too. then should resolve this bug.
[Bug libstdc++/108561] New: std::endl causes a flush on a bad stream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108561
Bug ID: 108561
Summary: std::endl causes a flush on a bad stream
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: lavr at ncbi dot nlm.nih.gov
Target Milestone: ---
As implemented:
template
inline basic_ostream<_CharT, _Traits>&
endl(basic_ostream<_CharT, _Traits>& __os)
{ return flush(__os.put(__os.widen('\n'))); }
this code can cause flush() to be called for a stream that has gone bad during
the execution of put(). Note that put() constructs a sentry, which if it threw
an exception, would case the stream to get a badbit (the most severe case; but
other unsuccessful sentry construction errors fit the same pattern). On the
other hand, flush() does not check for any such things -- there's no sentry
construction -- instead, it just blindly calls the underlying stream buffer's
pubsync(). The bottom line result is that the failed output is missing yet the
flush is still attempted, but the expected behavior is that the output should
be _followed_ by the flush. Otherwise, the order of the expected I/O is wrong
(the flush appears out of order when put() failed).
A fix would be to do something like this:
__os = __os.put(__os.widen('\n');
return __os ? flush(__os) : __os;
[Bug modula2/108551] gcc/m2/gm2-libs-pim/Termbase.mod:128:1: error: control reaches end of non-void function [-Werror=return-type]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108551 Gaius Mulley changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #6 from Gaius Mulley --- In the initial testcase I think cc1gm2 is ignoring the <* noreturn *> attribute to M2RTS.mod:Halt.
[Bug modula2/108555] gm2_langhook_option_lang_mask causes all (unappropriate) C language options to be recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108555 --- Comment #5 from Iain Sandoe --- Created attachment 54355 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54355&action=edit Partch under test - partial reversion of r13-5373-g80cf2c5e8f496b This reverts the part of r13-5373-g80cf2c5e8f496b that claims *all* the C and Driver options for Modula-2 .. instead we now add them to the lang.opt file.
[Bug c++/108559] [13 Regression] A new crash with using a simple class, inheritance and a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108559 --- Comment #2 from Andrew Pinski --- This might be related to C++ core issue cwg2403: https://wg21.link/cwg2403
[Bug modula2/108553] GM2 ICEs on mistyped command line options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108553 --- Comment #5 from CVS Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:6dd4578f4779b27b2115d78226ff7df46c939061 commit r13-5398-g6dd4578f4779b27b2115d78226ff7df46c939061 Author: Iain Sandoe Date: Thu Jan 26 09:46:32 2023 + Modula-2: Remove debug code [PR108553]. Remove debugging code accidentally left in place in r13-5373-g80cf2c5e8f496b. Signed-off-by: Iain Sandoe PR modula2/108553 gcc/m2/ChangeLog: * gm2-lang.cc (gm2_langhook_init_options): Remove debug code.
[Bug tree-optimization/108540] [13 Regression] Frange miscompilation of ruby since r13-3261
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108540
--- Comment #8 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:09176201ec6a21c25b1edb07f19f83be22a123f9
commit r13-5397-g09176201ec6a21c25b1edb07f19f83be22a123f9
Author: Jakub Jelinek
Date: Thu Jan 26 17:21:22 2023 +0100
frange: Fix up foperator_{,not_}equal::fold_range for signed zeros
[PR108540]
The following testcases are miscompiled, because threader sees some
SSA_NAME would have -0.0 value and when computing range of SSA_NAME == 0.0
foperator_equal::fold_range sees one operand has [-0.0, -0.0] singleton
range, the other [0.0, 0.0], they aren't equal (frange operator== uses
real_identical etc. rather than real comparisons) and so it thinks they
compare unequal. With signed zeros -0.0 == 0.0 is true though, so we
need to special case the both ranges singleton code.
Similarly, if we see op1 range being say [-42.0, -0.0] and op2 range
[0.0, 42.0], we'd check that the intersection of the two ranges is empty
(that is correct) and fold the result of == between such operands to
[0, 0] which is wrong, because -0.0 == 0.0, it needs to be [0, 1].
Similarly for foperator_not_equal::fold_range.
2023-01-26 Jakub Jelinek
PR tree-optimization/108540
* range-op-float.cc (foperator_equal::fold_range): If both op1 and
op2
are singletons, use range_true even if op1 != op2
when one range is [-0.0, -0.0] and another [0.0, 0.0]. Similarly,
even if intersection of the ranges is empty and one has
zero low bound and another zero high bound, use
range_true_and_false
rather than range_false.
(foperator_not_equal::fold_range): If both op1 and op2
are singletons, use range_false even if op1 != op2
when one range is [-0.0, -0.0] and another [0.0, 0.0]. Similarly,
even if intersection of the ranges is empty and one has
zero low bound and another zero high bound, use
range_true_and_false
rather than range_true.
* gcc.c-torture/execute/ieee/pr108540-1.c: New test.
* gcc.c-torture/execute/ieee/pr108540-2.c: New test.
[Bug modula2/108551] gcc/m2/gm2-libs-pim/Termbase.mod:128:1: error: control reaches end of non-void function [-Werror=return-type]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108551 Gaius Mulley changed: What|Removed |Added CC||gaius at gcc dot gnu.org --- Comment #5 from Gaius Mulley --- Created attachment 54354 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54354&action=edit Potential bug fix for missing return 0 in main Thanks for the bug report. The -Wreturn-type highlighted a bug in the scaffold main (missing a RETURN 0 after the exception handling in main) which I think is fixed in the following patch. Also contained are two dejagnu test cases (pass/fail) based on the test case above:
[Bug other/108560] builtin_va_arg_pack_len is documented to return size_t, but actually returns int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108560 Jakub Jelinek changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Last reconfirmed||2023-01-26 Status|UNCONFIRMED |ASSIGNED --- Comment #2 from Jakub Jelinek --- Created attachment 54353 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54353&action=edit gcc13-pr108560.patch Untested fix.
[Bug c++/108560] builtin_va_arg_pack_len is documented to return size_t, but actually returns int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108560 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- This is a bug in the documentation, introduced with r0-103077-gab940b73bfabe2cec4 which was meant to be a documentation formatting only change.
[Bug target/108552] Linux i386 kernel 5.14 memory corruption for pre_compound_page() when gcov is enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552 --- Comment #10 from Tang, Feng --- Created attachment 54352 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54352&action=edit page_alloc.i.xz
[Bug target/108552] Linux i386 kernel 5.14 memory corruption for pre_compound_page() when gcov is enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552 --- Comment #9 from Tang, Feng --- For original report https://lore.kernel.org/lkml/202301170941.49728982-oliver.s...@intel.com/t/, it was reported by Sang Oliver from 0Day team, but I failed to add him too cc (probably due to he is not registered in this bugzilla system?), so I will try to gather some info (some from Oliver's report, some from my local system when it can't be found from Oliver's report) gcc version: gcc-11 (Debian 11.3.0-8) 11.3.0 gcc (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0 Platform: QEMU Preprocessing file: page_alloc.i (attached) gcc options: from page_alloc.s(got from 'make ARCH=i386 mm/page_alloc.s') # GNU C89 (Ubuntu 11.3.0-1ubuntu1~22.04) version 11.3.0 (x86_64-linux-gnu) # compiled by GNU C version 11.3.0, GMP version 6.2.1, MPFR version 4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP # GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 # options passed: -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -m32 -msoft-float -mregparm=3 -mpreferred-stack-boundary=2 -march=i686 -mstack-protector-guard-reg=fs -msta ck-protector-guard-symbol=__stack_chk_guard -mindirect-branch=thunk-extern -mindirect-branch-register -O2 -std=gnu90 -fno-strict-aliasing -fno-common -fshort-wchar -fcf-prot ection=none -freg-struct-return -fno-pic -ffreestanding -fno-asynchronous-unwind-tables -fno-jump-tables -fno-delete-null-pointer-checks -fno-allow-store-data-races -fno-reo rder-blocks -fno-ipa-cp-clone -fno-partial-inlining -fstack-protector-strong -fno-omit-frame-pointer -fno-optimize-sibling-calls -fno-stack-clash-protection -fno-inline-func tions-called-once -fno-strict-overflow -fstack-check=no -fconserve-stack -fprofile-arcs -ftest-coverage -fno-tree-loop-im -fsanitize=bounds -fsanitize=shift -fsanitize=unrea chable
[Bug c++/108560] New: builtin_va_arg_pack_len is documented to return size_t, but actually returns int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108560
Bug ID: 108560
Summary: builtin_va_arg_pack_len is documented to return
size_t, but actually returns int
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.seifert at de dot ibm.com
Target Milestone: ---
#include
bool test(const char *fmt, size_t numTokens, ...)
{
return __builtin_va_arg_pack_len() != numTokens;
}
Compiled with -Wsign-compare results in:
: In function 'bool test(const char*, size_t, ...)':
:5:40: warning: comparison of integer expressions of different
signedness: 'int' and 'size_t' {aka 'long unsigned int'} [-Wsign-compare]
5 | return __builtin_va_arg_pack_len() != numTokens;
|^~~~
:5:37: error: invalid use of '__builtin_va_arg_pack_len ()'
5 | return __builtin_va_arg_pack_len() != numTokens;
|~^~
Compiler returned: 1
Documentation:
https://gcc.gnu.org/onlinedocs/gcc/Constructing-Calls.html
indicates a size_t return type
Built-in Function: size_t __builtin_va_arg_pack_len ()
[Bug c++/88853] ICE: verify_type failed (error: type variant differs by TYPE_PACKED) with -fpack-struct -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88853
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment #4 from David Binderman ---
I get something similar for this C code:
enum fmt_type parse_num_range(const enum fmt_type);
enum __attribute__((packed)) fmt_type {
FMT_NUMBER_OF_FORMATS
} parse_number(const enum fmt_type) {}
$ /usr/bin/gcc -c -g bug877.c
$ ~/gcc/results/bin/gcc -c -g bug877.c
bug877.c: In function ‘parse_number’:
bug877.c:4:27: error: type variant differs by TYPE_PACKED
4 | } parse_number(const enum fmt_type) {}
| ^~~~
This error seems like a regression in gcc-13.
The bug first appears sometime before 9b111debbfb79a0a.
[Bug c++/105300] [10/11/12 Regression] segfault from static_assert with user-defined string suffix argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105300 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Summary|[10/11/12/13 Regression]|[10/11/12 Regression] |segfault from static_assert |segfault from static_assert |with user-defined string|with user-defined string |suffix argument |suffix argument --- Comment #6 from Marek Polacek --- Fixed for GCC 13. I don't think I want to backport the patch.
[Bug c++/105300] [10/11/12/13 Regression] segfault from static_assert with user-defined string suffix argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105300 --- Comment #5 from CVS Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:9f353b0c1dc9385ba8b8a64b65d66d5452383c11 commit r13-5390-g9f353b0c1dc9385ba8b8a64b65d66d5452383c11 Author: Marek Polacek Date: Fri Nov 11 17:59:30 2022 -0500 c++: Reject UDLs in certain contexts [PR105300] In this PR, we are crashing because we've encountered a UDL where a string-literal is expected. This patch makes the parser reject string and character UDLs in all places where the grammar requires a string-literal and not a user-defined-string-literal. I've introduced two new wrappers; the existing cp_parser_string_literal was renamed to cp_parser_string_literal_common and should not be called directly. finish_userdef_string_literal is renamed from cp_parser_userdef_string_literal. PR c++/105300 gcc/c-family/ChangeLog: * c-pragma.cc (handle_pragma_message): Warn for CPP_STRING_USERDEF. gcc/cp/ChangeLog: * parser.cc: Remove unnecessary forward declarations. (cp_parser_string_literal): New wrapper. (cp_parser_string_literal_common): Renamed from cp_parser_string_literal. Add a bool parameter. Give an error when UDLs are not permitted. (cp_parser_userdef_string_literal): New wrapper. (finish_userdef_string_literal): Renamed from cp_parser_userdef_string_literal. (cp_parser_primary_expression): Call cp_parser_userdef_string_literal instead of cp_parser_string_literal. (cp_parser_linkage_specification): Move a variable declaration closer to its first use. (cp_parser_static_assert): Likewise. (cp_parser_operator): Call cp_parser_userdef_string_literal instead of cp_parser_string_literal. (cp_parser_asm_definition): Move a variable declaration closer to its first use. (cp_parser_asm_specification_opt): Move variable declarations closer to their first use. (cp_parser_asm_operand_list): Likewise. (cp_parser_asm_clobber_list): Likewise. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/udlit-error1.C: New test.
[Bug analyzer/108535] RFE: analyzer to allow ifdef inclusion/exclusion like cppcheck -D/-U
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108535 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-01-26 Status|UNCONFIRMED |WAITING --- Comment #1 from David Malcolm --- As I understand it, cppcheck's attempts to explore all combinations of possible preprocessor defines. GCC's -fanalyzer performs coverage-guided symbolic execution to try to explore the various execution paths in the user's code. It runs on GCC's intermediate representation as the code is being compiled. In particular -fanalyzer runs internally *after* preprocessing; it uses just the specific defines that the file was invoked with (via -D at the command-line, or via #defines in headers, etc). So I don't think GCC's -fanalyzer can support the "all combinations of preprocessor defines" approach; it would be a total rewrite. It sounds like what you really want is for GCC -fanalyzer to be faster on this particular translation unit. If so, I can try digging into it to see where the slowdown happens.
[Bug analyzer/108432] RFE: analyzer could detect out-of-bounds issues within loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108432 David Malcolm changed: What|Removed |Added Summary|Analyzer fails to detect|RFE: analyzer could detect |out-of-bounds issues within |out-of-bounds issues within |loops |loops --- Comment #4 from David Malcolm --- Retitling this to be an RFE, since handling these cases is an expansion of the scope of -fanalyzer's bounds-checker.
[Bug tree-optimization/107608] [13 Regression] Failure on fold-overflow-1.c and pr95115.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
--- Comment #44 from Xi Ruoyao ---
(In reply to rguent...@suse.de from comment #43)
> On Thu, 19 Jan 2023, xry111 at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
> >
> > --- Comment #42 from Xi Ruoyao ---
> > (In reply to Richard Biener from comment #41)
> > > We could fix the testcase with
> > >
> > > diff --git a/gcc/testsuite/gcc.dg/pr95115.c
> > > b/gcc/testsuite/gcc.dg/pr95115.c
> > > index 69c4f83250c..09273e445d2 100644
> > > --- a/gcc/testsuite/gcc.dg/pr95115.c
> > > +++ b/gcc/testsuite/gcc.dg/pr95115.c
> > > @@ -17,6 +17,7 @@ int
> > > main (void)
> > > {
> > >double r = x ();
> > > + volatile double rr = r;
> > >if (!__builtin_isnan (r))
> > > abort ();
> > >if (!fetestexcept (FE_INVALID))
> > >
> > > that preserves optimizing the isnan check but also preserves the
> > > computation
> > > and checks the non-propagation of a NaN.
> >
> > Hmm, so it means we cannot rely on Inf / Inf to raise an exception? Then we
> > need to fix Glibc...
>
> If the result is unused then no, GCC will happily elide exceptions from
> unused computations like Inexact from the statement
>
> 1./3.;
>
> but this has been done before. What's new is that GCC can now elide
> some uses (in this case the isnan check is the only use)
The should we just change PR95115 to "INVALID" and remove the test case, and
fix any regression on Glibc side?
[Bug analyzer/108524] -Wanalyzer-infinite-recursion false positives seen in qemu's JSON parser
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108524 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- Should be fixed by the above commit.
[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 Bug 88443 depends on bug 108507, which changed state. Bug 108507 Summary: [13 regression] new test case gcc.dg/analyzer/SARD-tc841-basic-00182-min.c in r13-5244-gc6a09bfa03 fails https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108507 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug analyzer/108507] [13 regression] new test case gcc.dg/analyzer/SARD-tc841-basic-00182-min.c in r13-5244-gc6a011119bfa03 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108507 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from David Malcolm --- Sorry about the noise. Should be fixed by the above commit; please reopen this bug if I messed up.
[Bug analyzer/108507] [13 regression] new test case gcc.dg/analyzer/SARD-tc841-basic-00182-min.c in r13-5244-gc6a011119bfa03 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108507 --- Comment #2 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:f1eab269288ffa80ba924ddb4c4b36f8f781d613 commit r13-5389-gf1eab269288ffa80ba924ddb4c4b36f8f781d613 Author: David Malcolm Date: Thu Jan 26 09:12:21 2023 -0500 analyzer: fix SARD-tc841-basic-00182-min.c test case [PR108507] gcc/testsuite/ChangeLog: PR analyzer/108507 * gcc.dg/analyzer/SARD-tc841-basic-00182-min.c: Add -Wno-stringop-overflow. Signed-off-by: David Malcolm
[Bug analyzer/108524] -Wanalyzer-infinite-recursion false positives seen in qemu's JSON parser
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108524 --- Comment #2 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:7bffea89f1f164efc10dd37d979a83c4c5fbfa7e commit r13-5388-g7bffea89f1f164efc10dd37d979a83c4c5fbfa7e Author: David Malcolm Date: Thu Jan 26 09:12:21 2023 -0500 analyzer: fix false positives from -Wanalyzer-infinite-recursion [PR108524] Reject -Wanalyzer-infinite-recursion diagnostics in which control flow has been affected by conjured_svalues between the initial call to a function and the subsequent entry to that function. This prevents false positives such as in qemu's recursive JSON parser where function calls are changing state in the rest of the program (e.g. consuming tokens), despite the modelled state being effectively identical at both nested entrypoints. gcc/analyzer/ChangeLog: PR analyzer/108524 * analyzer.h (class feasible_node): New forward decl. * diagnostic-manager.cc (epath_finder::get_best_epath): Add "pd" param. (epath_finder::explore_feasible_paths): Likewise. (epath_finder::process_worklist_item): Likewise. Use it to call pending_diagnostic::check_valid_fpath_p on the final fpath to give pending_diagnostic a way to add additional restrictions on feasibility. (saved_diagnostic::calc_best_epath): Pass pending_diagnostic to epath_finder::get_best_epath. * infinite-recursion.cc: Include "analyzer/feasible-graph.h". (infinite_recursion_diagnostic::check_valid_fpath_p): New. (infinite_recursion_diagnostic::fedge_uses_conjured_svalue_p): New. (infinite_recursion_diagnostic::expr_uses_conjured_svalue_p): New. * pending-diagnostic.h (pending_diagnostic::check_valid_fpath_p): New vfunc. gcc/testsuite/ChangeLog: PR analyzer/108524 * gcc.dg/analyzer/infinite-recursion-pr108524-1.c: New test. * gcc.dg/analyzer/infinite-recursion-pr108524-2.c: New test. * gcc.dg/analyzer/infinite-recursion-pr108524-qobject-json-parser.c: New test. Signed-off-by: David Malcolm
[Bug fortran/108558] OpenMP/Fortran 'has_device_addr' clause getting lost?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108558 --- Comment #2 from Thomas Schwinge --- (In reply to Tobias Burnus from comment #1) > I bet that this is a problem of 'gfc_split_omp_clauses': [...] Heh, so indeed as I suspected: (In reply to myself from comment #0) > (Decomposed combined construct. Is that perhaps where the problem lies?) :-) With your patch (thanks!) applied, I do get what I suspect are the expected changes: 'pr.f90.005t.original': - #pragma omp target + #pragma omp target has_device_addr(a) has_device_addr(b) 'pr.f90.006t.gimple': - #pragma omp target num_teams(0) thread_limit(0) firstprivate(m) map(tofrom:*b [len: D.4283][implicit]) map(alloc:b [pointer assign, bias: 0]) map(tofrom:*a [len: D.4280][implicit]) map(alloc:a [pointer assign, bias: 0]) + #pragma omp target num_teams(0) thread_limit(0) has_device_addr(a) has_device_addr(b) firstprivate(D.4283) firstprivate(D.4280) firstprivate(m) ..., and my original test case behaves as expected; OpenMP/Fortran 'has_device_addr' works.
[Bug libstdc++/108554] [12 Regression] Warning "null pointer dereferece" raised when extracting a unique_ptr from a map and any "-O" flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108554 Jonathan Wakely changed: What|Removed |Added Known to work||11.3.0 Known to fail||12.2.0 Target Milestone|--- |12.3 Summary|Warning "null pointer |[12 Regression] Warning |dereferece" raised when |"null pointer dereferece" |extracting a unique_ptr |raised when extracting a |from a map and any "-O" |unique_ptr from a map and |flag|any "-O" flag --- Comment #6 from Jonathan Wakely --- Fixed on trunk, but this should be backported to gcc-12 too. The warning is present on older branches but suppressed by default, so it's not important to backport before to older branches.
[Bug libstdc++/108554] Warning "null pointer dereferece" raised when extracting a unique_ptr from a map and any "-O" flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108554 --- Comment #5 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:3376467ce090aa0966d59ca3aea35db4f17a4b47 commit r13-5386-g3376467ce090aa0966d59ca3aea35db4f17a4b47 Author: Jonathan Wakely Date: Thu Jan 26 10:55:28 2023 + libstdc++: Add returns_nonnull to non-inline std::map detail [PR108554] std::map uses a non-inline function to rebalance its tree and the compiler can't see that it always returns a valid pointer (assuming valid inputs, which is a precondition anyway). This can result in -Wnull-derefernce warnings for valid code, because the compiler thinks there is a path where the function returns null. Adding the returns_nonnull attribute tells the compiler that is can't happen. While we're doing that, we might as well also add a nonnull attribute to the rebalancing functions too. libstdc++-v3/ChangeLog: PR libstdc++/108554 * include/bits/stl_tree.h (_Rb_tree_insert_and_rebalance): Add nonnull attribute. (_Rb_tree_rebalance_for_erase): Add nonnull and returns_nonnull attributes. * testsuite/23_containers/map/modifiers/108554.cc: New test.
[Bug libstdc++/108530] [13 regression] std/time/tzdb/1.cc fails after r13-5168-g559993b85744ae
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108530 --- Comment #8 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:93e2bf51dedd0870b78b770b72e34b15a7a0d14a commit r13-5385-g93e2bf51dedd0870b78b770b72e34b15a7a0d14a Author: Jonathan Wakely Date: Thu Jan 26 09:26:35 2023 + libstdc++: Fix strings read from /etc/sysconfig/clock [PR108530] In r13-5339-ge00d5cafbe1a77 I made std::chrono::current_zone() look for DEFAULT_TIMEZONE in /etc/sysconfig/clock but that is the wrong variable. Old Suse systems use TIMEZONE to determine which zone /etc/localtime is a copy of, and old RHEL system use ZONE. libstdc++-v3/ChangeLog: PR libstdc++/108530 * src/c++20/tzdb.cc (current_zone): Look for TIMEZONE or ZONE in /etc/sysconfig/clock, not DEFAULT_TIMEZONE.
[Bug tree-optimization/108520] [13 Regression] ICE in nonnull_arg_p, at tree.cc:14372 with -O1 and above (gnu::assume and gnu::nonnull)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108520
--- Comment #4 from Jakub Jelinek ---
Slightly cleaned up testcase:
static void foo () {}
struct S { void (*f) (); };
[[gnu::nonnull (1)]]
void
bar (void *x)
{
struct S a[3] = { { foo }, { foo }, { foo } };
for (struct S *i = a, *e = a + 3; i != e; i++)
{
[[assume (i->f)]];
i->f ();
}
}
[Bug tree-optimization/108520] [13 Regression] ICE in nonnull_arg_p, at tree.cc:14372 with -O1 and above (gnu::assume and gnu::nonnull)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108520 Jakub Jelinek changed: What|Removed |Added CC||aldyh at gcc dot gnu.org, ||amacleod at redhat dot com, ||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- So, unless nothing in the ranger uses cfun but passes around struct function *fun on which it should operate, I think gimple_infer_range::check_assume_func needs to temporarily set_cfun to fun and switch it back later. Generally set_cfun is fairly expensive, but for the assumption functions one would hope that at least in most cases they have the same optimization and target nodes as the "caller".
[Bug tree-optimization/108540] [13 Regression] Frange miscompilation of ruby since r13-3261
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108540 --- Comment #7 from Aldy Hernandez --- (In reply to Jakub Jelinek from comment #6) > Created attachment 54351 [details] > gcc13-pr108540.patch > > Untested fix. LGTM. Thanks for looking at this.
[Bug modula2/108557] Stuck compilation for empty file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108557 Gaius Mulley changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-01-26 Ever confirmed|0 |1 --- Comment #1 from Gaius Mulley --- Thanks, indeed replicated and confirmed.
[Bug modula2/108555] gm2_langhook_option_lang_mask causes all (unappropriate) C language options to be recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108555 Iain Sandoe changed: What|Removed |Added Assignee|gaius at gcc dot gnu.org |iains at gcc dot gnu.org --- Comment #4 from Iain Sandoe --- (In reply to Richard Biener from comment #3) > (In reply to Iain Sandoe from comment #2) > ... yes, you are short-cutting generic code that diagnoses and removes > unappropriate options, I'm not sure simulating that behavior is easily > possible. OK. I will rework it to claim the options in m2/lang.opt.
[Bug tree-optimization/108540] [13 Regression] Frange miscompilation of ruby since r13-3261
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108540 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- Created attachment 54351 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54351&action=edit gcc13-pr108540.patch Untested fix.
[Bug tree-optimization/107323] [10 Regression] Loop distribute issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107323 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Known to work||10.4.1 Status|ASSIGNED|RESOLVED --- Comment #15 from Richard Biener --- Fixed.
[Bug tree-optimization/107554] [10 Regression] Segmentation fault during GIMPLE pass: strlen (tree-ssa-strlen.cc:4772)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107554 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||10.4.1 Resolution|--- |FIXED --- Comment #11 from Richard Biener --- Fixed.
[Bug tree-optimization/107107] [10 Regression] Wrong codegen from TBAA when stores to distinct same-mode types are collapsed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107107 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail||10.4.0 Known to work||10.4.1 Resolution|--- |FIXED --- Comment #15 from Richard Biener --- Fixed.
[Bug tree-optimization/107554] [10 Regression] Segmentation fault during GIMPLE pass: strlen (tree-ssa-strlen.cc:4772)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107554 --- Comment #10 from CVS Commits --- The releases/gcc-10 branch has been updated by Richard Biener : https://gcc.gnu.org/g:5d62d86d958a217cdb4155a557aeda1d0e644aba commit r10-11179-g5d62d86d958a217cdb4155a557aeda1d0e644aba Author: Richard Biener Date: Fri Nov 11 14:28:52 2022 +0100 tree-optimization/107554 - fix ICE in stlen optimization The following fixes a wrongly typed variable causing an ICE. PR tree-optimization/107554 * tree-ssa-strlen.c (strlen_pass::count_nonzero_bytes): Use unsigned HOST_WIDE_INT type for the strlen. * gcc.dg/pr107554.c: New testcase. Co-Authored-By: Nikita Voronov (cherry picked from commit 81de4037454275f8ed6d858fbc129e832c6147ef)
[Bug tree-optimization/107323] [10 Regression] Loop distribute issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107323 --- Comment #14 from CVS Commits --- The releases/gcc-10 branch has been updated by Richard Biener : https://gcc.gnu.org/g:95e5c07aa216fe2863ea02e8508a51b5f7528839 commit r10-11178-g95e5c07aa216fe2863ea02e8508a51b5f7528839 Author: Richard Biener Date: Fri Oct 21 09:45:44 2022 +0200 tree-optimization/107323 - loop distribution partition ordering issue The following reverts part of the PR94125 fix which causes us to use a bogus partition ordering after applying versioning for alias to the testcase in PR107323. Instead PR94125 is fixed by appropriately considering to be merged SCCs when skipping edges we want to ignore because of the alias versioning. PR tree-optimization/107323 * tree-loop-distribution.c (pg_unmark_merged_alias_ddrs): New function. (loop_distribution::break_alias_scc_partitions): Revert postorder save/restore from the PR94125 fix. Instead make sure to not ignore edges from SCCs we are going to merge. * gcc.dg/tree-ssa/pr107323.c: New testcase. (cherry picked from commit 09f9814dc02c161ed78604c6df70b19b596f7524)
[Bug tree-optimization/106934] [10 Regression] ICE: verify_gimple failed since r9-5682-gef310a95a934d0f3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106934 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Known to fail||10.4.0 Status|ASSIGNED|RESOLVED Known to work||10.4.1 --- Comment #7 from Richard Biener --- Fixed.
[Bug tree-optimization/107107] [10 Regression] Wrong codegen from TBAA when stores to distinct same-mode types are collapsed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107107 --- Comment #14 from CVS Commits --- The releases/gcc-10 branch has been updated by Richard Biener : https://gcc.gnu.org/g:58e39fcaaf298ff54b6f1a45fa9d15390e8113fb commit r10-11177-g58e39fcaaf298ff54b6f1a45fa9d15390e8113fb Author: Richard Biener Date: Thu Oct 6 11:20:16 2022 +0200 tree-optimization/107107 - tail-merging VN wrong-code The following fixes an unintended(?) side-effect of the special MODIFY_EXPR expression entries we add for tail-merging during VN. We shouldn't value-number the virtual operand differently here. PR tree-optimization/107107 * tree-ssa-sccvn.c (visit_reference_op_store): Do not affect value-numbering when doing the tail merging MODIFY_EXPR lookup. * gcc.dg/pr107107.c: New testcase. (cherry picked from commit 85333b9265720fc4e49397301cb16324d2b89aa7)
[Bug tree-optimization/106934] [10 Regression] ICE: verify_gimple failed since r9-5682-gef310a95a934d0f3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106934 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Richard Biener : https://gcc.gnu.org/g:d0a3e323a0c0e3db7dcd428587f0633209f9ceec commit r10-11176-gd0a3e323a0c0e3db7dcd428587f0633209f9ceec Author: Richard Biener Date: Wed Sep 14 09:00:35 2022 +0200 tree-optimization/106934 - avoid BIT_FIELD_REF of bitfields The following avoids creating BIT_FIELD_REF of bitfields in update-address-taken. The patch doesn't implement punning to a full precision integer type but leaves a comment according to that. PR tree-optimization/106934 * tree-ssa.c (non_rewritable_mem_ref_base): Avoid BIT_FIELD_REFs of bitfields. (maybe_rewrite_mem_ref_base): Likewise. * gfortran.dg/pr106934.f90: New testcase. (cherry picked from commit 05f5c42cb42c5088187d44cc45a5f671d19ad8c5)
[Bug modula2/108551] gcc/m2/gm2-libs-pim/Termbase.mod:128:1: error: control reaches end of non-void function [-Werror=return-type]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108551 --- Comment #4 from Richard Biener --- (In reply to Martin Liška from comment #3) > I might reduced that: > > $ cat Termbase.mod > IMPLEMENTATION MODULE Termbase ; > TYPE >ReadMethods = POINTER TO RECORD >s : StatusProcedure ; > END ; >WriteMethod = POINTER TO RECORD > END ; > VAR >rStack: ReadMethods ; >wStack: WriteMethod ; > PROCEDURE AssignRead (rp: ReadProcedure; sp: StatusProcedure; > VAR Done: BOOLEAN) ; > BEGIN >IF rStack=NIL >THEN >END > END AssignRead ; > (* > *) > PROCEDURE UnAssignRead (VAR Done: BOOLEAN) ; > END UnAssignRead ; > PROCEDURE Read (VAR ch: CHAR) ; > END Read ; > PROCEDURE KeyPressed () : BOOLEAN ; > BEGIN >IF rStack=NIL >THEN > RETURN( rStack^.s() ) > ELSE > RETURN( rStack^.s() ) >END > END KeyPressed ; > PROCEDURE AssignWrite (wp: WriteProcedure; VAR Done: BOOLEAN) ; > BEGIN >IF wStack=NIL >THEN >END > END AssignWrite ; > PROCEDURE UnAssignWrite (VAR Done: BOOLEAN) ; > END UnAssignWrite ; > PROCEDURE Write (VAR ch: CHAR) ; > END Write ; > END Termbase. > > $ /dev/shm/objdir/./gcc/gm2 -B/dev/shm/objdir/./gcc/ Termbase.mod > -Werror=return-type -I/home/marxin/Programming/gcc/gcc/m2/gm2-libs-pim > -I/home/marxin/Programming/gcc/gcc/m2/gm2-libs > Termbase.mod: In function ‘main’: ^^^ that's again for 'main', like my attempt at a reduced testcase. I think the proper fix is to give up on fixing this diagnostic and instead ignore -Wreturn-type as intended.
[Bug c++/108559] [13 Regression] A new crash with using a simple class, inheritance and a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108559 Richard Biener changed: What|Removed |Added Priority|P3 |P1
