Re: [PATCH] [i386] Optimize __builtin_shuffle when it's used to zero the upper bits of the dest. [PR target/94680]
On Fri, Apr 23, 2021 at 5:13 PM Jakub Jelinek wrote: > > On Fri, Apr 23, 2021 at 12:53:58PM +0800, Hongtao Liu via Gcc-patches wrote: > > + if (!CONST_INT_P (er)) > > + return 0; > > + ei = INTVAL (er); > > + if (i < nelt2 && ei != i) > > + return 0; > > + if (i >= nelt2 > > + && (ei < nelt || ei >= nelt<<1)) > > Formatting: > 1) you have spaces followed by tab, remove the spaces; but, > if (i >= nelt2 && (ei < nelt || ei >= nelt<<1)) >fits on one line, so keep it on one line. > 2) nelt<<1 should be nelt << 1 with spaces around the << > Done. > > -(define_insn "*vec_concatv4si_0" > > - [(set (match_operand:V4SI 0 "register_operand" "=v,x") > > - (vec_concat:V4SI > > - (match_operand:V2SI 1 "nonimmediate_operand" "vm,?!*y") > > - (match_operand:V2SI 2 "const0_operand" " C,C")))] > > +(define_insn "*vec_concat_0" > > + [(set (match_operand:VI124_128 0 "register_operand" "=v,x") > > + (vec_concat:VI124_128 > > + (match_operand: 1 "nonimmediate_operand" "vm,?!*y") > > + (match_operand: 2 "const0_operand" " C,C")))] > >"TARGET_SSE2" > >"@ > > %vmovq\t{%1, %0|%0, %1} > > @@ -22154,6 +22157,24 @@ (define_insn "avx_vec_concat" > > (set_attr "prefix" "maybe_evex") > > (set_attr "mode" "")]) > > > > +(define_insn_and_split "*vec_concat_0" > > Would be better to use a different pattern name, *vec_concat_0 > is already used in the above define_insn. > Use some additional suffix after _0? > Changed to "*vec_concat_0_1" > > + return __builtin_shuffle (x, (v32qi) { 0, 0, 0, 0, 0, 0, 0, 0, > > + 0, 0, 0, 0, 0, 0, 0, 0, > > + 0, 0, 0, 0, 0, 0, 0, 0, > > + 0, 0, 0, 0, 0, 0, 0, 0 }, > > +(v32qi) { 0, 1, 2, 3, 4, 5, 6, 7, > > + 8, 9, 10, 11, 12, 13, 14, 15, > > + 32, 49, 34, 58, 36, 53, 38, 39, > > + 40, 60, 42, 43, 63, 45, 46, 47 }); > > In this testcase the shuffles in the part taking indexes from the zero > vector are nicely randomized. > > > --- /dev/null > > +++ b/gcc/testsuite/gcc.target/i386/avx512f-pr94680.c > > @@ -0,0 +1,78 @@ > > +/* { dg-do compile } */ > > +/* { dg-options "-mavx512bw -mavx512vbmi -O2" } */ > > +/* { dg-final { scan-assembler-times {(?n)vmov[a-z0-9]*[ \t]*%ymm[0-9]} 6} > > } */ > > +/* { dg-final { scan-assembler-not "pxor" } } */ > > + > > + > > +typedef float v16sf __attribute__((vector_size(64))); > > +typedef double v8df __attribute__ ((vector_size (64))); > > +typedef long long v8di __attribute__((vector_size(64))); > > +typedef int v16si __attribute__((vector_size(64))); > > +typedef short v32hi __attribute__ ((vector_size (64))); > > +typedef char v64qi __attribute__ ((vector_size (64))); > > + > > +v8df > > +foo_v8df (v8df x) > > +{ > > + return __builtin_shuffle (x, (v8df) { 0, 0, 0, 0, 0, 0, 0, 0 }, > > + (v8di) { 0, 1, 2, 3, 8, 9, 10, 11 }); > > +} > > + > > +v8di > > +foo_v8di (v8di x) > > +{ > > + return __builtin_shuffle (x, (v8di) { 0, 0, 0, 0, 0, 0, 0, 0 }, > > + (v8di) { 0, 1, 2, 3, 8, 9, 10, 11 }); > > +} > > + > > +v16sf > > +foo_v16sf (v16sf x) > > +{ > > + return __builtin_shuffle (x, (v16sf) { 0, 0, 0, 0, 0, 0, 0, 0, > > +0, 0, 0, 0, 0, 0, 0, 0 }, > > +(v16si) { 0, 1, 2, 3, 4, 5, 6, 7, > > + 16, 17, 18, 19, 20, 21, 22, 23 }); > > +} > > + > > +v16si > > +foo_v16si (v16si x) > > +{ > > +return __builtin_shuffle (x, (v16si) { 0, 0, 0, 0, 0, 0, 0, 0, > > +0, 0, 0, 0, 0, 0, 0, 0 }, > > +(v16si) { 0, 1, 2, 3, 4, 5, 6, 7, > > + 16, 17, 18, 19, 20, 21, 22, 23 }); > > +} > > + > > +v32hi > > +foo_v32hi (v32hi x) > > +{ > > + return __builtin_shuffle (x, (v32hi) { 0, 0, 0, 0, 0, 0, 0, 0, > > + 0, 0, 0, 0, 0, 0, 0, 0, > > + 0, 0, 0, 0, 0, 0, 0, 0, > > + 0, 0, 0, 0, 0, 0, 0, 0 }, > > +(v32hi) { 0, 1, 2, 3, 4, 5, 6, 7, > > + 8, 9, 10, 11, 12, 13, 14, 15, > > + 32, 33, 34, 35, 36, 37, 38, 39, > > + 40,41, 42, 43, 44, 45, 46, 47 }); > > +} > > + > > +v64qi > > +foo_v64qi (v64qi x) > > +{ > > + return __builtin_shuffle (x, (v64qi) { 0, 0, 0, 0, 0, 0, 0, 0, > > + 0, 0, 0, 0, 0, 0, 0, 0, > > + 0, 0, 0, 0, 0, 0, 0, 0, > > + 0, 0, 0, 0, 0, 0, 0, 0, > > + 0, 0,
Re: [PATCH] [Refactor] [AVX512] Combine VI12_AVX512VL with VI48_AVX512VL into VI_AVX512VLBW
On Wed, Dec 2, 2020 at 9:57 AM Hongtao Liu wrote: > > On Wed, Dec 2, 2020 at 8:28 AM Jeff Law wrote: > > > > > > > > On 11/30/20 10:17 PM, Hongtao Liu via Gcc-patches wrote: > > > Hi: > > > There're many pairs of define_insn/define_expand that are very similar > > > to each other except mode iterator and condition. For these patterns > > > VI12_AVX512VL are used under condition TARGET_AVX512BW, and > > > VI48_AVX512VL are used under condition TARGET_AVX512F. > > > > > > This patch is about to introduce a new iterator VI_AVX512VLBW to > > > combine a pair of those patterns into one. > > > > > > There are no functional changes, just code refactoring. > > > > > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? > > > > > > gcc/ChangeLog > > > > > > * config/i386/sse.md (VI_AVX512VLBW): New mode iterator. > > > (_ucmp3): Combine > > > two patterns with mode iterator VI12_AVX512VL and VI48_AVX512VL > > > into one pattern with mode iterator VI_AVX512VLBW. > > > (vec_cmpu): Ditto. > > > (_cvt2mask): Ditto. > > > (_cvtmask2): Ditto. > > > (*_cvtmask2): Ditto. > > > (3_mask): Ditto. > > > (*3_mask): Ditto. > > > (_eq3): Ditto. > > > (_eq3_1): Ditto. > > > (_gt3): Ditto. > > > (_andnot3_mask): Ditto. > > > (abs2_mask): Ditto. > > > (*_3): Combine from ... > > > (*avx512f_3) > > > and (3). > > I'd suggest deferring to gcc-12 unless there is a strong need for this > > cleanup to make fixing a bug easier. > > > > jeff > > > > Sure, I'll wait for GCC-12. > Rebased patch. > -- > BR, > Hongtao -- BR, Hongtao From 51a2fba947b5de779cda4f464cd25b13a21ff99c Mon Sep 17 00:00:00 2001 From: liuhongt Date: Fri, 23 Apr 2021 16:24:14 +0800 Subject: [PATCH] [PATCH] [i386] Combine same patterns with different iterators of VI12_AVX512VL and VI48_AVX512VL into VI1248_AVX512VLBW. gcc/ChangeLog * config/i386/sse.md (_ucmp3): Merge two same patterns with different iterators of VI12_AVX512VL and VI48_AVX512VL into VI1248_AVX512VLBW. (vec_cmpu): Ditto. (_cvt2mask): Ditto. (_cvtmask2): Ditto. (*_cvtmask2): Ditto. (3_mask): Ditto. (*3_mask): Ditto. (_eq3): Ditto. (_eq3_1): Ditto. (_gt3): Ditto. (_andnot3_mask): Ditto. (abs2_mask): Ditto. (*avx512f_3, 3_mask): Merged to .. (3): .. this. --- gcc/config/i386/sse.md | 298 ++--- 1 file changed, 73 insertions(+), 225 deletions(-) diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md index 9d3728d1cb0..fe8cb9c6d13 100644 --- a/gcc/config/i386/sse.md +++ b/gcc/config/i386/sse.md @@ -250,6 +250,14 @@ (define_mode_iterator VI12_AVX512VLBW (V32QI "TARGET_AVX512VL && TARGET_AVX512BW") (V32HI "TARGET_AVX512BW") (V16HI "TARGET_AVX512VL") (V8HI "TARGET_AVX512VL")]) +(define_mode_iterator VI1248_AVX512VLBW + [(V64QI "TARGET_AVX512BW") (V32QI "TARGET_AVX512VL && TARGET_AVX512BW") + (V16QI "TARGET_AVX512VL && TARGET_AVX512BW") + (V32HI "TARGET_AVX512BW") (V16HI "TARGET_AVX512VL && TARGET_AVX512BW") + (V8HI "TARGET_AVX512VL && TARGET_AVX512BW") + V16SI (V8SI "TARGET_AVX512VL") (V4SI "TARGET_AVX512VL") + V8DI (V4DI "TARGET_AVX512VL") (V2DI "TARGET_AVX512VL")]) + (define_mode_iterator VI1_AVX512VL [V64QI (V16QI "TARGET_AVX512VL") (V32QI "TARGET_AVX512VL")]) @@ -3222,22 +3230,8 @@ (define_insn_and_split "*_cmp3" (define_insn "_ucmp3" [(set (match_operand: 0 "register_operand" "=k") (unspec: - [(match_operand:VI12_AVX512VL 1 "register_operand" "v") - (match_operand:VI12_AVX512VL 2 "nonimmediate_operand" "vm") - (match_operand:SI 3 "const_0_to_7_operand" "n")] - UNSPEC_UNSIGNED_PCMP))] - "TARGET_AVX512BW" - "vpcmpu\t{%3, %2, %1, %0|%0, %1, %2, %3}" - [(set_attr "type" "ssecmp") - (set_attr "length_immediate" "1") - (set_attr "prefix" "evex") - (set_attr "mode" "")]) - -(define_insn "_ucmp3" - [(set (match_operand: 0 "register_operand" "=k") - (unspec: - [(match_operand:VI48_AVX512VL 1 "register_operand" "v") - (match_operand:VI48_AVX512VL 2 "nonimmediate_operand" "vm") + [(match_operand:VI1248_AVX512VLBW 1 "register_operand" "v") + (match_operand:VI1248_AVX512VLBW 2 "nonimmediate_operand" "vm") (match_operand:SI 3 "const_0_to_7_operand" "n")] UNSPEC_UNSIGNED_PCMP))] "TARGET_AVX512F" @@ -3444,8 +3438,8 @@ (define_expand "vec_cmp" (define_expand "vec_cmpu" [(set (match_operand: 0 "register_operand") (match_operator: 1 "" - [(match_operand:VI48_AVX512VL 2 "register_operand") - (match_operand:VI48_AVX512VL 3 "nonimmediate_operand")]))] + [(match_operand:VI1248_AVX512VLBW 2 "register_operand") + (match_operand:VI1248_AVX512VLBW 3 "nonimmediate_operand")]))] "TARGET_AVX512F" { bool ok = ix86_expand_mask_vec_cmp (operands[0], GET_CODE (operands[1]), @@ -3454,19 +3448,6 @@ (define_expand "vec_cmpu" DONE; }) -(define_expand "vec_cmpu" - [(set (match_operand: 0 "register_operand") - (mat
[PATCH] analyzer: fix ICE on NULL change.m_expr [PR100244]
PR analyzer/100244 reports an ICE on a -Wanalyzer-free-of-non-heap due to a case where free_of_non_heap::describe_state_change can be passed a NULL change.m_expr for a suitably complicated symbolic value. Bulletproof it by checking for change.m_expr being NULL before dereferencing it. Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. Pushed to trunk for gcc 12 as r12-108-g61bfff562e3b6091d5a0a412a7d496bd523868a8. This ICE is technically a regression for gcc 11. The fix is trivial and confined to the analyzer. OK to push to gcc 11 branch? gcc/analyzer/ChangeLog: PR analyzer/100244 * sm-malloc.cc (free_of_non_heap::describe_state_change): Bulletproof against change.m_expr being NULL. gcc/testsuite/ChangeLog: PR analyzer/100244 * g++.dg/analyzer/pr100244.C: New test. --- gcc/analyzer/sm-malloc.cc| 2 +- gcc/testsuite/g++.dg/analyzer/pr100244.C | 22 ++ 2 files changed, 23 insertions(+), 1 deletion(-) create mode 100644 gcc/testsuite/g++.dg/analyzer/pr100244.C diff --git a/gcc/analyzer/sm-malloc.cc b/gcc/analyzer/sm-malloc.cc index 1d5b8601b1f..f02b73ab90a 100644 --- a/gcc/analyzer/sm-malloc.cc +++ b/gcc/analyzer/sm-malloc.cc @@ -1303,7 +1303,7 @@ public: { /* Attempt to reconstruct what kind of pointer it is. (It seems neater for this to be a part of the state, though). */ -if (TREE_CODE (change.m_expr) == SSA_NAME) +if (change.m_expr && TREE_CODE (change.m_expr) == SSA_NAME) { gimple *def_stmt = SSA_NAME_DEF_STMT (change.m_expr); if (gcall *call = dyn_cast (def_stmt)) diff --git a/gcc/testsuite/g++.dg/analyzer/pr100244.C b/gcc/testsuite/g++.dg/analyzer/pr100244.C new file mode 100644 index 000..261b3cfff57 --- /dev/null +++ b/gcc/testsuite/g++.dg/analyzer/pr100244.C @@ -0,0 +1,22 @@ +// { dg-additional-options "-O1 -Wno-free-nonheap-object" } + +inline void *operator new (__SIZE_TYPE__, void *__p) { return __p; } + +struct __aligned_buffer { + int _M_storage; + int *_M_addr() { return &_M_storage; } +}; + +struct _Hashtable_alloc { + int _M_single_bucket; + int *_M_buckets; + _Hashtable_alloc () { _M_buckets = &_M_single_bucket; } + ~_Hashtable_alloc () { delete _M_buckets; } // { dg-warning "not on the heap" } +}; + +void +test01 (__aligned_buffer buf) +{ + _Hashtable_alloc *tmp = new (buf._M_addr ()) _Hashtable_alloc; + tmp->~_Hashtable_alloc (); +} -- 2.26.3
RE: [RFC] bpf.2: Use standard types and attributes
From: Alexei Starovoitov > Sent: 24 April 2021 00:20 > > On Fri, Apr 23, 2021 at 4:15 PM Alejandro Colomar > wrote: > > > > Some manual pages are already using C99 syntax for integral > > types 'uint32_t', but some aren't. There are some using kernel > > syntax '__u32'. Fix those. > > > > Some pages also document attributes, using GNU syntax > > '__attribute__((xxx))'. Update those to use the shorter and more > > portable C2x syntax, which hasn't been standardized yet, but is > > already implemented in GCC, and available through either --std=c2x > > or any of the --std=gnu... options. > > > > Signed-off-by: Alejandro Colomar > > --- > > man2/bpf.2 | 47 +++ > > 1 file changed, 23 insertions(+), 24 deletions(-) > > > > diff --git a/man2/bpf.2 b/man2/bpf.2 > > index 6e1ffa198..204f01bfc 100644 > > --- a/man2/bpf.2 > > +++ b/man2/bpf.2 > > @@ -188,39 +188,38 @@ commands: > > .EX > > union bpf_attr { > > struct {/* Used by BPF_MAP_CREATE */ > > -__u32 map_type; > > -__u32 key_size;/* size of key in bytes */ > > -__u32 value_size; /* size of value in bytes */ > > -__u32 max_entries; /* maximum number of entries > > - in a map */ > > +uint32_tmap_type; > > +uint32_tkey_size;/* size of key in bytes */ > > +uint32_tvalue_size; /* size of value in bytes */ > > +uint32_tmax_entries; /* maximum number of entries > > +in a map */ > > Nack. > The man page should describe the kernel api the way it is in .h file. And the code below is no more portable that a #pragma'. It is probably worse than __attribute__((aligned(8))) +uint64_t [[gnu::aligned(8)]] value; The standards committee are smoking dope again. At least the '__aligned_u64 value;' form stands a reasonable chance of being converted by cpp into whatever your compiler supports. OTOH the bfp developers want shooting for defining a structure with hidden padding fields. It they ensured that all 64bit fields were aligned they wouldn't need the __aligned_u64 at all. And would be much less likely to leak kernel stack to userspace. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Re: [pushed] Darwin : Adjust darwin_binds_local_p for PIC code [PR100152].
Iain Sandoe wrote: gcc/ChangeLog: PR target/100152 * config/darwin.c (darwin_binds_local_p): Assume that any public symbol might be interposed for PIC code. Update function header comment to reflect current Darwin capability. unfortunately, wider testing showed fallout in sanitizer tests - despite that this is notionally correct - so I’ve reverted it until those fails can be analyzed. Iain
Re: [Patch] PR fortran/100218 - target of pointer from evaluation of function-reference
Hi Paul, > Is there a test for an error with -std=f2003? If not, you should, perhaps, > include one. after checking for the corresponding error message, I found that ptr-func-2.f90 already covers this case. Considering this, I'll rename the current testcase from pr100218.f90 to ptr-func-4.f90. Thanks for the review! Harald
Re: [RFC] bpf.2: Use standard types and attributes
Hello Alexei, On 4/24/21 1:20 AM, Alexei Starovoitov wrote: Nack. The man page should describe the kernel api the way it is in .h file. Why? When glibc uses __size_t (or any other non-standard types) just because the standard doesn't allow it to define some types in some specific header, the manual pages document the equivalent standard type, (i.e., if glibc uses __size_t, we document size_t). The compiler, AFAIK (gcc is CCd, so they can jump in if I'm wrong), using uint32_t in every situation where __u32 is expected. They're both typedefs for the same basic type. I can understand why Linux will keep using u32 types (and their __ user space variants), but that doesn't mean user space programs need to use the same type. If we have a standard syntax for fixed-width integral types (and for anything, actually), the manual pages should probably follow it, whenever possible. Any deviation from the standard (be it C or POSIX) should have a very good reason to be; otherwise, it only creates confusion. Thanks, Alex -- Alejandro Colomar Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/ Senior SW Engineer; http://www.alejandro-colomar.es/
Re: [Patch] PR fortran/100218 - target of pointer from evaluation of function-reference
Hi Harald, Another good one - OK for master but wait a while for 11-branch. I am a bit hesitant about 10-branch because this is not a regression. That said, this is harmless because it is permissive, so I will leave it to you to decide. Is there a test for an error with -std=f2003? If not, you should, perhaps, include one. Thanks Paul On Thu, 22 Apr 2021 at 23:37, Harald Anlauf via Fortran wrote: > Dear Fortranners, > > while analyzing a different PR (PR100154), Tobias pointed out that the > target of a pointer from the evaluation of function-reference is allowed > to be used in a variable definition context and thus as an actual > argument to a function or subroutine. > > This seems to be a more general issue that seems to have been overlooked. > The attached simple patch allows to compile and run the attached example, > which is by the way already yet rejected with -std=f2003. > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > Shall we backport this to (at least) 11? > > Thanks, > Harald > > > Fortran - allow target of pointer from evaluation of function-reference > > Fortran allows the target of a pointer from the evaluation of a > function-reference in a variable definition context (e.g. F2018:R902). > > gcc/fortran/ChangeLog: > > PR fortran/100218 > * expr.c (gfc_check_vardef_context): Extend check to allow pointer > from a function reference. > > gcc/testsuite/ChangeLog: > > PR fortran/100218 > * gfortran.dg/pr100218.f90: New test. > > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: [Patch] PR fortran/100154 - [9/10/11/12 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.c:6131
Hi Harald, It looks good to me! Keep clear of 11-branch until release but OK for the others. Thanks Paul On Fri, 23 Apr 2021 at 00:18, Harald Anlauf via Fortran wrote: > Now with the correct patch attached ... > > Sorry for the confusion! > > --- > > Dear Fortranners, > > we need to check the arguments to the affected GNU intrinsic extensions > properly, and - as pointed out in the PR by Tobias - we need to allow > function references that have a data pointer result. Also the argument > names of the character arguments of the subroutine versions needed a > fix ("c" instead of "count"). > > Regtested on x86_64-pc-linux-gnu. OK for mainline (12)? > OK for backports after 11.1 release? > > Thanks, > Harald > > > PR fortran/100154 - ICE in gfc_conv_procedure_call, at > fortran/trans-expr.c:6131 > > Add appropriate static checks for the character and status arguments to > the GNU Fortran intrinsic extensions fget[c], fput[c]. Extend variable > check to allow a function reference having a data pointer result. > > gcc/fortran/ChangeLog: > > PR fortran/100154 > * check.c (variable_check): Allow function reference having a data > pointer result. > (arg_strlen_is_zero): New function. > (gfc_check_fgetputc_sub): Add static check of character and status > arguments. > (gfc_check_fgetput_sub): Likewise. > * intrinsic.c (add_subroutines): Fix argument name for the > character argument to intrinsic subroutines fget[c], fput[c]. > > gcc/testsuite/ChangeLog: > > PR fortran/100154 > * gfortran.dg/pr100154.f90: New test. > > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
[PATCH][_GLIBCXX_DEBUG] libbacktrace integration
Hi Here is the patch to add backtrace generation on _GLIBCXX_DEBUG assertions thanks to libbacktrace. In addition to this integration I am also improving the generation of the assertion message thanks to the "%.*s" printf format, it avoids an intermediate buffer most of the time. I am also removing the "__" used for uglification to get a nicer output. I can propose it in a dedicated patch if you prefer. I am adding GLIBCXX_3.4.30 abi version to properly export the 2 new weak symbols. Let me know if it isn't necessary. libstdc++: [_GLIBCXX_DEBUG] Add backtrace generation thanks to libbacktrace Add _GLIBCXX_DEBUG_BACKTRACE macro to activate backtrace generation on _GLIBCXX_DEBUG assertions using libbacktrace. * config/abi/pre/gnu.ver: Add GLIBCXX_3.4.30 version and new exports. * include/debug/formatter.h [_GLIBCXX_DEBUG_BACKTRACE]: Include . [_GLIBCXX_DEBUG_BACKTRACE && BACKTRACE_SUPPORTED]: Include . [(!_GLIBCXX_DEBUG_BACKTRACE || !BACKTRACE_SUPPORTED) && _GLIBCXX_USE_C99_STDINT_TR1]: Include . [_GLIBCXX_DEBUG_USE_LIBBACKTRACE] (__gnu_debug::__create_backtrace_state): New. [_GLIBCXX_DEBUG_USE_LIBBACKTRACE] (__gnu_debug::__render_backtrace): New. [_GLIBCXX_DEBUG_USE_LIBBACKTRACE](_Error_formatter::_M_print_backtrace): New. [_GLIBCXX_DEBUG_USE_LIBBACKTRACE](_Error_formatter::_M_backtrace_state): New. (_Error_formatter::_Error_formatter): Outline definition. * src/c++11/debug.cc: Include . (_Print_func_t): New. (print_word): Use '%.*s' format in fprintf to render only expected number of chars. (print_raw(PrintContext&, const char*, ptrdiff_t)): New. (print_function(PrintContext&, const char*, _Print_func_t)): New. (print_type): Use latter. (print_string(PrintContext&, const char*, const _Parameter*, size_t)): Change signature to... (print_string(PrintContext&, const char*, ptrdiff_t, const _Parameter*, size_t)): ...this and adapt. Remove intermediate buffer to render input string. (print_string(PrintContext&, const char*, ptrdiff_t)): New. [_GLIBCXX_DEBUG_USE_LIBBACKTRACE] (print_backtrace(void*, uintptr_t, const char*, int, const char*)): New. (_Error_formatter::_M_error()): Adapt. [_GLIBCXX_DEBUG_USE_LIBBACKTRACE] (__gnu_debug::__create_backtrace_state): New, weak symbol. [_GLIBCXX_DEBUG_USE_LIBBACKTRACE] (__gnu_debug::__render_backtrace): New, weak symbol. * testsuite/util/testsuite_abi.cc: Add new symbol version. * doc/xml/manual/debug_mode.xml: Document _GLIBCXX_DEBUG_BACKTRACE. * doc/xml/manual/using.xml: Likewise. Tested under Linux x86_64. Ok to commit ? François diff --git a/libstdc++-v3/config/abi/pre/gnu.ver b/libstdc++-v3/config/abi/pre/gnu.ver index 5323c7f0604..2606d67d8a9 100644 --- a/libstdc++-v3/config/abi/pre/gnu.ver +++ b/libstdc++-v3/config/abi/pre/gnu.ver @@ -2397,6 +2397,15 @@ GLIBCXX_3.4.29 { } GLIBCXX_3.4.28; +GLIBCXX_3.4.30 { + +# __gnu_debug::__create_backtrace +_ZN11__gnu_debug24__create_backtrace_stateEv; +_ZN11__gnu_debug18__render_backtraceEPvPFiS0_mPKciS2_ES0_; + +} GLIBCXX_3.4.29; + + # Symbols in the support library (libsupc++) have their own tag. CXXABI_1.3 { diff --git a/libstdc++-v3/doc/xml/manual/debug_mode.xml b/libstdc++-v3/doc/xml/manual/debug_mode.xml index 883e8cb4f03..931b09710f3 100644 --- a/libstdc++-v3/doc/xml/manual/debug_mode.xml +++ b/libstdc++-v3/doc/xml/manual/debug_mode.xml @@ -160,6 +160,12 @@ which always works correctly. GLIBCXX_DEBUG_MESSAGE_LENGTH can be used to request a different length. +Note that libstdc++ is able to use + http://www.w3.org/1999/xlink"; + xlink:href="https://github.com/ianlancetaylor/libbacktrace";>libbacktrace + to produce backtraces on error. Use -D_GLIBCXX_DEBUG_BACKTRACE to + activate it. You'll also have to link with libbacktrace + (-lbacktrace) to build your application. Using a Specific Debug Container diff --git a/libstdc++-v3/doc/xml/manual/using.xml b/libstdc++-v3/doc/xml/manual/using.xml index 24543e9526e..9bd0da8c1c5 100644 --- a/libstdc++-v3/doc/xml/manual/using.xml +++ b/libstdc++-v3/doc/xml/manual/using.xml @@ -1128,6 +1128,16 @@ g++ -Winvalid-pch -I. -include stdc++.h -H -g -O2 hello.cc -o test.exe extensions and libstdc++-specific behavior into errors. +_GLIBCXX_DEBUG_BACKTRACE + + + Undefined by default. Considered only if _GLIBCXX_DEBUG + is defined. When defined, checks for http://www.w3.org/1999/xlink"; + xlink:href="https://github.com/ianlancetaylor/libbacktrace";>libbacktrace + support and use it to display backtraces on + debug mode assertion
[PATCH] Synchronize Rocket Lake's processor_names and processor_cost_table with processor_type
Hi Uros, This patch is to synchronize Rocket Lake's processor_names and processor_cost_table with processor_type. Bootstrap is ok, and no regressions for i386/x86-64 testsuite. OK for master? [PATCH] Synchronize Rocket Lake's processor_names and processor_cost_table with processor_type gcc/ChangeLog * common/config/i386/i386-common.c (processor_names): Sync processor_names with processor_type. * config/i386/i386-options.c (processor_cost_table): Sync processor_cost_table with processor_type. --- gcc/common/config/i386/i386-common.c | 2 +- gcc/config/i386/i386-options.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/gcc/common/config/i386/i386-common.c b/gcc/common/config/i386/i386-common.c index 1e6c1590ac4..6a7b5c8312f 100644 --- a/gcc/common/config/i386/i386-common.c +++ b/gcc/common/config/i386/i386-common.c @@ -1743,13 +1743,13 @@ const char *const processor_names[] = "skylake-avx512", "cannonlake", "icelake-client", - "rocketlake", "icelake-server", "cascadelake", "tigerlake", "cooperlake", "sapphirerapids", "alderlake", + "rocketlake", "intel", "geode", "k6", diff --git a/gcc/config/i386/i386-options.c b/gcc/config/i386/i386-options.c index 7e59ccd988d..eafa3d4f715 100644 --- a/gcc/config/i386/i386-options.c +++ b/gcc/config/i386/i386-options.c @@ -726,12 +726,12 @@ static const struct processor_costs *processor_cost_table[] = &icelake_cost, &icelake_cost, &icelake_cost, - &icelake_cost, &skylake_cost, &icelake_cost, &skylake_cost, &icelake_cost, &icelake_cost, + &icelake_cost, &intel_cost, &geode_cost, &k6_cost, -- 2.17.1 Thanks, Lili. 0001-Synchronize-Rocket-Lake-s-processor_names-and-proces.patch Description: 0001-Synchronize-Rocket-Lake-s-processor_names-and-proces.patch
[pushed] Darwin : Adjust darwin_binds_local_p for PIC code [PR100152].
Hi Darwin's dynamic linker supports interposition and lazy symbol binding. If we are generating PIC code and a symbol is public, then it could potentially be indirected via a lazy-resolver stub; we cannot tell at compile-time if this will be done (since the indirection can be the result of adding a -flat-namespace option at link-time). Here we are conservative and assume that any such symbol cannot bind locally. The default implementation for binds_local_p handles undefined, weak and common symbols which are always indirected (for mdynamic-no-pic also). tested on x86_64-darwin, pushed to master, thanks Iain gcc/ChangeLog: PR target/100152 * config/darwin.c (darwin_binds_local_p): Assume that any public symbol might be interposed for PIC code. Update function header comment to reflect current Darwin capability. --- gcc/config/darwin.c | 17 + 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/gcc/config/darwin.c b/gcc/config/darwin.c index 5d173919ee0..36b460a9890 100644 --- a/gcc/config/darwin.c +++ b/gcc/config/darwin.c @@ -3134,16 +3134,25 @@ darwin_file_end (void) /* TODO: Add a language hook for identifying if a decl is a vtable. */ #define DARWIN_VTABLE_P(DECL) 0 -/* Cross-module name binding. Darwin does not support overriding - functions at dynamic-link time, except for vtables in kexts. */ +/* Cross-module name binding. + Darwin's dynamic linker supports interposition and lazy symbol binding. + If we are generating PIC code and a symbol is public, then it could + potentially be indirected via a lazy-resolver stub; we cannot tell at + compile-time if this will be done (since the indirection can be the + result of adding a -flat-namespace option at link-time). Here we are + conservative and assume that any such symbol cannot bind locally. + The default implementation for binds_local_p handles undefined, weak and + common symbols which are always indirected. */ bool darwin_binds_local_p (const_tree decl) { /* We use the "shlib" input to indicate that a symbol should be - considered overridable; only relevant for vtables in kernel modules - on earlier system versions, and with a TODO to complete. */ + considered overridable. Older versions of the kernel also support + interposition for extensions (although this code is a place-holder + until there is an implementation for DARWIN_VTABLE_P). */ bool force_overridable = TARGET_KEXTABI && DARWIN_VTABLE_P (decl); + force_overridable |= MACHOPIC_PURE; return default_binds_local_p_3 (decl, force_overridable /* shlib */, false /* weak dominate */, false /* extern_protected_data */, -- 2.24.1
[Patch, fortran] PR fortran/100245 - ICE on automatic reallocation
Hi All! Proposed patch to: PR100245 - ICE on automatic reallocation. Patch tested only on x86_64-pc-linux-gnu. Add an if clause for handling derived types in the left hand side. Thank you very much. Best regards, José Rui Fortran: Fix ICE with automatic reallocation [PR100136] gcc/fortran/ChangeLog: PR fortran/100245 * trans-expr.c (trans_class_assignment): Add if clause to handle derived type in the LHS. gcc/testsuite/ChangeLog: PR fortran/100245 * gfortran.dg/PR100245.f90: New test. diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c index 213f32b0a67..faced471918 100644 --- a/gcc/fortran/trans-expr.c +++ b/gcc/fortran/trans-expr.c @@ -10995,6 +10995,9 @@ trans_class_assignment (stmtblock_t *block, gfc_expr *lhs, gfc_expr *rhs, class_han = GFC_CLASS_TYPE_P (TREE_TYPE (lse->expr)) ? gfc_class_data_get (lse->expr) : lse->expr; + if (!POINTER_TYPE_P (TREE_TYPE (class_han))) + class_han = gfc_build_addr_expr (NULL_TREE, class_han); + /* Allocate block. */ gfc_init_block (&alloc); gfc_allocate_using_malloc (&alloc, class_han, size, NULL_TREE); diff --git a/gcc/testsuite/gfortran.dg/PR100245.f90 b/gcc/testsuite/gfortran.dg/PR100245.f90 new file mode 100644 index 000..1fc372a0d67 --- /dev/null +++ b/gcc/testsuite/gfortran.dg/PR100245.f90 @@ -0,0 +1,29 @@ +! { dg-do run } +! +! Test the fix for PR100245 +! + +program main_p + + implicit none + + type :: foo_t +integer :: a + end type foo_t + + integer, parameter :: a = 42 + + class(foo_t), allocatable :: val + class(foo_t), allocatable :: rs1 + type(foo_t), allocatable :: rs2 + + allocate(val, source=foo_t(42)) + if (val%a/=a) stop 1 + rs1 = val + if (rs1%a/=a) stop 2 + rs2 = val + if (rs2%a/=a) stop 3 + deallocate(val, rs1, rs2) + stop + +end program main_p