[Bug jit/98615] New: libgccjit crash while freeing 'clone_info' in 'cgraph_c_finalize'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98615 Bug ID: 98615 Summary: libgccjit crash while freeing 'clone_info' in 'cgraph_c_finalize' Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: akrl at gcc dot gnu.org Target Milestone: --- Created attachment 49928 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49928&action=edit reproducer $ gcc libgccjit_repro.c -lgccjit $ ./a.out munmap_chunk(): invalid pointer Aborted (core dumped) What is going on is that a static function (CAR) is inlined via virtual clone and its symbol released. Eventually 'cgraph_c_finalize' calls 'clone_info::release' and this is where (not sure why) we crash. I believe this bug was introduced by: ae7a23a3fab Move clone_info to summary The first revision where is possible to reproduce on was unbroken few commits later with: 895fdc1f4c9 ipa: Fix segmentation fault in function_summary::get(cgraph_node*) I found this because it breaks Emacs bootstrap on libgccjit.
[Bug c++/97402] Value of dependent partial-concept-id is not usable in a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97402 Amir Kirsh changed: What|Removed |Added CC||kirshamir at gmail dot com --- Comment #2 from Amir Kirsh --- See also: https://stackoverflow.com/questions/65653983/gcc-stdis-same-vint-t-is-not-usable-in-a-constant-expression
[Bug c++/97402] Value of dependent partial-concept-id is not usable in a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97402 --- Comment #3 from Amir Kirsh --- Playing with the code even leads to compiler seg-fault, see: https://stackoverflow.com/a/65654043/2085626
[Bug bootstrap/98616] New: Compile gcc 10.2.0 error for loongson 2f CPU use MIPS n32 ABI on Gentoo OS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98616 Bug ID: 98616 Summary: Compile gcc 10.2.0 error for loongson 2f CPU use MIPS n32 ABI on Gentoo OS Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: tong__hui at 163 dot com Target Milestone: --- emerge --info '=sys-devel/gcc-10.2.0-r5::gentoo' Portage 3.0.12 (python 3.8.6-final-0, default/linux/mips/17.0/mipsel/multilib/n32, gcc-8.3.0, glibc-2.32-r2, 4.19.121 mips64) = System Settings = System uname: Linux-4.19.121-mips64-ICT_Loongson-2_V0.3_FPU_V0.1-with-glibc2.2 KiB Mem: 1013280 total, 18496 free KiB Swap:3911808 total, 3837312 free Timestamp of repository gentoo: Sat, 09 Jan 2021 00:45:01 + sh bash 5.0_p18 ld GNU ld (Gentoo 2.30 p3) 2.30.0 ccache version 3.7.12 [disabled] app-shells/bash: 5.0_p18::gentoo dev-java/java-config: 2.2.0-r3::gentoo dev-lang/perl:5.30.3-r1::gentoo dev-lang/python: 2.7.18-r4::gentoo, 3.5.7::gentoo, 3.6.12::gentoo, 3.7.9::gentoo, 3.8.6::gentoo, 3.9.0::gentoo dev-util/ccache: 3.7.12::gentoo dev-util/cmake: 3.18.4::gentoo dev-util/pkgconfig: 0.29.2::gentoo sys-apps/baselayout: 2.7::gentoo sys-apps/openrc: 0.42.1::gentoo sys-apps/sandbox: 2.20::gentoo sys-devel/autoconf: 2.13-r1::gentoo, 2.69-r5::gentoo, 2.70::gentoo sys-devel/automake: 1.11.6-r3::gentoo, 1.14.1::gentoo, 1.15.1-r1::gentoo, 1.16.3-r1::gentoo sys-devel/binutils: 2.29.1-r1::gentoo, 2.30-r3::gentoo, 2.31.1-r4::gentoo, 2.32-r1::gentoo, 2.33.1::gentoo, 2.34::gentoo, 2.35.1-r1::gentoo sys-devel/gcc:4.8.3::gentoo, 5.4.0-r6::gentoo, 5.5.0::gentoo, 6.4.0-r5::gentoo, 7.3.0-r3::gentoo, 8.2.0-r6::gentoo, 8.3.0::gentoo sys-devel/gcc-config: 2.3.2::gentoo sys-devel/libtool:2.4.6-r6::gentoo sys-devel/make: 4.3::gentoo sys-kernel/linux-headers: 5.8::gentoo (virtual/os-headers) sys-libs/glibc: 2.32-r2::gentoo Repositories: gentoo location: /usr/portage sync-type: webrsync sync-uri: https://mirrors.163.com/gentoo/ priority: -1000 sync-webrsync-verify-signature: yes python location: /var/lib/layman/python masters: gentoo priority: 50 ACCEPT_KEYWORDS="mips ~mips" ACCEPT_LICENSE="*" CBUILD="mips64el-unknown-linux-gnu" CFLAGS="-O2 -march=loongson2f -Wa,-mfix-loongson2f-nop -pipe -fPIC" CHOST="mips64el-unknown-linux-gnu" CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php7.3/ext-active/ /etc/php/apache2-php7.4/ext-active/ /etc/php/cgi-php7.3/ext-active/ /etc/php/cgi-php7.4/ext-active/ /etc/php/cli-php7.3/ext-active/ /etc/php/cli-php7.4/ext-active/ /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -march=loongson2f -Wa,-mfix-loongson2f-nop -pipe -fPIC" DISTDIR="/usr/portage/distfiles" ENV_UNSET="CARGO_HOME DBUS_SESSION_BUS_ADDRESS DISPLAY GOBIN GOPATH PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch pid-sandbox preserve-libs protect-owned qa-unresolved-soname-deps sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="https://mirrors.tuna.tsinghua.edu.cn/gentoo"; LDFLAGS="-Wl,-O1 -Wl,--as-needed" PKGDIR="/var/cache/binpkgs" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git" PORTAGE_TMPDIR="/var/tmp" USE="X acl alsa artworkextra avahi berkdb bzip2 cairo cli crypt cups dbus exif ffmpeg flac gdbm gdu glchess gtk gtk3 gudev hwdb iconv id3tag ipv6 jpeg latex lcms libglvnd libsamplerate lock math midi mips mp3 multilib ncurses nls nptl openssl openxml ots pcre pic png policykit python readline seccomp session soundtouch spell split-usr ssl startup-notification suid tcpd threads thunar tiff twolame udev udisks unicode vamp vorbis wmf wordperfect xattr zlib" ABI_MIPS="n32" ADA_TARGET="gnat_2018" ALSA_CARDS="au1x00" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_d
[Bug bootstrap/98616] Compile gcc 10.2.0 error for loongson 2f CPU use MIPS n32 ABI on Gentoo OS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98616 --- Comment #1 from tong__hui at 163 dot com --- Created attachment 49929 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49929&action=edit gcc-build-logs gcc build logs
[Bug go/98496] [11 Regression] bootstrap broken in libgo on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98496 --- Comment #4 from Svante Signell --- Created attachment 49930 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49930&action=edit gcc-11 patches for libgo
[Bug go/98496] [11 Regression] bootstrap broken in libgo on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98496 --- Comment #5 from Svante Signell --- Created attachment 49931 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49931&action=edit gcc-11 patches for libgo
[Bug go/98496] [11 Regression] bootstrap broken in libgo on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98496 --- Comment #6 from Svante Signell --- Created attachment 49932 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49932&action=edit gcc-11 patches for libgo
[Bug go/98496] [11 Regression] bootstrap broken in libgo on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98496 --- Comment #7 from Svante Signell --- Created attachment 49933 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49933&action=edit gcc-11 patches for libgo
[Bug go/98496] [11 Regression] bootstrap broken in libgo on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98496 --- Comment #8 from Svante Signell --- Created attachment 49934 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49934&action=edit gcc-11 patches for libgo
[Bug go/98496] [11 Regression] bootstrap broken in libgo on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98496 --- Comment #9 from Svante Signell --- Created attachment 49935 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49935&action=edit gcc-11 patches for libgo
[Bug go/98496] [11 Regression] bootstrap broken in libgo on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98496 --- Comment #10 from Svante Signell --- Hello, The 6 attached patches are improving the build and tests of gccgo for Hurd. Attachment 49931 is needed for libgo to build, while the other are improving the tests of libgo,go and gotools. Attachment 49934 if just a cosmetic change of os_hurd.go. Further changes are still needed to the Makefiles of libgo and gotools to enable proper linking of libpthread and libdl. The dynamic linking of extra libraries does not work automatically as it does on Linux systems. Thanks!
[Bug tree-optimization/98499] [11 Regression] Possibly bad std::string initialization in constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98499
--- Comment #8 from Sergei Trofimovich ---
(In reply to Richard Biener from comment #7)
> (In reply to Sergei Trofimovich from comment #6)
> > (In reply to Richard Biener from comment #5)
> > > Possibly in discovering pure/constness. See uses of
> > > gimple_call_return_slot_opt_p in tree-ssa-structalias.c
> >
> > Aha, that's useful!
> >
> > Trying to understand the problem better myself: `-fdump-tree-all` has
> > seemingly relevant `036t.ealias` that precedes breaking `037t.fre1`.
> >
> > I assume `036t.ealias` analyses individual functions locally and does not
> > take into account other details, thus main() analysis should be enough:
>
> Well - it does take into account fnspecs derived by modref analysis for
> Importer::Importer - specifically ...
Oh, thank you! Only after many printf() attempts it sunk in that `036t.ealias`
is using data from seemingly later `043t.modref1` pass. It is so confusing!
> > ```
> > ...
> > Points-to sets
> >
> > ANYTHING = { ANYTHING }
> > ESCAPED = { ESCAPED NONLOCAL }
> > NONLOCAL = { ESCAPED NONLOCAL }
> > STOREDANYTHING = { }
> > INTEGER = { ANYTHING }
> > _ZN8ImporterC1Ev = { }
> > imp.0+64 = { ESCAPED NONLOCAL } same as _6
> > imp.64+8 = { ESCAPED NONLOCAL }
> > __builtin_trap = { }
> > main = { }
> > CALLUSED(9) = { ESCAPED NONLOCAL imp.0+64 imp.64+8 } same as callarg(11)
> > CALLCLOBBERED(10) = { ESCAPED NONLOCAL imp.0+64 imp.64+8 } same as
> > callarg(11)
> > callarg(11) = { ESCAPED NONLOCAL imp.0+64 imp.64+8 }
>
> the above shows we do not consider 'imp' to escape, and thus
>
> > _6 = { ESCAPED NONLOCAL }
>
> _6 does not point to 'imp'.
>
> Relevant parts of handle_rhs_call are probably
>
> /* As we compute ESCAPED context-insensitive we do not gain
> any precision with just EAF_NOCLOBBER but not EAF_NOESCAPE
> set. The argument would still get clobbered through the
> escape solution. */
> if ((flags & EAF_NOCLOBBER)
>&& (flags & (EAF_NOESCAPE | EAF_NODIRECTESCAPE)))
> {
> ...
>
> specifically lines
>
> if (!(flags & (EAF_NOESCAPE | EAF_DIRECT)))
> make_indirect_escape_constraint (tem);
>
> probably do not trigger because of the invalid modref analysis. I suggest
> to look at the early modref pass dump (it's after FRE but still applies
> to callers)
Yeah, that makes sense.
Minor correction: we get into second branch of handle_rhs_call():
else if (flags & (EAF_NOESCAPE | EAF_NODIRECTESCAPE))
I traced it through around and I agree it looks like an ipa-modref bug.
Mechanically ipa-modref does not handle `gimple_call_return_slot_opt_p()` and
assumes 'foo = bar() [return slot optimization]' never escape 'foo'.
As a workaround I attempted to pessimize modref and it fixes the test case:
```diff
--- a/gcc/ipa-modref.c
+++ b/gcc/ipa-modref.c
@@ -1614,23 +1614,26 @@ analyze_ssa_name_flags (tree name, vec
&lattice, int depth,
{
if (gimple_return_retval (ret) == name)
lattice[index].merge (~EAF_UNUSED);
else if (memory_access_to (gimple_return_retval (ret), name))
lattice[index].merge_direct_load ();
}
/* Account for LHS store, arg loads and flags from callee function. */
else if (gcall *call = dyn_cast (use_stmt))
{
tree callee = gimple_call_fndecl (call);
-
+ if (gimple_call_return_slot_opt_p (call)
+ && gimple_call_lhs (call) != NULL_TREE
+ && TREE_ADDRESSABLE (TREE_TYPE (gimple_call_lhs (call
+ lattice[index].merge (0);
/* Recursion would require bit of propagation; give up for now. */
- if (callee && !ipa && recursive_call_p (current_function_decl,
+ else if (callee && !ipa && recursive_call_p (current_function_decl,
callee))
lattice[index].merge (0);
else
{
int ecf_flags = gimple_call_flags (call);
bool ignore_stores = ignore_stores_p (current_function_decl,
ecf_flags);
bool ignore_retval = ignore_retval_p (current_function_decl,
ecf_flags);
```
Mechanically ESCAPE bit was lost in Importer::Importer at:
1. in "this->base_path = dir_name (); [r s o]" ipa-modref derived 'DIRECT
NODIRECTESCAPE NOESCAPE' flags as it assumed it's just a memory store without
'this' escape.
2. main() optimised Inporter::Importer(&imp) as a noescape using
handle_rhs_call()
-> gimple_call_arg_flags(arg_index = 0)
-> - fnspec was empty
- modref's get_modref_function_summary() adds 'DIRECT NODIRECTESCAPE
NOESCAPE'
Is it a reasonable fix? Or it's too conservative and we could easily do better?
I copied predicate from handle_rhs_call(), but did not pick constrain copying:
/* And if we applied NRV the address of
[Bug fortran/82480] KIND array returned by STAT too small for many values on CygWin platforms (and probably others)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82480 --- Comment #5 from urbanjost at comcast dot net --- Since it is an extension that makes perfect sense to me. Backward-compatible and solves the problem.
[Bug c++/98617] New: Failure to recognize pack expansion argument for non-pack parameter of alias template when alias is "exact"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98617 Bug ID: 98617 Summary: Failure to recognize pack expansion argument for non-pack parameter of alias template when alias is "exact" Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ryan_greenblatt at brown dot edu Target Milestone: --- It is invalid to expand a parameter pack into a non pack parameter of an alias template. However, gcc accepts this when the alias is exactly the same as the struct it is aliasing. Consider https://godbolt.org/z/YrqTTx AliasA doesn't fail, but it should fail with the same error as AliasB and AliasC.
[Bug libstdc++/98613] vstring mov testsuite failures on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98613 Martin Sebor changed: What|Removed |Added Keywords||diagnostic --- Comment #4 from Martin Sebor --- Yes, I think so. I see code in the optimized dump that the warning should trigger for even on x86_64 but doesn't due to a known bug/limitation in how GCC determines the context into which a function defined in a system header has been inlined. All the calls to operator delete with _S_empty_rep should trigger it: $ /build/gcc-master/gcc/xg++ -B /build/gcc-master/gcc -nostdinc++ -I /build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I /build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include -I /src/gcc/master/libstdc++-v3/libsupc++ -I /src/gcc/master/libstdc++-v3/include/backward -I /src/gcc/master/libstdc++-v3/testsuite/util -L /build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -O3 -Wall -fdump-tree-optimized=/dev/stdout /src/gcc/master/libstdc++-v3/testsuite/ext/vstring/cons/moveable.cc | grep delete operator delete (_17, _21); [tail call] operator delete (_35, _37); operator delete (_38, _40); operator delete (&MEM [(void *)&_S_empty_rep], _156); operator delete (_220, _224); operator delete (_288, _292); operator delete (_318, _322); operator delete (&MEM [(void *)&_S_empty_rep], _328); operator delete (&MEM [(void *)&_S_empty_rep], _334); [tail call]
[Bug libstdc++/98613] vstring mov testsuite failures on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98613 --- Comment #5 from CVS Commits --- The master branch has been updated by David Edelsohn : https://gcc.gnu.org/g:4a1d7f7e203d0ec4b9d67ea6fc9b84bee1e211d3 commit r11-6573-g4a1d7f7e203d0ec4b9d67ea6fc9b84bee1e211d3 Author: David Edelsohn Date: Sun Jan 10 18:10:34 2021 -0500 libstdc++: Suppress more vstring testsuite warnings. [PR 98613] PR c++/57111 - 57111 - Generalize -Wfree-nonheap-object to delete can create false positive warnings for vstring _S_empty_rep. This patch prunes the excess false positive warnings from two more testcases. libstdc++-v3/ChangeLog: PR libstdc++/98613 * testsuite/ext/vstring/cons/moveable.cc: Suppress false positive warning. * testsuite/ext/vstring/modifiers/assign/move_assign.cc: Same.
[Bug c++/57111] Generalize -Wfree-nonheap-object to delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57111 --- Comment #17 from CVS Commits --- The master branch has been updated by David Edelsohn : https://gcc.gnu.org/g:4a1d7f7e203d0ec4b9d67ea6fc9b84bee1e211d3 commit r11-6573-g4a1d7f7e203d0ec4b9d67ea6fc9b84bee1e211d3 Author: David Edelsohn Date: Sun Jan 10 18:10:34 2021 -0500 libstdc++: Suppress more vstring testsuite warnings. [PR 98613] PR c++/57111 - 57111 - Generalize -Wfree-nonheap-object to delete can create false positive warnings for vstring _S_empty_rep. This patch prunes the excess false positive warnings from two more testcases. libstdc++-v3/ChangeLog: PR libstdc++/98613 * testsuite/ext/vstring/cons/moveable.cc: Suppress false positive warning. * testsuite/ext/vstring/modifiers/assign/move_assign.cc: Same.
[Bug libstdc++/98613] vstring mov testsuite failures on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98613 David Edelsohn changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from David Edelsohn --- ignore the warnings.
[Bug target/98612] _mm_comieq_sd has wrong semantics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98612
--- Comment #2 from Hongtao.liu ---
(In reply to Guillaume Piolat from comment #0)
> Created attachment 49926 [details]
> Behaviour with 3 compilers
>
> _mm_comieq_sd has different NaN semantics for different people.
>
> # The Unordered team
> - GCC will return 1 for a comparison that involved NaN.
> - this maps to the underlying instruction
>
> # The Ordered team
> - Intel intrinsics guide says:
>
> RETURN ( a[63:0] == b[63:0] ) ? 1 : 0
>
> which indicates an ordered comparison.
ICC take _mm_{u,}comi{eq,lt,le,gt,ge}_s{s,d} as ordered comparison, and
_mm_{u,}comineq_s{s,d} as unordered comparison, GCC didn't take {Q,}NAN operand
into consideration.
The codes has been in gcc for more than 15 years, and I'm not sure if some
applications are taking advantage of this "bug" in gcc, so do we really need to
"fix" it?
Technically, we can just "refine" as.
modified gcc/config/i386/emmintrin.h
@@ -515,7 +515,7 @@ _mm_cmpunord_sd (__m128d __A, __m128d __B)
extern __inline int __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_comieq_sd (__m128d __A, __m128d __B)
{
- return __builtin_ia32_comisdeq ((__v2df)__A, (__v2df)__B);
+ return __A[0] == __B[0];
}
[Bug target/98612] _mm_comieq_sd has wrong semantics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98612
--- Comment #3 from Hongtao.liu ---
Also found some dead code in ix86_expand_sse_comi which is called by
if (fcode >= IX86_BUILTIN__BDESC_COMI_FIRST
&& fcode <= IX86_BUILTIN__BDESC_COMI_LAST)
where all builtins are defined with flags as 0.
2 files changed, 9 deletions(-)
gcc/config/i386/i386-builtins.h | 4
gcc/config/i386/i386-expand.c | 5 -
modified gcc/config/i386/i386-builtins.h
@@ -236,10 +236,6 @@ struct builtin_isa {
/* Bits for builtin_description.flag. */
-/* Set when we don't support the comparison natively, and should
- swap_comparison in order to support it. */
-#define BUILTIN_DESC_SWAP_OPERANDS 1
-
struct builtin_description
{
const HOST_WIDE_INT mask;
modified gcc/config/i386/i386-expand.c
@@ -8634,11 +8634,6 @@ ix86_expand_sse_comi (const struct builtin_description
*d, tree exp,
if (VECTOR_MODE_P (mode1))
op1 = safe_vector_operand (op1, mode1);
- /* Swap operands if we have a comparison that isn't available in
- hardware. */
- if (d->flag & BUILTIN_DESC_SWAP_OPERANDS)
-std::swap (op0, op1);
-
target = gen_reg_rtx (SImode);
emit_move_insn (target, const0_rtx);
target = gen_rtx_SUBREG (QImode, target, 0);
[back]
[Bug tree-optimization/36602] memset should be optimized into an empty CONSTRUCTOR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36602
--- Comment #14 from Richard Biener ---
Yes, I think so. = {} has the advantage that the destination isn't
address-taken compared to memset which has alias analysis benefits.
[Bug tree-optimization/98598] Missed opportunity to optimize dependent loads in loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98598 --- Comment #8 from rguenther at suse dot de --- On Sat, 9 Jan 2021, jiangning.liu at amperecomputing dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98598 > > --- Comment #7 from Jiangning Liu > --- > (In reply to rguent...@suse.de from comment #6) > > On January 9, 2021 4:17:17 AM GMT+01:00, "jiangning.liu at amperecomputing > > dot com" wrote: > > >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98598 > > > > > >--- Comment #5 from Jiangning Liu > >com> --- > > >> It has to be done with care of course, cost modeling is difficult > > >> (we need to have a good estimate of n and m or need to version > > >> the whole nest). That said, usually we attempt the reverse > > >transform. > > > > > >Before tuning the cost model good enough, we may implement this > > >optimization by > > >adding a new optimization command line option. This won't hurt gcc, > > >right? > > > > New options not enabled by default tend to bitrot, be broken from the start > > and won't be used by the lazy user. So I see no point in doing that. > > > > Understand. I mean we can enable it by default eventually, but we need to > implement and tune it step by step. It is unrealistic to work out the best > cost > model at the very beginning. Sure. The "easiest" thing is to rely on a profile from PGO, we did have some transforms only enabled by -fprofile-use by default. That is, the cost model needs to be conservative, esp. if you introduce dynamic allocation for this. In the end I guess only a variant that versions the nest on the size of the temporary will be good enough to not trigger OOM or excessive overhead for small sizes anyway.
