[Bug tree-optimization/91790] New: ICE: Segmentation fault (in vr_values::vrp_visit_assignment_or_call), or ICE: verify_ssa failed (error: definition in block 2 follows the use)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91790
Bug ID: 91790
Summary: ICE: Segmentation fault (in
vr_values::vrp_visit_assignment_or_call), or ICE:
verify_ssa failed (error: definition in block 2
follows the use)
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-checking, ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: powerpc-*-linux-gnu
Created attachment 46888
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46888=edit
Testcase
g++-10.0.0-alpha20190915 snapshot (r275736) ICEs when compiling the attached
testcase, partially reduced from
libstdc++-v3/testsuite/26_numerics/pstl/numeric_ops/transform_reduce.cc, w/
-mvsx -O3 for 32-bit BE powerpc:
w/ -fchecking:
% powerpc-e300c3-linux-gnu-g++-10.0.0-alpha20190915 -mvsx -O3 -fchecking -c
tp2khayx.cc
tp2khayx.cc: In function 'void bg()':
tp2khayx.cc:75:6: error: definition in block 2 follows the use
75 | void bg() {
| ^~
for SSA_NAME: _30 in statement:
vectp.75_391 = _30;
during GIMPLE pass: slp
tp2khayx.cc:75:6: internal compiler error: verify_ssa failed
0x123fdef verify_ssa(bool, bool)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20190915/work/gcc-10-20190915/gcc/tree-ssa.c:1208
0xf2ed08 execute_function_todo
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20190915/work/gcc-10-20190915/gcc/passes.c:1990
0xf2f41a execute_todo
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20190915/work/gcc-10-20190915/gcc/passes.c:2037
w/ -fno-checking:
% powerpc-e300c3-linux-gnu-g++-10.0.0-alpha20190915 -mvsx -O3 -fno-checking -c
tp2khayx.cc
during GIMPLE pass: dom
tp2khayx.cc: In function 'void bg()':
tp2khayx.cc:75:6: internal compiler error: Segmentation fault
75 | void bg() {
| ^~
0x100d316 crash_signal
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20190915/work/gcc-10-20190915/gcc/toplev.c:326
0x1352cae vr_values::vrp_visit_assignment_or_call(gimple*, tree_node**,
value_range*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20190915/work/gcc-10-20190915/gcc/vr-values.c:2074
0x1352cae vr_values::vrp_visit_assignment_or_call(gimple*, tree_node**,
value_range*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20190915/work/gcc-10-20190915/gcc/vr-values.c:2054
0x176ec25 evrp_range_analyzer::record_ranges_from_stmt(gimple*, bool)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20190915/work/gcc-10-20190915/gcc/gimple-ssa-evrp-analyze.c:307
0x1139cf3 dom_opt_dom_walker::before_dom_children(basic_block_def*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20190915/work/gcc-10-20190915/gcc/tree-ssa-dom.c:1503
0x174b8a7 dom_walker::walk(basic_block_def*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20190915/work/gcc-10-20190915/gcc/domwalk.c:309
0x113764d execute
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20190915/work/gcc-10-20190915/gcc/tree-ssa-dom.c:724
[Bug tree-optimization/91789] Value ranges determined from comparisons not used transitively
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91789 Eric Gallager changed: What|Removed |Added Keywords||missed-optimization CC||egallager at gcc dot gnu.org Blocks||85316 --- Comment #1 from Eric Gallager --- If I understood the "Project Ranger" talk at Cauldron correctly, the new version of VRP that it'll provide will probably fix this. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316 [Bug 85316] [meta-bug] VRP range propagation missed cases
[Bug c/45977] "warning: 'i' initialized and declared 'extern'" could use a separate warning flag controlling it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45977 --- Comment #7 from Eric Gallager --- This bug provoked this StackOverflow question: https://stackoverflow.com/questions/57957168/how-do-i-disable-a-gcc-warning-which-has-no-command-line-switch
[Bug tree-optimization/91789] New: Value ranges determined from comparisons not used transitively
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91789
Bug ID: 91789
Summary: Value ranges determined from comparisons not used
transitively
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
Target Milestone: ---
Take the following code:
int foo(int a, int b)
{
if (b < a)
__builtin_unreachable();
if (a < 0)
return -1;
if (b < 0)
return 0;
return 1;
}
The compiler should be able to determine that the b < 0 can never be true. At
that point in the code a >= 0 and b >= a, therefore transitively b >= 0.
The problem is not tied to __builtin_unreachable as can be seen by changing the
code slightly:
int foo(int a, int b)
{
if (b < a)
return 2;
if (a < 0)
return -1;
if (b < 0)
return 0;
return 1;
}
After the initial test b < a is handled there is still a threeway comparison.
The problem can be seen with 9.2.1 as well as the current trunk version. clang
8.0.0 generates pretty much the same code as gcc.
[Bug c++/55578] Disabling warnings inside macro definition doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55578 Eric Gallager changed: What|Removed |Added See Also|https://gcc.gnu.org/bugzill |https://gcc.gnu.org/bugzill |a/show_bug.cgi?id=9128 |a/show_bug.cgi?id=91285 --- Comment #6 from Eric Gallager --- dang it, typoed one of the "See Also" entries...
[Bug c++/55578] Disabling warnings inside macro definition doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55578 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=91669, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=90400, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=69558, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=9128 --- Comment #5 from Eric Gallager --- (In reply to Eric Gallager from comment #4) > (In reply to Andrew Pinski from comment #2) > > Confirmed. It only happens with the C++ front-end though. The exact same > > code does not warn with the C front-end. I think this might be the > > pre-ahead of time tokenizer that happens for the C++ front-end but does not > > happen for C. > > so related to bug 53431 then and bug 91669, bug 90400, bug 69558, bug 91285, etc. We should probably choose one of the bugs in this web of related bugs and choose one to use as the base bug and mark the rest as duplicates, but idk which one...
[Bug target/91766] -fvisibility=hidden during -fpic still uses GOT indirection on arm64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91766 Eric Gallager changed: What|Removed |Added Keywords||visibility CC||egallager at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=85678 --- Comment #6 from Eric Gallager --- (In reply to Wilco from comment #4) > (In reply to martin krastev from comment #3) > > So it appears to be a clash between -fcommon and -fvisibility=hidden during > > -fpic -- passing either -fno-common or -fno-pic drops the GOT indirection. > > And explicitly hiding the symbol obviously solves it. But the crux of the > > issue, IMO, is a multi-platform one -- that behavior deviates on gcc-8.2 > > from platform to platform. On amd64 it suffices to -fvisibility=hidden to > > stop GOT detours, whereas on aarch64 it's -fvisibility=hidden -fno-common. > > As a result aarch64 performance gets penalized in unsuspecting multi-plats. > > -fno-common should really become the default, -fcommon causes way too many > issues. That's bug 85678
[Bug tree-optimization/91758] Clang fails to pass validation after r261089
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91758 Martin Liška changed: What|Removed |Added Status|WAITING |ASSIGNED CC||marxin at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- I've reduced that and I'm working on that right now.
[Bug libstdc++/91788] std::variant index +1-1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91788 --- Comment #1 from Marc Glisse --- Internally, it may also be possible to avoid calling index() so often and work with the raw _M_index more often.
[Bug target/91269] sparc64-gcc fails to build glibc (-fcall-used-g6) on niagara4: Assembler messages: Error: Illegal operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91269 --- Comment #9 from Sergei Trofimovich --- Still happens on gcc version 10.0.0 20190916 (experimental) (GCC) How can I peek at the stage where registers are assigned to std instruction? I suspect it needs special annotation WRT paired FPU registers.
[Bug libstdc++/91788] New: std::variant index +1-1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91788
Bug ID: 91788
Summary: std::variant index +1-1
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
(this is a detail, it probably has a negligible impact)
constexpr size_t index() const noexcept
{ return size_t(typename _Base::__index_type(this->_M_index + 1)) - 1; }
IIUC, the whole +1-1 is here so that for a valueless variant, index_type(-1)
becomes size_t(-1). I think there are cases where we could do better. For
instance, for a never valueless type, we could just return _M_index. If there
are fewer than 128 alternatives, we could use a sign extension: "return (signed
char)_M_index;". Maybe some well-placed __builtin_unreachable to specify the
range of _M_index would work as well.
[Bug libstdc++/78113] std::variant and std::visit's current implementations do not get optimized out (compared to "recursive visitation")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78113 --- Comment #6 from Marc Glisse --- (looking at the first testcase) There are 2 things. One is the implementation strategy in libstdc++ vs boost vs others (I don't know what is best, it probably depends on the application). The other one is that gcc's inliner is very badly suited to this type of code, as we have been seeing for a while with std::any, std::function, etc. Even if I manually unroll the loop (the unroller is too late) and force as much inlining as possible, it would require cycling between inlining and FRE (or similar, anything that replaces a memory load with whatever was last stored there).
[Bug c++/91777] No warning for iterator going out of scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91777 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-09-16 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- I can see a ASAN error: $ g++ pr91777.cc -std=c++17 -fsanitize=address -g -O3 -Wall -Wextra -Wsign-conversion && ./a.out = ==21067==ERROR: AddressSanitizer: heap-use-after-free on address 0x60300020 at pc 0x00401464 bp 0x7ffe073683b0 sp 0x7ffe073683a8 READ of size 4 at 0x60300020 thread T0 #0 0x401463 in main /home/marxin/Programming/testcases/pr91777.cc:13 #1 0x7fd31dd8cbca in __libc_start_main ../csu/libc-start.c:308 #2 0x401529 in _start (/home/marxin/Programming/testcases/a.out+0x401529) 0x60300020 is located 16 bytes inside of 24-byte region [0x60300010,0x60300028) freed by thread T0 here: #0 0x7fd31e374f37 in operator delete(void*, unsigned long) /home/marxin/Programming/gcc/libsanitizer/asan/asan_new_delete.cpp:172 #1 0x401c7f in __gnu_cxx::new_allocator >::deallocate(std::_List_node*, unsigned long) /home/marxin/bin/gcc/include/c++/10.0.0/ext/new_allocator.h:129 #2 0x401c7f in std::allocator_traits > >::deallocate(std::allocator >&, std::_List_node*, unsigned long) /home/marxin/bin/gcc/include/c++/10.0.0/bits/alloc_traits.h:470 #3 0x401c7f in std::__cxx11::_List_base >::_M_put_node(std::_List_node*) /home/marxin/bin/gcc/include/c++/10.0.0/bits/stl_list.h:442 #4 0x401c7f in std::__cxx11::_List_base >::_M_clear() /home/marxin/bin/gcc/include/c++/10.0.0/bits/list.tcc:81 #5 0x401c7f in std::__cxx11::_List_base >::~_List_base() /home/marxin/bin/gcc/include/c++/10.0.0/bits/stl_list.h:495 #6 0x401c7f in std::__cxx11::list >::~list() /home/marxin/bin/gcc/include/c++/10.0.0/bits/stl_list.h:823 #7 0x401c7f in foo[abi:cxx11]() /home/marxin/Programming/testcases/pr91777.cc:7 #8 0x6030006f () previously allocated by thread T0 here: #0 0x7fd31e374117 in operator new(unsigned long) /home/marxin/Programming/gcc/libsanitizer/asan/asan_new_delete.cpp:99 #1 0x40184c in __gnu_cxx::new_allocator >::allocate(unsigned long, void const*) /home/marxin/bin/gcc/include/c++/10.0.0/ext/new_allocator.h:111 #2 0x40184c in std::allocator_traits > >::allocate(std::allocator >&, unsigned long) /home/marxin/bin/gcc/include/c++/10.0.0/bits/alloc_traits.h:444 #3 0x40184c in std::__cxx11::_List_base >::_M_get_node() /home/marxin/bin/gcc/include/c++/10.0.0/bits/stl_list.h:438 #4 0x40184c in std::_List_node* std::__cxx11::list >::_M_create_node(int const&) /home/marxin/bin/gcc/include/c++/10.0.0/bits/stl_list.h:630 #5 0x40184c in void std::__cxx11::list >::_M_insert(std::_List_iterator, int const&) /home/marxin/bin/gcc/include/c++/10.0.0/bits/stl_list.h:1907 #6 0x40184c in int& std::__cxx11::list >::emplace_back(int const&) /home/marxin/bin/gcc/include/c++/10.0.0/bits/stl_list.h:1223 #7 0x40184c in void std::__cxx11::list >::_M_initialize_dispatch(int const*, int const*, std::__false_type) /home/marxin/bin/gcc/include/c++/10.0.0/bits/stl_list.h:1836 #8 0x40184c in std::__cxx11::list >::list(std::initializer_list, std::allocator const&) /home/marxin/bin/gcc/include/c++/10.0.0/bits/stl_list.h:757 #9 0x40184c in foo[abi:cxx11]() /home/marxin/Programming/testcases/pr91777.cc:7 #10 0x7fd30002 () SUMMARY: AddressSanitizer: heap-use-after-free /home/marxin/Programming/testcases/pr91777.cc:13 in main Shadow bytes around the buggy address: 0x0c067fff7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c067fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c067fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c067fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c067fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x0c067fff8000: fa fa fd fd[fd]fa fa fa fd fd fd fa fa fa fd fd 0x0c067fff8010: fd fa fa fa 00 00 00 fa fa fa 00 00 00 fa fa fa 0x0c067fff8020: 00 00 00 fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c067fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c067fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c067fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by
[Bug c++/81042] Too many constexpr iterations on unreachable loop.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81042
Ralph Tandetzky changed:
What|Removed |Added
CC||ralph.tandetzky at gmail dot
com
--- Comment #4 from Ralph Tandetzky ---
The following code:
1 constexpr int f()
2 {
3 for ( int i = 0; i < 1; ++i ) {
4 const int digit = i/1;
5 if( digit == 0 )
6 continue;
7 for ( int j = 0; j < 0; ++j ) {} // <-- loop iteration count
8 // exceeds limit
9 }
10 return 0;
11 }
12
13 constexpr int i = f();
produces the following error with GCC 8.2:
:13:20: in 'constexpr' expansion of 'f()'
:7:9: error: 'constexpr' loop iteration count exceeds
limit of 262144 (use -fconstexpr-loop-limit= to increase the limit)
for ( int j = 0; j < 0; ++j ) {}
^~~
[Bug c++/91787] New: an elaborated-type-specifier only takes plain "enum", gcc accept ill-formed, while it should not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91787 Bug ID: 91787 Summary: an elaborated-type-specifier only takes plain "enum", gcc accept ill-formed, while it should not. Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: derrick at ca dot ibm.com Target Milestone: --- Refer to C++11 N3290 7.1.6.3 Elaborated type specifiers An enum-specifier needs the body of the definition, and an elaborated-type-specifier only takes plain "enum". Following code compile failure on clang8.0, and gcc accept it while it should not. using var = enum struct alignas(1) var;
[Bug libstdc++/91786] New: Clang 8.0.1 can't compile the header on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91786 Bug ID: 91786 Summary: Clang 8.0.1 can't compile the header on Windows Product: gcc Version: 9.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: iamsupermouse at mail dot ru Target Milestone: --- On Windows, Clang 8.0.1 refuses to compile the header with following errors: > In file included from ...\mingw64\include\c++\9.2.0\filesystem:37: > ...\mingw64\include\c++\9.2.0\bits/fs_path.h:636:31: error: invalid use of > incomplete > type 'std::filesystem::__cxx11::filesystem_error' > _GLIBCXX_THROW_OR_ABORT(filesystem_error( > ^ > ...\mingw64\include\c++\9.2.0\x86_64-w64-mingw32\bits/c++config.h:177:49: > note: expanded > from macro '_GLIBCXX_THROW_OR_ABORT' > # define _GLIBCXX_THROW_OR_ABORT(_EXC) (throw (_EXC)) > ^~~~ > ...\mingw64\include\c++\9.2.0\bits/fs_fwd.h:61:9: note: forward declaration of > 'std::filesystem::__cxx11::filesystem_error' > class filesystem_error; > ^ > 1 error generated. We can prevent Clang from complaining by moving the definition of `class filesystem_error` a few lines up. It should be at least above the definition of `u8path()`.
[Bug preprocessor/49973] Column numbers count multibyte characters as multiple columns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49973 --- Comment #14 from joseph at codesourcery dot com --- On Sun, 15 Sep 2019, lhyatt at gmail dot com wrote: > I feel like the most portable solution is just to use directly the necessary > code (from glibc or gnulib or from scratch or wherever) to handle the > wcwidth() > functionality, and tweak it for this purpose. It's in essence just a binary Both of those use data generated in some way from Unicode data (stored in the locale in the glibc case). A standalone generator implementing UAX#11 rules for character width should be straightforward (we'd need to check in the generator sources as well as the generated table). > search in a table. Basically I would convert the source line from the input > charset to UTF-8 the same way the file is read on original input (using the > facilities in libcpp/charset.c), and then I would just need a variant of Yes, sources need to be processed consistently (converted from input charset to UTF-8). And then of course converted from UTF-8 to the locale character set for the final output on the terminal (with some form of graceful degradation if the source character set has characters that can't be represented in the locale character set - extended identifiers diagnostics use UCNs in that case, but I don't know if that's best in general). If a source line in the default -finput-charset=utf-8 case contains non-UTF-8 bytes in strings or comments, we can't safely display them on the terminal, so my inclination in such a case would be to treat such bytes as width-1 and output them as '?'.
[Bug go/91781] [10 regression] r275691 breaks go test "reflect"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91781 --- Comment #4 from Andreas Schwab --- For reflect to work there needs to be support for go closures in libffi.
[Bug go/91781] [10 regression] r275691 breaks go test "reflect"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91781 --- Comment #3 from seurer at gcc dot gnu.org --- Sorry, I missed this was a new test case. And no, it still doesn't work with current trunk.
[Bug go/91781] [10 regression] r275691 breaks go test "reflect"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91781 --- Comment #2 from Ian Lance Taylor --- Oh, never mind, this is a new test in r275691, this code has probably never worked on ppc64be.
[Bug go/91781] [10 regression] r275691 breaks go test "reflect"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91781 --- Comment #1 from Ian Lance Taylor --- Does this work at SVN revision r275611?
[Bug fortran/91784] ICE in gfc_real2complex, at fortran/arith.c:2208
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91784
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2019-09-16
CC||kargl at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org
Target Milestone|--- |9.3
Ever confirmed|0 |1
--- Comment #1 from kargl at gcc dot gnu.org ---
Ugh. I have a patch that fixes this one, too.
I think, however, that we're missing a simplification
step while matching the array constructor.
(Watch for copy-n-paste tab to spaces corruption)
Index: gcc/fortran/simplify.c
===
--- gcc/fortran/simplify.c (revision 275730)
+++ gcc/fortran/simplify.c (working copy)
@@ -8508,10 +8508,10 @@ gfc_convert_constant (gfc_expr *e, bt type, int kind)
{
if (c->expr->expr_type == EXPR_ARRAY)
tmp = gfc_convert_constant (c->expr, type, kind);
- else if (c->expr->expr_type == EXPR_OP
- && c->expr->value.op.op == INTRINSIC_PARENTHESES)
+ else if (c->expr->expr_type == EXPR_OP)
{
- gfc_simplify_expr (c->expr, 1);
+ if (!gfc_simplify_expr (c->expr, 1))
+ return _bad_expr;
tmp = f (c->expr, kind);
}
else
[Bug driver/81358] libatomic not automatically linked with C11 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358 --- Comment #10 from Andreas Schwab --- All these failure modes can already be observed on riscv-linux, where -pthread implies -latomic.
[Bug fortran/91785] ICE in check_assumed_size_reference, at fortran/resolve.c:1601
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91785 G. Steinmetz changed: What|Removed |Added Keywords||ice-on-invalid-code --- Comment #1 from G. Steinmetz --- $ cat z2.f90 # for reference program p complex :: a(*) real :: b(2) b = aimag(a) end $ gfortran-10-20190915 -c z2.f90 z2.f90:2:18: 2 |complex :: a(*) | 1 Error: Assumed size array at (1) must be a dummy argument z2.f90:4:13: 4 |b = aimag(a) | 1 Error: The upper bound in the last dimension must appear in the reference to the assumed size array 'a' at (1)
[Bug fortran/91785] New: ICE in check_assumed_size_reference, at fortran/resolve.c:1601
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91785 Bug ID: 91785 Summary: ICE in check_assumed_size_reference, at fortran/resolve.c:1601 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- With an invalid declaration since gfortran-9 : $ cat z1.f90 program p complex :: a(*) real :: b(2) b = a%im end $ gfortran-10-20190915 -c z1.f90 0x61adfe gfc_format_decoder ../../gcc/fortran/error.c:947 0x139bf3e pp_format(pretty_printer*, text_info*) ../../gcc/pretty-print.c:1390 0x1391845 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*) ../../gcc/diagnostic.c:1025 0x61ac9c gfc_error_opt ../../gcc/fortran/error.c:1313 0x61c260 gfc_error(char const*, ...) ../../gcc/fortran/error.c:1342 0x67fc82 check_assumed_size_reference ../../gcc/fortran/resolve.c:1601 0x68edd3 resolve_variable ../../gcc/fortran/resolve.c:5655 0x68edd3 gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.c:6954 0x61df91 find_inquiry_ref ../../gcc/fortran/expr.c:1776 0x62136d simplify_ref_chain ../../gcc/fortran/expr.c:2023 0x620c87 gfc_simplify_expr(gfc_expr*, int) ../../gcc/fortran/expr.c:2220 0x67b4b9 gfc_match_varspec(gfc_expr*, int, bool, bool) ../../gcc/fortran/primary.c:2334 0x67ce50 gfc_match_rvalue(gfc_expr**) ../../gcc/fortran/primary.c:3570 0x65412e match_primary ../../gcc/fortran/matchexp.c:157 0x65412e match_level_1 ../../gcc/fortran/matchexp.c:211 0x65412e match_mult_operand ../../gcc/fortran/matchexp.c:267 0x654378 match_add_operand ../../gcc/fortran/matchexp.c:356 0x6545cc match_level_2 ../../gcc/fortran/matchexp.c:480 0x654722 match_level_3 ../../gcc/fortran/matchexp.c:551 0x654814 match_level_4 ../../gcc/fortran/matchexp.c:599
[Bug fortran/91784] New: ICE in gfc_real2complex, at fortran/arith.c:2208
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91784 Bug ID: 91784 Summary: ICE in gfc_real2complex, at fortran/arith.c:2208 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Follow-up of pr91553, with a negation : $ cat z1.f90 program p complex :: x(1) x = (1.0, 2.0) * [real :: -(3.0 + 4.0)] end $ cat z2.f90 program p complex :: x(1) x = (1.0, 2.0) * [real :: -2.0 * (3 + 4)] end $ gfortran-10-20190915 -c z1.f90 f951: internal compiler error: Segmentation fault 0xb3e54f crash_signal ../../gcc/toplev.c:326 0x5e9721 gfc_real2complex(gfc_expr*, int) ../../gcc/fortran/arith.c:2208 0x6abd74 gfc_convert_constant(gfc_expr*, bt, int) ../../gcc/fortran/simplify.c:8518 0x62fccb do_simplify ../../gcc/fortran/intrinsic.c:4540 0x63ae7a gfc_convert_type_warn(gfc_expr*, gfc_typespec*, int, int) ../../gcc/fortran/intrinsic.c:5223 0x5e6da3 eval_intrinsic ../../gcc/fortran/arith.c:1563 0x65441c match_add_operand ../../gcc/fortran/matchexp.c:392 0x6545cc match_level_2 ../../gcc/fortran/matchexp.c:480 0x654722 match_level_3 ../../gcc/fortran/matchexp.c:551 0x654814 match_level_4 ../../gcc/fortran/matchexp.c:599 0x654814 match_and_operand ../../gcc/fortran/matchexp.c:693 0x654a02 match_or_operand ../../gcc/fortran/matchexp.c:722 0x654ad2 match_equiv_operand ../../gcc/fortran/matchexp.c:765 0x654ba4 match_level_5 ../../gcc/fortran/matchexp.c:811 0x653f81 gfc_match_expr(gfc_expr**) ../../gcc/fortran/matchexp.c:870 0x64bff8 gfc_match(char const*, ...) ../../gcc/fortran/match.c:1150 0x64d879 gfc_match_assignment() ../../gcc/fortran/match.c:1349 0x66fe50 match_word ../../gcc/fortran/parse.c:65 0x66fe50 decode_statement ../../gcc/fortran/parse.c:361 0x67194a next_free ../../gcc/fortran/parse.c:1251
[Bug fortran/91783] New: [10 Regression] ICE in gfc_dep_resolver, at fortran/dependency.c:2111
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91783 Bug ID: 91783 Summary: [10 Regression] ICE in gfc_dep_resolver, at fortran/dependency.c:2111 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Changed between 20190630 and 20190728 : $ cat z1.f90 program p class(*), allocatable :: a(:) a = [1, 2, 3] a = f(a) contains function f(x) result(y) class(*), allocatable, intent(in) :: x(:) class(*), allocatable :: y(:) y = x end end $ gfortran-10-20190630 -c z1.f90 $ $ gfortran-10-20190915 -c z1.f90 z1.f90:4:0: 4 |a = f(a) | internal compiler error: in gfc_dep_resolver, at fortran/dependency.c:2111 0x6b9cce gfc_dep_resolver(gfc_ref*, gfc_ref*, gfc_reverse*, bool) ../../gcc/fortran/dependency.c:2111 0x6ba2a0 gfc_check_dependency(gfc_expr*, gfc_expr*, bool) ../../gcc/fortran/dependency.c:1373 0x6d35be gfc_conv_resolve_dependencies(gfc_loopinfo*, gfc_ss*, gfc_ss*) ../../gcc/fortran/trans-array.c:4847 0x704c55 gfc_trans_assignment_1 ../../gcc/fortran/trans-expr.c:10736 0x6c4f5f trans_code ../../gcc/fortran/trans.c:1852 0x6edd14 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6781 0x677af6 translate_all_program_units ../../gcc/fortran/parse.c:6254 0x677af6 gfc_parse_file() ../../gcc/fortran/parse.c:6493 0x6c1a0f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204
[Bug fortran/91782] Accepts invalid array constructor with character parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91782 G. Steinmetz changed: What|Removed |Added Keywords||accepts-invalid --- Comment #1 from G. Steinmetz --- $ cat z2.f90 # without parameter program p integer :: i character(3) :: x = 'abc' print *, ['a', 'ab', 'abc'] print *, [x(1:1), x(1:2), x(1:3)] print *, [(x(1:i), i=1,3)] print *, ichar(([(x(1:i), i=1,3)])) print *, len_trim([(x(min(1,i):i), i=1,3)]) end $ gfortran-10-20190915 -c z2.f90 z2.f90:4:17: 4 |print *, ['a', 'ab', 'abc'] | 1 Error: Different CHARACTER lengths (1/2) in array constructor at (1) z2.f90:5:20: 5 |print *, [x(1:1), x(1:2), x(1:3)] |1 Error: Different CHARACTER lengths (1/2) in array constructor at (1) z2.f90:6:14: 6 |print *, [(x(1:i), i=1,3)] | 1 Error: Different CHARACTER lengths (1/2) in array constructor at (1) z2.f90:7:21: 7 |print *, ichar(([(x(1:i), i=1,3)])) | 1 Error: Different CHARACTER lengths (1/2) in array constructor at (1) z2.f90:8:23: 8 |print *, len_trim([(x(min(1,i):i), i=1,3)]) | 1 Error: Different CHARACTER lengths (1/2) in array constructor at (1)
[Bug fortran/91782] New: Accepts invalid array constructor with character parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91782 Bug ID: 91782 Summary: Accepts invalid array constructor with character parameter Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- A parameter attribute prevents some checks in comparison to a character variable. Affects gfortran down to at least version 5. $ cat z1.f90 program p integer :: i character(3), parameter :: x = 'abc' print *, ['abc'(1:1), 'abc'(1:2), 'abc'(1:3)] print *, [x(1:1), x(1:2), x(1:3)] print *, [(x(1:i), i=1,3)] print *, ichar(([(x(1:i), i=1,3)])) print *, len_trim([(x(min(1,i):i), i=1,3)]) end $ gfortran-10-20190915 z1.f90 && ./a.out aaa aaa aaa 97 97 97 1 1 1
[Bug target/91719] gcc compiles seq_cst store on x86-64 differently from clang/icc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91719 --- Comment #11 from uros at gcc dot gnu.org --- Author: uros Date: Mon Sep 16 18:37:28 2019 New Revision: 275754 URL: https://gcc.gnu.org/viewcvs?rev=275754=gcc=rev Log: PR target/91719 * config/i386/i386.h (TARGET_USE_XCHG_FOR_ATOMIC_STORE): New macro. * config/i386/x86-tune.def (X86_TUNE_USE_XCHG_FOR_ATOMIC_STORE): New. * config/i386/sync.md (atomic_store): emit XCHG for TARGET_USE_XCHG_FOR_ATOMIC_STORE. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.h trunk/gcc/config/i386/sync.md trunk/gcc/config/i386/x86-tune.def
[Bug go/91781] New: [10 regression] r275691 breaks go test "reflect"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91781 Bug ID: 91781 Summary: [10 regression] r275691 breaks go test "reflect" Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: seurer at gcc dot gnu.org CC: cmang at google dot com Target Milestone: --- This only seems to occur on powerpc 64 BE. --- FAIL: TestMethodValue (0.00s) all_test.go:2290: Int32Method returned 45088; want 456 FAIL FAIL: reflect r275691 | ian | 2019-09-12 18:22:53 -0500 (Thu, 12 Sep 2019) | 4 lines libgo: update to Go1.13 Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/194698
[Bug driver/81358] libatomic not automatically linked with C11 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358 --- Comment #9 from joseph at codesourcery dot com --- I should also note the testsuite point I mentioned in the BoF, and related points about building target libraries, which mean this is more complicated than just the driver specs change: There is testsuite logic (see gcc/testsuite/lib/atomic-dg.exp) to locate libatomic for build-tree testing and set appropriate -L options and LD_LIBRARY_PATH. This is only used in gcc/testsuite/gcc.dg/atomic/atomic.exp at present. If the driver specs change to use "--as-needed -latomic --no-as-needed" whenever libatomic is built (obviously they shouldn't do so for configurations not building libatomic, whether because unsupported for the target or because disabled at configure time), linking *any* target program will then require libatomic to be somewhere that ld can find it (because ld requires a library named with -l to be somewhere it can find, even inside --as-needed; it can only know whether a library is needed after seeing what symbols it defines). Thus, that logic would need to be used globally for all testsuites. In addition, all configure tests in target libraries that run link tests, and linking of shared target libraries, would need to pass appropriate -L options to find libatomic, and we'd need to make sure the target library dependencies in toplevel Makefile.def ensure libatomic is built before other target libraries are configured for this to work. I think libgcc should still be built before libatomic and so we'd need some driver option to disable linking with libatomic that would be passed when linking shared libgcc.
Re: [Bug driver/81358] libatomic not automatically linked with C11 code
I should also note the testsuite point I mentioned in the BoF, and related points about building target libraries, which mean this is more complicated than just the driver specs change: There is testsuite logic (see gcc/testsuite/lib/atomic-dg.exp) to locate libatomic for build-tree testing and set appropriate -L options and LD_LIBRARY_PATH. This is only used in gcc/testsuite/gcc.dg/atomic/atomic.exp at present. If the driver specs change to use "--as-needed -latomic --no-as-needed" whenever libatomic is built (obviously they shouldn't do so for configurations not building libatomic, whether because unsupported for the target or because disabled at configure time), linking *any* target program will then require libatomic to be somewhere that ld can find it (because ld requires a library named with -l to be somewhere it can find, even inside --as-needed; it can only know whether a library is needed after seeing what symbols it defines). Thus, that logic would need to be used globally for all testsuites. In addition, all configure tests in target libraries that run link tests, and linking of shared target libraries, would need to pass appropriate -L options to find libatomic, and we'd need to make sure the target library dependencies in toplevel Makefile.def ensure libatomic is built before other target libraries are configured for this to work. I think libgcc should still be built before libatomic and so we'd need some driver option to disable linking with libatomic that would be passed when linking shared libgcc. -- Joseph S. Myers jos...@codesourcery.com
[Bug tree-optimization/91776] `-fsplit-paths` generates slower code on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91776 Wilco changed: What|Removed |Added CC||wilco at gcc dot gnu.org --- Comment #1 from Wilco --- (In reply to yhr-_-yhr from comment #0) > I'm doing this test on a Raspberry Pi Model 3B+. The CPU is BCM2835 ARMv7. I think it's BM2837, ie. Cortex-A53. Or did you mean a different Pi? > pi@rpi:~/Desktop $ gcc -Wall -march=native -mtune=native -o fibmod -O2 > fibmod.c > pi@rpi:~/Desktop $ ./fibmod > ~ 240755135 loop/s > ~ 277965738 loop/s > ~ 276675919 loop/s > ~ 277244469 loop/s > ~ 277207289 loop/s > ~ 277303633 loop/s > ^C > > (2) > pi@rpi:~/Desktop $ gcc -Wall -march=native -mtune=native -o fibmod -O2 > -fsplit-paths fibmod.c > pi@rpi:~/Desktop $ ./fibmod > ~ 137691044 loop/s > ~ 144593838 loop/s > ~ 144397428 loop/s > ~ 144519131 loop/s > ~ 144392500 loop/s > ^C Can you list the assembly code for both inner loops please? This doesn't seem like -fsplit-paths, but more likely related to -mstrict-it in Armv8. I can reproduce a 2x slowdown with this loop if the subtract is not conditionally executed. This happens if the register allocator uses a high register: fast case: cmp r4, r3 it ls subls r3, r3, r4 slow case: cmp r10, r3 bhi .L2 sub r3, r3, r10 .L2: Can you try using -mno-strict-it on your examples and see whether that helps?
[Bug c++/91780] New: Discrepancy between gcc 7.4, through 9.2, compared to clang.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91780
Bug ID: 91780
Summary: Discrepancy between gcc 7.4, through 9.2, compared to
clang.
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mikael.p.persson at gmail dot com
Target Milestone: ---
GCC does not change values in tuple of references
The bug is indicated by a difference between gcc7.4 to 9.2 and gcc trunk and
clang 6.0 to 8.0
clang succeeds, gcc fails. I think clang is right, but I am not absolutely
sure.
Compiler from godbolt
Flags:
-std=c++17
Problem occurs regardless of optimization levels.
-fsanitize-undefined shows no problem
I am uncertain where the problem occurs, and the smallest case I have is as
follows:
#include
#include
#include
#include
#include
#include
template
auto tuple_map_impl(Fn&& fn, Argument&& argument, std::index_sequence) {
if constexpr (sizeof...(Ns) == 0) return std::tuple<>(); // empty tuple
else if constexpr (std::is_same_v(argument))),
void>) {
[[maybe_unused]]
auto _ = {(fn(std::get(argument)), 0)...}; // no return value
expected
return;
}
// then dispatch lvalue, rvalue ref, temporary
else if constexpr
(std::is_lvalue_reference_v(argument)))>) {
return std::tie(fn(std::get(argument))...);
}
else if constexpr
(std::is_rvalue_reference_v(argument)))>) {
return std::forward_as_tuple(fn(std::get(argument))...);
}
else {
return std::tuple(fn(std::get(argument))...);
}
}
template
constexpr bool is_tuple_impl_v = false;
template
constexpr bool is_tuple_impl_v> = true;
template
constexpr bool is_tuple_v = is_tuple_impl_v>;
template
auto tuple_map(Fn&& fn, Tuple&& tuple) {
static_assert(is_tuple_v, "tuple_map implemented only for tuples");
return tuple_map_impl(std::forward(fn), std::forward(tuple),
std::make_index_sequence>::value>());
}
template
class zip_iterator {
public:
using value_type = std::tuple::value_type...>;
using difference_type = std::size_t;
using pointer = value_type*;
using reference = value_type&;
using iterator_category = std::forward_iterator_tag;
public:
zip_iterator(Iterators... iterators) : iters(iterators...) {}
zip_iterator(const std::tuple& iter_tuple) :
iters(iter_tuple) {}
zip_iterator(const zip_iterator&) = default;
zip_iterator(zip_iterator&&) = default;
zip_iterator& operator=(const zip_iterator&) = default;
zip_iterator& operator=(zip_iterator&&) = default;
bool operator != (const zip_iterator& other) const { return iters !=
other.iters; }
zip_iterator& operator++() {
tuple_map([](auto& iter) { ++iter; }, iters);
return *this;
}
zip_iterator operator++(int) {
auto tmp = *this;
++(*this);
return tmp;
}
auto operator*() {
return tuple_map([](auto i) -> decltype(auto) { return *i; }, iters);
}
auto operator*() const {
return tuple_map([](auto i) -> decltype(auto) { return *i; }, iters);
}
private:
std::tuple iters;
};
template
struct zip {
using iterator =
zip_iterator().begin())...>;
template
zip(Containers... containers) :
containers_(std::forward(containers)...) { }
auto begin() { return iterator(tuple_map([](auto&& i) { return
std::begin(i); }, containers_)); }
auto end() { return iterator(tuple_map([](auto&& i) { return std::end(i);
}, containers_)); }
std::tuple containers_;
};
template
zip(Container_types&&... containers) -> zip;
int main(){
std::vector as{1,2,3};
std::vector bs{-1,-2,-3};
// tuple of references references are returned,
// so they should be changed
for (auto [x, y] : zip(as, bs)) {
x++;y--;
}
// check that the result is changed,
// this succeeds on clang 6.0.0, 8.0.0, fails on gcc 7.4.0, 9.2.0
assert(as[0]== 2);
assert(as[1]== 3);
assert(as[2]== 4);
assert(bs[0]==-2);
assert(bs[1]==-3);
assert(bs[2]==-4);
return 0;
}
[Bug target/91779] Unbalanced stack manipulation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91779 Andreas Schwab changed: What|Removed |Added Summary|[9 regression] Unbalanced |Unbalanced stack |stack manipulation |manipulation Known to fail||7.4.1, 9.2.1 --- Comment #1 from Andreas Schwab --- Not a regression, also fails with 7.4.1.
[Bug target/91779] New: [9 regression] Unbalanced stack manipulation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91779
Bug ID: 91779
Summary: [9 regression] Unbalanced stack manipulation
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sch...@linux-m68k.org
Target Milestone: ---
Target: i586-*-*
Created attachment 46887
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46887=edit
Preprocessed input
When compiled with -m32 -O2, the first call to _fprintf in main
_fprintf(out,"->{'%c'}\n",Cr.x);
saves the format string on the stack at $fp-100:
pushl %eax
leal.LC164@GOTOFF(%ebx), %eax
pushl %eax
pushl (%esi)
movl%eax, -100(%ebp)
call_fprintf
This is then reused by the second call:
pushl %eax
pushl -100(%ebp)
pushl (%esi)
call_fprintf
but here pushl %eax overwrites the value in $fp-100.
The bug appears to be here (after first call to fflush):
pushl (%esi)
callfflush@PLT
leal-84(%ebp), %eax
popl%edx
popl%ecx
The second popl is causing a stack frame underflow.
[Bug middle-end/88784] Middle end is missing some optimizations about unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88784 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED CC||marxin at gcc dot gnu.org Resolution|--- |FIXED --- Comment #30 from Martin Liška --- Implemented on trunk.
[Bug middle-end/88784] Middle end is missing some optimizations about unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88784 --- Comment #29 from Martin Liška --- Author: marxin Date: Mon Sep 16 14:22:16 2019 New Revision: 275749 URL: https://gcc.gnu.org/viewcvs?rev=275749=gcc=rev Log: Fix PR88784, middle end is missing some optimizations about unsigned 2019-09-16 Li Jia He Qi Feng PR middle-end/88784 * match.pd (x > y && x != XXX_MIN): Optimize into 'x > y'. (x > y && x == XXX_MIN): Optimize into 'false'. (x <= y && x == XXX_MIN): Optimize into 'x == XXX_MIN'. (x < y && x != XXX_MAX): Optimize into 'x < y'. (x < y && x == XXX_MAX): Optimize into 'false'. (x >= y && x == XXX_MAX): Optimize into 'x == XXX_MAX'. (x > y || x != XXX_MIN): Optimize into 'x != XXX_MIN'. (x <= y || x != XXX_MIN): Optimize into 'true'. (x <= y || x == XXX_MIN): Optimize into 'x <= y'. (x < y || x != XXX_MAX): Optimize into 'x != XXX_MAX'. (x >= y || x != XXX_MAX): Optimize into 'true'. (x >= y || x == XXX_MAX): Optimize into 'x >= y'. 2019-09-16 Li Jia He Qi Feng PR middle-end/88784 * gcc.dg/pr88784-1.c: New testcase. * gcc.dg/pr88784-2.c: New testcase. * gcc.dg/pr88784-3.c: New testcase. * gcc.dg/pr88784-4.c: New testcase. * gcc.dg/pr88784-5.c: New testcase. * gcc.dg/pr88784-6.c: New testcase. * gcc.dg/pr88784-7.c: New testcase. * gcc.dg/pr88784-8.c: New testcase. * gcc.dg/pr88784-9.c: New testcase. * gcc.dg/pr88784-10.c: New testcase. * gcc.dg/pr88784-11.c: New testcase. * gcc.dg/pr88784-12.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr88784-1.c trunk/gcc/testsuite/gcc.dg/pr88784-10.c trunk/gcc/testsuite/gcc.dg/pr88784-11.c trunk/gcc/testsuite/gcc.dg/pr88784-12.c trunk/gcc/testsuite/gcc.dg/pr88784-2.c trunk/gcc/testsuite/gcc.dg/pr88784-3.c trunk/gcc/testsuite/gcc.dg/pr88784-4.c trunk/gcc/testsuite/gcc.dg/pr88784-5.c trunk/gcc/testsuite/gcc.dg/pr88784-6.c trunk/gcc/testsuite/gcc.dg/pr88784-7.c trunk/gcc/testsuite/gcc.dg/pr88784-8.c trunk/gcc/testsuite/gcc.dg/pr88784-9.c Modified: trunk/gcc/ChangeLog trunk/gcc/match.pd trunk/gcc/testsuite/ChangeLog
[Bug fortran/91778] gfortran GCC9 optimizer bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91778 Mark Wieczorek changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #4 from Mark Wieczorek --- Thanks for the help. After realizing that the fftw_execute call was in fact suspicious I went to their web site and found that it had been updated recently. They state that "we have had reports that this causes problems with some recent optimizing Fortran compilers. The problem is, because the input/output arrays are not passed as explicit arguments to dfftw_execute, the semantics of Fortran (unlike C) allow the compiler to assume that the input/output arrays are not changed by dfftw_execute. As a consequence, certain compilers end up optimizing out or repositioning the call to dfftw_execute, assuming incorrectly that it does nothing." They then suggest using new convenience functions that are like call fftw_execute(plan, coef, grid) where the coef and grid variable are just placeholders so that optimizer understands the dependencies. I am going to consider this closed. Thanks again!
[Bug lto/91772] [8/9/10 Regression] ICE in add_dwarf_attr, at dwarf2out.c:4412 since r259749
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91772 --- Comment #2 from Martin Liška --- Created attachment 46886 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46886=edit Test-case
[Bug fortran/91513] Non-standard terminology in error message for pointer component assignment in pure procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91513 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #1) > I confirm the error message from at least 4.8 up to trunk (10.0). > > Could you please suggest a better message? Damian and I worked on an improvement, and have developed a patch. Need to pull patch off my laptop and send to Damian for review.
[Bug fortran/91778] gfortran GCC9 optimizer bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91778 Thomas Koenig changed: What|Removed |Added Last reconfirmed|2019-09-16 00:00:00 | CC||tkoenig at gcc dot gnu.org --- Comment #3 from Thomas Koenig --- (In reply to Mark Wieczorek from comment #0) > I am writing about a possible bug in the gfortran GCC9 optimizer on macOS > (installed via brew). > > Before going into the details, I note that my code (SHTOOLS/pyshtools) is > widely used on many platforms and compilers. My code works with GCC8 > compiled with optimizations "-O" or "-O3", and it works fine with GCC9 when > compiled _without_ optimizations. I was able to "fix" my code to work with > GCC9, but I feel that what I am doing is avoiding a bug in the GCC9 > optimizer, and that I am not in fact "fixing" my code (perhaps I am > wrong...). > > The problem is related to using the FFTW3 library, which is the most widely > used FFT library for scientific computing. If this is a bug, then others > will probably encounter similar problems. As my code is somewhat long (and > given the lack of time I have now), I will just give you a summary of two > problems. If necessary, I could try to write a "small" example that > reproduces these problems when I have more free time later. If it turns out that this is needed, please do. However... > I start by describing how FFTW routines are use. First, you initialize the > FFT operation and get pointers to all the input and output arrays, which are > stored in the variable "plan": > > call dfftw_plan_dft_c2r_1d(plan, nlong, coef, grid) This sounds very suspicious. According to the Fortran standard, you cannot stash away a pointer to a Fortran array unless that array is marked as TARGET. Well, you can, but it's liable to break any time, and apparently it did. Can you show the declaration of dfftw_plan_dft_c2r_1d ? > Then you perform the FFT simply by calling > > call dfftw_execute(plan) > > The first problem boils down to this: > > call dfftw_plan_dft_c2r_1d(plan, nlong, coef, grid) > > coef(1) = dcmplx(coef0,0.0d0) ! A > coef(2:lmax_comp+1) = coef(2:lmax_comp+1) / 2.0d0 > > call dfftw_execute(plan) ! AA > gridglq(i,1:nlong) = grid(1:nlong) > > coef(1) = dcmplx(coef0s,0.0d0) ! B > coef(2:lmax_comp+1) = coefs(2:lmax_comp+1)/2.0d0 > > call dfftw_execute(plan) ! BB > gridglq(i_s,1:nlong) = grid(1:nlong) > > > The problem is that the optimizer thinks the line A is redundant with line B > (the same variable is being defined twice). And that is correct behavior. Try marking coef as TARGET or VOLATILE, this should inhibit this optimization. > The second problem I encountered is a little more mysterious. These are the > _last_ 4 lines of the subroutine: > > coef(lmax_comp+1) = coef(lmax_comp+1) + cilm(1,lmax_comp+1,lmax_comp+1) > coef(nlong-(lmax_comp-1)) = coef(nlong-(lmax_comp-1)) & > + cilm(2,lmax_comp+1,lmax_comp+1) > > call dfftw_execute(plan) > > griddh(i_eq,1:nlong) = grid(1:nlong) > > The problem is that the optimizer ignores the first two lines. The reason > for this is probably because (1) the variable coef is not explicitly noted > in the fftw call, and (2) the variable coef is not output in the subroutine. > Thus, the optimizer probably thinks that it doesn't need to compute the > first two lines Sounds reasonable. > So, in summary, I believe that the GCC9 optimizer is not working correctly > because it doesn't realize that the function call dfftw_execute(plan) > actually depends on the variables coef and grid. Given that my code has > worked well with all other versions of GCC, I suspect that there has been a > change in how the optimizer works. I assume that your program was always non-conforming, and that gcc has simply gotten better at finding optimization opportunities.
[Bug fortran/91778] gfortran GCC9 optimizer bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91778 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-09-16 CC||kargl at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from kargl at gcc dot gnu.org --- Need a reproducer. It would also be beneficial to know what happens when your code is compiled with -Wall -Werror -fcheck=all -ffpe-trap=invalid,zero
[Bug fortran/91778] gfortran GCC9 optimizer bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91778 --- Comment #1 from Andrew Pinski --- Are you using c bindings to bind to fftw functions?
[Bug c++/91777] No warning for iterator going out of scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91777 --- Comment #1 from Konstantin Kharlamov --- FTR, on IRC was referenced the following paper that may be interesting for implementors https://github.com/isocpp/CppCoreGuidelines/blob/master/docs/Lifetime.pdf
[Bug fortran/91649] ICE in gfc_resolve_findloc, at fortran/iresolve.c:1827
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91649 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-09-16 Ever confirmed|0 |1
[Bug fortran/91778] New: gfortran GCC9 optimizer bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91778 Bug ID: 91778 Summary: gfortran GCC9 optimizer bug Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mark.wieczorek at oca dot eu Target Milestone: --- I am writing about a possible bug in the gfortran GCC9 optimizer on macOS (installed via brew). Before going into the details, I note that my code (SHTOOLS/pyshtools) is widely used on many platforms and compilers. My code works with GCC8 compiled with optimizations "-O" or "-O3", and it works fine with GCC9 when compiled _without_ optimizations. I was able to "fix" my code to work with GCC9, but I feel that what I am doing is avoiding a bug in the GCC9 optimizer, and that I am not in fact "fixing" my code (perhaps I am wrong...). The problem is related to using the FFTW3 library, which is the most widely used FFT library for scientific computing. If this is a bug, then others will probably encounter similar problems. As my code is somewhat long (and given the lack of time I have now), I will just give you a summary of two problems. If necessary, I could try to write a "small" example that reproduces these problems when I have more free time later. I start by describing how FFTW routines are use. First, you initialize the FFT operation and get pointers to all the input and output arrays, which are stored in the variable "plan": call dfftw_plan_dft_c2r_1d(plan, nlong, coef, grid) Then you perform the FFT simply by calling call dfftw_execute(plan) The first problem boils down to this: call dfftw_plan_dft_c2r_1d(plan, nlong, coef, grid) coef(1) = dcmplx(coef0,0.0d0) ! A coef(2:lmax_comp+1) = coef(2:lmax_comp+1) / 2.0d0 call dfftw_execute(plan) ! AA gridglq(i,1:nlong) = grid(1:nlong) coef(1) = dcmplx(coef0s,0.0d0) ! B coef(2:lmax_comp+1) = coefs(2:lmax_comp+1)/2.0d0 call dfftw_execute(plan) ! BB gridglq(i_s,1:nlong) = grid(1:nlong) The problem is that the optimizer thinks the line A is redundant with line B (the same variable is being defined twice). Thus, the optimizer sets line A to that of line B and deletes line B. I have verified this by doing so in my code. However, line A is necessary to execute line AA, and line B is necessary to execute line BB. The optimizer probably doesn't realize this because the variable "coef" is not explicitly included when calling the function dfftw_execute(plan). The second problem I encountered is a little more mysterious. These are the _last_ 4 lines of the subroutine: coef(lmax_comp+1) = coef(lmax_comp+1) + cilm(1,lmax_comp+1,lmax_comp+1) coef(nlong-(lmax_comp-1)) = coef(nlong-(lmax_comp-1)) & + cilm(2,lmax_comp+1,lmax_comp+1) call dfftw_execute(plan) griddh(i_eq,1:nlong) = grid(1:nlong) The problem is that the optimizer ignores the first two lines. The reason for this is probably because (1) the variable coef is not explicitly noted in the fftw call, and (2) the variable coef is not output in the subroutine. Thus, the optimizer probably thinks that it doesn't need to compute the first two lines So, in summary, I believe that the GCC9 optimizer is not working correctly because it doesn't realize that the function call dfftw_execute(plan) actually depends on the variables coef and grid. Given that my code has worked well with all other versions of GCC, I suspect that there has been a change in how the optimizer works.
[Bug tree-optimization/91756] [10 regression] g++.dg/lto/alias-3 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91756 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed.
[Bug fortran/91513] Non-standard terminology in error message for pointer component assignment in pure procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91513 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P5 Status|UNCONFIRMED |NEW Last reconfirmed||2019-09-16 Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from Dominique d'Humieres --- I confirm the error message from at least 4.8 up to trunk (10.0). Could you please suggest a better message?
[Bug c++/91777] New: No warning for iterator going out of scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91777
Bug ID: 91777
Summary: No warning for iterator going out of scope
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Hi-Angel at yandex dot ru
Target Milestone: ---
The testcase below would've worked if instead of `return {l,…` was used `return
{move(l),…`. But it wasn't, and due to lack of borrow-semantics in C++ language
such mistakes are easy to make. In these circumstances programmers has to rely
on compiler warnings, so it would be amazing if GCC warn about iterators still
referencing the out-of-scope container.
# Steps to reproduce (in terms of terminal commands)
$ cat test.cpp
#include
#include
using namespace std;
pair, list::const_iterator> foo() {
list l = {1,2,3};
return {l, l.begin()};
}
int main() {
pair p = foo();
printf("%i\n", *p.second);
}
$ g++ test.cpp -o a -O3 -Wall -Wextra -Wsign-conversion -std=c++17
-fsanitize=address,undefined
## Expected
A warning about the second element in `return {l, l.begin()}` become invalid
once `l` goes out of scope.
## Actual
No output.
[Bug fortran/91715] ICE in resolve_fntype, at fortran/resolve.c:16884
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91715 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-09-16 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- From 4.8 up to 6 I get the following ICE f951: internal compiler error: gfc_validate_kind(): Got bad kind I get the reported error starting at gcc7 up to trunk (10.0).
[Bug fortran/91690] Slow IEEE intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91690 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-09-16 Ever confirmed|0 |1
[Bug tree-optimization/87132] [9 Regression] Gcc miscompiles at -O2 on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87132 --- Comment #5 from Richard Biener --- Author: rguenth Date: Mon Sep 16 11:58:35 2019 New Revision: 275747 URL: https://gcc.gnu.org/viewcvs?rev=275747=gcc=rev Log: 2019-09-16 Richard Biener PR tree-optimization/91756 PR tree-optimization/87132 * tree-ssa-alias.h (enum translate_flags): New. (get_continuation_for_phi): Use it instead of simple bool flag. (walk_non_aliased_vuses): Likewise. * tree-ssa-alias.c (maybe_skip_until): Adjust. (get_continuation_for_phi): When looking across backedges only disallow valueization. (walk_non_aliased_vuses): Adjust. * tree-ssa-sccvn.c (vn_reference_lookup_3): Avoid valueization if requested. * gcc.dg/tree-ssa/ssa-fre-81.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-81.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-alias.c trunk/gcc/tree-ssa-alias.h trunk/gcc/tree-ssa-sccvn.c
[Bug tree-optimization/91756] [10 regression] g++.dg/lto/alias-3 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91756 --- Comment #3 from Richard Biener --- Author: rguenth Date: Mon Sep 16 11:58:35 2019 New Revision: 275747 URL: https://gcc.gnu.org/viewcvs?rev=275747=gcc=rev Log: 2019-09-16 Richard Biener PR tree-optimization/91756 PR tree-optimization/87132 * tree-ssa-alias.h (enum translate_flags): New. (get_continuation_for_phi): Use it instead of simple bool flag. (walk_non_aliased_vuses): Likewise. * tree-ssa-alias.c (maybe_skip_until): Adjust. (get_continuation_for_phi): When looking across backedges only disallow valueization. (walk_non_aliased_vuses): Adjust. * tree-ssa-sccvn.c (vn_reference_lookup_3): Avoid valueization if requested. * gcc.dg/tree-ssa/ssa-fre-81.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-81.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-alias.c trunk/gcc/tree-ssa-alias.h trunk/gcc/tree-ssa-sccvn.c
[Bug fortran/87797] Enhancement: Warning for potential name clash of variables/intrinsics...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87797 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P5
[Bug tree-optimization/91776] New: `-fsplit-paths` generates slower code on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91776
Bug ID: 91776
Summary: `-fsplit-paths` generates slower code on arm
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: yhr-_-yhr at qq dot com
Target Milestone: ---
I'm doing this test on a Raspberry Pi Model 3B+. The CPU is BCM2835 ARMv7.
Writing a silly program calculating the cycle length of Fibonacci sequence
modulo n.
version: gcc (Raspbian 8.3.0-6+rpi1) 8.3.0
#include
#include
typedef unsigned int uint;
typedef unsigned long long ullong;
int main(){
uint m;
ullong cyc=0,lastcyc=0;
clock_t lastclock=0;
for(m=2;;m++){
uint
a=0,
b=1,
n=0;
do{
b+=a;
a=b-a;
n++;
if(b>=m)
b-=m;
}while(
a!=0||
b!=1
);
cyc+=n;
//if(n>=4*m)
// printf("%u: %u %.2f\n",m,n,(double)n/m);
if(cyc-lastcyc>1){
clock_t now=clock();
printf("~ %.0f
loop/s\n",(double)(cyc-lastcyc)/(now-lastclock)*CLOCKS_PER_SEC);
lastclock=now;
lastcyc=cyc;
}
}
}
(1)
pi@rpi:~/Desktop $ gcc -Wall -march=native -mtune=native -o fibmod -O2
fibmod.c
pi@rpi:~/Desktop $ ./fibmod
~ 240755135 loop/s
~ 277965738 loop/s
~ 276675919 loop/s
~ 277244469 loop/s
~ 277207289 loop/s
~ 277303633 loop/s
^C
(2)
pi@rpi:~/Desktop $ gcc -Wall -march=native -mtune=native -o fibmod -O2
-fsplit-paths fibmod.c
pi@rpi:~/Desktop $ ./fibmod
~ 137691044 loop/s
~ 144593838 loop/s
~ 144397428 loop/s
~ 144519131 loop/s
~ 144392500 loop/s
^C
Also tested with `-Ofast -nofsplit-paths`, the speed measured is almost same as
(1).
On other hardware with x86_64 arch, this option doesn't seem to make observable
difference in running time.
btw, clang without `-march=mative -mtune-native` also produces the same speed
as (1), but with these two options, the speed is even higher.
(3)
pi@rpi:~/Desktop $ clang -Wall -march=native -mtune=native -o fibmodclang
-Ofast fibmod.c
pi@rpi:~/Desktop $ ./fibmodclang
~ 291343047 loop/s
~ 347350967 loop/s
~ 349217005 loop/s
~ 349320149 loop/s
~ 349367926 loop/s
~ 349372536 loop/s
^C
[Bug tree-optimization/91775] Can eliminate compare from loop with known number of iterations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91775 --- Comment #5 from Richard Biener --- Oh, the special accounting triggers for candidate 6, not for candidate 3. Candidate 6: Incr POS: orig biv IV struct: Type: unsigned int Base: 1024 Step: 4294967295 Biv:N Overflowness wrto loop niter: Overflow there's also Candidate 5: Var befor: ivtmp.8 Var after: ivtmp.8 Incr POS: before exit test IV struct: Type: unsigned int Base: 1024 Step: 4294967295 Biv:N Overflowness wrto loop niter: Overflow so lots of "same" candidates. Btw, we miss a candidate based on 4096 which would allow to elide the multiplication which probably means complex addressing mode. In the end we choose Candidate 11: Var befor: ivtmp.12_5 Var after: ivtmp.12_4 Incr POS: before exit test IV struct: Type: sizetype Base: 0 Step: 4 Biv:N Overflowness wrto loop niter: No-overflow probably also a missed-optimization for the new doloop stuff?
[Bug tree-optimization/91775] Can eliminate compare from loop with known number of iterations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91775 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Target||x86_64-*-*, i?86-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2019-09-16 CC||amker at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Richard Biener --- IVOPTS considers Candidate 3: Var befor: ivtmp.6 Var after: ivtmp.6 Incr POS: before exit test IV struct: Type: unsigned int Base: 1023 Step: 4294967295 Biv:N Overflowness wrto loop niter: Overflow thus decrement to zero candidates but not increment to zero. I'm not sure why it rejects this - candidate cost seems OK. IVOPTs does consider decrement to zero specially: /* When the condition is a comparison of the candidate IV against zero, prefer this IV. TODO: The constant that we're subtracting from the cost should be target-dependent. This information should be added to the target costs for each backend. */ if (!elim_cost.infinite_cost_p () /* Do not try to decrease infinite! */ && integer_zerop (*bound_cst) && (operand_equal_p (*control_var, cand->var_after, 0) || operand_equal_p (*control_var, cand->var_before, 0))) elim_cost -= 1; so there must be other differences (the != 0 offset in the address uses) compensating for it. Bin may be able to decipher the IVOPTs dump to say what causes another IV to be selected.
[Bug c++/91607] [9 regression] internal compiler error: in equal, at cp/constexpr.c:1088
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91607 --- Comment #7 from Hannes Hauswedell --- Any news here? It's still marked unconfirmed. Thank you!
[Bug fortran/90329] Incompatibility between gfortran and C lapack calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329 --- Comment #54 from Tomas Kalibera --- (In reply to Jakub Jelinek from comment #53) > Backported to 7.x, please test it. Thanks! I tested the default behavior with DPOSV and reference LAPACK, where it worked fine. Also with all of CRAN+BIOC R packages - there is one newly failing package with 275369 compared to gfortran 7 from Ubuntu 7.4.0-8ubuntu1 with -fno-optimize-sibling-calls, but I don't think it is related to the change.
[Bug tree-optimization/91775] Can eliminate compare from loop with known number of iterations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91775 --- Comment #3 from Andrew Pinski --- I dont know/remember if iv-opts takes into account the cost difference of the comparisons for the exit condition. If it does then this becomes a target issue.
[Bug tree-optimization/91775] Can eliminate compare from loop with known number of iterations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91775 --- Comment #2 from Andrew Pinski --- This is iv selection. You need to look into iv-opts on why it is not choosing the one you want it to choose.
[Bug tree-optimization/91775] Can eliminate compare from loop with known number of iterations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91775
--- Comment #1 from Uroš Bizjak ---
Even if the loop is rewritten as:
--cut here--
#define N 1024
int a[N], b[N], c[N];
void
foo (void)
{
int i;
for (i = -N; i < 0; i++)
a[i+N] = b[i+N] + c[i+N];
}
--cut here--
gcc still emits compare insn:
xorl%eax, %eax
.L2:
movlc(%rax), %edx
addlb(%rax), %edx
addq$4, %rax
movl%edx, a-4(%rax)
* cmpq$4096, %rax
jne .L2
ret
[Bug tree-optimization/91775] New: Can eliminate compare from loop with known number of iterations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91775
Bug ID: 91775
Summary: Can eliminate compare from loop with known number of
iterations
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ubizjak at gmail dot com
Target Milestone: ---
The compiler can eliminate compare for targets, where operation sets flags (e.g
x86). Following example:
--cut here--
#define N 1024
int a[N], b[N], c[N];
void
foo (void)
{
int i;
for (i = 0; i < N; i++)
a[i] = b[i] + c[i];
}
--cut here--
compiles to (-O2):
xorl%eax, %eax
.L2:
movlc(%rax), %edx
addlb(%rax), %edx
addq$4, %rax
movl%edx, a-4(%rax)
(*) cmpq$4096, %rax
jne .L2
ret
clang generates (-O2 -fno-vectorize -fno-unroll-loops):
movq$-4096, %rax# imm = 0xF000
.LBB0_1:# =>This Inner Loop Header: Depth=1
movlc+4096(%rax), %ecx
addlb+4096(%rax), %ecx
movl%ecx, a+4096(%rax)
addq$4, %rax
jne .LBB0_1
retq
Please note that clang rewrites loop to eliminate compare (*).
[Bug c++/91774] Assignment from return value of function to reference returned by function occasionally produces wrong results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91774 --- Comment #4 from Andrew Pinski --- I see the issue: ListManager[probe].rchild = ListManager.Alloc(); If you take that, which side of the equals is evaluated first is the problem. Is "ListManager[probe].rchild" or "ListManager.Alloc()". GCC is evaluating the lhs side first and then rhs. But ListManager.Alloc() has a side effect of doing a Array::resize() which means the lhs has now a reference for the old array rather than the new one. NOTE before C++17 is unspecified which side is evulated first. I don't remember the rules for C++17 to say if it is evulated the way you want it to be evulated.
[Bug c++/91774] Assignment from return value of function to reference returned by function occasionally produces wrong results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91774
--- Comment #3 from 이경룡 ---
Oops. Sorry for the unclear explanation on the core. Forgive me.
the throw statement is not the bug itself but acted as a detector for the bug
line 28868 ~ 28925: Definition of Interpreter::Read()
line 28901 has statement:
ListManager[probe].rchild = ListManager.Alloc();
which corresponds to the statement in the prior explanation:
a[index].x = b.CalcFunc();
line 28557 ~ 28587: Definition of ListPocket::Alloc();
{
while(true){
//something
}
//some calculation
return allocIndex;
}
Observing the bug with the testcase:
among many times the ListPocket::Alloc() is invoked via
"ListManager.Alloc()"
when the if statement with a for loop inside is triggered, the return value
is expected to be 30
(sorry for mistaking it as a while loop in the prior
explanation)
the problem is that
the return value of "ListManager.Alloc()" is not properly assigned into the
reference "ListManager[probe].rchild"
In fact, the gdb shows that the return value is 30(even immediately after
the return)
and using std::cout to print out the value reports as 30 inside and outside
the function prints 30.
the cout part was disabled by the preprocessor and cannot be seen.
i.e. ListManager[probe].rchild remains 29 (it was formerly 29)
the equivalent statement that works well is:
{
auto temp = ListManager.Alloc();
ListManager[probe].rchild = temp;
}
Note: sorry for the source reduction being late.
[Bug c++/91774] Assignment from return value of function to reference returned by function occasionally produces wrong results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91774
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed||2019-09-16
Ever confirmed|0 |1
--- Comment #2 from Richard Biener ---
When you say
"The statement that triggers the bug:
A a;
B b;
auto index = (something);
a[index].x = b.CalcFunc();
The equivalent statement that avoids the bug:
A a;
B b;
auto index = (something);
{
auto temp = b.CalcFunc();
a[index].x = temp;
}"
which part of the code of the original source file needs to be modified
in what way to avoid the bug?
[Bug c++/91774] Assignment from return value of function to reference returned by function occasionally produces wrong results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91774
--- Comment #1 from Richard Biener ---
I am seeing
...
Input String and Parsed String is output inside []
>((dvo) wji (qbr) (ndo) qbr (kfh) (dvp) pzo (oos) (rmy) xuk xug fiv cks wjj zhn
>(wjh) uwa lql kfe (ckk) lqm ckp ooq uwc pzt xul xun fis qbz ) exit
Input String: [((dvo) wji (qbr) (ndo) qbr (kfh) (dvp) pzo (oos) (rmy) xuk xug
fiv cks wjj zhn (wjh) uwa lql kfe (ckk) lqm ckp ooq uwc pzt xul xun fis qbz )
exit]
Parsed String: [((dvo) wji (qbr) (ndo) qbr (kfh) (dvp) pzo (oos) (rmy) xuk xug
fiv cks wjj zhn (wjh) uwa lql kfe (lqm ckp ooq uwc pzt xul xun fis qbz) lqm ckp
ooq uwc pzt xul xun fis qbz)]
]Free List root: 40
...
-49 |qbz | 0
Hash table Full View END
Parsed String: [((dvo) wji (qbr) (ndo) qbr (kfh) (dvp) pzo (oos) (rmy) xuk xug
fiv cks wjj zhn (wjh) uwa lql kfe (lqm ckp ooq uwc pzt xul xun fis qbz) lqm ckp
ooq uwc pzt xul xun fis qbz)]
terminate called after throwing an instance of 'char const*'
Program received signal SIGABRT, Aborted.
with a backtrace like
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x7717a741 in __GI_abort () at abort.c:79
#2 0x77ae0e83 in ?? () from /usr/lib64/libstdc++.so.6
#3 0x77ae6dd8 in ?? () from /usr/lib64/libstdc++.so.6
#4 0x77ae6e23 in std::terminate() () from /usr/lib64/libstdc++.so.6
#5 0x77ae7053 in __cxa_throw () from /usr/lib64/libstdc++.so.6
#6 0x00401dbe in ListPocket::operator[] (this=0x7fffdc28,
index=29) at ../src/./ListPocketLKR.hpp:87
#7 0x00402844 in Interpreter::Restore (this=0x7fffdc10, root=29)
at ../src/./InterpreterLKR.hpp:167
#8 0x004032b4 in run_Interpreter () at ../src/main.cpp:39
#9 0x0040312d in main () at ../src/main.cpp:18
pointing to
ListElement & ListPocket::operator[](const size_t index){
if(index>= Table.getSize() ) throw "ListPocket operator [] : Array Index Out
of Bounds";
if( !Table[index].occupied ) throw "ListPocket operator [] : Reference to
Unallocated Element";
return Table[index].elem;
}
is that the "bug" you see? Compiling with clang++ doesn't abort.
The code seems ubsan and valgrind clean (whatever that means).
[Bug fortran/87797] Enhancement: Warning for potential name clash of variables/intrinsics...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87797 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-09-16 CC||tkoenig at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Thomas Koenig --- Confirmed.
[Bug target/91767] [10 regression] After r274953, clang-compiled xgcc segfaults during RTL pass: stv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91767 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.0
[Bug target/91769] [9/10 regression] wrong code with -O2 on MIPS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91769 Richard Biener changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |9.3 Summary|[9 regression] wrong code |[9/10 regression] wrong |with -O2 on MIPS|code with -O2 on MIPS
[Bug ipa/91771] Optimization fails to inline final override.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91771 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2019-09-16 CC||hubicka at gcc dot gnu.org, ||marxin at gcc dot gnu.org Component|c++ |ipa Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- I think GCC at devirtualization time does not know that 'd' (in f) has the base 'Derived'. That is, GCC only speculates that 'd' might be 'Derived': t.C:3:33: note: speculatively devirtualizing call in int f(Derived&)/2 to virtual int Derived::do_foo(int)/1 Indirect call -> speculative call int f(Derived&)/2 => virtual int Derived::do_foo(int)/1 1 polymorphic calls, 0 devirtualized, 1 speculatively devirtualized, 0 cold 0 have multiple targets, 0 overwritable, 0 already speculated (0 agree, 0 disagree), 0 external, 0 not defined, 0 artificial, 0 infos dropped and IPA inlining performs the inlining: Considering virtual int Derived::do_foo(int)/1 with 4 size to be inlined into int f(Derived&)/2 in t.C:3 Estimated badness is -inf, frequency 0.80. Badness calculation for int f(Derived&)/2 -> virtual int Derived::do_foo(int)/1 size growth -4, time 0.00 unspec 3.00 IPA hints: declared_inline big_speedup -inf: Growth -4 <= 0 Adjusted by hints -inf Inlined virtual int Derived::do_foo(int) into int f(Derived&) which now has time 6.60 and size 11, net change of -4. and then we get the code you quoted. So basically GCC fails to elide the runtime check guarding the inlined code. We're elsewhere looking at function signatures to derive stronger guarantees on pointed to types so devirt might be one place we could resort to this as well. Honza?
[Bug lto/91772] [8/9/10 Regression] ICE in add_dwarf_attr, at dwarf2out.c:4412 since r259749
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91772 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed|2019-09-14 00:00:00 |2019-09-16 Target Milestone|--- |8.4 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Attachment missing?
