[Bug libstdc++/100889] Wrong param type for std::atomic_ref<_Tp*>::wait
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100889 --- Comment #1 from Richard Li --- Created attachment 50917 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50917&action=edit Proposed patch This patch fixes the problem.
[Bug libstdc++/100889] New: Wrong param type for std::atomic_ref<_Tp*>::wait
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100889
Bug ID: 100889
Summary: Wrong param type for std::atomic_ref<_Tp*>::wait
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: richardpku at gmail dot com
Target Milestone: ---
/tmp % cat a.cpp
#include
void* p;
void foo() { std::atomic_ref(p).store(nullptr); }
/tmp % g++-11.1.0 -c -std=gnu++20 a.cpp
In file included from
/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/include/g++-v11/atomic:41,
from a.cpp:1:
/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/include/g++-v11/bits/atomic_base.h: In
instantiation of 'struct std::__atomic_ref':
/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/include/g++-v11/atomic:1618:12:
required from 'struct std::atomic_ref'
a.cpp:3:31: required from here
/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/include/g++-v11/bits/atomic_base.h:1873:7:
error: invalid parameter type 'void'
1873 | wait(_Tp __old, memory_order __m = memory_order_seq_cst) const
noexcept
| ^~~~
/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/include/g++-v11/bits/atomic_base.h:1873:7:
error: in declaration 'void std::__atomic_ref<_Tp*, false, false>::wait(_Tp,
std::memory_order) const'
Apparently, the first param of std::atomic<_Tp*>::wait should be _Tp* instead
of _Tp.
It appears this bug has existed since GCC 11, when __cpp_lib_atomic_wait was
implemented.
[Bug tree-optimization/13563] if-conversion not agressive enough
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13563 Andrew Pinski changed: What|Removed |Added CC||nok.raven at gmail dot com --- Comment #5 from Andrew Pinski --- *** Bug 100857 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/100857] Simple common code sinking is not performed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100857 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- (In reply to Richard Biener from comment #1) > There's a duplicate of this PR. sink_common_stores_to_bb could be quite > easily enhanced to perform the desired transform on such simple testcases. PR 13563. *** This bug has been marked as a duplicate of bug 13563 ***
[Bug target/100885] [12 Regression] ICE: in extract_constrain_insn, at recog.c:2671: insn does not satisfy its constraints: {sse4_1_zero_extendv8qiv8hi2}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100885 --- Comment #3 from Hongtao.liu --- (In reply to Hongtao.liu from comment #2) > > With avx512vl Yw should be matched, and w/o avx512bw, only SSE_REGS should > > be matched, why xmm16 is allocated? > > It didn't come from RA, but post_reload splitter. > > 18103(define_insn_and_split "*sse4_1_zero_extendv8qiv8hi2_3" > 18104 [(set (match_operand:V16QI 0 "register_operand" "=Yr,*x,v") > 18105(vec_select:V16QI > 18106 (vec_concat:V32QI > 18107(match_operand:V16QI 1 "vector_operand" "YrBm,*xBm,vm") > 18108(match_operand:V16QI 2 "const0_operand" "C,C,C")) > 18109 (match_parallel 3 "pmovzx_parallel" > 18110[(match_operand 4 "const_int_operand" "n,n,n")])))] > 18111 "TARGET_SSE4_1" Need to adjust the third constraint from (v, vm, C, n) to (Yw, Ywm, C, n)
[Bug tree-optimization/78528] Recursion not optimized for structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78528 --- Comment #5 from Andrew Pinski --- tailr1: D.2500 = strlen (_2); : lhs$m_value_10 = D.2500.m_value; _14 = lhs$m_value_10 + 1; D.2496.m_value = _14; : return D.2496; For tailr on structures we only allow for structure copies and nothing else. For an example, if we remove the + 1 part, we do get the tail recursion. Now the question becomes is it worth the effect in doing it. clang can handle this case because they handle structures at a lower level than GCC does.
[Bug target/43892] PowerPC suboptimal "add with carry" optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
--- Comment #33 from Segher Boessenkool ---
(In reply to Andrew Pinski from comment #32)
> So it is more about the back-end of PowerPC at this point.
For the testcase
===
typedef unsigned int u32;
typedef unsigned long long u64;
u32 f(u32 a, u32 b)
{
u32 s = a + b;
if (a + b < b)
s++;
return s;
}
u32 g(u32 *p, u32 n)
{
u32 s = 0;
while (n--)
s = f(s, *p++);
return s;
}
u32 g4(u32 *p)
{
u32 s = 0;
s = f(s, *p++);
s = f(s, *p++);
s = f(s, *p++);
s = f(s, *p++);
return s;
}
u32 h4(u32 *p)
{
u64 s = 0;
s += *p++;imple
s += *p++;
s += *p++;
s += *p++;
s = (s >> 32) + (u32)s;
s = (s >> 32) + (u32)s;
return s;
}
===
... GCC does not do anything with ADD_OVERFLOW. But all *do* compile
to reasonable code (albeit not optimal). So no, you cannot say Gimple
is super here and it is all the backend's fault :-)
[Bug tree-optimization/67998] redundant test for 0 when also checking inequality
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67998 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Target Milestone|--- |12.0 Known to fail||7.1.0 --- Comment #2 from Andrew Pinski --- Fixed already on the trunk, I have not tried any other version (except GCC 7 where it was still broken): [local count: 1073741824]: if (a_2(D) <= b_3(D)) goto ; [34.00%] else goto ; [66.00%] [local count: 365072224]: [local count: 1073741824]: # _1 = PHI <5(3), 2(2)>
[Bug middle-end/68000] Suboptimal ternary operator codegen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68000 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #5 from Andrew Pinski --- So take: p->x + 1 == p->y If p->x == 255 and p->y == 0. The above will be false due to C integer promotion rules. The other two testcases have the case where p->x == 255 and p->y == 0 will be true. Basically foo is not the same as the other two.
[Bug c++/100877] g++ freezes system by consuming infinite amount of memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100877 Steven Sun changed: What|Removed |Added CC||StevenSun2021 at hotmail dot com --- Comment #2 from Steven Sun --- Feng use a non-exist member in your definition of template< Expression Ex, Place_Holder Ph, Expression Ey > auto replace_placeholder_with_expression( Ex const& ex, Ph const& old_place_holder, Ey const& new_expression ) namely `ex.reset_action_`. It the one and only bug in your code. It compiles in a few seconds after being fixed. CONCLUSION: No bug in GCC but a stupid bug in Feng's code. But interestingly, GCC eats so much memory to dump an error message involving lambdas, template lambdas, and templates (eats 20G in my desktop, >400G in Feng's cluster).
[Bug target/100885] [12 Regression] ICE: in extract_constrain_insn, at recog.c:2671: insn does not satisfy its constraints: {sse4_1_zero_extendv8qiv8hi2}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100885 --- Comment #2 from Hongtao.liu --- > With avx512vl Yw should be matched, and w/o avx512bw, only SSE_REGS should > be matched, why xmm16 is allocated? It didn't come from RA, but post_reload splitter. 18103(define_insn_and_split "*sse4_1_zero_extendv8qiv8hi2_3" 18104 [(set (match_operand:V16QI 0 "register_operand" "=Yr,*x,v") 18105(vec_select:V16QI 18106 (vec_concat:V32QI 18107(match_operand:V16QI 1 "vector_operand" "YrBm,*xBm,vm") 18108(match_operand:V16QI 2 "const0_operand" "C,C,C")) 18109 (match_parallel 3 "pmovzx_parallel" 18110[(match_operand 4 "const_int_operand" "n,n,n")])))] 18111 "TARGET_SSE4_1"
[Bug tree-optimization/22199] fold does not optimize (int)ABS_EXPR<(long long)(int_var)>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22199 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |9.0 --- Comment #5 from Andrew Pinski --- Fixed with r9-1281 by the way.
[Bug c++/100877] g++ freezes system by consuming infinite amount of memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100877 --- Comment #1 from Steven Sun --- I look at the call stack. Most of the time is wasted on `dump_template_parms` in `gcc/cp/error.c`. I commented several functions calling it: (I'm using stage-1 compiler) `announce_function` in `gcc/toplev.c` `push_tinst_level_loc` in `gcc/cp/pt.c` `cp_printer` in `gcc/cp/error.c` (directly return true) Then I got the output after a few seconds. -- examples/../include/./model.hpp: In instantiation of ‘’: examples/../include/./model.hpp:55:147: required from ‘’ examples/../include/./model.hpp:61:77: required from ‘’ examples/../include/./model.hpp:55:147: [ skipping 8 instantiation contexts, use -ftemplate-backtrace-limit=0 to disable ] examples/../include/./model.hpp:55:147: required from ‘’ examples/../include/./model.hpp:55:147: recursively required from ‘’ examples/../include/./model.hpp:55:147: required from ‘’ examples/../include/./model.hpp:60:77: required from ‘’ examples/../include/./model.hpp:60:77: recursively required from ‘’ examples/../include/./model.hpp:55:147: recursively required from ‘’ examples/../include/./model.hpp:55:147: required from ‘’ examples/../include/./model.hpp:55:147: recursively required from ‘’ examples/../include/./model.hpp:55:147: required from ‘’ examples/../include/./model.hpp:60:77: required from ‘’ examples/../include/./model.hpp:55:147: required from ‘’ examples/../include/./model.hpp:382:55: required from ‘’ examples/dcgan.cc:48:43: required from here examples/../include/./model.hpp:59:96: error: ‘’ has no member named ‘’ -- But I cannot give the output. Because the dumping process will lead to an out of memory. If I disable member access check, it gives an error - examples/../include/./model.hpp: In instantiation of ‘’: examples/../include/./model.hpp:55:147: recursively required from ‘’ examples/../include/./model.hpp:55:147: required from ‘’ examples/../include/./model.hpp:60:77: required from ‘’ examples/../include/./model.hpp:55:147: required from ‘’ examples/../include/./model.hpp:382:55: required from ‘’ examples/dcgan.cc:48:43: required from here examples/../include/./model.hpp:60:77: error: use of ‘’ before deduction of ‘auto’ It's the same source location! and it is in your definition of template< Expression Ex, Place_Holder Ph, Expression Ey > auto replace_placeholder_with_expression( Ex const& ex, Ph const& old_place_holder, Ey const& new_expression )
[Bug tree-optimization/64946] [AArch64] gcc.target/aarch64/vect-abs-compile.c - "abs" vectorization fails for char/short types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64946 Bug 64946 depends on bug 22199, which changed state. Bug 22199 Summary: fold does not optimize (int)ABS_EXPR<(long long)(int_var)> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22199 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug middle-end/19987] [meta-bug] fold missing optimizations in general
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987 Bug 19987 depends on bug 22199, which changed state. Bug 22199 Summary: fold does not optimize (int)ABS_EXPR<(long long)(int_var)> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22199 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/22199] fold does not optimize (int)ABS_EXPR<(long long)(int_var)>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22199 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Andrew Pinski --- There is ABSU now. Which we use now: a.0_1 = a; _2 = ABSU_EXPR ; _3 = (long int) _2; b.1_4 = b; So fixed.
[Bug target/100885] [12 Regression] ICE: in extract_constrain_insn, at recog.c:2671: insn does not satisfy its constraints: {sse4_1_zero_extendv8qiv8hi2}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100885
--- Comment #1 from Hongtao.liu ---
152(define_register_constraint "Yw"
153 "TARGET_AVX512BW && TARGET_AVX512VL ? ALL_SSE_REGS : TARGET_SSE ? SSE_REGS
: NO_REGS"
154 "@internal Any EVEX encodable SSE register (@code{%xmm0-%xmm31}) for
AVX512BW with TARGET_AVX512VL target, otherwise any \
SSE register.")
19076(define_insn "sse4_1_v8qiv8hi2"
19077 [(set (match_operand:V8HI 0 "register_operand" "=Yr,*x,Yw")
19078(any_extend:V8HI
19079 (vec_select:V8QI
19080(match_operand:V16QI 1 "register_operand" "Yr,*x,Yw")
19081(parallel [(const_int 0) (const_int 1)
19082 (const_int 2) (const_int 3)
19083 (const_int 4) (const_int 5)
19084 (const_int 6) (const_int 7)]]
19085 "TARGET_SSE4_1 && &&
"
19086 "%vpmovbw\t{%1, %0|%0, %1}"
19087 [(set_attr "isa" "noavx,noavx,avx")
19088 (set_attr "type" "ssemov")
19089 (set_attr "prefix_extra" "1")
19090 (set_attr "prefix" "orig,orig,maybe_evex")
19091 (set_attr "mode" "TI")])
With avx512vl Yw should be matched, and w/o avx512bw, only SSE_REGS should be
matched, why xmm16 is allocated?
[Bug tree-optimization/27109] Simplify "a - 10 > 150" into "a > 160" when range of a is known (in VRP or somewhere else)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27109
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2007-07-01 00:53:44 |2021-6-2
--- Comment #3 from Andrew Pinski ---
Here is a better testcase:
void bar(void);
void goo(void);
void
foo (unsigned a)
{
if (a < 100)
return;
goo();
if (200 < a)
return;
if (a - 10 > 150)
bar ();
}
Note the original testcase is optimized correctly in reassoc1 but that was not
the point of it.
Anyways we have:
# RANGE [90, 190] NONZERO 255
_1 = a_3(D) + 4294967286;
if (_1 > 150)
4294967286 is -10
[Bug tree-optimization/29738] Missed constant propagation into loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29738 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #14 from Andrew Pinski --- (In reply to Richard Biener from comment #13) > A case predicated VN should handle. Fixed in GCC 9 with r9-2635
[Bug tree-optimization/35306] Missing expression simplication for conditional OR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35306 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |7.0 Status|NEW |RESOLVED --- Comment #4 from Andrew Pinski --- Fixed in GCC 7 at least. Note there is an extra cast in the bla function but it does not matter for code gen reasons: _8 = (unsigned int) x_5(D); _9 = (unsigned int) y_6(D); _10 = _8 | _9; _11 = (unsigned int) a_4(D); _12 = _10 & _11; _13 = _12 != 0;
[Bug tree-optimization/45861] Possible missed optimization - array ops vs shift-and-mask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45861 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2012-02-03 00:00:00 |2021-6-2 --- Comment #3 from Andrew Pinski --- One way of fixing this is making bswap pass really a generic permute pass and then use the vector if it was not a bswap.
[Bug middle-end/38126] suboptimal code for (a && b || !a && !b)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38126 --- Comment #5 from Andrew Pinski --- For the original testcase with GCC 7, we get the same(similar enough) code gen for both functions now. foo: .LFB0: .cfi_startproc testq %rdi, %rdi setne %al testq %rsi, %rsi sete%dl xorl%edx, %eax movzbl %al, %eax ret bar: .LFB1: .cfi_startproc testq %rdi, %rdi sete%al testq %rsi, %rsi setne %dl xorl%edx, %eax movzbl %al, %eax ret
[Bug tree-optimization/27504] x && (x & y) not optimized to x & y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27504 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2012-01-04 00:00:00 |2021-6-2 --- Comment #3 from Andrew Pinski --- Confirmed again. So looking at the IR, it took until PHI-OPT4 to be able to convert it into: [local count: 1073741824]: if (x_3(D) != 0) goto ; [50.00%] else goto ; [50.00%] [local count: 536870913]: _1 = x_3(D) & 85; _5 = _1 != 0; _6 = (int) _5; [local count: 1073741824]: # iftmp.0_2 = PHI <_6(3), 0(2)>
[Bug testsuite/100749] [12 regression] gcc.dg/pch/valid-1.c fails after r12-949
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100749 seurer at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from seurer at gcc dot gnu.org --- Everything is working now.
[Bug tree-optimization/39870] VRP can't see through cast to unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39870 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2009-04-23 15:54:45 |2021-6-2 --- Comment #16 from Andrew Pinski --- apinski@xeond:~/src/upstream-gcc$ ~/upstream-gcc/bin/gcc -O2 t8.c -S -include stdlib.h -o - |grep abort apinski@xeond:~/src/upstream-gcc$ ~/upstream-gcc/bin/gcc -O2 t8.c -S -include stdlib.h -o - -DBORKED |grep abort callabort
[Bug middle-end/36384] folding of conversion for BOOLEAN_TYPE or ENUMERAL_TYPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36384 --- Comment #2 from Andrew Pinski --- during VRP1 removes the casts now. So I don't know if this bug should be closed as fixed or not.
[Bug target/100865] Convert CONST_WIDE_INT to broadcast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100865 --- Comment #5 from H.J. Lu --- A small benchmark: https://gitlab.com/x86-benchmarks/microbenchmark/-/tree/memset/broadcast shows that broadcast is a little bit faster on Intel Core i7-8559U: [hjl@gnu-cfl-2 microbenchmark]$ make gcc -g -I. -O2 -c -o test.o test.c gcc -g -c -o memory.o memory.S gcc -g -c -o broadcast.o broadcast.S gcc -o test test.o memory.o broadcast.o ./test memory : 99333 broadcast: 97208 [hjl@gnu-cfl-2 microbenchmark]$
[Bug c++/94492] no way to silence -Wdeprecated-copy for aggregates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94492 --- Comment #2 from Nikita Kniazev --- Could this be backported? The issue affects every release with -Wdeprecated-copy, which are GCC 9+.
[Bug target/45548] Add with carry - missed optimization on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45548 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Andrew Pinski --- This is all fixed in GCC 11 at least.
[Bug target/43892] PowerPC suboptimal "add with carry" optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
--- Comment #32 from Andrew Pinski ---
(In reply to Richard Biener from comment #5)
> No.
>
> Actually compilable testcase:
>
> typedef unsigned int u32;
>
> u32
> add32carry(u32 sum, u32 x)
> {
> u32 z = sum + x;
> if (sum + x < x)
> z++;
> return z;
> }
>
> u32
> loop(u32 *buf, int len)
> {
> u32 sum = 0;
> for(; len; --len)
> sum = add32carry(sum, *++buf);
> return sum;
> }
Note on the trunk this code is recognized at least on the gimple level as add
with overflow and does:
_7 = .ADD_OVERFLOW (sum_2(D), x_3(D));
z_4 = REALPART_EXPR <_7>;
_8 = IMAGPART_EXPR <_7>;
if (_8 != 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 536870913]:
z_5 = z_4 + 1;
[local count: 1073741824]:
# z_1 = PHI
CUT ---
So it is more about the back-end of PowerPC at this point.
[Bug target/100865] Convert CONST_WIDE_INT to broadcast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100865 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||wwwhhhyyy333 at gmail dot com Ever confirmed|0 |1 Version|11.1.1 |12.0 Summary|pass_data_constant_pool_bro |Convert CONST_WIDE_INT to |adcast doesn't work on |broadcast |TImode | Last reconfirmed||2021-06-03 --- Comment #4 from H.J. Lu --- Please try this patch with SPEC CPU 2017 on SKX to see its impact on performance.
[Bug target/100865] pass_data_constant_pool_broadcast doesn't work on TImode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100865 --- Comment #3 from H.J. Lu --- Created attachment 50916 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50916&action=edit x86: Convert CONST_WIDE_INT to broadcast in move expanders
[Bug target/35646] gcc is not using the overflow flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35646 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.0 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Andrew Pinski --- Fixed in GCC 11 at least. add: movl%edi, %eax addl%esi, %eax jc .L10 ret .L10: pushq %rax xorl%edi, %edi callexit .cfi_endproc .LFE13: .size add, .-add .p2align 4 .globl addto .type addto, @function addto: addl%esi, (%rdi) jc .L18 ret .L18: subq$8, %rsp xorl%edi, %edi callexit CUT Note GCC 7 almost gets it right for both add: addl%esi, %edi jc .L10 movl%edi, %eax ret .L10: subq$8, %rsp xorl%edi, %edi callexit@PLT addto: xorl%eax, %eax addl(%rdi), %esi setc%al movl%esi, (%rdi) testl %eax, %eax jne .L18 rep ret .L18: subq$8, %rsp xorl%edi, %edi callexit@PLT
[Bug testsuite/100407] New test cases attr-retain-*.c fail after their introduction in r11-7284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100407 H.J. Lu changed: What|Removed |Added Attachment #50914|0 |1 is obsolete|| --- Comment #7 from H.J. Lu --- Created attachment 50915 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50915&action=edit attr-retain-1.s Here is my attr-retain-1.s compiled with -O0. Please upload yours.
[Bug testsuite/100407] New test cases attr-retain-*.c fail after their introduction in r11-7284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100407 --- Comment #6 from H.J. Lu --- Created attachment 50914 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50914&action=edit attr-retain-1.s Here is my attr-retain-1.s. Please upload your attr-retain-1.s.
[Bug testsuite/100407] New test cases attr-retain-*.c fail after their introduction in r11-7284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100407 --- Comment #5 from H.J. Lu --- I can't reproduce it with GCC master, glibc 2.33 and binutils 2.36 branch.
[Bug rtl-optimization/10945] Trivial Bit Twiddling Optimizations Not Performed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10945 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |7.0 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Andrew Pinski --- simple2.c and revised2.c produce the same code for a while now: x: movl12(%esp), %edx movl8(%esp), %eax xorl%edx, %eax andl4(%esp), %eax xorl%edx, %eax ret y: movl12(%esp), %edx movl8(%esp), %eax xorl%edx, %eax andl4(%esp), %eax xorl%edx, %eax ret .cfi_endproc CUT as for simple.c and revised.c: f: .LFB0: .cfi_startproc movl8(%esp), %edx movl12(%esp), %ecx movl%edx, %eax andl%ecx, %edx orl %ecx, %eax andl4(%esp), %eax orl %edx, %eax ret g: movl4(%esp), %edx movl8(%esp), %ecx movl%edx, %eax andl%ecx, %edx orl %ecx, %eax andl12(%esp), %eax orl %edx, %eax ret I am going to close it as fixed for GCC 7 (even though it has been fixed maybe long before that).
[Bug tree-optimization/20083] Missed optimization with conditional and basically ||
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20083 Andrew Pinski changed: What|Removed |Added Depends on||96923 --- Comment #5 from Andrew Pinski --- Looks like only f is broken now. in phiopt3: _8 = i_4(D) != 0; _9 = (int) _8; if (j_5(D) != 0) goto ; [50.00%] else goto ; [50.00%] [local count: 536870913]: [local count: 1073741824]: # k_2 = PHI <_9(2), 1(3)> if (l_6(D) != 0) goto ; [50.00%] else goto ; [50.00%] [local count: 536870913]: [local count: 1073741824]: # k_3 = PHI Hmm, this looks like it could be fixed with PR 96923. I will test it again once I fix that one. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96923 [Bug 96923] Failure to optimize a select-related bool pattern to or+not
[Bug target/95967] Poor aarch64 vector constructor code when using arm_neon.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95967 Andrew Pinski changed: What|Removed |Added Depends on||93237 --- Comment #5 from Andrew Pinski --- f1 is really PR 93237. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93237 [Bug 93237] vector defined using inserts is not converted into constructors
[Bug tree-optimization/52254] VRP does not fold (~a) & N to a ^ N if a has range [0, N]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52254 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |7.0 --- Comment #4 from Andrew Pinski --- Was fixed with r7-820 which adds the pattern to match.pd.
[Bug gcov-profile/100788] Internal compiler error related to #line macros(?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100788 --- Comment #11 from seberg --- Does that mean that fixing the `#line` directives (or inserting additional ones) should be able to fix the issue? (Or work around it, if you consider it a bug.) I tried to figure out where the `#line` directives currently causes this situation, and add new ones in some places in the templater. But I don't really see where it goes wrong. That is, unless `#if 0` causes the directives within the block to be ignored?
[Bug target/100736] ICE: unrecognizable insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100736 Segher Boessenkool changed: What|Removed |Added Last reconfirmed||2021-06-03 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Segher Boessenkool --- Confirmed. Happens at expand time already.
[Bug target/100703] __vector_pair and __vector_quad cannot be passed by reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100703 --- Comment #2 from Segher Boessenkool --- This compiles just fine for me, even with -O0. Does this only happen with some older version of the compiler? Are some special flags needed?
[Bug tree-optimization/100883] ifcombine should use (gimple) match and simplify instead of fold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100883 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |10.0
[Bug tree-optimization/100883] ifcombine should use (gimple) match and simplify instead of fold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100883 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Actually I did not realize it was already done for GCC 10. Blah.
[Bug testsuite/100407] New test cases attr-retain-*.c fail after their introduction in r11-7284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100407 --- Comment #4 from seurer at gcc dot gnu.org --- It does not fail on LE.
[Bug tree-optimization/100858] Simple common code hoisting is not performed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100858
--- Comment #2 from Nikita Kniazev ---
(In reply to Richard Biener from comment #1)
> That's really a duplicate of 100858 - this case can be handled by sinking as
> well
> since we "sink" the return. Make it
>
> void bar();
>
> int foo(bool f)
> {
> if (f) {
> bar();
> __builtin_abort ();
> }
> else {
> bar();
> return 2;
> }
> }
> to force hoisting.
I have a hard time in finding this as equivalent to the original code.
> Hoisting is done by PRE but that requires a LHS and doesn't handle calls with
> side-effects.
That seems like an artificial limitation. Why we cannot hoist the bar call?
[Bug rtl-optimization/98777] [11 Regression] ICE in update_equiv at gcc/lra-constraints.c:504 since r11-6819-g4334b52427420312
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98777 --- Comment #7 from CVS Commits --- The releases/gcc-10 branch has been updated by Przemyslaw Wirkus : https://gcc.gnu.org/g:05f6971ac40912ef062915f88b3ea0bf27278285 commit r10-9882-g05f6971ac40912ef062915f88b3ea0bf27278285 Author: Vladimir N. Makarov Date: Thu Jan 21 17:27:01 2021 -0500 [PR98777] LRA: Use preliminary created pseudo for in LRA elimination subpass LRA did not extend ira_reg_equiv after generation of a pseudo in eliminate_regs_in_insn which might results in LRA crash. It is better not to extend ira_reg_equiv but to use preliminary generated pseudo. The patch implements it. gcc/ChangeLog: PR rtl-optimization/98777 * lra-int.h (lra_pmode_pseudo): New extern. * lra.c (lra_pmode_pseudo): New global. (lra): Set it up. * lra-eliminations.c (eliminate_regs_in_insn): Use it. gcc/testsuite/ChangeLog: PR rtl-optimization/98777 * gcc.target/riscv/pr98777.c: New. (cherry picked from commit 68ba1039c7daf0485b167fe199ed7e8031158091)
[Bug rtl-optimization/98722] [11 Regression] ICE in lra_set_insn_recog_data, at lra.c:1004 since r11-6615-gcf2ac1c30af0fa783c8d72e527904dda5d8cc330
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98722 --- Comment #8 from CVS Commits --- The releases/gcc-10 branch has been updated by Przemyslaw Wirkus : https://gcc.gnu.org/g:1791b11d9cae388ae18a768eeb96c998439c986a commit r10-9881-g1791b11d9cae388ae18a768eeb96c998439c986a Author: Vladimir N. Makarov Date: Wed Jan 20 11:40:14 2021 -0500 [PR98722] LRA: Check that target has no 3-op add insn to transform 2 plus expression. Patch cf2ac1c30af0fa783c8d72e527904dda5d8cc330 for solving PR97969 was assumed for targets with absent 3-op add insn. But the original patch did not check this. This patch adds the check. gcc/ChangeLog: PR rtl-optimization/98722 * lra-eliminations.c (eliminate_regs_in_insn): Check that target has no 3-op add insn to transform insns containing two pluses. gcc/testsuite/ChangeLog: PR rtl-optimization/98722 * g++.target/s390/pr98722.C: New. (cherry picked from commit 4334b524274203125193a08a8485250c41c2daa9)
[Bug target/97969] [9/10 Regression][ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969 --- Comment #27 from CVS Commits --- The releases/gcc-10 branch has been updated by Przemyslaw Wirkus : https://gcc.gnu.org/g:eb13f3f81d56910626529af52e03e74770ffca98 commit r10-9880-geb13f3f81d56910626529af52e03e74770ffca98 Author: Vladimir N. Makarov Date: Tue Jan 12 11:26:15 2021 -0500 [PR97969] LRA: Transform pattern `plus (plus (hard reg, const), pseudo)` after elimination LRA can loop infinitely on targets without `reg + imm` insns. Register elimination on such targets can increase register pressure resulting in permanent stack size increase and changing elimination offset. To avoid such situation, a simple transformation can be done to avoid register pressure increase after generating reload insns containing eliminated hard regs. gcc/ChangeLog: PR target/97969 * lra-eliminations.c (eliminate_regs_in_insn): Add transformation of pattern 'plus (plus (hard reg, const), pseudo)'. gcc/testsuite/ChangeLog: PR target/97969 * gcc.target/arm/pr97969.c: New. (cherry picked from commit cf2ac1c30af0fa783c8d72e527904dda5d8cc330)
[Bug middle-end/100876] -Wmismatched-new-delete should understand placement new when it's not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100876 Martin Sebor changed: What|Removed |Added Keywords||patch Target Milestone|--- |11.2 --- Comment #2 from Martin Sebor --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571777.html
[Bug c/100888] New: ICE: symtab_node::verify failed, symtab_node::verify()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100888
Bug ID: 100888
Summary: ICE: symtab_node::verify failed, symtab_node::verify()
Product: gcc
Version: tree-ssa
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: cnsun at uwaterloo dot ca
Target Milestone: ---
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.2G3KkJkZyC-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-checking-yes --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210602 (experimental) [master revision
:5b6bc0f6e:b75978d14fc35981ffd8bf060ee52300db4dae50] (GCC)
$ cat mutant.c
register __sys_res asm("r10");
r10() {}
$ gcc-trunk mutant.c
mutant.c:1:10: warning: type defaults to ‘int’ in declaration of ‘__sys_res’
[-Wimplicit-int]
1 | register __sys_res asm("r10");
| ^
mutant.c:1:10: warning: call-clobbered register used for global register
variable
mutant.c:2:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
2 | r10() {}
| ^~~
mutant.c:2:1: error: assembler name hash list corrupted
*r10/0 (__sys_res) @0x7f5bf87f5000
Type: variable definition analyzed
Visibility: force_output no_reorder public
References:
Referring:
Availability: not-ready
Varpool flags:
mutant.c:2:1: internal compiler error: symtab_node::verify failed
0xa717c9 symtab_node::verify()
/tmp/tmp.2G3KkJkZyC-gcc-builder/gcc/gcc/symtab.c:1361
0xa717c9 symtab_node::verify()
/tmp/tmp.2G3KkJkZyC-gcc-builder/gcc/gcc/symtab.c:1349
0xa72a27 symtab_node::verify_symtab_nodes()
/tmp/tmp.2G3KkJkZyC-gcc-builder/gcc/gcc/symtab.c:1384
0xa88b04 symtab_node::checking_verify_symtab_nodes()
/tmp/tmp.2G3KkJkZyC-gcc-builder/gcc/gcc/cgraph.h:678
0xa88b04 symbol_table::compile()
/tmp/tmp.2G3KkJkZyC-gcc-builder/gcc/gcc/cgraphunit.c:2272
0xa8b7db symbol_table::compile()
/tmp/tmp.2G3KkJkZyC-gcc-builder/gcc/gcc/cgraphunit.c:2269
0xa8b7db symbol_table::finalize_compilation_unit()
/tmp/tmp.2G3KkJkZyC-gcc-builder/gcc/gcc/cgraphunit.c:2537
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[Bug fortran/100194] [9/10/11/12 Regression] ICE in gfc_trans_create_temp_array, at fortran/trans-array.c:1351
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100194 --- Comment #4 from anlauf at gcc dot gnu.org --- We are hitting the assert 1351 gcc_assert (ss->dimen > 0); in gfc_trans_create_temp_array which does not handle assumed rank yet. (here ss->dimen = -1).
[Bug testsuite/100749] [12 regression] gcc.dg/pch/valid-1.c fails after r12-949
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100749 Bill Schmidt changed: What|Removed |Added CC||wschmidt at gcc dot gnu.org --- Comment #4 from Bill Schmidt --- @seurer, is this working now? Can it be closed?
[Bug target/100706] Invalid instructions in plt calls on PPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100706 Bill Schmidt changed: What|Removed |Added CC||wschmidt at gcc dot gnu.org Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #4 from Bill Schmidt --- Sorry, just now saw this...closing.
[Bug rtl-optimization/100264] REE does not work on PARALLEL expressions with a single register SET child
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100264 Jim Wilson changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||wilson at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from Jim Wilson --- Fixed on mainline.
[Bug rtl-optimization/100264] REE does not work on PARALLEL expressions with a single register SET child
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100264 --- Comment #2 from CVS Commits --- The master branch has been updated by Jim Wilson : https://gcc.gnu.org/g:d5ba2eaf7032f234fdcf11d9cfc513ce7be0a255 commit r12-1168-gd5ba2eaf7032f234fdcf11d9cfc513ce7be0a255 Author: Christoph Muellner Date: Mon May 10 14:39:03 2021 +0200 REE: PR rtl-optimization/100264: Handle more PARALLEL SET expressions Move the check for register targets (i.e. REG_P ()) into the function get_sub_rtx () and change the restriction of REE to "only one child of a PARALLEL expression is a SET register expression" (was "only one child of a PARALLEL expression is a SET expression"). This allows to handle more PARALLEL SET expressions. gcc/ChangeLog: PR rtl-optimization/100264 * ree.c (get_sub_rtx): Ignore SET expressions without register destinations and remove assertion, as it is not valid anymore with this new behaviour. (merge_def_and_ext): Eliminate destination check for register as such SET expressions can't occur anymore. (combine_reaching_defs): Likewise.
[Bug target/100887] New: [12 Regression] ICE: in ix86_expand_vector_init_concat, at config/i386/i386-expand.c:14178 with -mavx512f and __builtin_shufflevector()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100887 Bug ID: 100887 Summary: [12 Regression] ICE: in ix86_expand_vector_init_concat, at config/i386/i386-expand.c:14178 with -mavx512f and __builtin_shufflevector() Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 50913 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50913&action=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -mavx512f testcase.c during RTL pass: expand testcase.c: In function 'foo': testcase.c:6:3: internal compiler error: in ix86_expand_vector_init_concat, at config/i386/i386-expand.c:14178 6 | __builtin_shufflevector (u, v, 0); | ^~~ 0x7ddb42 ix86_expand_vector_init_concat /repo/gcc-trunk/gcc/config/i386/i386-expand.c:14178 0x149cf87 ix86_expand_vector_init(bool, rtx_def*, rtx_def*) /repo/gcc-trunk/gcc/config/i386/i386-expand.c:14622 0x18c32ee ??? /repo/gcc-trunk/gcc/config/i386/sse.md:22289 0xce0ba6 rtx_insn* insn_gen_fn::operator()(rtx_def*, rtx_def*) const /repo/gcc-trunk/gcc/recog.h:407 0xce0ba6 store_constructor /repo/gcc-trunk/gcc/expr.c:7217 0xce2645 expand_constructor /repo/gcc-trunk/gcc/expr.c:8555 0xccea3a expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) /repo/gcc-trunk/gcc/expr.c:10738 0xcdbe6c store_expr(tree_node*, rtx_def*, int, bool, bool) /repo/gcc-trunk/gcc/expr.c:5986 0xcdd62d expand_assignment(tree_node*, tree_node*, bool) /repo/gcc-trunk/gcc/expr.c:5721 0xb97ef1 expand_gimple_stmt_1 /repo/gcc-trunk/gcc/cfgexpand.c:3916 0xb97ef1 expand_gimple_stmt /repo/gcc-trunk/gcc/cfgexpand.c:4014 0xb9e79b expand_gimple_basic_block /repo/gcc-trunk/gcc/cfgexpand.c:6056 0xba06c7 execute /repo/gcc-trunk/gcc/cfgexpand.c:6782 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-1164-20210602094549-g659cc7d6320-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r12-1164-20210602094549-g659cc7d6320-checking-yes-rtl-df-extra-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.0.0 20210602 (experimental) (GCC)
[Bug fortran/100886] New: Variable character pointer within a Fortran derived type can't determine the shape(mold) of the target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100886
Bug ID: 100886
Summary: Variable character pointer within a Fortran derived
type can't determine the shape(mold) of the target
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: thomas.robinson at noaa dot gov
Target Milestone: ---
A character pointer within a Fortran DDT can't determine the shape(mold) of a
variable length allocatable target character array
Desired behavior: DDT pointer behaves like a non-DDT pointer and properly
determines shape(mold) of the target and points to it
Here is some sample code:
program char_ptr_test
implicit none
character(len=:), dimension(:), allocatable, target:: input_nml_file
character(len=:), dimension(:), pointer:: copy_input_nml_file => null()
type init_type
character(len=:), dimension(:), pointer:: input_nml_file => null()
end type init_type
type(init_type):: Init
integer:: i
character(len=6):: arg
logical:: gnu=.false.
!--- parse command line
call get_command_argument(1, arg)
if (len_trim(arg) > 0) print *, trim(arg)
!--- set up input_nml_file and output the result
call init_input()
do i = 1,size(input_nml_file)
print *, 'Main input_nml_file is: "',input_nml_file(i),'"'
enddo
!--- plain pointer - works as expected
print *, NEW_LINE('a'),'plain pointer'
copy_input_nml_file => input_nml_file
do i = 1,size(copy_input_nml_file)
print *, 'copy_input_nml_file is: "',copy_input_nml_file(i),'"'
enddo
nullify(copy_input_nml_file)
!--- pointer within a DDT - fails
!--- point to input_nml_file elements (:)
print *, NEW_LINE('a'),'pointer within fortran ddt @ elements (:)'
Init%input_nml_file => input_nml_file(:)
do i = 1,size(Init%input_nml_file)
print *, 'Init%input_nml_file is: "',Init%input_nml_file(i),'"'
enddo
!--- pointer within a DDT - fails
!--- point to input_nml_file as whole
print *, NEW_LINE('a'),'pointer within fortran ddt @ whole entity'
Init%input_nml_file => input_nml_file
do i = 1,size(Init%input_nml_file)
print *, 'Init%input_nml_file is: "',Init%input_nml_file(i),'"'
enddo
nullify(Init%input_nml_file)
!--- pointer within a DDT - works
!--- point to input_nml_file elements (:)
!--- allocate/deallocate to get shape
print *, NEW_LINE('a'),'pointer within fortran ddt with shape settings @
elements(:)'
allocate(Init%input_nml_file, mold=input_nml_file)
deallocate(Init%input_nml_file)
Init%input_nml_file => input_nml_file(:)
do i = 1,size(Init%input_nml_file)
print *, 'Init%input_nml_file is: "',Init%input_nml_file(i),'"'
enddo
nullify(Init%input_nml_file)
!--- pointer within a DDT - fails with segfault
!--- point to input_nml_file as whole
!--- allocate/deallocate to get shape
print *, NEW_LINE('a'),'pointer within fortran ddt w/ shape settings @ whole
entity'
allocate(Init%input_nml_file, mold=input_nml_file)
deallocate(Init%input_nml_file)
Init%input_nml_file => input_nml_file
do i = 1,size(Init%input_nml_file)
print *, 'Init%input_nml_file is: "',Init%input_nml_file(i),'"'
enddo
nullify(Init%input_nml_file)
contains
subroutine init_input()
allocate(character(len=10)::input_nml_file(7))
input_nml_file(1) = 'New York '
input_nml_file(2) = 'London'
input_nml_file(3) = 'Paris '
input_nml_file(4) = 'Munich'
input_nml_file(5) = 'Everybody '
input_nml_file(6) = 'talk about'
input_nml_file(7) = 'Pop Muzik '
end subroutine init_input
end program char_ptr_test
The behavior is different between 9.3 and 10.2, but the same for 10.2 to 12.0
(at least for the versions that I have available). Please let me know if
there's any other information you need
[Bug target/100885] New: [12 Regression] ICE: in extract_constrain_insn, at recog.c:2671: insn does not satisfy its constraints: {sse4_1_zero_extendv8qiv8hi2}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100885
Bug ID: 100885
Summary: [12 Regression] ICE: in extract_constrain_insn, at
recog.c:2671: insn does not satisfy its constraints:
{sse4_1_zero_extendv8qiv8hi2}
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Created attachment 50912
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50912&action=edit
auto-reduced testcase (from OpenTTD sources)
Compiler output:
$ x86_64-pc-linux-gnu-gcc -O2 -mavx512vl testcase.C
testcase.C: In instantiation of 'void Blitter_32bppSSE4_Anim::Draw(const
Blitter::BlitterParams*, ZoomLevel) [with BlitterMode =
BM_COLOUR_REMAP; Blitter_32bppSSE_Base::ReadMode =
Blitter_32bppSSE_Base::RM_WITH_MARGIN; Blitter_32bppSSE_Base::BlockType
= Blitter_32bppSSE_Base::BT_NONE; bool = true; bool
= false]':
testcase.C:154:62: required from here
testcase.C:120:27: warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]
120 | Colour *src_rgba_line = (Colour *)sd->data;
| ^~
testcase.C:130:19: warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]
130 | int mvX2 = *(unsigned *)sd->infos[zoom], m = byte(mvX2);
| ^~~
testcase.C: In member function 'void Blitter_32bppSSE4_Anim::Draw(const
Blitter::BlitterParams*, ZoomLevel) [with BlitterMode =
BM_COLOUR_REMAP; Blitter_32bppSSE_Base::ReadMode =
Blitter_32bppSSE_Base::RM_WITH_MARGIN; Blitter_32bppSSE_Base::BlockType
= Blitter_32bppSSE_Base::BT_NONE; bool = true; bool
= false]':
testcase.C:150:1: error: insn does not satisfy its constraints:
150 | }
| ^
(insn 295 221 134 12 (set (reg:V8HI 22 xmm2 [230])
(zero_extend:V8HI (vec_select:V8QI (reg:V16QI 52 xmm16 [orig:134
__trans_tmp_5 ] [134])
(parallel [
(const_int 0 [0])
(const_int 1 [0x1])
(const_int 2 [0x2])
(const_int 3 [0x3])
(const_int 4 [0x4])
(const_int 5 [0x5])
(const_int 6 [0x6])
(const_int 7 [0x7])
] "testcase.C":49:46 4653 {sse4_1_zero_extendv8qiv8hi2}
(expr_list:REG_DEAD (reg:V16QI 52 xmm16 [orig:134 __trans_tmp_5 ] [134])
(nil)))
during RTL pass: cprop_hardreg
testcase.C:150:1: internal compiler error: in extract_constrain_insn, at
recog.c:2671
0x7ece3a _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/repo/gcc-trunk/gcc/rtl-error.c:108
0x7ecec7 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/repo/gcc-trunk/gcc/rtl-error.c:118
0x7dbaaf extract_constrain_insn(rtx_insn*)
/repo/gcc-trunk/gcc/recog.c:2671
0x1292534 copyprop_hardreg_forward_1
/repo/gcc-trunk/gcc/regcprop.c:825
0x129383e execute
/repo/gcc-trunk/gcc/regcprop.c:1390
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-1164-20210602094549-g659cc7d6320-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r12-1164-20210602094549-g659cc7d6320-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20210602 (experimental) (GCC)
[Bug c++/100884] New: Comparing unsigned 32 bit integer values generates 64 bit compare instructions when optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100884
Bug ID: 100884
Summary: Comparing unsigned 32 bit integer values generates 64
bit compare instructions when optimized
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mfarazma.ext at gmail dot com
Target Milestone: ---
**0.c**
```
#include
uint32_t codegen();
int main(){
uint32_t expected = (codegen()) != 0 ? -1 : -2;
bool check_eq = expected == codegen();
if (!(check_eq)){
std::cout << "Check failed" << std::endl;
}
return 0;
}
```
**1.cc**
```
#include
uint32_t codegen(){
volatile int64_t a = -1;
return a;
}
```
Compile it with optimization enabled:
g++ -O3 0.cc 1.cc
Checking the generate code shows this instruction is generated for ` if
(!(check_eq)){...}`:
```
cmpdr31,r3
```
Compiling the same code with gcc version 8.4.0 emits this instead which is
correct:
```
cmpwcr7,r3,r31
```
This issue is causing failures as the returned value from `codegen()` may not
have its upper 32 bits cleared and using `cmpd` on it will create the wrong
output.
[Bug target/100841] xtensa-linux: dwarf2cfi.c:291:12: error: comparison of integer expressions of different signedness: 'const unsigned int' and 'int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100841 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:50b1de860a58bf85b40a72219bc2fdfaf0dff355 commit r12-1167-g50b1de860a58bf85b40a72219bc2fdfaf0dff355 Author: Jakub Jelinek Date: Wed Jun 2 22:09:53 2021 +0200 xtensa: Fix 2 warnings during xtensa build [PR100841] When building gcc targetting xtensa-linux, there are 2 warnings the PR complains about: ../../gcc/dwarf2cfi.c: In function âvoid init_one_dwarf_reg_size(int, machine_mode, rtx, machine_mode, init_one_dwarf_reg_state*)â: ../../gcc/dwarf2cfi.c:291:12: warning: comparison of integer expressions of different signedness: âconst unsigned intâ and âintâ [-Wsign-compare] 291 | if (rnum >= DWARF_FRAME_REGISTERS) ../../gcc/function.c: In function âvoid gen_call_used_regs_seq(rtx_insn*, unsigned int)â: ../../gcc/function.c:5897:63: warning: comparison of unsigned expression in â< 0â is always false [-Wtype-limits] 5897 | if (crtl->uses_only_leaf_regs && LEAF_REG_REMAP (regno) < 0) which might during bootstrap or when configured with --enable-werror-always be turned into errors. The first one is the -Wsign-compare warning, in c-family we do: 2281 /* Do not warn if the signed quantity is an unsuffixed integer 2282 literal (or some static constant expression involving such 2283 literals or a conditional expression involving such literals) 2284 and it is non-negative. */ 2285 if (tree_expr_nonnegative_warnv_p (sop, &ovf)) 2286/* OK */; and so don't warn if that function determines the expression is non-negative. But xtensa defines DWARF_FRAME_REGISTERS as (16 + (something ? 0 : 1)) and that isn't handled by tree_expr_nonnegative_warnv_p, VRP can handle it of course, but that is much later. The second chunk rewrites it into a form that tree_expr_nonnegative_warnv_p can handle, in particular (something ? 16 : 16 + 1), where for COND_EXPRs that function checks both the 2nd and 3rd operand of the ternary operator and if both are nonnegative, returns true. The other warning has been introduced fairly recently; LEAF_REG_REMAP is currently used by 2 targets only, and is documented to yield -1 if a hard reg number can't be remapped and the remapped register number otherwise. That means that the type of the expression should be signed (otherwise -1 could never appear), and on SPARC indeed it is defined as extern char leaf_reg_remap[]; #define LEAF_REG_REMAP(REGNO) (leaf_reg_remap[REGNO]) so unless the host is -funsigned-char by default it works fine. I guess sparc.[ch] should be fixed to use signed char of leaf_reg_remap, Eric? The argument to LEAF_REG_REMAP is often unsigned int though, hard register numbers are usually not negative, and thus the warning. I think xtensa doesn't have 2G hard registers and so it is ok to just cast it to int. 2021-06-02 Jakub Jelinek PR target/100841 * config/xtensa/xtensa.h (LEAF_REG_REMAP): Cast REGNO to int to avoid -Wtype-limits warnings. (DWARF_FRAME_REGISTER): Rewrite into ternary operator with addition in operands to avoid -Wsign-compare warnings.
[Bug sanitizer/71458] ICE with -fsanitize=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71458
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment #9 from Harald van Dijk ---
I know the GCC 5 branch is long closed and this will not be fixed, but for
completeness, the backport to GCC 5 was wrong: error (UNKNOWN_LOCATION, "...")
should have been error ("..."). error (UNKNOWN_LOCATION, "...") compiles but
does the wrong thing: UNKNOWN_LOCATION is interpreted as a null pointer format
string and causes a segfault.
[Bug testsuite/100407] New test cases attr-retain-*.c fail after their introduction in r11-7284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100407
--- Comment #3 from H.J. Lu ---
(In reply to seurer from comment #2)
> I got it to fail on the gcc110 gcc farm machine.
>
> g:659cc7d6320aae7ab390b5886f0efed22f78e244, r12-1164
> make -k check-gcc RUNTESTFLAGS="--target_board=unix'{-m32}'
> compile.exp=gcc.c-torture/compile/attr-retain-1.c"
> FAIL: gcc.c-torture/compile/attr-retain-1.c -O0 scan-assembler
> .rodata.*,"aR"
> FAIL: gcc.c-torture/compile/attr-retain-1.c -O1 scan-assembler
> .rodata.*,"aR"
> FAIL: gcc.c-torture/compile/attr-retain-1.c -O2 scan-assembler
> .rodata.*,"aR"
> FAIL: gcc.c-torture/compile/attr-retain-1.c -O3 -g scan-assembler
> .rodata.*,"aR"
> FAIL: gcc.c-torture/compile/attr-retain-1.c -Os scan-assembler
> .rodata.*,"aR"
> FAIL: gcc.c-torture/compile/attr-retain-1.c -O2 -flto
> -fno-use-linker-plugin -flto-partition=none scan-assembler .rodata.*,"aR"
> FAIL: gcc.c-torture/compile/attr-retain-1.c -O2 -flto -fuse-linker-plugin
> -fno-fat-lto-objects scan-assembler .rodata.*,"aR"
> # of expected passes 35
> # of unexpected failures 7
>
> I did have to use my own binutils (2.36.1) or the test came up as
> unsupported.
Does it fail on LE?
[Bug testsuite/100407] New test cases attr-retain-*.c fail after their introduction in r11-7284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100407
--- Comment #2 from seurer at gcc dot gnu.org ---
I got it to fail on the gcc110 gcc farm machine.
g:659cc7d6320aae7ab390b5886f0efed22f78e244, r12-1164
make -k check-gcc RUNTESTFLAGS="--target_board=unix'{-m32}'
compile.exp=gcc.c-torture/compile/attr-retain-1.c"
FAIL: gcc.c-torture/compile/attr-retain-1.c -O0 scan-assembler
.rodata.*,"aR"
FAIL: gcc.c-torture/compile/attr-retain-1.c -O1 scan-assembler
.rodata.*,"aR"
FAIL: gcc.c-torture/compile/attr-retain-1.c -O2 scan-assembler
.rodata.*,"aR"
FAIL: gcc.c-torture/compile/attr-retain-1.c -O3 -g scan-assembler
.rodata.*,"aR"
FAIL: gcc.c-torture/compile/attr-retain-1.c -Os scan-assembler
.rodata.*,"aR"
FAIL: gcc.c-torture/compile/attr-retain-1.c -O2 -flto -fno-use-linker-plugin
-flto-partition=none scan-assembler .rodata.*,"aR"
FAIL: gcc.c-torture/compile/attr-retain-1.c -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects scan-assembler .rodata.*,"aR"
# of expected passes35
# of unexpected failures7
I did have to use my own binutils (2.36.1) or the test came up as unsupported.
[Bug tree-optimization/100883] New: ifcombine should use (gimple) match and simplify instead of fold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100883 Bug ID: 100883 Summary: ifcombine should use (gimple) match and simplify instead of fold Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- Like PHI-OPT, ifcombine was written before match and simplify was around so it calls fold_build* to do the folding of the if statements. It would be better if it calls gimple_simplify instead of doing the gimplification manually.
[Bug middle-end/19987] [meta-bug] fold missing optimizations in general
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987 Bug 19987 depends on bug 96674, which changed state. Bug 96674 Summary: Failure to optimize combination of comparisons to dec+compare https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96674 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/96674] Failure to optimize combination of comparisons to dec+compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96674 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED CC||law at gcc dot gnu.org Resolution|--- |FIXED --- Comment #11 from Jeffrey A. Law --- Resolved by Eugene's patch on the trunk.
[Bug d/100882] New: ICE in gimplify_var_or_parm_decl, at gimplify.c:2755
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100882
Bug ID: 100882
Summary: ICE in gimplify_var_or_parm_decl, at gimplify.c:2755
Product: gcc
Version: 9.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
Reduced test, adapted to make clear what the correct behaviour should be after
the ICE is fixed.
---
__gshared int counter = 0;
struct S
{
this(int) { counter++; }
~this() { counter++; }
}
static S s;
static this()
{
s = cast(shared) S(0);
assert(counter == 2);
}
---
Reproducible from gdc-9 onwards.
[Bug c++/100881] New: [c++ modules][possible bug?] default arguments break when the default argument's type isn't explicitly included/exported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100881
Bug ID: 100881
Summary: [c++ modules][possible bug?] default arguments break
when the default argument's type isn't explicitly
included/exported
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: evanc.github at gmail dot com
Target Milestone: ---
Created attachment 50911
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50911&action=edit
Preprocessed output of foo.cc
GCC Version / steps to reproduce:
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/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 --enable-plugin
--enable-initfini-array
--with-isl=/builddir/build/BUILD/gcc-11.1.1-20210428/obj-x86_64-redhat-linux/isl-install
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-gnu-indirect-function --enable-cet --with-tune=generic
--with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.1.1 20210428 (Red Hat 11.1.1-1) (GCC)
$ cat foo.cc
module;
#include
export module foo;
export void log(const std::source_location& loc =
std::source_location::current()) {
//
}
$ cat main.cc
import foo;
int main() {
log();
}
$ g++ -fmodules-ts -std=c++20 -c foo.cc -o foo.o
$ g++ -fmodules-ts -std=c++20 main.cc foo.o
main.cc: In function ‘int main()’:
main.cc:4:8: error: ‘source_location’ is not a member of ‘std’
4 | log();
| ~~~^~
main.cc:1:1: note: ‘std::source_location’ is defined in header
‘’; did you forget to ‘#include ’?
+++ |+#include
1 | import foo;
main.cc:4:8: note: evaluating ‘__builtin_source_location’
4 | log();
| ~~~^~
In file included from foo.cc:2,
of module foo, imported at main.cc:1:
main.cc:4:8: in ‘constexpr’ expansion of
‘std::source_location@foo::current(0)’
/usr/include/c++/11/source_location:54:23: error: cast from ‘const void*’ is
not allowed
54 | __ret._M_impl = static_cast (__p);
|
=
Apologies if this isn't actually a bug, but it seemed to be.
This error disappears when is included in main.cc or `export
import ).
[Bug middle-end/100880] New: The build should error out for define_insn without insn template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100880 Bug ID: 100880 Summary: The build should error out for define_insn without insn template Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: ubizjak at gmail dot com Target Milestone: --- Currently, the build allows define_insn RTX without insn template. It would be nice to detect this invalid RTX and error out during build. This would help to avoid thinkos like: -(define_insn "abs2" +(define_expand "abs2" [(set (match_operand:MMXMODEI 0 "register_operand") (abs:MMXMODEI (match_operand:MMXMODEI 1 "register_operand")))] "TARGET_MMX_WITH_SSE && TARGET_SSSE3") which worked only by luck due to the shadowing of the insn above this one. The documentation does not say that insn template can be optional in the define_insn RTX.
[Bug c++/100838] [11/12 Regression] -fno-elide-constructors for C++14 missing required destructor call since r11-5872-g4eb28483004f8291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100838 --- Comment #3 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:63d182b29306e582bfb151cf762820211ea1cc7e commit r12-1165-g63d182b29306e582bfb151cf762820211ea1cc7e Author: Jason Merrill Date: Mon May 31 12:36:25 2021 -0400 c++: missing dtor with -fno-elide-constructors [PR100838] tf_no_cleanup only applies to the outermost TARGET_EXPR, and we already clear it for nested calls in build_over_call, but in this case both constructor calls came from convert_like, so we need to clear it in the recursive call as well. This revealed that we were adding an extra ck_rvalue in direct-initialization cases where it was wrong. PR c++/100838 gcc/cp/ChangeLog: * call.c (convert_like_internal): Clear tf_no_cleanup when recursing. (build_user_type_conversion_1): Only add ck_rvalue if LOOKUP_ONLYCONVERTING. gcc/testsuite/ChangeLog: * g++.dg/init/no-elide2.C: New test.
[Bug middle-end/100876] -Wmismatched-new-delete should understand placement new when it's not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100876 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org
[Bug middle-end/100876] -Wmismatched-new-delete should understand placement new when it's not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100876 Martin Sebor changed: What|Removed |Added Blocks||100406 Known to fail||11.1.0 Summary|-Wmismatched-new-delete |-Wmismatched-new-delete |should either look through |should understand placement |or ignore placement new |new when it's not inlined CC||msebor at gcc dot gnu.org Component|c++ |middle-end --- Comment #1 from Martin Sebor --- [Please include all the information we ask for in the bug report, including the command line options and the full test cases: https://gcc.gnu.org/bugs/#need] The test case behaves as expected when the placement new is inlined, either with optimization or when the operator is declared with attribute always_inline: inline __attribute__ ((__always_inline__)) void* operator new (__SIZE_TYPE__, void*); The problem is a general one, not specific to -Wmismatched-new-delete: GCC understands the semantics of built-in functions, including whether they return one of their arguments, but not user-defined ones. Even though it's special, GCC treats placement new as an ordinary user-defined function. Because nothing indicates the operator returns its pointer argument, no logic in GCC can determine that unless the operator is inlined. The fix is to either hardcode into GCC the knowledge of placement new, or provide an attribute for users (and the standard library) to indicate that a function returns one of its argument. The former might be suitable for GCC 11 as a bug fix for this warning, the latter is something I'd like to do in GCC 12 regardless. Let me work on the former and plan on looking into the latter in the future. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100406 [Bug 100406] bogus/missing -Wmismatched-new-delete
[Bug c++/100879] New: gcc is complaining of a signed compare when comparing enums of different types (same underlying type)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100879
Bug ID: 100879
Summary: gcc is complaining of a signed compare when comparing
enums of different types (same underlying type)
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: andre at kostur dot net
Target Milestone: ---
With the following test code:
enum e1 { e1val };
enum e2 { e3val };
int main( int, char * [] ) {
if ( e1val == e3val ) return 1;
}
The compiler emits two warnings:
: In function 'int main(int, char**)':
:6:15: warning: comparison between 'enum e1' and 'enum e2'
[-Wenum-compare]
6 |if ( e1val == e3val ) return 1;
| ~~^~~~
:6:15: warning: comparison between types 'e1' and 'e2' [-Wsign-compare]
The first is correct, but the second warning seems wrong. There is no sign
mismatch as both enums would have the same underlying type.
gcc 9.3 does not seem to suffer this problem. gcc 10.1 does, and appears every
version up to at least 11.1 does. (Checked on compiler-explorer)
[Bug fortran/100855] pow run time gfortran vs ifort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100855 --- Comment #6 from Dominique d'Humieres --- On a MacOS, Corei9, 2.4Ghz, the program runs in ~1s, almost indpendtly of the option level. This PR remind me an old problem in which the transcendental functions were almost slower for REAL(4) then for REAL(8) on some Unix distros (Fedora(?), based of "correct rounding"). What are your timings if you replace real :: sum, n, q with real(8) :: sum, n, q and sum = sum + (i ** (0.05 + n)) with sum = sum + (i ** (0.05_8 + n)) ?
[Bug c++/100825] function signature constraints are not a part of mangled name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100825 TC changed: What|Removed |Added CC||rs2740 at gmail dot com --- Comment #7 from TC --- I think the code is valid; it's just that the ABI doesn't have a mangling for constraints yet: https://github.com/itanium-cxx-abi/cxx-abi/issues/24
[Bug sanitizer/100878] New: enabling UBSAN leads to false positive `'this' pointer is null` when casting lambda to function pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100878
Bug ID: 100878
Summary: enabling UBSAN leads to false positive `'this' pointer
is null` when casting lambda to function pointer
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: mail at milianw dot de
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
```
const auto lambda = [](int i) -> int { return i + 1; };
using Callback = int (*)(int);
int run(Callback callback, int i)
{
return callback(i);
}
int main()
{
return run(lambda, 52);
}
```
compile with `-g -Og -fsanitize=undefined -Wall -Werror -Wpedantic -Wextra`
leads to:
```
: In static member function 'static constexpr
int::_FUN(int)':
:1:54: error: 'this' pointer is null [-Werror=nonnull]
1 | const auto lambda = [](int i) -> int { return i + 1; };
| ^
:1:21: note: in a call to non-static member function ''
1 | const auto lambda = [](int i) -> int { return i + 1; };
| ^
cc1plus: all warnings being treated as errors
Compiler returned: 1
```
see also: https://godbolt.org/z/jTYYWbMsz
[Bug c++/100592] Bogus "qualifiers cannot be applied" error with reference type produced by dependent alias template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100592 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
[Bug target/100808] PPC: ISA 3.1 builtin documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100808 --- Comment #3 from Jens Seifert --- - Avoid additional "int" unsigned long long int => unsigned long long Why? Those are exactly the same types! Yes, but the rest of the documentation uses unsigned long long. This is just for consistency with existing documentation.
[Bug target/100808] PPC: ISA 3.1 builtin documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100808 --- Comment #2 from Segher Boessenkool --- (In reply to Jens Seifert from comment #0) > - Avoid additional "int" unsigned long long int => unsigned long long Why? Those are exactly the same types! > - add missing line breaks between builtins > - remove semicolons Patches welcome. Comment 1 is a separate issue, please use a different bug to track that.
[Bug target/100868] PPC: Inefficient code for vec_reve(vector double)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100868 Segher Boessenkool changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-06-02 Severity|normal |enhancement Status|UNCONFIRMED |NEW --- Comment #1 from Segher Boessenkool --- Confirmed.
[Bug c++/100876] -Wmismatched-new-delete should either look through or ignore placement new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100876 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2021-06-02 Ever confirmed|0 |1 Keywords||diagnostic Status|UNCONFIRMED |NEW
[Bug c++/100877] New: g++ freezes system by consuming infinite amount of memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100877 Bug ID: 100877 Summary: g++ freezes system by consuming infinite amount of memory Product: gcc Version: 11.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: wang_feng at live dot com Target Milestone: --- Created attachment 50910 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50910&action=edit The preprocessed source code to reproduce the problem. g++ tends to allocate infinite amount of memory while compiling this program. 1. g++ version: Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl --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-install-libiberty --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch --disable-libunwind-exceptions --disable-werror gdc_include_dir=/usr/include/dlang/gdc Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.1.0 (GCC) 2. compile command (dcgan.cc is attached with this report): g++ -c -std=c++20 -Wall -Wextra -fmax-errors=1 -ftemplate-backtrace-limit=0 -fdata-sections -ffunction-sections -funsafe-math-optimizations -fconcepts-diagnostics-depth=4 -ftemplate-depth=100860 -Ofast -flto -pipe -march=native ./dcgan.cc 3. host system: Arch Linux 5.10.39-1-lts #1 SMP Sat, 22 May 2021 10:57:31 + x86_64 GNU/Linux
[Bug target/100866] PPC: Inefficient code for vec_revb(vector unsigned short) < P9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100866 Segher Boessenkool changed: What|Removed |Added Target|powerpc-*-*-* |powerpc* Severity|normal |enhancement Last reconfirmed||2021-06-02 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Segher Boessenkool --- Confirmed. There are other ways to write this in two insns, but this is probably the cheapest and simplest, and the immediate can be reused potentially.
[Bug testsuite/100750] new test case gcc.target/powerpc/rop-5.c fails on BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100750 Bill Schmidt changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Bill Schmidt --- The LE problems were shown to be an out-of-date assembler, so this is now fixed.
[Bug middle-end/100872] [12 Regression] [OpenMP] internal compiler error: tree check: expected integer_cst, have mult_expr in simd_clone_clauses_extract, at omp-simd-clone.c:253
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100872 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Created attachment 50909 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50909&action=edit gcc12-pr100872.patch Untested fix.
[Bug middle-end/100872] [12 Regression] [OpenMP] internal compiler error: tree check: expected integer_cst, have mult_expr in simd_clone_clauses_extract, at omp-simd-clone.c:253
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100872 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-06-02 Ever confirmed|0 |1 Target Milestone|--- |12.0 Summary|[OpenMP] internal compiler |[12 Regression] [OpenMP] |error: tree check: expected |internal compiler error: |integer_cst, have mult_expr |tree check: expected |in |integer_cst, have mult_expr |simd_clone_clauses_extract, |in |at omp-simd-clone.c:253 |simd_clone_clauses_extract, ||at omp-simd-clone.c:253 --- Comment #2 from Jakub Jelinek --- Started with the PR51577 fix r12-702-g6ab1176667734bd6de20833f8d263c03a418c452
[Bug c++/100876] New: -Wmismatched-new-delete should either look through or ignore placement new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100876 Bug ID: 100876 Summary: -Wmismatched-new-delete should either look through or ignore placement new Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: redbeard0531 at gmail dot com Target Milestone: --- https://godbolt.org/z/KTTMrEGns Example code: free(new (malloc(4)) int()); // Warns but shouldn't delete new (malloc(4)) int(); // Doesn't warn but should output: :5:9: warning: 'void free(void*)' called on pointer returned from a mismatched allocation function [-Wmismatched-new-delete] 5 | free(new (malloc(4)) int()); // Warns but shouldn't | ^~~ :5:30: note: returned from 'void* operator new(std::size_t, void*)' 5 | free(new (malloc(4)) int()); // Warns but shouldn't | ^ While it would be nice to have a warning on the second line, not warning on the first seems more important. And hopefully is a backportable fix. Here is some Real World Code exhibiting this pattern that g++ currently warns about when compiling: https://github.com/facebook/hermes/blob/dfef1abd6d20b196e24c591e225a7003e6337a94/unittests/VMRuntime/StringPrimitiveTest.cpp#L221-L235. There is also an example using calloc() lower in that file.
[Bug libstdc++/100676] Redeclaring __failed_assertion() at every point of use of __glibcxx_assert breaks Clang CUDA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100676 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Jonathan Wakely --- Fixed for 11.2
[Bug libstdc++/100676] Redeclaring __failed_assertion() at every point of use of __glibcxx_assert breaks Clang CUDA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100676 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:10c58754a862470484eca81623b71e6851470bb6 commit r11-8503-g10c58754a862470484eca81623b71e6851470bb6 Author: Jonathan Wakely Date: Thu May 20 16:39:06 2021 +0100 libstdc++: Use __builtin_unreachable for constexpr assertions [PR 100676] The current implementation of compile-time precondition checks causes compilation to fail by calling a non-constexpr function declared at block scope. This breaks the CUDA compiler, which wraps some libstdc++ headers in a pragma that declares everything as a __host__ __device__ function, but others are not wrapped and so everything is a __host__ function. The local declaration thus gets redeclared as two different types of function, which doesn't work. Just use __builtin_unreachable to make constant evaluation fail, instead of the local function declaration. Also simplify the assertion macros, which has the side effect of giving simpler compilation errors when using Clang. libstdc++-v3/ChangeLog: PR libstdc++/100676 * include/bits/c++config (__glibcxx_assert_1): Rename to ... (__glibcxx_constexpr_assert): ... this. (__glibcxx_assert_impl): Use __glibcxx_constexpr_assert. (__glibcxx_assert): Define as either __glibcxx_constexpr_assert or __glibcxx_assert_impl. (__glibcxx_assert_2): Remove * include/debug/macros.h (_GLIBCXX_DEBUG_VERIFY_AT_F): Use __glibcxx_constexpr_assert instead of __glibcxx_assert_1. * testsuite/21_strings/basic_string_view/element_access/char/back_constexpr_neg.cc: Adjust expected error. * testsuite/21_strings/basic_string_view/element_access/char/constexpr_neg.cc: Likewise. * testsuite/21_strings/basic_string_view/element_access/char/front_constexpr_neg.cc: Likewise. Likewise. * testsuite/21_strings/basic_string_view/element_access/wchar_t/back_constexpr_neg.cc: Likewise. * testsuite/21_strings/basic_string_view/element_access/wchar_t/constexpr_neg.cc: Likewise. * testsuite/21_strings/basic_string_view/element_access/wchar_t/front_constexpr_neg.cc: Likewise. * testsuite/23_containers/span/back_neg.cc: Likewise. * testsuite/23_containers/span/front_neg.cc: Likewise. * testsuite/23_containers/span/index_op_neg.cc: Likewise. (cherry picked from commit 6b42b5a8a207de5e021a2916281f46bcd60b20d2)
[Bug libstdc++/100833] ranges::advance should return n when i == bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100833 --- Comment #2 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:88ed4abb351117f3b7ef9174b3f538c73e6012c7 commit r11-8502-g88ed4abb351117f3b7ef9174b3f538c73e6012c7 Author: Jonathan Wakely Date: Tue Jun 1 16:02:45 2021 +0100 libstdc++: Fix return value of std::ranges::advance [PR 100833] The three-argument form of ranges::advance is supposed to return the difference between the second argument and the distance the iterator was advanced. When a non-random-access iterator is not advanced (because it already equals the sentinel) we were returning 0 rather than n - 0. libstdc++-v3/ChangeLog: PR libstdc++/100833 * include/bits/ranges_base.h (ranges::advance(iter, n, sentinel)): Fix return value for no-op case. * testsuite/24_iterators/range_operations/advance.cc: Test return values of three-argument overload. (cherry picked from commit d8326291695c0f13124c232ddf4fd34e3310e649)
[Bug libstdc++/100768] Range iterator operations should be function objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100768 --- Comment #2 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:f2b76257e9a487fd2c7265094f7b4d1bd46f5f03 commit r11-8501-gf2b76257e9a487fd2c7265094f7b4d1bd46f5f03 Author: Jonathan Wakely Date: Wed May 26 17:32:53 2021 +0100 libstdc++: Change [range.iter.op] functions to function objects [PR 100768] The standard specifies std::ranges::distance etc as function templates, but it also requires them to not be found by ADL, and to suppress ADL when normal unqualified lookup does find them. That means they need to be function objects. libstdc++-v3/ChangeLog: PR libstdc++/100768 * include/bits/ranges_base.h (advance, distance, next, prev): Replace function templates with function objects. * testsuite/24_iterators/headers/iterator/synopsis_c++20.cc: Adjust for changes to function objects. * testsuite/std/ranges/adaptors/elements.cc: Add using declarations for names from namespace ranges. * testsuite/std/ranges/adaptors/transform.cc: Likewise. * testsuite/24_iterators/range_operations/100768.cc: New test. (cherry picked from commit a49a045b92f982f5617c3bbde97a33157237e25b)
[Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99453 --- Comment #17 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:ad4c21f0f59b52357019148ec94d767aa2acd8f2 commit r11-8500-gad4c21f0f59b52357019148ec94d767aa2acd8f2 Author: Jonathan Wakely Date: Tue Jun 1 11:00:16 2021 +0100 libstdc++: Fix installation of python hooks [PR 99453] When no shared library is installed, the new code to determine the name of the -gdb.py file yields an empty string. Use the name of the static library in that case. libstdc++-v3/ChangeLog: PR libstdc++/99453 * python/Makefile.am: Use archive name for printer hook if no dynamic library name is available. * python/Makefile.in: Regenerate. (cherry picked from commit 9f7bc160b4a0f27dce248d1226e3ae7104b0e67b)
[Bug fortran/100860] class(*) type is (character(*)) produces a segmentation fault when run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100860 Tom Robinson changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #4 from Tom Robinson --- Actually, it looks like someone else saw this bug report and tested the code. They reported it worked. Thanks.
[Bug fortran/100860] class(*) type is (character(*)) produces a segmentation fault when run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100860 --- Comment #3 from Tom Robinson --- I tried with the main (12.0.0) and this code ran. I will try it in with our main codebase to confirm it works there too.
[Bug ipa/99122] [10 Regression] ICE in force_constant_size, at gimplify.c:733
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122 --- Comment #35 from Eric Botcazou --- > interestingly I see > > a.9_70 = .builtin_alloca_with_align (iftmp.8_1, 8); > (*a.9_70) = inline22.get_zero (); [static-chain: &FRAME.20] [return slot > optimization] > > so there's no WITH_SIZE_EXPR, but the return value ends up done by reference: > > leaq-80(%rbp), %rdx > movq%rdx, %r10 > movq%rax, %rdi > callinline22__get_zero.0 > movq%rbx, %rsp > movq-8(%rbp), %rbx > leave > > so I wonder if omitting DECL_BY_REFERENCE is simply a bug? I mean the > ABI of the callee must be aware and it seems CALL_EXPR_RETURN_SLOT_OPT > is set by gimplification. IIRC CALL_EXPR_RETURN_SLOT_OPT also only means > we _may_ return by reference not that we must. I don't think it's a bug, in the sense that you can be aggregate_value_p without being DECL_BY_REFERENCE, as it's the case here; the latter is explicit in the GIMPLE representation whereas the former is not. > But of course if we do not exercise the return slot opt then there definitely > is a WITH_SIZE_EXPR missing. Unless I'm missing somehting ... WITH_SIZE_EXPR is for something else (self-referential types). > so I wonder if you can modify the Ada testcase so that > CALL_EXPR_RETURN_SLOT_OPT is not set? No, CALL_EXPR_RETURN_SLOT_OPT is always set, that's the point.
[Bug libstdc++/100863] 23_containers/unordered_{map,set}/allocator/default_init.cc still fail at runtime even after r12-1153
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100863 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |12.0 Version|11.0|12.0
[Bug libstdc++/100863] 23_containers/unordered_{map,set}/allocator/default_init.cc still fail at runtime even after r12-1153
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100863 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Jonathan Wakely --- Done
[Bug c++/100862] using enum member access fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100862 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED
