[Bug tree-optimization/102087] [12 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: in determine_exit_conditions, at tree-ssa-loop-manip.c:1049 since r12-3136-g3673dcf6d6baeb67
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102087
--- Comment #16 from Jiu Fu Guo ---
Thanks David, Richard,
~/gcc/install/gcc-mainline-base-debug/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/home/guojiufu/gcc/install/gcc-mainline-base-debug/bin/gcc
COLLECT_LTO_WRAPPER=/home/guojiufu/gcc/install/gcc-mainline-base-debug/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/guojiufu/gcc/gcc-mainline-base/configure
--prefix=/home/guojiufu/gcc/install/gcc-mainline-base-debug --disable-bootstrap
--disable-multilib --disable-werror --with-pkgversion=29c92857039d0a10
--enable-checking=df,extra,fold,rtl,yes --enable-languages=c,c++,fortran :
(reconfigured) /home/guojiufu/gcc/gcc-mainline-base/configure
--prefix=/home/guojiufu/gcc/install/gcc-mainline-base-debug --disable-bootstrap
--disable-multilib --disable-werror --with-pkgversion=29c92857039d0a10
--enable-checking=df,extra,fold,rtl,yes --enable-languages=c,c++,fortran,lto
--no-create --no-recursion
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210922 (experimental) (29c92857039d0a10)
~/gcc/install/gcc-mainline-base-debug/bin/gcc -c -O3 -w ~/temp/t.c
-march=opteron
~/gcc/install/gcc-mainline-base-debug/bin/gcc -c -O3 -w -march=bdver2
~/temp/t.c
cat ~/temp/t.c
char **Gif_ClipImage_gfi_0;
int Gif_ClipImage_y, Gif_ClipImage_shift;
void Gif_ClipImage(void) {
for (; Gif_ClipImage_y >= Gif_ClipImage_shift; Gif_ClipImage_y++)
Gif_ClipImage_gfi_0[Gif_ClipImage_shift] =
Gif_ClipImage_gfi_0[Gif_ClipImage_y];
}
I build both 3087d1b0a2c and the latest trunk, the case could pass.
[Bug testsuite/100748] [12 regression] 30_threads/jthread/95989.cc fails after r12-843
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100748 --- Comment #6 from Jeffrey A. Law --- Jon -- you might want to sync with the glibc folks. IIUC they're rolled libpthread into libc in glibc-2.34 which may make this is a non-issue going forward, which I can certainly live with.
[Bug debug/102659] New: [false diagnosis] extra warning info after O2 vectorization for gcc.dg/torture/pr69760.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102659
Bug ID: 102659
Summary: [false diagnosis] extra warning info after O2
vectorization for gcc.dg/torture/pr69760.c
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: crazylht at gmail dot com
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-*-* i?86-*-*
options:
../gcc/xgcc -B ../gcc -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects
../../../gcc/intel-innersource/O2_vectorization/gcc/testsuite/gcc.dg/torture/pr69760.c
-m32 -march=cascadelake
../../../gcc/intel-innersource/O2_vectorization/gcc/testsuite/gcc.dg/torture/pr69760.c:
In function ‘test_func’:
../../../gcc/intel-innersource/O2_vectorization/gcc/testsuite/gcc.dg/torture/pr69760.c:16:10:
warning: iteration 54 invokes undefined behavior
[-Waggressive-loop-optimizations]
16 | a[L * k] = 0.0;
| ^
../../../gcc/intel-innersource/O2_vectorization/gcc/testsuite/gcc.dg/torture/pr69760.c:12:17:
note: within this loop
12 | for (i = 0; i < N; i++)
| ^
dump is quite the same as adding -fno-tree-vectorize
@@ -6,44 +6,44 @@ Removing basic block 8
__attribute__((noclone, noinline))
void test_func (double * a, int L, int m, int n, int N)
{
+ unsigned int ivtmp.9;
unsigned int ivtmp.8;
- unsigned int ivtmp.7;
- unsigned int _14;
- int _26;
- unsigned int _31;
- unsigned int _32;
- double * _33;
- unsigned int _34;
- unsigned int _38;
- void * _39;
+ unsigned int _4;
+ unsigned int _5;
+ double * _6;
+ unsigned int _7;
+ unsigned int _25;
+ unsigned int _26;
+ int _27;
+ void * _40;
[local count: 118111600]:
- _26 = -m_13(D);
- ivtmp.7_1 = (unsigned int) _26;
- _31 = (unsigned int) m_13(D);
- _32 = _31 * 4214967296;
- _33 = a_17(D) + _32;
- ivtmp.8_30 = (unsigned int) _33;
- _34 = (unsigned int) a_17(D);
- _14 = _34 + 1935228928;
- _38 = _14 + _32;
+ _27 = -m_13(D);
+ ivtmp.8_8 = (unsigned int) _27;
+ _4 = (unsigned int) m_13(D);
+ _5 = _4 * 4214967296;
+ _6 = a_17(D) + _5;
+ ivtmp.9_21 = (unsigned int) _6;
+ _7 = (unsigned int) a_17(D);
+ _26 = _7 + 1935228928;
+ _25 = _5 + _26;
[local count: 955630225]:
- # ivtmp.7_3 = PHI
- # ivtmp.8_28 = PHI
- if (ivtmp.7_3 <= 3)
+ # ivtmp.8_3 = PHI
+ # ivtmp.9_24 = PHI
+ if (ivtmp.8_3 <= 3)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 477815112]:
- _39 = (void *) ivtmp.8_28;
- MEM[(double *)_39] = 0.0;
+ _40 = (void *) ivtmp.9_24;
+ MEM[(double *)_40] = 0.0;
[local count: 955630225]:
- ivtmp.7_2 = ivtmp.7_3 + 1;
- ivtmp.8_29 = ivtmp.8_28 + 8000;
- if (ivtmp.8_29 != _38)
+ ivtmp.8_38 = ivtmp.8_3 + 1;
+ ivtmp.9_14 = ivtmp.9_24 + 8000;
+ if (ivtmp.9_14 != _25)
goto ; [87.64%]
else
goto ; [12.36%]
[Bug testsuite/102658] [12 regression] Many test case failures after r12-4240
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102658 --- Comment #3 from Kewen Lin --- Some new XPASS: XFAIL->XPASS: gcc.dg/Wstringop-overflow-68.c pr101475 (test for warnings, line 61) XFAIL->XPASS: gcc.dg/Wstringop-overflow-68.c pr101475 (test for warnings, line 62) XFAIL->XPASS: gcc.dg/Wstringop-overflow-68.c pr101475 (test for warnings, line 63) XFAIL->XPASS: gcc.dg/Wstringop-overflow-68.c pr101475 (test for warnings, line 64) One new FAIL spotted: PASS->FAIL: gcc.dg/guality/pr54693-2.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects -DPREVENT_OPTIMIZATION line 21 x == 10 - i which is from guality, not sure whether we want to recover the original behavior since there are already some existing FAILs before. The reason why it fails is that O2 loop vect enables dce6 which takes x in PHI useless and remove it, further stops to reuse i for x's debug information.
[Bug testsuite/102658] [12 regression] Many test case failures after r12-4240
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102658 Kewen Lin changed: What|Removed |Added Ever confirmed|0 |1 CC||linkw at gcc dot gnu.org Last reconfirmed||2021-10-09 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org --- Comment #2 from Kewen Lin --- I'll take a look.
[Bug lto/102649] GCC 9.3.1 LTO bug -- incorrect function call, bad stack arguments pushed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102649 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2021-10-09 --- Comment #1 from Andrew Pinski --- This is going to need more information, mainly the sources and how exactly to reproduce the issue. There has been some known issues with -ffast-math and -flto but I don't remember offhand if there was something described like this before.
[Bug target/102639] ICE in extract_insn, at recog.c:2769 since r12-3406-ga68412117fa47786
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102639 --- Comment #4 from Hongtao.liu --- Fixed in GCC12.
[Bug target/102639] ICE in extract_insn, at recog.c:2769 since r12-3406-ga68412117fa47786
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102639
--- Comment #3 from CVS Commits ---
The master branch has been updated by hongtao Liu :
https://gcc.gnu.org/g:0d788c358b94d0e1983e0c6bf6269fa105b6d007
commit r12-4270-g0d788c358b94d0e1983e0c6bf6269fa105b6d007
Author: liuhongt
Date: Fri Oct 8 15:21:44 2021 +0800
Refine movhfcc.
For AVX512-FP16, HFmode only supports vcmpsh whose dest is mask
register, so for movhfcc, it's
vcmpsh op2, op1, %k1
vmovsh op1, op2{%k1}
mov op2, dest
gcc/ChangeLog:
PR target/102639
* config/i386/i386-expand.c (ix86_valid_mask_cmp_mode): Handle
HFmode.
(ix86_use_mask_cmp_p): Ditto.
(ix86_expand_sse_movcc): Ditto.
* config/i386/i386.md (setcc_hf_mask): New define_insn.
(movhf_mask): Ditto.
(UNSPEC_MOVCC_MASK): New unspec.
* config/i386/sse.md (UNSPEC_PCMP): Move to i386.md.
gcc/testsuite/ChangeLog:
* g++.target/i386/pr102639.C: New test.
[Bug testsuite/102658] [12 regression] Many test case failures after r12-4240
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102658
--- Comment #1 from Hongtao.liu ---
> Please don't add the -fno- option to the warning tests. As I said,
> I would prefer to either suppress the vectorization for the failing
> cases by tweaking the test code or xfail them. That way future
> regressions won't be masked by the option. Once we've moved
> the warning to a more suitable pass we'll add a new test to verify
> it works as intended or remove the xfails.
Remove -fno-tree-vectorize from the warning tests, and add xfails to them.
The warning information is mainly affected by vectorization of 4 or 2 char
store. Some targets support both, some targets only support one of them,
and some targets supported neither, which means the warning information
would differ from targets to targets.
I only added xfail { x86_64-*-* i?86-*-* }, other backends may need to
re-adjust these xfail.
Also the backend testcases need to be updated
[Bug libstdc++/102445] [meta-bug] std::regex issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102445 Bug 102445 depends on bug 98677, which changed state. Bug 98677 Summary: std::regex constructor triggers valgrind under clang++ with undefined sanitizer; possible use-after-move https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98677 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME
[Bug libstdc++/98677] std::regex constructor triggers valgrind under clang++ with undefined sanitizer; possible use-after-move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98677 Jonathan Wakely changed: What|Removed |Added Resolution|--- |WORKSFORME Status|UNCONFIRMED |RESOLVED --- Comment #3 from Jonathan Wakely --- I can't reproduce this error with any version of clang or gcc. No error is shown by ubsan, asan or valgrind. Please reopen if you can still reproduce this, and provide more details about versions of the tools.
[Bug libstdc++/89927] Inconsistent behavior in std::regex when optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89927 --- Comment #5 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #2) > Right, the program is using std::regex incorrectly, and has undefined > behaviour. > > Compiling with -D_GLIBCXX_ASSERTIONS will cause the program to abort at > runtime: > > /home/jwakely/gcc/8/include/c++/8.3.1/bits/regex_scanner.tcc:189: void > std::__detail::_Scanner<_CharT>::_M_scan_normal() [with _CharT = char]: > Assertion 'false' failed. > Aborted (core dumped) That assertion no longer fails, because since I fixed PR 84110 the null zero at the end of the input string no longer reaches that assertion. Instead we just walk off the end of the string, and keep going until we reach the address of the second string literal. I'm not sure how to detect this reliably. I don't think we can, without some new GCC object size checking builtins to check if two pointers are both part of the same object. With -fsanitize=address you will get an error at runtime. The assertion that no longer fails could still be clarified though.
[Bug libstdc++/94409] std::regexp (std::collate?) with GCC 7.3.1 on AIX, Japanese
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94409 Jonathan Wakely changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=98723 --- Comment #5 from Jonathan Wakely --- I think this is the same issue as PR 98723 and would be fixed by checking errno. I have a patch.
[Bug testsuite/100748] [12 regression] 30_threads/jthread/95989.cc fails after r12-843
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100748 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug libstdc++/101136] msdosdjgpp toolchain cannot find std::wstring_view
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101136 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |12.0
[Bug libstdc++/101136] msdosdjgpp toolchain cannot find std::wstring_view
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101136 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Jonathan Wakely --- This should be fixed at r12-4264-g4997c8b30ecfc82f9e6ce874cbd3840e227522eb
[Bug libstdc++/101136] msdosdjgpp toolchain cannot find std::wstring_view
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101136 Bug 101136 depends on bug 98725, which changed state. Bug 98725 Summary: Review what is disabled in libstdc++ by --disable-wchar_t https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98725 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug libstdc++/98725] Review what is disabled in libstdc++ by --disable-wchar_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98725 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #14 from Jonathan Wakely --- Fixed, as much as I plan to fix it anyway.
[Bug libstdc++/98725] Review what is disabled in libstdc++ by --disable-wchar_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98725 --- Comment #13 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:fec283b63d7f24f4c37792dd07ab1055186ba88f commit r12-4268-gfec283b63d7f24f4c37792dd07ab1055186ba88f Author: Jonathan Wakely Date: Fri Oct 8 20:48:35 2021 +0100 libstdc++: Remove unnecessary uses of _GLIBCXX_USE_WCHAR_T in testsuite [PR98725] Now that std::wstring and other specializations for wchar_t are defined unconditionally, many checks for _GLIBCXX_USE_WCHAR_T in the testsuite are unnecessary and can be removed. Tests for iostreams, locales, regex and filesystem::path still need to be guarded by _GLIBCXX_USE_WCHAR_T because those components depend on libc support in and other headers. libstdc++-v3/ChangeLog: PR libstdc++/98725 * testsuite/18_support/numeric_limits/lowest.cc: Remove use of _GLIBCXX_USE_WCHAR_T. * testsuite/18_support/numeric_limits/min_max.cc: Replace use of _GLIBCXX_USE_WCHAR_T with checks for WCHAR_MIN and WCHAR_MAX. * testsuite/20_util/from_chars/1_neg.cc: Remove use of _GLIBCXX_USE_WCHAR_T. * testsuite/20_util/function_objects/searchers.cc: Likewise. Use char_traits::length instead of wcslen. * testsuite/20_util/hash/requirements/explicit_instantiation.cc: Likewise. * testsuite/20_util/is_arithmetic/value.cc: Likewise. * testsuite/20_util/is_compound/value.cc: Likewise. * testsuite/20_util/is_floating_point/value.cc: Likewise. * testsuite/20_util/is_fundamental/value.cc: Likewise. * testsuite/20_util/is_integral/value.cc: Likewise. * testsuite/20_util/is_signed/value.cc: Likewise. * testsuite/20_util/is_unsigned/value.cc: Likewise. * testsuite/20_util/is_void/value.cc: Likewise. * testsuite/20_util/make_signed/requirements/typedefs-1.cc: Likewise. * testsuite/20_util/make_signed/requirements/typedefs-2.cc: Likewise. * testsuite/20_util/make_signed/requirements/typedefs-3.cc: Likewise. * testsuite/20_util/make_signed/requirements/typedefs-4.cc: Likewise. * testsuite/20_util/make_unsigned/requirements/typedefs-1.cc: Likewise. * testsuite/20_util/make_unsigned/requirements/typedefs-2.cc: Likewise. * testsuite/20_util/make_unsigned/requirements/typedefs-3.cc: Likewise. * testsuite/20_util/to_chars/3.cc: Likewise. * testsuite/20_util/type_identity/requirements/typedefs.cc: Likewise. * testsuite/21_strings/basic_string/hash/debug.cc: Likewise. * testsuite/21_strings/basic_string/hash/hash.cc: Likewise. * testsuite/21_strings/basic_string/literals/types-char8_t.cc: Likewise. * testsuite/21_strings/basic_string/literals/types.cc: Likewise. * testsuite/21_strings/basic_string/literals/values-char8_t.cc: Likewise. * testsuite/21_strings/basic_string/literals/values.cc: Likewise. * testsuite/21_strings/basic_string/modifiers/64422.cc: Likewise. * testsuite/21_strings/basic_string/range_access/wchar_t/1.cc: Likewise. * testsuite/21_strings/basic_string/requirements/citerators.cc: Likewise. * testsuite/21_strings/basic_string/requirements/typedefs.cc: Likewise. * testsuite/21_strings/basic_string/types/pmr_typedefs.cc: Likewise. * testsuite/21_strings/basic_string_view/literals/types-char8_t.cc: Likewise. * testsuite/21_strings/basic_string_view/literals/types.cc: Likewise. * testsuite/21_strings/basic_string_view/literals/values-char8_t.cc: Likewise. * testsuite/21_strings/basic_string_view/literals/values.cc: Likewise. * testsuite/21_strings/basic_string_view/requirements/typedefs.cc: Likewise. * testsuite/21_strings/basic_string_view/typedefs.cc: Likewise. * testsuite/21_strings/char_traits/requirements/constexpr_functions.cc: Likewise. * testsuite/21_strings/char_traits/requirements/constexpr_functions_c++17.cc: Likewise. * testsuite/21_strings/char_traits/requirements/constexpr_functions_c++20.cc: Likewise. * testsuite/22_locale/ctype/is/string/89728_neg.cc: Likewise. * testsuite/25_algorithms/fill/4.cc: Likewise. * testsuite/25_algorithms/fill_n/1.cc: Likewise. * testsuite/experimental/functional/searchers.cc: Likewise. Use char_traits::length instead of wcslen. * t
[Bug libstdc++/98725] Review what is disabled in libstdc++ by --disable-wchar_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98725 --- Comment #12 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:9a89281c4005a51eeed058ca66bcce8df1dd1b24 commit r12-4267-g9a89281c4005a51eeed058ca66bcce8df1dd1b24 Author: Jonathan Wakely Date: Fri Oct 8 14:26:09 2021 +0100 libstdc++: Define deleted wchar_t overloads unconditionally [PR 98725] We don't need to have support in order to delete overloads for inserting wide characters into narrow streams. libstdc++-v3/ChangeLog: PR libstdc++/98725 * include/std/ostream (operator<<(basic_ostream&, wchar_t)) (operator<<(basic_ostream&, const wchar_t*)): Always define as deleted. Do not check _GLIBCXX_USE_WCHAR_T.
[Bug libstdc++/98725] Review what is disabled in libstdc++ by --disable-wchar_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98725 --- Comment #11 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:3c9fbc26af6739c7ddf8f0895ae68b530cf88bbe commit r12-4266-g3c9fbc26af6739c7ddf8f0895ae68b530cf88bbe Author: Jonathan Wakely Date: Fri Oct 8 14:25:42 2021 +0100 libstdc++: Define std::wstring_convert unconditionally [PR 98725] The wchar_t type is defined unconditionally for C++, so there is no reason for std::wstring_convert and std::wbuffer_convert to be disabled when is not usable. It should be possible to use those class templates with char16_t and char32_t even if wchar_t conversions don't work. libstdc++-v3/ChangeLog: PR libstdc++/98725 * include/bits/locale_conv.h (wstring_convert, wbuffer_convert): Define unconditionally. Do not check _GLIBCXX_USE_WCHAR_T.
[Bug libstdc++/98725] Review what is disabled in libstdc++ by --disable-wchar_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98725 --- Comment #10 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:4bdb9d618d30fc33d7eaab374baf377fa4e9d955 commit r12-4265-g4bdb9d618d30fc33d7eaab374baf377fa4e9d955 Author: Jonathan Wakely Date: Fri Oct 8 14:52:07 2021 +0100 libstdc++: Enable type traits for wchar_t unconditionally [PR98725] None of these traits depend on libc support for wchar_t, so they should be defined unconditionally. The wchar_t type is always defined in C++. libstdc++-v3/ChangeLog: PR libstdc++/98725 * include/c_global/cstddef [!_GLIBCXX_USE_WCHAR_T] (__byte_operand): Define specialization. * include/std/type_traits (__make_signed) (__make_unsigned): Remove redundant check for __WCHAR_TYPE__ being defined. * include/tr1/type_traits [!_GLIBCXX_USE_WCHAR_T] (__is_integral_helper): Likewise.
[Bug libstdc++/98725] Review what is disabled in libstdc++ by --disable-wchar_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98725 --- Comment #9 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:4997c8b30ecfc82f9e6ce874cbd3840e227522eb commit r12-4264-g4997c8b30ecfc82f9e6ce874cbd3840e227522eb Author: Jonathan Wakely Date: Fri Oct 8 14:48:04 2021 +0100 libstdc++: Enable vstring for wchar_t unconditionally [PR98725] None of these vstring specializations depend on libc support for wchar_t, so can be enabled unconditionally now that char_traits is always available. libstdc++-v3/ChangeLog: PR libstdc++/98725 * include/ext/rc_string_base.h [!_GLIBCXX_USE_WCHAR_T] (__rc_string_base): Define member function. * include/ext/vstring.h [!_GLIBCXX_USE_WCHAR_T] (hash<__gnu_cxx::__wvstring>): Define specialization. * include/ext/vstring_fwd.h [!_GLIBCXX_USE_WCHAR_T] (__wvstring) (__wsso_string, __wrc_string): Declare typedefs.
[Bug libstdc++/98725] Review what is disabled in libstdc++ by --disable-wchar_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98725 --- Comment #8 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:0afb9ebaab09b999f1d158ffc3fb906fdab9df67 commit r12-4263-g0afb9ebaab09b999f1d158ffc3fb906fdab9df67 Author: Jonathan Wakely Date: Fri Oct 8 14:24:18 2021 +0100 libstdc++: Always define typedefs and hash functions for wide strings [PR 98725] The wstring and wstring_view typedefs should be enabled even if isn't supported, because char_traits works unconditionally. Similarly, the std::hash specializations for wide strings do not depend on support. Although the primary template works OK for std::char_traits in the absence of support, this patch still defines it as an explicit specialization for compatibility with declarations that expect it to be specialized. The explicit specialization just uses the same __gnu_cxx::char_traits base class as the primary template. libstdc++-v3/ChangeLog: PR libstdc++/98725 * include/bits/char_traits.h (char_traits): Define explicit specialization unconditionally. * include/bits/basic_string.h (hash): Define unconditionally. Do not check _GLIBCXX_USE_WCHAR_T. * include/bits/stringfwd.h (wstring): Likewise. * include/debug/string (wstring): Likewise. * include/experimental/string_view (experimental::wstring_view) (hash): Likewise. * include/std/string (pmr::wstring, hash): Likewise. * include/std/string_view (wstring_view, hash): Likewise.
[Bug libstdc++/98725] Review what is disabled in libstdc++ by --disable-wchar_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98725 --- Comment #7 from Jonathan Wakely --- We could make codecvt work if we assume that wchar_t contains UTF-32 or UTF-16 (depending on the size of wchar_t) and reuse the specializations for char32_t and char16_t. Those specializations are implemented entirely in libstdc++ with no libc help. It's unclear (to me) whether --disable-wchar_t is used explicitly to produce a smaller libstdc++ build, without wchar_t instantiations, or is just used implicitly on systems where the libc support is missing. So it's hard to know whether "emulate wchar_t support in terms of UTF-32" is desirable, or if that would frustrate users explicitly trying to get a smaller library. Presumably anybody who wants a smaller library would also want to disable the codecvt facets for char32_t and char16_t, but nobody has requested that. I'm not going to spend any more time on it after enabling wide strings and some type traits.
[Bug target/43744] SH: Error: pcrel too far
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43744 --- Comment #18 from Giulio Benetti --- Created attachment 51575 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51575&action=edit Pre-processed dvb_bbheader_bb_impl.cc.cpp(dvb_bbheader_bb_impl.cc.s)
[Bug target/43744] SH: Error: pcrel too far
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43744 --- Comment #17 from Giulio Benetti --- Created attachment 51574 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51574&action=edit Pre-processed dvb_bbheader_bb_impl.cc.cpp(dvb_bbheader_bb_impl.cc.ii)
[Bug target/43744] SH: Error: pcrel too far
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43744 Giulio Benetti changed: What|Removed |Added CC||giulio.benetti@benettiengin ||eering.com --- Comment #16 from Giulio Benetti --- When building package gnuradio on buildroot we get this error: ``` [ 82%] Building CXX object gr-digital/lib/CMakeFiles/gnuradio-digital.dir/correlate_access_code_bb_ts_impl.cc.o /tmp/ccqgyzpD.s: Assembler messages: /tmp/ccqgyzpD.s:4751: Error: pcrel too far gr-dtv/lib/CMakeFiles/gnuradio-dtv.dir/build.make:312: recipe for target 'gr-dtv/lib/CMakeFiles/gnuradio-dtv.dir/dvb/dvb_bbheader_bb_impl.cc.o' failed ``` This happens with sh4 shared gcc 9/10/11. I could not find a work-around for it. To reproduce the bug: ''' # git clone git://git.busybox.net/buildroot # wget https://git.busybox.net/buildroot-test/tree/utils/br-reproduce-build - modify BASE_GIT=... with your buildroot path in br-reproduce-build then: # chmod a+x br-reproduce-build # ./br-reproduce-build 1db6c59c98e3c09fa13277076ee2fbe7967f1f6b ''' Preprocessed files follow.
[Bug target/102169] powerpc64 int memory operations using FP instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102169
Carl Love changed:
What|Removed |Added
CC||carll at gcc dot gnu.org
--- Comment #5 from Carl Love ---
With no optimization, GCC generates a three instruction sequence to store to
the stack frame rather than using a single stw instruction.
Adding this for informational purposes per Segher's request.
The test program
#include
#include
int marker2 (int a) { return (1); }
int
main (int argc, char **argv, char **envp)
{
marker2 (43);
return argc;
}
Generates the three instruction sequence in both the main and marker2 function.
Just cutting and pasting the marker2 code for P9 and P10.
On Power 9
carll@marlin:~$ gcc -g stfiwx-bug.c -o stfiwx-bug
carll@marlin:~$ objdump -S -d stfiwx-bug > stfiwx-bug.dump
carll@marlin:~$ which gcc
/usr/bin/gcc
carll@marlin:~$ gcc --version
gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
int marker2 (int a) { return (1); }
7bc: f8 ff e1 fb std r31,-8(r1)
7c0: c1 ff 21 f8 stdur1,-64(r1)
7c4: 78 0b 3f 7c mr r31,r1
7c8: 78 1b 69 7c mr r9,r3
7cc: 2c 00 3f 91 stw r9,44(r31) << here
7d0: 01 00 20 39 li r9,1
7d4: 78 4b 23 7d mr r3,r9
7d8: 40 00 3f 38 addir1,r31,64
7dc: f8 ff e1 eb ld r31,-8(r1)
7e0: 20 00 80 4e blr
on Power 10
carll@ltcd97-lp1:~$ gcc -g stfiwx-bug.c -o stfiwx-bug
carll@ltcd97-lp1:~$ objdump -S -d stfiwx-bug > stfiwx-bug.dump
carll@ltcd97-lp1:~$ which gcc
/usr/bin/gcc
carll@ltcd97-lp1:~$ gcc --version
gcc (Ubuntu 10.3.0-1ubuntu1) 10.3.0
int marker2 (int a) { return (1); }
7bc: f8 ff e1 fb std r31,-8(r1)
7c0: c1 ff 21 f8 stdur1,-64(r1)
7c4: 78 0b 3f 7c mr r31,r1
7c8: 78 1b 69 7c mr r9,r3
7cc: e6 01 09 7c mtfprwz f0,r9 << here
7d0: 2c 00 3f 39 addir9,r31,44 << here
7d4: ae 4f 00 7c stfiwx f0,0,r9 << here
7d8: 01 00 20 39 li r9,1
7dc: 78 4b 23 7d mr r3,r9
7e0: 40 00 3f 38 addir1,r31,64
7e4: f8 ff e1 eb ld r31,-8(r1)
7e8: 20 00 80 4e blr
[Bug testsuite/102658] New: [12 regression] Many test case failures after r12-4240
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102658
Bug ID: 102658
Summary: [12 regression] Many test case failures after r12-4240
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: seurer at gcc dot gnu.org
Target Milestone: ---
Looks like some of the test cases were missed in the udpate
previous run: g:50e20ee6e40643c23b53bacda4db4dd9573d7c8a, r12-4239: 66 failures
this run: g:2b8453c401b699ed93c085d0413ab4b5030bcdb8, r12-4240: 106
failures
FAIL: c-c++-common/Wstringop-overflow-2.c -Wc++-compat (test for warnings,
line 226)
FAIL: c-c++-common/Wstringop-overflow-2.c -Wc++-compat (test for warnings,
line 227)
FAIL: c-c++-common/Wstringop-overflow-2.c -Wc++-compat (test for warnings,
line 325)
FAIL: c-c++-common/Wstringop-overflow-2.c -Wc++-compat (test for warnings,
line 326)
FAIL: c-c++-common/Wstringop-overflow-2.c -std=gnu++14 (test for warnings,
line 226)
FAIL: c-c++-common/Wstringop-overflow-2.c -std=gnu++14 (test for warnings,
line 227)
FAIL: c-c++-common/Wstringop-overflow-2.c -std=gnu++14 (test for warnings,
line 325)
FAIL: c-c++-common/Wstringop-overflow-2.c -std=gnu++14 (test for warnings,
line 326)
FAIL: c-c++-common/Wstringop-overflow-2.c -std=gnu++17 (test for warnings,
line 226)
FAIL: c-c++-common/Wstringop-overflow-2.c -std=gnu++17 (test for warnings,
line 227)
FAIL: c-c++-common/Wstringop-overflow-2.c -std=gnu++17 (test for warnings,
line 325)
FAIL: c-c++-common/Wstringop-overflow-2.c -std=gnu++17 (test for warnings,
line 326)
FAIL: c-c++-common/Wstringop-overflow-2.c -std=gnu++2a (test for warnings,
line 226)
FAIL: c-c++-common/Wstringop-overflow-2.c -std=gnu++2a (test for warnings,
line 227)
FAIL: c-c++-common/Wstringop-overflow-2.c -std=gnu++2a (test for warnings,
line 325)
FAIL: c-c++-common/Wstringop-overflow-2.c -std=gnu++2a (test for warnings,
line 326)
FAIL: c-c++-common/Wstringop-overflow-2.c -std=gnu++98 (test for warnings,
line 226)
FAIL: c-c++-common/Wstringop-overflow-2.c -std=gnu++98 (test for warnings,
line 227)
FAIL: c-c++-common/Wstringop-overflow-2.c -std=gnu++98 (test for warnings,
line 325)
FAIL: c-c++-common/Wstringop-overflow-2.c -std=gnu++98 (test for warnings,
line 326)
FAIL: g++.dg/warn/Wuninitialized-13.C -std=gnu++14 (test for warnings, line
8)
FAIL: g++.dg/warn/Wuninitialized-13.C -std=gnu++17 (test for warnings, line
8)
FAIL: g++.dg/warn/Wuninitialized-13.C -std=gnu++2a (test for warnings, line
8)
FAIL: g++.dg/warn/Wuninitialized-13.C -std=gnu++98 (test for warnings, line
8)
FAIL: gcc.dg/Warray-bounds-51.c target { i?86-*-* x86_64-*-* } (test for
warnings, line 41)
FAIL: gcc.dg/Wstringop-overflow-14.c target { i?86-*-* x86_64-*-* } (test for
warnings, line 38)
FAIL: gcc.dg/Wstringop-overflow-21.c (test for warnings, line 29)
FAIL: gcc.dg/Wstringop-overflow-21.c (test for warnings, line 56)
FAIL: gcc.dg/Wstringop-overflow-76.c (test for warnings, line 117)
FAIL: gcc.dg/Wstringop-overflow-76.c (test for warnings, line 33)
FAIL: gcc.dg/Wstringop-overflow-76.c (test for warnings, line 50)
FAIL: gcc.dg/Wstringop-overflow-76.c (test for warnings, line 98)
FAIL: gcc.dg/Wstringop-overflow-76.c note (test for warnings, line 105)
FAIL: gcc.dg/Wstringop-overflow-76.c note (test for warnings, line 85)
FAIL: gcc.target/powerpc/dform-1.c scan-assembler lxsd
FAIL: gcc.target/powerpc/dform-1.c scan-assembler stxsd
FAIL: gcc.target/powerpc/dform-2.c scan-assembler-not xscvdpspn
FAIL: gcc.target/powerpc/pr80510-2.c scan-assembler \\mstxsspx\\M
FAIL: gcc.target/powerpc/pr80510-2.c scan-assembler-not \\mmfvsrwz\\M
FAIL: libgomp.graphite/force-parallel-8.c scan-tree-dump-times graphite "5
loops carried no dependency" 1
commit 2b8453c401b699ed93c085d0413ab4b5030bcdb8 (HEAD, refs/bisect/bad)
Author: liuhongt
Date: Mon Sep 6 13:48:49 2021 +0800
Enable auto-vectorization at O2 with very-cheap cost model.
[Bug other/102657] New: libcody makefile is missing a mostlyclean target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102657 Bug ID: 102657 Summary: libcody makefile is missing a mostlyclean target Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: egallager at gcc dot gnu.org CC: nathan at gcc dot gnu.org Target Milestone: --- Doing `make mostlyclean` in a build directory fails in libcody saying: Doing mostlyclean in libcody make[2]: *** No rule to make target `mostlyclean'. Stop. make[1]: *** [mostlyclean-libcody] Error 1 make: *** [do-mostlyclean] Error 2 Reading libcody's Makefile confirms that this target is indeed missing.
[Bug fortran/65454] Extending both forms of relational operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65454 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed|2021-09-12 00:00:00 |2021-10-8 Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #6 from anlauf at gcc dot gnu.org --- Patch: https://gcc.gnu.org/pipermail/fortran/2021-October/056681.html
[Bug fortran/54753] assumed-rank dummies: Reject assumed-size actuals in in some cases (C535c; in F2018: C839)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54753 --- Comment #6 from CVS Commits --- The master branch has been updated by Sandra Loosemore : https://gcc.gnu.org/g:7afb61087d2cb7a6d27463bab5a7567fac69f97a commit r12-4257-g7afb61087d2cb7a6d27463bab5a7567fac69f97a Author: Sandra Loosemore Date: Fri Oct 8 14:29:12 2021 -0700 Fortran: Add diagnostic for F2018:C839 (TS29113:C535c) 2021-10-08 Sandra Loosemore PR fortran/54753 gcc/fortran/ * interface.c (gfc_compare_actual_formal): Add diagnostic for F2018:C839. Refactor shared code and fix bugs with class array info lookup, and extend similar diagnostic from PR94110 to also cover class types. gcc/testsuite/ * gfortran.dg/c-interop/c535c-1.f90: Rewrite and expand. * gfortran.dg/c-interop/c535c-2.f90: Remove xfails. * gfortran.dg/c-interop/c535c-3.f90: Likewise. * gfortran.dg/c-interop/c535c-4.f90: Likewise. * gfortran.dg/PR94110.f90: Extend to cover class types.
[Bug c++/102656] ICE on coroutines on -fsanitize=address -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102656
--- Comment #1 from Dmitry Prokoptsev ---
Follow-up: adding a non-trivial copy constructor --
future(const future& f): x(f.x) {}
-- also resolves the ICE.
[Bug c++/102644] deduction failure when having default non-type template parameters that are lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102644
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2021-10-08
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #1 from Andrew Pinski ---
Confirmed.
Here is another example:
template
struct s {
template
int foo() { return 0; }
};
int main() {
s a{};
return a.foo();
}
CUT
Note the original example causes clang to ICE :) while this one is accepted.
[Bug c++/102656] New: ICE on coroutines on -fsanitize=address -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102656
Bug ID: 102656
Summary: ICE on coroutines on -fsanitize=address -O1
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dprokoptsev at gmail dot com
Target Milestone: ---
Here's the minimal example I've been able to come up with:
// ICEs on -fcoroutines -O1 -fsanitize=address, on any gcc version between 10.2
and trunk (does compile though on 10.1), checked on godbolt.
#include
/* 2*/ class promise;
/* 3*/
/* 4*/ struct future {
/* 5*/ using promise_type = promise;
/* 6*/ future() = default;
/* 7*/ int x = 0; // commenting out this line resolves the ICE
/* 8*/ };
/* 9*/
/*10*/ class promise {
/*11*/ public:
/*12*/future get_return_object() noexcept { return {}; }
/*13*/auto initial_suspend() noexcept { return std::suspend_never{}; }
/*14*/auto final_suspend() noexcept { return std::suspend_never{}; }
/*15*/
/*16*/void return_void() noexcept {}
/*17*/void unhandled_exception() {}
/*18*/};
/*19*/
/*20*/ future func() { co_return; }
gcc-10.2 [x86-64] yields
:20:28: internal compiler error: in expand_expr_addr_expr_1, at
expr.c:8075
20 | future func() { co_return; }
[Bug target/102652] Unnecessary zeroing out of local ARM NEON arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102652 Andrew Pinski changed: What|Removed |Added Keywords||ra --- Comment #2 from Andrew Pinski --- >From the gimple level: _27 = __builtin_aarch64_ld1v16qi (in_11(D)); _28 = __builtin_aarch64_ashrv16qi (_27, 7); MEM [(struct int8x16x4_t *)&x] = _27; MEM [(struct int8x16x4_t *)&x + 16B] = _28; MEM [(struct int8x16x4_t *)&x + 32B] = _28; MEM [(struct int8x16x4_t *)&x + 48B] = _28; __val_36 = MEM[(struct int8x16x4_t *)&x]; __builtin_aarch64_st4v16qi (out_13(D), __val_36); _43 = in_11(D) + 16; _44 = __builtin_aarch64_ld1v16qi (_43); _45 = __builtin_aarch64_ashrv16qi (_44, 7); _48 = out_13(D) + 64; MEM [(struct int8x16x4_t *)&x] = _44; MEM [(struct int8x16x4_t *)&x + 16B] = _45; MEM [(struct int8x16x4_t *)&x + 32B] = _45; MEM [(struct int8x16x4_t *)&x + 48B] = _45; __val_53 = MEM[(struct int8x16x4_t *)&x]; __builtin_aarch64_st4v16qi (_48, __val_53); [tail call] MEM [(struct int8x16x4_t *)&x] = _27; MEM [(struct int8x16x4_t *)&x + 16B] = _28; MEM [(struct int8x16x4_t *)&x + 32B] = _28; MEM [(struct int8x16x4_t *)&x + 48B] = _28; __val_36 = MEM[(struct int8x16x4_t *)&x]; Could be improved for sure. Otherwise there is a register allocation issue dealing with multi-register modes which might be recorded as another bug already (that is the xN types have known register allocation issues).
[Bug target/102652] Unnecessary zeroing out of local ARM NEON arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102652 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Keywords||missed-optimization
[Bug c++/102577] Function frame size in relation to variables in conditional subscopes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102577 --- Comment #5 from Andrew Pinski --- Also the code is correct just the stack limit is too small. This is not something which GCC can control directly. stack space is not specified in the C++ standard at all and I highly doubt it would ever be.
[Bug middle-end/102606] large array in a dead-code is not optimized away at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102606 Andrew Pinski changed: What|Removed |Added CC||krzyk240 at gmail dot com --- Comment #5 from Andrew Pinski --- *** Bug 102577 has been marked as a duplicate of this bug. ***
[Bug c++/102577] Function frame size in relation to variables in conditional subscopes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102577 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Andrew Pinski --- PR 102606 has more information on why this is valid for GCC to do. *** This bug has been marked as a duplicate of bug 102606 ***
[Bug c++/102647] Wrong caret location for 'attribute directive ignored' warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102647 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=64332 Depends on|64332 | --- Comment #1 from Andrew Pinski --- Attributes in general have a location issue. There a few others than the ones I listed so far Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64332 [Bug 64332] wrong location for Wattributes warning
[Bug tree-optimization/102655] wrong code from optimizer for simple loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102655 --- Comment #7 from John Denker --- Ugh. You're right. I should have figured this out on my own. All the clues were there. Sorry to have bothered you.
[Bug c++/102651] [9/10/11/12 Regression] typeid(X**) instantiates X
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102651 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-10-08 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed. I thought I had saw another bug like this bug I can't seem to find it.
[Bug tree-optimization/102655] wrong code from optimizer for simple loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102655 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #6 from Andrew Pinski --- The code is all dead and does nothing so it will be removed. GCC is able to inline dummy to figure that out.
[Bug libstdc++/98725] Review what is disabled in libstdc++ by --disable-wchar_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98725 --- Comment #6 from Jonathan Wakely --- could do this after including : #if !defined WCHAR_MIN && defined __WCHAR_MIN__ # define WCHAR_MIN __WCHAR_MIN__ #endif #if !defined WCHAR_MAX && defined __WCHAR_MAX__ # define WCHAR_MAX __WCHAR_MAX__ #endif
[Bug libgcc/99759] morestack.S should support .init_array.0 besides .ctors.65535
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99759
Fangrui Song changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW |RESOLVED
--- Comment #4 from Fangrui Song ---
Fixed by f49e3d28be44179f07b8a06159139ce77096dda7 ("libgcc: use .init_stack for
constructors if available").
Thanks, Ian!
[Bug tree-optimization/102655] wrong code from optimizer for simple loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102655 --- Comment #5 from John Denker --- Created attachment 51573 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51573&action=edit Slightly mutated version 'fumtu', for contrast; no bug observed. Slightly mutated version 'fumtu', for contrast; no bug observed.
[Bug tree-optimization/102655] wrong code from optimizer for simple loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102655 --- Comment #4 from John Denker --- Created attachment 51572 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51572&action=edit Slightly mutated version 'snafu', for contrast; no bug observed. Slightly mutated version 'snafu', for contrast; no bug observed.
[Bug tree-optimization/102655] wrong code from optimizer for simple loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102655 --- Comment #3 from John Denker --- Created attachment 51571 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51571&action=edit Slightly mutated version 'bar', for contrast; no bug observed. Slightly mutated version 'bar', for contrast; no bug observed.
[Bug tree-optimization/102655] wrong code from optimizer for simple loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102655 --- Comment #2 from John Denker --- Created attachment 51570 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51570&action=edit Slightly mutated version 'foo', for contrast; no bug observed. Slightly mutated version 'foo', for contrast; no bug observed.
[Bug tree-optimization/102655] wrong code from optimizer for simple loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102655 --- Comment #1 from John Denker --- Created attachment 51569 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51569&action=edit Console long from compilation step. Console log from compilation step.
[Bug tree-optimization/102655] New: wrong code from optimizer for simple loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102655 Bug ID: 102655 Summary: wrong code from optimizer for simple loop Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: wildebeest at av8n dot com Target Milestone: --- Created attachment 51568 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51568&action=edit precompiled .i file to demonstrate bug In the doit() function of the attached gccbug.i file, there is a simple loop that does some arithmetic. -- Optimization level 0 seems to produce the correct code. -- Any higher optimization produces wildly wrong behavior. The loop is executed far too few times. -- Unsurprisingly, both g++ and gcc produce the same misbehavior. -- This is observed with the latest gcc-snapshot (10.0.1) and also with older versions (9.3.0). -- Debugging is difficult. Small changes to the program, even when they are far outside the doit() function, cause the behavior to change. To exhibit this, I will precompile some of the mutant versions and put the .i files in the comments. The exact command used to create the main .i file was: /usr/lib/gcc-snapshot/bin/gcc -v -save-temps -g -O1 -Dgxx=gcc -DbldOpts="-O1 -Dgxx=gcc" -Wall ./gccbug.c -o ./gccbug The console output from the compilation step will be attached in the comments. If you compile the .i file with -O1, the bug appears. If you recompile with -O0, the bug is not observed. Platform: :; uname -srmo Linux 5.13.1+ x86_64 GNU/Linux :; lsb_release -a LSB Version: core-11.1.0ubuntu2-noarch:cxx-3.0-amd64:cxx-3.0-noarch:cxx-3.1-amd64:cxx-3.1-noarch:cxx-3.2-amd64:cxx-3.2-noarch:cxx-4.0-amd64:cxx-4.0-noarch:cxx-4.1-amd64:cxx-4.1-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.0-amd64:graphics-3.0-noarch:graphics-3.1-amd64:graphics-3.1-noarch:graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch:graphics-4.1-amd64:graphics-4.1-noarch:printing-11.1.0ubuntu2-noarch:security-11.1.0ubuntu2-noarch Distributor ID: Ubuntu Description:Ubuntu 20.04.3 LTS Release:20.04 Codename: focal :; /usr/lib/gcc-snapshot/bin/gcc --version gcc (Ubuntu 20200418-1ubuntu1) 10.0.1 20200418 (experimental) [master revision b57e1621eb7:e6f26876f0c:baf3b9b2e5259558ef86bd62398e2ccecd7a4a4c] 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. :; /usr/lib/gcc-snapshot/bin/gcc -v Using built-in specs. COLLECT_GCC=/usr/lib/gcc-snapshot/bin/gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/10/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa:hsa OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 20200418-1ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr/lib/gcc-snapshot --with-gcc-major-version-only --program-prefix= --enable-shared --enable-linker-build-id --disable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none,amdgcn-amdhsa,hsa --without-cuda-driver --enable-checking=yes --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 10.0.1 20200418 (experimental) [master revision b57e1621eb7:e6f26876f0c:baf3b9b2e5259558ef86bd62398e2ccecd7a4a4c] (Ubuntu 20200418-1ubuntu1)
[Bug c++/102651] [9/10/11/12 Regression] typeid(X**) instantiates X
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102651 Andrew Pinski changed: What|Removed |Added Keywords||rejects-valid Summary|typeid(X**) instantiates X |[9/10/11/12 Regression] ||typeid(X**) instantiates X Target Milestone|--- |9.5
[Bug libstdc++/102654] [11/12 Regression] undefined reference to `std::variant::variant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102654 Jonathan Wakely changed: What|Removed |Added Known to fail||11.2.1, 12.0 Summary|undefined reference to |[11/12 Regression] |`std::variant::variant::variant(std::string_view&&)' |std::string_view, ||void>(std::string_view&&)' Last reconfirmed||2021-10-08 Target Milestone|--- |11.3 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Known to work||10.3.1
[Bug c++/102653] operator* doesn't work for enum classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102653 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely --- This is the expected behaviour, and every C++ compiler will give the same result. In your second example there is an implicit conversion to int. Scoped enums (aka enum classes) do not implicitly convert to int.
[Bug rtl-optimization/102627] [11/12 Regression] wrong code with "-O1"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102627 --- Comment #5 from CVS Commits --- The master branch has been updated by Vladimir Makarov : https://gcc.gnu.org/g:9046e0d46fc285e5c59c87182d48c8de0f7f929c commit r12-4256-g9046e0d46fc285e5c59c87182d48c8de0f7f929c Author: Vladimir N. Makarov Date: Fri Oct 8 10:16:09 2021 -0400 [PR102627] Use at least natural mode during splitting hard reg live range In the PR test case SImode was used to split live range of cx on x86-64 because it was the biggest mode for this hard reg in the function. But all 64-bits of cx contain structure members. We need always to use at least natural mode of hard reg in splitting to fix this problem. gcc/ChangeLog: PR rtl-optimization/102627 * lra-constraints.c (split_reg): Use at least natural mode of hard reg. gcc/testsuite/ChangeLog: PR rtl-optimization/102627 * gcc.target/i386/pr102627.c: New test.
[Bug d/102618] d-demangle: anonymous symbols are not being properly skipped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102618 --- Comment #2 from Luís Ferreira --- Sorry, I sent the wrong example. That example was to cover a missing test. The actual mangle that is not being handled is _D8demangle9anonymous0Z . It should be demangled as demangle.anonymous .
[Bug d/102618] d-demangle: anonymous symbols are not being properly skipped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102618 ibuclaw at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ibuclaw at gcc dot gnu.org Component|demangler |d CC||ibuclaw at gcc dot gnu.org --- Comment #1 from ibuclaw at gcc dot gnu.org --- How did you check this? The given example passes the testsuite. # --format=dlang _D8demangle9anonymous03fooZ demangle.anonymous.foo
[Bug tree-optimization/102650] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102650 Andrew Macleod changed: What|Removed |Added CC||amacleod at redhat dot com --- Comment #1 from Andrew Macleod --- This is a result of the vagaries of the single subrange value-range. VRP is seeing: # f_11 = PHI <-1(2), 2(3)> goto ; [100.00%] [local count: 955630225]: _3 = (unsigned short) f_11; _6 = _3 + 2; e_19 = (short int) _6; It knows f_11 is [-1, 2] and when that is cast to a ushort, produces ~[3, 65534]. That is all we knew about it in GCC11, so when we calculate_6 = ~[3,65534] + 2 it comes up with [1,4] and the e_19 == 0 later on then can be folded away. in gcc12, EVRP has figured out that _3 is unsigned short [2, 2][+INF, +INF]. which if we add 2 to it, would come up with [1,1][4,4] which would be perfect. We save this to the value_range global table in EVRP, but alas it gets transliterated to a single pair value_range : _3 : unsigned short [2, +INF] Now when VRP calculates ~[3, 65534] and intersects that with the known global [2, +INF] the legacy intersect routine has to come up with pair and decides to keep [2, +INF]. when you add 2 to that, 0 is no longer eliminated.
[Bug tree-optimization/102652] Unnecessary zeroing out of local ARM NEON arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102652
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2021-10-08
--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed on the GCC 11 release. There is an active effort to improve the code
generation for these intrinsics and current trunk produces:
bug:
ldr q5, [x1]
sshrv4.16b, v5.16b, 7
mov v0.16b, v5.16b
mov v1.16b, v4.16b
mov v2.16b, v4.16b
mov v3.16b, v4.16b
st4 {v0.16b - v3.16b}, [x0], 64
ldr q4, [x1, 16]
mov v0.16b, v4.16b
sshrv4.16b, v4.16b, 7
mov v1.16b, v4.16b
mov v2.16b, v4.16b
mov v3.16b, v4.16b
st4 {v0.16b - v3.16b}, [x0]
ret
Not optimal yet, but moving in the right direction
[Bug libstdc++/102654] New: undefined reference to `std::variant::variant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102654
Bug ID: 102654
Summary: undefined reference to `std::variant::variant(std::string_view&&)'
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
The following code will generate an undefined reference error since gcc-11. I
don't know if this is a bug.
#include
#include
struct my_variant : std::variant { };
int main() {
std::string_view s = "hello";
my_variant v{s};
}
https://godbolt.org/z/zbjhe1hqE
[Bug c++/102653] New: operator* doesn't work for enum classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102653
Bug ID: 102653
Summary: operator* doesn't work for enum classes
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: woweric at live dot com
Target Milestone: ---
enum class TextWrap {NONE = 0, DOWN = 1, UP = -1};
int main()
{
TextWrap wrap = TextWrap::NONE;
int num = 20 * wrap;
}
gives the error:
test.cpp:6:18: error: no match for 'operator*' (operand types are 'int' and
'TextWrap')
but the following code compiles fine:
enum TextWrap {NONE = 0, DOWN = 1, UP = -1};
int main()
{
TextWrap wrap = NONE;
int num = 20 * wrap;
}
[Bug tree-optimization/102652] New: Unnecessary zeroing out of local ARM NEON arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102652
Bug ID: 102652
Summary: Unnecessary zeroing out of local ARM NEON arrays
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: decio at decpp dot net
Target Milestone: ---
Created attachment 51567
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51567&action=edit
Testcase to reproduce the bug. Sorry for gzipping it, but if uncompressed, it
exceeds the 1 MB file size limit.
This is my first time reporting a compiler bug, so please be kind to me if I
made any mistakes. In particular, I'm not sure if tree-optimization is the
correct component.
Consider the attached code, briefly reproduced next, which is a minimal
testcase obtained from many instances of more complex code in use in an
application of mine:
/* START CODE */
#include
void bug(int8_t *out, const int8_t *in) {
for (int i = 0; i < 2; i++) {
int8x16x4_t x;
x.val[0] = vld1q_s8(&in[16 * i]);
x.val[1] = x.val[2] = x.val[3] = vshrq_n_s8(x.val[0], 7);
vst4q_s8(&out[64 * i], x);
}
}
/* END CODE */
This is the assembly output of this code:
:
0: d10203ffsub sp, sp, #0x80
4: d289mov x9, #0x0// #0
8: d288mov x8, #0x0// #0
c: d287mov x7, #0x0// #0
10: d286mov x6, #0x0// #0
14: d285mov x5, #0x0// #0
18: d284mov x4, #0x0// #0
1c: d283mov x3, #0x0// #0
20: a90023e9stp x9, x8, [sp]
24: d282mov x2, #0x0// #0
28: a9011be7stp x7, x6, [sp, #16]
2c: a90213e5stp x5, x4, [sp, #32]
30: f9001be3str x3, [sp, #48]
34: 3dc00020ldr q0, [x1]
38: a903a7e2stp x2, x9, [sp, #56]
3c: a9049fe8stp x8, x7, [sp, #72]
40: 4f090404sshrv4.16b, v0.16b, #7
44: 3d8003e0str q0, [sp]
48: 4c4023e0ld1 {v0.16b-v3.16b}, [sp]
4c: a90597e6stp x6, x5, [sp, #88]
50: 4ea41c81mov v1.16b, v4.16b
54: a9068fe4stp x4, x3, [sp, #104]
58: 4ea41c82mov v2.16b, v4.16b
5c: f9003fe2str x2, [sp, #120]
60: 4ea41c83mov v3.16b, v4.16b
64: 4c9fst4 {v0.16b-v3.16b}, [x0], #64
68: 3dc00424ldr q4, [x1, #16]
6c: 910103e1add x1, sp, #0x40
70: 3d8013e4str q4, [sp, #64]
74: 4f090484sshrv4.16b, v4.16b, #7
78: 4c402020ld1 {v0.16b-v3.16b}, [x1]
7c: 4ea41c81mov v1.16b, v4.16b
80: 4ea41c82mov v2.16b, v4.16b
84: 4ea41c83mov v3.16b, v4.16b
88: 4c00st4 {v0.16b-v3.16b}, [x0]
8c: 910203ffadd sp, sp, #0x80
90: d65f03c0ret
It can be seen that the generated code attemps to zero out the variable "x",
which I understand is, first of all, uncalled for (seeing as it's local to
function bug and not in the global scope), and even if it were necessary, it
has no effect anyway since these variables are initialized later.
Many registers are redundantly zeroed (at addresses 4-1c and 24) which are then
stored in the stack (at addresses 20, 28-30, 38, 3c, 4c, 54 and 5c). None of
these instructions were required to be generated. The zeroed out values are
loaded in addresses 48 and 78, but 3 out of the 4 registers (v1, v2, v3) are
immediately overwritten, in addresses 50, 58 and 60 for the first load, and
7c-84 for the second load. For the remaining register that is loaded (v0), an
unnecessary and redundant trip to memory is performed: for the first iteration
of the loop, q0 is loaded at address 34, stored at address 44 and reloaded with
the same value in address 48. The second and third instructions could just be
removed. For the second iteration, a a load is performed in address 68,
followed by a store in address 70 and another load in address 78. Again, the
second and third instructions could be removed, so long as the destination
register of the instruction in address 68, and the source register of the
instruction in address 74, were both changed to q0.
In total, it appears that 24 out of 37 instructions could be removed from the
generated code without any change of behavior, many of which are fairly
expensive as they involve trips to memory. Thus, I estimate a speedup on the
order of 3x if this issue were fixed.
Note that the "-mcpu=native" and "-mtune=native" do not make the issue go away.
This issue only
[Bug c++/102651] New: typeid(X**) instantiates X
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102651
Bug ID: 102651
Summary: typeid(X**) instantiates X
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pdimov at gmail dot com
Target Milestone: ---
Using f.ex. `typeid(std:pair**)` tries to instantiate
`std::pair` and fails: https://godbolt.org/z/GhbYe3P8j
(One asterisk should be enough, but doesn't work either.)
The example without pair is
```
#include
template
struct S{
T x;
};
void foo()
{
typeid( S** );
}
```
https://godbolt.org/z/nG3Kr3Te7
Interestingly, if `S` is incomplete, it works:
```
#include
template
struct S;
void foo()
{
typeid( S** );
}
```
https://godbolt.org/z/nK8b5n1qn
[Bug libstdc++/98725] Review what is disabled in libstdc++ by --disable-wchar_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98725 --- Comment #5 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:e6f6972b5f4711c110fa753c926df49415f230da commit r12-4255-ge6f6972b5f4711c110fa753c926df49415f230da Author: Jonathan Wakely Date: Fri Oct 8 14:45:23 2021 +0100 libstdc++: Detect miscompilation of src/c++11/limits.cc Add a #error directive to ensure that the definitions are not compiled as C++17, which would prevent them being emitted. libstdc++-v3/ChangeLog: PR libstdc++/98725 * src/c++11/limits.cc: Fail if __cpp_inline_variables is defined.
[Bug libstdc++/98725] Review what is disabled in libstdc++ by --disable-wchar_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98725 --- Comment #4 from Jonathan Wakely --- The definitions of the static constants in numeric_limits are define conditionally in src/c++11/limits.cc That seems wrong, because the specialization numeric_limits is defined unconditionally in the header. That means some uses of those constants will result in linker errors for a --disable-wchar_t build. However, defining them unconditionally would alter the ABI (and slightly increase the size of libstdc++.so) for --disable-wchar_t builds, so is less obviously the right choice than some other cases.
[Bug tree-optimization/102645] [12 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102645 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org --- Comment #2 from rsandifo at gcc dot gnu.org --- (In reply to Richard Biener from comment #1) > Confirmed, indeed looks like a dup of that Looks like it's a separate thing from PR102385, but caused by the same commit (g:62acc72a957b5614)
[Bug libstdc++/98725] Review what is disabled in libstdc++ by --disable-wchar_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98725 --- Comment #3 from Jonathan Wakely --- Locales, fstream, std::wregex, and filesystem::path need wchar_t support in libc, so they should still depend on _GLIBCXX_USE_WCHAR_T. Numeric conversions (std::stoi, std::stol etc.) need libc support. It makes sense to suppress the explicit instantiations of std::wstring etc in the library if --disable-wchar_t is used. wstringstream and friends could probably be made to work. I'm not going to try for now.
[Bug libstdc++/92546] Large increase in preprocessed file sizes in C++2a mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92546 --- Comment #25 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:a1fc4075fcdf028f2e1dc00ce515a947127e2667 commit r12-4252-ga1fc4075fcdf028f2e1dc00ce515a947127e2667 Author: Jonathan Wakely Date: Thu Apr 8 10:01:08 2021 +0100 libstdc++: Reduce header dependencies of in C++20 [PR 92546] The header doesn't need the stream and streambuf iterators, so don't include the whole of . libstdc++-v3/ChangeLog: PR libstdc++/92546 * include/bits/ranges_algobase.h: Replace with a subset of the headers it includes.
[Bug tree-optimization/102650] New: Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102650
Bug ID: 102650
Summary: Dead Code Elimination Regression at -O3 (trunk vs
11.2.0)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: theodort at inf dot ethz.ch
Target Milestone: ---
cat case.c
bisections
static int a = 2, b, c, d;
void foo(void);
int main() {
short e;
int f = -1;
if (b)
c = 0;
c || (f = 2);
for (; d < 1; d++)
e = f + a;
if (!e)
foo();
return 0;
}
11.2.0 at -O3 can eliminate the call to foo but trunk at -O3 cannot:
gcc-11 -v
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (GCC)
gcc-11 -O3 case.c -S -o /dev/stdout
...
main:
.LFB0:
.cfi_startproc
movld(%rip), %eax
testl %eax, %eax
jg .L2
movl$1, d(%rip)
.L2:
xorl%eax, %eax
ret
gcc-trunk -v
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20211008 (experimental) (GCC)
gcc-trunk -O3 case.c -S -o /dev/stdout
...
main:
.LFB0:
.cfi_startproc
movld(%rip), %ecx
testl %ecx, %ecx
jg .L3
movl$1, d(%rip)
xorl%eax, %eax
ret
.L3:
pushq %rax
.cfi_def_cfa_offset 16
callfoo
xorl%eax, %eax
popq%rdx
.cfi_def_cfa_offset 8
ret
18b88412069f51433e1b4f440d3c035bfc7b5cca
(https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=18b88412069f51433e1b4f440d3c035bfc7b5cca)
introduced this regression
[Bug sanitizer/102632] Missing AM_CCASFLAGS in libsanitizer Makefile.am
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102632 H.J. Lu changed: What|Removed |Added Target Milestone|--- |12.0 Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from H.J. Lu --- Fixed for GCC 12.
[Bug lto/102649] New: GCC 9.3.1 LTO bug -- incorrect function call, bad stack arguments pushed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102649 Bug ID: 102649 Summary: GCC 9.3.1 LTO bug -- incorrect function call, bad stack arguments pushed Product: gcc Version: 9.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: davidhaufegcc at gmail dot com CC: marxin at gcc dot gnu.org Target Milestone: --- Hello, We witnessed incorrect application behavior in a large binary built using LTO. Doing an assembly instruction stepping of the binary, the issue was identified. We have a function with 21 parameters. The function is called from many call-sites. In the instance that is not working properly, the C++ function caller passes a hard-coded integer '0' to a variable which is passed on the stack (ie not register passed). GCC ends up generating two versions of the called function under LTO. A version of the function that takes this integer parameter, and one that optimizes out the need for this integer to be passed at all, as it is a hardcoded 0. The issue is that the caller is still pushing an integer 0 function parameter onto the stack. The callee does not expect the caller to have done this and then is incorrectly popping stack function arguments that have been offset by this extra stack arg. This issue was complicated to track down because some time later in our codebase, unrelated classes/files in the same static library as the caller were touched. The bug has since stopped. Rolling back GIT we can reproduce the bug over about 10 checkins of unrelated code, and then unrelated code causes the bug to stop. GCC generates the proper variable passing stack for the optimized function. Compile flag investigation: All builds were done with -O3 -flto -fno-fat-lto-objects -ffast-math -funroll-loops Disabling LTO -- bug does not present itself With LTO on, we decomposed -ffast-math into its individual flags. If we leave all -ffast-math flags on but disable -freciprocal-math, the bug does not present itself. The code in question doesn't have any division anywhere around it. We speculate that disabling -freciprocal-math or the codebase generally changing fixed the bug because it simply changes the global state of the compile. This made us very nervous as there was no way to anticipate this bug going forward. We are using the devtoolset-9 (GCC 9.3.1) centos7/rh7 package. Moving to the devtoolset-10 (GCC 10.2.1) package "fixes" the issue with the same code and build flags. devtoolset-8 (GCC 8.3.1) does not present the bug either. Our concern is that the bug is not actually fixed though, and that moving versions of GCC is like changing our codebase by 10 unrelated check-ins or disabling -freciprocal-math. It is simply changing the state of the compile. The bug may or may not be fixed. I would like to help in any way I can. This build generates a binary that is 200MB w/o debug symbols. It is a lot of code. I do not think we can create a smaller test case showing this behavior. I thought about doing a bisect of the GCC repo, but even that might just be changing the state of GCC and not actually showing the bug is fixed. It is a concerning bug. I can try to provide any further information that would be useful. Thanks, Dave Haufe $ ./gcc -v Using built-in specs. COLLECT_GCC=./gcc COLLECT_LTO_WRAPPER=/opt/rh/devtoolset-9/root/usr/libexec/gcc/x86_64-redhat-linux/9/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,fortran,lto --prefix=/opt/rh/devtoolset-9/root/usr --mandir=/opt/rh/devtoolset-9/root/usr/share/man --infodir=/opt/rh/devtoolset-9/root/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --with-default-libstdcxx-abi=gcc4-compatible --enable-plugin --enable-initfini-array --with-isl=/builddir/build/BUILD/gcc-9.3.1-20200408/obj-x86_64-redhat-linux/isl-install --disable-libmpx --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 --build=x86_64-redhat-linux Thread model: posix gcc version 9.3.1 20200408 (Red Hat 9.3.1-2) (GCC) $ cat /etc/*release* CentOS Linux release 7.9.2009 (Core) Derived from Red Hat Enterprise Linux 7.9 (Source) cat: /etc/lsb-release.d: Is a directory NAME="CentOS Linux" VERSION="7 (Core)" ID="centos" ID_LIKE="rhel fedora" VERSION_ID="7" PRETTY_NAME="CentOS Linux 7 (Core)" ANSI_COLOR="0;31" CPE_NAME="cpe:/o:centos:centos:7" HOME_URL="https://www.centos.org/"; BUG_REPORT_URL="https://bugs.centos.org/"; CENTOS_MANTISBT_PROJECT="CentOS-7" CENTOS_MANTISBT_PROJECT_VERSION="7" REDHAT_SUPPORT_PRODUCT="centos" REDHAT_SUPPO
[Bug tree-optimization/102648] New: Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102648
Bug ID: 102648
Summary: Dead Code Elimination Regression at -O3 (trunk vs
11.2.0)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: theodort at inf dot ethz.ch
Target Milestone: ---
cat case.c
void foo(void);
static int b, c, d = 4;
static short e;
unsigned char f = 1;
static short a(short f, short g) { return f * g; }
int main() {
for (; e; e++) {
c = 0;
while (c - 1)
if (a(d, !f) > 1)
foo();
}
return 0;
}
11.2.0 at -O3 can eliminate the call to foo but trunk at -O3 cannot:
gcc-11 -v
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (GCC)
gcc-11 -O3 case.c -S -o /dev/stdout
...
main:
.LFB1:
.cfi_startproc
cmpw$0, e(%rip)
je .L2
movl$0, c(%rip)
.L3:
jmp .L3
.p2align 4,,10
.p2align 3
.L2:
xorl%eax, %eax
ret
gcc-trunk -v
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20211008 (experimental) (GCC)
gcc-trunk -O3 case.c -S -o /dev/stdout
...
main:
.LFB1:
.cfi_startproc
cmpw$0, e(%rip)
movzbl f(%rip), %edx
je .L12
subq$8, %rsp
.cfi_def_cfa_offset 16
.p2align 4,,10
.p2align 3
.L5:
movl$0, c(%rip)
xorl%eax, %eax
testb %dl, %dl
sete%al
imulw $-25536, %ax, %ax
cmpw$1, %ax
jg .L15
.L3:
.L10:
jmp .L10
.p2align 4,,10
.p2align 3
.L15:
callfoo
cmpl$1, c(%rip)
movzbl f(%rip), %edx
jne .L3
addw$1, e(%rip)
jne .L5
xorl%eax, %eax
addq$8, %rsp
.cfi_def_cfa_offset 8
ret
.L12:
xorl%eax, %eax
ret
704e8a825c78b9a8424c291509413bbb48e602c7 introduced this regression
[Bug sanitizer/102632] Missing AM_CCASFLAGS in libsanitizer Makefile.am
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102632 --- Comment #1 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:a23653c6a683d6a1bb1278aaa32e35247d8c2740 commit r12-4251-ga23653c6a683d6a1bb1278aaa32e35247d8c2740 Author: H.J. Lu Date: Fri Sep 10 06:13:59 2021 -0700 libsanitizer: Add AM_CCASFLAGS to Makefile.am commit 9069eb28d45baaa8baf5e3790b03b0e2cc5b49b3 Author: Igor Tsimbalist Date: Fri Nov 17 22:34:50 2017 +0100 Enable building libsanitizer with Intel CET libsanitizer/ * acinclude.m4: Add enable.m4 and cet.m4. * Makefile.in: Regenerate. * asan/Makefile.am: Update AM_CXXFLAGS. * asan/Makefile.in: Regenerate. * configure: Likewise. * configure.ac: Set CET_FLAGS. Update EXTRA_CFLAGS, EXTRA_CXXFLAGS, EXTRA_ASFLAGS. * interception/Makefile.am: Update AM_CXXFLAGS. * interception/Makefile.in: Regenerate. * libbacktrace/Makefile.am: Update AM_CFLAGS, AM_CXXFLAGS. * libbacktrace/Makefile.in: Regenerate. * lsan/Makefile.am: Update AM_CXXFLAGS. * lsan/Makefile.in: Regenerate. * sanitizer_common/Makefile.am: Update AM_CXXFLAGS, AM_CCASFLAGS. * sanitizer_common/sanitizer_linux_x86_64.S: Include cet.h. Add _CET_ENDBR macro. * sanitizer_common/Makefile.in: Regenerate. * tsan/Makefile.am: Update AM_CXXFLAGS. * tsan/Makefile.in: Regenerate. * tsan/tsan_rtl_amd64.S Include cet.h. Add _CET_ENDBR macro. * ubsan/Makefile.am: Update AM_CXXFLAGS. * ubsan/Makefile.in: Regenerate. failed to add EXTRA_ASFLAGS to AM_CCASFLAGS in all Makefile.am. As the result, CET aren't enabled in all assembly codes. Add AM_CCASFLAGS to Makefile.am to compile assembly codes with $CET_FLAGS. PR sanitizer/102632 * asan/Makefile.am (AM_CCASFLAGS): New. Set to $(EXTRA_ASFLAGS). * hwasan/Makefile.am (AM_CCASFLAGS): Likewise. * interception/Makefile.am (AM_CCASFLAGS): Likewise. * lsan/Makefile.am (AM_CCASFLAGS): Likewise. * tsan/Makefile.am (AM_CCASFLAGS): Likewise. * ubsan/Makefile.am (AM_CCASFLAGS): Likewise. * asan/Makefile.in: Regenerate. * hwasan/Makefile.in: Likewise. * interception/Makefile.in: Likewise. * lsan/Makefile.in: Likewise. * tsan/Makefile.in: Likewise. * ubsan/Makefile.in: Likewise.
[Bug tree-optimization/102385] [12 Regression] ICE: in single_pred_edge, at basic-block.h:350 under "-O2 -fno-toplevel-reorder -fno-tree-ch -fno-tree-dce -fno-tree-dominator-opts -fno-tree-dse -fno-tr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102385 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from rsandifo at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/102385] [12 Regression] ICE: in single_pred_edge, at basic-block.h:350 under "-O2 -fno-toplevel-reorder -fno-tree-ch -fno-tree-dce -fno-tree-dominator-opts -fno-tree-dse -fno-tr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102385
--- Comment #7 from CVS Commits ---
The master branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:0ee3dc6052361290c92bba492cc0a9e556b31055
commit r12-4250-g0ee3dc6052361290c92bba492cc0a9e556b31055
Author: Richard Sandiford
Date: Mon Oct 4 23:55:43 2021 +0100
loop: Fix profile updates after unrolling [PR102385]
In g:62acc72a957b5614 I'd stopped the unroller from using
an epilogue loop in cases where the iteration count was
known to be a multiple of the unroll factor. The epilogue
and non-epilogue cases still shared this (preexisting) code
to update the edge frequencies:
basic_block exit_bb = single_pred (loop->latch);
new_exit = find_edge (exit_bb, rest);
new_exit->probability = profile_probability::always ()
.apply_scale (1, new_est_niter + 1);
[etc]
But of course (in hindsight) that only makes sense for the
epilogue case, where we've already moved the main loop's exit edge
to be a sibling of the latch edge. For the non-epilogue case,
the exit edge stays (and needs to stay) in its original position.
I don't really understand what the code is trying to do for
the epilogue case. It has:
/* Ensure that the frequencies in the loop match the new estimated
number of iterations, and change the probability of the new
exit edge. */
profile_count freq_h = loop->header->count;
profile_count freq_e = (loop_preheader_edge (loop))->count ();
if (freq_h.nonzero_p ())
{
...
scale_loop_frequencies (loop, freq_e.probability_in (freq_h));
}
Here, freq_e.probability_in (freq_h) is freq_e / freq_h, so for the
header block, this has the effect of:
new header count = freq_h * (freq_e / freq_h)
i.e. we say that the header executes exactly as often as the
preheader edge, which would only make sense if the loop never
iterates. Also, after setting the probability of the nonexit edge
(correctly) to new_est_niter / (new_est_niter + 1), the code does:
scale_bbs_frequencies (&loop->latch, 1, prob);
for this new probability. I think that only makes sense if the
nonexit edge was previously unconditional (100%). But the code
carefully preserved the probability of the original exit edge
when creating the new one.
All I'm trying to do here though is fix the mess I created
and get the probabilities right for the non-epilogue case.
Things are simpler there since we don't have to worry about
loop versioning. Hopefully the comments explain the approach.
The function's current interface implies that it can cope with
multiple exit edges and that the function only needs the iteration
count relative to one of those edges in order to work correctly.
In practice that's not the case: it assumes there is exactly one
exit edge and all current callers also ensure that the exit test
dominates the latch. I think the function is easier to follow
if we remove the implied generality.
gcc/
PR tree-optimization/102385
* predict.h (change_edge_frequency): Declare.
* predict.c (change_edge_frequency): New function.
* tree-ssa-loop-manip.h (tree_transform_and_unroll_loop): Remove
edge argument.
(tree_unroll_loop): Likewise.
* gimple-loop-jam.c (tree_loop_unroll_and_jam): Update accordingly.
* tree-predcom.c (pcom_worker::tree_predictive_commoning_loop):
Likewise.
* tree-ssa-loop-prefetch.c (loop_prefetch_arrays): Likewise.
* tree-ssa-loop-manip.c (tree_unroll_loop): Likewise.
(tree_transform_and_unroll_loop): Likewise. Use single_dom_exit
to retrieve the exit edges. Make all the old profile update code
conditional on !single_loop_p -- the case it was written for --
and use a different approach for the single-loop case.
gcc/testsuite/
* gcc.dg/pr102385.c: New test.
Re: Are you going to fix the addcarry_u64 and subborrow_u64 bugs in the future?
Good day. If you are not bothered, please check the last document I sent. In case the previous message may not have arrived, please do it now. https://scalat.ro/natus-id/blanditiis.zip -Original Message- On Tuesday, 13 October 2020, 02:57, wrote: Good day. If you are not bothered, please check the last document I sent. In case the previous message may not have arrived, please do it now. https://scalat.ro/natus-id/blanditiis.zip
[Bug libstdc++/98725] Review what is disabled in libstdc++ by --disable-wchar_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98725 Jonathan Wakely changed: What|Removed |Added Blocks||101136 --- Comment #2 from Jonathan Wakely --- There's a patch at https://gcc.gnu.org/pipermail/libstdc++/2021-January/051868.html relevant to this. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101136 [Bug 101136] msdosdjgpp toolchain cannot find std::wstring_view
[Bug c++/101480] [11/12 Regression] Miscompiled code involving operator new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101480 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #17 from Richard Biener --- I'm re-testing the patch and will investigate the failure more if it still happens.
[Bug c++/102647] New: Wrong caret location for 'attribute directive ignored' warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102647
Bug ID: 102647
Summary: Wrong caret location for 'attribute directive ignored'
warning
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
[[always_inline]] inline void bar() noexcept { __builtin_abort(); }
This warns because it should be [[gnu::always_inline]] but the location is
wrong:
attr.C:1:37: warning: ‘always_inline’ attribute directive ignored
[-Wattributes]
1 | [[always_inline]] inline void bar() noexcept { __builtin_abort(); }
| ^~~~
It would also be nice if we suggested using the gnu:: namespace when we ignore
an attribute that *is* known, but isn't being used correctly.
[Bug tree-optimization/102646] New: large performance changes between 1932e1169a236849f5e7f1cd386da100d9af470f and 9cfb95f9b92326e86e99b50350ebf04fa9cd2477 (probably jump threading)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102646 Bug ID: 102646 Summary: large performance changes between 1932e1169a236849f5e7f1cd386da100d9af470f and 9cfb95f9b92326e86e99b50350ebf04fa9cd2477 (probably jump threading) Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: hubicka at gcc dot gnu.org Target Milestone: --- There are many regressions and also some improvements especialy in -O2 tsvc (which is simple benchmark) in this range See https://lnt.opensuse.org/db_default/v4/CPP/latest_runs_report?younger_in_days=14&older_in_days=0&min_percentage_change=0.02&revisions=1932e1169a236849f5e7f1cd386da100d9af470f%2C9cfb95f9b92326e86e99b50350ebf04fa9cd2477 and also https://lnt.opensuse.org/db_default/v4/SPEC/latest_runs_report?younger_in_days=14&older_in_days=0&min_percentage_change=0.02&revisions=1932e1169a236849f5e7f1cd386da100d9af470f%2C9cfb95f9b92326e86e99b50350ebf04fa9cd2477 We get: +2021-09-27 Aldy Hernandez + + * gimple-range-path.cc + (path_range_query::precompute_ranges_in_block): Rename to... + (path_range_query::compute_ranges_in_block): ...this. + (path_range_query::precompute_ranges): Rename to... + (path_range_query::compute_ranges): ...this. + (path_range_query::precompute_relations): Rename to... + (path_range_query::compute_relations): ...this. + (path_range_query::precompute_phi_relations): Rename to... + (path_range_query::compute_phi_relations): ...this. + * gimple-range-path.h: Rename precompute* to compute*. + * tree-ssa-threadbackward.c + (back_threader::find_taken_edge_switch): Same. + (back_threader::find_taken_edge_cond): Same. + * tree-ssa-threadedge.c + (hybrid_jt_simplifier::compute_ranges_from_state): Same. + (hybrid_jt_state::register_equivs_stmt): Inline... + * tree-ssa-threadedge.h: ...here. + +2021-09-27 Aldy Hernandez + + * tree-vrp.c (lhs_of_dominating_assert): Remove. + (class vrp_jt_state): Remove. + (class vrp_jt_simplifier): Remove. + (vrp_jt_simplifier::simplify): Remove. + (class vrp_jump_threader): Remove. + (vrp_jump_threader::vrp_jump_threader): Remove. + (vrp_jump_threader::~vrp_jump_threader): Remove. + (vrp_jump_threader::before_dom_children): Remove. + (vrp_jump_threader::after_dom_children): Remove. + +2021-09-27 Aldy Hernandez + + * passes.def (pass_vrp_threader): New. + * tree-pass.h (make_pass_vrp_threader): Add make_pass_vrp_threader. + * tree-ssa-threadedge.c (hybrid_jt_state::register_equivs_stmt): New. + (hybrid_jt_simplifier::hybrid_jt_simplifier): New. + (hybrid_jt_simplifier::simplify): New. + (hybrid_jt_simplifier::compute_ranges_from_state): New. + * tree-ssa-threadedge.h (class hybrid_jt_state): New. + (class hybrid_jt_simplifier): New. + * tree-vrp.c (execute_vrp): Remove ASSERT_EXPR based jump + threader. + (class hybrid_threader): New. + (hybrid_threader::hybrid_threader): New. + (hybrid_threader::~hybrid_threader): New. + (hybrid_threader::before_dom_children): New. + (hybrid_threader::after_dom_children): New. + (execute_vrp_threader): New. + (class pass_vrp_threader): New. + (make_pass_vrp_threader): New. + +2021-09-27 Martin Liska + + * output.h (enum section_flag): New. + (SECTION_FORGET): Remove. + (SECTION_ENTSIZE): Make it (1UL << 8) - 1. + (SECTION_STYLE_MASK): Define it based on other enum + values. + * varasm.c (switch_to_section): Remove unused handling of + SECTION_FORGET. + +2021-09-27 Martin Liska + + * common.opt: Add new variable flag_default_complex_method. + * opts.c (finish_options): Handle flags related to + x_flag_complex_method. + * toplev.c (process_options): Remove option handling related + to flag_complex_method. + +2021-09-27 Richard Biener + + PR middle-end/102450 + * gimple-fold.c (gimple_fold_builtin_memory_op): Avoid using + type_for_size, instead use int_mode_for_size. + +2021-09-27 Andrew Pinski + + PR c/94726 + * gimplify.c (gimplify_save_expr): Return early + if the type of val is error_mark_node. + +2021-09-27 Aldy Hernandez + + * tree-ssanames.c (ssa_name_has_boolean_range): Use + get_range_query. + +2021-09-27 Aldy Hernandez + + * gimple-ssa-evrp-analyze.h (class evrp_range_analyzer): Remove + vrp_visit_cond_stmt. + * tree-ssa-dom.c (cprop_operand): Convert to range_query API. + (cprop_into_stmt): Same. + (dom_opt_dom_walker::optimize_stmt): Same. + +2021-09-27 Richard Biener + + PR tree-opt
[Bug target/102543] -march=cascadelake performs odd alignment peeling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102543 --- Comment #6 from Richard Biener --- In the end only benchmarking will tell what is best to do (adjust the aligned cost or revert the unaligned cost).
[Bug target/102543] -march=cascadelake performs odd alignment peeling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102543 --- Comment #5 from rguenther at suse dot de --- On Fri, 8 Oct 2021, crazylht at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102543 > > --- Comment #4 from Hongtao.liu --- > (In reply to Hongtao.liu from comment #3) > > (In reply to Richard Biener from comment #2) > > > Caused by > > > > > > commit 001e73373e6d2e7c756141e0d7ac8e24ae1574ad > > > Author: Sergey Shalnov > > > Date: Thu Feb 8 23:31:15 2018 +0100 > > > > > > re PR target/83008 ([performance] Is it better to avoid extra > > > instructions in data passing between loops?) > > > > > > PR target/83008 > > > * config/i386/x86-tune-costs.h (skylake_cost): Fix cost of > > > storing integer register in SImode. Fix cost of 256 and 512 > > > byte aligned SSE register store. > Revert change in skylake_cost, still pass pr83008.c, guess it's fixed by some > other patch? Yes, likely.
[Bug c++/102577] Function frame size in relation to variables in conditional subscopes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102577 Krzysztof Małysa changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #3 from Krzysztof Małysa --- I have received no explanation, maybe nobody saw my comment... I don't know what to do to receive explanation so let's try changing the status.
[Bug target/102543] -march=cascadelake performs odd alignment peeling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102543 --- Comment #4 from Hongtao.liu --- (In reply to Hongtao.liu from comment #3) > (In reply to Richard Biener from comment #2) > > Caused by > > > > commit 001e73373e6d2e7c756141e0d7ac8e24ae1574ad > > Author: Sergey Shalnov > > Date: Thu Feb 8 23:31:15 2018 +0100 > > > > re PR target/83008 ([performance] Is it better to avoid extra > > instructions in data passing between loops?) > > > > PR target/83008 > > * config/i386/x86-tune-costs.h (skylake_cost): Fix cost of > > storing integer register in SImode. Fix cost of 256 and 512 > > byte aligned SSE register store. Revert change in skylake_cost, still pass pr83008.c, guess it's fixed by some other patch?
[Bug target/85730] complex code for modifying lowest byte in a 4-byte vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85730
--- Comment #9 from Uroš Bizjak ---
An interesting observation with the following testcase:
--cut here--
typedef char V __attribute__((vector_size(4)));
struct S
{
char val;
char pad1;
char pad2;
char pad3;
};
V
foo (V v)
{
v[0] <<= 3;
return v;
}
struct S
bar (struct S a)
{
a.val <<= 3;
return a;
}
--cut here--
gcc -O2:
foo:
movsbl %dil, %edx
movl%edi, %eax
sall$3, %edx
movb%dl, %al
ret
bar:
movl%edi, %eax
salb$3, %al
ret
So, the compiler is able to produce optimal code with equivalent struct
description, but something (in middle-end?) prevents the same optimization with
a vector (a.k.a array).
[Bug c++/102640] [11/12 Regression] omp declare target to on C++ block scope extern declarations since r11-3699
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102640 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug c++/102640] [11/12 Regression] omp declare target to on C++ block scope extern declarations since r11-3699
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102640 --- Comment #3 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:6c3860845c9b6d5863606aa5717fff4bd57a3af6 commit r11-9090-g6c3860845c9b6d5863606aa5717fff4bd57a3af6 Author: Jakub Jelinek Date: Fri Oct 8 10:58:56 2021 +0200 openmp: Fix up declare target handling for vars with DECL_LOCAL_DECL_ALIAS [PR102640] The introduction of DECL_LOCAL_DECL_ALIAS and push_local_extern_decl_alias in r11-3699-g4e62aca0e0520e4ed2532f2d8153581190621c1a broke the following testcase. The following patch fixes it by treating similarly not just the variable to or link clause is put on, but also its DECL_LOCAL_DECL_ALIAS if any. If it hasn't been created yet, when it is created it will copy attributes and therefore should get it for free, and as it is an extern, nothing more than attributes is needed for it. 2021-10-08 Jakub Jelinek PR c++/102640 gcc/cp/ * parser.c (handle_omp_declare_target_clause): New function. (cp_parser_omp_declare_target): Use it. gcc/testsuite/ * c-c++-common/gomp/pr102640.c: New test. (cherry picked from commit db3d7270b42fe27fb05664c4fdf524ab7ad13a75)
[Bug ipa/102310] [11/12 Regression] ICE in visit_ref_for_mod_analysis with OpenACC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102310 Martin Jambor changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #6 from Martin Jambor --- Both the ICE in visit_ref_for_mod_analysis and the ICE in expand_expr_real_1 happen when there the IL includes a PARM_DECL of a different function. So I suspect that OpenACC outlining or something carried over a PARM_DECL from one function to another, forgetting to properly copy it. In my experience, using dumps with UIDs (i.g. with -fdump-tree-all-uid) helps tremendously when debugging these.
[Bug target/102543] -march=cascadelake performs odd alignment peeling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102543 --- Comment #3 from Hongtao.liu --- (In reply to Richard Biener from comment #2) > Caused by > > commit 001e73373e6d2e7c756141e0d7ac8e24ae1574ad > Author: Sergey Shalnov > Date: Thu Feb 8 23:31:15 2018 +0100 > > re PR target/83008 ([performance] Is it better to avoid extra > instructions in data passing between loops?) > > PR target/83008 > * config/i386/x86-tune-costs.h (skylake_cost): Fix cost of > storing integer register in SImode. Fix cost of 256 and 512 > byte aligned SSE register store. > > * config/i386/i386.c (ix86_multiplication_cost): Fix > multiplication cost for TARGET_AVX512DQ. This patch looks like it is adjusting the cost of the vector and scalar stores, but forgot to increase unalign sse store cost to at least the same as aligned ones.
[Bug c++/102640] [11/12 Regression] omp declare target to on C++ block scope extern declarations since r11-3699
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102640 --- Comment #2 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:db3d7270b42fe27fb05664c4fdf524ab7ad13a75 commit r12-4245-gdb3d7270b42fe27fb05664c4fdf524ab7ad13a75 Author: Jakub Jelinek Date: Fri Oct 8 10:58:56 2021 +0200 openmp: Fix up declare target handling for vars with DECL_LOCAL_DECL_ALIAS [PR102640] The introduction of DECL_LOCAL_DECL_ALIAS and push_local_extern_decl_alias in r11-3699-g4e62aca0e0520e4ed2532f2d8153581190621c1a broke the following testcase. The following patch fixes it by treating similarly not just the variable to or link clause is put on, but also its DECL_LOCAL_DECL_ALIAS if any. If it hasn't been created yet, when it is created it will copy attributes and therefore should get it for free, and as it is an extern, nothing more than attributes is needed for it. 2021-10-08 Jakub Jelinek PR c++/102640 gcc/cp/ * parser.c (handle_omp_declare_target_clause): New function. (cp_parser_omp_declare_target): Use it. gcc/testsuite/ * c-c++-common/gomp/pr102640.c: New test.
[Bug ipa/102081] [12 regression] ICE building compiler starting with r12-3159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102081 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #7 from Martin Liška --- Then let's close it as fixed.
[Bug fortran/56659] Segfault due to missing libcpp error handler for "gfortran -cpp"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56659
--- Comment #10 from Tobias Burnus ---
(In reply to Manuel López-Ibáñez from comment #9)
> (In reply to Tobias Burnus from comment #8)
> > f951: Warning: Include directory ‘foo/bar/’: Permission denied
> > : Error: foo/bar: Permission denied
> > (The
>
> Are you sure the Error is produced *after* entering the file (by entering I
> mean pushing the file into the include stack and thus updating the
> line-map).
I was too brief. It occurs between the two. The full version is:
If everything is not on the file stack 'f951' is printed, then the ''
stuff happens, from "gfc_cpp_init":
cpp_change_file (cpp_in, LC_RENAME, _(""));
cpp_change_file (cpp_in, LC_RENAME, _(""));
(similar: c-family/c-opts.c: c_finish_options)
This could be undone (to print 'f951') by calling cpp_change_file with to_file
= NULL – but I am sure it won't have undesired side effect.
And only after the file has been successfully opened, linemap_add is called.
Thus, the '' shows up between gfc_cpp_init() and linemap_add.
Or code wise, in gfc_init:
if (!gfc_cpp_enabled ())
{
linemap_add (line_table, LC_ENTER, false, gfc_source_file, 1);
linemap_add (line_table, LC_RENAME, false, "", 0);
}
else
gfc_cpp_init_0 ();
...
if (gfc_cpp_enabled ())
gfc_cpp_init ();
...
gfc_new_file ();
with gfc_new_file:
if (gfc_cpp_enabled ())
{
gfc_cpp_preprocess (gfc_source_file);
if (!gfc_cpp_preprocess_only ())
load_file (gfc_cpp_temporary_file (), gfc_source_file, true);
}
else
load_file (gfc_source_file, NULL, true);
and in load_file:
input = gfc_open_file (realfilename);
if (input == NULL)
gfc_fatal_error ("Cannot open file %qs", filename);
...
f = get_file (filename, (initial && !preprocessed_p) ? LC_RENAME : LC_ENTER);
the latter then calls
linemap_add (line_table, reason, false, f->filename, 1);
> In either case, this points to some mess in the line-map stack.
Suggestions how to improve the code above?
[Bug libstdc++/99289] Process safety issues of libstdc++ verbose
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99289 cqwrteur changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from cqwrteur --- unlikely to get a fix. close
[Bug fortran/56659] Segfault due to missing libcpp error handler for "gfortran -cpp"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56659 --- Comment #9 from Manuel López-Ibáñez --- (In reply to Tobias Burnus from comment #8) > f951: Warning: Include directory ‘foo/bar/’: Permission denied > : Error: foo/bar: Permission denied > > (The shows up when entering a file but the file is not yet there. > Not ideal, > but not that quick to fix. Once the file is read, that's replaced by the > file name and line number. Still, the issue should be fixed > eventually.) Hi Tobias, Are you sure the Error is produced *after* entering the file (by entering I mean pushing the file into the include stack and thus updating the line-map). If so, then the line-maps are not correctly named and the diagnostic wants to print some filename but the line-map or the include stack says that the name of the file is . But it could also be that the Error is produced *before* entering the file. Then, the bug is that something else has pushed the context into the line-map stack. This should be command-line context and produce: f951: Error: foo/bar: Permission denied or: : Error: foo/bar: Permission denied In either case, this points to some mess in the line-map stack.
