[Bug tree-optimization/88606] New: [9 Regression] ICE: verify_type failed (error: type variant differs by TYPE_TRANSPARENT_AGGR)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88606 Bug ID: 88606 Summary: [9 Regression] ICE: verify_type failed (error: type variant differs by TYPE_TRANSPARENT_AGGR) Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: 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 gcc-9.0.0-alpha20181223 snapshot (r267388) ICEs when compiling gcc/testsuite/gcc.dg/transparent-union-6.c w/ -m32 -mcpu=403 (=8540, =8548) -flto -fpack-struct: % powerpc-e300c3-linux-gnu-gcc-9.0.0-alpha20181223 -m32 -mcpu=403 -flto -fpack-struct -w -c gcc/testsuite/gcc.dg/transparent-union-6.c gcc/testsuite/gcc.dg/transparent-union-6.c:17:1: error: type variant differs by TYPE_TRANSPARENT_AGGR 17 | } | ^ constant 32> unit-size constant 4> align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fca981ddf18 fields unit-size align:32 warn_if_not_align:0 symtab:0 alias-set 2 canonical-type 0x7fca981075e8 precision:32 min max pointer_to_this > packed SI gcc/testsuite/gcc.dg/transparent-union-6.c:8:7 size unit-size align:8 warn_if_not_align:0 offset_align 128 offset bit-offset context > context > constant 32> unit-size constant 4> align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fca981ddf18 fields unit-size align:32 warn_if_not_align:0 symtab:0 alias-set 2 canonical-type 0x7fca981075e8 precision:32 min max pointer_to_this > packed SI gcc/testsuite/gcc.dg/transparent-union-6.c:8:7 size unit-size align:8 warn_if_not_align:0 offset_align 128 offset bit-offset context > context > during IPA pass: *free_lang_data gcc/testsuite/gcc.dg/transparent-union-6.c:17:1: internal compiler error: verify_type failed 0xff68db verify_type(tree_node const*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181223/work/gcc-9-20181223/gcc/tree.c:14468 0xff834f free_lang_data /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181223/work/gcc-9-20181223/gcc/tree.c:6237 0xff834f execute /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181223/work/gcc-9-20181223/gcc/tree.c:6282
[Bug tree-optimization/88605] vector extensions: Widening or conversion generates inefficient or scalar code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88605 --- Comment #1 from Andrew Pinski --- __builtin_convertvector is PR 85052
[Bug tree-optimization/88605] New: vector extensions: Widening or conversion generates inefficient or scalar code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88605
Bug ID: 88605
Summary: vector extensions: Widening or conversion generates
inefficient or scalar code.
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: husseydevin at gmail dot com
Target Milestone: ---
If you want to, say, convert a u32x2 vector to a u64x2 while avoiding
intrinsics, good luck.
GCC doesn't have a builtin like __builtin_convertvector, and doing the
conversion manually generates scalar code. This makes clean generic vector code
difficult.
SSE and NEON both have plenty of conversion instructions, such as pmovzxdq or
vmovl.32, but GCC will not emit them.
typedef unsigned long long U64;
typedef U64 U64x2 __attribute__((vector_size(16)));
typedef unsigned int U32;
typedef U32 U32x2 __attribute__((vector_size(8)));
U64x2 vconvert_u64_u32(U32x2 v)
{
return (U64x2) { v[0], v[1] };
}
x86_32:
Flags: -O3 -m32 -msse4.1
Clang Trunk (revision 350063)
vconvert_u64_u32:
pmovzxdqxmm0, qword ptr [esp + 4] # xmm0 =
mem[0],zero,mem[1],zero
ret
GCC (GCC-Explorer-Build) 9.0.0 20181225 (experimental)
convert_u64_u32:
pushebx
sub esp, 40
movqQWORD PTR [esp+8], mm0
mov ecx, DWORD PTR [esp+8]
mov ebx, DWORD PTR [esp+12]
mov DWORD PTR [esp+8], ecx
movdxmm0, DWORD PTR [esp+8]
mov DWORD PTR [esp+20], ebx
movdxmm1, DWORD PTR [esp+20]
mov DWORD PTR [esp+16], ecx
add esp, 40
punpcklqdq xmm0, xmm1
pop ebx
ret
I can't even understand what is going on here, except it is wasting 44 bytes of
stack for no good reason.
x86_64:
Flags: -O3 -m64 -msse4.1
Clang:
vconvert_u64_u32:
pmovzxdqxmm0, xmm0 # xmm0 = xmm0[0],zero,xmm0[1],zero
ret
GCC:
vconvert_u64_u32:
movqrax, xmm0
movdDWORD PTR [rsp-28], xmm0
movdxmm0, DWORD PTR [rsp-28]
shr rax, 32
pinsrq xmm0, rax, 1
ret
ARMv7 NEON:
Flags: -march=armv7-a -mfloat-abi=hard -mfpu=neon -O3
Clang (with --target=arm-none-eabi):
vconvert_u64_u32:
vmovl.u32 q0, d0
bx lr
arm-unknown-linux-gnueabi-gcc (GCC) 8.2.0:
vconvert_u64_u32:
mov r3, #0
sub sp, sp, #16
add r2, sp, #8
vst1.32 {d0[0]}, [sp]
vst1.32 {d0[1]}, [r2]
str r3, [sp, #4]
str r3, [sp, #12]
vld1.64 {d0-d1}, [sp:64]
add sp, sp, #16
bx lr
aarch64 NEON:
Flags: -O3
Clang (with --target=aarch64-none-eabi):
vconvert_u64_u32:
ushll v0.2d, v0.2s, #0
ret
aarch64-unknown-linux-gnu-gcc 8.2.0:
vconvert_u64_u32:
umovw1, v0.s[0]
umovw0, v0.s[1]
uxtwx1, w1
uxtwx0, w0
dup v0.2d, x1
ins v0.d[1], x0
ret
Some other things include things like getting a standalone pmuludq.
In clang, this always generates pmuludq:
U64x2 pmuludq(U64x2 v1, U64x2 v2)
{
return (v1 & 0x) * (v2 & 0x);
}
But GCC generates this:
pmuludq:
movdqa xmm2, XMMWORD PTR .LC0[rip]
pandxmm0, xmm2
pandxmm2, xmm1
movdqa xmm4, xmm2
movdqa xmm1, xmm0
movdqa xmm3, xmm0
psrlq xmm4, 32
psrlq xmm1, 32
pmuludq xmm0, xmm4
pmuludq xmm1, xmm2
pmuludq xmm3, xmm2
paddq xmm1, xmm0
psllq xmm1, 32
paddq xmm3, xmm1
movdqa xmm0, xmm3
ret
.LC0:
.quad 4294967295
.quad 4294967295
and that is the best code it generates. Much worse code is generated depending
on how you write it.
Meanwhile, while it has some struggles with sse2 and x86_64, there is a
reliable way to get Clang to generate pmuludq, and the NEON equivalent,
vmull.u32,
https://godbolt.org/z/H_tOi1
[Bug c++/88604] Initializing constexpr array consumes all memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88604 --- Comment #1 from Hubert Matthews --- Created attachment 45288 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45288&action=edit Source code
[Bug c++/88604] New: Initializing constexpr array consumes all memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88604 Bug ID: 88604 Summary: Initializing constexpr array consumes all memory Product: gcc Version: 8.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: gcc-bugs at oxyware dot com Target Milestone: --- Compiling the attached code with g++ 8.2.1 and no optimisation or compiler flags causes cc1plus to consume all of physical memory until it hits an OOM Linux error. Clang compiles this without any problems. I tried this on gcc.godbolt.org for various compiler versions and the problem is present in many previous versions of g++. The problem doesn't appear if numAirports is set to 500 but it does when at the full 26^3. Also, if latArray[i] is assigned a constant rather than copying a value from the other constexpr class then it works at full size (26^3). Using 4000, cc1plus peaks at 2.1GB of resident RAM. # with numAirports == 4000 $ /usr/bin/time g++ index.cpp 3.27user 1.07system 0:04.38elapsed 99%CPU (0avgtext+0avgdata 2224108maxresident)k 0inputs+144outputs (0major+559502minor)pagefaults 0swaps $ g++ --version g++ (GCC) 8.2.1 20181215 (Red Hat 8.2.1-6) $ uname -a Linux konan.oxyware.net 4.19.8-200.fc28.x86_64 #1 SMP Mon Dec 10 15:43:40 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux $ cat /etc/fedora-release Fedora release 28 (Twenty Eight)
[Bug libfortran/67540] string_intrinsics_inc.c sanitizer detects null pointer passed to memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67540 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Status|NEW |RESOLVED CC||kargl at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #14 from kargl at gcc dot gnu.org --- "We are weighed down, every moment, by the conception and the sensation of Time. And there are but two means of escaping and forgetting this nightmare: pleasure and work. Pleasure consumes us. Work strengthens us. Let us choose." Charles Baudelaire *** This bug has been marked as a duplicate of bug 81984 ***
[Bug libfortran/81984] NULL string pointer dereferencing forces undefined behaviour in libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81984 --- Comment #5 from kargl at gcc dot gnu.org --- *** Bug 67540 has been marked as a duplicate of this bug. ***
[Bug fortran/85357] ICE on invalid code with equal procedure names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85357 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Status|NEW |RESOLVED CC||kargl at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #9 from kargl at gcc dot gnu.org --- Having reviewed the audit trail, I agree with Janus' assessment with regard to the invalid code. The reported ICE is gone on branch-7, branch-8, and trunk. I have converted his code in comment #7 to a testcase and committed it to trunk to ensure that the ICE does not return.
[Bug fortran/85357] ICE on invalid code with equal procedure names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85357 --- Comment #8 from kargl at gcc dot gnu.org --- Author: kargl Date: Wed Dec 26 21:08:53 2018 New Revision: 267423 URL: https://gcc.gnu.org/viewcvs?rev=267423&root=gcc&view=rev Log: 2018-12-26 Steven G. Kargl PR fortran/85357 * gfortran.df/pr85357.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr85357.f90 Modified: trunk/gcc/testsuite/ChangeLog
[Bug fortran/85407] Replace gcc_assert in module.c:read_module by more helpful diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85407 kargl at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #5 from kargl at gcc dot gnu.org --- Fixed on trunk. Harald, sorry about the long delay. Perhaps, we should get you a commit bit. :)
[Bug fortran/85407] Replace gcc_assert in module.c:read_module by more helpful diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85407 --- Comment #4 from kargl at gcc dot gnu.org --- Author: kargl Date: Wed Dec 26 20:37:28 2018 New Revision: 267422 URL: https://gcc.gnu.org/viewcvs?rev=267422&root=gcc&view=rev Log: 2018-12-26 Harald Anlauf PR fortran/85407 * module.c (read_module): Convert assert to fatal error to give user a sensible error message. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c
[Bug c++/80438] Variadic template class argument deduction failure from variadic constructor deduction guide
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80438
Tony E Lewis changed:
What|Removed |Added
CC||TonyELewis at hotmail dot com
--- Comment #1 from Tony E Lewis ---
Here are the notes I wrote before I spotted I was about to file a duplicate of
Vittorio's report...
[C++17] constructor unexpectedly preferred over deduction guide in CTAD
Compiling the following under `-std=c++17` :
#include
template
struct x {
template x(const Ts &...) {}
};
template x(const Ts &...) -> x;
static_assert( std::is_same_v< decltype( x{ 0 } ), x > );
static_assert( ! std::is_same_v< decltype( x{ 0 } ), x< > > );
...I see the two static_assert statements failing under GCC, implying that `x{
0 }` is of type `x<>`, rather than `x` as I would expect. These two
static_assert statements pass under Clang.
I would expect `x` because I would expect the deduction guide to take
precedence over the constructor in determining the type of the expression `x{ 0
}`. AFAIU, this is what's meant by the point in [over.match.best] in the
standard that says F1 is "better" than F2 if:
> [...] F1 is generated from a deduction-guide [...] and F2 is not [...]
(from C++17 draft n4659.pdf and from working draft
http://eel.is/c++draft/over.match.best )
I'm seeing this on the current trunk build of GCC on Godbolt (g++ 9.0.0
20181225 (experimental)).
[Bug c++/88600] GCC rejects attributes on type aliases, while clang accepts them
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88600 --- Comment #2 from Jan Hubicka --- > Applying the attribute to V rather than T works: > > template > using V __attribute__ ((__vector_size (8))) = T; Very cool, I did managed to work that out. Should it work the clang way too?
[Bug fortran/85407] Replace gcc_assert in module.c:read_module by more helpful diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85407 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Version|unknown |9.0 Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org Target Milestone|--- |9.0
[Bug c++/88600] GCC rejects attributes on type aliases, while clang accepts them
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88600 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #1 from Alexander Monakov --- Applying the attribute to V rather than T works: template using V __attribute__ ((__vector_size (8))) = T;
[Bug tree-optimization/88603] New: optimization missed for saturation arithmetic add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88603
Bug ID: 88603
Summary: optimization missed for saturation arithmetic add
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: SztfG at yandex dot ru
Target Milestone: ---
Target: x86_64-linux-gnu
example:
#include
uint32_t saturation_add(uint32_t a, uint32_t b)
{
const uint64_t tmp = (uint64_t)a + b;
if (tmp > UINT32_MAX)
{
return UINT32_MAX;
}
return tmp;
}
output:
mov edx, esi
mov eax, edi
add edi, esi # Why need to add two times here
add rax, rdx # and here ?
mov edx, 4294967295
cmp rax, rdx
mov eax, -1 # Why? edx already have this value. -1 and 4294967295
are same
cmovbe eax, edi
ret
better do something like this:
add edi, esi
mov eax, -1
cmovae eax, edi
ret
[Bug c++/88602] New: Consider adding ext_vector_type for better clang compatibility
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88602 Bug ID: 88602 Summary: Consider adding ext_vector_type for better clang compatibility Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hubicka at gcc dot gnu.org Target Milestone: --- Clang has attribute ext_vector_type which is like vector_size but it accepts number of lanes. This is used by some vector code and while it can be replaced by multiplication by sizeof (elt_type) it may be good idea to add it.
[Bug c++/88601] We may consider adding __builtin_convertvector and __builtin_shufflevector for better compaitbility with Clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88601 Jan Hubicka changed: What|Removed |Added Depends on||85052 --- Comment #2 from Jan Hubicka --- Good catch. I linked the PRs together. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85052 [Bug 85052] Implement support for clang's __builtin_convertvector
[Bug target/61731] Feature request: "generic" builtin for "conversion operator" among vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61731 Jan Hubicka changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||hubicka at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Jan Hubicka --- PR 85052 has at least some useful info in it. *** This bug has been marked as a duplicate of bug 85052 ***
[Bug c++/85052] Implement support for clang's __builtin_convertvector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85052 Jan Hubicka changed: What|Removed |Added CC||vincenzo.innocente at cern dot ch --- Comment #3 from Jan Hubicka --- *** Bug 61731 has been marked as a duplicate of this bug. ***
[Bug c++/88601] We may consider adding __builtin_convertvector and __builtin_shufflevector for better compaitbility with Clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88601 --- Comment #1 from Marc Glisse --- __builtin_convertvector is a dup of at least PR85052 and PR61731.
[Bug c++/88601] New: We may consider adding __builtin_convertvector and __builtin_shufflevector for better compaitbility with Clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88601 Bug ID: 88601 Summary: We may consider adding __builtin_convertvector and __builtin_shufflevector for better compaitbility with Clang Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hubicka at gcc dot gnu.org Target Milestone: --- These two builtins are used by Skia and while they can be replaced by generic code, it is not very pretty. https://clang.llvm.org/docs/LanguageExtensions.html#langext-builtin-convertvector https://clang.llvm.org/docs/LanguageExtensions.html#langext-builtin-shufflevector
[Bug c++/88600] New: GCC rejects attributes on type aliases, while clang accepts them
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88600 Bug ID: 88600 Summary: GCC rejects attributes on type aliases, while clang accepts them Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hubicka at gcc dot gnu.org Target Milestone: --- Compiling: template using V = __attribute__ ((__vector_size (8))) T; with GCC leads to: tt.C:1:69: warning: ignoring attributes applied to dependent type âTâ without an associated declaration [-Wattributes] template using V = __attribute__ ((__vector_size (8))) T; ^ while clang produces type V which is vector of integers. This is used by templates in Skia library which I am not sure how to write w/o this construct: // These are __m256 and __m256i, but friendlier and strongly-typed. template using V = T __attribute__((ext_vector_type(8))); using F = V; using I32 = V< int32_t>; using U64 = V; using U32 = V; using U16 = V; using U8 = V; I am not sure how to do the same in a way compatible with GCC.
[Bug tree-optimization/88599] New: ICE in make_decl_rtl, at varasm.c:1337
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88599
Bug ID: 88599
Summary: ICE in make_decl_rtl, at varasm.c:1337
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: 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
gcc-9.0.0-alpha20181223 snapshot (r267388) and all releases to at least gcc 6
ICE when compiling the following snippet w/ -msoft-float:
void
ud (_Atomic double *my)
{
*my += 1.0;
}
% powerpc-e300c3-linux-gnu-gcc-9.0.0-alpha20181223 -msoft-float -c ixpqp7a6.c
during RTL pass: expand
ixpqp7a6.c: In function 'ud':
ixpqp7a6.c:4:3: internal compiler error: in make_decl_rtl, at varasm.c:1337
4 | *my += 1.0;
| ^
0x6d2d9d make_decl_rtl(tree_node*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181223/work/gcc-9-20181223/gcc/varasm.c:1333
0x9d5278 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181223/work/gcc-9-20181223/gcc/expr.c:9938
0x9df4df expand_expr
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181223/work/gcc-9-20181223/gcc/expr.h:279
0x9df4df expand_expr_addr_expr_1
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181223/work/gcc-9-20181223/gcc/expr.c:7945
0x9d3275 expand_expr_addr_expr
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181223/work/gcc-9-20181223/gcc/expr.c:8066
0x9d3275 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181223/work/gcc-9-20181223/gcc/expr.c:11221
0x9dfd77 store_expr(tree_node*, rtx_def*, int, bool, bool)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181223/work/gcc-9-20181223/gcc/expr.c:5633
0x9e1f59 expand_assignment(tree_node*, tree_node*, bool)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181223/work/gcc-9-20181223/gcc/expr.c:5416
0x8b9f2f expand_gimple_stmt_1
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181223/work/gcc-9-20181223/gcc/cfgexpand.c:3746
0x8b9f2f expand_gimple_stmt
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181223/work/gcc-9-20181223/gcc/cfgexpand.c:3844
0x8bb3a7 expand_gimple_basic_block
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181223/work/gcc-9-20181223/gcc/cfgexpand.c:5880
0x8c15e7 execute
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181223/work/gcc-9-20181223/gcc/cfgexpand.c:6502
[Bug c++/88114] "virtual ~destructor() = default": Destructor not created
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88114 --- Comment #4 from Tobias Burnus --- (In reply to Tobias Burnus from comment #3) > Patch: https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01824.html Patch review: https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00319.html (I still plan to update my patch, but didn't manage to find time for it so far.)
[Bug tree-optimization/88598] simplification of multiplication by 1 or 0 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88598
--- Comment #1 from Marc Glisse ---
-funroll-loops helps (I expect that's what llvm does).
float j[5] = {}; also helps. We should probably simplify {0,0,...} to {}, but
then we would still be missing the optimization for {1,1,...} where we would
like to notice that any read can only yield 1.
[Bug tree-optimization/88598] New: simplification of multiplication by 1 or 0 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88598
Bug ID: 88598
Summary: simplification of multiplication by 1 or 0 fails
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vincenzo.innocente at cern dot ch
Target Milestone: ---
g++ fails to optimize the code below
even with -Ofast https://godbolt.org/z/mYRgVX
independently of vectorization options https://godbolt.org/z/XMnCNz
clang optimizes (return zero for "foo" and v[1] for "bar") even for just
-ffinite-math-only -fno-signed-zeros -O2
https://godbolt.org/z/KU5f-x
float foo(float const * __restrict__ v) {
float j[5] = {0.,0.,0.,0.,0.};
float ret=0.;
for (int i=0; i<5; ++i) ret +=j[i]*v[i];
return ret;
}
float bar(float const * __restrict__ v) {
float j[5] = {0.,1.,0.,0.,0.};
float ret=0.;
for (int i=0; i<5; ++i) ret +=j[i]*v[i];
return ret;
}
[Bug lto/88550] A compiler error when use lto: internal compiler error: in add_symbol_to_partition_1, at lto/lto-partition.c:155
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88550 --- Comment #3 from Harry Wong --- Thanks for your help! After using the '-fdump-ipa-cgraph --save-temps' option I had thousands of files generated and don't know how to analysis them... Could you help me with this? And I also got the .cgraph file, it too large(more than 141MB), and I've found these lines in the end of file: Total unit size: 308429, partition size: 1 Step 0: added _GLOBAL__I_65535_0_main.cpp.o/1191204, size 1755, cost 9206/779 best 9206/779, step 0 Step 1: added uninitialized_move_alloc.constprop/1191183, size 1799, cost 9553/779 best 9553/779, step 1 Step 2: added throw_length_error.constprop/1191181, size 1815, cost 9628/779 best 9628/779, step 2 Step 3: added operator().constprop/1191180, size 1840, cost 11089/779 best 11089/779, step 3 Step 4: added _M_construct.constprop/1191177, size 1886, cost 342715/779 best 342715/779, step 4 Step 5: added __ct_base .constprop/1191176, size 1912, cost 794034/2171 best 794034/2171, step 5 Step 1145: added __dt_comp /490360, size 7271, cost 228255/656661 best 228255/656661, step 1145
