James Greenhalgh writes:
> On Mon, Jun 24, 2019 at 04:33:40PM +0100, Dennis Zhang wrote:
>> Hi,
>>
>> A number of AArch64 define_expand patterns have specified constraints
>> for their operands. But the constraint strings are ignored at expand
>> time and are therefore redundant/useless. We now
DOM can handle different shape refs but fails for bases with
differing TBAA behavior currently. This isn't necessary
and fixed via using OEP_ADDRESS_OF for handling of the base
returned from get_ref_base_and_extent.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2019-
On 2019/7/1 3:30 PM, Richard Biener wrote:
On Fri, 28 Jun 2019, Andrew Pinski wrote:
On Thu, Jun 27, 2019 at 9:55 PM Li Jia He wrote:
On 2019/6/27 11:48 PM, Jeff Law wrote:
On 6/27/19 12:11 AM, Li Jia He wrote:
Hi,
According to the optimizable case described by Qi Feng on
issue 88784,
This removes chrec_not_analyzed_yet, chrec_dont_know, and chrec_known
GC roots in favor of putting them in global_trees[] and hard-wire
chrec_not_analyzed_yet to NULL_TREE.
We don't stream any SCEV state so it's pointless to preload those
nodes. It might possibly make sense to merge global_tree
On Mon, 1 Jul 2019, Jan Hubicka wrote:
> Hi,
> the testcase makes inliner to substitute RESULT_DECL by COMPONENT_REF
> inside CLOBBER statement. This is not allowed and leads to ICE in
> verifier (while I think we should fix code to support this).
> This patch simply makes inliner to watch for thi
On Fri, 28 Jun 2019, Jan Hubicka wrote:
> Hi,
> this patch proceeds with further integrating
> nonoverlapping_component_refs_for_decl_p and nonoverlapping_component_refs_p
> however in bit more careful way then I intended previously (so we do not need
> to xfail testcases and miss disambiguations
On Tue, 2 Jul 2019, Li Jia He wrote:
>
>
> On 2019/7/1 3:30 PM, Richard Biener wrote:
> > On Fri, 28 Jun 2019, Andrew Pinski wrote:
> >
> > > On Thu, Jun 27, 2019 at 9:55 PM Li Jia He wrote:
> > > >
> > > >
> > > >
> > > > On 2019/6/27 11:48 PM, Jeff Law wrote:
> > > > > On 6/27/19 12:11 AM
> On Mon, 1 Jul 2019, Jan Hubicka wrote:
>
> > Hi,
> > the testcase makes inliner to substitute RESULT_DECL by COMPONENT_REF
> > inside CLOBBER statement. This is not allowed and leads to ICE in
> > verifier (while I think we should fix code to support this).
> > This patch simply makes inliner to
Hi,
on aarch64 we get ICEs with -flto because pre-streamed va_arg type
becames main variant of the va_arg types read from the LTO stream.
If the LTo stream was produced by C++ then the variants have CXX_ODR_P
while the main variant, produced by lto frontend is !CXX_ODR_P.
This is harmless because w
On 01/07/2019 16:58, Kyrill Tkachov wrote:
Hi Christophe,
On 6/13/19 4:13 PM, Christophe Lyon wrote:
Hi,
Similar to what already exists for TI msp430 or in TI compilers for
arm, this patch adds support for "noinit" attribute for arm. It's very
similar to the corresponding code in GCC for ms
On 02/07/2019 09:39, Richard Earnshaw wrote:
On 01/07/2019 16:58, Kyrill Tkachov wrote:
Hi Christophe,
On 6/13/19 4:13 PM, Christophe Lyon wrote:
Hi,
Similar to what already exists for TI msp430 or in TI compilers for
arm, this patch adds support for "noinit" attribute for arm. It's very
On Jul 1, 2019, Richard Biener wrote:
> Oh, I see. The GIMPLE frontend is also missing parsing support
> for the EH stmt kinds, it might have been possible to build a testcase
> with that I guess (yeah, only a very slight hint ... ;))
Ooh, beautiful! Is that in the trunk already? I couldn't
On Tue, 2 Jul 2019, Richard Biener wrote:
> On Tue, 2 Jul 2019, Li Jia He wrote:
>
> >
> >
> > On 2019/7/1 3:30 PM, Richard Biener wrote:
> > > On Fri, 28 Jun 2019, Andrew Pinski wrote:
> > >
> > > > On Thu, Jun 27, 2019 at 9:55 PM Li Jia He wrote:
> > > > >
> > > > >
> > > > >
> > > > > O
Bootstrapped and regtested on x86_64-redhat-linux, s390x-redhat-linux
and ppc64le-redhat-linux.
Currently s390 emits the following sequence to store a frame_pc:
a:
.LASANPC0:
lg %r1,.L5-.L4(%r13)
la %r1,0(%r1,%r12)
stg
Hi,
this patch adds the shortcut for must aliases discussed earlier and enables
access path even if bases are proved to be equivalent - it could still do
useful job for arrays etc.
tramp3d stats go from:
Alias oracle query stats:
refs_may_alias_p: 4421560 disambiguations, 4781790 queries
ref_
Hi Iain,
On 6/28/19 1:56 PM, Iain Apreotesei wrote:
gcc/ChangeLog:
2019-06-28 Iain Apreotesei
* config/arm/iterators.md (VRHADD, VHADD): Add, update int_iterators.
(u) new int_attr.
* config/arm/neon.md (avg3_floor, avg3_ceil)
(neon_vhadd, neon_vrhadd): Add new patterns.
> It seems inappropriate to use handles as thread identifiers (as handles
> imply resource ownership and are not unique identifiers); thread IDs (as
> `DWORD` or `unsigned long`) would be a better alternative.
This was considered but ultimately rejected, as you can do nothing with a
thread Id, i.
> s/c++0x/c++11/ please, it hasn't been 0x for eight years now :-)
I suppose I didn't invent it though, so you'll probably find more with grep...
--
Eric Botcazou
Hi Richi,
The 06/25/2019 10:02, Richard Biener wrote:
>
> This looks like a literal 1:1 translation plus merging with the
> existing pattern around integers. You changed
> (op:s@0 (convert@3 @1) (convert?@4 @2)) to
> (op:s@0 (convert1?@3 @1) (convert2?@4 @2)) where this now also
> matches if the
pass_expand::execute does the same job as commit_edge_insertions but manually,
except for a special case if the entry block has a single successor. But we
can extract the special case and just call commit_edge_insertions afterwards.
Tested on x86_64-suse-linux, applied on the mainline.
2019-0
On 02/07/19 11:23 +0200, Eric Botcazou wrote:
s/c++0x/c++11/ please, it hasn't been 0x for eight years now :-)
I suppose I didn't invent it though, so you'll probably find more with grep...
Yes there are definitely still references to C++0x elsewhere in
libstdc++, especially in the testsuite,
> Yes there are definitely still references to C++0x elsewhere in
> libstdc++, especially in the testsuite, but let's not add new ones.
It's libgcc though, not libstdc++. And it's a bit inconvenient to have c++0x
on the one hand (gthr.h) and c++11 on the other hand (gthr-win32-thread.c); in
oth
在 2019/7/2 下午5:19, Eric Botcazou 写道:
>> It seems inappropriate to use handles as thread identifiers (as handles
>> imply resource ownership and are not unique identifiers); thread IDs (as
>> `DWORD` or `unsigned long`) would be a better alternative.
>
> This was considered but ultimately rejected,
On Tue, Jul 2, 2019 at 3:48 AM Martin Sebor wrote:
>
> Attached is a more complete solution that fully resolves the bug
> report by avoiding a warning in cases like:
>
>char a[32], b[8];
>
>void f (void)
>{
> if (strlen (a) < sizeof b - 2)
>snprintf (b, sizeof b, "b=%s", a
On Tue, Jul 2, 2019 at 10:51 AM Alexandre Oliva wrote:
>
> On Jul 1, 2019, Richard Biener wrote:
>
> > Oh, I see. The GIMPLE frontend is also missing parsing support
> > for the EH stmt kinds, it might have been possible to build a testcase
> > with that I guess (yeah, only a very slight hint .
On 02/07/2019 09:39, Richard Earnshaw wrote:
On 01/07/2019 16:58, Kyrill Tkachov wrote:
Hi Christophe,
On 6/13/19 4:13 PM, Christophe Lyon wrote:
Hi,
Similar to what already exists for TI msp430 or in TI compilers for
arm, this patch adds support for "noinit" attribute for arm. It's very
On 02/07/2019 11:57, Liu Hao wrote:
在 2019/7/2 下午5:19, Eric Botcazou 写道:
It seems inappropriate to use handles as thread identifiers (as handles
imply resource ownership and are not unique identifiers); thread IDs (as
`DWORD` or `unsigned long`) would be a better alternative.
This was consider
On 02/07/2019 12:12, Jacek Caban wrote:
On 02/07/2019 11:57, Liu Hao wrote:
在 2019/7/2 下午5:19, Eric Botcazou 写道:
It seems inappropriate to use handles as thread identifiers (as
handles
imply resource ownership and are not unique identifiers); thread
IDs (as
`DWORD` or `unsigned long`) woul
On Tue, 2 Jul 2019, Tamar Christina wrote:
> Hi Richi,
>
> The 06/25/2019 10:02, Richard Biener wrote:
> >
> > This looks like a literal 1:1 translation plus merging with the
> > existing pattern around integers. You changed
> > (op:s@0 (convert@3 @1) (convert?@4 @2)) to
> > (op:s@0 (convert1?@
On 02/07/2019 11:13, Richard Earnshaw wrote:
On 02/07/2019 09:39, Richard Earnshaw wrote:
On 01/07/2019 16:58, Kyrill Tkachov wrote:
Hi Christophe,
On 6/13/19 4:13 PM, Christophe Lyon wrote:
Hi,
Similar to what already exists for TI msp430 or in TI compilers for
arm, this patch adds s
On 7/1/19 7:32 PM, Giuliano Belinassi wrote:
> Hi, Liška
>
> I incorporated all your suggestions to the patch, but before sending the
> v2 I want to discuss some errors reported by the style script.
>
>> === ERROR type #1: blocks of 8 spaces should be replaced with tabs (16
>> error(s)) ===
>> gc
Hi all,
This patch fixes the regression to gcc.dg/rtl/aarch64/subs_adds_sp.c that
r271735 caused. This was done by ensuring that the current function's
frame has
been laid out before checking if return address signing is enabled.
Tested and built on aarch64-none-elf and aarch64-none-linux-gnu.
On Wed, 26 Jun 2019 at 23:45, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > On Wed, 26 Jun 2019 at 16:05, Richard Sandiford
> > wrote:
> >>
> >> Prathamesh Kulkarni writes:
> >> > On Tue, 25 Jun 2019 at 20:05, Richard Sandiford
> >> > wrote:
> >> >>
> >> >> Prathamesh Kulkarni
David Malcolm writes:
> On Mon, 2019-07-01 at 12:50 +0300, Vladislav Ivanishin wrote:
>> Hi!
>>
>> GDB's Python API provides strip_typedefs method that can be
>> instrumental
>> for writing DRY code. Using it at least partially obviates the need
>> for
>> the add_printer_for_types method we hav
Thanks for fixing this.
Prathamesh Kulkarni writes:
> diff --git a/gcc/simplify-rtx.c b/gcc/simplify-rtx.c
> index 89a46a933fa..79bd0cfbd28 100644
> --- a/gcc/simplify-rtx.c
> +++ b/gcc/simplify-rtx.c
> @@ -6697,6 +6697,19 @@ simplify_subreg (machine_mode outermode, rtx op,
> }
> }
>
Clang seems to define built-ins that start with "__builtin_" as
non-keywords, which means that we need to use __has_builtin to detect
them, not __is_identifier. The built-ins that don't start with
"__builtin_" are keywords, and can only be detected using
__is_identifier and not by __has_builtin.
Second part.
Martin
>From a5226ccfdc46459afc3474472197aabf51331a63 Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Tue, 2 Jul 2019 09:08:27 +0200
Subject: [PATCH 2/2] Extend DCE to remove unnecessary new/delete-pairs (PR
c++/23383).
gcc/ChangeLog:
2019-07-02 Martin Liska
Dominik Infu
Hi.
After the discussion with Richi and Nathan, I made a place in tree_function_decl
and I rebased the original Dominik's patch on top of that.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
>From cdf41c7e6d00680b6c7fc31234025aef0091b
On 02/07/19 11:54 +0200, Eric Botcazou wrote:
Yes there are definitely still references to C++0x elsewhere in
libstdc++, especially in the testsuite, but let's not add new ones.
It's libgcc though, not libstdc++. And it's a bit inconvenient to have c++0x
on the one hand (gthr.h) and c++11 on t
On 02/07/19 12:15 +0200, Jacek Caban wrote:
On 02/07/2019 12:12, Jacek Caban wrote:
On 02/07/2019 11:57, Liu Hao wrote:
在 2019/7/2 下午5:19, Eric Botcazou 写道:
It seems inappropriate to use handles as thread identifiers
(as handles
imply resource ownership and are not unique identifiers);
thre
On 02/07/19 12:56 +0100, Jonathan Wakely wrote:
On 02/07/19 11:54 +0200, Eric Botcazou wrote:
Yes there are definitely still references to C++0x elsewhere in
libstdc++, especially in the testsuite, but let's not add new ones.
It's libgcc though, not libstdc++. And it's a bit inconvenient to h
This patch fixes a regrename ICE that affects testcase
gfortran.dg/optional_absent_4.f90.
The problem was that the save-restore pattern for the SCC register
conflicted with the live value in that register. That is, it looked fine
in the dump files and assembler output, but broken the assumptio
On Tue, 2 Jul 2019 at 16:59, Richard Sandiford
wrote:
>
> Thanks for fixing this.
>
> Prathamesh Kulkarni writes:
> > diff --git a/gcc/simplify-rtx.c b/gcc/simplify-rtx.c
> > index 89a46a933fa..79bd0cfbd28 100644
> > --- a/gcc/simplify-rtx.c
> > +++ b/gcc/simplify-rtx.c
> > @@ -6697,6 +6697,19 @@
On 26/06/19 19:13 -0400, Ed Smith-Rowland via libstdc++ wrote:
Here is the first of three patches for C++20 constexpr library.
?? Implement C++20 p0202 - Add constexpr Modifiers to Functions in
and Headers.
??Implement C++20 p1023 - constexpr comparison operators for std::array.
I
在 2019/7/2 下午8:00, Jonathan Wakely 写道:
> The C++ standard says:
>
> "The library may reuse the value of a thread::id of a terminated
> thread that can no longer be joined."
>
> So that's not a reason to use a handle.
According to MSDN [1] a thread ID is valid 'until the thread has been
terminate
On 02/07/19 20:14 +0800, Liu Hao wrote:
在 2019/7/2 下午8:00, Jonathan Wakely 写道:
The C++ standard says:
"The library may reuse the value of a thread::id of a terminated
thread that can no longer be joined."
So that's not a reason to use a handle.
According to MSDN [1] a thread ID is valid 'unt
This patch makes lto-dump the symtab callgraph in graphviz DOT format.
Previously, the suggested patch had some minor and checkstyle issues
that were fixed in this version.
gcc/ChangeLog
2019-07-02 Giuliano Belinassi
* cgraph.c (dump_graphviz): New function
*
Hi.
The patch is about a new option that can be handy when you pipe
output and you do not use an object file.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
2019-07-02 Martin Liska
* common.opt: Add fprofi
On 7/2/19 2:36 PM, Giuliano Belinassi wrote:
> This patch makes lto-dump the symtab callgraph in graphviz DOT format.
>
> Previously, the suggested patch had some minor and checkstyle issues
> that were fixed in this version.
>
>
> gcc/ChangeLog
> 2019-07-02 Giuliano Belinassi
>
>
On Wed, 20 Mar 2019, Kewen.Lin wrote:
> Hi,
>
> Please refer to below link for previous threads.
> https://gcc.gnu.org/ml/gcc-patches/2019-03/msg00348.html
>
> Comparing to patch v2, I've moved up the vector operation target
> check upward together with vector type target check. Besides, I
> r
Prathamesh Kulkarni writes:
> On Tue, 2 Jul 2019 at 16:59, Richard Sandiford
> wrote:
>>
>> Thanks for fixing this.
>>
>> Prathamesh Kulkarni writes:
>> > diff --git a/gcc/simplify-rtx.c b/gcc/simplify-rtx.c
>> > index 89a46a933fa..79bd0cfbd28 100644
>> > --- a/gcc/simplify-rtx.c
>> > +++ b/gcc/
Hi Ilya,
On Tue, Jul 02, 2019 at 10:51:54AM +0200, Ilya Leoshkevich wrote:
> +#undef TARGET_INSN_ALIGNMENT
> +#define TARGET_INSN_ALIGNMENT 16
There already is FUNCTION_BOUNDARY for something similar, which fits in
well with STACK_BOUNDARY, PARM_BOUNDARY, many more *_BOUNDARY. I realise
you may
On Tue, Jul 02, 2019 at 08:02:16AM -0500, Segher Boessenkool wrote:
> On Tue, Jul 02, 2019 at 10:51:54AM +0200, Ilya Leoshkevich wrote:
> > +#undef TARGET_INSN_ALIGNMENT
> > +#define TARGET_INSN_ALIGNMENT 16
>
> There already is FUNCTION_BOUNDARY for something similar, which fits in
> well with ST
On Tue, 2019-07-02 at 14:29 +0300, Vladislav Ivanishin wrote:
> David Malcolm writes:
>
> > On Mon, 2019-07-01 at 12:50 +0300, Vladislav Ivanishin wrote:
> > > Hi!
> > >
> > > GDB's Python API provides strip_typedefs method that can be
> > > instrumental
> > > for writing DRY code. Using it at
> Am 02.07.2019 um 15:19 schrieb Segher Boessenkool
> :
>
> On Tue, Jul 02, 2019 at 08:02:16AM -0500, Segher Boessenkool wrote:
>> On Tue, Jul 02, 2019 at 10:51:54AM +0200, Ilya Leoshkevich wrote:
>>> +#undef TARGET_INSN_ALIGNMENT
>>> +#define TARGET_INSN_ALIGNMENT 16
>>
>> There already is FUNC
On Tue, Jul 02, 2019 at 03:33:28PM +0200, Ilya Leoshkevich wrote:
> > Am 02.07.2019 um 15:19 schrieb Segher Boessenkool
> > :
> >
> > On Tue, Jul 02, 2019 at 08:02:16AM -0500, Segher Boessenkool wrote:
> >> On Tue, Jul 02, 2019 at 10:51:54AM +0200, Ilya Leoshkevich wrote:
> >>> +#undef TARGET_INS
> Am 02.07.2019 um 15:39 schrieb Jakub Jelinek :
>
> On Tue, Jul 02, 2019 at 03:33:28PM +0200, Ilya Leoshkevich wrote:
>>> Am 02.07.2019 um 15:19 schrieb Segher Boessenkool
>>> :
>>>
>>> On Tue, Jul 02, 2019 at 08:02:16AM -0500, Segher Boessenkool wrote:
On Tue, Jul 02, 2019 at 10:51:54A
On Tue, Jul 02, 2019 at 03:55:56PM +0200, Ilya Leoshkevich wrote:
> > Am 02.07.2019 um 15:39 schrieb Jakub Jelinek :
> > On Tue, Jul 02, 2019 at 03:33:28PM +0200, Ilya Leoshkevich wrote:
> >>> Am 02.07.2019 um 15:19 schrieb Segher Boessenkool
> >>> :
> >>>
> >>> On Tue, Jul 02, 2019 at 08:02:16AM
This is the second piece for allowing inline expansion of memmove. Now that
the old movmem patterns have all been renamed to cpymem, the movmem optab can
be added back.
Next piece will be: add support for __builtin_memmove() to use the movmem optab
and
associated patterns.
This patch passes boot
Hi,
While running the GCC testsuite with an armv8-m target, I noticed that
a few tests where causing the BFD linker to crash. I opened PR
ld/24709 for this [1], but fixing it properly is tricky and not worth
the headache.
I "fixed" the linker so that it emits a useful error message instead
of cr
On Tue, 2 Jul 2019 at 12:30, Richard Earnshaw wrote:
>
>
>
> On 02/07/2019 11:13, Richard Earnshaw wrote:
> >
> >
> > On 02/07/2019 09:39, Richard Earnshaw wrote:
> >>
> >>
> >> On 01/07/2019 16:58, Kyrill Tkachov wrote:
> >>> Hi Christophe,
> >>>
> >>> On 6/13/19 4:13 PM, Christophe Lyon wrote:
>
On Wed, 2019-06-26 at 15:05 +, Andrea Corallo wrote:
> David Malcolm writes:
>
> > On Tue, 2019-06-25 at 08:11 +, Andrea Corallo wrote:
> > > Hi,
> > > third version for this patch with the simplified test.
> > >
> > > make check-jit pass clean
> > >
> > > Bests
> > > Andrea
> > >
> >
Hi David, Andrea,
On 7/2/19 3:46 PM, David Malcolm wrote:
On Wed, 2019-06-26 at 15:05 +, Andrea Corallo wrote:
> David Malcolm writes:
>
> > On Tue, 2019-06-25 at 08:11 +, Andrea Corallo wrote:
> > > Hi,
> > > third version for this patch with the simplified test.
> > >
> > > make check-
Hi Kyrill,
On Mon, 1 Jul 2019 at 17:58, Kyrill Tkachov wrote:
>
> Hi Christophe,
>
> On 6/13/19 4:13 PM, Christophe Lyon wrote:
> > Hi,
> >
> > Similar to what already exists for TI msp430 or in TI compilers for
> > arm, this patch adds support for "noinit" attribute for arm. It's very
> > simila
David Malcolm writes:
>> Hi David,
>> I can work on to get the SVN commit access.
>> As a maintainer has to sponsor it would you mind being the one?
>
> https://www.gnu.org/software/gcc/svnwrite.html says:
> "a well-established GCC maintainer (including reviewers) can approve
> for write access
Bootstrap and regtest running on x86_64-redhat-linux, s390x-redhat-linux
and ppc64le-redhat-linux.
Currently s390 emits the following sequence to store a frame_pc:
a:
.LASANPC0:
lg %r1,.L5-.L4(%r13)
la %r1,0(%r1,%r12)
stg
On 7/2/19 9:01 AM, Christophe Lyon wrote:
Hi Kyrill,
On Mon, 1 Jul 2019 at 17:58, Kyrill Tkachov wrote:
Hi Christophe,
On 6/13/19 4:13 PM, Christophe Lyon wrote:
Hi,
Similar to what already exists for TI msp430 or in TI compilers for
arm, this patch adds support for "noinit" attribute for
Attached patch improves the split condition from using
TARGET_MMX_WITH_SSE to TARGET_SSEx && SSE_REGNO_P, which is what these
splitters really split.
2019-07-02 Uroš Bizjak
* config/i386/mmx.md (mmx_packswb):
Use TARGET_SSE2 && SSE_REGNO_P in split condition.
(mmx_packssdw): Ditto.
On 7/2/19 5:49 AM, Martin Liška wrote:
Hi.
After the discussion with Richi and Nathan, I made a place in tree_function_decl
and I rebased the original Dominik's patch on top of that.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
FWIW, I think there is a choice between
Hi All,
Here's an updated patch with the changes processed from the previous review.
I've bootstrapped and regtested on aarch64-none-linux-gnu and
x86_64-pc-linux-gnu and no issues.
Ok for trunk?
Thanks,
Tamar
The 07/02/2019 11:20, Richard Biener wrote:
> On Tue, 2 Jul 2019, Tamar Christina
This patch by Cherry Zhang changes the Go frontend to use the builtin
memset function for zeroing a range of memory that doesn't contain any
pointers. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.
Committed to mainline.
Ian
2019-07-02 Cherry Zhang
* go-gcc.cc (Gcc_backend::Gcc_ba
On Tue, Jul 02, 2019 at 05:01:33PM +0200, Christophe Lyon wrote:
> On Mon, 1 Jul 2019 at 17:58, Kyrill Tkachov
> wrote:
> > +static tree
> > +arm_data_attr (tree * node,
> > + tree name,
> > + tree args ATTRIBUTE_UNUSED,
> > + intflags ATTRI
On Tue, 2 Jul 2019, Martin Liška wrote:
After the discussion with Richi and Nathan, I made a place in tree_function_decl
and I rebased the original Dominik's patch on top of that.
So, last time there were some questions about the legality of this
transformation. Did you change the exact set o
Ping.
Can someone please review these patches ? We would like to get the
support for CTF integrated soon.
Thanks
Indu
On Wed, Jun 26, 2019 at 11:38 PM Indu Bhagat wrote:
>
> Hello,
>
> This patch series adds support for CTF generation in GCC.
>
> [Changes from V2]
> - Patch 1, 2, and 3 have mino
On 7/2/19 8:32 AM, Aaron Sawdey wrote:
> This is the second piece for allowing inline expansion of memmove. Now that
> the old movmem patterns have all been renamed to cpymem, the movmem optab can
> be added back.
>
> Next piece will be: add support for __builtin_memmove() to use the movmem
> opt
On 7/2/19 6:37 AM, Martin Liška wrote:
> Hi.
>
> The patch is about a new option that can be handy when you pipe
> output and you do not use an object file.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
>
> gcc/ChangeLog
On Tue, Jun 18, 2019 at 8:58 AM H.J. Lu wrote:
>
> On Tue, Jun 11, 2019 at 8:14 AM H.J. Lu wrote:
> >
> > For op_by_pieces operations between two areas of memory, this patch adds
> > -fminimize-op-by-pieces-run to minimize number of operations. When
> > operating on LENGTH bytes of memory, it st
On 7/2/19 6:36 AM, Giuliano Belinassi wrote:
> This patch makes lto-dump the symtab callgraph in graphviz DOT format.
>
> Previously, the suggested patch had some minor and checkstyle issues
> that were fixed in this version.
>
>
> gcc/ChangeLog
> 2019-07-02 Giuliano Belinassi
>
>
On 7/2/19 3:59 AM, Richard Biener wrote:
> On Tue, Jul 2, 2019 at 3:48 AM Martin Sebor wrote:
>>
>> Attached is a more complete solution that fully resolves the bug
>> report by avoiding a warning in cases like:
>>
>>char a[32], b[8];
>>
>>void f (void)
>>{
>> if (strlen (a) < siz
On 7/1/19 3:35 AM, Martin Liška wrote:
> Hi.
>
> The patch is about use-after-scope. However, I can't verify
> it survives bootstrap on the affected target.
>
> Ready for the trunk?
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> 2019-07-01 Martin Liska
>
> PR target/88056
> * config/
On 7/1/19 2:52 AM, Aldy Hernandez wrote:
> As discussed before, this enforces types on undefined and varying, which
> makes everything more regular, and removes some special casing
> throughout range handling.
>
> The min/max fields will contain TYPE_MIN_VALUE and TYPE_MAX_VALUE, which
> will make
On 6/29/19 9:51 AM, Segher Boessenkool wrote:
> On Mon, Jun 17, 2019 at 01:13:43PM -0600, Jeff Law wrote:
>>> (Hopefully one day GET_MODE_SIZE & co. will assert on BLKmode and VOIDmode.)
>> Yea. Not sure why. There's probably a compile-time hit, but I suspect
>> it'd turn up some interesting bugs
On 6/28/19 12:46 PM, Richard Sandiford wrote:
> Segher Boessenkool writes:
>> On Fri, Jun 28, 2019 at 08:55:00AM -0600, Martin Sebor wrote:
>>> Jeff reminded me in a code review the other day that GCC does
>>> have a guideline for defining POD structs with the keyword
>>> "struct" and classes with
On 7/1/19 4:59 AM, Martin Liška wrote:
> Hi.
>
> Ok, so there's a version with added ChangeLog that survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
>
>
> 0001-Add-.gnu.lto_.lto-section.patch
>
> From e6745583dc4b7f5543878c0a25498e818531f73e Mon Sep 17 00:00:00 2001
> F
On 7/1/19 5:00 AM, Martin Liška wrote:
> Hi.
>
> This is updated version of the zstd patch that should handle all what Joseph
> pointed out.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
>
>
> 0002-Add-zstd-support-for-
On 6/30/19 3:50 PM, Martin Sebor wrote:
> On 6/26/19 6:11 PM, Jeff Law wrote:
[ Another big snip ]
>
>> Is there a strong need for an overloaded operator? Our guidelines
>> generally discourage operator overloads. This one seems on the border
>> to me. Others may have different ideas where the
On 7/1/19 3:02 AM, Aldy Hernandez wrote:
> As discussed prior. This enforces canonicalization at creation time,
> which makes things a lot more consistent throughout.
>
> Since now [MIN, MAX] will be canonicalized into VR_VARYING, we can no
> longer depend on normalizing VARYING's into [MIN, MAX]
Regression tested running plugin.exp testing gcc configured with
--enable-checking=all (failure fixed),
--enable-checking=yes, and without --enable-checking (both no change).
2019-07-02 Joern Rennecke
PR testsuite/91065
* testsuite/gcc.dg/plugin/start_unit_plugin.c: Register a
David Malcolm writes:
> On Tue, 2019-07-02 at 14:29 +0300, Vladislav Ivanishin wrote:
>> David Malcolm writes:
>>
>> > On Mon, 2019-07-01 at 12:50 +0300, Vladislav Ivanishin wrote:
>> > > Hi!
>> > >
>> > > GDB's Python API provides strip_typedefs method that can be
>> > > instrumental for writ
On 7/1/19 7:47 PM, Martin Sebor wrote:
> Attached is a more complete solution that fully resolves the bug
> report by avoiding a warning in cases like:
>
> char a[32], b[8];
>
> void f (void)
> {
> if (strlen (a) < sizeof b - 2)
> snprintf (b, sizeof b, "b=%s", a); // no -Wformat-
Vladislav Ivanishin writes:
> Hi!
>
> It is nice to be able to reload the pretty printers and convenience
> functions from gdbhooks.py without exiting GDB: reloading cc1 takes
> several seconds (plus, the debugging session is lost).
>
> Previously:
>
>(gdb) python import imp; imp.reload(gdbho
So a couple of things can come into play that make this test target
dependent.
First, on some targets we emit a loop to zero the objects. Thankfully
we can use -Os which gets us an empty constructor node again. That
seems to make several unhappy targets happy again.
On i?86 (and perhaps other
On 7/2/19 3:52 PM, Joern Wolfgang Rennecke wrote:
> Regression tested running plugin.exp testing gcc configured with
> --enable-checking=all (failure fixed),
> --enable-checking=yes, and without --enable-checking (both no change).
>
> pr91065-patch.txt
>
> 2019-07-02 Joern Rennecke
>
>
On 7/1/19 4:28 AM, Martin Liška wrote:
> On 6/27/19 7:24 PM, Richard Sandiford wrote:
>> Martin Liška writes:
>>> diff --git a/gcc/config/i386/i386-expand.c b/gcc/config/i386/i386-expand.c
>>> index d50b811d863..1bd251ea8e2 100644
>>> --- a/gcc/config/i386/i386-expand.c
>>> +++ b/gcc/config/i386/i
On 6/28/19 7:39 AM, Claudiu Zissulescu wrote:
> When entering an interrupt, not only the call save registers needs to
> be place on stack but also the call clobbers one. More over, the
> ARC700 return from interrupt instruction needs to be rtie, the same
> like ARCv2 CPUs. While the ARC6xx family u
On Mon, Jul 01, 2019 at 04:27:05PM -0500, Segher Boessenkool wrote:
> The entry before the 8 is split as well. Maybe that should be "4", to
> stand out? I don't know what works better; your choice.
I'll look into it. Note, the length is used in two places. One at the end to
generate the approp
On 6/27/19 7:20 AM, Martin Liška wrote:
> On 6/18/19 12:16 PM, Jakub Jelinek wrote:
>> I think any such length changes should be moved after the two punt checks.
>> Move also the len3 setting before the new checks (of course conditional on
>> is_ncmp).
> Ok, I'm sending updated version of the patch
On 6/18/19 2:58 AM, Martin Liška wrote:
> Hi.
>
> The patch is quite obvious, it copies the same what we do in
> another IPA passes.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> 2019-06-18 Marti
On 6/26/19 2:06 PM, Mark Wielaard wrote:
> Even if there was no, or an empty address list we would try to generate
> and index for the .debug_addr section with -gdwarf-5 and -gsplit-dwarf.
> The skeleton DIE would also get a (dangling) DW_AT_addr_base in that case.
>
> PR debug/90981
>
On Tue, Jul 02, 2019 at 07:36:21PM -0400, Michael Meissner wrote:
> On Mon, Jul 01, 2019 at 04:27:05PM -0500, Segher Boessenkool wrote:
> > The entry before the 8 is split as well. Maybe that should be "4", to
> > stand out? I don't know what works better; your choice.
>
> I'll look into it. No
1 - 100 of 115 matches
Mail list logo