[Bug ipa/105600] [9/10/11/12/13 Regression] ICE with LTO when building Mumble since r12-5696-g53caa4723d8de73f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105600 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.5
[Bug c++/105652] [12/13 Regression] ICE: in is_base_type, at dwarf2out.cc:13400 since r12-1937-gc28e1d288ab727de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105652 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.2 Priority|P3 |P2
[Bug tree-optimization/103116] SLP vectoriser fails to peel for gaps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103116 --- Comment #9 from CVS Commits --- The releases/gcc-12 branch has been updated by Richard Biener : https://gcc.gnu.org/g:fdf50499a40399a48ac5e5d521ef93ed302be157 commit r12-8405-gfdf50499a40399a48ac5e5d521ef93ed302be157 Author: Richard Biener Date: Wed May 4 10:43:07 2022 +0200 tree-optimization/103116 - SLP permutes and peeling for gaps The testcase shows that we can end up with a contiguous access across loop iterations but by means of permutations the elements accessed might only cover parts of a vector. In this case we end up with GROUP_GAP == 0 but still need to avoid accessing excess elements in the last loop iterations. Peeling for gaps is designed to cover this but a single scalar iteration might not cover all of the excess elements. The following ensures peeling for gaps is done in this situation and when that isn't sufficient because we need to peel more than one iteration (gcc.dg/vect/pr103116-2.c), fail the SLP vectorization. 2022-05-04 Richard Biener PR tree-optimization/103116 * tree-vect-stmts.cc (get_group_load_store_type): Handle the case we need peeling for gaps even though GROUP_GAP is zero. * gcc.dg/vect/pr103116-1.c: New testcase. * gcc.dg/vect/pr103116-2.c: Likewise. (cherry picked from commit 52b7b86f8c72eb19e637f1e72ffd10f39b8cb829)
[Bug libgcc/105669] New: DFP to HF (_Float16) conversions use incorrect rounding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105669 Bug ID: 105669 Summary: DFP to HF (_Float16) conversions use incorrect rounding Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- Support for conversions between DFP and _Float16 have been introduced with r13-687-g308a0af4f91324. For simplicity it uses intermediate conversions with SFmode, leading to double rounding which probably produces incorrectly rounded results. See also PR97635
[Bug c++/105667] [C++20] lambas in template argument sometimes causes an ICE (seg fault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105667 Martin Liška changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org --- Comment #5 from Martin Liška --- Likely started with r9-4045-g0c1e0d63fe0ceabb, it was rejected before the revision.
[Bug tree-optimization/105668] [13 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281 with -O -ftracer -fno-tree-fre since r13-458-gd75d4293dcc029a7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105668 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org, ||sayle at gcc dot gnu.org Summary|[13 Regression] ICE: in |[13 Regression] ICE: in |gimple_expand_vec_cond_expr |gimple_expand_vec_cond_expr |, at gimple-isel.cc:281 |, at gimple-isel.cc:281 |with -O -ftracer|with -O -ftracer |-fno-tree-fre |-fno-tree-fre since ||r13-458-gd75d4293dcc029a7 Keywords|needs-bisection | --- Comment #2 from Martin Liška --- Started with r13-458-gd75d4293dcc029a7.
[Bug tree-optimization/105329] [12/13 Regression] Bogus restrict warning when assigning 1-char string literal to std::string since r12-3347-g8af8abfbbace49e6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105329 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/102844] [9/10/11/12/13 Regression] DOM jump threading not copying block that became non-empty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102844 --- Comment #25 from Richard Biener --- I'm not sure about the state of this bug - the issue reproduces on the GCC 10 branch with checking enabled and -O[2s] -fdisable-tree-fre4 -fno-strict-overflow It might be that using the backward threader from DOM (are we now doing that?) makes this truly fixed but I'm not sure the backward threader is resilent to the issue analyzed in comments #13 to #15. Eventually the NOCOPY special-casing could be removed as premature optimization (CFG cleanup will remove any copied forwarders), but then IIRC we have a hard limit on the number of blocks the threader handles.
[Bug target/105513] [9/10/11/12/13 Regression] Unnecessary SSE spill since r9-5748-g1d4b4f4979171ef0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105513
--- Comment #6 from Hongtao.liu ---
Also notice a intersting case impacted by a separate m alternatvie.
typedef long v2di __attribute__((vector_size(16)));
v2di
foo (v2di a)
{
a[1] = 1113;
return a;
}
with -O2 gcc generates
foo(long __vector(2)):
movhps .LC0(%rip), %xmm0
ret
.LC0:
.quad 1113
llvm has
foo(long __vector(2)):# @foo(long __vector(2))
movl$1113, %eax # imm = 0x459
movq%rax, %xmm1
punpcklqdq %xmm1, %xmm0# xmm0 = xmm0[0],xmm1[0]
retq
Microbenchmark show both both sequences are almost as fast, really don't know
which is better.
[Bug target/105513] [9/10/11/12/13 Regression] Unnecessary SSE spill since r9-5748-g1d4b4f4979171ef0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105513 --- Comment #7 from Alexander Monakov --- The second sequence is 3 uops vs 1/2 (issued/executed) uops in first, and on Haswell and Skylake it ties up port 5 for two cycles. Unclear if you're microbenchmarking latency or throughput, but in any case on Haswell and Skylake you should see a close to 2x difference.
[Bug tree-optimization/101668] BB vectorizer doesn't handle lowpart of existing vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101668 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Richard Biener --- Some pending enhancements would allow us to use VEC_PERM_EXPR with different input modes from output mode and thus make implementation of this easier. vectorizable_slp_permutation doesn't yet support that though. For the special case of a contiguous permutation we can also vectorize it as BIT_FIELD_REF of course.
[Bug target/105513] [9/10/11/12/13 Regression] Unnecessary SSE spill since r9-5748-g1d4b4f4979171ef0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105513
--- Comment #8 from Hongtao.liu ---
(In reply to Alexander Monakov from comment #7)
> The second sequence is 3 uops vs 1/2 (issued/executed) uops in first, and on
> Haswell and Skylake it ties up port 5 for two cycles.
>
> Unclear if you're microbenchmarking latency or throughput, but in any case
> on Haswell and Skylake you should see a close to 2x difference.
I'm counting clocksticks, and thought a load may take more latency.
#include
#include
#include
#define LOOP 10
typedef long v2di __attribute__((vector_size(16)));
typedef int v4si __attribute__((vector_size(16)));
v2di
__attribute__ ((noipa))
foo (v2di a)
{
a[1] = 13;
return a;
}
void
__attribute__ ((noipa))
foo1 (v2di a)
{
}
int
main ()
{
int i;
unsigned long long start, end;
unsigned long long diff;
unsigned int aux;
start = __rdtscp (&aux);
v2di b = __extension__ (v2di){111, 222};
for (i = 0; i < LOOP; i++)
{
v2di a = foo (b);
foo1 (a);
}
end = __rdtscp (&aux);
diff = end - start;
printf ("alterna: %lld\n", diff);
return 0;
}
[Bug tree-optimization/101668] BB vectorizer doesn't handle lowpart of existing vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101668 --- Comment #4 from Hongtao.liu --- Guess we need to extend backend hook to handle different input and output modes.
[Bug ipa/105600] [9/10/11/12/13 Regression] ICE with LTO when building Mumble
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105600 Alex Coplan changed: What|Removed |Added Summary|[9/10/11/12/13 Regression] |[9/10/11/12/13 Regression] |ICE with LTO when building |ICE with LTO when building |Mumble since|Mumble |r12-5696-g53caa4723d8de73f | --- Comment #13 from Alex Coplan --- FWIW, we started ICEing somewhere between r9-856-g7ce4ce10cd0a6f332dd473bd4726f1a1adefda0e and r9-870-ge062dc808950801a089ee6acd969393da2f39406, the build was broken between these revisions.
[Bug tree-optimization/101668] BB vectorizer doesn't handle lowpart of existing vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101668
--- Comment #5 from Richard Biener ---
(In reply to Hongtao.liu from comment #4)
> Guess we need to extend backend hook to handle different input and output
> modes.
Yes, alternatively as said, some special cases could be directly handled.
For example v16si -> v8si could be handled by VEC_PERM
without any extra magic (but IIRC we don't have a way to query target support
for specific BIT_FIELD_REFs which we'd use for getting at the lowpart
or highpart and if not available those would fall back to memory).
And contiguous permutes could be directly emitted as BIT_FIELD_REFs
(in some cases).
I have a half-way patch that does the preparatory work but leaves
vectorizable_slp_permutation unchanged so we immediately fail there
due to
FOR_EACH_VEC_ELT (SLP_TREE_CHILDREN (node), i, child)
{
if (!vect_maybe_update_slp_op_vectype (child, vectype)
|| !types_compatible_p (SLP_TREE_VECTYPE (child), vectype))
{
if (dump_enabled_p ())
dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
"Unsupported lane permutation\n");
return false;
the comment above that says
/* ??? We currently only support all same vector input and output types
while the SLP IL should really do a concat + select and thus accept
arbitrary mismatches. */
so it was designed to handle more, it wasn't just necessary to implement it ...
[Bug target/105670] New: [x86] suboptimal code for branch over two bools
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105670
Bug ID: 105670
Summary: [x86] suboptimal code for branch over two bools
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: fent at in dot tum.de
Target Milestone: ---
void test(bool a, bool b, int* t) {
if (a & b)
*t = 42;
}
With -O1, -O2, -O3, and -Os this produces:
test(bool, bool, int*):
testdil, dil
je .L1
testsil, sil
je .L1
mov DWORD PTR [rdx], 42
.L1:
ret
The following would be 5B shorter and also faster, since it minimizes branch
misses:
test(bool, bool, int*):
testsil, dil
je .L1
mov DWORD PTR [rdx], 42
.L1:
ret
Note that this is (somewhat) ABI dependent, but works on x86-64 System V,
since:
> bit 0 contains the truth value and bits 1 to 7 shall be zero
[Bug target/61810] init-regs.c papers over issues elsewhere
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61810
Richard Biener changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #7 from Richard Biener ---
(In reply to Andrew Pinski from comment #6)
> https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577192.html
On current trunk x86_64 that gets
FAIL: gcc.target/i386/extract-insert-combining.c scan-assembler-times
(?:vmovd|movd)[ t]+[^{\\n]*%xmm[0-9] 3
FAIL: gcc.target/i386/extract-insert-combining.c scan-assembler-times
(?:vpinsrd|pinsrd)[ t]+[^{\\n]*%xmm[0-9] 1
FAIL: gcc.target/i386/pr104441-1b.c execution test
FAIL: gcc.target/i386/pr98335.c scan-assembler movzbl
FAIL: gcc.target/i386/pr98335.c scan-assembler-not movb
FAIL: gnat.dg/sso8.adb execution test
FAIL: libgomp.c/loop-19.c execution test
FAILs can be reproduced in an unpatched tree with specifying
-fdisable-rtl-init-regs
Assembly difference for gcc.target/i386/pr104441-1b.c is (besides RA):
- vpxor %xmm1, %xmm1, %xmm1
+ vpinsrd $1, (%rax,%r10), %xmm5, %xmm1
+ vpinsrd $1, (%rdx,%r9), %xmm4, %xmm3
vmovd (%rax), %xmm0
- vpxor %xmm2, %xmm2, %xmm2
addl$4, %ecx
- vpinsrd $1, (%rax,%r10), %xmm1, %xmm1
- vpinsrd $1, (%rdx,%r9), %xmm2, %xmm2
adding initialization in compute4x_m_sad_avx2_intrin of reg 109 at in block 4
for insn 33.
adding initialization in compute4x_m_sad_avx2_intrin of reg 99 at in block 4
for insn 48.
where we have for example
-(insn 97 31 98 4 (clobber (reg/v:V2DI 109 [ src23 ]))
"/home/rguenther/obj-gcc4-g/gcc/include/smmintrin.h":408:20 -1
- (nil))
-(insn 98 97 33 4 (set (reg/v:V2DI 109 [ src23 ])
-(const_vector:V2DI [
-(const_int 0 [0]) repeated x2
-])) "/home/rguenther/obj-gcc4-g/gcc/include/smmintrin.h":408:20 -1
- (nil))
-(insn 33 98 36 4 (set (reg:V4SI 138 [ src23 ])
+(insn 33 31 36 4 (set (reg:V4SI 138 [ src23 ])
(vec_merge:V4SI (vec_duplicate:V4SI (reg:SI 137 [ MEM[(int32_t
*)src_62 + _41 * 1] ]))
(subreg:V4SI (reg/v:V2DI 109 [ src23 ]) 0)
(const_int 2 [0x2])))
"/home/rguenther/obj-gcc4-g/gcc/include/smmintrin.h":408:20 6925
{sse4_1_pinsrd}
where this produces { undef, MEM, undef, undef } without init-regs
But it looks like the testcase is broken:
__attribute__((always_inline, target("avx2")))
static __m256i
load8bit_4x4_avx2(const uint8_t *const src, const uint32_t stride)
{
__m128i src01, src23;
src01 = _mm_cvtsi32_si128(*(int32_t*)(src + 0 * stride));
src23 = _mm_insert_epi32(src23, *(int32_t *)(src + 3 * stride), 1);
return _mm256_setr_m128i(src01, src23);
}
it seems to expect that src23 is zero before inserting the data?
[Bug c++/105671] New: Unexplained "undefined reference" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105671 Bug ID: 105671 Summary: Unexplained "undefined reference" error Product: gcc Version: 12.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: christian.morales.vega at gmail dot com Target Milestone: --- Created attachment 53005 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53005&action=edit Full verbose build log I have found a strange issue in my project build that reproduces is Ubuntu 22.04 (gcc 11.2) and Fedora 36 (gcc 12.1.1). This is the most I have been able to reduce it: $ tar xf boost_1_79_0.tar.bz2 $ cd boost_1_79_0/ $ ./bootstrap.sh $ ./b2 --with-program_options link=static --user-config=$PWD/../user-config.jam $ cd .. $ g++ -o /dev/null test.cpp -Iboost_1_79_0 boost_1_79_0/stage/lib/libboost_program_options.a -Os -flto /usr/bin/ld: /tmp/cccbpRrv.ltrans0.ltrans.o: in function `boost::program_options::options_description::get_option_column_width() const': :(.text+0x28cd): undefined reference to `std::__cxx11::basic_stringbuf, std::allocator >::_M_high_mark() const' /usr/bin/ld: /tmp/cccbpRrv.ltrans0.ltrans.o: in function `boost::program_options::(anonymous namespace)::format_one(std::ostream&, boost::program_options::option_description const&, unsigned int, unsigned int) [clone .constprop.0]': :(.text+0x2d80): undefined reference to `std::__cxx11::basic_stringbuf, std::allocator >::_M_high_mark() const' /usr/bin/ld: :(.text+0x2e13): undefined reference to `std::__cxx11::basic_stringbuf, std::allocator >::_M_high_mark() const' /usr/bin/ld: :(.text+0x3d40): undefined reference to `std::__cxx11::basic_stringbuf, std::allocator >::_M_high_mark() const' collect2: error: ld returned 1 exit status $ I'm attaching a log showing the whole Boost.Program_options verbose build log. - Change "-Os" for "-O1" and it works - Remove the -supposedly unused- "#include " line and it works.
[Bug libstdc++/104019] Testsuite 17_intro/headers/c++2020/stdc++_multiple_inclusion.cc failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104019 --- Comment #14 from Jonathan Wakely --- Apart from the bogus warnings caused by PR 61596, I think only the std::latch problem remains. Comment 11 has a suggestion for that.
[Bug c++/105671] Unexplained "undefined reference" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105671
--- Comment #1 from Cristian Morales Vega ---
It's in the full verbose build log, but failed to include it here. These are
the contents of the files:
$ cat user-config.jam
using gcc : : g++ : "-flto" ;
$ cat test.cpp
#include
#include
#include
int
main()
{
auto generic = boost::program_options::options_description{};
std::cout << generic;
}
[Bug tree-optimization/105663] [11/12/13 Regression] ICE (segfault) in operator_bitwise_not::fold_range with O1/O2/O3/Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105663 --- Comment #8 from Hans de Jong --- The reduced testcase of comment #1 also fails on optimization levels O1 and Os. I added the compiler versions which I have seen break on godbolt.org.
[Bug middle-end/105629] [13 Regression] g++.dg/opt/pr94589-2.C for cris, m68k, s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105629 --- Comment #3 from Hans-Peter Nilsson --- (In reply to rguent...@suse.de from comment #2) > On Thu, 19 May 2022, hp at gcc dot gnu.org wrote: > I wonder if you can help and "bisect" the actual pattern that is now > enabled for GENERIC folding? The testcase is about spaceship optimization > and the matching done in forwprop might be quite specific and in the need > of a slight adjustment. I'm going to interpret that as "if each pattern had its own #if GIMPLE-wrapping, which hunk in the diff caused the regression". I'll try and see if it's as simple as it sounds.
[Bug ipa/105600] [9/10/11/12/13 Regression] ICE with LTO when building Mumble
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105600 --- Comment #14 from Martin Liška --- (In reply to Alex Coplan from comment #13) > FWIW, we started ICEing somewhere between > r9-856-g7ce4ce10cd0a6f332dd473bd4726f1a1adefda0e and > r9-870-ge062dc808950801a089ee6acd969393da2f39406, the build was broken > between these revisions. Sure, I've sent a fix that I'll backport later then.
[Bug middle-end/105629] [13 Regression] g++.dg/opt/pr94589-2.C for cris, m68k, s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105629 --- Comment #4 from rguenther at suse dot de --- On Fri, 20 May 2022, hp at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105629 > > --- Comment #3 from Hans-Peter Nilsson --- > (In reply to rguent...@suse.de from comment #2) > > On Thu, 19 May 2022, hp at gcc dot gnu.org wrote: > > I wonder if you can help and "bisect" the actual pattern that is now > > enabled for GENERIC folding? The testcase is about spaceship optimization > > and the matching done in forwprop might be quite specific and in the need > > of a slight adjustment. > > I'm going to interpret that as "if each pattern had its own #if > GIMPLE-wrapping, which hunk in the diff caused the regression". I'll try and > see if it's as simple as it sounds. Yes - thanks.
[Bug tree-optimization/102844] [9/10/11/12/13 Regression] DOM jump threading not copying block that became non-empty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102844 --- Comment #26 from Aldy Hernandez --- (In reply to Richard Biener from comment #25) > I'm not sure about the state of this bug - the issue reproduces on the GCC > 10 branch with checking enabled and -O[2s] -fdisable-tree-fre4 > -fno-strict-overflow > > It might be that using the backward threader from DOM (are we now doing > that?) > makes this truly fixed but I'm not sure the backward threader is resilent > to the issue analyzed in comments #13 to #15. Eventually the NOCOPY No. DOM is the only remaining use of the forward threader. It does not use the backward threader, nor the ranger path solver.
[Bug target/61810] init-regs.c papers over issues elsewhere
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61810
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comment #8 from Alexander Monakov ---
(In reply to Richard Biener from comment #7)
> But it looks like the testcase is broken:
>
> __attribute__((always_inline, target("avx2")))
> static __m256i
> load8bit_4x4_avx2(const uint8_t *const src, const uint32_t stride)
> {
> __m128i src01, src23;
> src01 = _mm_cvtsi32_si128(*(int32_t*)(src + 0 * stride));
> src23 = _mm_insert_epi32(src23, *(int32_t *)(src + 3 * stride), 1);
> return _mm256_setr_m128i(src01, src23);
> }
>
> it seems to expect that src23 is zero before inserting the data?
If you look in the original PR 104441 testcase, it has sensible code:
static __m256i __attribute__((always_inline))
load8bit_4x4_avx2(const uint8_t *const src, const uint32_t stride)
{
__m128i src01, src23;
src01 = _mm_cvtsi32_si128(*(int32_t*)(src + 0 * stride));
src01 = _mm_insert_epi32(src01, *(int32_t *)(src + 1 * stride), 1);
src23 = _mm_cvtsi32_si128(*(int32_t*)(src + 2 * stride));
src23 = _mm_insert_epi32(src23, *(int32_t *)(src + 3 * stride), 1);
return _mm256_setr_m128i(src01, src23);
}
[Bug middle-end/105654] transparent_union, function pointer and different types arguments causes null pointer to be passed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105654 Tobias Brunner changed: What|Removed |Added CC||tobias at strongswan dot org --- Comment #4 from Tobias Brunner --- Note that changing the macro so that instead of static typeof(_cb_parse)* parse = _cb_parse; it declares the function like this static _Bool (*parse)(void*, char* in) = _cb_parse; seems to fix the issue (see my update here: https://github.com/strongswan/strongswan/issues/1053#issuecomment-1131356912).
[Bug d/105659] error: #error You must define PREFERRED_DEBUGGING_TYPE if DWARF is not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105659 --- Comment #2 from Iain Buclaw --- (In reply to Iain Buclaw from comment #1) > If I recall the conversation correctly, either the CPU-specific D language > hooks should be moved to macros - equivalent to TARGET_CPU_CPP_BUILTINS and > others. Or the tm_d file should be packed with a lot more headers within - > possibly tricky as it would mean handling it in every possible path in > config.gcc. Or I do away with tm_d.h and just include tm.h and tm_p.h in all D-specific target files, so that the CPU version macros will always be picked up by default-d.cc and others. I note that there's also a similar hack done for darwin-d.cc, where tm-dwarf2.h is explicitly added to the tm_d.h file in order to get around this.
[Bug c++/105672] New: Print note when unable to convert between types with the same name but different scopes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105672
Bug ID: 105672
Summary: Print note when unable to convert between types with
the same name but different scopes
Product: gcc
Version: 12.1.1
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: ---
I spent far too long confused by this error:
vt.C:276:15: error: conversion from 'std::tuple, std::allocator >
>' to non-scalar type 'tuple, std::allocator > >' requested
276 | make_tuple(17, 2.718281828, std::string("Fun"));
| ~~^
The problem is that one type is std::tuple<...> and the other is ::tuple<...>
but the distinction is not very obvious in the error.
Could we add a note for ill-formed conversions between two types that have the
same name, to make it more obvious that they're defined in different scopes?
Maybe:
:: note: tuple and std::tuple are not the same type
:: note: tuple define here
:: note: std::tuple define here
[Bug c++/105672] Print note when unable to convert between types with the same name but different scopes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105672 --- Comment #1 from Jonathan Wakely --- Another option suggested by Barry Revzin is to line up the types, so that the type's name is in the same column so the different nested-name-qualifier is more obvious: vt.C:276:15: error: conversion from 'std::tuple' to non-scalar type 'tuple' requested Although this breaks the current convention that the error is on a single line. This also seems kinda related to the -fdiagnostics-show-template-tree option, but that doesn't help here (and that option is only helpful if you remember it exists and use it).
[Bug c++/89370] Output std::string in diagnostics instead of std::__cxx11::basic_string<_CharT, _Traits, _Alloc>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89370
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2019-02-18 00:00:00 |2022-5-20
--- Comment #3 from Jonathan Wakely ---
I lost two hours of my life last night because of this error:
vt.C:276:15: error: conversion from 'std::tuple, std::allocator >
>' to non-scalar type 'tuple, std::allocator > >' requested
276 | make_tuple(17, 2.718281828, std::string("Fun"));
| ~~^
I might have notice sooner that it's "std::tuple" vs "tuple" if I hadn't been
double- and triple-checking the std::__cxx11::basic_string noise :-(
Without default template args:
vt.C:276:15: error: conversion from 'std::tuple >' to non-scalar type 'tuple >' requested
276 | make_tuple(17, 2.718281828, std::string("Fun"));
| ~~^
And with std::__cxx11::basic_string replaced with just std::string:
vt.C:276:15: error: conversion from 'std::tuple' to
non-scalar type 'tuple' requested
276 | make_tuple(17, 2.718281828, std::string("Fun"));
| ~~^
(I've reported PR 105672 to improve this specific case, as the real problem is
orthogonal to the request for improving std::__cxx11::basic_string output.)
[Bug c++/89370] Output std::string in diagnostics instead of std::__cxx11::basic_string<_CharT, _Traits, _Alloc>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89370 Jonathan Wakely changed: What|Removed |Added Attachment #50880|0 |1 is obsolete|| --- Comment #4 from Jonathan Wakely --- Created attachment 53006 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53006&action=edit patch to make candidate printing less verbose (rebased) I've rebased Jason's patch, but it doesn't affect the printing of std::__cxx11::basic_string in the previous comment.
[Bug c++/105672] Print note when unable to convert between types with the same name but different scopes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105672 Barry Revzin changed: What|Removed |Added CC||barry.revzin at gmail dot com --- Comment #2 from Barry Revzin --- My suggestion is more to line up the fronts of the types: vt.C:276:15: error: conversion requested from: std::tuple to: tuple And drop the "non-scalar type" part - does it add anything meaningful to the diagnostic? I already know tuple<...> isn't a scalar (and if I didn't, would it help?) But what Mr. Wakely indicated also works - basically any presentation where the 'from' and 'to' types are on separate lines and similarly formatted makes it easier to see what's up.
[Bug c++/105672] Print note when unable to convert between types with the same name but different scopes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105672
--- Comment #3 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #0)
> Could we add a note for ill-formed conversions between two types that have
> the same name, to make it more obvious that they're defined in different
> scopes?
>
> Maybe:
>
> :: note: tuple and std::tuple are not the same type
> :: note: tuple define here
> :: note: std::tuple define here
I *don't* want the locations printed for two different specializations of the
same temploid, so e.g. don't show where foo::bar and foo::bar are
declared. It will almost certainly be the same line, which won't help the
confused user. I don't even think it's worth adding the first note that they're
not the same type for two specializations of the same template. That's not the
confusing case.
I'm only suggesting this for two unrelated types that just happen to have the
same name but are actually defined in totally different scopes, so a::foo and
b::foo, or c::bar and ::bar.
This would probably be useful for enumeration types as well as classes:
namespace a { enum foo { } }
namespace b { enum foo { B } }
a::foo e = b::B;
[Bug c++/105672] Print note when unable to convert between types with the same name but different scopes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105672 --- Comment #4 from Jonathan Wakely --- (In reply to Barry Revzin from comment #2) > And drop the "non-scalar type" part - does it add anything meaningful to the > diagnostic? Good point. I assume the intention of that wording is to say "I tried to find constructors and conversion operators to make this work, but there aren't any" but that's a very compiler-centric error. The user doesn't care where we looked, only that it didn't compile. They can figure out (or probably already know) whether that type is a class, and whether that means no constructor exists for the conversion.
[Bug c++/105672] Print note when unable to convert between types with the same name but different scopes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105672 --- Comment #5 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #0) > :: note: tuple and std::tuple are not the same type And just to be clear, it was very intentional that this suggestion *doesn't* show the template argument lists. That's just clutter in this context (and those arg lists are already shown in the "error:" line). The template arg lists are irrelevant here, *no* argument list is going to make them the same type, so showing it doesn't help. What matters here is the nested-name-specifier and the name after it.
[Bug tree-optimization/102844] [9/10/11/12/13 Regression] DOM jump threading not copying block that became non-empty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102844 --- Comment #27 from Jeffrey A. Law --- We're not using the backward threader to replace DOM's threader yet. I've got a TODO to push on Aldy's patch, but haven't been able to get to it over the last couple weeks. It's an, umm, busy time for us right now. There's really only one issue we need to hash out in Aldy's work and there's a couple proposed workarounds/interm solutions on our way to removing both the forward threader and DOM itself.
[Bug libstdc++/105673] New: _M_futex_wait_until_steady() always falls back to old syscall with FUTEX_WAIT operation even after successful FUTEX_WAIT_BITSET
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105673
Bug ID: 105673
Summary: _M_futex_wait_until_steady() always falls back to old
syscall with FUTEX_WAIT operation even after
successful FUTEX_WAIT_BITSET
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: vlad at solidsands dot nl
Target Milestone: ---
We were doing coverage analysis of GNU libstdc++ library and noticed that in
the function _M_futex_wait_until_steady() (src/c++11/futex.cc) the second part
of the function is always executed even though the FUTEX_WAIT_BITSET syscall is
available on the system.
How to reproduce:
auto f = std::async(std::launch::async, foo);
const auto start{std::chrono::steady_clock::now()};
auto status = f.wait_until(start + std::chrono::seconds{5});
We suspect the reason might be because the if statement on line 217 is missing
an else branch.
(https://gcc.gnu.org/git?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/src/c%2B%2B11/futex.cc;h=4d56c286ec597c19e4dc20bfb0c82d03ee93da8d;hb=HEAD#l217)
The sibling function _M_futex_wait_until() does have an else branch for similar
if statement. Without the else branch if futex syscall was successful the
function still falls back to the alternative version and performs another futex
syscall.
[Bug tree-optimization/102844] [9/10/11/12/13 Regression] DOM jump threading not copying block that became non-empty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102844 --- Comment #28 from Aldy Hernandez --- (In reply to Jeffrey A. Law from comment #27) > We're not using the backward threader to replace DOM's threader yet. I've > got a TODO to push on Aldy's patch, but haven't been able to get to it over > the last couple weeks. It's an, umm, busy time for us right now. > > There's really only one issue we need to hash out in Aldy's work and there's > a couple proposed workarounds/interm solutions on our way to removing both > the forward threader and DOM itself. And even that patch does not replace the forward threader. It is a hybrid approach using the forward threader, but the ranger path solver (instead of evrp). The forward threader should be with us until ranger can do floats and pointers later this season.
[Bug fortran/105674] New: Wrong bounds for assumed rank pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105674 Bug ID: 105674 Summary: Wrong bounds for assumed rank pointer Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: martin.diehl at kuleuven dot be Target Milestone: --- Created attachment 53007 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53007&action=edit small reproducer When using a pointer with striding, the ranks in a rank selector are wrong (0-based instead of 1-based). In the following program, lbound/lbound differ between 'strided' '(strided)'. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89364 and https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94070 seem to be related. The example is also attached as a file. program test integer, dimension(2,2), target :: dim_2 integer, dimension(product(shape(dim_2))), target :: dim_1 integer, dimension(:,:), pointer :: strided integer :: i dim_1 = [(i,i=1,size(dim_1,1))] dim_2 = reshape(dim_1,shape(dim_2)) strided => dim_2(1:1,:) print*, 'lbound', lbound(strided) print*, 'ubound', ubound(strided) call assumed_rank(dim_1) call assumed_rank(dim_2) call assumed_rank(strided) call assumed_rank((strided)) contains subroutine assumed_rank(dataset) integer, intent(in), dimension(..) :: dataset select rank(dataset) rank(1) print*, 'rank 1' print*, 'lbound', lbound(dataset), 'ubound', ubound(dataset) print*, dataset rank(2) print*, 'rank 2', dataset print*, 'lbound', lbound(dataset), 'ubound', ubound(dataset) end select print*, '' end subroutine assumed_rank end program test
[Bug libstdc++/105673] _M_futex_wait_until_steady() always falls back to old syscall with FUTEX_WAIT operation even after successful FUTEX_WAIT_BITSET
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105673 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-05-20 --- Comment #1 from Jonathan Wakely --- Good catch, thanks.
[Bug c/105675] New: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105675 Bug ID: 105675 Summary: Segmentation fault Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: watarai775 at gmail dot com Target Milestone: --- Running gcc on input file from an attachment resulting in segmentation fault gcc-12 1.cpp gcc-12: internal compiler error: Segmentation fault signal terminated program cc1plus Please submit a full bug report, with preprocessed source (by using -freport-bug). See for instructions.
[Bug c/105676] New: Bogus `-Wsuggest-attribute=pure` on function marked `__attribute__((const))`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105676
Bug ID: 105676
Summary: Bogus `-Wsuggest-attribute=pure` on function marked
`__attribute__((const))`
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sagebar at web dot de
Target Milestone: ---
When compiling with `-Wsuggest-attribute=pure`, gcc warns about missing
`__attribute__((pure))` on functions declared as `__attribute__((const))`.
It is common knowledge that any function marked as `__attribute__((const))`
also implicitly has the behavior of a function marked as
`__attribute__((pure))` (const implies pure).
Therefor, it stands to reason that such a warning is bogus (also: earlier
version of gcc didn't emit a warning in this case; know: gcc-9 already
supported these warnings, but didn't emit `-Wsuggest-attribute=pure` on a
`__attribute__((const))` function).
Example (`gcc -Wsuggest-attribute=pure -c -O2 input.c`):
```
__attribute__((const))
extern int do_expensive_calculation(void);
__attribute__((const))
int getval(void) {
static int cache = -1;
if (cache == -1)
cache = do_expensive_calculation();
return cache;
}
```
>test.c: In function 'getval':
>test.c:5:5: warning: function might be candidate for attribute 'pure'
>>[-Wsuggest-attribute=pure]
>5 | int getval(void) {
> | ^~
When trying to declare as both pure+const:
>test.c:5:1: warning: ignoring attribute 'const' because it conflicts with
>attribute 'pure' [-Wattributes]
>5 | int getval(void) {
> | ^~~
Explaination of why using `__attribute__((const))` is valid here
I see why gcc might think that `getval()` is *only* `pure`, but there is
nothing wrong with the `__attribute__((const))` annotation since we don't "read
global memory" (emphasis on the "global"), and thus don't depend on the global
state (also: what counts as "global" vs. "non-global" isn't something that can
be quantified. - It depends on the application and how memory is used).
As such, the use of `__attribute__((const))` is very much valid (and gcc might
even consider suggesting `__attribute__((const))` instead of
`__attribute__((pure))`, since because `cache` is scoped-static, it not being
used outside of `getval()` can actually be proven, though that isn't what this
bug report is about...). However, so-long as it believes that the function is
pure, there is no reason to ever emit a about that fact so-long as `getval()`
remains annotated as `__attribute__((const))`.
End of Explaination
[Bug target/105275] 525.x264_r and 538.imagick_r regressed on x86_64 at -O2 with PGO after r12-7319-g90d693bdc9d718
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105275 --- Comment #1 from Martin Jambor --- Confirmed with GCC 12.1 numbers.
[Bug ipa/105676] [12/13 Regression] Bogus `-Wsuggest-attribute=pure` on function marked `__attribute__((const))`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105676 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2022-05-20 Status|UNCONFIRMED |NEW Known to fail||12.1.0 Known to work||11.2.0, 11.3.0 Ever confirmed|0 |1 Target Milestone|--- |12.2 Summary|Bogus |[12/13 Regression] Bogus |`-Wsuggest-attribute=pure` |`-Wsuggest-attribute=pure` |on function marked |on function marked |`__attribute__((const))`|`__attribute__((const))` --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug target/105493] [12/13 Regression] x86_64 538.imagick_r 6% regressions and 2% 525.x264_r regressions on Alder Lake after r12-7319-g90d693bdc9d718
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105493 --- Comment #5 from Martin Jambor --- I can confirm that an Intel Cascade Lake Xeon, using -Ofast -flto -march=native, 538.imagick_r produced by GCC 12.1 is almost 20% slower than the benchmark built with GCC 11.2 and the same options (on Zen2 or 3 I can see only smaller regressios at -O2 and with PGO) I do not see the 525.x264_r regression using the same compilers and options on this machine.
[Bug c/105675] Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105675 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2022-05-20 --- Comment #1 from Andrew Pinski --- >Running gcc on input file from an attachment resulting in segmentation fault The file didn't attach, maybe it was too big. Can you try to compress it and attach that?
[Bug target/105670] [x86] suboptimal code for branch over two bools
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105670 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2022-05-20 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Gimple level is good: _7 = a_2(D) & b_3(D); if (_7 != 0) goto ; [50.00%] else goto ; [50.00%] But at expand it changes the above to: (insn 11 10 12 (set (reg:CCZ 17 flags) (compare:CCZ (reg/v:QI 83 [ a ]) (const_int 0 [0]))) "/app/example.cpp":2:3 -1 (nil)) (jump_insn 12 11 13 (set (pc) (if_then_else (eq (reg:CCZ 17 flags) (const_int 0 [0])) (label_ref 0) (pc))) "/app/example.cpp":2:3 -1 (int_list:REG_BR_PROB 268435460 (nil))) (insn 13 12 14 (set (reg:CCZ 17 flags) (compare:CCZ (reg/v:QI 85 [ b ]) (const_int 0 [0]))) "/app/example.cpp":2:3 -1 (nil)) (jump_insn 14 13 0 (set (pc) (if_then_else (eq (reg:CCZ 17 flags) (const_int 0 [0])) (label_ref 0) (pc))) "/app/example.cpp":2:3 -1 (int_list:REG_BR_PROB 357913948 (nil))) I noticed LLVM does the same as GCC here ... While ICC does the one test.
[Bug target/105670] [x86] suboptimal code for branch over two bools
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105670 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug target/61810] init-regs.c papers over issues elsewhere
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61810 --- Comment #9 from H.J. Lu --- Created attachment 53008 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53008&action=edit A patch for pr104441-1a.c Does it help?
[Bug tree-optimization/105677] New: Calling strlen on a string constant is optimized out, but calling wcslen on a string constant is not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105677
Bug ID: 105677
Summary: Calling strlen on a string constant is optimized out,
but calling wcslen on a string constant is not
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: alexhenrie24 at gmail dot com
Target Milestone: ---
strlen example, source code:
#include
int main()
{
return strlen("Hello world!");
}
strlen example, assembly code at -O3:
movl$12, %eax
ret
wcslen example, source code:
#include
int main()
{
return wcslen(L"Hello world!");
}
wcslen example, assembly code at -O3:
subq$8, %rsp
.cfi_def_cfa_offset 16
leaq.LC0(%rip), %rdi
callwcslen@PLT
addq$8, %rsp
.cfi_def_cfa_offset 8
ret
Interestingly, Clang produces identical assembly code for both examples, which
is what I expected GCC to do.
[Bug tree-optimization/105677] Calling strlen on a string constant is optimized out, but calling wcslen on a string constant is not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105677 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement --- Comment #1 from Andrew Pinski --- GCC does not optimize any of the wide character functions ...
[Bug c++/105675] Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105675 --- Comment #2 from Ruslan Mkoyan --- Created attachment 53009 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53009&action=edit Input file
[Bug c/105675] Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105675 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX Keywords||ice-on-valid-code --- Comment #3 from Andrew Pinski --- This is a won't fix stitutation. You have & on a type repeated 237,679 times. With a recusive decent compiler, you run out of stack space with that many times. #17 0x00b7c653 in cp_parser_declarator (parser=0x772bd7b8, dcl_kind=CP_PARSER_DECLARATOR_NAMED, flags=0, ctor_dtor_or_conv_p=0x0, parenthesized_p=, member_p=false, friend_p=false, static_p=false) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:22948 #18 0x00b7c653 in cp_parser_declarator (parser=0x772bd7b8, dcl_kind=CP_PARSER_DECLARATOR_NAMED, flags=0, ctor_dtor_or_conv_p=0x0, parenthesized_p=, member_p=false, friend_p=false, static_p=false) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:22948 #19 0x00b7c653 in cp_parser_declarator (parser=0x772bd7b8, dcl_kind=CP_PARSER_DECLARATOR_NAMED, flags=0, ctor_dtor_or_conv_p=0x0, parenthesized_p=, member_p=false, friend_p=false, static_p=false) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:22948 #20 0x00b7c653 in cp_parser_declarator (parser=0x772bd7b8, dcl_kind=CP_PARSER_DECLARATOR_NAMED, flags=0, ctor_dtor_or_conv_p=0x0, parenthesized_p=, member_p=false, friend_p=false, static_p=false) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:22948 #21 0x00b7c653 in cp_parser_declarator (parser=0x772bd7b8, dcl_kind=CP_PARSER_DECLARATOR_NAMED, flags=0, ctor_dtor_or_conv_p=0x0, parenthesized_p=, member_p=false, friend_p=false, static_p=false) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:22948 #22 0x00b7c653 in cp_parser_declarator (parser=0x772bd7b8, dcl_kind=CP_PARSER_DECLARATOR_NAMED, flags=0, ctor_dtor_or_conv_p=0x0, parenthesized_p=, member_p=false, friend_p=false, static_p=false) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:22948 #23 0x00b7c653 in cp_parser_declarator (parser=0x772bd7b8, dcl_kind=CP_PARSER_DECLARATOR_NAMED, flags=0, ctor_dtor_or_conv_p=0x0, parenthesized_p=, member_p=false, friend_p=false, static_p=false) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:22948 #24 0x00b7c653 in cp_parser_declarator (parser=0x772bd7b8, dcl_kind=CP_PARSER_DECLARATOR_NAMED, flags=0, ctor_dtor_or_conv_p=0x0, parenthesized_p=, member_p=false, friend_p=false, static_p=false) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:22948 #25 0x00b7c653 in cp_parser_declarator (parser=0x772bd7b8, dcl_kind=CP_PARSER_DECLARATOR_NAMED, flags=0, ctor_dtor_or_conv_p=0x0, parenthesized_p=, member_p=false, friend_p=false, static_p=false) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:22948 #26 0x00b7c653 in cp_parser_declarator (parser=0x772bd7b8, dcl_kind=CP_PARSER_DECLARATOR_NAMED, flags=0, ctor_dtor_or_conv_p=0x0, parenthesized_p=, member_p=false, friend_p=false, static_p=false) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:22948 #27 0x00b7c653 in cp_parser_declarator (parser=0x772bd7b8, dcl_kind=CP_PARSER_DECLARATOR_NAMED, flags=0, ctor_dtor_or_conv_p=0x0, parenthesized_p=, member_p=false, friend_p=false, static_p=false) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:22948 #28 0x00b7c653 in cp_parser_declarator (parser=0x772bd7b8, dcl_kind=CP_PARSER_DECLARATOR_NAMED, flags=0, ctor_dtor_or_conv_p=0x0, parenthesized_p=, member_p=false, friend_p=false, static_p=false) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:22948 #29 0x00b7c653 in cp_parser_declarator (parser=0x772bd7b8, dcl_kind=CP_PARSER_DECLARATOR_NAMED, flags=0, ctor_dtor_or_conv_p=0x0, parenthesized_p=, member_p=false, friend_p=false, static_p=false) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:22948 #30 0x00b7c653 in cp_parser_declarator (parser=0x772bd7b8, dcl_kind=CP_PARSER_DECLARATOR_NAMED, flags=0, ctor_dtor_or_conv_p=0x0, parenthesized_p=, member_p=false, friend_p=false, static_p=false) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:22948 #31 0x00b7c653 in cp_parser_declarator (parser=0x772bd7b8, dcl_kind=CP_PARSER_DECLARATOR_NAMED, flags=0, ctor_dtor_or_conv_p=0x0, parenthesized_p=, member_p=false, friend_p=false, static_p=false) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:22948 #32 0x00b7c653 in cp_parser_declarator (parser=0x772bd7b8, dcl_kind=CP_PARSER_DECLARATOR_NAMED, flags=0, ctor_dtor_or_conv_p=0x0, parenthesized_p=, member_p=false, friend_p=false, static_p=false) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:22948 #33 0x00b7c653 in cp_parser_declarator (parser=0x772bd7b8, dcl_kind=CP_PARSER_DECLARATO
[Bug tree-optimization/105668] [13 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281 with -O -ftracer -fno-tree-fre since r13-458-gd75d4293dcc029a7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105668 Roger Sayle changed: What|Removed |Added CC||roger at nextmovesoftware dot com --- Comment #3 from Roger Sayle --- I suspect that the middle-end could be a bit more forgiving whilst expanding vcond_mask. If a target doesn't provide V1TImode, GCC can fall back to using V2DImode, and if that isn't supported V4SImode, then V8HImode then V16QImode. On x86-64, these all use the same vblendvb instruction or pand,pandn,por logic (also known as V128BImode :-).
[Bug libstdc++/105678] New: Undefined reference to stacktrace standard library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105678
Bug ID: 105678
Summary: Undefined reference to stacktrace standard library
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: fcolecumberri at hotmail dot com
Target Milestone: ---
I'm trying to test the stacktrace C++23 feature by creating the next program:
```c++
#include
int main(){
std::stacktrace::current();
return 0;
}
```
using the next g++:
```
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/franky/Descargas/gcc-libs/src/gcc/configure
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-bootstrap
--prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit
--enable-cet=auto --enable-checking=release --enable-clocale=gnu
--enable-default-pie --enable-default-ssp --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-linker-build-id --enable-lto
--enable-multilib --enable-plugin --enable-shared --enable-threads=posix
--disable-libssp --disable-libstdcxx-pch --disable-werror
--with-build-config=bootstrap-lto --enable-link-serialization=1
--enable-libstdcxx-backtrace=yes
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.1.0 (GCC)
```
Notice I added the `--enable-libstdcxx-backtrace=yes`
with this command:
```bash
g++ -std=gnu++2b cpp_file.cpp
```
And I get the next output:
```
/usr/bin/ld: a-cpp_file.o: in function `std::stacktrace_entry::_S_init()':
cpp_file.cpp:(.text._ZNSt16stacktrace_entry7_S_initEv[_ZNSt16stacktrace_entry7_S_initEv]+0x4a):
undefined reference to `__glibcxx_backtrace_create_state'
/usr/bin/ld: a-cpp_file.o: in function
`std::basic_stacktrace
>::current(std::allocator const&)':
cpp_file.cpp:(.text._ZNSt16basic_stacktraceISaISt16stacktrace_entryEE7currentERKS1_[_ZNSt16basic_stacktraceISaISt16stacktrace_entryEE7currentERKS1_]+0x70):
undefined reference to `__glibcxx_backtrace_simple'
collect2: error: ld returned 1 exit status
```
Maybe I am missing something, maybe the documentation is missing something, or
maybe this is still very experimental.
[Bug libstdc++/105678] Undefined reference to stacktrace standard library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105678 --- Comment #1 from Andrew Pinski --- I suspect it is missing from the linker script for versioning. Using -static-libstdc++ should be a workaround.
[Bug libstdc++/105678] Undefined reference to stacktrace standard library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105678 --- Comment #2 from Francisco --- just tried ```bash g++ -std=gnu++2b -static-libstdc++ cpp_file.cpp ``` but same result.
[Bug fortran/105674] Wrong bounds for assumed rank pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105674 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords||wrong-code Last reconfirmed||2022-05-20 Ever confirmed|0 |1 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. All versions accepting assumed-rank (10+) are affected. The lower bounds of the temporary are reset to the wrong value (0 instead of 1).
[Bug libgcc/105669] DFP to HF (_Float16) conversions use incorrect rounding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105669
Joseph S. Myers changed:
What|Removed |Added
Last reconfirmed||2022-05-20
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #1 from Joseph S. Myers ---
Example test illustrating this bug, at least on x86_64 (the DFP input is very
close to half way between two consecutive _Float16 values):
extern void exit (int);
extern void abort (void);
#define DCONST 7.340312e-5DF
static const _Float16 f1 = DCONST;
volatile _Decimal32 d = DCONST;
int
main (void)
{
volatile _Float16 f2;
f2 = d;
if (f1 == f2)
exit (0);
else
abort ();
}
[Bug middle-end/105629] [13 Regression] g++.dg/opt/pr94589-2.C for cris, m68k, s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105629
--- Comment #5 from Hans-Peter Nilsson ---
Additional observation: the diff is local to functions f5 and f17 (in
g++.dg/opt/pr94589-2.C), i.e. "reduced" to (for reference only):
A bool f5 (double i, double j) { auto c = i <=> j; return c >= 0; }
A bool f17 (double i) { auto c = i <=> 5.0; return c >= 0; }
[Bug target/105556] RA assigns an MMA vector input operand to vs0-vs31 causing an MMA accumulator to be spilled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105556 --- Comment #5 from CVS Commits --- The releases/gcc-12 branch has been updated by Peter Bergner : https://gcc.gnu.org/g:c83d78585078d6918853fbe0f74a3a78e88e3e32 commit r12-8406-gc83d78585078d6918853fbe0f74a3a78e88e3e32 Author: Peter Bergner Date: Tue May 17 21:09:29 2022 -0500 rs6000: Prefer assigning the MMA vector operands to altivec registers [PR105556] When optimizing the DGEMM kernel in OpenBLAS to use MMA, the MMA code uses all 8 accumulators, which overlap all vs0-vs31 vector registers. Current trunk assigns one of the normal vector inputs to one of the MMA instructions, which forces us to spill one of the accumulators to memory, leading to poor performance. The solution here is to replace the "wa" constraints for the vector input operands in the MMA instruction patterns with "v,?wa" so that we prefer using the altivec registers vs32-vs63 over the vs0-vs31 registers. 2022-05-17 Peter Bergner Segher Boessenkool gcc/ PR target/105556 * config/rs6000/mma.md (mma_, mma_, mma_, mma_, mma_, mma_, mma_, mma_, mma_, mma_, mma_, mma_, mma_, mma_): Replace "wa" constraints with "v,?wa". Update other operands accordingly. (cherry picked from commit c6e36f05fbb081abb068958d8900ad34b303a70b)
[Bug target/105556] RA assigns an MMA vector input operand to vs0-vs31 causing an MMA accumulator to be spilled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105556 Peter Bergner changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Peter Bergner --- Fixed on trunk and GCC 12. At the moment, no need for GCC 11 or later backports.
[Bug c/105679] New: erroneous -Warray-bounds warning with sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105679 Bug ID: 105679 Summary: erroneous -Warray-bounds warning with sanitizer Product: gcc Version: 12.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: kees at outflux dot net Target Milestone: --- Created attachment 53010 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53010&action=edit test case minimized as much as possible Some combination of things (likely triggered by -fsanitize=shift and an array index being used with "<<" operator) is causing erroneous warnings about array bounds accesses: $ gcc -O2 -Warray-bounds -fno-strict-aliasing -fno-strict-overflow -fsanitize=shift -fsanitize-coverage=trace-pc -c -o /dev/null test.c test.c: In function 'work.isra': test.c:31:32: warning: array subscript 32 is above array bounds of 'struct object[2]' [-Warray-bounds] 31 | entry = instance->array[irq]; | ~~~^ test.c:19:23: note: while referencing 'array' 19 | struct object array[ELEMENTS]; | ^
[Bug c/105679] erroneous -Warray-bounds warning with sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105679 --- Comment #1 from Kees Cook --- The Linux kernel has encountered at least two of these (seen as specifically "array subscript 32", though the root cause may be causing many others: ../drivers/net/wireless/ath/ath9k/mac.c:373:22: warning: array subscript 32 is above array bounds of 'struct ath9k_tx_queue_info[10]' [-Warray-bounds] ../arch/x86/kvm/ioapic.c:213:33: warning: array subscript 32 is above array bounds of 'union kvm_ioapic_redirect_entry[24]' [-Warray-bounds]
[Bug tree-optimization/105679] erroneous -Warray-bounds warning with sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105679 --- Comment #2 from Andrew Pinski --- This is jump threading due to the fsanitize=shift option. With the irq argument to work changed to int from unsigned, the work function is inlined. And then the check: if (irq < 0 || irq >= ELEMENTS) return; works. So I don't know how to solve this really.
[Bug middle-end/105629] [13 Regression] g++.dg/opt/pr94589-2.C for cris, m68k, s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105629 --- Comment #6 from Hans-Peter Nilsson --- Created attachment 53011 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53011&action=edit Reduced fix on top of 93416de0cb; a fragmental revert The attached patch, applied to 93416de0cb, re-introduces the one of the removed #if GIMPLE clauses, but narrowed to the one (simplify ...) clause, that mattered for the regression. (Not regtested though, just pr94589-2.C re-compiled.) I have no idea how this pattern matched here, as there appears to be no "bit_and" expressions in the affected functions. I'd suspect some kind of saddle-point/local-minimum false lead, except then there'd reasonably be some half-way transformation left in the code. But then again, reasoning around bugs you don't fully understand is rarely useful. Anyway, I hope this helped.
[Bug c++/105680] New: undefined type after new does not give a helpful error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105680
Bug ID: 105680
Summary: undefined type after new does not give a helpful error
message
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
struct settype{};
void g(void){
new setype();
}
--- CUT ---
There is a typo in g for settype missing one character. GCC gives:
: In function 'void g()':
:4:9: error: expected type-specifier before 'setype'
4 | new setype();
| ^~
I looked at this a few times to see what my mistake was and I finally figured
it out.
Clang gives a much better error message:
:4:9: error: unknown type name 'setype'; did you mean 'settype'?
new setype();
^~
settype
:1:8: note: 'settype' declared here
struct settype{};
^
[Bug c++/105680] undefined type after new does not give a helpful error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105680 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
