[Bug modula2/110125] Variables are reported as uninitialized when only set inside WITH statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110125 Gaius Mulley changed: What|Removed |Added CC||gaius at gcc dot gnu.org --- Comment #3 from Gaius Mulley --- Created attachment 55357 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55357=edit Proposed fix Thanks for the bug report - here is a work in progress patch.
[Bug target/110264] internal compiler error: riscv_vector::vector_insn_info::get_avl_reg_rtx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110264 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2023-06-17 Ever confirmed|0 |1 CC||law at gcc dot gnu.org --- Comment #5 from Jeffrey A. Law --- Note that Pan can cherry pick it into gcc-13. Typically folks wait a week or so after the patch is on the trunk to see if there's any fallout. Given that I don't expect gcc-13.2 until late summer, we've certainly got time.
[Bug middle-end/110228] [13/14 Regression] llvm-16 miscompiled due to an maybe uninitialized and optimizations saying that the uninitialized has a nonzero bits of 1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228
Andrew Pinski changed:
What|Removed |Added
Summary|[14 Regression] llvm-16 |[13/14 Regression] llvm-16
|miscompiled due to an maybe |miscompiled due to an maybe
|uninitialized and |uninitialized and
|optimizations saying that |optimizations saying that
|the uninitialized has a |the uninitialized has a
|nonzero bits of 1. |nonzero bits of 1.
Target Milestone|14.0|13.2
--- Comment #16 from Andrew Pinski ---
here is a (x86_64 as it requires the inline-asm to force an undefined value
inside LookupFlags but LookupFlags is not used until the next iteration)
program which we have been miscompiling -O2 since r13-4459-g6508d5e5a1a8:
```
unsigned a[4] = {1,1,1,1};
unsigned tt1 = 0;
__attribute__((noipa))
static void bug(unsigned & p, unsigned *t, int n, int t2) {
for(int i = 0; i < n; i++) {
bool LookupFlags ;
unsigned v = t[i];
unsigned tt = tt1;
if (v == 0)
LookupFlags = 0;
else if (v == 1)
LookupFlags = 1;
if (LookupFlags) {
tt|=3u;
LookupFlags = 0;
}
asm("movq $-1, %q1":"+a"(LookupFlags));
p = tt;
}
}
int main() {
unsigned r = 42;
bug(r,a, sizeof(a)/sizeof(a[0]), 1);
__builtin_printf("%u\n", r);
if (r != 3) __builtin_abort();
}
```
Yes it is a bit odd but that was the only way I could get the code added in
r13-4459-g6508d5e5a1a8 to be invoked and even have LookupFlags|=v==1 happening
and get what could get undefined behavior in the loop.
[Bug modula2/110284] [14 Regression] Bootstrap failures with m2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110284 Gaius Mulley changed: What|Removed |Added Last reconfirmed||2023-06-17 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Gaius Mulley --- Certainly - will investigate - thanks for the diagnosis.
[Bug middle-end/110228] [14 Regression] llvm-16 miscompiled due to an maybe uninitialized and optimizations saying that the uninitialized has a nonzero bits of 1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #15 from Jakub Jelinek --- (In reply to Andrew Pinski from comment #13) > has undefined behavior in it? Right now we remove the whole `!= 0` if we use > with -O2. Yes, it is UB. You'd need first array element of 0 to make it valid.
[Bug middle-end/110228] [14 Regression] llvm-16 miscompiled due to an maybe uninitialized and optimizations saying that the uninitialized has a nonzero bits of 1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228 --- Comment #14 from Sergei Trofimovich --- > LookupFlags = LookupFlags | t; That makes `LookupFlags` to guarantee to contain uninitialized bits. Did you mean `LookupFlags = t;`?
[Bug middle-end/110228] [14 Regression] llvm-16 miscompiled due to an maybe uninitialized and optimizations saying that the uninitialized has a nonzero bits of 1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228
--- Comment #13 from Andrew Pinski ---
The big question is this code here:
```
unsigned a[4] = {1,1,1,1};
__attribute__((noipa))
void sink(int){}
__attribute__((noipa))
static void bug(unsigned & p, unsigned *t, int n) {
bool LookupFlags ;
for(int i = 0; i < n; i++) {
unsigned v = t[i];
if (v == 0)
LookupFlags = 0;
else {
bool t = v == 1;
LookupFlags = LookupFlags | t;
}
sink(LookupFlags);
p = LookupFlags;
}
}
int main() {
unsigned r = 42;
bug(r,a, sizeof(a)/sizeof(a[0]));
__builtin_printf("%u\n", r);
if (r != 1) __builtin_abort();
}
```
has undefined behavior in it? Right now we remove the whole `!= 0` if we use
with -O2.
[Bug fortran/92887] [F2008] Passing nullified/disassociated pointer or unalloc allocatable to OPTIONAL + VALUE dummy fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92887
--- Comment #3 from anlauf at gcc dot gnu.org ---
When using the tentative patch
https://gcc.gnu.org/bugzilla/attachment.cgi?id=55333
and adding a hackish
else if (e && fsym && fsym->attr.value && e->expr_type == EXPR_VARIABLE)
{
parmse.expr = gfc_evaluate_now (parmse.expr, );
}
I see a temporary generated for the integer arguments, but not for the
character variable.
The above hackish addition is even not yet correct: we must not dereference
a disassociated pointer when copying to the temporary ...
[Bug fortran/92887] [F2008] Passing nullified/disassociated pointer or unalloc allocatable to OPTIONAL + VALUE dummy fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92887 --- Comment #2 from anlauf at gcc dot gnu.org --- Created attachment 55356 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55356=edit Partial patch for the presence attribute The attached patch generates a test for the presence that depends on the allocation or association status of the argument. An extended testcase however shows that we mishandle the VALUE attribute: we do not generate a proper temporary: program p implicit none (type, external) integer, allocatable :: aa integer, pointer :: pp character,allocatable :: ca character,pointer :: cp nullify (pp, cp) call sub (aa, pp, ca, cp) allocate (aa, pp, ca, cp) aa = 1; pp = 2; ca = "a"; cp = "b" call foo (3, 4, "a", "b") call foo (aa, pp, ca, cp) call bar (5, 6, "c", "d") call bar (aa, pp, ca, cp) call bla (7, 8, "e", "f") call bla (aa, pp, ca, cp) deallocate (aa, pp, ca, cp) contains subroutine sub (x, y, c, d) integer, value, optional :: x, y character, value, optional :: c, d if (present(x)) stop 1 if (present(y)) stop 2 if (present(c)) stop 3 if (present(d)) stop 4 end subroutine foo (x, y, c, d) integer, value, optional :: x, y character, value, optional :: c, d if (.not. present(x)) stop 1 if (.not. present(y)) stop 2 if (.not. present(c)) stop 3 if (.not. present(d)) stop 4 print *, "value+optional:", x, y, c, d end subroutine bar (x, y, c, d) integer, value :: x, y character, value :: c, d print *, "value :", x, y, c, d end subroutine bla (x, y, c, d) integer :: x, y character :: c, d print *, "no value :", x, y, c, d end end Executing this testcase shows junk for the character variable, and inspection of the tree dump shows that this is not limited to it...
[Bug c++/110295] [10/11/12/13/14 Regression] ICE in dwarf2out_finish with local class with inherited operator delete in a templated function and -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110295
Andrew Pinski changed:
What|Removed |Added
Summary|internal compiler error: in |[10/11/12/13/14 Regression]
|dwarf2out_finish|ICE in dwarf2out_finish
||with local class with
||inherited operator delete
||in a templated function and
||-g
Target Milestone|--- |10.5
Ever confirmed|0 |1
Known to work||5.1.0, 5.5.0
Known to fail||10.1.0, 6.1.0, 7.1.0
Status|UNCONFIRMED |NEW
Keywords||ice-on-valid-code
Last reconfirmed||2023-06-17
--- Comment #2 from Andrew Pinski ---
Reduced testcase:
```
template
struct QCachedT
{
void operator delete(void *, T *) {}
};
template
void exercise()
{
struct thing_t
: QCachedT
{
};
thing_t *list[1];
new thing_t;
}
int main() { exercise<1>(); }
```
Note exercise needs to be templated and so does QCachedT.
My guess is thing_t that is for the operator delete is not be subsituted
correctly for the new class when instantiating exercise; it works ok without -g
but when trying to emit debug info, it crashes not knowing the class.
[Bug c++/110295] internal compiler error: in dwarf2out_finish
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110295 Andrew Pinski changed: What|Removed |Added Known to fail||14.0 --- Comment #1 from Andrew Pinski --- Reducing ...
[Bug tree-optimization/110298] [10/11/12/13/14 Regression] ICE at -Os on x86_64-linux-gnu since r10-840
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110298 --- Comment #2 from Andrew Pinski --- loop->nb_iterations still includes reference to a removed SSA name ...
[Bug tree-optimization/110298] [10/11/12/13/14 Regression] ICE at -Os on x86_64-linux-gnu since r10-840
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110298 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |10.5 Keywords||ice-on-valid-code Component|c |tree-optimization
[Bug target/54089] [SH] Refactor shift patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089 --- Comment #82 from Alexander Klepikov --- I have read the docs and other targets' code, and the puzzle finally came together. A struct with additional current function context is a really good idea! I'll implement it in a couple of days.
[Bug middle-end/110228] [14 Regression] llvm-16 miscompiled due to an maybe uninitialized and optimizations saying that the uninitialized has a nonzero bits of 1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228 --- Comment #12 from Andrew Pinski --- I should note my reduced testcase does not even need the ranger to tell me that the range is [0,1] because it uses a bool which has a PRECISION of 1. If an expand solution is not implemented in a few months, I will submit a patch which disables the `bit_ior` case and leave a comment there on referencing PR 71762 and this bug.
[Bug fortran/110033] rejects-valid: associate name corresponding to coarray selector should be considered a coarray
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110033 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org Blocks||87477 --- Comment #3 from Paul Thomas --- I'm onto it :-) Paul Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87477 [Bug 87477] [meta-bug] [F03] issues concerning the ASSOCIATE statement
[Bug fortran/110224] Rejects valid: function reference with data pointer result as lhs in assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110224 Paul Thomas changed: What|Removed |Added Blocks||87477 --- Comment #2 from Paul Thomas --- OK - I'm onto it :-) Paul Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87477 [Bug 87477] [meta-bug] [F03] issues concerning the ASSOCIATE statement
[Bug middle-end/79173] add-with-carry and subtract-with-borrow support (x86_64 and others)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79173 --- Comment #24 from Jakub Jelinek --- Sorry, in that case nothing needs to be done for riscv. I'm sure aarch64, arm has one (e.g. adcs), I think powerpc has some, but e.g. PR43892 is still open, and I'm sure s390 has them too (alc*, slb*).
[Bug middle-end/79173] add-with-carry and subtract-with-borrow support (x86_64 and others)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79173 --- Comment #23 from Jeffrey A. Law --- risc-v doesn't have any special instructions to implement add-with-carry or subtract-with-borrow. Depending on who you talk do, it's either a feature or a mis-design.
[Bug c/110298] [10/11/12/13/14 Regression] ICE at -Os on x86_64-linux-gnu since r10-840
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110298 Jakub Jelinek changed: What|Removed |Added Ever confirmed|0 |1 Summary|ICE at -Os on |[10/11/12/13/14 Regression] |x86_64-linux-gnu|ICE at -Os on ||x86_64-linux-gnu since ||r10-840 CC||jakub at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Last reconfirmed||2023-06-17 Status|UNCONFIRMED |NEW --- Comment #1 from Jakub Jelinek --- Started with r10-840-g5fd8a9cb5b0e95af7f833
[Bug c/110298] New: ICE at -Os on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110298
Bug ID: 110298
Summary: ICE at -Os on x86_64-linux-gnu
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: shaohua.li at inf dot ethz.ch
Target Milestone: ---
ICE at -Os.
$ cat a.c
int a, b, c, d, e;
int f() {
c = 0;
for (; c >= 0; c--) {
d = 0;
for (; d <= 0; d++) {
e = 0;
for (; d + c + e >= 0; e--)
;
a = 1;
b = 0;
for (; a; ++b)
a *= 2;
for (; b + d >= 0;)
return 0;
}
}
}
int main() {}
$
$ gcc-tk -Os a.c
during GIMPLE pass: cunroll
a.c: In function ‘f’:
a.c:2:5: internal compiler error: tree check: expected class ‘type’, have
‘exceptional’ (error_mark) in tree_nop_conversion_p, at tree.cc:11961
2 | int f() {
| ^
0x20cb70e internal_error(char const*, ...)
???:0
0x87f9b6 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
???:0
0x16e265d generic_simplify_386(unsigned int, tree_node*, tree_node*,
tree_node*, tree_node**, tree_code)
???:0
0x16b8bc8 generic_simplify_GE_EXPR(unsigned int, tree_code, tree_node*,
tree_node*, tree_node*)
???:0
0xca5f45 fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
???:0
0xcc0dc4 fold(tree_node*)
???:0
0x1209be8 simplify_replace_tree(tree_node*, tree_node*, tree_node*, tree_node*
(*)(tree_node*, void*), void*, bool)
???:0
0x120abcb substitute_in_loop_info(loop*, tree_node*, tree_node*)
???:0
0x10c6dc5 replace_uses_by(tree_node*, tree_node*)
???:0
0xb485d3 merge_blocks(basic_block_def*, basic_block_def*)
???:0
0x10d9784 cleanup_tree_cfg(unsigned int)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug libstdc++/110287] _M_check_len is expensive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110287
--- Comment #4 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #3)
> @@ -946,7 +945,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
>else
> {
> const size_type __len =
> - _M_check_len(size_type(1), "vector::_M_insert_aux");
> + _M_check_len_1("vector::_M_insert_aux");
> _Bit_pointer __q = this->_M_allocate(__len);
> iterator __start(std::__addressof(*__q), 0);
> iterator __i = _M_copy_aligned(begin(), __position, __start);
Oops, this hunk is for vector which is different. Ignore this part.
[Bug libstdc++/110287] _M_check_len is expensive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110287
--- Comment #3 from Jonathan Wakely ---
Do you mean something like this?
diff --git a/libstdc++-v3/include/bits/stl_vector.h
b/libstdc++-v3/include/bits/stl_vector.h
index 70ced3d101f..a4dbfeb8b5b 100644
--- a/libstdc++-v3/include/bits/stl_vector.h
+++ b/libstdc++-v3/include/bits/stl_vector.h
@@ -1902,6 +1902,21 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
return (__len < size() || __len > max_size()) ? max_size() : __len;
}
+ // Called by _M_insert_aux etc.
+ _GLIBCXX20_CONSTEXPR
+ size_type
+ _M_check_len_1(const char* __s) const
+ {
+ if (__builtin_constant_p(size()))
+ {
+ if (size() == 0)
+ return 1;
+ else if (size() < max_size() / 2)
+ return size() * 2;
+ }
+ return _M_check_len(1, __s);
+ }
+
// Called by constructors to check initial size.
static _GLIBCXX20_CONSTEXPR size_type
_S_check_init_len(size_type __n, const allocator_type& __a)
diff --git a/libstdc++-v3/include/bits/vector.tcc
b/libstdc++-v3/include/bits/vector.tcc
index acd11e2dc68..1f0b3123c3b 100644
--- a/libstdc++-v3/include/bits/vector.tcc
+++ b/libstdc++-v3/include/bits/vector.tcc
@@ -458,8 +458,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
_M_realloc_insert(iterator __position, const _Tp& __x)
#endif
{
- const size_type __len =
- _M_check_len(size_type(1), "vector::_M_realloc_insert");
+ const size_type __len = _M_check_len_1("vector::_M_realloc_insert");
pointer __old_start = this->_M_impl._M_start;
pointer __old_finish = this->_M_impl._M_finish;
const size_type __elems_before = __position - begin();
@@ -946,7 +945,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
else
{
const size_type __len =
- _M_check_len(size_type(1), "vector::_M_insert_aux");
+ _M_check_len_1("vector::_M_insert_aux");
_Bit_pointer __q = this->_M_allocate(__len);
iterator __start(std::__addressof(*__q), 0);
iterator __i = _M_copy_aligned(begin(), __position, __start);
Incorrect type when using std::conditional_t with an empty lambda
When using std::conditional_t inside a class/struct with one of the
conditional types being `decltype([]{})`, the type is wrong.
https://godbolt.org/z/3jhfcKav4
```
#include
#include
#include
template
using test_alias = std::conditional_t;
template
using test_alias3 = std::conditional_t;
template
class aboba {
public:
using test_alias2 = std::conditional_t;
static_assert(std::same_as, uint32_t[32]>);
static_assert(std::same_as, uint32_t[32]>);
test_alias a;
test_alias2 b;
std::conditional_t c;
test_alias3 d;
};
aboba test{};
int main() {
using a_t = decltype(test.a);
using b_t = decltype(test.b);
using c_t = decltype(test.c);
using d_t = decltype(test.d);
static_assert(std::same_as, uint32_t[32]>);
static_assert(std::same_as);
static_assert(std::same_as);
static_assert(std::same_as);
static_assert(std::same_as);
return 0;
}
```
```
Compiler returned: 1
Compiler stderr
:19:24: error: template argument 1 is invalid
19 | static_assert(std::same_as,
uint32_t[32]>);
|
^~
: In function 'int main()':
:37:24: error: static assertion failed
37 | static_assert(std::same_as);
| ~^~
:37:24: note: constraints not satisfied
In file included from :2:
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/concepts:57:15:
required for the satisfaction of '__same_as<_Tp, _Up>' [with _Tp = int; _Up
= unsigned int[32]]
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/concepts:57:32: note:
the expression 'is_same_v<_Tp, _Up> [with _Tp = int; _Up = unsigned
int[32]]' evaluated to 'false'
57 | concept __same_as = std::is_same_v<_Tp, _Up>;
|
```
[Bug target/54089] [SH] Refactor shift patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089 --- Comment #81 from Alexander Klepikov --- (In reply to Oleg Endo from comment #78) > The compiler processes one function at a time, all passes at once. It > doesn't mix passes of different functions. So I think using global variable > in sh.cc + override 'set_current_function' should get the job done. When > the insn split code is executed, just set the global flag in the SH specific > function context. I made a proof of concept using a global variable only. It is defined in sh.cc and it is defined as extern in sh_loop.cc. It is set when splitting is done and it is cleared when sh_loop_done is called, i.e. at the end of loop optimization. Do we really need 'set_current_function'? Because so far it seems a little excessive.
[Bug fortran/88688] Incorrect association in SELECT TYPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88688 Paul Thomas changed: What|Removed |Added Status|WAITING |NEW CC||pault at gcc dot gnu.org --- Comment #2 from Paul Thomas --- nagfor has the same behavior as ifort. I believe that the following, which appears in F2018:19.5.1.6 applies: "If a selector has the POINTER attribute, it shall be associated; the associate name is associated with the target of the pointer and does not have the POINTER attribute." In other words, the association shall be via assignment, rather than pointer assignment. Changing to new. Paul PS Thomas, did you by any chance take this up on c.l.f?
[Bug go/110297] New: [13/14 Regression] all libgo tests fail on arm-linux-gnueabi and arm-linxu-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110297
Bug ID: 110297
Summary: [13/14 Regression] all libgo tests fail on
arm-linux-gnueabi and arm-linxu-gnueabihf
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: doko at gcc dot gnu.org
Target Milestone: ---
seen on the gcc-13 branch 20230611 on arm-linux-gnueabi and
arm-linux-gnueabihf:
and all libgo tests fail on ARM32, both on the gcc-13 branch and the trunk.
[...]
fatal error: runtime: cannot allocate memory
runtime stack:
runtime.dopanic__m
../../../src/libgo/go/runtime/panic.go:1207
runtime.fatalthrow
../../../src/libgo/go/runtime/panic.go:1073
runtime.throw
../../../src/libgo/go/runtime/panic.go:1044
runtime.persistentalloc1
../../../src/libgo/go/runtime/malloc.go:1475
runtime.persistentalloc..func1
../../../src/libgo/go/runtime/malloc.go:1429
runtime.systemstack
../../../src/libgo/go/runtime/stubs.go:61
runtime.persistentalloc
../../../src/libgo/go/runtime/malloc.go:1428
runtime.addrRanges.init
../../../src/libgo/go/runtime/mranges.go:170
runtime.pageAlloc.init
../../../src/libgo/go/runtime/mpagealloc.go:330
runtime.mheap.init
../../../src/libgo/go/runtime/mheap.go:723
runtime.mallocinit
../../../src/libgo/go/runtime/malloc.go:497
runtime.schedinit
../../../src/libgo/go/runtime/proc.go:681
:0
:0
__libc_start_main
:0
that's from a simple check:
GO=go-13
WORKDIR=$(mktemp -d)
trap "rm -rf $WORKDIR" 0 INT QUIT ABRT PIPE TERM
cd $WORKDIR
cat < hello.go
package main
import "fmt"
func main() {
fmt.Println("hello world")
}
EOF
$GO run hello.go
$GO build hello.go
echo "build: OK"
ldd hello
[ -x hello ]
./hello
echo "run: OK"
[Bug target/54089] [SH] Refactor shift patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089 --- Comment #80 from Oleg Endo --- (In reply to Alexander Klepikov from comment #79) > > I mean that if a user run GCC with -O1 and we don't do SH specific loop move > invariants pass at -O1, a user could look at binary (or at .S file) and find > that not all invariants are moved out of the loops, because library > addresses are hoisted after split1 pass. That would confuse a user even if > RTL dump is generated, and he can decide that it's a bug into loop2 pass. I > suggest to generate sh_loop dumps if RTL dump is requested and place there a > message that sh_loop hoisting is not done due to optimization level setting. I don't think users would get surprised or anything by lack of certain optimization. There is no official set of guaranteed optimizations performed at a particular -O level. It's OK to output a message into the RTL dump of course. But everything else seems a bit overthinking the issue. Actually the hoisting might not be always done. E.g. when register pressure in a loop is high, it might be better to not hoist the function address and keep it inside of the loop to reduce register pressure. But I'm not sure the loop optimization passes are smart enough to do that (yet). > > I checked several cases and they are because ld cannot link little endian > binary. When I run failed command taken from log file, it always fails for > linking little endian binary. But sometimes logs say that executing of > little endian binary is successful. I'm at a loss - how is that even > possible? Ugh, sounds weird. Sometimes a particular binutils version is also no good. Have you tried using an older binutils? Maybe it's more stable?
[Bug c++/110296] ICE in gsi_replace, at gimple-iterator.cc:437 during GIMPLE pass: widening_mul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110296 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Already fixed. *** This bug has been marked as a duplicate of bug 110271 ***
[Bug tree-optimization/110271] [14 Regression] UICE on pycryptodome-3.17.0 during GIMPLE pass: widening_mul: in gsi_replace, at gimple-iterator.cc:437
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110271 Andrew Pinski changed: What|Removed |Added CC||manuel.lauss at googlemail dot com --- Comment #8 from Andrew Pinski --- *** Bug 110296 has been marked as a duplicate of this bug. ***
[Bug c++/110296] New: ICE in gsi_replace, at gimple-iterator.cc:437 during GIMPLE pass: widening_mul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110296 Bug ID: 110296 Summary: ICE in gsi_replace, at gimple-iterator.cc:437 during GIMPLE pass: widening_mul Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: manuel.lauss at googlemail dot com Target Milestone: --- Created attachment 55355 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55355=edit unreduced testcase # g++ -v gcc version 14.0.0 20230616 (experimental) ea1cd66f2200839d46a8b4dc140d18c00b849c82 # g++ -O2 fail.i -cduring GIMPLE pass: widening_mul /tmp-ram/portage/app-crypt/qca-2.3.6-r2/work/qca-2.3.6/src/botantools/botan/mp_comba.cpp: In function 'void QCA::Botan::bigint_comba_mul4(word*, const word*, const word*)': /tmp-ram/portage/app-crypt/qca-2.3.6-r2/work/qca-2.3.6/src/botantools/botan/mp_comba.cpp:47:6: internal compiler error: in gsi_replace, at gimple-iterator.cc:437 47 | void bigint_comba_mul4(word z[8], const word x[4], const word y[4]) | ^ See attached unreduced source. Thanks! Manuel
[Bug target/54089] [SH] Refactor shift patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089 --- Comment #79 from Alexander Klepikov --- (In reply to Oleg Endo from comment #78) > (In reply to Alexander Klepikov from comment #77) > > > It'd be good if the newly added passes are ran only with -O2 or higher. > > > > This can be confusing to users when they discover that not all invariants > > are moved out of loops. Then we should inform them about that at least. > > I don't think the compiler reports any optimizations not done to the user at > lower optimization levels? It's normal not to do certain optimizations at a > lower level, that's why we have -O0 -O1 -O2 ... or do you mean something > else by that? > I mean that if a user run GCC with -O1 and we don't do SH specific loop move invariants pass at -O1, a user could look at binary (or at .S file) and find that not all invariants are moved out of the loops, because library addresses are hoisted after split1 pass. That would confuse a user even if RTL dump is generated, and he can decide that it's a bug into loop2 pass. I suggest to generate sh_loop dumps if RTL dump is requested and place there a message that sh_loop hoisting is not done due to optimization level setting. But, actually, it's not that important at the moment because I'm aiming to do the second option - run sh_loop only when it's potentially needed. > The compiler processes one function at a time, all passes at once. That's what I missed! Thank you for clarification! > > I see some strange new exec fails only at testsuite logs. Right now I'm > > trying to find the cause. > > What's the configure line of your GCC build? ../gcc-13.1.0/configure --target=sh-elf --with-endian=big,little --disable-bootstrap --enable-languages=c,c++ --disable-nls --with-gnu-as --with-gnu-ld --prefix=/usr/local/sh-toolchain/ --without-newlib --without-headers I checked several cases and they are because ld cannot link little endian binary. When I run failed command taken from log file, it always fails for linking little endian binary. But sometimes logs say that executing of little endian binary is successful. I'm at a loss - how is that even possible?
[Bug c++/110295] New: internal compiler error: in dwarf2out_finish
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110295 Bug ID: 110295 Summary: internal compiler error: in dwarf2out_finish Product: gcc Version: 11.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: d...@sol-3.de Target Milestone: --- Created attachment 55354 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55354=edit Files required as per your bug reporting guidelines. A small test program to a small caching utility class uses a template template parameter and a local class. This is too much for all GCC Versions from 9 to 13 when compiling with -g on any unixoid system. See attached file: Here produced with gcc-11.4 on Debian-11.7. Code is fine and works otherwise. Cheers, Dirk
[Bug tree-optimization/110280] internal compiler error: in const_unop, at fold-const.cc:1884
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110280 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=96463 --- Comment #9 from Andrew Pinski --- The creation of that VEC_PERM comes started at r13-1055-g494bec025002df422f2f (aka PR 96463). The VEC_PERM match-and-simplify was not updated for the new semantics it seems (it was added at r10-507-gebd733a78ccf ).
[Bug tree-optimization/110280] internal compiler error: in const_unop, at fold-const.cc:1884
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110280
--- Comment #8 from Andrew Pinski ---
In the original case FRE is trying to do the same thing as the reduced
testcase:
```
Successfully combined 4 partial definitions
Setting value number of _39 to { 0, 0, 0, 0 } (changed)
Value numbering stmt = _40 = VEC_PERM_EXPR <_39, _39, { 0, 1, 2, 3, ... }>;
Match-and-simplified VEC_PERM_EXPR <_39, _39, { 0, 1, 2, 3, ... }> to { 0, 0,
0, 0 }
RHS VEC_PERM_EXPR <_39, _39, { 0, 1, 2, 3, ... }> simplified to { 0, 0, 0, 0 }
Setting value number of _40 to { 0, 0, 0, 0 } (changed)
Value numbering stmt = lanes ={v} {CLOBBER(eol)};
Setting value number of .MEM_54 to .MEM_54 (changed)
Value numbering stmt = _41 = [vec_unpack_lo_expr] _40;
```
[Bug tree-optimization/110280] internal compiler error: in const_unop, at fold-const.cc:1884
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110280
--- Comment #7 from Andrew Pinski ---
I think this part of match is incorrect:
(if (sel.series_p (0, 1, 0, 1))
{ op0; }
(if (sel.series_p (0, 1, nelts, 1))
{ op1; }
This is only true if type == TREE_TYPE (op0) (well compatible) ...
[Bug tree-optimization/110280] internal compiler error: in const_unop, at fold-const.cc:1884
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110280
--- Comment #6 from Andrew Pinski ---
Match-and-simplified VEC_PERM_EXPR <_10, _10, { 0, 1, 2, 3, ... }> to { 0, 0,
0, 0 }
Ok, that is wrong ...
[Bug tree-optimization/110280] internal compiler error: in const_unop, at fold-const.cc:1884
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110280
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.2
Known to fail||13.1.0
--- Comment #5 from Andrew Pinski ---
First reduced testcase with the same ICE:
```
#include "arm_sve.h"
auto l() {
svuint32_t ttt;
{
alignas(16) const unsigned int lanes[4] = {0, 0, 0, 0};
ttt = svld1rq_u32(svptrue_b8(), lanes);
}
return svunpklo_u64 (ttt);
}
```
Another reduced testcase with a related ICE:
```
#include "arm_sve.h"
svuint32_t l() {
alignas(16) const unsigned int lanes[4] = {0, 0, 0, 0};
return svld1rq_u32(svptrue_b8(), lanes);
}
```
For the first one, we have:
```
lanes[0] = 0;
lanes[1] = 0;
lanes[2] = 0;
lanes[3] = 0;
_10 = MEM [(unsigned int * {ref-all})];
ttt_7 = VEC_PERM_EXPR <_10, _10, { 0, 1, 2, 3, ... }>;
lanes ={v} {CLOBBER(eol)};
_9 = [vec_unpack_lo_expr] ttt_7;
```
The ICE is on simplifying _9.
The second one we have a similar thing except no vec_unpack_lo_expr there.
I suspect it is the simplification of the VEC_PERM which is causing the issue
rather than vec_unpack_lo_expr directly.
And dealing with how _10 is generated inside fre to a vector.
[Bug target/54089] [SH] Refactor shift patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089 --- Comment #78 from Oleg Endo --- (In reply to Alexander Klepikov from comment #77) > > It'd be good if the newly added passes are ran only with -O2 or higher. > > This can be confusing to users when they discover that not all invariants > are moved out of loops. Then we should inform them about that at least. I don't think the compiler reports any optimizations not done to the user at lower optimization levels? It's normal not to do certain optimizations at a lower level, that's why we have -O0 -O1 -O2 ... or do you mean something else by that? > I'm thinking about this for some time. We know that we should potentially > run additional loop optimization pass when we're splitting libcall. I did > not find the way to know in what function we are splitting yet. The compiler processes one function at a time, all passes at once. It doesn't mix passes of different functions. So I think using global variable in sh.cc + override 'set_current_function' should get the job done. When the insn split code is executed, just set the global flag in the SH specific function context. > I see some strange new exec fails only at testsuite logs. Right now I'm > trying to find the cause. What's the configure line of your GCC build?
[Bug middle-end/110282] Segmentation fault with specific optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110282 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #2 from Xi Ruoyao --- Not reproducible with GCC 13.1 too.
[Bug c/110294] Segmentation fault with '-O3 -fno-dce -fno-toplevel-reorder -fno-tree-dce -fno-tree-pta -fno-tree-sink -ftoplevel-reorder'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110294 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #2 from Xi Ruoyao --- Not reproducible with GCC 13.1. I guess it's a duplicate of a fixed issue.
[Bug middle-end/110292] undefined value due to strict aliasing without warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110292 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #6 from Xi Ruoyao --- (In reply to Yann Droneaud from comment #5) > Hi, > > Thanks a lot for the quick analysis of my issue. > > (In reply to Andrew Pinski from comment #4) > > Note -Wstrict-aliasing=1 actually does warn: > > OK, and -Wall enables -Wstrict-aliasing which defaults to > -Wstrict-aliasing=3, > I'm sorry I haven't tried to use lower values ... The problem is -Wstrict-aliasing=1 may produce many false positives, as it's documented. > https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wstrict- > aliasing > > (In reply to Andrew Pinski from comment #2) > > aliasing violations are known not to be warned about nor have a runtime > > sanitizer either. > > Is there any other tool that would reliably detect such issues ? Such issues are obviously impossible to be detected reliably at compile time (because doing so will need to solve the halting problem). At runtime LLVM guys are developing a type sanitizer: https://discourse.llvm.org/t/reviving-typesanitizer-a-sanitizer-to-catch-type-based-aliasing-violations
[Bug target/54089] [SH] Refactor shift patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089 --- Comment #77 from Alexander Klepikov --- > It'd be good if the newly added passes are ran only with -O2 or higher. This can be confusing to users when they discover that not all invariants are moved out of loops. Then we should inform them about that at least. > Or even better, if we can find a way to enable them only when actually > needed. > E.g. when it's splitting a shift insn that will potentially need the loop > optimizations again, set a flag in the function. I'm thinking about this for some time. We know that we should potentially run additional loop optimization pass when we're splitting libcall. I did not find the way to know in what function we are splitting yet. > However, to get better test coverage, it's better first let the additional > loop passes run all the time to uncover any potential issues. Later the > above can be added as a supplementary optimization. I see some strange new exec fails only at testsuite logs. Right now I'm trying to find the cause.
