[Bug target/98827] [11 regression] gcc.target/powerpc/vsx-builtin-7.c assembler counts off after r11-6857
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98827 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0
[Bug middle-end/98829] Different results with -O3 and custom quiet NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98829
--- Comment #4 from Richard Biener ---
The issue is likely GCC canonicalizing the NaN somewhere and your is_value
doing a 1:1 bit comparison. In particular we optimize MyNAN::value to
MyNAN::value ()
{
[local count: 1073741824]:
return Nan;
but ::is_value is
MyNAN::is_value (double d)
{
long unsigned int _2;
bool _3;
[local count: 1073741824]:
_2 = VIEW_CONVERT_EXPR(d_1(D));
_3 = _2 == 9218868437227407042;
return _3;
MyNAN::value is optimized by CSE via native_encode/interpret.
I'm not sure why -O2 vs. -O3 makes a difference in the end but I think
your program is ill-formed.
[Bug target/98833] New: [11 Regression] ICE in extract_insn, at recog.c:2769 since r11-6849-gee78c20e74d30284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98833
Bug ID: 98833
Summary: [11 Regression] ICE in extract_insn, at recog.c:2769
since r11-6849-gee78c20e74d30284
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: crazylht at gmail dot com
Target Milestone: ---
Host: x86_64-linux
Target: x86_64-linux-gnu
The following ICEs:
$ cat xop.c
int __attribute__((__vector_size__(4 * sizeof(int * f5_p;
void f5() { *f5_p = 0 == *f5_p; }
$ gcc xop.c -mavx512vl -mxop -O -c
xop.c: In function ‘f5’:
xop.c:3:33: error: unrecognizable insn:
3 | void f5() { *f5_p = 0 == *f5_p; }
| ^
(insn 14 15 11 2 (set (reg:V4SI 84 [ _4 ])
(eq:V4SI (mem:V4SI (reg/f:DI 82 [ f5_p.0_1 ]) [2 *f5_p.0_1+0 S16 A128])
(reg:V4SI 85))) "xop.c":3:23 -1
(expr_list:REG_DEAD (reg:V4SI 85)
(nil)))
during RTL pass: ira
xop.c:3:33: internal compiler error: in extract_insn, at recog.c:2769
0x6fe7bf _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/marxin/Programming/gcc/gcc/rtl-error.c:108
0x6fe7e1 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/marxin/Programming/gcc/gcc/rtl-error.c:116
0x6fc985 extract_insn(rtx_insn*)
/home/marxin/Programming/gcc/gcc/recog.c:2769
0xc84915 ira_remove_insn_scratches(rtx_insn*, bool, _IO_FILE*, rtx_def*
(*)(rtx_def*))
/home/marxin/Programming/gcc/gcc/ira.c:5243
0xc85b68 remove_scratches
/home/marxin/Programming/gcc/gcc/ira.c:5287
0xc85b68 ira
/home/marxin/Programming/gcc/gcc/ira.c:5602
0xc85b68 execute
/home/marxin/Programming/gcc/gcc/ira.c:5964
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug target/98833] [11 Regression] ICE in extract_insn, at recog.c:2769 since r11-6849-gee78c20e74d30284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98833 Martin Liška changed: What|Removed |Added Known to work||10.2.0 Priority|P3 |P1 Ever confirmed|0 |1 Target Milestone|--- |11.0 Known to fail||11.0 Last reconfirmed||2021-01-26 Status|UNCONFIRMED |NEW
[Bug ipa/98815] Redundant free_dominance_info in cgraph_node::analyze()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98815 Martin Liška changed: What|Removed |Added Resolution|INVALID |--- Status|RESOLVED|ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Last reconfirmed||2021-01-26 Ever confirmed|0 |1 --- Comment #3 from Martin Liška --- All right, let me take a look.
[Bug fortran/93924] ICE in gfc_class_len_get at trans_expr.c:231 with function returning a procedure pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93924 Thomas Koenig changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #5 from Thomas Koenig --- Paul, you've been fixing so many CLASS errors, maybe you'd like about this one :-)
[Bug sanitizer/98828] liblsan.so: undefined reference to __lsan::GetThreadRangesLocked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98828 Martin Liška changed: What|Removed |Added Last reconfirmed||2021-01-26 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Let me take a look.
[Bug tree-optimization/98813] loop is sub-optimized if index is unsigned int with offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98813
--- Comment #6 from Richard Biener ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Jiu Fu Guo from comment #0)
> > For the below code:
> > ---t.c
> > void
> > foo (const double* __restrict__ A, const double* __restrict__ B, double*
> > __restrict__ C,
> > int n, int k, int m)
> > {
> > for (unsigned int l_m = 0; l_m < m; l_m++)
> > C[n + l_m] += A[k + l_m] * B[k];
> > }
>
> Try using unsigned long instead of unsigned int.
> I think this is the same as PR 61247.
Yes, I think we've seen plenty examples in the past where conversions in
the SCEV chain prevent analysis.
[Bug fortran/93924] ICE in gfc_class_len_get at trans_expr.c:231 with function returning a procedure pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93924 --- Comment #6 from Thomas Koenig --- This actually segfaults at runtime.
[Bug tree-optimization/98834] New: Code path incorrectly determined to be unreachable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98834 Bug ID: 98834 Summary: Code path incorrectly determined to be unreachable Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: kretz at kde dot org Target Milestone: --- Target: x86_64-pc-linux-gnu Created attachment 50054 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50054&action=edit test case The attached testcase compiles to a main function without return statement, as if the compiler determines the code path is unreachable. Compile with -O2. If you compile with -O2 -fno-tree-vrp, the return statement is emitted.
[Bug c++/97474] [8/9/10/11 Regression] produces wrong code with references to another field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97474 --- Comment #13 from rguenther at suse dot de --- On Mon, 25 Jan 2021, jason at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97474 > > --- Comment #12 from Jason Merrill --- > Yeah, adding restrict there is just wrong; the constructor is called outside > the function, and could e.g. stash a pointer to the object in a global > variable. What we actually want is to treat this reference parameter like a > value parameter. Is that information actually useful to the optimizers? It's a layout hint PTA can use but without restricting who can point to said object it's not going to affect precision much (in fact I'd have to double check that giving hinting a wrong object size by passing the base "value" of a derived class object won't cause issues). ISTR we've explored keying on REFERENCE_TYPE only (for said layout hint) in the past.
[Bug target/98807] [11 Regression] wrong code with -O2 -mno-sse2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98807 --- Comment #6 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:eb77a934eec8fe52e4c5612f5264127290bc517d commit r11-6905-geb77a934eec8fe52e4c5612f5264127290bc517d Author: Jakub Jelinek Date: Tue Jan 26 09:33:04 2021 +0100 testsuite: Fix up pr98807.c on i686-linux [PR98807] The new testcase FAILs on i686-linux with: gcc/testsuite/gcc.dg/pr98807.c: In function 'foo0': gcc/testsuite/gcc.dg/pr98807.c:20:1: warning: SSE vector return without SSE enabled changes the ABI [-Wpsabi] gcc/testsuite/gcc.dg/pr98807.c:19:1: note: the ABI for passing parameters with 16-byte alignment has changed in GCC 4.6 gcc/testsuite/gcc.dg/pr98807.c:19:1: warning: SSE vector argument without SSE enabled changes the ABI [-Wpsabi] FAIL: gcc.dg/pr98807.c (test for excess errors) Adding usual testcase treatment for such cases. 2021-01-26 Jakub Jelinek PR middle-end/98807 * gcc.dg/pr98807.c: Add -Wno-psabi -w to dg-options.
[Bug fortran/93924] [OOP] segfault with function returning a CLASS(*) pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93924 --- Comment #7 from martin --- With a recent gfortran version I get (how did you compile that you can run the code): fun_select.f90:37:15: 37 | f => selector() | 1 internal compiler error: Segmentation fault 0xc1f3af crash_signal ../../gcc-repo/gcc/toplev.c:327 0x7842f2 gfc_class_vptr_get(tree_node*) ../../gcc-repo/gcc/fortran/trans-expr.c:205 0x797d7c trans_class_vptr_len_assignment ../../gcc-repo/gcc/fortran/trans-expr.c:9202 0x799afa trans_class_assignment ../../gcc-repo/gcc/fortran/trans-expr.c:10893 0x799afa gfc_trans_assignment_1 ../../gcc-repo/gcc/fortran/trans-expr.c:11326 0x757d77 trans_code ../../gcc-repo/gcc/fortran/trans.c:1919 0x781a99 gfc_generate_function_code(gfc_namespace*) ../../gcc-repo/gcc/fortran/trans-decl.c:6880 0x6fd80e translate_all_program_units ../../gcc-repo/gcc/fortran/parse.c:6351 0x6fd80e gfc_parse_file() ../../gcc-repo/gcc/fortran/parse.c:6620 0x75504f gfc_be_parse_file ../../gcc-repo/gcc/fortran/f95-lang.c:212 Please submit a full bug report,
[Bug fortran/93924] [OOP] ICE with procedure pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93924 Thomas Koenig changed: What|Removed |Added Summary|[OOP] segfault with |[OOP] ICE with procedure |function returning a|pointer |CLASS(*) pointer| Keywords|wrong-code |ice-on-valid-code --- Comment #8 from Thomas Koenig --- Sorry, I got the PRs mixed up here and edited the wrong one :-(
[Bug target/98833] [11 Regression] ICE in extract_insn, at recog.c:2769 since r11-6849-gee78c20e74d30284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98833 --- Comment #1 from Hongtao.liu --- hmm, why TARGET_SSE2 && !TARGET_XOP? (define_insn "*sse2_eq3" [(set (match_operand:VI124_128 0 "register_operand" "=x,x") (eq:VI124_128 (match_operand:VI124_128 1 "vector_operand" "%0,x") (match_operand:VI124_128 2 "vector_operand" "xBm,xm")))] "TARGET_SSE2 && !TARGET_XOP && !(MEM_P (operands[1]) && MEM_P (operands[2]))"
[Bug ipa/98834] [10/11 Regression] Code path incorrectly determined to be unreachable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98834 Richard Biener changed: What|Removed |Added Last reconfirmed||2021-01-26 Keywords||needs-bisection, wrong-code CC||jamborm at gcc dot gnu.org, ||marxin at gcc dot gnu.org Ever confirmed|0 |1 Component|tree-optimization |ipa Target Milestone|--- |10.3 Priority|P3 |P2 Status|UNCONFIRMED |NEW --- Comment #1 from Richard Biener --- Confirmed, the __builtin_unreachable is introduced by inlining: Considering _S_multiplies.isra/23 with 12 size to be inlined into int main()/13 in t.C:54 Estimated badness is -inf, frequency 1.00. Badness calculation for int main()/13 -> _S_multiplies.isra/23 size growth -2, time 2.00 unspec 10.00 IPA hints: declared_inline big_speedup -inf: Growth -2 <= 0 Adjusted by hints -inf Accounting size:2.00, time:2.00 on predicate exec:(true) Introduced new external node (void __builtin_unreachable()/24). Processing frequency _S_multiplies.isra/23 Called by int main()/13 that is executed once Accounting size:-4.00, time:-13.00 on predicate exec:(true) t.C:54:62: optimized: Inlined _S_multiplies.isra/23 into int main()/13 which now has time 8.00 and size 9, net change of -14. which points to IPA SRA. VRP then simplifies __builtin_constant_p seen as _12 = __builtin_constant_p (__xx_11); if (_12 != 0) goto ; [100.00%] else goto ; [0.00%] [count: 0]: __builtin_unreachable (); [local count: 1073741824]: MEM [(struct _Tuple *)&D.2557] = 0; and uses conservatively false but that runs into __builtin_unreachable () ... The IPA inline transform ends us with _12 = __builtin_constant_p (__xx_11); if (_12 != 0) goto ; [100.00%] else goto ; [0.00%] [count: 0]: _13 = _16(D); __builtin_unreachable (); [local count: 1073741824]: # SR.30_15 = PHI <__y_10(2)> which eventually shows the reason (the unused argument?)
[Bug target/98833] [11 Regression] ICE in extract_insn, at recog.c:2769 since r11-6849-gee78c20e74d30284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98833
--- Comment #2 from Hongtao.liu ---
Oh, becuase xop has it's own integer compare
(define_insn "xop_maskcmp3"
[(set (match_operand:VI_128 0 "register_operand" "=x")
(match_operator:VI_128 1 "ix86_comparison_int_operator"
[(match_operand:VI_128 2 "register_operand" "x")
(match_operand:VI_128 3 "nonimmediate_operand" "xm")]))]
"TARGET_XOP"
"vpcom%Y1\t{%3, %2, %0|%0, %2, %3}"
[(set_attr "type" "sse4arg")
(set_attr "prefix_data16" "0")
(set_attr "prefix_rep" "0")
(set_attr "prefix_extra" "2")
(set_attr "length_immediate" "1")
(set_attr "mode" "TI")])
[Bug ipa/98834] [10/11 Regression] Code path incorrectly determined to be unreachable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98834 --- Comment #2 from Matthias Kretz (Vir) --- This is reduced from a larger (4MB) testcase which doesn't have any unused arguments.
[Bug target/98833] [11 Regression] ICE in extract_insn, at recog.c:2769 since r11-6849-gee78c20e74d30284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98833 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- So the options are either to restrict the new define_insn_and_split to !TARGET_XOP, or split into something different when TARGET_XOP. Seems it is only for the 128-bit comparisons...
[Bug target/98833] [11 Regression] ICE in extract_insn, at recog.c:2769 since r11-6849-gee78c20e74d30284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98833 --- Comment #4 from Richard Biener --- Eventually XOP has some "better" compares (vpcom). Btw, why do we have a define_expand for "sse2_eq3"? Do we use this as building block internally? Then we should remove the !TARGET_XOP from that? That is, I think (define_insn "xop_maskcmp3" [(set (match_operand:VI_128 0 "register_operand" "=x") (match_operator:VI_128 1 "ix86_comparison_int_operator" [(match_operand:VI_128 2 "register_operand" "x") (match_operand:VI_128 3 "nonimmediate_operand" "xm")]))] "TARGET_XOP" should match what that expander generates?
[Bug target/98833] [11 Regression] ICE in extract_insn, at recog.c:2769 since r11-6849-gee78c20e74d30284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98833 --- Comment #5 from Richard Biener --- Or rather keep the define_expand but remove the !TARGET_XOP from the define_insn? Will we be confused when we have two define_insns matching?
[Bug target/98833] [11 Regression] ICE in extract_insn, at recog.c:2769 since r11-6849-gee78c20e74d30284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98833 --- Comment #6 from Jakub Jelinek --- I think the expander is there to perform ix86_fixup_binary_operands_no_copy (there is a lot of other expanders that have the sole purpose of doing that).
[Bug ipa/98834] [10/11 Regression] Code path incorrectly determined to be unreachable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98834 --- Comment #3 from Matthias Kretz (Vir) --- Created attachment 50055 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50055&action=edit unreduced test case This is the test case I gave to C-Vise. It's already reduced from a more confusing test, where preceding COMPARE(...) would fail by taking the fail path unconditionally. Which now makes sense, since GCC considered the following code to be unreachable.
[Bug c++/98835] New: False positive -Wclass-memaccess with class with ref-qualified copy-assignment operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98835
Bug ID: 98835
Summary: False positive -Wclass-memaccess with class with
ref-qualified copy-assignment operator
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jchl at arista dot com
Target Milestone: ---
Consider the following code:
#include
#include
class Good {
public:
Good & operator=(Good const &) = default;
};
class Bad {
public:
Bad & operator=(Bad const &) & = default;
};
template
void test() {
static_assert(std::is_trivially_copyable_v);
T value1;
T value2;
std::memcpy(&value1, &value2, sizeof(T));
}
int main() {
test();
test();
}
[See: https://godbolt.org/z/4vj9GT ]
GCC trunk on x86_64 incorrectly gives the following warning:
: In instantiation of 'void test() [with T = Bad]':
:24:15: required from here
:19:16: warning: 'void* memcpy(void*, const void*, size_t)' writing
to an object of type 'class Bad' with no trivial copy-assignment; use
copy-assignment or copy-initialization instead [-Wclass-memaccess]
19 | std::memcpy(&value1, &value2, sizeof(T));
| ~~~^
Since both Good and Bad have trivial copy-assignment operators and are
trivially copyable, both types are eligible to be memcpy'd; the
ref-qualification of the assignment operator shouldn't be relevant.
[Bug target/98833] [11 Regression] ICE in extract_insn, at recog.c:2769 since r11-6849-gee78c20e74d30284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98833 --- Comment #7 from Jakub Jelinek --- If two insns with the same RTL match, then the first one wins. But the vpcom instructions have different RTL, so I see no reason for the !TARGET_XOP. grepping for sse2_eq I see only: i386-builtin.def:BDESC (OPTION_MASK_ISA_SSE2, 0, CODE_FOR_sse2_eqv16qi3, "__builtin_ia32_pcmpeqb128", IX86_BUILTIN_PCMPEQB128, UNKNOWN, (int) V16QI_FTYPE_V16QI_V16QI) i386-builtin.def:BDESC (OPTION_MASK_ISA_SSE2, 0, CODE_FOR_sse2_eqv8hi3, "__builtin_ia32_pcmpeqw128", IX86_BUILTIN_PCMPEQW128, UNKNOWN, (int) V8HI_FTYPE_V8HI_V8HI) i386-builtin.def:BDESC (OPTION_MASK_ISA_SSE2, 0, CODE_FOR_sse2_eqv4si3, "__builtin_ia32_pcmpeqd128", IX86_BUILTIN_PCMPEQD128, UNKNOWN, (int) V4SI_FTYPE_V4SI_V4SI ) sse.md:(define_insn "*sse2_eq3" sse.md:(define_expand "sse2_eq3" and those 3 builtins are never used in the headers, so we could as well just remove them and remove the define_expand too (of course keep *sse2_eq with the !TARGET_XOP dropped). Also, grepping for avx2_eq I see: grep avx2_eq * i386-builtin.def:BDESC (OPTION_MASK_ISA_AVX2, 0, CODE_FOR_avx2_eqv32qi3, "__builtin_ia32_pcmpeqb256", IX86_BUILTIN_PCMPEQB256, UNKNOWN, (int) V32QI_FTYPE_V32QI_V32QI) i386-builtin.def:BDESC (OPTION_MASK_ISA_AVX2, 0, CODE_FOR_avx2_eqv16hi3, "__builtin_ia32_pcmpeqw256", IX86_BUILTIN_PCMPEQW256, UNKNOWN, (int) V16HI_FTYPE_V16HI_V16HI) i386-builtin.def:BDESC (OPTION_MASK_ISA_AVX2, 0, CODE_FOR_avx2_eqv8si3, "__builtin_ia32_pcmpeqd256", IX86_BUILTIN_PCMPEQD256, UNKNOWN, (int) V8SI_FTYPE_V8SI_V8SI ) i386-builtin.def:BDESC (OPTION_MASK_ISA_AVX2, 0, CODE_FOR_avx2_eqv4di3, "__builtin_ia32_pcmpeqq256", IX86_BUILTIN_PCMPEQQ256, UNKNOWN, (int) V4DI_FTYPE_V4DI_V4DI ) sse.md:(define_expand "avx2_eq3" sse.md:(define_insn "*avx2_eq3" sse.md:(define_insn_and_split "*avx2_eq3" so perhaps again drop the builtins and expander? Ditto sse2_gt (no expander, rename insn to *sse2_gt and drop builtins). For avx2_gt we actually use the expander in one spot, but don't use the builtins.
[Bug ipa/98834] [10/11 Regression] Code path incorrectly determined to be unreachable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98834 --- Comment #4 from Jakub Jelinek --- Started with r10-3106-g46dfa8ad6c18feb45d35734eae38798edb7c38cd Anyway, I wonder if this isn't similar to the cases where the inliner optimistically assumed that __builtin_constant_p will fold to true but didn't actually fold it that way, and then later on that didn't happen?
[Bug ipa/98834] [10/11 Regression] Code path incorrectly determined to be unreachable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98834 --- Comment #5 from rguenther at suse dot de --- On Tue, 26 Jan 2021, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98834 > > --- Comment #4 from Jakub Jelinek --- > Started with r10-3106-g46dfa8ad6c18feb45d35734eae38798edb7c38cd > Anyway, I wonder if this isn't similar to the cases where the inliner > optimistically assumed that __builtin_constant_p will fold to true but didn't > actually fold it that way, and then later on that didn't happen? Yes, which is why I made it IPA and CCed Martin ... IMHO the __builtin_unreachable () introduced is bogus.
[Bug middle-end/98829] Different results with -O3 and custom quiet NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98829 --- Comment #5 from Nemanja Boric --- Yes, it seems that if the constants are `constexpr` or `static inline const` the custom payload is gone. I guess this is aligned to https://en.cppreference.com/w/cpp/types/numeric_limits/quiet_NaN "A NaN never compares equal to itself. Copying a NaN may not preserve its bit representation."
[Bug fortran/94408] Spurious error: ‘rw_nl_grid’ must be a module procedure or an external procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94408 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Thomas Koenig --- This is now fixed on master, very probably as a result of the fix for PR96320. Since the test case is so similar, it is probably not necessary to commit the test case.
[Bug target/97701] [10/11 Regression] aarch64: ICE in extract_constrain_insn since r10-4447-g095f78c6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97701
Jakub Jelinek changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org,
||rsandifo at gcc dot gnu.org,
||vmakarov at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek ---
I can still reproduce with current trunk and it seems it was latent before and
is a ra or backend bug.
The problematic insn is created during LRA, and first is:
(insn 2616 2615 0 (set (reg:DI 1467)
(lo_sum:DI (reg:DI 1468)
(symbol_ref/u:DI ("*.LC0") [flags 0x82]))) -1
(nil))
which is fine for:
(set (match_operand:DI 0 ("register_operand") ("=r"))
(lo_sum:DI (match_operand:DI 1 ("register_operand") ("r"))
(match_operand 2 ("aarch64_valid_symref") ("S"
insn, but later on LRA changes the destination register to:
(insn 2616 2615 2617 5 (set (reg:DI 32 v0 [1467])
(lo_sum:DI (reg:DI 1468)
(symbol_ref/u:DI ("*.LC0") [flags 0x82]))) 1007 {add_losym_di}
(expr_list:REG_DEAD (reg:DI 1468)
(nil)))
and that doesn't match anymore, as v0 register is not GENERAL_REGS.
[Bug fortran/67539] Segmentation fault with elemental defined assignment and scalar function at the RHS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67539 Thomas Koenig changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||tkoenig at gcc dot gnu.org --- Comment #2 from Thomas Koenig --- Works now, fixed by I don't know what commit. Test case committed as https://gcc.gnu.org/g:80198c701a7fc09e736ccffe470ee5033ca59a69 , closing. Thanks for the bug report!
[Bug gcov-profile/98739] -fprofile-reproducible is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98739 --- Comment #6 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:d40b21eebc9d41c3cb9ccbdf6338968436550621 commit r11-6910-gd40b21eebc9d41c3cb9ccbdf6338968436550621 Author: Martin Liska Date: Tue Jan 26 12:44:34 2021 +0100 libgcov: improve profile reproducibility libgcc/ChangeLog: PR gcov-profile/98739 * libgcov.h (gcov_topn_add_value): Do not train when we have a merged profile with a negative number of total value.
[Bug analyzer/98830] -Wanalyzer-null-argument on static_cast and inheritance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98830 David Malcolm changed: What|Removed |Added Last reconfirmed||2021-01-26 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #4 from David Malcolm --- Thanks. The control flow was created by the compiler, not the user (as part of the static_cast with multiple inheritance). I take your point that we ought not to warn for such cases. I'm looking at how to implement that suppression.
[Bug gcov-profile/98739] -fprofile-reproducible is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98739 --- Comment #7 from CVS Commits --- The releases/gcc-10 branch has been updated by Martin Liska : https://gcc.gnu.org/g:7b7ae189d3ef385b29fa4d5aafa6e01e6111a336 commit r10-9302-g7b7ae189d3ef385b29fa4d5aafa6e01e6111a336 Author: Martin Liska Date: Tue Jan 26 12:48:35 2021 +0100 Fix missing equal symbol for -fprofile-reproducible opt. gcc/ChangeLog: PR gcov-profile/98739 * common.opt: Add missing equal symbol.
[Bug gcov-profile/98739] -fprofile-reproducible is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98739 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Martin Liška --- Fixed on master and I've also fixed the broken option for GCC 10.
[Bug gcov-profile/97461] [11 Regression] allocate_gcov_kvp() deadlocks in firefox LTO+PGO build (overridden malloc() recursion)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97461 Martin Liška changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2021-January ||/564110.html Keywords||patch --- Comment #26 from Martin Liška --- I sent a patch that uses the mmap approach.
[Bug c++/98836] New: tie with spaceship requires operator==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98836
Bug ID: 98836
Summary: tie with spaceship requires operator==
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nunoplopes at sapo dot pt
Target Milestone: ---
The following program doesn't compile with gcc trunk:
https://gcc.godbolt.org/z/PGqMGn
```
#include
#include
using namespace std;
struct expr {
strong_ordering operator<=>(const expr &rhs) const;
};
class FunctionExpr {
std::map fn;
public:
auto operator<=>(const FunctionExpr &rhs) const = default;
};
weak_ordering f(FunctionExpr &a, FunctionExpr &b) {
return tie(a) <=> tie(b);
// <- the one below is OK
return a <=> b;
}
```
TL;DR: the synthesized <=> operator for std::map calls operator== rather than
just calling operator<=>. The code above works fine with clang.
Error:
include/c++/11.0.0/bits/stl_map.h:1465:23: required from 'bool
std::operator==(const std::map<_Key, _Tp, _Compare, _Allocator>&, const
std::map<_Key, _Tp, _Compare, _Allocator>&) [with _Key = expr; _Tp = expr;
_Compare = std::less; _Alloc = std::allocator
>]'
:14:8: required from 'static constexpr bool
std::__detail::_Synth3way::_S_noexcept(const _Tp*, const _Up*) [with _Tp =
FunctionExpr; _Up = FunctionExpr]'
include/c++/11.0.0/compare:885:32: required from 'constexpr auto
std::__detail::_Synth3way::operator()(const _Tp&, const _Up&) const requires
requires{{std::__detail::_Synth3way::operator()::__t <
std::__detail::_Synth3way::operator()::__u} -> decltype(auto) [requires
std::__detail::__boolean_testable<,
>];{std::__detail::_Synth3way::operator()::__u <
std::__detail::_Synth3way::operator()::__t} -> decltype(auto) [requires
std::__detail::__boolean_testable<, >];} [with _Tp = FunctionExpr;
_Up = FunctionExpr]'
include/c++/11.0.0/compare:909:34: required by substitution of
'template using __synth3way_t = decltype
(std::__detail::__synth3way(declval<_Tp&>(), declval<_Up&>())) [with _Tp =
FunctionExpr&; _Up = FunctionExpr&]'
include/c++/11.0.0/tuple:1509:5: required by substitution of 'template constexpr
std::common_comparison_category_t...>
std::operator<=>(const std::tuple<_Tps ...>&, const std::tuple<_Args2 ...>&)
[with _Tps = {FunctionExpr&}; _Ups = {FunctionExpr&}]'
:18:26: required from here
include/c++/11.0.0/bits/stl_pair.h:467:24: error: no match for 'operator=='
(operand types are 'const expr' and 'const expr')
467 | { return __x.first == __y.first && __x.second == __y.second; }
| ~~^~~~
[Bug ipa/98815] Redundant free_dominance_info in cgraph_node::analyze()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98815 Martin Liška changed: What|Removed |Added Target Milestone|--- |12.0
[Bug tree-optimization/98837] New: SLP discovery does not consider all lane permutes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98837
Bug ID: 98837
Summary: SLP discovery does not consider all lane permutes
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
While we SLP vectorize
int a[1024], b[1024], c[1024];
void foo ()
{
for (int i = 0; i < 1024; i += 4)
{
c[i] = a[i] + b[i];
c[i+1] = a[i+1] + b[i+1];
c[i+2] = a[i+2] * b[i+2];
c[i+3] = a[i+3] * b[i+3];
}
}
by splitting the SLP group into two the very similar
int a[1024], b[1024], c[1024];
void foo ()
{
for (int i = 0; i < 1024; i += 4)
{
c[i] = a[i] + b[i];
c[i+1] = a[i+1] * b[i+1];
c[i+2] = a[i+2] + b[i+2];
c[i+3] = a[i+3] * b[i+3];
}
}
is not SLPed because we do not consider splitting the group into
non-adjacent sets. The same applies to basic-block SLP when
you make the data type double (so we don't need unrolling),
of course we simply fall back to a scalar build then.
[Bug tree-optimization/98563] [10/11 Regression] vectorization fails while it worked on gcc 9 and earlier since since r10-2271-gd81ab49d0586fca0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98563 --- Comment #6 from Richard Biener --- (In reply to Jakub Jelinek from comment #5) > That change included an important bugfix for the simd handling of > addressable locals, when they escape they would be then mishandled during > vectorization. > I think the current representation is right, represent them as if each simd > lane has its own copy of the variable. > The reason why this isn't vectorized is I think PR91020, that SRA doesn't > split those real and imag parts as separate (simd array) vars. Hmm, it's a bit far-fetched to consider this an SRA issue - can't OMP lowering do any better here?
[Bug c++/98798] Custom operator new[] and delete[] is buggy for aligned class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98798
Martin Liška changed:
What|Removed |Added
CC||jwakely at redhat dot com
Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot
gnu.org
Status|ASSIGNED|NEW
--- Comment #2 from Martin Liška ---
(In reply to Martin Liška from comment #1)
> Confirmed, reduced test-case:
>
> $ cat pr98798.C
> #include
> #include
>
> class alignas(32) Foo
> {
> public :
> char x;
>
> void * operator new[ ] (size_t s, std::align_val_t a)
> {
> __builtin_printf ("s: %d, a: %d\n", s, a);
> return aligned_alloc(static_cast(a), s);
> }
>
> void operator delete[ ] (void *p, size_t s, std::align_val_t a)
> {
> }
> };
>
> int main()
> {
> auto p = std::make_unique(3);
> }
>
> I'm going to take a look.
I think it's a bug in libstdc++ and one can see it with valgrind:
g++-10 pr98798.C -std=c++17 -g && valgrind ./a.out
==10004== Memcheck, a memory error detector
==10004== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==10004== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
==10004== Command: ./a.out
==10004==
s: 96, a: 32
==10004== Invalid read of size 8
==10004==at 0x4013B3: std::enable_if::value, void>::type std::default_delete::operator()(Foo*)
const (unique_ptr.h:120)
==10004==by 0x401304: std::unique_ptr
>::~unique_ptr() (unique_ptr.h:612)
==10004==by 0x40119A: main (pr98798.C:22)
==10004== Address 0x4da70f8 is 8 bytes before a block of size 96 alloc'd
==10004==at 0x483C118: memalign (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==10004==by 0x401231: Foo::operator new[](unsigned long, std::align_val_t)
(pr98798.C:12)
==10004==by 0x40127E: std::_MakeUniq::__array std::make_unique(unsigned long) (unique_ptr.h:968)
==10004==by 0x40118E: main (pr98798.C:22)
@Jonathan: Can you please take a look?
[Bug sanitizer/98828] liblsan.so: undefined reference to __lsan::GetThreadRangesLocked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98828 --- Comment #2 from Martin Liška --- I can confirm that even on x86_64-linux-gnu. Thanks for the report!
[Bug tree-optimization/98726] [10/11 Regression] SVE: tree check: expected integer_cst, have poly_int_cst in to_wide, at tree.h:5984
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98726
Richard Biener changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
--- Comment #2 from Richard Biener ---
Eh, we can't even _dump_ those VECTOR_CST:
#0 internal_error (gmsgid=0x29cb490 "tree check: %s, have %s in %s, at %s:%d")
at ../../src/trunk/gcc/diagnostic.c:1804
#1 0x017d00ea in tree_check_failed (
node=,
file=0x2858ad0 "../../src/trunk/gcc/tree.h", line=5984,
function=0x285fe70 "to_wide")
at ../../src/trunk/gcc/tree.c:9812
#2 0x00ad994d in tree_check (__t=,
__f=0x2858ad0 "../../src/trunk/gcc/tree.h", __l=5984,
__g=0x285fe70 "to_wide",
__c=INTEGER_CST) at ../../src/trunk/gcc/tree.h:3594
#3 0x00b56c27 in wi::to_wide (t=)
at ../../src/trunk/gcc/tree.h:5984
#4 0x017d75b2 in vector_cst_int_elt (t=,
i=3) at ../../src/trunk/gcc/tree.c:11104
#5 0x017d7798 in vector_cst_elt (t=, i=3)
at ../../src/trunk/gcc/tree.c:11131
#6 0x014e0e2c in dump_generic_node (pp=0x3754e00,
node=, spc=0, flags=2112, is_stmt=false)
at ../../src/trunk/gcc/tree-pretty-print.c:2112
11101 /* Otherwise work out the value from the last two encoded elements.
*/
11102 tree v1 = VECTOR_CST_ENCODED_ELT (t, final_i - npatterns);
11103 tree v2 = VECTOR_CST_ENCODED_ELT (t, final_i);
11104 wide_int diff = wi::to_wide (v2) - wi::to_wide (v1);
(gdb) p v1
$5 =
(gdb) p v2
$6 =
now if such VECTOR_CST is well-formed (well ...?), then with using
poly_wide_int in vector_cst_int_elt we at least get to RTL expansion where
we ICE like
#0 fancy_abort (file=0x28dd290 "../../src/trunk/gcc/rtl.h", line=2296,
function=0x28e84a0
>::decompose(long*, unsigned int, std::pair
const&)::__FUNCTION__> "decompose") at ../../src/trunk/gcc/diagnostic.c:1884
#1 0x00e17546 in wi::int_traits
>::decompose (precision=32, x=...) at ../../src/trunk/gcc/rtl.h:2296
#2 0x00e45617 in wide_int_ref_storage::wide_int_ref_storage >
(this=0x7fffc5a0, x=...,
precision=32) at ../../src/trunk/gcc/wide-int.h:1034
#3 0x00e427e7 in generic_wide_int
>::generic_wide_int > (this=0x7fffc5a0,
x=..., precision=32) at ../../src/trunk/gcc/wide-int.h:790
#4 0x00e405be in wi::sub,
std::pair > (x=..., y=...) at
../../src/trunk/gcc/wide-int.h:2512
#5 0x0132743f in rtx_vector_builder::step (this=0x7fffc7a0,
elt1=0x76f2f0c0, elt2=0x76f2f0e0)
at ../../src/trunk/gcc/rtx-vector-builder.h:122
#6 0x0132795e in vector_builder::elt (this=0x7fffc7a0, i=3)
at ../../src/trunk/gcc/vector-builder.h:254
#7 0x01327051 in rtx_vector_builder::build (this=0x7fffc7a0)
at ../../src/trunk/gcc/rtx-vector-builder.c:73
#8 0x00eb109a in const_vector_from_tree (
exp=) at ../../src/trunk/gcc/expr.c:12763
Richard - are POLY_INT_CST element VECTOR_CST well-formed? It seems
they are introduced during vectorization but there they are simple
like { POLY_INT_CST [4, 4], ... } but then FRE4 produces
Value numbering stmt = _48 = vect_cst__46 + { 0, 1, 2, ... };
Match-and-simplified vect_cst__46 + { 0, 1, 2, ... } to { POLY_INT_CST [16,
16], POLY_INT_CST [17, 16], POLY_INT_CST [18, 16], ... }
and things start to go downhill.
[Bug tree-optimization/98726] [10/11 Regression] SVE: tree check: expected integer_cst, have poly_int_cst in to_wide, at tree.h:5984
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98726 --- Comment #3 from Richard Biener --- Created attachment 50056 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50056&action=edit patch to make dumping not ICE The attached avoids ICEing during dumping (it seems there's no reason to export the function in the first place)
[Bug c++/98798] Custom operator new[] and delete[] is buggy for aligned class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98798 --- Comment #3 from Jonathan Wakely --- (In reply to Martin Liška from comment #2) > I think it's a bug in libstdc++ and one can see it with valgrind: But there's no error when compiled with clang and libstdc++, so that suggests the problem is g++ not libstdc++.
[Bug other/98838] New: Spam sent to dedicated Bugzilla e-mail address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98838 Bug ID: 98838 Summary: Spam sent to dedicated Bugzilla e-mail address Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: g...@christoph-conrads.name Target Milestone: --- My account on gcc.gnu.org/bugzilla is linked to a dedicated e-mail address (go check my account data). I began receiving spam mail recently with the destination address being the e-mail address associated with my account on this website. In my opinion, the only possible way for my e-mail address to end up in the hand of spammers is if there is a problem on the side of Bugzilla.
[Bug other/98838] Spam sent to dedicated Bugzilla e-mail address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98838 Christoph Conrads changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Christoph Conrads --- I just saw that bug reports are automatically forwarded to the GCC mailing lists with the e-mail address not being scrambled.
[Bug c++/98798] Custom operator new[] and delete[] is buggy for aligned class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98798
--- Comment #4 from Jonathan Wakely ---
#include
using std::size_t;
struct alignas(32) Foo
{
char x;
void * operator new[ ] (size_t s, std::align_val_t a)
{
void* p = aligned_alloc(static_cast(a), s);
__builtin_printf ("p: %p s: %zu, a: %zu\n", p, s, (size_t)a);
return p;
}
void operator delete[ ] (void *p, size_t s, std::align_val_t a)
{
__builtin_printf ("p: %p s: %zu, a: %zu\n", p, s, (size_t)a);
free(p);
}
};
int main()
{
auto p = std::make_unique(3);
__builtin_printf("p: %p\n", p.get());
}
For this code clang prints:
p: 0x4daacc0 s: 128, a: 32
p: 0x4daace0
p: 0x4daacc0 s: 128, a: 32
Notice that the p.get() pointer is not equal to the value returned by
aligned_alloc, because the compiler adds a cookie and then adjusts the pointer.
G++ prints:
p: 0x4dd2cc0 s: 96, a: 32
p: 0x4dd2cc0
==1233795== Invalid read of size 8
==1233795==at 0x40144D: std::enable_if::value, void>::type std::default_delete::operator()(Foo*)
const (unique_ptr.h:120)
==1233795==by 0x401328: std::unique_ptr
>::~unique_ptr() (unique_ptr.h:612)
==1233795==by 0x4011B9: main (98798.C:25)
==1233795== Address 0x4dd2cb8 is 8 bytes before a block of size 96 alloc'd
==1233795==at 0x483D01C: memalign (vg_replace_malloc.c:907)
==1233795==by 0x401203: Foo::operator new[](unsigned long,
std::align_val_t) (98798.C:11)
==1233795==by 0x4012A4: std::_MakeUniq::__array
std::make_unique(unsigned long) (unique_ptr.h:968)
==1233795==by 0x40118F: main (98798.C:25)
==1233795==
p: 0x4dd2cc0 s: 0, a: 32
There are three problems here.
Firstly, the p.get() pointer is the same as that returned by aligned_alloc,
meaning there is no array cookie.
Secondly, the delete[] expression at unique_ptr.h:120 expects a cookie and so
inspects the 8 bytes before the pointer value (which valgrind correctly
diagnoses as invalid).
Thirdly, the size passed to Foo::operator delete[] is zero. Probably because
the 8 bytes before the allocation (where the cookie should be) happen to be
zero.
This is a G++ bug.
[Bug tree-optimization/98726] [10/11 Regression] SVE: tree check: expected integer_cst, have poly_int_cst in to_wide, at tree.h:5984
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98726 --- Comment #4 from Richard Biener --- So looks like induction vectorization is the culprit here but I also guess that's actually supported? -fdisable-tree-fre4 -fdisable-tree-fre5 -fdisable-tree-dom3 makes the testcase compile since we only retain the basic VECTOR_CSTs that appear to be supported?
[Bug fortran/93924] [OOP] ICE with procedure pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93924 --- Comment #9 from Paul Thomas --- Created attachment 50057 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50057&action=edit Patch that "fixes" all versions of the problem The attached patch has a fragment of my finalize on assignment patch in the second chunk. The changes are small and few so could be applied manually. Whatever is the legality or otherwise, this fixes all versions of the problem and regtests OK. Please do what you will with this. If it is still open in a few weeks time, I will take it. At the present, I have too many open PRs. Paul
[Bug c/98819] Wall Wformat-signedness suggests %u for %u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98819 --- Comment #5 from Jonny Grant --- (In reply to David Malcolm from comment #4) > In comment #0, the bottom-most "%u" is a fix-it hint, giving the nonsensical > suggestion to the user that they replace the "%u" with itself. Clearly we > shouldn't issue such a fix-it hint. > > I'm not able to reproduce the warning with the given reproducer. What flags > are you using? Do you have a URL for your godbolt example? Hello David, Martin Godbot was with: -Wall -Wformat-signedness https://godbolt.org/z/bn3oeh
[Bug c++/98798] Custom operator new[] and delete[] is buggy for aligned class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98798 --- Comment #5 from Jonathan Wakely --- I wonder if https://itanium-cxx-abi.github.io/cxx-abi/abi.html#array-cookies needs to be updated for aligned new[] expressions, or if G++ is just not accounring for them correctly.
[Bug tree-optimization/98563] [10/11 Regression] vectorization fails while it worked on gcc 9 and earlier since since r10-2271-gd81ab49d0586fca0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98563 --- Comment #7 from Jakub Jelinek --- I'm afraid no. The vectorization can handle addresses into the simd arrays, but right now only if it accesses the whole element, i.e. when we can turn the simd array into a vector register (or set thereof) that hold the variable. In this case that is not the case, as in the end it uses the real and imag parts separately. So, either it can be handled in SRA, or we'd need to teach the vectorizer to permute those fur us.
[Bug c++/98798] Custom operator new[] and delete[] is buggy for aligned class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98798 --- Comment #6 from Jonathan Wakely --- Yes, I think the ABI needs fixing. In this example Foo has a trivial destructor and Foo::operator delete[](void*, size_t, align_val_t) does not have two parameters. According to the ABI, no cookie is needed. But that's wrong, this operator delete[] needs a cookie just like operator delete[](void*, size_t) needs it. The rule in the ABI might need to consider a destroying operator delete too.
[Bug c++/98798] Custom operator new[] and delete[] is buggy for aligned class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98798 --- Comment #7 from Jonathan Wakely --- Also, the note in that section of the ABI is wrong: > (Note: if the usual array deallocation function takes two arguments, > then it is a member function whose second argument is of type size_t. That was true prior to sized deallocation, but it's no longer true.
[Bug c/98819] Wall Wformat-signedness suggests %u for %u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98819 --- Comment #6 from Jonny Grant --- Godbolt %u example https://godbolt.org/z/sc7K6T
[Bug c++/98798] Custom operator new[] and delete[] is buggy for aligned class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98798 --- Comment #8 from Jonathan Wakely --- I've reported this as https://github.com/itanium-cxx-abi/cxx-abi/issues/119 but I haven't tried to fix the spec, or fix G++.
[Bug sanitizer/98828] liblsan.so: undefined reference to __lsan::GetThreadRangesLocked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98828 --- Comment #3 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:2e81b16c24367d7cc92f6d369606dca5575f6b5f commit r11-6911-g2e81b16c24367d7cc92f6d369606dca5575f6b5f Author: Martin Liska Date: Tue Jan 26 14:11:39 2021 +0100 liblsan: build missing lsan_posix.cpp file libsanitizer/ChangeLog: PR sanitizer/98828 * lsan/Makefile.am: Add missing lsan_posix.cpp file. * lsan/Makefile.in: Likewise.
[Bug sanitizer/98828] liblsan.so: undefined reference to __lsan::GetThreadRangesLocked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98828 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Martin Liška --- Fixed.
[Bug ada/98228] [11 Regression] ICE: Assert_Failure atree.adb:931: Error detected at s-gearop.adb:382:34 [a-ngrear.adb:313:7 [a-nllrar.ads:18:1]] on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228 --- Comment #19 from Marius Hillenbrand --- Eric, I have bootstrapped and successfully reg-tested your proposed fix on s390x and x86-64. fwict, it works as intended.
[Bug tree-optimization/98563] [10/11 Regression] vectorization fails while it worked on gcc 9 and earlier since since r10-2271-gd81ab49d0586fca0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98563
--- Comment #8 from Richard Biener ---
(In reply to Jakub Jelinek from comment #7)
> I'm afraid no.
> The vectorization can handle addresses into the simd arrays, but right now
> only if it accesses the whole element, i.e. when we can turn the simd array
> into a vector register (or set thereof) that hold the variable.
> In this case that is not the case, as in the end it uses the real and imag
> parts separately.
> So, either it can be handled in SRA, or we'd need to teach the vectorizer to
> permute those fur us.
Hmm, I see. The vectorizer can in theory handle "existing" vectors (currently
only enabled for basic-block SLP though). But of course the first hurdle is
to not treat those as memory accesses (thus ignore the data-ref analysis
failure or somehow make that treat the SIMD_LANE indexing "nicely").
When we see
_13 = .GOMP_SIMD_LANE (simduid.0_12(D), 0);
can we compute how _13 evolves with loop iteration? Thus, can we
SCEV analyze it? Isn't it sth like { .GOMP_SIMD_LANE_START (simduid.0_12(D),
.GOMP_SIMD_LANE_STEP (simduid.0_12(D), 0) } thus an affine evolution
in the end?
Simplified C testcase:
typedef _Complex double cplx;
void foo (cplx *);
void test(cplx* __restrict__ a, const cplx* b, double c, int N)
{
cplx tem;
#pragma omp simd private (tem)
for (int i=0; i<8*N; i++) {
__real tem = __real b[i];
__imag tem = __imag b[i];
__real a[i] = __real tem;
__imag a[i] = __imag tem;
}
foo (&tem);
}
which we miscompile (well, I guess I did sth wrong with the use after
the loop but to trigger GOMP_SIMD_LANE the temporary seems to need to
have its address taken).
[Bug other/98838] Spam sent to dedicated Bugzilla e-mail address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98838 --- Comment #2 from Jonathan Wakely --- Indeed: https://gcc.gnu.org/pipermail/gcc-bugs/2021-January/727161.html It was discussed when we moved to the new list software and it was suggested that simply replacing "@" with " at " and ".com" with " dot com" probably doesn't do much good anyway: https://gcc.gnu.org/pipermail/gcc/2020-March/12.html
[Bug tree-optimization/98726] [10/11 Regression] SVE: tree check: expected integer_cst, have poly_int_cst in to_wide, at tree.h:5984
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98726 --- Comment #5 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:4b59dbb5d6759e43bfa23161a8d3feb9ae969e1a commit r11-6912-g4b59dbb5d6759e43bfa23161a8d3feb9ae969e1a Author: Richard Biener Date: Tue Jan 26 13:32:27 2021 +0100 middle-end/98726 - fix VECTOR_CST element access This fixes VECTOR_CST element access with POLY_INT elements and allows to produce dump files of the PR98726 testcase without ICEing. 2021-01-26 Richard Biener PR middle-end/98726 * tree.h (vector_cst_int_elt): Remove. * tree.c (vector_cst_int_elt): Use poly_wide_int for computations, make static.
[Bug tree-optimization/98726] [10/11 Regression] SVE: tree check: expected integer_cst, have poly_int_cst in to_wide, at tree.h:5984
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98726 --- Comment #6 from Richard Biener --- RTL expansion ICE remains.
[Bug tree-optimization/98563] [10/11 Regression] vectorization fails while it worked on gcc 9 and earlier since since r10-2271-gd81ab49d0586fca0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98563
--- Comment #9 from Jakub Jelinek ---
(In reply to Richard Biener from comment #8)
> (In reply to Jakub Jelinek from comment #7)
> > I'm afraid no.
> > The vectorization can handle addresses into the simd arrays, but right now
> > only if it accesses the whole element, i.e. when we can turn the simd array
> > into a vector register (or set thereof) that hold the variable.
> > In this case that is not the case, as in the end it uses the real and imag
> > parts separately.
> > So, either it can be handled in SRA, or we'd need to teach the vectorizer to
> > permute those fur us.
>
> Hmm, I see. The vectorizer can in theory handle "existing" vectors
> (currently only enabled for basic-block SLP though). But of course the
> first hurdle is
> to not treat those as memory accesses (thus ignore the data-ref analysis
> failure or somehow make that treat the SIMD_LANE indexing "nicely").
>
> When we see
>
> _13 = .GOMP_SIMD_LANE (simduid.0_12(D), 0);
>
> can we compute how _13 evolves with loop iteration? Thus, can we
> SCEV analyze it? Isn't it sth like { .GOMP_SIMD_LANE_START
> (simduid.0_12(D), .GOMP_SIMD_LANE_STEP (simduid.0_12(D), 0) } thus an affine
> evolution
> in the end?
_13 has modulo semantics in the loop, it gets values 0, 1, ... vf-1, 0, 1, ...
vf-1 etc., where vf is the vectorization factor of the loop.
The intent is that after successful vectorization, the array can be promoted to
a vector containing those (or a set of vectors, it is a software vector rather
than necessarily hardware vector) and on unsuccessful vectorization it will
shrink into a single array variable (scalar).
> Simplified C testcase:
>
> typedef _Complex double cplx;
> void foo (cplx *);
> void test(cplx* __restrict__ a, const cplx* b, double c, int N)
> {
> cplx tem;
> #pragma omp simd private (tem)
> for (int i=0; i<8*N; i++) {
> __real tem = __real b[i];
> __imag tem = __imag b[i];
> __real a[i] = __real tem;
> __imag a[i] = __imag tem;
> }
> foo (&tem);
private clause means undefined at the end of construct, if you want to inspect
the value afterwards, the possible clauses are lastprivate (the scalar variable
receives the value from the last iteration), or reduction (in that case it will
reduce it using some base language reduction operator or user defined function
from all the vector elements).
[Bug rtl-optimization/21182] [8/9/10/11 Regression] gcc can use registers but uses stack instead
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21182 --- Comment #31 from Richard Biener --- -fno-tree-ter improves things quite a bit. With -DNAILED_REGS gimple doesn't do much because we treat registers as memory here. For trunk -O2 has 52 spills -O2 -fno-tree-ter has 35 spills -O2 -fno-tree-ter -fschedule-insns has 74 spills -O2 -fno-tree-ter -fschedule-insns -fsched-pressure has 18 spills -O2 -fschedule-insns -fsched-pressure has 17 spills to me this really hints at out-of-SSA producing a very bad initial schedule, by TER but also likely due to folding & friends doing random stmt placing (it's all a single BB). I think we'd benefit quite a bit with killing TER (doing all interesting bits pre-RTL or via SSA RTL forwprop) and ordering SSA def expansion for optimal register pressure.
[Bug target/98681] [8/9/10/11 Regression] aarch64: Invalid ubfiz instruction rejected by assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98681 --- Comment #9 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:17ad8cdebe65b47d257d85849747b806af0a85fd commit r11-6914-g17ad8cdebe65b47d257d85849747b806af0a85fd Author: Jakub Jelinek Date: Tue Jan 26 14:48:26 2021 +0100 aarch64: Tighten up checks for ubfix [PR98681] The testcase in the patch doesn't assemble, because the instruction requires that the penultimate operand (lsb) range is [0, 32] (or [0, 64]) and the last operand's range is [1, 32 - lsb] (or [1, 64 - lsb]). The INTVAL (shft_amnt) < GET_MODE_BITSIZE (mode) will accept the lsb operand to be in range [MIN, 32] (or [MIN, 64]) and then we invoke UB in the compiler and sometimes it will make it through. The patch changes all the INTVAL uses in that function to UINTVAL, which isn't strictly necessary, but can be done (e.g. after the UINTVAL (shft_amnt) < GET_MODE_BITSIZE (mode) check we know it is not negative and thus INTVAL (shft_amnt) and UINTVAL (shft_amnt) then behave the same. But, I had to add INTVAL (mask) > 0 check in that case, otherwise we risk (hypothetically) emitting instruction that doesn't assemble. The problem is with masks that have the MSB bit set, while the instruction can handle those, e.g. ubfiz w1, w0, 13, 19 will do (w0 << 13) & 0xe000 in RTL we represent SImode constants with MSB set as negative HOST_WIDE_INT, so it will actually be HOST_WIDE_INT_C (0xe000), and the instruction uses %P3 to print the last operand, which calls asm_fprintf (f, "%u", popcount_hwi (INTVAL (x))) to print that. But that will not print 19, but 51 instead, will include there also all the copies of the sign bit. Not supporting those masks with MSB set isn't a big loss though, they really shouldn't appear normally, as both GIMPLE and RTL optimizations should optimize those away (one isn't masking any bits off with such masks, so just w0 << 13 will do too). 2021-01-26 Jakub Jelinek PR target/98681 * config/aarch64/aarch64.c (aarch64_mask_and_shift_for_ubfiz_p): Use UINTVAL (shft_amnt) and UINTVAL (mask) instead of INTVAL (shft_amnt) and INTVAL (mask). Add && INTVAL (mask) > 0 condition. * gcc.c-torture/execute/pr98681.c: New test.
[Bug target/98681] [8/9/10 Regression] aarch64: Invalid ubfiz instruction rejected by assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98681 Jakub Jelinek changed: What|Removed |Added Summary|[8/9/10/11 Regression] |[8/9/10 Regression] |aarch64: Invalid ubfiz |aarch64: Invalid ubfiz |instruction rejected by |instruction rejected by |assembler |assembler --- Comment #10 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug target/82150] Produces a branch prefetch which causes a hang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82150
--- Comment #11 from david.welch at netronome dot com ---
I wish I had know this when I filed this ticket, there is an ARM Errata for
this issue that was issued before or in 2009.
720247: Speculative Instruction fetches can be made anywhere in the memory map
I have researched this bug on this core and provided a workaround that ARM was
not able or willing. (put a nop after unconditional branch instructions that
modify the pc like pop {r4,pc}, but not bx lr...,anything other than another
branch instruction that causes a speculative fetch).
So if you require an ARM Errata in order to fix something, there you go it
exists.
It is still present in gcc 10 (has been present all this time). I have not
examined gcc 11 yet as it has not been formally released.
unsigned int more_fun ( unsigned int );
unsigned int fun ( void )
{
return(more_fun(0x12344700)+1);
}
Disassembly of section .text:
:
0: b510push{r4, lr}
2: 4802ldr r0, [pc, #8]; (c )
4: f7ff fffe bl 0
8: 3001addsr0, #1
a: bd10pop {r4, pc}
c: 12344700.word 0x12344700
.thumb
.inst.n 0x4700
Disassembly of section .text:
<.text>:
0: 4700bx r0
and there is the speculative execution that causes a read (that can be anywhere
in the address space)
arm-none-eabi-gcc --version
arm-none-eabi-gcc (GCC) 10.2.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
One could examine everything after a branch like this for another branch as a
real instruction or embedded in the top of the pool a nop may be simpler after
each of the at-risk instructions.
[Bug target/82150] Produces a branch prefetch which causes a hang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82150 --- Comment #12 from david.welch at netronome dot com --- I my case this was found with a hang, but the problem exists as a read, which means it can cause a read to a read sensitive peripheral causing adverse affects.
[Bug target/98737] Atomic operation on x86 no optimized to use flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98737 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #5 from Jakub Jelinek --- Created attachment 50058 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50058&action=edit gcc11-pr98737.patch Untested fix.
[Bug target/98827] [11 regression] gcc.target/powerpc/vsx-builtin-7.c assembler counts off after r11-6857
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98827 --- Comment #2 from seurer at gcc dot gnu.org --- On power 8 I used: configure --enable-languages=c,fortran,c++ --with-cpu=power8 --disable-bootstrap --disable-multilib On power 7 it was the same but --with-cpu=power7
[Bug debug/98811] [11 regression] All Go tests FAIL with abbrev offset out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98811 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek --- Fixed.
[Bug fortran/93924] [OOP] ICE with procedure pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93924 --- Comment #10 from Paul Thomas --- (In reply to Paul Thomas from comment #9) > Created attachment 50057 [details] > Patch that "fixes" all versions of the problem > > The attached patch has a fragment of my finalize on assignment patch in the > second chunk. The changes are small and few so could be applied manually. > > Whatever is the legality or otherwise, this fixes all versions of the > problem and regtests OK. > > Please do what you will with this. If it is still open in a few weeks time, > I will take it. At the present, I have too many open PRs. > > Paul Final remarks for the time being in comments below: module cs implicit none private public classStar_map_ifc public apply, selector integer, target :: integer_target abstract interface function classStar_map_ifc(x) result(y) class(*), pointer:: y class(*), target, intent(in) :: x end function classStar_map_ifc end interface contains function fun(x) result(y) class(*), pointer:: y class(*), target, intent(in) :: x select type (x) type is (integer) integer_target = x ! One way of overcoming dangling target business y => integer_target class default y => null() end select end function fun function apply(f, x) result(y) procedure(classStar_map_ifc) :: f integer, intent(in) :: x integer :: y class(*), pointer :: p y = 0 ! Get rid of 'y' undefined warning p => f(x) select type (p) type is (integer) y = p end select end function apply function selector() result(f) procedure(classStar_map_ifc), pointer :: f f => fun end function selector end module cs program classStar_map use cs implicit none integer :: x, y procedure(classStar_map_ifc), pointer :: f x = 123654 f => selector() ! Fixed by second chunk in patch (suppresses class assignment) y = apply(f, x) ! Fixed by first chunk in patch (passing procedure) print *, x, y end program classStar_map
[Bug bootstrap/98839] New: [11 regression] compilation failure for dwarf2asm.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98839 Bug ID: 98839 Summary: [11 regression] compilation failure for dwarf2asm.c Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- I am seeing this on all varieties of powerpc64. I am still narrowing down when it started. make[3]: Entering directory `/home/seurer/gcc/git/build/gcc-trunk-bootstrap/gcc' /home/seurer/gcc/git/build/gcc-trunk-bootstrap/./prev-gcc/xg++ -B/home/seurer/gcc/git/build/gcc-trunk-bootstrap/./prev-gcc/ -B/home/seurer/gcc/git/install/gcc-trunk-bootstrap/powerpc64-unknown-linux-gnu/bin/ -nostdinc++ -B/home/seurer/gcc/git/build/gcc-trunk-bootstrap/prev-powerpc64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/home/seurer/gcc/git/build/gcc-trunk-bootstrap/prev-powerpc64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/home/seurer/gcc/git/build/gcc-trunk-bootstrap/prev-powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu -I/home/seurer/gcc/git/build/gcc-trunk-bootstrap/prev-powerpc64-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/git/gcc-trunk-bootstrap/libstdc++-v3/libsupc++ -L/home/seurer/gcc/git/build/gcc-trunk-bootstrap/prev-powerpc64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/home/seurer/gcc/git/build/gcc-trunk-bootstrap/prev-powerpc64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -fno-PIE -c -g -O2 -fno-checking -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc -I/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/. -I/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/../include -I/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/../libcpp/include -I/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/../libcody -I/home/seurer/gcc/git/build/gcc-trunk-bootstrap/./gmp -I/home/seurer/gcc/git/gcc-trunk-bootstrap/gmp -I/home/seurer/gcc/git/build/gcc-trunk-bootstrap/./mpfr/src -I/home/seurer/gcc/git/gcc-trunk-bootstrap/mpfr/src -I/home/seurer/gcc/git/gcc-trunk-bootstrap/mpc/src -I/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/../libdecnumber -I/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/../libdecnumber/dpd -I../libdecnumber -I/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/../libbacktrace -I/home/seurer/gcc/git/build/gcc-trunk-bootstrap/./isl/include -I/home/seurer/gcc/git/gcc-trunk-bootstrap/isl/include -o dwarf2asm.o -MT dwarf2asm.o -MMD -MP -MF ./.deps/dwarf2asm.TPo /home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/dwarf2asm.c /home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/dwarf2asm.c: In function 'void dw2_assemble_integer(int, rtx)': /home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/dwarf2asm.c:49:12: error: comparison of integer expressions of different signedness: 'int' and 'unsigned int' [-Werror=sign-compare] 49 | if (size == 2 * DWARF2_ADDR_SIZE && !CONST_SCALAR_INT_P (x)) cc1plus: all warnings being treated as errors make[3]: *** [dwarf2asm.o] Error 1 make[3]: Leaving directory `/home/seurer/gcc/git/build/gcc-trunk-bootstrap/gcc'
[Bug bootstrap/98839] [11 regression] compilation failure for dwarf2asm.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98839 seurer at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from seurer at gcc dot gnu.org --- Probably this one: commit 7423731691e898b0581532cf277b1e08a510323a Author: Jakub Jelinek Date: Tue Jan 26 09:20:23 2021 +0100
[Bug bootstrap/98839] [11 regression] compilation failure for dwarf2asm.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98839
--- Comment #2 from Jakub Jelinek ---
That is because most targets define POINTER_SIZE as (condition ? 64 : 32) or
constant while rs6000 as a variable holding it, therefore whether it chooses
unsigned or signed type for it then matters in these cases.
Does:
2021-01-26 Jakub Jelinek
PR bootstrap/98839
* dwarf2asm.c (dw2_assemble_integer): Cast DWARF2_ADDR_SIZE to int
in comparison.
--- gcc/dwarf2asm.c.jj 2021-01-26 09:20:19.242499512 +0100
+++ gcc/dwarf2asm.c 2021-01-26 16:33:20.320710684 +0100
@@ -46,7 +46,7 @@ along with GCC; see the file COPYING3.
void
dw2_assemble_integer (int size, rtx x)
{
- if (size == 2 * DWARF2_ADDR_SIZE && !CONST_SCALAR_INT_P (x))
+ if (size == 2 * (int) DWARF2_ADDR_SIZE && !CONST_SCALAR_INT_P (x))
{
/* On 32-bit targets with -gdwarf64, DImode values with
relocations usually result in assembler errors. Assume
fix this?
[Bug c++/98840] New: Why does baz call the delete operator for moved unique_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98840
Bug ID: 98840
Summary: Why does baz call the delete operator for moved
unique_ptr
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dmitriy.ovdienko at gmail dot com
Target Milestone: ---
I'm trying to evaluate the overhead of the `unique_ptr` and I do not understand
why does Gcc execute the destructor of the `unique_ptr` passed by value?
Let's assume we have two examples of code:
C style:
```
#include
void foo(int* ptr);
void baz(int value)
{
int* ptr = new int(value);
try
{
foo(ptr);
}
catch(...)
{
delete ptr;
throw;
}
}
```
The asm (/O3):
```
baz(int):
pushrbp
pushrbx
mov ebx, edi
mov edi, 4
sub rsp, 8
calloperator new(unsigned long)
mov DWORD PTR [rax], ebx
mov rdi, rax
mov rbp, rax
callfoo(int*)
add rsp, 8
pop rbx
pop rbp
ret
mov rdi, rax
jmp .L2
baz(int) [clone .cold]:
.L2:
call__cxa_begin_catch
mov esi, 4
mov rdi, rbp
calloperator delete(void*, unsigned long)
call__cxa_rethrow
mov rbp, rax
call__cxa_end_catch
mov rdi, rbp
call_Unwind_Resume
```
And C++ style
```
#include
void foo(std::unique_ptr ptr);
void baz(int value)
{
foo(std::make_unique(value));
}
```
The asm (/O3)
```
baz(int):
pushrbp
pushrbx
mov ebx, edi
mov edi, 4
sub rsp, 24
calloperator new(unsigned long)
lea rdi, [rsp+8]
mov DWORD PTR [rax], ebx
mov QWORD PTR [rsp+8], rax
callfoo(std::unique_ptr >)
mov rdi, QWORD PTR [rsp+8]
testrdi, rdi
je .L1
mov esi, 4
calloperator delete(void*, unsigned long) << Here, why do we
need to call the delete operator. It is `foo` who is responsible for that
.L1:
add rsp, 24
pop rbx
pop rbp
ret
mov rbp, rax
jmp .L3
baz(int) [clone .cold]:
```
[Bug lto/85574] [8/9 Regression] LTO bootstapped binaries differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #33 from Eric Botcazou --- The bootstrap-lto.mk patch breaks LTO bootstrap on Windows: you cannot compare executables on this system since they are timestamped. I really don't see the point in this patch, why comparing lto1 and not other compilers?
[Bug c++/98814] Add fix-it hints for missing asterisk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98814 Ivan Sorokin changed: What|Removed |Added CC||vanyacpp at gmail dot com --- Comment #2 from Ivan Sorokin --- PR87850 looks similar. It discusses only pointers, but I think it can be generalized to any type that has operator*: pointers, iterators and smart-pointers.
[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640 --- Comment #20 from Bill Long --- Original customer is asking about the status of this issue.
[Bug target/98737] Atomic operation on x86 no optimized to use flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98737 --- Comment #6 from Ulrich Drepper --- (In reply to Jakub Jelinek from comment #5) > Created attachment 50058 [details] > gcc11-pr98737.patch > > Untested fix. This only handles sub? The same applies to add, or, and, xor. Maybe nand? Can this patch be generalized?
[Bug bootstrap/98839] [11 regression] compilation failure for dwarf2asm.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98839 --- Comment #3 from seurer at gcc dot gnu.org --- I tried that and it now compiles ok.
[Bug fortran/95038] Not treating function result name as a variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95038 --- Comment #6 from Bill Long --- Is there a released version with the fix noted in this bug?
[Bug target/98737] Atomic operation on x86 no optimized to use flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98737 --- Comment #7 from Jakub Jelinek --- The sub fix won't be the same as would add, perhaps xor/or/and can be handled by the same peephole2, but even for that I'm not sure. Though e.g. trying __atomic_or_fetch (&a, b, ...) == 0 doesn't seem to be something people would use.
[Bug bootstrap/98839] [11 regression] compilation failure for dwarf2asm.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98839 --- Comment #4 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:6e44c09b2df7282e0b519f241cf54438ab183b5e commit r11-6915-g6e44c09b2df7282e0b519f241cf54438ab183b5e Author: Jakub Jelinek Date: Tue Jan 26 18:13:07 2021 +0100 dwarf2asm: Fix bootstrap on powerpc*-*-* [PR98839] My recent dwarf2asm.c patch broke powerpc*-*-* bootstrap, while most target define POINTER_SIZE to (cond ? cst1 : cst2) or constant, rs6000 defines it to a variable, and the arbitrarily chosen type of that variable determines whether we get warnings on comparison of that against signed or unsigned ints. Fixed by adding a cast. 2021-01-26 Jakub Jelinek PR bootstrap/98839 * dwarf2asm.c (dw2_assemble_integer): Cast DWARF2_ADDR_SIZE to int in comparison.
[Bug c++/80460] Incorrect fallthrough warning after [[noreturn]] function inside always-true conditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80460 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|NEW CC||mpolacek at gcc dot gnu.org
[Bug c++/98841] New: wrong ‘operator=’ should return a reference to ‘*this’ [-Weffc++]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98841 Bug ID: 98841 Summary: wrong ‘operator=’ should return a reference to ‘*this’ [-Weffc++] Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: o.mandel at menlosystems dot com Target Milestone: --- Created attachment 50059 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50059&action=edit Console output of version 8.3.0 I get unexpected warnings about "'operator=' should return a reference to '*this' [-Weffc++]". This happens for at least versions 8.3.0 and 10.2.0 of g++. The output of the following command is attached for both versions: g++ -v -save-temps -Weffc++ -c t.cpp In the minimal demo used here this only happens for a template member function, but in larger code it can also be observed for a plain member function: see e.g. https://github.com/jbeder/yaml-cpp/issues/970 This might be the same issue as mentioned in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84364#c9 (why the comment asked for that ticket to be reopened)?
[Bug c++/98841] wrong ‘operator=’ should return a reference to ‘*this’ [-Weffc++]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98841 --- Comment #1 from Olaf Mandel --- Created attachment 50060 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50060&action=edit Preprocessed source file of version 8.3.0
[Bug c++/98841] wrong ‘operator=’ should return a reference to ‘*this’ [-Weffc++]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98841 --- Comment #2 from Olaf Mandel --- Created attachment 50061 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50061&action=edit Console output of version 10.2.0
[Bug c++/98841] wrong ‘operator=’ should return a reference to ‘*this’ [-Weffc++]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98841 --- Comment #3 from Olaf Mandel --- Created attachment 50062 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50062&action=edit Preprocessed source file of version 10.2.0
[Bug c++/98841] wrong ‘operator=’ should return a reference to ‘*this’ [-Weffc++]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98841 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2021-01-26 Keywords||diagnostic Ever confirmed|0 |1 Blocks||81930 Status|UNCONFIRMED |NEW Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81930 [Bug 81930] [meta-bug] Issues with -Weffc++
[Bug c++/98840] Why does baz call the delete operator for moved unique_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98840 --- Comment #1 from Jonathan Wakely --- The ABI requires it. The caller is responsible for constructing and destroying the argument.
[Bug c++/98840] Why does baz call the delete operator for moved unique_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98840 --- Comment #2 from Jonathan Wakely --- https://www.youtube.com/watch?v=rHIkrotSwcc discusses exactly this problem. See also https://quuxplusone.github.io/blog/2018/05/02/trivial-abi-101/ This is not a GCC bug.
[Bug ada/98228] [11 Regression] ICE: Assert_Failure atree.adb:931: Error detected at s-gearop.adb:382:34 [a-ngrear.adb:313:7 [a-nllrar.ads:18:1]] on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228 --- Comment #20 from CVS Commits --- The master branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:9c41bcc59c237aaa629e271f88c20a90cb8e0af5 commit r11-6916-g9c41bcc59c237aaa629e271f88c20a90cb8e0af5 Author: Eric Botcazou Date: Tue Jan 26 18:54:26 2021 +0100 Fix PR ada/98228 This is the profiled bootstrap failure for s390x/Linux on the mainline, which has been introduced by the modref pass but actually exposing an existing issue in the maybe_pad_type function that is visible on s390x. The issue is too weak a test for the addressability of the inner component. gcc/ada/ Marius Hillenbrand PR ada/98228 * gcc-interface/utils.c (maybe_pad_type): Test the size of the new packable type instead of its alignment for addressability's sake.
[Bug ada/98228] [11 Regression] ICE: Assert_Failure atree.adb:931: Error detected at s-gearop.adb:382:34 [a-ngrear.adb:313:7 [a-nllrar.ads:18:1]] on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228 --- Comment #21 from CVS Commits --- The releases/gcc-10 branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:f3e3fc277502626677c59e2a7f3dcefa9f9123b5 commit r10-9303-gf3e3fc277502626677c59e2a7f3dcefa9f9123b5 Author: Eric Botcazou Date: Tue Jan 26 18:54:26 2021 +0100 Fix PR ada/98228 This is the profiled bootstrap failure for s390x/Linux on the mainline, which has been introduced by the modref pass but actually exposing an existing issue in the maybe_pad_type function that is visible on s390x. The issue is too weak a test for the addressability of the inner component. gcc/ada/ Marius Hillenbrand PR ada/98228 * gcc-interface/utils.c (maybe_pad_type): Test the size of the new packable type instead of its alignment for addressability's sake.
[Bug ada/98228] [11 Regression] ICE: Assert_Failure atree.adb:931: Error detected at s-gearop.adb:382:34 [a-ngrear.adb:313:7 [a-nllrar.ads:18:1]] on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228 --- Comment #22 from CVS Commits --- The releases/gcc-9 branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:29f721366b718b60d4c72d82e42e1e3d0a6405c2 commit r9-9205-g29f721366b718b60d4c72d82e42e1e3d0a6405c2 Author: Eric Botcazou Date: Tue Jan 26 18:54:26 2021 +0100 Fix PR ada/98228 This is the profiled bootstrap failure for s390x/Linux on the mainline, which has been introduced by the modref pass but actually exposing an existing issue in the maybe_pad_type function that is visible on s390x. The issue is too weak a test for the addressability of the inner component. gcc/ada/ Marius Hillenbrand PR ada/98228 * gcc-interface/utils.c (maybe_pad_type): Test the size of the new packable type instead of its alignment for addressability's sake.
[Bug libstdc++/98842] New: optional's spaceship operations generates wrong code when operator== is not present
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98842
Bug ID: 98842
Summary: optional's spaceship operations generates wrong code
when operator== is not present
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: nunoplopes at sapo dot pt
Target Milestone: ---
struct expr {
std::strong_ordering operator<=>(const expr &rhs) const;
//bool operator==(const expr &rhs) const;
};
int f() {
return std::is_eq(std::optional() <=> std::optional());
//return std::optional() == std::optional();
}
Function f() is compiled to 0 like that. But if you uncomment the
expr::operator== line, it returns 1.
https://gcc.godbolt.org/z/fv85eP
[Bug ada/98228] [11 Regression] ICE: Assert_Failure atree.adb:931: Error detected at s-gearop.adb:382:34 [a-ngrear.adb:313:7 [a-nllrar.ads:18:1]] on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228 Eric Botcazou changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #23 from Eric Botcazou --- Thanks a lot for all the work done for this PR.
[Bug c++/98840] Why does baz call the delete operator for moved unique_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98840 --- Comment #3 from Dmitriy Ovdienko --- > This is not a GCC bug. No it is not. But can we improve that? That approach increases the binary size. In case if `baz` is called from many places, that is going to increase the binary size.
