[Bug tree-optimization/98984] New: Failure to optinize out float conversion from long long->float->char conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98984
Bug ID: 98984
Summary: Failure to optinize out float conversion from long
long->float->char conversion
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
char f(unsigned long long n)
{
return (float)n;
}
This can be optimized to `return n;`. This transformation is done by LLVM, but
not by GCC.
[Bug target/98537] [11 Regression] ICE in emit_move_insn since r11-5839
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98537 --- Comment #10 from Hongtao.liu --- Fixed in GCC11, not sure backport
[Bug fortran/88735] Nested assignment triggers call of final method for right hand side
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88735 --- Comment #6 from Ev Drikos --- (In reply to martin from comment #5) > Hi Ev, > > the testcase is actually derived from a smart pointer implementation (where > i is the reference count, shared between all smart pointers [hence > allocatable will not do], and incremented upon sharing). It would be nice to > have the bug fixed, though I have seen too many (subtle) bugs with > assignments by different compilers that I try not to use them. But thanks > for providing a better and more thorough testcase. Ok, then. Of course I don't think my test case is better. But as I see the underlying implementation, I feel (maybe wrong) that any allocatables would sky rocket the complexity of the solution. Regards.
[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860 --- Comment #26 from cqwrteur --- (In reply to Mikael Pettersson from comment #25) > Created attachment 50138 [details] > do not default to dwarf5 on Windows > > I have the same problem with gcc-11 bootstrap failures due to Exec format > errors post stage 1 on Cygwin64, even with current binutils master. I don't > know if it's a bug in binutils or a limitation in Windows, but DWARF5 > clearly does not work there, so this patch disables it. Works for me on > Cygwin64. Can someone please test it on mingw-w64? What cygwin compilation script are you using? Can you show me. I want this.
[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860 Mikael Pettersson changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #25 from Mikael Pettersson --- Created attachment 50138 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50138&action=edit do not default to dwarf5 on Windows I have the same problem with gcc-11 bootstrap failures due to Exec format errors post stage 1 on Cygwin64, even with current binutils master. I don't know if it's a bug in binutils or a limitation in Windows, but DWARF5 clearly does not work there, so this patch disables it. Works for me on Cygwin64. Can someone please test it on mingw-w64?
[Bug fortran/88735] Nested assignment triggers call of final method for right hand side
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88735 --- Comment #5 from martin --- Hi Ev, the testcase is actually derived from a smart pointer implementation (where i is the reference count, shared between all smart pointers [hence allocatable will not do], and incremented upon sharing). It would be nice to have the bug fixed, though I have seen too many (subtle) bugs with assignments by different compilers that I try not to use them. But thanks for providing a better and more thorough testcase.
[Bug tree-optimization/98982] Optimizing loop variants of fixed-byte-order functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98982 --- Comment #2 from Julian Andres Klode --- clang works perfectly, fwiw. I was told it has a separate pass dedicated to just recognizing loop idioms and optimizing them. I have no idea if gcc has that, but it seems useful.
[Bug c++/98983] New: SEGV during C++17 variadic template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98983
Bug ID: 98983
Summary: SEGV during C++17 variadic template instantiation
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ali...@she-devel.com
Target Milestone: ---
The code that causes the crash relies on GCC's typeclass.h and the folly
project's StaticTracepoint.h, which implements support for Linux BPF userspace
static tracing. I will attach the requested preprocessor output. The code
also crashes clang++. I do not work for F**k: this is my personal weekend
hack project.
$ make arg_classifier_lib_test
/usr/bin/g++ -std=c++17 -pthread -ggdb -Wall -Wextra -g -O0 -fno-inline
-fsanitize=address,undefined
-I/home/alison/gitsrc/googletest/googletest/include -ggdb -g -fsanitize=address
-L/home/alison/gitsrc/googletest/googletest/make -lpthread
-I/home/alison/gitsrc/gcc -I/home/alison/gitsrc/folly
/home/alison/gitsrc/googletest/googletest/make/libgtest.a
/home/alison/gitsrc/googletest/googletest/make/libgtest_main.a
/home/alison/gitsrc/fbcode-install/folly/lib/libfolly.a
/home/alison/gitsrc/fbcode-install/folly/lib/libfolly_test_util.a
arg_classifier_lib_test.cc -o arg_classifier_lib_test
In file included from
/home/alison/gitsrc/folly/folly/tracing/StaticTracepoint.h:22,
from arg_classifier.h:8,
from arg_classifier_lib_test.cc:12:
arg_classifier.h: In instantiation of ‘bool
arg_classify::maybe_insert_folly_sdt_probe(const char*, const char*, T, Pars
...) [with T = int; Pars = {int}]’:
arg_classifier_lib_test.cc:194:3: required from here
/home/alison/gitsrc/folly/folly/tracing/StaticTracepoint-ELFx86.h:53:65:
internal compiler error: Segmentation fault
[Bug fortran/98979] [11 regression] ICE in several tests cases after r11-7112
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98979 David Edelsohn changed: What|Removed |Added Target|powerpc64*-linux-gnu, |powerpc64*-linux-gnu, |x86_64-apple-darwin20.3.0 |x86_64-apple-darwin20.3.0, ||powerpc*-aix CC||dje at gcc dot gnu.org Host|powerpc64*-linux-gnu, |powerpc64*-linux-gnu, |x86_64-apple-darwin20.3.0 |x86_64-apple-darwin20.3.0, ||powerpc*-aix Build|powerpc64*-linux-gnu, |powerpc64*-linux-gnu, |x86_64-apple-darwin20.3.0 |x86_64-apple-darwin20.3.0, ||powerpc*-aix --- Comment #2 from David Edelsohn --- AIX also.
[Bug tree-optimization/98982] Optimizing loop variants of fixed-byte-order functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98982 --- Comment #1 from Julian Andres Klode --- Verified with gcc version 11.0.0 20210203 (experimental) [master revision e8c87bc07b5:def4749fcba:84110515b93a6709de24240d6658ac207db5129f] (Ubuntu 11-20210203-0ubuntu1)
[Bug tree-optimization/98982] New: Optimizing loop variants of fixed-byte-order functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98982
Bug ID: 98982
Summary: Optimizing loop variants of fixed-byte-order functions
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: j...@jak-linux.org
Target Milestone: ---
These functions actually generate loops whereas they should just be optimized
to no-ops.
It's the classic byte-read/write idiom for little endian encoded integers, just
written as a loop, to accomodate varying sizeof(T) in the template.
template
struct little_endian
{
uint8_t data[sizeof(T)];
constexpr little_endian() : data{}
{
}
constexpr little_endian(T in)
{
for (size_t i = 0; i < sizeof(T); i++)
data[i] = (in >> (8 * i)) & 0xFF;
}
constexpr operator T() const
{
T res = 0;
for (size_t i = 0; i < sizeof(T); i++)
res |= static_cast(data[i]) << (8u * i);
return res;
}
};
-O3 or -funroll-loops correctly unrolls the encoding (the constructor), but the
operator T() still ends up being
▸ endbr64
▸ movabsq▸$72057594037927935, %rdx
▸ movq▸ %rdi, %rax
▸ shrq▸ $56, %rax
▸ andq▸ %rdi, %rdx
▸ salq▸ $56, %rax
▸ orq▸%rdx, %rax
▸ ret
Seems weird to me.
[Bug libstdc++/98978] Consider packing _M_Engaged in the tail padding of T in optional<>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98978 --- Comment #4 from Jonathan Wakely --- (In reply to andysem from comment #3) > Is there no way to improve standard components implementation? I'd imagine > you could provide the new implementation in the new version inline namespace > and still support the old ABI for backward compatibility. Yes ABI changes can be done for the --enable-symvers=gnu-versioned-namespace configuration, but nobody uses it so anything invasive like this is not worth the effort. > This would be more problematic as emplace(), value() and operator*() need to > return T&, which would not be possible. Use 0xff to mean disengaged, and 0x00 and 0x01 for engaged. You only need to return a reference when it's engaged.
[Bug analyzer/98969] [11 Regression] ICE: Segmentation fault (in print_mem_ref)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98969
--- Comment #8 from Martin Sebor ---
For reference, this is the change I used to test the MEM_REF formatting:
diff --git a/gcc/tree-ssa-uninit.c b/gcc/tree-ssa-uninit.c
index 0800f596ab1..0f47c0c286d 100644
--- a/gcc/tree-ssa-uninit.c
+++ b/gcc/tree-ssa-uninit.c
@@ -251,6 +251,9 @@ maybe_warn_operand (ao_ref &ref, gimple *stmt, tree lhs,
tree rhs,
if (TREE_NO_WARNING (rhs))
return NULL_TREE;
+ if (TREE_CODE (rhs) == MEM_REF)
+inform (gimple_location (stmt), "MEM_REF = %qE", rhs);
+
/* Do not warn if the base was marked so or this is a
hard register var. */
tree base = ao_ref_base (&ref);
And the reduced test case (doesn't ICE with xgcc):
$ cat a.c && g++ -O2 -S -Wall a.c
void clear_bit_region (unsigned char*, unsigned, unsigned);
void verify_clear_bit_region (void)
{
unsigned char orig[3] = { 1, 1, 1 }, in[3];
__builtin_memcpy (in, orig, sizeof in);
clear_bit_region (in, 0, 3 * (8));
}
‘
during GIMPLE pass: *early_warn_uninitialized
In function ‘void verify_clear_bit_region()’:
canonical types differ for identical types ‘unsigned char [3]’ and ‘unsigned
char [3]’
8 | }
| ^
0xe61a0a comptypes(tree_node*, tree_node*, int)
/src/gcc/master/gcc/cp/typeck.c:1540
0xe61c07 same_type_ignoring_top_level_qualifiers_p(tree_node*, tree_node*)
/src/gcc/master/gcc/cp/typeck.c:1576
0xaf4fe0 cxx_types_compatible_p(tree_node*, tree_node*)
/src/gcc/master/gcc/cp/cp-objcp-common.c:123
0xf4f98e c_fold_indirect_ref_for_warn
/src/gcc/master/gcc/c-family/c-pretty-print.c:1829
0xf50695 print_mem_ref
/src/gcc/master/gcc/c-family/c-pretty-print.c:1953
0xf515bd c_pretty_printer::unary_expression(tree_node*)
/src/gcc/master/gcc/c-family/c-pretty-print.c:2171
0xbad752 dump_expr
/src/gcc/master/gcc/cp/error.c:2422
0xbb0ed8 expr_to_string(tree_node*)
/src/gcc/master/gcc/cp/error.c:3188
0xbb4ffd cp_printer
/src/gcc/master/gcc/cp/error.c:4356
0x2cba14f pp_format(pretty_printer*, text_info*)
/src/gcc/master/gcc/pretty-print.c:1475
0x2c8ffd5 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
/src/gcc/master/gcc/diagnostic.c:1244
0x2c90675 diagnostic_impl
/src/gcc/master/gcc/diagnostic.c:1406
0x2c90ad3 inform(unsigned int, char const*, ...)
/src/gcc/master/gcc/diagnostic.c:1485
0x1c107c7 maybe_warn_operand
/src/gcc/master/gcc/tree-ssa-uninit.c:255
0x1c11bf1 warn_uninitialized_vars
/src/gcc/master/gcc/tree-ssa-uninit.c:660
0x1c17374 execute_early_warn_uninitialized
/src/gcc/master/gcc/tree-ssa-uninit.c:3092
0x1c173f2 execute
/src/gcc/master/gcc/tree-ssa-uninit.c:3127
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug analyzer/98969] [11 Regression] ICE: Segmentation fault (in print_mem_ref)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98969
--- Comment #7 from Martin Sebor ---
I had already dealt with this problem in the pretty printer in r11-6621 (the
same way as in comment #2) but it regressed with Jakub's subsequent changes in
r11-6729. It's also not the only regression that Jakub's change seems to have
caused. Instrumenting GCC to print every MEM_REF it sees in
maybe_warn_operand() in tree-ssa-uninit.c causes the ICE below that I didn't
get when testing r11-6621.
I agree the pretty printer should as much as possible try to behave robustly
for bad MEM_REfs, if only to make debugging easier.
...
during GIMPLE pass: *early_warn_uninitialized
In function ‘void selftest::verify_clear_bit_region()’:
canonical types differ for identical types ‘unsigned char [3]’ and ‘unsigned
char [3]’
5499 | } // namespace selftest
| ^
0xe61a0a comptypes(tree_node*, tree_node*, int)
/src/gcc/master/gcc/cp/typeck.c:1540
0xe61c07 same_type_ignoring_top_level_qualifiers_p(tree_node*, tree_node*)
/src/gcc/master/gcc/cp/typeck.c:1576
0xaf4fe0 cxx_types_compatible_p(tree_node*, tree_node*)
/src/gcc/master/gcc/cp/cp-objcp-common.c:123
0xf4f98e c_fold_indirect_ref_for_warn
/src/gcc/master/gcc/c-family/c-pretty-print.c:1829
0xf50695 print_mem_ref
/src/gcc/master/gcc/c-family/c-pretty-print.c:1953
0xf515bd c_pretty_printer::unary_expression(tree_node*)
/src/gcc/master/gcc/c-family/c-pretty-print.c:2171
0xbad752 dump_expr
/src/gcc/master/gcc/cp/error.c:2422
0xbb0ed8 expr_to_string(tree_node*)
/src/gcc/master/gcc/cp/error.c:3188
0xbb4ffd cp_printer
/src/gcc/master/gcc/cp/error.c:4356
0x2cba14f pp_format(pretty_printer*, text_info*)
/src/gcc/master/gcc/pretty-print.c:1475
0x2c8ffd5 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
/src/gcc/master/gcc/diagnostic.c:1244
0x2c90675 diagnostic_impl
/src/gcc/master/gcc/diagnostic.c:1406
0x2c90ad3 inform(unsigned int, char const*, ...)
/src/gcc/master/gcc/diagnostic.c:1485
0x1c107c7 maybe_warn_operand
/src/gcc/master/gcc/tree-ssa-uninit.c:255
0x1c11bf1 warn_uninitialized_vars
/src/gcc/master/gcc/tree-ssa-uninit.c:660
0x1c17374 execute_early_warn_uninitialized
/src/gcc/master/gcc/tree-ssa-uninit.c:3092
0x1c173f2 execute
/src/gcc/master/gcc/tree-ssa-uninit.c:3127
...
The ICE is for this statement
MEM [(char * {ref-all})&in] = MEM
[(char * {ref-all})&orig];
and the following value of e in print_mem_ref:
unit-size
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea815348 precision:8 min max
pointer_to_this >
BLK
size
unit-size
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffe74c9e70
domain
sizes-gimplified type_6 DI
size
unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffe8f7ad20 precision:64 min max >>
arg:0
unsigned DI size unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffe6e01540>
arg:0
used tree_1 tree_2 tree_6 read decl_5 BLK
/src/gcc/master/gcc/gimple-ssa-store-merging.c:5442:17 size unit-size
align:8 warn_if_not_align:0 context chain >
/src/gcc/master/gcc/gimple-ssa-store-merging.c:5445:15 start:
/src/gcc/master/gcc/gimple-ssa-store-merging.c:5445:15 finish:
/src/gcc/master/gcc/gimple-ssa-store-merging.c:5445:18>
arg:1
constant 0>>
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 --- Comment #48 from Senthil Kumar Selvaraj --- Submitted https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563638.html, which addresses comments made when the work-in-progress version was submitted. There are no regression failures (save for some tests that fail because of code size increase) on atmega128, atxmega128a3, attiny40 and atmega8. Follow up patch https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563779.html improves code size regressions. More patches along the way - fixing some define_splits, and adding CC_CZN and CC_ZN modes, along with enabling the cmpelim pass.
[Bug libgcc/85621] savms/resms have executable stack (lack GNU-stack marking)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85621 Sergei Trofimovich changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Sergei Trofimovich --- FIXED in gcc-11.
[Bug libgcc/85621] savms/resms have executable stack (lack GNU-stack marking)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85621 Sergei Trofimovich changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at redhat dot com Status|NEW |ASSIGNED CC||slyfox at gcc dot gnu.org --- Comment #5 from Sergei Trofimovich --- I think it was fixed with commit 686b1cdfdc46a476056fe4df6e8186be8c889aca Author: Jakub Jelinek Date: Wed Jan 27 11:49:23 2021 +0100 libgcc, i386: Add .note.GNU-stack sections to the ms sse/avx sav/res On Linux, GCC emits .note.GNU-stack sections when compiling code to mark the code as not needing or needing executable stack, missing section means unknown. But assembly files need to be marked manually. We already mark various *.S files in libgcc manually, but the avx_resms64f.o avx_resms64fx.o avx_resms64.o avx_resms64x.o avx_savms64f.o avx_savms64.o sse_resms64f.o sse_resms64fx.o sse_resms64.o sse_resms64x.o sse_savms64f.o sse_savms64.o files aren't marked, so when something links it in, it will require executable stack. Nothing in the assembly requires executable stack though. 2021-01-27 Jakub Jelinek * config/i386/savms64.h: Add .note.GNU-stack section on Linux. * config/i386/savms64f.h: Likewise. * config/i386/resms64.h: Likewise. * config/i386/resms64f.h: Likewise. * config/i386/resms64x.h: Likewise. * config/i386/resms64fx.h: Likewise.
[Bug fortran/88735] Nested assignment triggers call of final method for right hand side
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88735 Ev Drikos changed: What|Removed |Added Attachment #50129|0 |1 is obsolete|| --- Comment #4 from Ev Drikos --- Created attachment 50137 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50137&action=edit Also a test case without allocatable components (In reply to martin from comment #0) Hello Martin, I'm also interest in seeing this bug fixed. The attached test case contains more fields in structure 's'. Yet, it's still a simple reproducer in the sense that a solution may also be relative simple in 'trans_scalar_assign'. If however the structure 's' contained allocatable components the solution would be more complex (again in trans_scalar_assign) and may have many side effects, as happens also with a general solution for the PR/64290. IMHO, there is a piece of code in assignments that perhaps needs redesign. Let's see if a prime maintainer will join the discussion here (or fix the bug). Hope this helps, Ev. Drikos
[Bug fortran/98979] [11 regression] ICE in several tests cases after r11-7112
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98979 Dominique d'Humieres changed: What|Removed |Added Build|powerpc64*-linux-gnu|powerpc64*-linux-gnu, ||x86_64-apple-darwin20.3.0 Host|powerpc64*-linux-gnu|powerpc64*-linux-gnu, ||x86_64-apple-darwin20.3.0 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||iains at gcc dot gnu.org Target|powerpc64*-linux-gnu|powerpc64*-linux-gnu, ||x86_64-apple-darwin20.3.0 Last reconfirmed||2021-02-06 --- Comment #1 from Dominique d'Humieres --- Confirmed on x86_64-apple-darwin20.3.0 FAIL: gfortran.dg/goacc/array-with-dt-2.f90 -O (internal compiler error) FAIL: gfortran.dg/goacc/array-with-dt-2.f90 -O (test for excess errors) FAIL: gfortran.dg/goacc/derived-chartypes-1.f90 -O (internal compiler error) FAIL: gfortran.dg/goacc/derived-chartypes-1.f90 -O (test for excess errors) FAIL: gfortran.dg/goacc/derived-chartypes-2.f90 -O (internal compiler error) FAIL: gfortran.dg/goacc/derived-chartypes-2.f90 -O (test for excess errors) and FAIL: libgomp.oacc-fortran/array-stride-dt-1.f90 -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable -O0 (internal compiler error) FAIL: libgomp.oacc-fortran/array-stride-dt-1.f90 -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable -O0 (test for excess errors) UNRESOLVED: libgomp.oacc-fortran/array-stride-dt-1.f90 -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable -O0 compilation failed to produce executable FAIL: libgomp.oacc-fortran/array-stride-dt-1.f90 -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable -O1 (internal compiler error) FAIL: libgomp.oacc-fortran/array-stride-dt-1.f90 -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable -O1 (test for excess errors) UNRESOLVED: libgomp.oacc-fortran/array-stride-dt-1.f90 -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable -O1 compilation failed to produce executable FAIL: libgomp.oacc-fortran/array-stride-dt-1.f90 -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable -O2 (internal compiler error) FAIL: libgomp.oacc-fortran/array-stride-dt-1.f90 -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable -O2 (test for excess errors) UNRESOLVED: libgomp.oacc-fortran/array-stride-dt-1.f90 -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable -O2 compilation failed to produce executable FAIL: libgomp.oacc-fortran/array-stride-dt-1.f90 -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (internal compiler error) FAIL: libgomp.oacc-fortran/array-stride-dt-1.f90 -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) UNRESOLVED: libgomp.oacc-fortran/array-stride-dt-1.f90 -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions compilation failed to produce executable FAIL: libgomp.oacc-fortran/array-stride-dt-1.f90 -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable -O3 -g (internal compiler error) FAIL: libgomp.oacc-fortran/array-stride-dt-1.f90 -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable -O3 -g (test for excess errors) UNRESOLVED: libgomp.oacc-fortran/array-stride-dt-1.f90 -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable -O3 -g compilation failed to produce executable FAIL: libgomp.oacc-fortran/array-stride-dt-1.f90 -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable -Os (internal compiler error) FAIL: libgomp.oacc-fortran/array-stride-dt-1.f90 -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable -Os (test for excess errors) UNRESOLVED: libgomp.oacc-fortran/array-stride-dt-1.f90 -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable -Os compilation failed to produce executable FAIL: libgomp.oacc-fortran/array-stride-dt-1.f90 -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable -g -flto (internal compiler error) FAIL: libgomp.oacc-fortran/array-stride-dt-1.f90 -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable -g -flto (test for excess errors) UNRESOLVED: libgomp.oacc-fortran/array-stride-dt-1.f90 -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable -g -flto compilation failed to produce executable FAIL: libgomp.oacc-fortran/array-stride-dt-1.f90 -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable -g -O3 -fwhole-program -flto (inte
[Bug c++/98975] Infinite loop produces no assembly (including returning) with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98975 --- Comment #7 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #6) > That is not what the UB in the testcase is, it is the out of bound accesses > to the array - arr[2] and above. > The bsort function has auto return type, but as there is no return, it is > deduced to be void. And the UB would be there even with j < 3 instead of i > < 3 (and even with j < 2). Whoops I forgot to look the source to see which UB was happening.
[Bug c++/98975] Infinite loop produces no assembly (including returning) with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98975 --- Comment #6 from Jakub Jelinek --- That is not what the UB in the testcase is, it is the out of bound accesses to the array - arr[2] and above. The bsort function has auto return type, but as there is no return, it is deduced to be void. And the UB would be there even with j < 3 instead of i < 3 (and even with j < 2).
[Bug c++/98232] [9 Regression] ICE when compiling libreoffice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98232 --- Comment #8 from Hussam Al-Tayeb --- (In reply to Hussam Al-Tayeb from comment #7) > The patch in bug 95719 fixes the ICE. Can you please backport it to the > gcc-9 branch? > Also we need some methodology for followup patches so they are marked as > candidates for stable branches as well. > > In this case https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=0ddb93ce77374004 > is the initial patch which was applied to 10 and 9 branches. > The a followup patch > https://gcc.gnu.org/g:554eb7d2e1ef5660d6a8e1c12ee1d751a70bbf31 was only > applied in gcc-10 branch but not gcc-9 branch. For the record, libreoffice compiles correctly with gcc 9.3.1 20210205 with that gcc patch.
