On Fri, Dec 20, 2019 at 12:29 AM Jakub Jelinek wrote:
>
> Hi!
>
> The following patch optimizes
> decl %eax; cmpl $-1, %eax; jne .Lxx;
> into shorter and even possible to be fused:
> subl $1, %eax; jnc .Lxx;
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, during which
> this peephole2
On Fri, Dec 20, 2019 at 12:26 AM Jakub Jelinek wrote:
>
> On Thu, Dec 19, 2019 at 06:23:59PM +0100, Jakub Jelinek wrote:
> > On Thu, Dec 19, 2019 at 04:50:40PM +0100, Jan Hubicka wrote:
> > > Outputting the move as RIP relative movq would work.
> > > LC12 is string "s" and has nothing to do with
On December 20, 2019 2:13:47 AM GMT+01:00, "Bin.Cheng"
wrote:
>On Fri, Dec 13, 2019 at 11:26 AM bin.cheng
> wrote:
>>
>> Hi,
>>
>> As reported in PR92926, constant ctor is shared translation unit wide
>because of constexpr_call_table,
>> however, during gimplify, the shared ctor could be
Hi,
Previously, limited unrolling was enabled at O2 for powerpc in r278034. At that
time, -fweb and -frename-registers were not enabled together with -funroll-loops
even for -O3. After that, we notice there are some performance degradation on
SPEC2006fp which caused by without web and rnreg.
gcc/analyzer/ChangeLog:
* analyzer.opt (Wanalyzer-use-of-closed-file): New option.
* sm-file.cc (class use_of_closed_file): New file_diagnostic subclass.
(find_file_param): New function.
(fileptr_state_machine::on_stmt): Complain about operations on
closed
This patch adds a simple mechanism for tracking sets of functions
for which a particular property holds, as a pragmatic way to build
knowledge about important APIs into the analyzer without requiring
markup of the user's libc.
gcc/ChangeLog:
* Makefile.in (ANALYZER_OBJS): Add
The analyzer ought to report various file leaks for the reproducer in
PR analyzer/58237, such as:
void f1(const char *str)
{
FILE * fp = fopen(str, "r");
char buf[10];
while (fgets(buf, 10, fp) != NULL)
{
/* Do something with buf */
}
/* Missing call to fclose.
On Wed, 2019-12-11 at 14:48 -0500, David Malcolm wrote:
> On Sat, 2019-12-07 at 08:01 -0700, Jeff Law wrote:
> > On Fri, 2019-11-15 at 20:23 -0500, David Malcolm wrote:
> [...]
> > > diff --git a/gcc/analyzer/analyzer.cc b/gcc/analyzer/analyzer.cc
> > > new file mode 100644
> > > index
This patch uses the class function_set from the previous patch to
generalize the test for an fprintf inside a signal handler to
check for a set of known async-signal-unsafe functions.
gcc/analyzer/ChangeLog:
* analyzer-selftests.cc (selftest::run_analyzer_selftests): Call
On Wed, 18 Dec 2019 18:44:04 +0100
Thomas Schwinge wrote:
> Hi!
>
> On 2019-12-17T22:02:25-0800, Julian Brown
> wrote:
> > This patch series provides support for OpenACC 2.6's manual deep
> > copy (attach/detach) feature.
>
> Thanks.
>
>
> There is high pressure to get this functionality
On Fri, Dec 13, 2019 at 11:26 AM bin.cheng wrote:
>
> Hi,
>
> As reported in PR92926, constant ctor is shared translation unit wide because
> of constexpr_call_table,
> however, during gimplify, the shared ctor could be modified. This patch
> fixes the issue by unsharing
> it before
On Thu, Dec 19, 2019 at 09:30:49PM +0100, Tobias Burnus wrote:
>
> The latter could be "solved" by using %C instead of %L after
> gfc_simplify_expr in gfc_match_stopcode.
> [The "ref" has its own address (e->ref->u.ar->where); hence,
> the a(1,1) error would be still fine.]
> (Though, this
Eric,
On Wed, 18 Dec 2019, Maciej W. Rozycki wrote:
> On Wed, 18 Dec 2019, Eric Botcazou wrote:
>
> > > gcc/ada/
> > > * gcc-interface/Makefile.in (ADA_RTL_DSO_DIR): New variable.
> > > (install-gnatlib): Use it in place of ADA_RTL_OBJ_DIR for shared
> > > library installation.
> > >
>
Hi!
The following patch optimizes
decl %eax; cmpl $-1, %eax; jne .Lxx;
into shorter and even possible to be fused:
subl $1, %eax; jnc .Lxx;
Bootstrapped/regtested on x86_64-linux and i686-linux, during which
this peephole2 triggered 7825 times, ok for trunk?
2019-12-19 Jakub Jelinek
On Thu, Dec 19, 2019 at 06:23:59PM +0100, Jakub Jelinek wrote:
> On Thu, Dec 19, 2019 at 04:50:40PM +0100, Jan Hubicka wrote:
> > Outputting the move as RIP relative movq would work.
> > LC12 is string "s" and has nothing to do with stack protecting.
>
> This should fix it by doing more carefully
build_min_non_dep wasn't setting any location so when we were emitting the
warning in the following test while instantiating a template, it's location
was UNKNOWN_LOCATION. Rather than adding a location_t parameter, let's use
the location from the original expression.
Bootstrapped/regtested on
On 12/19/19 6:29 AM, Eric Botcazou wrote:
Simple LRA algorithms switch off hard register splitting, so there might
a slightly bigger chance for occurring "can find reload register" error
(e.g. when -O0 -fschedule-insns is used). But this error is still not
solved in general case and in my
x-post from here: https://marc.info/?t=15767864485=1=2
diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
index 6341216d1bc..e6d690b75c0 100644
--- a/gcc/config/mips/mips.c
diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
index 6341216d1bc..e6d690b75c0 100644
---
On Thu, Dec 19, 2019 at 03:24:19PM -0500, David Malcolm wrote:
> Currently -fdiagnostics-urls defaults to "auto" and this works
> (e.g. for recent gnome-terminal, and is gracefully discarded by
> konsole5), but there have been reports of incompatibilities of the
> feature with various other
On Thu, Dec 19, 2019 at 12:40:12AM +0100, Jakub Jelinek wrote:
> Hi!
>
> While looking at PR92666, I've spotted a wrong-code issue where we ignore
> any side-effects on arguments passed to ellipsis if they have
> decltype(nullptr) type.
>
> Fixed thusly, bootstrapped/regtested on x86_64-linux
Hi all,
expressions initially have "expr->rank = 0" (cf. gfc_match_rvalue,
called by match_expr). This is later fixed during the resolution in
"expression_rank", which is called by (gfc_)resolve_ref, which in turn
is called by gfc_resolve_expr. Additionally, the resolve_array_ref
ensures
On Mon, 2019-12-16 at 10:39 +0800, 王昊然 wrote:
> > Which revision of gcc is this?
> Using built-in specs.
> COLLECT_GCC=/opt/gcc-10.0-20191208/bin/gcc-10.0-20191208
> COLLECT_LTO_WRAPPER=/opt/gcc-10.0-20191208/bin/../lib/gcc/x86_64-pc-
> linux-gnu/10.0.0/lto-wrapper
> Target: x86_64-pc-linux-gnu
>
Because of this change printers.py has to be updated too.
François
On 11/17/19 10:15 PM, François Dumont wrote:
H1 used to be a reference to the user Hash, now _Hashtable and
unordered types agree on the same Hash type which is more intuitive.
I also chose to not support anymore a stateful
After further work on pretty printers I prefer to stay closer to what is
done currently. It works better with another patch I'll submit one day.
The drawback is that I needed to consider versioned namespace in
template parameters passed to lookup_templ_spec.
François
On 12/9/19 10:15 PM,
On Thu, Dec 19, 2019 at 11:52 AM Richard Sandiford <
richard.sandif...@arm.com> wrote:
> Jason Merrill writes:
> > On 12/12/19 10:16 AM, Richard Sandiford wrote:
> >> As Jason pointed out in the review of the C++ gnu_vector_type_p patch:
> >>
> >>
Hi Srinath,
On 11/14/19 7:13 PM, Srinath Parvathaneni wrote:
Hello,
This patch supports following MVE ACLE intrinsics with binary operand.
vsubq_n_f16, vsubq_n_f32, vbrsrq_n_f16, vbrsrq_n_f32, vcvtq_n_f16_s16,
vcvtq_n_f32_s32, vcvtq_n_f16_u16, vcvtq_n_f32_u32, vcreateq_f16,
vcreateq_f32.
Hi Srinath,
On 11/14/19 7:13 PM, Srinath Parvathaneni wrote:
Hello,
This patch supports following MVE ACLE intrinsics with unary operand.
vctp16q, vctp32q, vctp64q, vctp8q, vpnot.
Please refer to M-profile Vector Extension (MVE) intrinsics [1] for
more details.
[1]
Hi Srinath,
On 11/14/19 7:13 PM, Srinath Parvathaneni wrote:
Hello,
This patch supports following MVE ACLE intrinsics with unary operand.
vmvnq_n_s16, vmvnq_n_s32, vrev64q_s8, vrev64q_s16, vrev64q_s32,
vcvtq_s16_f16, vcvtq_s32_f32,
vrev64q_u8, vrev64q_u16, vrev64q_u32, vmvnq_n_u16,
Hi Srinath,
On 11/14/19 7:12 PM, Srinath Parvathaneni wrote:
Hello,
This patch supports MVE ACLE intrinsics vcvtq_f16_s16, vcvtq_f32_s32,
vcvtq_f16_u16, vcvtq_f32_u32n
vrndxq_f16, vrndxq_f32, vrndq_f16, vrndq_f32, vrndpq_f16, vrndpq_f32,
vrndnq_f16, vrndnq_f32,
vrndmq_f16, vrndmq_f32,
Hi Srinath,
On 11/14/19 7:12 PM, Srinath Parvathaneni wrote:
Hello,
This patch is part of MVE ACLE intrinsics framework.
The patch supports the use of emulation for the double-precision
arithmetic
operations for MVE. This changes are to support the MVE ACLE
intrinsics which
operates on
Andrew Stubbs writes:
> This patch changes the operand predicates such that vector constants are
> permitted during compilation. This prevents ICEs caused by the compiler
> trying to emit such instructions without checking.
That sounds like a target-independent bug though. Why didn't we
On 11/14/19 7:12 PM, Srinath Parvathaneni wrote:
Hello,
This patch supports MVE ACLE intrinsics vst4q_s8, vst4q_s16,
vst4q_s32, vst4q_u8,
vst4q_u16, vst4q_u32, vst4q_f16 and vst4q_f32.
In this patch arm_mve_builtins.def file is added to the source code in
which the
builtins for MVE ACLE
Hello,
The attached patch is a standalone part of a slightly more
general change last discussed here:
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02626.html
Which I re-tested successfully on aarch64-linux (bootstrap
and regression test with --enable-languages=all + local tests
with Ada
Jason Merrill writes:
> On Thu, Dec 19, 2019 at 9:05 AM Christophe Lyon
> wrote:
>
>> On Tue, 17 Dec 2019 at 22:46, Jason Merrill wrote:
>> >
>> > The variable templates patch way back when forgot to add handling here.
>> The
>> > simplest answer seems to be recursing to the underlying
On Thu, Dec 19, 2019 at 04:50:40PM +0100, Jan Hubicka wrote:
> Outputting the move as RIP relative movq would work.
> LC12 is string "s" and has nothing to do with stack protecting.
This should fix it by doing more carefully what *movdi_internal
does. Will bootstrap/regtest it tonight.
Hi Srinath,
On 11/14/19 7:12 PM, Srinath Parvathaneni wrote:
Hello,
This patch is part of MVE ACLE intrinsics framework.
This patches add support to update (read/write) the APSR (Application
Program Status Register)
register and FPSCR (Floating-point Status and Control Register)
register for
This patch changes the operand predicates such that vector constants are
permitted during compilation. This prevents ICEs caused by the compiler
trying to emit such instructions without checking.
The machine instruction does not accept constants, but it is expected
that the RTL optimizers
Normally we only create SVE ACLE functions when arm_sve.h is included.
But for LTO we need to do it at start-up, so that the functions are
already defined when streaming in the LTO objects.
One hitch with doing that is that LTO doesn't yet implement the
simulate_enum_decl langhook. This patch
Jason Merrill writes:
> On 12/12/19 10:16 AM, Richard Sandiford wrote:
>> As Jason pointed out in the review of the C++ gnu_vector_type_p patch:
>>
>> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00173.html
>>
>> the real fix for the XFAILs in acle/general-c++/gnu_vectors_*.C is to
>>
This test:
typedef unsigned int v4si __attribute__ ((vector_size(16)));
typedef unsigned char v16qi __attribute__ ((vector_size(16)));
extern v16qi x;
v4si = x;
ICEs with:
a.c:4:11: internal compiler error: in convert_like_real, at cp/call.c:7670
This started with r260780, which had the
This patch does nothing but replace a mode iterator with the concrete
mode. It has no effect on the generated machine description whatsoever.
This is part of an incremental clean-up of the mode iterators, following
the introduction of vector QI/HI support. The add-with-carry
instructions are
Ping
Richard Sandiford writes:
> pass_return_slot::execute has:
>
> /* Ignore internal functions without direct optabs,
>those are expanded specially and aggregate_value_p
>on their result might result in undesirable warnings
>with some
> On Thu, Dec 19, 2019 at 04:01:31PM +0100, Jan Hubicka wrote:
> > I now get build failure of Firefox with LTO due to:
> >
> > movabsq $.LC12, %rax
> >
> > which is output by:
> >
> > (insn:TI 468 3 849 2 (parallel [
> >
> > (set
On Thu, Dec 19, 2019 at 04:01:31PM +0100, Jan Hubicka wrote:
> I now get build failure of Firefox with LTO due to:
>
> movabsq $.LC12, %rax
>
> which is output by:
>
> (insn:TI 468 3 849 2 (parallel [
>
> (set (mem/v/f/c:DI (plus:DI
IFN_DIV_POW2 currently requires all elements to be shifted by the
same amount, in a similar way as for WIDEN_LSHIFT_EXPR. This patch
enforces that when building the SLP tree.
If in future targets want to support IFN_DIV_POW2 without this
restriction, we'll probably need the kind of
On Thu, Dec 19, 2019 at 9:05 AM Christophe Lyon
wrote:
> On Tue, 17 Dec 2019 at 22:46, Jason Merrill wrote:
> >
> > The variable templates patch way back when forgot to add handling here.
> The
> > simplest answer seems to be recursing to the underlying declaration.
> >
> > Tested
On Wed, 2019-12-04 at 11:11 -0700, Martin Sebor wrote:
> On 11/15/19 6:23 PM, David Malcolm wrote:
> > gcc/ChangeLog:
> > * builtins.def (BUILT_IN_ANALYZER_BREAK): New builtin.
> > (BUILT_IN_ANALYZER_DUMP): New builtin.
> > (BUILT_IN_ANALYZER_DUMP_EXPLODED_NODES): New builtin.
> >
> Hi!
>
> I'd like to ping this patch (with the sizeof (c) -> sizeof (c) / sizeof (c[0])
> testsuite fix Andreas pointed out).
>
> Thanks!
>
> On Tue, Dec 10, 2019 at 10:57:35AM +0100, Jakub Jelinek wrote:
> > 2019-12-10 Jakub Jelinek
> >
> > PR target/92841
> > *
For partial SVE vectors of element X, we want to treat duplicates
of single X elements in the same way as for full vectors of X.
But if a constant instead contains a repeating pattern of X elements,
the transition from one value to the next must happen at container
boundaries rather than element
Hi all,
I have committed the attached patch adding myself to the Write After
Approval section of the MAINTAINERS file.
Cheers,
Stam
(commits r279573, r279575)
2019-12-19 Stam Markianos-Wright
* MAINTAINERS (write_after_approval): Add myself.
diff --git a/MAINTAINERS b/MAINTAINERS
This testcase wasn't fixed by the 66139 patch; split_nonconstant_init_1 was
failing to add a cleanup for an array member of a class (e.g. e1) that will
run if initializing a later member (e.g. e2) throws.
Tested x86_64-pc-linux-gnu, applying to trunk.
* typeck2.c
There were several overlapping PRs about failure to clean up fully
constructed subobjects when an exception is thrown during aggregate
initialization of a temporary. I fixed this for non-temporaries in the
context of 57510, but that fix didn't handle temporaries. So this patch
does
This patch add vector add and sub instruction patterns for V64QI and
V64HI modes.
The instructions used are actually 32-bit as GCN does not support
sub-dword operations in this way, but I believe it ought to be safe for
these operations, provided that the excess bits are ignored properly
On Tue, 17 Dec 2019 at 22:46, Jason Merrill wrote:
>
> The variable templates patch way back when forgot to add handling here. The
> simplest answer seems to be recursing to the underlying declaration.
>
> Tested x86_64-pc-linux-gnu, applying to trunk.
>
> * decl.c
When adding partial SVE modes, I'd remembered to handle reloads
in a similar way to full big-endian SVE vectors, but forgot the
just-as-important mode-change rules.
Tested on aarch64-linux-gnu and applied as r279572.
Richard
2019-12-19 Richard Sandiford
gcc/
*
Partial SVE modes can be picked up and used by the vector_size(N)
attribute.[*] This means that we need to cope with arguments and return
values with partial SVE modes, which previously triggered asserts like:
/* Generic vectors that map to SVE modes with -msve-vector-bits=N are
passed by
Hi,
>> I've noticed that your patch caused a regression:
>> FAIL: gcc.dg/tree-prof/pr77698.c scan-rtl-dump-times alignments
>> "internal loop alignment added" 1
I've created https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93007
Cheers,
Wilco
> > gcc/ChangeLog
> >
> > 2019-12-02 Xiong Hu Luo
> >
> > PR ipa/69678
> > * Makefile.in (GTFILES): Add ipa-profile.c.
> > * cgraph.c (symbol_table::create_edge): Init speculative_id.
> > (cgraph_edge::make_speculative): Add param for setting speculative_id.
> >
> On 2019/12/18 23:48, Jan Hubicka wrote:
> >> The size_info of ipa_size_summary are created by r277424. It should be
> >> duplicated for cloned nodes, otherwise self_size and
> >> estimated_self_stack_size
> >> would be 0, causing param large-function-insns and large-function-growth
> >>
> On 2019-12-19 19:12 +0800, Xi Ruoyao wrote:
> > On 2019-12-19 11:06 +0100, Jan Hubicka wrote:
> > > - /* See if we have linker information about symbol not being used or
> > > - if we need to make guess based on the declaration.
> > > + /* Limitation of gas requires us to output targets of
On 2019-12-19 19:12 +0800, Xi Ruoyao wrote:
> On 2019-12-19 11:06 +0100, Jan Hubicka wrote:
> > - /* See if we have linker information about symbol not being used or
> > - if we need to make guess based on the declaration.
> > + /* Limitation of gas requires us to output targets of symver
> Simple LRA algorithms switch off hard register splitting, so there might
> a slightly bigger chance for occurring "can find reload register" error
> (e.g. when -O0 -fschedule-insns is used). But this error is still not
> solved in general case and in my experience the chance for this error is
>
On 17/12/19 10:04 +0100, Jérôme Lambourg wrote:
Hello,
This patch to libstdc++ configure ensures that pthread_rwlock_t is used only
when pthread is used for gthreads implementation.
The original issue is that VxWorks comes with its native tasking layer and an
optional pthread layer built above
On 2019-12-19 11:06 +0100, Jan Hubicka wrote:
> This is variant of your patch I comitted. It also adds verification so
> we get ICE rather then wrong code. In addition I moved the checks away
> rom used_from_object_file. This function is about non-LTO objects
> linked into the DSO and thus does
On 13/12/19 18:54 +0100, Olivier Hainque wrote:
This change adjusts the libstdc++ configuration for VxWorks
to set ac_has_nanosleep=yes, which enables the use of nanosleep
from the library.
While this technically depends on the kernel configuration
(INCLUDE_POSIX_TIMERS) this is the normal
Hi!
Bernhard mentioned on IRC that || would be better here, while it doesn't
make a difference for the generated code, consistency is good and the
compiler will turn it into | itself.
Committed to trunk.
2019-12-19 Jakub Jelinek
PR fortran/92977
* frontend-passes.c
Stam Markianos-Wright writes:
> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> index f57469b6e23..f40f6432fd4 100644
> --- a/gcc/config/aarch64/aarch64.c
> +++ b/gcc/config/aarch64/aarch64.c
> @@ -21661,6 +21661,68 @@ aarch64_stack_protect_guard (void)
>return
> On 2019-12-18 14:19 +0100, Jan Hubicka wrote:
> > The problem here is that we lie to the compiler (by pretending that
> > foo_v2 is exported from DSO while it is not) and force user to do the
> > same.
> >
> > We support two ways to hide symbol - either at compile time via
> >
Stam Markianos-Wright writes:
> [...]
> @@ -659,6 +666,8 @@ aarch64_simd_builtin_std_type (machine_mode mode,
>return float_type_node;
> case E_DFmode:
>return double_type_node;
> +case E_BFmode:
> + return aarch64_bf16_type_node;
> default:
>
On 05/12/19 17:12 +0100, Christophe Lyon wrote:
On Thu, 5 Dec 2019 at 12:43, Jonathan Wakely wrote:
On 05/12/19 09:00 +0100, Christophe Lyon wrote:
>On Tue, 3 Dec 2019 at 10:16, Jonathan Wakely wrote:
>>
>> On 03/12/19 09:11 +0100, Christophe Lyon wrote:
>> >On Mon, 16 Sep 2019 at 04:34, Tom
70 matches
Mail list logo
