[Bug fortran/98686] Namelist group objects shall be defined before appearing in namelist for -std=f2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98686 --- Comment #3 from Jerry DeLisle --- I am changing the word 'defined' to 'declared'.
[Bug target/99094] [AIX] Thread local uninitialized data allocated in .comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99094 David Edelsohn changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Assignee|unassigned at gcc dot gnu.org |dje at gcc dot gnu.org Target Milestone|--- |11.0 Last reconfirmed||2021-02-14 --- Comment #1 from David Edelsohn --- Confirmed.
[Bug target/99094] New: [AIX] Thread local uninitialized data allocated in .comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99094 Bug ID: 99094 Summary: [AIX] Thread local uninitialized data allocated in .comm Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: dje at gcc dot gnu.org Target Milestone: --- Target: powerpc-ibm-aix* GCC on AIX generates thread local uninitialized data in the common section, which could conflict with another module. $ cat static2.c static _Thread_local int x; $ cat static2.s ... .comm x[UL],4 The symbol should be allocated in the TLS lcomm BSS section.
[Bug fortran/98686] Namelist group objects shall be defined before appearing in namelist for -std=f2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98686 Jerry DeLisle changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org Status|NEW |ASSIGNED CC||jvdelisle at gcc dot gnu.org --- Comment #2 from Jerry DeLisle --- I have this working: pr98686.f90:2:19: 2 | namelist /NML/ x, m, q | 1 Error: Symbol ‘x’ in namelist ‘nml’ at (1) must be defined before the namelist is declared. Does this read OK?
[Bug c++/99093] New: [missed optimization] Missed devirtualization involving internal-linkage class type (but only sometimes)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99093
Bug ID: 99093
Summary: [missed optimization] Missed devirtualization
involving internal-linkage class type (but only
sometimes)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
// https://godbolt.org/z/hx7h7v
struct Base {
virtual int f() { return 1; }
};
namespace {
struct Derived1 : public Base {
int f() override { return 2; }
};
struct Derived2 : public Base {};
}
int leaf_class1(Base *p) { return ((Derived1*)p)->f(); }
// devirtualized by GCC, because PrivateDerived is provably a leaf
int leaf_class2(Base *p) { return ((Derived2*)p)->f(); }
// not devirtualized by GCC -- this smells like a missed-optimization bug
GCC 4.9 started to be able to devirtualize things in the compiler, based on
translation-unit-wide (but still compiler-time) information. GCC 4.9.0 is able
to devirtualize the call in `leaf_class1`. This is awesome!
However, both GCC 4.9 and GCC trunk fail to apply the exact same optimization
to `leaf_class2`. The only difference between `Derived1` and `Derived2` is that
`Derived1::f` is declared directly in `Derived1` whereas `Derived2::f` is
technically a member of `Base`. That shouldn't matter at all to the
devirtualization logic. But apparently it does.
Barely possibly related missed-devirtualization bugs: #47316, #60674, #89924,
#94243.
[Bug ada/98996] mips64 ada ftbfs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98996 --- Comment #2 from YunQiang Su --- Created attachment 50180 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50180=edit it generates subreg instead of reg
[Bug c/89807] Incorrect -Wconversion warning when shifting uint32_t with 24
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89807
--- Comment #1 from Hannes Domani ---
(In reply to Nickolay Kolchin-Semyonov from comment #0)
> uint8_t a = (v >> 24) & 0xFF; // ERROR: produces warning
> uint8_t a2 = v >> 24; // ERROR: produces warning
I think the '& 0xFF' part is optimized away, so for the warning, this is
basically the same code.
In unsafe_conversion_p() is an extra check if the result of a bitwise-and
operation fits in the target type, and that's the reason the other lines don't
get a warning.
The following adds a similar check for the result of a right-shift operation:
--- gcc/c-family/c-common.c 2020-07-23 08:35:17.296384000 +0200
+++ gcc/c-family/c-common.c 2021-02-14 00:53:07.130219200 +0100
@@ -1488,6 +1488,26 @@
return SAFE_CONVERSION;
}
}
+ else if (TREE_CODE (expr) == RSHIFT_EXPR)
+ {
+ tree op0 = TREE_OPERAND (expr, 0);
+ tree op1 = TREE_OPERAND (expr, 1);
+
+ /* Don't warn if the result of an unsigned value, right shifted
+by a constant, fits in the target type. */
+ if (TYPE_UNSIGNED (TREE_TYPE (op0))
+ && TREE_CODE (op1) == INTEGER_CST)
+ {
+ int prec_rshift = TYPE_PRECISION (TREE_TYPE (op0))
+ - TREE_INT_CST_LOW (op1);
+ int prec_res = TYPE_PRECISION (type);
+ if (!TYPE_UNSIGNED (type))
+ prec_res--;
+
+ if (prec_rshift <= prec_res)
+ return SAFE_CONVERSION;
+ }
+ }
/* Warn for integer types converted to smaller integer types. */
if (TYPE_PRECISION (type) < TYPE_PRECISION (expr_type))
give_warning = UNSAFE_OTHER;
PS: This is possibly a dup of PR83122.
[Bug middle-end/96900] [9/10/11 Regression] bogus -Warray-bounds on strlen with valid pointer obtained from just-past-the-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96900 Martin Sebor changed: What|Removed |Added Last reconfirmed||2021-02-14 Blocks||56456 Ever confirmed|0 |1 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=84050 Status|UNCONFIRMED |NEW --- Comment #4 from Martin Sebor --- Confirmed. See also pr84050 for another bug caused by fold_nonarray_ctor_reference() returning a scalar zero for out-of-bounds references (that one is a false negative). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 [Bug 56456] [meta-bug] bogus/missing -Warray-bounds
[Bug tree-optimization/92539] [8/9/10/11 Regression] -Warray-bounds false positive with -O3 (loop unroll?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92539
--- Comment #5 from Martin Sebor ---
>From the vrp1 dump it seems that it should be possible to determine that bb 8
and later are unreachable. Might the predicate analysis help here as well?
int main ()
{
const char * last;
int i;
const char * local_iterator;
const char * in;
int _3;
char _5;
bool iftmp.0_13;
[local count: 118111600]:
goto ; [100.00%]
[local count: 955630225]:
last_4 = last_2 + 1;
[local count: 1073741824]:
# last_2 = PHI <"aa"(2), last_4(3)>
_5 = *last_2;
if (_5 != 0)
goto ; [89.00%]
else
goto ; [11.00%]<<< *last_2 ==
'\0' implies last_2 == "aa" + 2
[local count: 118111600]:
# last_12 = PHI
if (last_12 != "aa") <<< true
goto ; [54.59%]
else
goto ; [45.41%]
[local count: 64477123]:
if (last_12 != [(void *)"aa" + 1B]) <<< true
goto ; [54.59%]
else
goto ; [45.41%]
[local count: 55926445]:
if (last_12 != [(void *)"aa" + 2B]) <<< false
goto ; [54.59%]
else
goto ; [45.41%]
[local count: 30530247]:
if (last_12 != [(void *)"aa" + 3B])
goto ; [54.59%]
else
goto ; [45.41%]
[local count: 14456228]:
if (last_12 != [(void *)"aa" + 5B])
goto ; [54.59%]
else
goto ; [45.41%]
[local count: 59055800]:
if (last_12 == [(void *)"aa" + 6B])
goto ; [30.00%]
else
goto ; [70.00%]
[local count: 100394860]:
[local count: 118111600]:
# iftmp.0_13 = PHI <0(12), 1(11)>
_3 = (int) iftmp.0_13;
return _3;
}
[Bug middle-end/90663] [8/9 Regression] strcmp ([i], a + i) not folded for arrays and constant index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90663 Martin Sebor changed: What|Removed |Added Known to fail|10.0|10.2.0, 11.0 --- Comment #4 from Martin Sebor --- No progress in GCC 11.
[Bug fortran/99092] New: Using -O3 and -fprefetch-loop-arrays to compile BLAS on Apple M1 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99092 Bug ID: 99092 Summary: Using -O3 and -fprefetch-loop-arrays to compile BLAS on Apple M1 fails Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jeff.science at gmail dot com Target Milestone: --- Created attachment 50179 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50179=edit source code that triggers bug I am using GCC 10.2.1 installed via Homebrew on an Apple M1 system. I attempted to compile one of the functions from the BLAS and it fails as follows. The failure is triggered by the combined use of -O3 and -fprefetch-loop-arrays. Reducing to -O2 or removing the latter eliminates the issue, so there is a simple workaround. Nonetheless, I encountered it the first time I tried to build NWChem on this platform, so it will be seen by others until I can fix the NWChem build system to avoid it. I do not see this issue on x86, although I am not sure if I have tested GCC 10.2.1 specifically. % wget https://netlib.sandia.gov/blas/ctrsm.f # also attached % gfortran -O3 -fprefetch-loop-arrays -c ctrsm.f && echo OKAY /var/folders/8n/llwp7zmd4jx697g8sw5w46p0gn/T//ccj3jW77.s:362:23: error: index must be a multiple of 8 in range [0, 32760]. prfmPLDL1KEEP, [x0, -8] ^ % gfortran -O2 -fprefetch-loop-arrays -c ctrsm.f && echo OKAY OKAY % gfortran -O3 -c ctrsm.f && echo OKAY OKAY % gfortran --version GNU Fortran (Homebrew GCC 10.2.0_3) 10.2.1 20201220 Copyright (C) 2020 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug tree-optimization/84050] [8/9/10/11 Regression] missing -Warray-bounds accessing a struct array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84050 Martin Sebor changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #8 from Martin Sebor --- I'll look into it for GCC 12.
[Bug tree-optimization/84050] [8/9/10/11 Regression] missing -Warray-bounds accessing a struct array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84050 Martin Sebor changed: What|Removed |Added Known to fail|10.0|10.2.0, 11.0 --- Comment #7 from Martin Sebor --- (In reply to Aldy Hernandez from comment #2) ... > I'm not a language lawyer, so I don't know what the semantics of undefined > behavior is. Is returning 0 even the correct thing to do? Anything goes for undefined behavior so folding the access to zero is strictly valid. But doing it silently, without issuing a warning designed to detect this bug, is at a minimum unfriendly (I'd even say it's a bug in the warning). I believe the problem is in fold_nonarray_ctor_reference(): the function doesn't make sure the reference is in bounds of the object. It simply returns zero when it isn't om the assumption reflected in a comment removed in r274837: /* Memory not explicitly mentioned in constructor is 0. */ The function assumes that when the constructor is smaller than the type of the declared object the reference is to an element of the object. But that's only true for valid references, not for those that are out of bounds. So before returning zero, the function should check that the offset into the object plus the element size doesn't exceed the size of the object and if it does, return null. I suspect a fix wouldn't be considered in stage 4 of GCC 11 but it's something to look into for GCC 12.
[Bug c++/99091] New: constexpr variable evaluated at runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99091
Bug ID: 99091
Summary: constexpr variable evaluated at runtime
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
Consider the following (link to compiler explorer:
https://godbolt.org/z/jWsxsK)
#include
static constexpr auto doy = []{
std::array month_offset{};
for (int m=1; m<=12;++m) {
month_offset[m] = (153*(m > 2 ? m-3 : m+9) + 2)/5;
}
return month_offset;
}();
auto foo(int m) -> int {
#ifdef LOCAL
constexpr auto doy = []{
std::array month_offset{};
for (int m=1; m<=12;++m) {
month_offset[m] = (153*(m > 2 ? m-3 : m+9) + 2)/5;
}
return month_offset;
}();
#endif
return doy[m];
}
This is a fragment of code that does some calculation to figure out the date,
which isn't super important. If LOCAL is not defined (i.e. we declare the array
as a namespace-scope constexpr), the -O3 codegen of 'foo' is:
foo(int):
movsx rdi, edi
mov eax, DWORD PTR doy[0+rdi*4]
ret
However, if we want to move the declaration of doy to be more local to the
calculation and compile with -DLOCAL, the codegen instead is (on -O3):
foo(int):
pxorxmm0, xmm0
mov rax, QWORD PTR .LC0[rip]
movsx rdi, edi
mov DWORD PTR [rsp-24], 275
movaps XMMWORD PTR [rsp-72], xmm0
movdqa xmm0, XMMWORD PTR .LC1[rip]
mov QWORD PTR [rsp-68], rax
movaps XMMWORD PTR [rsp-56], xmm0
movdqa xmm0, XMMWORD PTR .LC2[rip]
movaps XMMWORD PTR [rsp-40], xmm0
mov eax, DWORD PTR [rsp-72+rdi*4]
ret
This can be alleviated by marked the local variable doy as being static
constexpr. Except that this prevents 'foo' from being a constexpr function
(can't have static variables).
This just seems like bad codegen, I'm not sure there's any reason that the
compiler needs to do work here. It would be nice if the codegen with a local
constexpr variable were the same as if it were a non-local constexpr variable.
[Bug fortran/95647] operator(.eq.) and operator(==) treated differently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95647 Jerry DeLisle changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from Jerry DeLisle --- Fixed on trunk and gcc-10
[Bug libfortran/98825] Unexpected behavior of FORTRAN FORMAT expressions when suppressing new line with '$'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98825 Jerry DeLisle changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #11 from Jerry DeLisle --- Fixed on trunk. Thanks for report.
[Bug debug/99090] New: gsplit-dwarf broken on riscv64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99090 Bug ID: 99090 Summary: gsplit-dwarf broken on riscv64-linux Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: wilson at gcc dot gnu.org Target Milestone: --- Enabling -gsplit-dwarf by default and trying a build hits an assert in dw2_asm_output_delta_uleb128 because HAVE_AS_LEB128 is not defined. The problem appears to be in output_loc_list in dwarf2out.c which has in the dwarf_split_debug_info code /* FIXME: This will ICE ifndef HAVE_AS_LEB128. For that case we probably need to emit DW_LLE_startx_endx, but we'd need 2 .debug_addr entries rather than just one. */ riscv doesn't allow leb128 because of agressive linker relaxation, so we need the alternative solution here that works without HAVE_AS_LEB128.
[Bug target/99089] New: unnecessary zero extend before AND
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99089
Bug ID: 99089
Summary: unnecessary zero extend before AND
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: wilson at gcc dot gnu.org
Target Milestone: ---
Given this testcase extracted from newlib
struct s
{
short s;
int i;
};
extern void sub2 (void);
extern void sub3 (void);
int
sub (struct s* t)
{
short i = t->s;
if ((i & 0x8) == 0)
t->s |= 0x800;
if ((t->s & 0x3) == 0)
sub3 ();
t->i = i;
return 0;
}
compiling for riscv32-elf with -O2 -S and looking at assembly code, I see two
places where we have
sllia5,a5,16
srlia5,a5,16
andia5,a5,3
The zero extend before the AND is clearly unnecessary.
It seems a complex set of circumstances leads to here. The tree level
optimizer extends the lifetime of the first zero extend into a phi, which means
the operation is split across basic blocks. This also means no REG_DEAD note
and no combine. It isn't until 309 bbro that the zero extend and AND end up
back in the same basic block again, and that is too late to optimize it as
nothing after 309 bbro can fix this.
So it appears we need a global rtl pass that can notice and fix redundant zero
extends feeding into AND operations across basic blocks.
[Bug target/97417] RISC-V Unnecessary andi instruction when loading volatile bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417 Jim Wilson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #62 from Jim Wilson --- I committed my shorten memrefs patch and Levy's patch minus the combine change. I don't believe that we need the combine change. I did notice one interesting case where we get unnecesssary zero extends. I will submit that as a new bug report. I also noticed with riscv64-linux testing that some -gsplit-dwarf tests fail, but this turns out to be a latent bug in the split-dwarf support. I will submit that as a new bug report. I believe this is fixed, so closing as resolved.
[Bug target/97417] RISC-V Unnecessary andi instruction when loading volatile bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417 --- Comment #61 from CVS Commits --- The master branch has been updated by Jim Wilson : https://gcc.gnu.org/g:18fabc35f47f0abf4ec14d147098ec4e0734d2a3 commit r11-7237-g18fabc35f47f0abf4ec14d147098ec4e0734d2a3 Author: Levy Hsu Date: Sat Feb 13 12:26:33 2021 -0800 RISC-V: Avoid zero/sign extend for volatile loads. Fix for 97417. This expands sub-word loads as a zero/sign extended load, followed by a subreg. This helps eliminate unnecessary zero/sign extend insns after the load, particularly for volatiles, but also in some other cases. Testing shows that it gives consistent code size decreases. Tested with riscv32-elf rv32imac/ilp32 and riscv64-linux rv64gc/lp064d builds and checks. Some -gsplit-stack tests fail with the patch, but this turns out to be an existing bug with the split-stack support that I hadn't noticed before. It isn't a bug in this patch. Ignoring that there are no regressions. Committed. gcc/ PR target/97417 * config/riscv/riscv-shorten-memrefs.c (pass_shorten_memrefs): Add extend parameter to get_si_mem_base_reg declaration. (get_si_mem_base_reg): Add extend parameter. Set it. (analyze): Pass extend arg to get_si_mem_base_reg. (transform): Likewise. Use it when rewriting mems. * config/riscv/riscv.c (riscv_legitimize_move): Check for subword loads and emit sign/zero extending load followed by subreg move.
[Bug target/97417] RISC-V Unnecessary andi instruction when loading volatile bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417 --- Comment #60 from CVS Commits --- The master branch has been updated by Jim Wilson : https://gcc.gnu.org/g:a4953810bac524e19126a2745c75fed58db962c2 commit r11-7236-ga4953810bac524e19126a2745c75fed58db962c2 Author: Jim Wilson Date: Sat Feb 13 12:13:08 2021 -0800 RISC-V: Shorten memrefs improvement, partial fix 97417. We already have a check for riscv_shorten_memrefs in riscv_address_cost. This adds the same check to riscv_rtx_costs. Making this work also requires a change to riscv_compressed_lw_address_p to work before reload by checking the offset and assuming any pseudo reg is OK. Testing shows that this consistently gives small code size reductions. gcc/ PR target/97417 * config/riscv/riscv.c (riscv_compressed_lw_address_p): Drop early exit when !reload_completed. Only perform check for compressed reg if reload_completed. (riscv_rtx_costs): In MEM case, when optimizing for size and shorten memrefs, if not compressible, then increase cost.
[Bug fortran/99027] Incorrect ubound result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99027
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #2 from Tobias Burnus ---
Untested patch:
diff --git a/gcc/fortran/simplify.c b/gcc/fortran/simplify.c
index 23317a2e2d9..6a180ff40f2 100644
--- a/gcc/fortran/simplify.c
+++ b/gcc/fortran/simplify.c
@@ -4170,3 +4170,13 @@ simplify_bound_dim (gfc_expr *array, gfc_expr *kind, int
d, int upper,
{
- if (!gfc_ref_dimen_size (>u.ar, d - 1, >value.integer,
NULL))
+ int d2 = 0, cnt = 0;
+ for (int idx = 0; idx < ref->u.ar.dimen; ++idx)
+ {
+ if (ref->u.ar.dimen_type == DIMEN_ELEMENT)
+ d2++;
+ else if (cnt < d - 1)
+ cnt++;
+ else
+ break;
+ }
+ if (!gfc_ref_dimen_size (>u.ar, d2 + d - 1,
>value.integer, NULL))
goto returnNull;
[Bug c++/99088] New: Failure to error on recursive template instantiation in a reasonable time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99088
Bug ID: 99088
Summary: Failure to error on recursive template instantiation
in a reasonable time
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
templatestruct W{T v;W(T v):v(v){}};
templateint f(T x){f(W(x));}
int main(){f(0);}
This seems to make GCC lag out for an *extremely* long time (at least long
enough that Godbolt kills GCC (20 seconds), I personally do not have a build of
trunk GCC to test this bug on). On GCC 10 and before, this resulted in an error
in a reasonable amount of time (<1 second)
-v output:
Using built-in specs.
COLLECT_GCC=/opt/compiler-explorer/gcc-snapshot/bin/g++
Target: x86_64-linux-gnu
Configured with: ../gcc-trunk-20210213/configure
--prefix=/opt/compiler-explorer/gcc-build/staging --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu --disable-bootstrap
--enable-multiarch --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --enable-clocale=gnu --enable-languages=c,c++,fortran,ada,d
--enable-ld=yes --enable-gold=yes --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-linker-build-id --enable-lto
--enable-plugins --enable-threads=posix
--with-pkgversion=Compiler-Explorer-Build
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20210212 (experimental) (Compiler-Explorer-Build)
COLLECT_GCC_OPTIONS='-fdiagnostics-color=always' '-g' '-o' './output.s'
'-masm=intel' '-S' '-O3' '-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
'-dumpdir' './'
/opt/compiler-explorer/gcc-trunk-20210213/bin/../libexec/gcc/x86_64-linux-gnu/11.0.0/cc1plus
-quiet -v -imultiarch x86_64-linux-gnu -iprefix
/opt/compiler-explorer/gcc-trunk-20210213/bin/../lib/gcc/x86_64-linux-gnu/11.0.0/
-D_GNU_SOURCE -quiet -dumpdir ./ -dumpbase output.cpp -dumpbase-ext
.cpp -masm=intel -mtune=generic -march=x86-64 -g -O3 -version
-fdiagnostics-color=always -o ./output.s
GNU C++17 (Compiler-Explorer-Build) version 11.0.0 20210212 (experimental)
(x86_64-linux-gnu)
compiled by GNU C version 7.5.0, GMP version 6.1.0, MPFR version 3.1.4,
MPC version 1.0.3, isl version isl-0.18-GMP
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory
"/opt/compiler-explorer/gcc-trunk-20210213/bin/../lib/gcc/x86_64-linux-gnu/11.0.0/../../../../x86_64-linux-gnu/include"
ignoring duplicate directory
"/opt/compiler-explorer/gcc-trunk-20210213/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/11.0.0/../../../../include/c++/11.0.0"
ignoring duplicate directory
"/opt/compiler-explorer/gcc-trunk-20210213/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/11.0.0/../../../../include/c++/11.0.0/x86_64-linux-gnu"
ignoring duplicate directory
"/opt/compiler-explorer/gcc-trunk-20210213/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/11.0.0/../../../../include/c++/11.0.0/backward"
ignoring duplicate directory
"/opt/compiler-explorer/gcc-trunk-20210213/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/11.0.0/include"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring duplicate directory
"/opt/compiler-explorer/gcc-trunk-20210213/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/11.0.0/include-fixed"
ignoring nonexistent directory
"/opt/compiler-explorer/gcc-trunk-20210213/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/11.0.0/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/opt/compiler-explorer/gcc-trunk-20210213/bin/../lib/gcc/x86_64-linux-gnu/11.0.0/../../../../include/c++/11.0.0
/opt/compiler-explorer/gcc-trunk-20210213/bin/../lib/gcc/x86_64-linux-gnu/11.0.0/../../../../include/c++/11.0.0/x86_64-linux-gnu
/opt/compiler-explorer/gcc-trunk-20210213/bin/../lib/gcc/x86_64-linux-gnu/11.0.0/../../../../include/c++/11.0.0/backward
/opt/compiler-explorer/gcc-trunk-20210213/bin/../lib/gcc/x86_64-linux-gnu/11.0.0/include
/opt/compiler-explorer/gcc-trunk-20210213/bin/../lib/gcc/x86_64-linux-gnu/11.0.0/include-fixed
/usr/local/include
/opt/compiler-explorer/gcc-trunk-20210213/bin/../lib/gcc/../../include
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
GNU C++17 (Compiler-Explorer-Build) version 11.0.0 20210212 (experimental)
(x86_64-linux-gnu)
compiled by GNU C version 7.5.0, GMP version 6.1.0, MPFR version 3.1.4,
MPC version 1.0.3, isl version isl-0.18-GMP
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: a47483d85f54b7b7df3d6a6237220aa1
COMPILER_PATH=/opt/compiler-explorer/gcc-trunk-20210213/bin/../libexec/gcc/x86_64-linux-gnu/11.0.0/:/opt/compiler-explorer/gc
[Bug middle-end/99087] New: suboptimal codegen for division by constant 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99087
Bug ID: 99087
Summary: suboptimal codegen for division by constant 3
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: vanyacpp at gmail dot com
Target Milestone: ---
These two are functionally the same, but generate different code with g++ -O2:
unsigned long long foo(unsigned long long a)
{
return a / 3;
}
unsigned long long bar(unsigned long long a)
{
return (unsigned __int128)a * 0x'''AAAB >> 65;
}
foo(unsigned long long):
movabs rdx, -6148914691236517205
mov rax, rdi
mul rdx
mov rax, rdx
shr rax
ret
bar(unsigned long long):
movabs rax, -6148914691236517205
mul rdi
mov rax, rdx
shr rax
ret
For some reason for division GCC chooses different argument order which causes
generation of one extra mov.
[Bug rtl-optimization/98439] [11 Regression] ICE in final_scan_insn_1, at final.c:3096
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98439 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Jakub Jelinek --- Fixed.
[Bug rtl-optimization/98439] [11 Regression] ICE in final_scan_insn_1, at final.c:3096
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98439 --- Comment #6 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:05402ca65a6696a8f20a3dbcb18f47ba3bdfa268 commit r11-7235-g05402ca65a6696a8f20a3dbcb18f47ba3bdfa268 Author: Jakub Jelinek Date: Sat Feb 13 16:08:29 2021 +0100 passes: Enable split4 with selective scheduling 2 [PR98439] As mentioned in the PR, we have 5 split passes (+ splitting during final). split1 is before RA and is unconditional, split2 is after RA and is gated on optimize > 0, split3 is before sched2 and is gated on defined(INSN_SCHEDULING) && optimize > 0 && flag_schedule_insns_after_reload split4 is before regstack and is gated on HAVE_ATTR_length && defined (STACK_REGS) && !gate (split3) split5 is before shorten_branches and is gated on HAVE_ATTR_length && !defined (STACK_REGS) and the splitting during final works only when !HAVE_ATTR_length. STACK_REGS is a macro enabled only on i386/x86_64. The problem with the following testcase is that split3 before sched2 is the last splitting pass for the target/command line options set, but selective scheduling unlike normal scheduling can create new instructions that need to be split, which means we ICE during final as there are insns that require splitting but nothing split them. This patch fixes it by doing split4 also when -fselective-scheduling2 is enabled on x86 and split3 has been run. As that option isn't on by default, it should slow down compilation only for those that enable that option. 2021-02-13 Jakub Jelinek PR rtl-optimization/98439 * recog.c (pass_split_before_regstack::gate): Enable even when pass_split_before_sched2 is enabled if -fselective-scheduling2 is on. * gcc.target/i386/pr98439.c: New test.
[Bug c++/99086] New: including and defaulting spaceship operator causes compiler segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99086
Bug ID: 99086
Summary: including and defaulting spaceship operator
causes compiler segfault
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: crillion at tiscali dot it
Target Milestone: ---
Created attachment 50178
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50178=edit
an archive containing .ii and .s files for windows and linux
Hi,
a little program with a tiny class defaulting the spaceship operator and the
inclusion of header causes compiler segfault (the compiler gives
segmentation error while compiling, no executable is produced).
I could see this behaviour on these systems :
(windows 10 64bit)
(it's the g++ 10.2 from mingw-w64 distribution obtained by msys2)
g++ --version
g++ (Rev6, Built by MSYS2 project) 10.2.0
(linux opensuse 15.2 64bit, hosted on virtual box 6.1.16 r140961 (Qt5.6.2),
running on my above windows system)
> g++ --version
g++ (SUSE Linux) 10.2.1 20200825 [revision
c0746a1beb1ba073c7981eb09f55b3d993b32e5c]
==
program.cpp :
--
#include
class value_wrapper
{
public :
bool operator<=>(const value_wrapper& rhs) const = default;
private :
unsigned short value_;
};
int main(int, char**)
{
value_wrapper lhs, rhs;
auto x = lhs < rhs;
}
=
batch file used to compile it (already including your recommended switches in
bug reporting instructions, which turn out not to mitigate the segfault error)
windows :
g++ -std=c++20 -pedantic -Wall -Wextra -Werror=return-type -Wshadow=local
-Wempty-body -fdiagnostics-color -s -Os -fno-strict-aliasing -fwrapv
-fno-aggressive-loop-optimizations program.cpp -save-temps -o program_gpp.exe
linux :
g++ -std=c++20 -pedantic -Wall -Wextra -Werror=return-type -Wshadow=local
-Wempty-body -fdiagnostics-color -s -Os -fno-strict-aliasing -fwrapv
-fno-aggressive-loop-optimizations program.cpp -save-temps -o program_gpp
I add as attachment a 7zip archive containing the requested .ii and .s files
respectively for the windows and linux compilation:
program.ii.linux
program.ii.windows
program.s.linux
program.s.windows
I was originally using a field of type boost gregorian date, which in turn
causes inclusion of . I could reduce boost include files just to the
inclusion of
Sorry but I didn't reduce, nor inspect the header, since I consider
standard library headers too complicated for me to analyze.
Thanks,
Marco
[Bug tree-optimization/93721] swapping adjacent scalars could be more efficient
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93721 Nikita Kniazev changed: What|Removed |Added CC||nok.raven at gmail dot com --- Comment #7 from Nikita Kniazev --- The SLP regression was reported in bug 96166.
[Bug ada/98996] mips64 ada ftbfs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98996 --- Comment #1 from YunQiang Su --- 96=64+32, so the rtl should be a ldl/ldr + lwl/lwr It should be: (insn 377 376 378 16 (set (reg:SI 499) (unspec:SI [ (mem:BLK (plus:DI (reg/f:DI 216 [ _65 ]) (const_int 8 [0x8])) [0 +8 S4 A8]) (mem:QI (plus:DI (reg/f:DI 216 [ _65 ]) (const_int 11 [0xb])) [0 +11 S1 A8]) ] UNSPEC_LOAD_LEFT)) "s-pack96.adb":160:23 -1 (nil))
[Bug fortran/99027] Incorrect ubound result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99027 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-02-13 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed since at least GCC7.
[Bug fortran/99065] ASSOCIATE function selector expression "no IMPLICIT type" failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99065 Dominique d'Humieres changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-02-13 Status|UNCONFIRMED |NEW --- Comment #1 from Dominique d'Humieres --- Confirmed since at least GCC7.
[Bug fortran/98897] Erroneous procedure attribute for associate name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98897 Dominique d'Humieres changed: What|Removed |Added CC||Bader at lrz dot de --- Comment #7 from Dominique d'Humieres --- *** Bug 67744 has been marked as a duplicate of this bug. ***
[Bug fortran/67744] [OOP] polymorphic associating entity is refused TBP invocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67744 Dominique d'Humieres changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #6 from Dominique d'Humieres --- This PR is fixed at r11-7225, likely r11-7188. It looks as a duplicate of pr98897. *** This bug has been marked as a duplicate of bug 98897 ***
[Bug target/96166] [10 Regression] -O3/-ftree-slp-vectorize turns ROL into a mess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96166 Jakub Jelinek changed: What|Removed |Added Summary|[10/11 Regression] |[10 Regression] |-O3/-ftree-slp-vectorize|-O3/-ftree-slp-vectorize |turns ROL into a mess |turns ROL into a mess --- Comment #12 from Jakub Jelinek --- Fixed on the trunk so far, most likely undesirable for backporting.
[Bug target/96166] [10/11 Regression] -O3/-ftree-slp-vectorize turns ROL into a mess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96166 --- Comment #11 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:0f3a743b688f4845e1798eed9b2e2284e891da11 commit r11-7233-g0f3a743b688f4845e1798eed9b2e2284e891da11 Author: Jakub Jelinek Date: Sat Feb 13 10:32:16 2021 +0100 i386: Add combiner splitter to optimize V2SImode memory rotation [PR96166] Since the x86 backend enabled V2SImode vectorization (with TARGET_MMX_WITH_SSE), slp vectorization can kick in and emit movq(%rdi), %xmm1 pshufd $225, %xmm1, %xmm0 movq%xmm0, (%rdi) instead of rolq$32, (%rdi) we used to emit (or emit when slp vectorization is disabled). I think the rotate is both smaller and faster, so this patch adds a combiner splitter to optimize that back. 2021-02-13 Jakub Jelinek PR target/96166 * config/i386/mmx.md (*mmx_pshufd_1): Add a combine splitter for swap of V2SImode elements in memory into DImode memory rotate by 32. * gcc.target/i386/pr96166.c: New test.
[Bug target/99083] Big run-time regressions of 519.lbm_r with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
--- Comment #1 from Uroš Bizjak ---
This should be a no-op. According to the documentation:
--q--
Macro: REG_ALLOC_ORDER
If defined, an initializer for a vector of integers, containing the numbers
of hard registers in the order in which GCC should prefer to use them (from
most preferred to least).
If this macro is not defined, registers are used lowest numbered first (all
else being equal).
One use of this macro is on machines where the highest numbered registers
must always be saved and the save-multiple-registers instruction supports only
sequences of consecutive registers. On such machines, define REG_ALLOC_ORDER to
be an initializer that lists the highest numbered allocable register first.
--/q--
and the patch removed:
-#define REG_ALLOC_ORDER
\
-{ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,
\
- 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, \
- 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, \
- 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, \
- 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75 }
It is trivial to revert the offending commit, but I think that this PR warrants
some more analysis of the underlying problem, presumably in the generic code.
