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

[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.

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

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

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.

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,

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

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

[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

[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

[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

[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]