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")
-
[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 assertions.
[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[] = _cost, _cost, _cost, - _cost, _cost, _cost, _cost, _cost, _cost, + _cost, _cost, _cost, _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 ();
gfc_allocate_using_malloc (, 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
