[Bug tree-optimization/92860] [9/10/11/12 regression] Global flags affected by -O settings are clobbered by optimize attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92860 --- Comment #60 from David Binderman --- (In reply to Martin Liška from comment #59) > Most of the issues were fixed in GCC 12 stage1. > There are still corner cases, but the current situation should be much > better. Not for me, they aren't. I can reproduce it on today's trunk, but any *.i file I produce seems to compile fine ;-< I will attach the *.i file and the command line.
[Bug tree-optimization/102087] [12 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: in determine_exit_conditions, at tree-ssa-loop-manip.c:1049 since r12-3136-g3673dcf6d6baeb67
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102087 --- Comment #18 from David Binderman --- (In reply to Arseny Solokha from comment #17) > (In reply to David Binderman from comment #13) > > The code in comment 8 still seems to fail: > > It might make sense to file a new PR for that, I guess. I checked, and the code in comment 8 works fine, since sometime before 20211105.
[Bug c/103492] 2 * new warnings in clang build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103492 --- Comment #5 from David Binderman --- (In reply to Martin Liška from comment #4) > All right! Is there any Clang bug report for this, or should I create it? Option 2, I think. I have a 0.0 % success rate at getting any response to any clang bug I report ;-<
[Bug ipa/103513] [12 Regression] ICE in evaluate_conditions_for_known_args, at ipa-fnsummary.c:516 with -O2 and above since r12-5531-g1b0acc4b800b589a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103513
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment #5 from David Binderman ---
Another test case:
$ more bug778.c
int us_1, func_8_i_8;
void func_8(int s_4)
{
func_8_i_8 = 7;
for (;;)
if (func_8_i_8 * (func_8_i_8 != s_4))
for (;;)
;
}
void func_7_s_4()
{
func_8(us_1 && func_7_s_4);
}
$
[Bug tree-optimization/103494] [12 Regression] ice in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1476
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103494
--- Comment #2 from David Binderman ---
$ more bug777.cc
void glFinish();
struct _Vector_base {
struct {
unsigned _M_start;
} _M_impl;
};
class vector : _Vector_base {
public:
vector(long) {}
unsigned *data() { return &_M_impl._M_start; }
};
void *PutBitsIndexedImpl_color_table;
int PutBitsIndexedImpl_dstRectHeight;
char *PutBitsIndexedImpl_src_ptr;
void PutBitsIndexedImpl() {
vector unpacked_buf(PutBitsIndexedImpl_dstRectHeight);
unsigned *dst_ptr = unpacked_buf.data();
for (int x; x; x++) {
char i = *PutBitsIndexedImpl_src_ptr++;
dst_ptr[x] = static_cast(PutBitsIndexedImpl_color_table)[i];
}
glFinish();
}
$
[Bug c++/103494] ice in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1476
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103494 --- Comment #1 from David Binderman --- I have a cvise reduction running right now. The code is C++, so it will take some time.
[Bug c++/103494] New: ice in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1476
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103494 Bug ID: 103494 Summary: ice in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1476 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 51906 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51906&action=edit gzipped C++ source code For the attached C++ code, with compiler flag -O3, does this: /home/dcb35/rpmbuild/BUILD/libvdpau-va-gl-0.4.2/src/api-output-surface.cc:448:1: internal compiler error: in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1476 448 | PutBitsIndexedImpl(VdpOutputSurface surface_id, VdpIndexedFormat source_indexed_format, | ^~ 0x1ff5137 vect_get_vec_defs_for_operand(vec_info*, _stmt_vec_info*, unsigned int, tree_node*, vec*, tree_node*) ../../trunk.git/gcc/tree-vect-stmts.c:1476 0x2014db1 vect_get_gather_scatter_ops(_loop_vec_info*, loop*, _stmt_vec_info*, _slp_tree*, unsigned int, gather_scatter_info*, tree_node**, vec*) ../../trunk.git/gcc/tree-vect-stmts.c:2981 The bug first seems to occur sometime between git hash 5e5f880d0452ef2c and 8af3f53d325fe4a6, a distance of 43 commits.
[Bug c/103492] New: 2 * new warnings in clang build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103492 Bug ID: 103492 Summary: 2 * new warnings in clang build Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- ../../trunk.git/gcc/fold-const-call.c:432:1: warning: non-void function does not return a value in all control paths [-Wreturn-type] ../../trunk.git/gcc/fold-const-call.c:465:1: warning: non-void function does not return a value in all control paths [-Wreturn-type] It looks like clang is being a bit keen. Suggest add a simple return false at the end of a couple of functions. Either that or start decorating the switch statements in some way.
[Bug c/103451] New: crash at gcc/range-op.cc:1836
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103451
Bug ID: 103451
Summary: crash at gcc/range-op.cc:1836
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For this C code:
int func_10_ptr_12;
void func_10(long li_8)
{
long *ptr_9 = &li_8;
li_8 &= *ptr_9 / 0 ?: li_8;
for (;;)
func_10_ptr_12 &= 4 ? *ptr_9 : 4;
}
void func_9_s_8()
{
func_10(func_9_s_8);
}
on recent gcc, does this:
$ /home/dcb/gcc/results/bin/gcc -c -O2 bug775.c
during IPA pass: inline
bug775.c: At top level:
bug775.c:14:1: internal compiler error: Segmentation fault
14 | }
| ^
0xdabcb9 crash_signal(int)
../../trunk.git/gcc/toplev.c:322
0x1c98f2f operator_div::wi_fold(irange&, tree_node*,
generic_wide_int const&, generic_wide_int
const&, generic_wide_int const&,
generic_wide_int const&) const
../../trunk.git/gcc/range-op.cc:1836
The bug first seems to occur sometime between git hash 415f9ee404dc9e8a
and 4a2007594cff78fb, a distance of 22 commits.
[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808
--- Comment #53 from David Binderman ---
I am not sure if this belongs here or in a separate bug report,
but given this code:
class AllocatorWithCleanup {
public:
int *allocate(int, void *);
};
class SecBlock {
SecBlock() : m_ptr(m_alloc.allocate(0, nullptr)) {}
AllocatorWithCleanup m_alloc;
int *m_ptr;
};
Recent clang-14 thinks it is ok and new gcc trunk thinks it isn't.
$ /home/dcb/llvm/results/bin/clang++ -c -O2 -Wall bug774.cc
$ /home/dcb/llvm/results/bin/clang++ -v
clang version 14.0.0 (https://github.com/llvm/llvm-project.git
f95bd18b5faa6a5af4b5786312c373c5b2dce687)
$ /home/dcb/gcc/results/bin/gcc -c -O2 -Wall bug774.cc
bug774.cc: In constructor ‘SecBlock::SecBlock()’:
bug774.cc:6:22: warning: member ‘SecBlock::m_alloc’ is used uninitialized
[-Wuninitialized]
6 | SecBlock() : m_ptr(m_alloc.allocate(0, nullptr)) {}
| ^~~
$ /home/dcb/gcc/results/bin/gcc -v
gcc version 12.0.0 2029 (experimental) (0e510ab53414430e)
$
[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808 --- Comment #52 from David Binderman --- (In reply to Marek Polacek from comment #51) > At last, implemented. Marvellous. I will test it by compiling Fedora rawhide and report back with any errors. Nearly 17 years is quite a wait for a fix.
[Bug tree-optimization/103288] [12 Regression] ice during GIMPLE pass: phiopt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103288 --- Comment #3 from David Binderman --- (In reply to Andrew Pinski from comment #1) > Most likely caused by r12-5300-gf98f373dd822b35c . Strange. That git commit doesn't seem to be in the range of git hashes I specified. The one commit that does mention phi in that range is b7a23949b0dcc4205fcc2be6b84b91441faa384d, by Aldy Hernandez. I am unlikely to have the time to do a git bisect in the next 24 hours or so.
[Bug tree-optimization/103288] [12 Regression] ice during GIMPLE pass: phiopt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103288
--- Comment #2 from David Binderman ---
Reduced C code seems to be
int ui_5;
long func_14_uli_8;
void func_14() {
ui_5 &= (func_14_uli_8 ? 60 : ui_5) ? 5 : 0;
}
[Bug c/103288] New: ice during GIMPLE pass: phiopt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103288 Bug ID: 103288 Summary: ice during GIMPLE pass: phiopt Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 51817 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51817&action=edit C source code For the attached C code, compiled with recent gcc trunk and compiler flag -O2, does this: $ /home/dcb/gcc/results/bin/gcc -w -O2 destDir/testFile.239.c destDir/testFile.239.c: In function ‘func_14’: destDir/testFile.239.c:38:9: error: definition in block 6 does not dominate use in block 5 38 | int32_t func_14(uint64_t uli_8, int8_t c_9, int8_t c_10, uint64_t uli_11) | ^~~ for SSA_NAME: _102 in statement: prephitmp_103 = PHI <_102(5), _102(6)> PHI argument _102 for PHI node prephitmp_103 = PHI <_102(5), _102(6)> during GIMPLE pass: phiopt The bug first seems to occur sometime between git hash 2f3d43a35155685b and 8a601f9bc45f9faa, a distance of 22 commits.
[Bug tree-optimization/103175] [12 Regression] internal compiler error: in handle_call_arg, at tree-ssa-structalias.c:4139
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103175 --- Comment #6 from David Binderman --- Created attachment 51773 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51773&action=edit gzipped C++ source code Another test case. Flag -O1 required.
[Bug c/103194] ice in optimize_atomic_bit_test_and, at tree-ssa-ccp.c:3626
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103194 David Binderman changed: What|Removed |Added CC||crazylht at gmail dot com --- Comment #1 from David Binderman --- Adding HJ. I hope I have the correct email account.
[Bug c/103194] New: ice in optimize_atomic_bit_test_and, at tree-ssa-ccp.c:3626
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103194
Bug ID: 103194
Summary: ice in optimize_atomic_bit_test_and, at
tree-ssa-ccp.c:3626
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For this C code:
long pscc_a_2_3;
int pscc_a_1_4;
void pscc()
{
pscc_a_1_4 = __sync_fetch_and_and(&pscc_a_2_3, 1);
}
compiled by recent gcc trunk, does this:
$ /home/dcb/gcc/results/bin/gcc -c -O1 bug771.c
during GIMPLE pass: fab
bug771.c: In function ‘pscc’:
bug771.c:3:6: internal compiler error: in optimize_atomic_bit_test_and, at
tree-ssa-ccp.c:3626
3 | void pscc()
| ^~~~
0xee6020 optimize_atomic_bit_test_and(gimple_stmt_iterator*, internal_fn, bool,
bool)
../../trunk.git/gcc/tree-ssa-ccp.c:3626
0xee389a (anonymous namespace)::pass_fold_builtins::execute(function*)
../../trunk.git/gcc/tree-ssa-ccp.c:0
The bug first seems to occur sometime between git hash f2572a398d21fd52
and a97fdde627e64202,a distance of some 60 commits.
In that range, commit fb161782545224f55ba26ba663889c5e6e9a04d1
looks a likely candidate.
[Bug c/103132] New: ice: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103132
Bug ID: 103132
Summary: ice: Segmentation fault
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For this C code:
int globus_i_GLOBUS_GRIDFTP_SERVER_debug_handle_1;
int globus_l_gfs_ipc_unpack_data__sz;
static void globus_l_gfs_ipc_unpack_cred(len) {
if (globus_i_GLOBUS_GRIDFTP_SERVER_debug_handle_1)
globus_i_GLOBUS_GRIDFTP_SERVER_debug_printf("", __func__);
}
static void globus_l_gfs_ipc_unpack_data(len) {
for (; globus_l_gfs_ipc_unpack_data__sz;)
len--;
len -= 4;
len -= 4;
globus_l_gfs_ipc_unpack_cred(len);
}
void globus_l_gfs_ipc_reply_read_body_cb() { globus_l_gfs_ipc_unpack_data(); }
compiled by recent gcc, does this:
$ /home/dcb/gcc/results.20211105/bin/gcc -g -O2 -c bug770.c
In function ‘globus_l_gfs_ipc_unpack_data.isra’:
cc1: internal compiler error: Segmentation fault
0xd987a9 crash_signal(int)
../../trunk.git/gcc/toplev.c:322
0x10b9b2a contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../trunk.git/gcc/tree.h:3546
0x10b9b2a walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../trunk.git/gcc/tree.c:11030
The fault first seems to occur sometime between git hash d3f7a2fa64f8777c
and bcf4065c909bd101, a distance of 25 commits.
[Bug ipa/103099] [12 Regression] ICE tree check: expected ssa_name, have debug_expr_decl in split_function, at ipa-split.c:1397 since r12-4920-g1ece90ffa9ce63b4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103099 David Binderman changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #3 from David Binderman --- I see this one also. I have a couple of test cases available on request.
[Bug c/103093] New: ice in get_imports, at gimple-range-gori.cc:221
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103093
Bug ID: 103093
Summary: ice in get_imports, at gimple-range-gori.cc:221
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For this C source code:
int i_0, c_4, uc_7, func_2_c_11;
short *func_2_ptr_10;
void func_2() {
uc_7 = 7;
for (; uc_7 <= 60; uc_7 += 1) {
c_4 = 5;
for (; c_4 <= 76; c_4 += 1) {
func_2_ptr_10 = &i_0;
if ((i_0 |= 5) > 0 ?: (60 && uc_7) | *func_2_ptr_10)
if (func_2_c_11)
for (;;)
;
}
}
}
compiled with recent trunk gcc and compiler flag -O2, does this:
$ /home/dcb/gcc/results/bin/gcc -c -w -O2 bug769.c
during GIMPLE pass: vrp
bug769.c: In function ‘func_2’:
bug769.c:5:6: internal compiler error: in get_imports, at
gimple-range-gori.cc:221
5 | void func_2() {
| ^~
0x1ae51cf range_def_chain::get_imports(tree_node*)
../../trunk.git/gcc/gimple-range-gori.cc:220
The bug first seems to occur sometime between git hash a11c53985a7080f9
and c79399c7e128a3ea, range of 44 commits.
[Bug c++/103007] ice in vect_normalize_conj_loc, at tree-vect-slp-patterns.c:722
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103007
--- Comment #1 from David Binderman ---
Reduced C++ code seems to be:
template class MushMeshVector {
public:
MushMeshVector(float, float, float, float);
float Z() {
float __trans_tmp_3;
int inIndex = 2;
__trans_tmp_3 = m_value[inIndex];
return __trans_tmp_3;
}
float W() {
float __trans_tmp_4;
int inIndex = 3;
__trans_tmp_4 = m_value[inIndex];
return __trans_tmp_4;
}
void ZSet(float inValue) {
int inIndex = 2;
m_value[inIndex] = inValue;
}
void WSet(float inValue) {
int inIndex = 3;
m_value[inIndex] = inValue;
}
float m_value[D];
};
template class MushMeshQuaternion : MushMeshVector<4> {
public:
void PreMultiplyVector(MushMeshVector &) const;
void PostMultiplyVector(MushMeshVector &) const;
};
template
void MushMeshQuaternion::PreMultiplyVector(MushMeshVector &ioVec) const {
ioVec.ZSet(2 - m_value[1] + m_value[3] * 0);
ioVec.WSet(m_value[3] + m_value[1] - m_value[2] * 0);
}
template
void MushMeshQuaternion::PostMultiplyVector(MushMeshVector &ioVec) const {
T c = ioVec.Z(), d = ioVec.W();
ioVec.ZSet(0 - d * m_value[1]);
ioVec.WSet(2 - c * m_value[1]);
}
template class MushMeshQuaternionPair {
public:
void VectorRotate(MushMeshVector<4> &) const;
MushMeshQuaternion m_first;
MushMeshQuaternion m_second;
};
template
void MushMeshQuaternionPair::VectorRotate(MushMeshVector<4> &ioVec) const {
m_first.PreMultiplyVector(ioVec);
m_second.PostMultiplyVector(ioVec);
}
class MushMeshPosticity {
public:
MushMeshQuaternionPair AngPos();
};
class MushGamePiece {
public:
MushMeshPosticity Post();
void PostWRef();
};
class AdanaxisPieceProjectile : MushGamePiece {
void Move();
float m_acceleration;
};
void AdanaxisPieceProjectile::Move() {
MushMeshVector<4> accVec(0, 0, 0, m_acceleration);
Post().AngPos().VectorRotate(accVec);
PostWRef();
}
[Bug c++/103007] New: ice in vect_normalize_conj_loc, at tree-vect-slp-patterns.c:722
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103007 Bug ID: 103007 Summary: ice in vect_normalize_conj_loc, at tree-vect-slp-patterns.c:722 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 51705 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51705&action=edit gzipped C++ source code The attached C++ code, with compiler flag -O2 -march=bdver2, does this: during GIMPLE pass: slp Adanaxis/AdanaxisPieceProjectile.cpp: In member function ‘virtual void AdanaxisPieceProjectile::Move(MushGameLogic&, Mushware::tVal)’: Adanaxis/AdanaxisPieceProjectile.cpp:123:1: internal compiler error: in vect_normalize_conj_loc, at tree-vect-slp-patterns.c:722 0x8f64ab vect_normalize_conj_loc ../../trunk.git/gcc/tree-vect-slp-patterns.c:722 The bug seems to start sometime between git hash b343a29dbcbfc5ea and 70c947e4dfaa6d63. I will have my usual go at reducing the code.
[Bug c/103003] ice in set_relation, at value-relation.cc:592
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103003
--- Comment #2 from David Binderman ---
I am not sure why the #include is in there.
Further reduced code is
typedef char int8_t;
int8_t c_4, uli_5;
unsigned short us_6;
func_1() {
int uli_9;
short ptr_16ptr_11 = &uli_9;
for (; us_6 <= 6;)
if ((us_6 *= uli_9) < (uli_5 || 0) ?: ((c_4 = us_6) >= us_6) - uli_5)
uli_9 = 9;
}
Flag -O2 required.
[Bug c/103003] ice in set_relation, at value-relation.cc:592
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103003
--- Comment #1 from David Binderman ---
Reduced C code seems to be
#include
int8_t c_4, uli_5;
uint16_t us_6;
func_1() {
int uli_9 = 0;
uint64_t ptr_11 = uli_9 |= uli_5 != 0;
uint16_t ptr_16ptr_11 = &uli_9;
for (; us_6 <= 6;)
if ((us_6 *= uli_9) < (ptr_11 || 0) ?: ((c_4 = us_6) >= us_6) - uli_5)
for (uli_9 = 9; uli_9;)
;
}
[Bug c/103003] New: ice in set_relation, at value-relation.cc:592
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103003
Bug ID: 103003
Summary: ice in set_relation, at value-relation.cc:592
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
Created attachment 51702
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51702&action=edit
C source code
The attached C code with recent gcc trunk, does this:
bug767.c: In function ‘func_1’:
bug767.c:10:1: internal compiler error: in set_relation, at
value-relation.cc:592
10 | func_1() {
| ^~
0x1c97b0c path_oracle::register_relation(basic_block_def*, tree_code,
tree_node*, tree_node*)
../../trunk.git/gcc/value-relation.cc:0
The code first goes wrong sometime between git hash 22d34a2a50651d01
and ec0124e0acb556cd.
I will try to reduce the code.
[Bug c++/102988] ice during GIMPLE pass: hardcbr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102988
--- Comment #1 from David Binderman ---
Reduced C++ code is:
inline namespace __cxx11 {}
template _Tp *__addressof(_Tp);
namespace __cxx11 {
class basic_string {
void _M_set_length();
public:
~basic_string();
void operator=(basic_string __str) {
if (this != __addressof(__str))
_M_set_length();
}
};
} // namespace __cxx11
class vector {
public:
basic_string operator[](long);
};
class PersistException {};
class PersistEngine {
const basic_string readClass() throw(PersistException);
vector myClassVector;
};
const basic_string PersistEngine::readClass() throw(PersistException) {
basic_string className;
className = myClassVector[0];
return className;
}
[Bug c++/102988] New: ice during GIMPLE pass: hardcbr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102988
Bug ID: 102988
Summary: ice during GIMPLE pass: hardcbr
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
Created attachment 51694
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51694&action=edit
gzipped C++ source code
The attached C++ code, with compiler flags -c -w -std=c++14 -w -O1
-fharden-conditional-branches, does this:
/home/dcb35/rpmbuild/BUILD/ucommon-7.0.0/commoncpp/persist.cpp:254:19: error:
RESULT_DECL should be read only when DECL_BY_REFERENCE is set
254 | const std::string PersistEngine::readClass() throw(PersistException)
| ^
while verifying SSA_NAME className_96 in statement
__asm__("" : "=g" className_96 : "0" className_14(D));
during GIMPLE pass: hardcbr
/home/dcb35/rpmbuild/BUILD/ucommon-7.0.0/commoncpp/persist.cpp:254:19: internal
compiler error: verify_ssa failed
I will have my usual go at reducing the code.
[Bug c++/87656] Useful flags to enable with -Wall or -Wextra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87656 --- Comment #7 from David Binderman --- (In reply to David Binderman from comment #6) > I'd like to vote for -Wduplicated-cond being in either -Wextra or -Wall. > > I only just found it last week (thanks to Weverything discussion) > and it is proving useful in finding bugs in fedora rawhide. -Wduplicated-branches in -Wextra too. I've switched on both in my local copy of gcc. Useful.
[Bug libffi/102896] src/moxie/ffi.c:239:arrayIndexOutOfBounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102896 --- Comment #5 from David Binderman --- (In reply to Martin Liška from comment #4) > Then, please file it here: https://github.com/libffi/libffi/issues. Done. https://github.com/libffi/libffi/issues/666
[Bug libffi/102896] src/moxie/ffi.c:239:arrayIndexOutOfBounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102896 --- Comment #3 from David Binderman --- (In reply to H.J. Lu from comment #2) > Does it happen in libffi upstream? > > https://github.com/libffi/libffi Yes.
[Bug libffi/102896] src/moxie/ffi.c:239:arrayIndexOutOfBounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102896 David Binderman changed: What|Removed |Added CC||hjl at gcc dot gnu.org --- Comment #1 from David Binderman --- git blame says: 92456a4e5658 (H.J. Lu 2021-08-31 07:14:47 -0700 239) else if (ptr == (char *) ®ister_args[7]) Adding HJ for their opinion.
[Bug libffi/102896] New: src/moxie/ffi.c:239:arrayIndexOutOfBounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102896
Bug ID: 102896
Summary: src/moxie/ffi.c:239:arrayIndexOutOfBounds
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libffi
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
Static analyser cppcheck says:
trunk.git/libffi/src/moxie/ffi.c:239:46: error: Array 'register_args[6]'
accessed at index 7, which is out of bounds. [arrayIndexOutOfBounds]
Source code is
unsigned register_args[6] =
{ arg1, arg2, arg3, arg4, arg5, arg6 };
...
else if (ptr == (char *) ®ister_args[7])
[Bug middle-end/102797] ice in useless_type_conversion_p, at gimple-expr.c:87
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102797 David Binderman changed: What|Removed |Added CC||amacleod at redhat dot com --- Comment #7 from David Binderman --- Andrew's commit 93ac832f1846e4867aa6537f76f510fab8e3e87d looks to me to be the culprit. Adding Andrew for best advice.
[Bug middle-end/102797] ice in useless_type_conversion_p, at gimple-expr.c:87
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102797 --- Comment #6 from David Binderman --- Range currently seems to be (a10794eafb151b92, 730f52e05a1fb5c8). Trying 1ba7adabf29eb671. Only 7 revisions left to go.
[Bug middle-end/102797] ice in useless_type_conversion_p, at gimple-expr.c:87
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102797 --- Comment #5 from David Binderman --- (In reply to David Binderman from comment #4) > I am trying a git bisect. I frequently get this wrong ;-< > > commit a10794eafb151b92 is being built. Seems fine, trying 730f52e05a1fb5c8.
[Bug middle-end/102797] ice in useless_type_conversion_p, at gimple-expr.c:87
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102797 --- Comment #4 from David Binderman --- I am trying a git bisect. I frequently get this wrong ;-< commit a10794eafb151b92 is being built.
[Bug c/102797] ice in useless_type_conversion_p, at gimple-expr.c:87
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102797
--- Comment #1 from David Binderman ---
Reduced C code is
glib_autoptr_cleanup_GdkPaintable(struct _GdkPaintable **_ptr) {
glib_autoptr_clear_GdkPaintable(*_ptr);
}
glib_autoptr_clear_GdkRGBA(struct _GdkRGBA *_ptr) {
if (_ptr)
gdk_rgba_free();
}
glib_autoptr_cleanup_GdkRGBA(struct _GdkRGBA **_ptr) {
glib_autoptr_clear_GdkRGBA(*_ptr);
}
gtd_sidebar_list_row_set_property() {
__attribute__((cleanup(glib_autoptr_cleanup_GdkPaintable))) *paintable = 0;
__attribute__((cleanup(glib_autoptr_cleanup_GdkRGBA))) *color = 0;
color = gtd_task_list_get_color();
paintable = gtd_create_circular_paintable();
gtk_image_set_from_paintable();
}
Flag -march=bdver2 not required for the reduced code, only -O2 -fexceptions.
[Bug c/102797] New: ice in useless_type_conversion_p, at gimple-expr.c:87
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102797 Bug ID: 102797 Summary: ice in useless_type_conversion_p, at gimple-expr.c:87 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 51615 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51615&action=edit gzipped C source code For the attached C code, recent gcc trunk does this: ../src/plugins/task-lists-workspace/gtd-sidebar-list-row.c:264:1: internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in useless_type_conversion_p, at gimple-expr.c:87 Flags -w -march=bdver2 -O2 -fexceptions required. The bug first seems to occur between git hash be072bfa5bb38171 and 93d183a5fff92d80, so about 27 revisions. I have a reduction running in the other window now.
[Bug middle-end/101292] [12 Regression] recent valgrind error in warning-control.cc since r12-1804-g65870e75616ee4359d1c13b99be794e6a577bc65
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101292 --- Comment #5 from David Binderman --- I tried out the C++ testsuite and there are dozens of duplicates. First four are ./g++.dg/abi/mangle36.C ./g++.dg/abi/mangle40.C ./g++.dg/asan/asan_test.cc ./g++.dg/asan/pr81021.C It looks like only -O1 is needed. $ /home/dcb/gcc/results.20211014.valgrind/bin/g++ -c -O1 ./g++.dg/abi/mangle36.C ==2656305== Invalid read of size 4 ==2656305==at 0x11AE4E0: put (hash-map.h:179) ==2656305==by 0x11AE4E0: copy_warning (warn ing-control.cc:209) ==2656305==by 0x11AE4E0: copy_warning(tree_node*, tree_node const*) (warn ing-control.cc:228) ==2656305==by 0x6FEE17: cp_fold(tree_node*) (cp-gimplify.c:2778)
[Bug c++/102281] -ftrivial-auto-var-init=zero causes ice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102281 --- Comment #13 from David Binderman --- Created attachment 51593 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51593&action=edit C++ source code Third test case.
[Bug c++/102281] -ftrivial-auto-var-init=zero causes ice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102281 --- Comment #9 from David Binderman --- Created attachment 51587 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51587&action=edit C++ source code Another test case derived from compiling fedora source code.
[Bug ipa/102081] [12 regression] ICE building compiler starting with r12-3159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102081 --- Comment #6 from David Binderman --- (In reply to Jan Hubicka from comment #5) > I believe that this should be fixed. Is it still reproducing for you? (the > testcase in comment #2 compiles for me) Code in comment 2 compiles fine for me now.
[Bug ipa/102581] [12 Regression] ice in forced_merge, at ipa-modref-tree.h:352 with -fno-strict-aliasing and -O2 since r12-3202-gf5ff3a8ed4ca9173
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102581
--- Comment #4 from David Binderman ---
Reduced C++ source code, after a pretty hefty four hours of reduction, is
enum VkStructureType {
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_BUFFER_DEVICE_ADDRESS_FEATURES_EXT,
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FEATURES_2_KHR
} typedef VkPhysicalDeviceSparseProperties;
struct VkPhysicalDeviceProperties {
int apiVersion;
VkPhysicalDeviceSparseProperties sparseProperties;
};
typedef struct {
VkStructureType sType;
int *pPhysicalDevices;
} VkPhysicalDeviceFeatures2;
typedef struct VkPhysicalDeviceProperties2 {
VkStructureType sType;
void *pNext;
} VkPhysicalDeviceMemoryProperties2;
struct VulkanVersion {
int major;
int minor;
int patch;
};
int make_vulkan_version_version;
VulkanVersion make_vulkan_version() {
return {make_vulkan_version_version, make_vulkan_version_version,
make_vulkan_version_version};
}
struct AppGpu {
int &inst;
int id;
int *phys_device = nullptr;
VulkanVersion api_version{};
VkPhysicalDeviceProperties props{};
VkPhysicalDeviceProperties2 props2{};
int memory_props{};
VkPhysicalDeviceMemoryProperties2 memory_props2{};
int features{};
VkPhysicalDeviceFeatures2 features2{};
int *dev = nullptr;
int enabled_features{};
int AppGpu_phys_device;
int AppGpu_inst;
AppGpu() : inst(AppGpu_inst), id() {
api_version = make_vulkan_version();
props2.sType = memory_props2.sType = features2.sType =
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FEATURES_2_KHR;
}
};
main() { AppGpu(); }
[Bug ipa/102581] [12 Regression] ice in forced_merge, at ipa-modref-tree.h:352 with -fno-strict-aliasing and -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102581 --- Comment #2 from David Binderman --- git blame says: f5ff3a8ed4ca (Jan Hubicka 2021-08-28 20:57:08 +0200 349) /* We assume that containment and lossless merging f5ff3a8ed4ca (Jan Hubicka 2021-08-28 20:57:08 +0200 350) was tested earlier. */ f5ff3a8ed4ca (Jan Hubicka 2021-08-28 20:57:08 +0200 351) gcc_checking_assert (!contains (a) && !a.contains (*this) f5ff3a8ed4ca (Jan Hubicka 2021-08-28 20:57:08 +0200 352) && !merge (a, record_adjustments)); Adding Jan for his best advice.
[Bug c++/102581] New: ice in forced_merge, at ipa-modref-tree.h:352 with -fno-strict-aliasing and -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102581 Bug ID: 102581 Summary: ice in forced_merge, at ipa-modref-tree.h:352 with -fno-strict-aliasing and -O2 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 51542 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51542&action=edit gzipped C++ source code The attached C++ source code, with compiler flags -fno-strict-aliasing and -O2, does this: /home/dcb35/rpmbuild/BUILD/Vulkan-Tools-sdk-1.2.189.0/vulkaninfo/vulkaninfo.cpp:1082:1: internal compiler error: in forced_merge, at ipa-modref-tree.h:352 The bug first occurs sometime before git hash 2fcfc03459a907c0, from about a month ago. I will try to reduce this source code downto somethine sensible.
[Bug c/102563] New: ice during GIMPLE pass: vrp-thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102563
Bug ID: 102563
Summary: ice during GIMPLE pass: vrp-thread
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For this C source code:
int _bdf_parse_glyphs_bp;
long _bdf_parse_glyphs_nibbles;
void _bdf_parse_glyphs_p()
{
long p_2;
_bdf_parse_glyphs_nibbles = p_2 << 1;
for (; 0 < _bdf_parse_glyphs_nibbles;)
if (1 < _bdf_parse_glyphs_nibbles)
_bdf_parse_glyphs_bp = _bdf_parse_glyphs_p;
}
compiled by recent gcc trunk and compiler flag -O2, does this:
$ /home/dcb/gcc/results/bin/gcc -c -O2 bug762.c
bug762.c: In function ‘_bdf_parse_glyphs_p’:
bug762.c:12:28: warning: assignment to ‘int’ from ‘void (*)()’ makes integer
from pointer without a cast [-Wint-conversion]
12 | _bdf_parse_glyphs_bp = _bdf_parse_glyphs_p;
|^
during GIMPLE pass: vrp-thread
bug762.c:4:6: internal compiler error: in upper_bound, at value-range.h:531
4 | void _bdf_parse_glyphs_p()
| ^~~
0x1b7a732 irange::upper_bound() const
../../trunk.git/gcc/value-range.h:531
The bug first seems to occur sometime between git hash
6de9f0c13b27c343 and 5f02854189405771.
[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes crash in pr82421.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285
--- Comment #11 from David Binderman ---
(In reply to qinzhao from comment #10)
> 2734 /* The heuristic of fold_builtin_alloca_with_align differs
git blame says:
13e49da934e9 (Tom de Vries 2011-10-07 12:49:49 + 2732) /*
The heuristic of fold_builtin_alloca_with_align differs before and
13e49da934e9 (Tom de Vries 2011-10-07 12:49:49 + 2733)
after inlining, so we don't require the arg to be changed into a
13e49da934e9 (Tom de Vries 2011-10-07 12:49:49 + 2734)
constant for folding, but just to be constant. */
9e878cf1bae7 (Eric Botcazou 2017-10-19 15:58:05 + 2735) if
(gimple_call_builtin_p (stmt, BUILT_IN_ALLOCA_WITH_ALIGN)
9e878cf1bae7 (Eric Botcazou 2017-10-19 15:58:05 + 2736)||
gimple_call_builtin_p (stmt, BUILT_IN_ALLOCA_WITH_ALIGN_AND_MAX))
1fed1006552c (Tom de Vries 2011-08-31 07:04:25 + 2737)
{
13e49da934e9 (Tom de Vries 2011-10-07 12:49:49 + 2738)
tree new_rhs = fold_builtin_alloca_with_align (stmt);
5d882cc1dafe (Richard Guenther 2011-09-02 11:53:55 + 2739)
if (new_rhs)
5d882cc1dafe (Richard Guenther 2011-09-02 11:53:55 + 2740) {
52a5515ed661 (Richard Biener 2021-04-14 13:40:58 +0200 2741)
gimplify_and_update_call_from_tree (gsi, new_rhs);
2f31f742a693 (Tom de Vries 2011-12-17 11:39:43 + 2742)
tree var = TREE_OPERAND (TREE_OPERAND (new_rhs, 0),0);
2f31f742a693 (Tom de Vries 2011-12-17 11:39:43 + 2743)
insert_clobbers_for_var (*gsi, var);
5d882cc1dafe (Richard Guenther 2011-09-02 11:53:55 + 2744)
return true;
5d882cc1dafe (Richard Guenther 2011-09-02 11:53:55 + 2745) }
1fed1006552c (Tom de Vries 2011-08-31 07:04:25 + 2746)
}
so at least Tom, Eric and Richard have been in there.
[Bug rtl-optimization/90275] [9 Regression] ICE: in insert_regs, at cse.c:1128 with -O2 -fno-dce -fno-tree-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90275
--- Comment #25 from David Binderman ---
This C source code:
$ more bug761.c
long a;
int b, c, e;
signed char d;
void f() {
long long g = 105230154306549745590;
b = (c ?: (d %= 11 * g)) + (e &= g += c);
a = 5;
for (; a <= 8;) {
g = b != d ? e : g || (5 ? e = 1 : 0);
a %= 0 < 0 / 0;
}
}
pi@raspberrypi:~/creduce $
on recent gcc trunk on ARM and flag -O2, does this:
$ ../gcc/results/bin/arm-linux-gnueabihf-gcc -c -w -O2 bug761.c
during RTL pass: cse_local
bug761.c: In function \u2018f\u2019:
bug761.c:12:1: internal compiler error: in insert_regs, at cse.c:1113
12 | }
| ^
0x16cd73f insert_regs(rtx_def*, table_elt*, int)
../../trunk/gcc/cse.c:1113
0x16c9d9f cse_insn(rtx_insn*)
../../trunk/gcc/cse.c:5926
...
$ ../gcc/results/bin/arm-linux-gnueabihf-gcc -v
Using built-in specs.
COLLECT_GCC=../gcc/results/bin/arm-linux-gnueabihf-gcc
COLLECT_LTO_WRAPPER=/home/pi/gcc/results.20210928/libexec/gcc/arm-linux-gnueabihf/12.0.0/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../trunk/configure --prefix=/home/pi/gcc/results.20210928
--disable-bootstrap --disable-multilib --disable-werror
--with-pkgversion=9cfb95f9b92326e8 --enable-checking=yes
--enable-languages=c,c++,fortran --with-cpu=cortex-a72 --with-fpu=neon-fp-armv8
--with-float=hard --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf
--target=arm-linux-gnueabihf
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210928 (experimental) (9cfb95f9b92326e8)
I don't have a git revision where it works ok. Sorry.
[Bug tree-optimization/102087] [12 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: in determine_exit_conditions, at tree-ssa-loop-manip.c:1049 since r12-3136-g3673dcf6d6baeb67
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102087 --- Comment #15 from David Binderman --- Since this bug depends on the setting of -march, I tried out all the possible legal settings of that value. alderlake amdfam10 during GIMPLE pass: aprefetch athlon-fx during GIMPLE pass: aprefetch athlon64 during GIMPLE pass: aprefetch athlon64-sse3 during GIMPLE pass: aprefetch atom barcelona during GIMPLE pass: aprefetch bdver1 during GIMPLE pass: aprefetch bdver2 during GIMPLE pass: aprefetch bdver3 during GIMPLE pass: aprefetch bdver4 during GIMPLE pass: aprefetch bonnell broadwell btver1 during GIMPLE pass: aprefetch btver2 during GIMPLE pass: aprefetch cannonlake cascadelake cooperlake core-avx-i core-avx2 core2 corei7 corei7-avx eden-x2 during GIMPLE pass: aprefetch eden-x4 during GIMPLE pass: aprefetch goldmont goldmont-plus haswell celake-client icelake-server ivybridge k8 during GIMPLE pass: aprefetch k8-sse3 during GIMPLE pass: aprefetch knl knm nano during GIMPLE pass: aprefetch nano-1000 during GIMPLE pass: aprefetch nano-2000 during GIMPLE pass: aprefetch nano-3000 during GIMPLE pass: aprefetch nano-x2 during GIMPLE pass: aprefetch nano-x4 during GIMPLE pass: aprefetch native during GIMPLE pass: aprefetch nehalem nocona opteron during GIMPLE pass: aprefetch opteron-sse3 during GIMPLE pass: aprefetch rocketlake sandybridge sapphirerapids silvermont skylake skylake-avx512 slm tigerlake tremont westmere x86-64 x86-64-v2 x86-64-v3 x86-64-v4 znver1 znver2 znver3 I generated this list with this command: $ for i in `cat ~/arch.list`; do echo $i; /home/dcb/gcc/results/bin/gcc -c -O3 -march=$i bug760.c 2>&1 | fgrep GIMPLE ; done
[Bug tree-optimization/102087] [12 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: in determine_exit_conditions, at tree-ssa-loop-manip.c:1049 since r12-3136-g3673dcf6d6baeb67
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102087
--- Comment #13 from David Binderman ---
The code in comment 8 still seems to fail:
$ /home/dcb/gcc/results/bin/gcc -c -O3 -w -march=bdver2 bug760.c
bug760.c: In function ‘Gif_ClipImage’:
bug760.c:3:1: error: type mismatch in binary expression
3 | Gif_ClipImage() {
| ^
unsigned int
int
int
_18 = Gif_ClipImage_gfi_1.0_1 + -1;
bug760.c:3:1: error: type mismatch in binary expression
unsigned int
int
int
_12 = Gif_ClipImage_gfi_1.0_1 + -1;
during GIMPLE pass: aprefetch
bug760.c:3:1: internal compiler error: verify_gimple failed
0xdac31a verify_gimple_in_cfg(function*, bool)
../../trunk.git/gcc/tree-cfg.c:5576
$ /home/dcb/gcc/results/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/home/dcb/gcc/results/bin/gcc
COLLECT_LTO_WRAPPER=/home/dcb/gcc/results.20210924/libexec/gcc/x86_64-pc-linux-g
nu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../trunk.git/configure --prefix=/home/dcb/gcc/results.20210924
--disable-bootstrap --disable-multilib --disable-werror
--with-pkgversion=29c928
57039d0a10 --enable-checking=df,extra,fold,rtl,yes
--enable-languages=c,c++,fort
ran
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20210924 (experimental) (29c92857039d0a10)
[Bug tree-optimization/102463] [12 Regression] ice in fold_using_range::relation_fold_and_or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102463 --- Comment #4 from David Binderman --- (In reply to Aldy Hernandez from comment #3) > Could you provide a preprocessed source? ? It already is. It might need a few "int" and "void" to keep modern C compilers happy. I forgot to add the relevant flags to the reduce. Sorry. Current git range is [5d110fe90afcd850..f6ccb788f29ce79a].
[Bug tree-optimization/102463] [12 Regression] ice in fold_using_range::relation_fold_and_or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102463 --- Comment #2 from David Binderman --- (In reply to David Binderman from comment #1) > 142 revisions in the gap, trying 24f99147b9264f8f. Revision looks good, trying f6ccb788f29ce79a, although Aldy seems to be in the frame for this one.
[Bug tree-optimization/102463] [12 Regression] ice in fold_using_range::relation_fold_and_or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102463 --- Comment #1 from David Binderman --- 142 revisions in the gap, trying 24f99147b9264f8f.
[Bug c/102463] New: ice in fold_using_range::relation_fold_and_or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102463
Bug ID: 102463
Summary: ice in fold_using_range::relation_fold_and_or
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For this C code:
_bfd_elf_merge_symbol_h, _bfd_elf_merge_symbol_h_1;
_Bool _bfd_elf_merge_symbol_olddef;
_bfd_elf_merge_symbol() {
_Bool newdef = bfd_is_com_section(), ntdef, tdef;
_bfd_elf_merge_symbol_olddef = _bfd_elf_merge_symbol_h;
if (_bfd_elf_merge_symbol_h_1) {
ntdef = newdef;
tdef = _bfd_elf_merge_symbol_h;
} else {
ntdef = _bfd_elf_merge_symbol_h;
tdef = newdef;
}
if (tdef && ntdef)
;
}
compiled by recent gcc and flag -O2, does this:
during GIMPLE pass: evrp
elflink.c: In function ‘_bfd_elf_merge_symbol’:
elflink.c:15198:1: internal compiler error: Segmentation fault
0xd6a899 crash_signal(int)
../../trunk.git/gcc/toplev.c:328
0x1a73c3c fold_using_range::relation_fold_and_or(irange&, gimple*, fur_source&)
../../trunk.git/gcc/gimple-range-fold.cc:1365
The problem first seems to occur sometime between git hash
947332a4e22aef9b, from last week, and hash 83aac698835edcdb
from yesterday.
[Bug target/102327] gcc/config/i386/i386-expand.c:14678: Suspicious coding ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102327 David Binderman changed: What|Removed |Added CC||liuhongt at gcc dot gnu.org --- Comment #1 from David Binderman --- Adding author for clarification.
[Bug target/102327] New: gcc/config/i386/i386-expand.c:14678: Suspicious coding ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102327 Bug ID: 102327 Summary: gcc/config/i386/i386-expand.c:14678: Suspicious coding ? Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Static analyser cppcheck says: gcc/config/i386/i386-expand.c:14678:8: style: Variable 'op1' is reassigned a value before the old one has been used. [redundantAssignment] Source code is /* Convert HFmode to HImode. */ op1 = gen_reg_rtx (HImode); op1 = gen_rtx_SUBREG (HImode, force_reg (HFmode, op), 0); I don't know the code, but if the return value from gen_reg_rtx isn't needed, then suggest don't assign it into op1.
[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes many crashes in the testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285 --- Comment #6 from David Binderman --- (In reply to qinzhao from comment #5) > with the latest GCC, for all the 42647 c files under gcc/testsuite, with -c > -g -O2 -Wall -ftrivial-auto-var-init=zero, there is only one failure: > /home/opc/Install/latest/bin/gcc -c -g -ftrivial-auto-var-init=zero -O2 > -Wall ./gcc.dg/graphite/pr82421.c > delete -ftrivial-auto-var-init=zero, the failure is gone. > > I will study this one to fix it. Good news. I'll test with -O3 -march=native, and if it passes then the C side of things looks good enough for prime time. I will then test C++ and Fortran in a similar way, and if they pass too, then the new flag looks IMHO ready for other compiler users.
[Bug c/102285] New: New flag -ftrivial-auto-var-init=zero causes many crashes in the testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285 Bug ID: 102285 Summary: New flag -ftrivial-auto-var-init=zero causes many crashes in the testsuite Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- For the C source code under gcc/trunk/gcc/testsuite, I did: $ find . -name \*.c -print | sort > file.c.list $ head file.c.list ./ada/acats/tests/cd/cd300051.c ./ada/acats/tests/cxb/cxb30040.c ./ada/acats/tests/cxb/cxb30060.c ./ada/acats/tests/cxb/cxb30130.c ./ada/acats/tests/cxb/cxb30131.c ./c-c++-common/addrtmp.c ./c-c++-common/array-1.c ./c-c++-common/array-5.c ./c-c++-common/array-6.c ./c-c++-common/array-init.c $ wc -l file.c.list 42647 file.c.list $ So I did a bit of light testing: $ for i in `cat file.c.list`; do echo $i; /home/dcb/gcc/results/bin/gcc -c -g -O2 -Wall -ftrivial-auto-var-init=zero $i; done > 11.out 2>&1 $ Normally, this kind of for loop would produce a small number of crashes. Instead, I get 25 and it's only done about 25% of all the C source code files. $ grep -c "\.c$" 11.out 9184 $ The compiler is built with checking enabled. Here are the first few: $ fgrep "internal compiler error:" 11.out | head ./c-c++-common/dfp/func-vararg-size0.c:16:5: internal compiler error: Segmentation fault ./c-c++-common/dfp/struct-layout-1.c:51:5: internal compiler error: Segmentation fault ./c-c++-common/gomp/reduction-1.c:8:1: internal compiler error: Segmentation fault ./c-c++-common/gomp/udr-1.c:11:1: internal compiler error: Segmentation fault ./c-c++-common/torture/pr46137.c:13:1: internal compiler error: Segmentation fault ./c-c++-common/ubsan/bounds-14.c:6:1: internal compiler error: Segmentation fault ./c-c++-common/Warray-bounds-10.c:63:6: internal compiler error: Segmentation fault ./c-c++-common/Warray-bounds-9.c:12:12: internal compiler error: Segmentation fault ./c-c++-common/Wsizeof-pointer-memaccess1.c:71:1: internal compiler error: Segmentation fault ./c-c++-common/Wsizeof-pointer-memaccess2.c:176:1: internal compiler error: Segmentation fault $ The -ftrivial... flag although a good idea, doesn't look ready for prime time yet. I suggest it is removed and the original code reworked until it doesn't cause any "internal compiler error:" for the C testsuite.
[Bug c++/102281] New: -ftrivial-auto-var-init=zero causes ice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102281
Bug ID: 102281
Summary: -ftrivial-auto-var-init=zero causes ice
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For this C++ code:
long _mm_set_epi64x___q0;
__attribute__((__vector_size__(2 * sizeof(long long long _mm_set_epi64x() {
return (__attribute__((__vector_size__(2 * sizeof(long long long){
_mm_set_epi64x___q0};
}
compiled by recent gcc and compiler flag -ftrivial-auto-var-init=zero,
does this:
$ /home/dcb/gcc/results/bin/gcc -ftrivial-auto-var-init=zero bug756.cc
bug756.cc: In function ‘__vector(2) long long int _mm_set_epi64x()’:
bug756.cc:2:62: error: invalid operand in return statement
2 | _attribute__((__vector_size__(2 * sizeof(long long long
_mm_set_epi64x() {
|
^~
D.2371
return D.2371;
bug756.cc:2:62: internal compiler error: ‘verify_gimple’ failed
0x105dc3a verify_gimple_in_seq(gimple*)
../../trunk.git/gcc/tree-cfg.c:5228
Taking the new flag off causes the code to compile ok:
$ /home/dcb/gcc/results/bin/gcc -c bug756.cc
$
[Bug c++/102243] New: ice in get_range_query
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102243
Bug ID: 102243
Summary: ice in get_range_query
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For this C++ code:
$ more bug755.cc
void *operator new(unsigned long, void *);
class FlagRegisterer {
public:
template < typename FlagType >
FlagRegisterer(char *, char *, char *, FlagType, FlagType);
};
union {
char s[sizeof(int)];
} s_message[2];
int FLAGS_nomessage;
FlagRegisterer o_message("", "", "", &FLAGS_nomessage,
new (s_message[1].s) int);
with recent g++ and *no* optimiser flags, does this:
$ /home/dcb/gcc/results/bin/g++ -c bug755.cc
bug755.cc:12:47: internal compiler error: Segmentation fault
12 | new (s_message[1].s) int);
| ^~~
0x1013819 crash_signal(int)
../../trunk.git/gcc/toplev.c:328
0x12286ff get_range_query(function const*)
../../trunk.git/gcc/function.h:728
Git hash range seems to be 7a6f40d0452ec76e..9695e1c23be5b5c5,
so only 21 commits.
[Bug c/102200] New: ice in put_ref, at pointer-query.cc:1351
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102200
Bug ID: 102200
Summary: ice in put_ref, at pointer-query.cc:1351
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For this C source code:
long try_extension_len;
void try_extension_str() {
char *curr = try_extension_str;
char end = sizeof try_extension_str;
while (try_extension_len) {
if (curr < end)
*curr = ';';
if (curr > &end)
curr = &end;
}
}
compiled with recent gcc trunk and compiler flag -O2, does this:
during GIMPLE pass: strlen
bug754.c: In function ‘try_extension_str’:
bug754.c:2:6: internal compiler error: in put_ref, at pointer-query.cc:1351
2 | void try_extension_str() {
| ^
0xc7696c pointer_query::put_ref(tree_node*, access_ref const&, int)
../../trunk.git/gcc/pointer-query.cc:1351
The bug first seems to occur sometime between git hash 7a6f40d0452ec76e
and 9695e1c23be5b5c5. Only 21 commits.
[Bug c++/64867] split warning for passing non-POD to varargs function from -Wconditionally-supported into new warning flag, -Wnon-pod-varargs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment #30 from David Binderman ---
(In reply to Trass3r from comment #27)
> This should really be enabled by -Wall or -Wextra as it generates code that
> may easily crash or corrupt something.
+1.
Clang errors, intel warns and for gcc you have to enable the somewhat
obscure flag -Wconditionally-supported to see anything at all.
gcc looks to be a trailer on this issue. It's not about standards conformance,
its about making it easy for users to find bugs.
Source code I used is:
struct S
{
S();
S( const S &);
~S();
char * p;
};
void f( int, ...);
void g()
{
S s1;
f( 3, s1);
};
$ /home/dcb/llvm/results/bin/clang++ sep3f.cc
sep3f.cc:19:8: error: cannot pass object of non-trivial type 'S' through
variadic function; call will abort at runtime [-Wnon-pod-varargs]
f( 3, s1);
^
1 error generated.
$ /home/dcb34/intel/oneapi/compiler/2021.3.0/linux/bin/intel64/icpc sep3f.cc
sep3f.cc(19): warning #1595: a class type that is not trivially copyable passed
through ellipsis
f( 3, s1);
^
$ /home/dcb/gcc/results/bin/g++ -c -g -O2 -Wall -Wextra sep3f.cc
$ /home/dcb/gcc/results/bin/g++ -c -g -O2 -Wall -Wextra
-Wconditionally-supported sep3f.cc
sep3f.cc: In function ‘void g()’:
sep3f.cc:19:10: warning: passing objects of non-trivially-copyable type ‘struct
S’ through ‘...’ is conditionally supported [-Wconditionally-supported]
19 | f( 3, s1);
| ~^~~~
I'll add flag -Wconditionally-supported to a build of Fedora and see
what happens.
[Bug c/102172] ice in determine_exit_conditions, at tree-ssa-loop-manip.c:1049
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102172 --- Comment #1 from David Binderman --- That's only 35 revisions, I'll have a go at a git bisect.
[Bug c/102172] New: ice in determine_exit_conditions, at tree-ssa-loop-manip.c:1049
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102172
Bug ID: 102172
Summary: ice in determine_exit_conditions, at
tree-ssa-loop-manip.c:1049
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For this C code:
char **Gif_ClipImage_gfi_0;
int Gif_ClipImage_y, Gif_ClipImage_shift;
void Gif_ClipImage() {
for (; Gif_ClipImage_y >= Gif_ClipImage_shift; Gif_ClipImage_y++)
Gif_ClipImage_gfi_0[Gif_ClipImage_shift] =
Gif_ClipImage_gfi_0[Gif_ClipImage_y];
}
compiled by recent gcc trunk and compiler flag -O3 -march=bdver2,
does this:
$ /home/dcb/gcc/results/bin/gcc -c -O3 -march=bdver2 bug753.c
during GIMPLE pass: aprefetch
bug753.c: In function ‘Gif_ClipImage’:
bug753.c:3:6: internal compiler error: in determine_exit_conditions, at
tree-ssa-loop-manip.c:1049
3 | void Gif_ClipImage() {
| ^
0xf070ff determine_exit_conditions(loop*, tree_niter_desc*, unsigned int,
tree_node**, tree_node**, tree_node**, tree_code*, tree_node**)
../../trunk.git/gcc/tree-ssa-loop-manip.c:1049
0xf070ff tree_transform_and_unroll_loop(loop*, unsigned int, edge_def*,
tree_niter_desc*, void (*)(loop*, void*), void*)
The bug first starts sometime between git hash f8977166135de09f,
dated 20210824 and git hash 3ac6b5cff1eca4e1, dated 20210825.
[Bug ada/102078] affinity.c:59:19: error: Signed integer overflow ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102078 --- Comment #6 from David Binderman --- (In reply to David Binderman from comment #4) > Full cppcheck error message is > > gcc/ada/affinity.c:59:19: error: Signed integer overflow for expression > '1< > I think cppcheck is worried if index runs up to 64, i.e. when sizeof( > unsigned) > is 8, hence my suggestion. > > AFAIK, 1 << 31 loses the sign bit and so cppcheck likes to grumble, but > I've long since forgotten if it is actually UB or not. Changing the 1 to 1UL seems to shut up cppcheck, so it looks like a 32/64 bit issue. I guess there are some machines where unsigned int is 64 bit.
[Bug ada/102078] affinity.c:59:19: error: Signed integer overflow ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102078 --- Comment #4 from David Binderman --- Full cppcheck error message is gcc/ada/affinity.c:59:19: error: Signed integer overflow for expression '1<
[Bug c/102118] New: ice in merge, at ipa-modref-tree.h:203
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102118
Bug ID: 102118
Summary: ice in merge, at ipa-modref-tree.h:203
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For this C code:
typedef struct {
int large_page_addr;
long n_used_entries
} CPUTLBDesc;
typedef struct {
long mask
} CPUTLBDescFast;
typedef struct {
CPUTLBDesc d[8];
CPUTLBDescFast f[]
} CPUTLB;
typedef int RISCVCPU;
CPUTLB *tlb_flush_page_bits_locked___trans_tmp_8,
*tlb_flush_page_bits_locked___trans_tmp_6,
*tlb_flush_page_bits_locked___trans_tmp_4;
void tlb_flush_page_bits_locked(int *env, int midx) {
{
int *__trans_tmp_5 = env;
{
RISCVCPU *arch_cpu = __trans_tmp_5;
tlb_flush_page_bits_locked___trans_tmp_4 = arch_cpu;
}
}
CPUTLBDesc *d = &tlb_flush_page_bits_locked___trans_tmp_4->d[midx];
{
int *__trans_tmp_7 = env;
{
RISCVCPU *arch_cpu = __trans_tmp_7;
tlb_flush_page_bits_locked___trans_tmp_6 = arch_cpu;
}
}
if (tlb_flush_page_bits_locked___trans_tmp_6->f[midx].mask)
if (d->large_page_addr) {
int *__trans_tmp_3 = env;
{
{
RISCVCPU *arch_cpu = __trans_tmp_3;
tlb_flush_page_bits_locked___trans_tmp_8 = arch_cpu;
}
tlb_flush_page_bits_locked___trans_tmp_8->d[midx].n_used_entries--;
}
}
}
compiled by recent gcc trunk and compiler flag -O1, does this:
during GIMPLE pass: modref
bug752.c: In function ‘tlb_flush_page_bits_locked’:
bug752.c:43:1: internal compiler error: in merge, at ipa-modref-tree.h:203
43 | }
| ^
0xae7448 modref_access_node::merge(modref_access_node const&, bool)
../../trunk.git/gcc/ipa-modref-tree.h:203
The code was fine at git hash 3ac6b5cff1eca4e1 and broken at hash
e28ac73af20028f8
[Bug tree-optimization/102087] [12 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: in determine_exit_conditions, at tree-ssa-loop-manip.c:1049 since r12-3136-g3673dcf6d6baeb67
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102087
--- Comment #9 from David Binderman ---
This second source code generates a similar but different error message:
void dnslabel_vector_dnslabel_to_dnsname_namestack(int bottom) {
char **name;
int top;
while (bottom <= top) {
char label = *name++;
memcpy(0, label, label);
bottom--;
}
}
internal compiler error: in determine_exit_conditions, at
tree-ssa-loop-manip.c:1045
Some four lines different place in the compiler source code to the original.
[Bug tree-optimization/102087] [12 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: in determine_exit_conditions, at tree-ssa-loop-manip.c:1049 since r12-3136-g3673dcf6d6baeb67
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102087
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment #8 from David Binderman ---
I see this problem also, with this reduced C code:
char **Gif_ClipImage_gfi_0;
int Gif_ClipImage_y, Gif_ClipImage_shift;
void Gif_ClipImage(void) {
for (; Gif_ClipImage_y >= Gif_ClipImage_shift; Gif_ClipImage_y++)
Gif_ClipImage_gfi_0[Gif_ClipImage_shift] =
Gif_ClipImage_gfi_0[Gif_ClipImage_y];
}
Flag -O3 -march=bdver2 required.
[Bug sanitizer/102085] New: libsanitizer/asan/asan_errors.cpp:387: declaration and definition do not match ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102085 Bug ID: 102085 Summary: libsanitizer/asan/asan_errors.cpp:387: declaration and definition do not match ? Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- libsanitizer/asan/asan_errors.cpp:387:32: warning: Function 'ErrorGeneric' argument order different: declaration 'tid, addr, pc_, bp_, sp_, is_write_, access_size_' definition 'tid, pc_, bp_, sp_, addr, is_write_, access_size_' [funcArgOrderDifferent] Another small problem found by static analyser cppcheck.
[Bug ipa/102081] [12 regression] ICE building compiler starting with r12-3159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102081
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment #2 from David Binderman ---
Might be related:
during GIMPLE pass: modref
bug749.c: In function ‘CopyMatrix3D’:
bug749.c:4:6: internal compiler error: in verify, at ipa-modref-tree.h:335
For this C source code and compiler flag -O3:
typedef double Matrix3D[][3];
Matrix3D *CopyMatrix3D_dest;
int CopyMatrix3D_x;
void CopyMatrix3D(Matrix3D *src) {
int y;
CopyMatrix3D_x = 0;
for (; CopyMatrix3D_x < 3; ++CopyMatrix3D_x) {
y = 0;
for (; y < 3; ++y)
(*CopyMatrix3D_dest)[CopyMatrix3D_x][y] = (*src)[CopyMatrix3D_x][y];
}
}
[Bug other/102083] New: libiberty/simple-object-xcoff.c:844: pointless test and assignment ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102083 Bug ID: 102083 Summary: libiberty/simple-object-xcoff.c:844: pointless test and assignment ? Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- libiberty/simple-object-xcoff.c:844:5: style: Assignment of function parameter has no effect outside the function. [uselessAssignmentArg] Source code is if (align > 13) align = 13; if (u64) set_32 (hdr + offsetof (struct external_scnhdr, u.xcoff64.s_flags), flags); else set_32 (hdr + offsetof (struct external_scnhdr, u.xcoff32.s_flags), flags); return simple_object_internal_write (descriptor, scnhdr_offset, hdrbuf, u64 ? SCNHSZ64 : SCNHSZ32, errmsg, err); } Suggest remove test and set of align, since they are not used in the rest of the function.
[Bug libgomp/102082] New: minor: 2 * pointless assignment to function parameters ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102082 Bug ID: 102082 Summary: minor: 2 * pointless assignment to function parameters ? Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com CC: jakub at gcc dot gnu.org Target Milestone: --- 1. libgomp/loop.c:627:7: style: Assignment of function parameter has no effect outside the function. [uselessAssignmentArg] Source code is sched = thr->ts.work_share->sched; But sched is unused in the remainder of the function. Suggest delete dead assignment. 2. libgomp/loop_ull.c:633:7: style: Assignment of function parameter has no effect outside the function. [uselessAssignmentArg] Duplicate.
[Bug ada/102078] New: ffinity.c:59:19: error: Signed integer overflow ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102078 Bug ID: 102078 Summary: ffinity.c:59:19: error: Signed integer overflow ? Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Source code is for (index = 0; index < sizeof (unsigned) * 8; index++) if (mask & (1 << index)) CPUSET_SET(cpuset, index); maybe better code: for (index = 0; index < sizeof (unsigned) * 8; index++) if (mask & (1UL << index)) CPUSET_SET(cpuset, index);
[Bug libstdc++/102074] New: include/bits/atomic_timed_wait.h:215: possible missing return ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102074
Bug ID: 102074
Summary: include/bits/atomic_timed_wait.h:215: possible missing
return ?
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
libstdc++-v3/include/bits/atomic_timed_wait.h:215:6: error: Found a exit path
from function with non-void return type that has missing return statement
[missingReturn]
Source code is
{
#ifdef _GLIBCXX_HAVE_PLATFORM_TIMED_WAIT
return __platform_wait_until(__addr, __old, __atime);
#else
__platform_wait_t __val;
__atomic_load(__addr, &__val, __ATOMIC_RELAXED);
if (__val == __old)
{
lock_guard __l(_M_mtx);
return __cond_wait_until(_M_cv, _M_mtx, __atime);
}
#endif // _GLIBCXX_HAVE_PLATFORM_TIMED_WAIT
}
I see no code for __val != __old, not even some rarely executed error handling
code.
Static analyser cppcheck found this possible problem.
[Bug ada/102073] New: gcc/ada/socket.c: 2 * missing return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102073 Bug ID: 102073 Summary: gcc/ada/socket.c: 2 * missing return Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- 1. trunk.git/gcc/ada/socket.c:308:3: error: Found a exit path from function with non-void return type that has missing return statement [missingReturn] Source code is ret->h_length= 4; ret->h_addr_list = &vxw_h_addr_list; } 2. gcc/ada/socket.c:540:7: error: Found a exit path from function with non-void return type that has missing return statement [missingReturn] Source code is } #if defined (__vxworks) return (inet_aton (src, dst) == OK); Seemingly, if __vxworks, _WIN32, __hpux__ are all not defined then fall through occurs. Thanks to cppcheck for finding these two.
[Bug c/102029] New: ice: error: type mismatch in ‘lshift_expr’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102029
Bug ID: 102029
Summary: ice: error: type mismatch in ‘lshift_expr’
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For this C code:
$ more bug743.c
const long fmpz_neg_f2;
void qfb_reduce(void) { __gmpz_neg((int *)(fmpz_neg_f2 << 2)); }
$
Recent gcc trunk does this:
$ /home/dcb/gcc/results.20210823/bin/gcc -c -O2 bug743.c
bug743.c: In function ‘qfb_reduce’:
bug743.c:2:25: warning: implicit declaration of function ‘__gmpz_neg’
[-Wimplici
t-function-declaration]
2 | void qfb_reduce(void) { __gmpz_neg((int *)(fmpz_neg_f2 << 2)); }
| ^~
bug743.c:2:6: error: type mismatch in ‘lshift_expr’
2 | void qfb_reduce(void) { __gmpz_neg((int *)(fmpz_neg_f2 << 2)); }
| ^~
int *
int *
int
_3 = fmpz_neg_f2.1_2 << 2;
bug743.c:2:6: internal compiler error: ‘verify_gimple’ failed
0xd9532a verify_gimple_in_seq(gimple*)
../../trunk.git/gcc/tree-cfg.c:5183
The problem first seems to appear sometime between git hash
e92d0ff6b5e6d4b9 and 38757aa88735ab2e, about 40 commits.
[Bug target/101505] [10/11 Regression] ICE: verify_gimple failed (error: incompatible types in 'PHI' argument 0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101505 --- Comment #8 from David Binderman --- (In reply to Richard Biener from comment #7) > This is a different bug though, probably caused by HJs changes, looks like > the fixed PR101742, indeed updating and re-building my dev tree makes the > issue go away. Indeed it does. Today's gcc is fine. My apologies for my error.
[Bug target/101505] [10/11 Regression] ICE: verify_gimple failed (error: incompatible types in 'PHI' argument 0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101505 --- Comment #6 from David Binderman --- Further research suggests it also crashes with amdfam10, athlon-fx, athlon64, athlon64-sse3, barcelona, bdver1, bdver3, bdver4, btver1, btver2, eden-x2, eden-x4, k8, k8-sse3, nano, nano-1000, nano-2000, nano-3000, nano-x2, nano-x4, opteron, opteron-sse3. 23 in total.
[Bug target/101505] [10/11 Regression] ICE: verify_gimple failed (error: incompatible types in 'PHI' argument 0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101505 David Binderman changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #5 from David Binderman --- Certainly works for -O3, but doesn't for -O3 -march=bdver2. during RTL pass: expand ./gcc.dg/vect/pr101505.c: In function ‘w7.simdclone.6’: ./gcc.dg/vect/pr101505.c:15:10: internal compiler error: in expand_mult, at expm ed.c:3585 15 | return xb; | ^~ 0x91344a expand_mult(machine_mode, rtx_def*, rtx_def*, rtx_def*, int, bool) ../../trunk.git/gcc/expmed.c:3585 It breaks sometime between git hash 145bc41dae7c7bfa and 14d8a5ae472ca574
[Bug middle-end/101720] compile time hog with -g -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101720 --- Comment #7 from David Binderman --- (In reply to Richard Biener from comment #4) > I suppose this isn't a recent regression of some sorts? Doubtful. I tried the system C++ compiler and got this: $ time /usr/bin/g++ -c -O2 -g bug741.cc real4m58.914s user4m47.745s sys 0m5.847s $ /usr/bin/g++ -v ... gcc version 11.1.1 20210531 (Red Hat 11.1.1-3) (GCC) So current development compiler is only taking about 20 seconds longer than a compiler from two months ago. Interestingly, I tried the -fno-var-tracking-assignments flag and got this: $ time /home/dcb/gcc/results.20210731.release/bin/g++ -g -O2 -c -fno-var-tracking-assignments bug741.cc real4m0.013s user3m53.771s sys 0m4.245s So about a 24 % time reduction. Still a long time though. Changing the -O2 to -O1 got this: $ time /home/dcb/gcc/results.20210731.release/bin/g++ -g -O1 -c -fno-var-tracking-assignments bug741.cc real2m43.303s user2m38.399s sys 0m3.796s which gives a 49 % reduction. So it looks to me like anything that takes a long time to compile, then we have a couple of workarounds (use -fno-var-tracking-assignments, use -O1 instead of -O2).
[Bug c++/101720] compile time hog with -g -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101720 --- Comment #3 from David Binderman --- Created attachment 51240 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51240&action=edit gzipped C source code
[Bug c++/101720] compile time hog with -g -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101720 --- Comment #2 from David Binderman --- I have another C test case which seems to take a long time when -g is switched on: $ time /home/dcb/gcc/results.20210731.release/bin/gcc -c -O2 bug742.c real1m45.778s user1m40.487s sys 0m0.954s $ time /home/dcb/gcc/results.20210731.release/bin/gcc -c -O2 -g bug742.c real8m40.157s user8m24.941s sys 0m3.953s
[Bug c++/101720] compile time hog with -g -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101720 --- Comment #1 from David Binderman --- Strangely, changing the -O2 to -O3 and dropping the -g changes the time to 3 minutes 49 seconds, so -g looks to be the culprit. The source code is 5.9 Megs, the gcc build is a release build and the test machine runs at 4.1GHz, so not a slow machine.
[Bug c++/101720] New: compile time hog with -g -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101720 Bug ID: 101720 Summary: compile time hog with -g -O2 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 51239 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51239&action=edit gzipped C++ source code The attached C++ code takes a suspiciously long time with flags -g -O2. $ time ../results.20210731.release/bin/gcc -c -O2 -g bug741.cc real5m24.015s user5m9.055s sys 0m7.148s
[Bug c/101642] ice in decompose, at wide-int.h:984
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101642 --- Comment #4 from David Binderman --- (In reply to David Binderman from comment #3) > In a git bisect, trying cf5f544227f16b63 Seems bad, so trying 1ab2270036dc0f2a.
[Bug c/101642] ice in decompose, at wide-int.h:984
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101642 --- Comment #3 from David Binderman --- In a git bisect, trying cf5f544227f16b63
[Bug c/101642] ice in decompose, at wide-int.h:984
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101642
--- Comment #2 from David Binderman ---
Reduced code seems to be
short __bswap_16___bsx, Process_v1___trans_tmp_1;
int Process_v1_common_record;
char Process_v1_s2;
void Process_v1(void) {
Process_v1___trans_tmp_1 = __builtin_bswap16(__bswap_16___bsx);
if (Process_v1___trans_tmp_1)
Process_v1_s2 = Process_v1_common_record;
}
[Bug c/101642] ice in decompose, at wide-int.h:984
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101642 --- Comment #1 from David Binderman --- Problem first seems to occur sometime between git hash ead235f60139edc6, dated 20210724 and git hash fcc7c6369f7fbf29, dated today.
[Bug c/101642] New: ice in decompose, at wide-int.h:984
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101642 Bug ID: 101642 Summary: ice in decompose, at wide-int.h:984 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 51210 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51210&action=edit C source code The attached C code does this with recent gcc: $ ../results/bin/gcc -c -O2 bug740.c during GIMPLE pass: fre netflow_v1.c: In function ‘Process_v1’: netflow_v1.c:507:1: internal compiler error: in decompose, at wide-int.h:984 0x139979c wi::int_traits >::decompose(long*, unsigned int, generic_wide_int const&) ../../trunk.git/gcc/wide-int.h:984 0x139979c wide_int_ref_storage::wide_int_ref_storage >(generic_wide_int const&, unsigned int) ../../trunk.git/gcc/wide-int.h:1034 0x139979c generic_wide_int >::generic_wide_int >(generic_wide_int const&, unsigned int) ../../trunk.git/gcc/wide-int.h:790 I will have my usual go at reducing the code and trying to spot a range of git hashes where the problem first occurs.
[Bug tree-optimization/101511] [12 Regression] ice in query_relation, at value-relation.cc:879
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101511 --- Comment #2 from David Binderman --- I've had a go at a git bisect, but couldn't produce any sensible answers ;-< Richard seems to think Andrew MacLeod may be helpful, so I am happy to go with that. For the git range I suggested, commits 4c85ff754927c518ed97da5e0221eeea742c9aa7, a03e944e92ee51ae583382079d4739b64bd93b35, ca4d381662c37733b2a1d49d6c8f5fcfc1348f3d and 9d674b735f22aa9cf85629851783ce38f25087b5 are by Andrew.
[Bug c++/101511] ice in query_relation, at value-relation.cc:879
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101511
--- Comment #1 from David Binderman ---
Reduced C++ code seems to be:
void __assert_fail(char *, char *, int, const char *)
__attribute__((__noreturn__));
template void test_uint() {
long __trans_tmp_3, __trans_tmp_1;
int Error;
for (;;) {
{
unsigned long Tmp = -1;
__trans_tmp_3 = Tmp - Tmp % 0;
}
Error += 0 == __trans_tmp_3 ? 0 : 1;
!Error ? void() : __assert_fail("", "", 3, __PRETTY_FUNCTION__);
T Tmp = -1;
__trans_tmp_1 = Tmp - Tmp % 0;
Error += 0 == __trans_tmp_1 ? 0 : 1;
!Error ? void() : __assert_fail("", "", 7, __PRETTY_FUNCTION__);
}
}
void test() { test_uint(); }
[Bug c++/101511] New: ice in query_relation, at value-relation.cc:879
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101511 Bug ID: 101511 Summary: ice in query_relation, at value-relation.cc:879 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 51171 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51171&action=edit gzipped C++ source code The attached C++ code does this with recent gcc: $ /home/dcb/gcc/results/bin/gcc -c -O2 -w bug739.cc during GIMPLE pass: evrp /home/dcb34/rpmbuild/BUILD/glm-0.9.9.8/test/ext/ext_scalar_integer.cpp: In funct ion ‘int nextMultiple::test_uint() [with T = unsigned int]’: /home/dcb34/rpmbuild/BUILD/glm-0.9.9.8/test/ext/ext_scalar_integer.cpp:677:1: in ternal compiler error: in query_relation, at value-relation.cc:879 677 | } | ^ 0x8caf23 relation_oracle::query_relation(basic_block_def*, tree_node*, tree_node *) ../../trunk.git/gcc/value-relation.cc:879 0x15ec545 range_query::query_relation(gimple*, tree_node*, tree_node*, bool) ../../trunk.git/gcc/value-query.cc:475 The bug first seems to occur sometime between git hash b4e21c80462682c4 and 7dcf139a2b8e1c53 I will have my usual go at reducing the code and I might even have a go at finding the git revision that causes the problem.
[Bug target/101507] New: ice for gcc.dg/Wstringop-overflow-69.c with -march=iwmmxt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101507 Bug ID: 101507 Summary: ice for gcc.dg/Wstringop-overflow-69.c with -march=iwmmxt Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- For gcc testsuite file ./gcc.dg/Wstringop-overflow-69.c, it compiles happily with march=armv8.6-a and many other settings, but isn't happy with -march=iwmmxt $ /home/dcb/raspberrypi/results/bin/arm-linux-gnueabihf-gcc -c -w -march=iwmmxt ./gcc.dg/Wstringop-overflow-69.c during RTL pass: reload ./gcc.dg/Wstringop-overflow-69.c: In function ‘warn_vec_func’: ./gcc.dg/Wstringop-overflow-69.c:84:1: internal compiler error: maximum number of generated reload insns per insn achieved (90) 84 | } | ^ 0xd7d3aa lra_constraints(bool) /home/dcb/gcc/trunk.git/gcc/lra-constraints.c:5091 This looks to me like some internal buffer overflow.
[Bug tree-optimization/101497] [12 Regression] ice in type, at value-range.h:221
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101497 David Binderman changed: What|Removed |Added CC||amacleod at redhat dot com --- Comment #4 from David Binderman --- Range seems to be [33255ad3ac14e395, c031ea2782a1873e], so this looks like another one for Andrew Macleod.
[Bug tree-optimization/101497] [12 Regression] ice in type, at value-range.h:221
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101497 --- Comment #3 from David Binderman --- (In reply to David Binderman from comment #2) > (In reply to Andrew Pinski from comment #1) > > (In reply to David Binderman from comment #0) > > > Bug first seems to occur sometime between git hash 7466a0a5d8d536ab > > > and 94ba897be8b59ef5 > > > > So between r12-2235 and r12-2372. > > About 68 revisions, so trying revision 269ca408e2839d7f. Seems good, so trying 33255ad3ac14e395.
[Bug tree-optimization/101497] [12 Regression] ice in type, at value-range.h:221
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101497 --- Comment #2 from David Binderman --- (In reply to Andrew Pinski from comment #1) > (In reply to David Binderman from comment #0) > > Bug first seems to occur sometime between git hash 7466a0a5d8d536ab > > and 94ba897be8b59ef5 > > So between r12-2235 and r12-2372. About 68 revisions, so trying revision 269ca408e2839d7f.
[Bug tree-optimization/101496] [12 Regression] ice during GIMPLE pass: evrp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101496 David Binderman changed: What|Removed |Added CC||amacleod at redhat dot com --- Comment #5 from David Binderman --- (In reply to David Binderman from comment #4) > (In reply to David Binderman from comment #3) > > (In reply to David Binderman from comment #2) > > > (In reply to Andrew Pinski from comment #1) > > > > (In reply to David Binderman from comment #0) > > > > > Bug first seems to occur sometime after git hash 42ff474e28fa3c85 > > > > > but before cca7eb8f7cc157ed. > > > > > > > > So between r12-1856 and r12-1917. > > > > > > There are about 61 revisions, so git bisect offers 32638d4975f2768b > > > for testing. > > > > Seems good, so trying ba4b83c3e3bd8a85e3771b91ae39421d9dd7 > > Seems good, so trying 0c06e46a81d86d70 Bug seems to be between a7e655ae4016eaf04e261ff32fc67a14ebb0e329 and cca7eb8f7cc157ed1b351cbaa10a4066f8065c3a. Andrew Macleod is the author of three of those four revisions, so adding this person for additional comment.
[Bug tree-optimization/101496] [12 Regression] ice during GIMPLE pass: evrp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101496 --- Comment #4 from David Binderman --- (In reply to David Binderman from comment #3) > (In reply to David Binderman from comment #2) > > (In reply to Andrew Pinski from comment #1) > > > (In reply to David Binderman from comment #0) > > > > Bug first seems to occur sometime after git hash 42ff474e28fa3c85 > > > > but before cca7eb8f7cc157ed. > > > > > > So between r12-1856 and r12-1917. > > > > There are about 61 revisions, so git bisect offers 32638d4975f2768b > > for testing. > > Seems good, so trying ba4b83c3e3bd8a85e3771b91ae39421d9dd7 Seems good, so trying 0c06e46a81d86d70
[Bug tree-optimization/101496] [12 Regression] ice during GIMPLE pass: evrp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101496 --- Comment #3 from David Binderman --- (In reply to David Binderman from comment #2) > (In reply to Andrew Pinski from comment #1) > > (In reply to David Binderman from comment #0) > > > Bug first seems to occur sometime after git hash 42ff474e28fa3c85 > > > but before cca7eb8f7cc157ed. > > > > So between r12-1856 and r12-1917. > > There are about 61 revisions, so git bisect offers 32638d4975f2768b > for testing. Seems good, so trying ba4b83c3e3bd8a85e3771b91ae39421d9dd7
