Hi!
As mentioned in the PR, I'm afraid we can't easily move the scatter/gather
verification from vect_analyze_data_refs to vectorizable_{load,store},
because we need to process_use in between on the gsinfo.offset to determine
what statements need to be vectorized and that can be only determined
Hi!
The following patch implements roughly the
https://gcc.gnu.org/ml/gcc-patches/2019-06/msg01330.html
design for worksharing loops (so far not for composite for simd, that will
be the next larger task).
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.
2019-07-03
Hi!
The spec says that reductions should be put on combined parallel for
onto the for and shared on parallel. This patch handles just inscan
reductions that way, doing it right for all reductions will be slightly more
work and once it works, will allow even cleanups. But for inscan it has to
be
Hi!
When working on scan, I've noticed I forgot to emit in loops
that use GOMP_loop_start just to allocate some memory also
GOMP_loop_end_nowait to allow destroying of that worksharing structure on
the libgomp side.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.
The force_reg in or1k_expand_compare is hard coded for SImode, which is fine as
this used to only be used on SI expands. However, with FP support this will
cause issues. In general we should only force the right hand operand to a
register if its an immediate. This patch adds an condition to
This adds support for OpenRISC hardware floating point instructions.
This is enabled with the -mhard-float option.
Double-prevision floating point operations work using register pairing as
specified in: https://openrisc.io/proposals/orfpx64a32. This has just been
added in the OpenRISC
gcc/ChangeLog:
* config.gcc (or1k*-*-*): Add mrori and mror to validation.
* doc/invoke.texi (OpenRISC Options): Add mrori option, rewrite all
documenation to be more clear.
* config/or1k/elf.opt (mboard=, mnewlib): Rewrite documentation to be
more clear.
Fixes bad assembly logic with software divide as reported by Richard Selvaggi.
Also, add a basic test to verify the soft math works when enabled.
gcc/testsuite/ChangeLog:
PR target/90362
* gcc.target/or1k/div-mul-3.c: New test.
libgcc/ChangeLog:
PR target/90362
Volatile memory does not match the memory_operand predicate. This
causes extra extend/mask instructions instructions when reading
from volatile memory. On OpenRISC loading volatile memory can be
treated the same as regular memory loads which supports combined
sign/zero extends. Fixing this
Hello,
It's been about 2 months since I last sent these patches. Sorry for the delay
I ended up getting side tracked finishing the new OpenRISC architecture spec
revision.
New since v1:
- Changed 64-bit FPU operations to use explicit register pairs as per spec
revision suggested by Richard
Hi Richard,
Thanks very much for reviewing my patch. I'll update it as your comments.
Before sending the next version, I've several questions embedded for further
check.
on 2019/7/2 下午8:43, Richard Biener wrote:
> On Wed, 20 Mar 2019, Kewen.Lin wrote:
>
>> +/* { dg-require-effective-target
On 7/2/19 11:54 AM, Indu Bhagat wrote:
> Ping.
> Can someone please review these patches ? We would like to get the
> support for CTF integrated soon.
I'm not sure there's really even consensus that we want CTF support in
GCC. Though I think that the changes you've made in the last several
weeks
On 1/24/19 12:51 PM, Giuliano Belinassi wrote:
> This patch adds two variables named 'TV_CGRAPH_FUNC_EXPANSION' and
> 'TV_CGRAPH_IPA_PASSES' that count the elapsed time of the functions
> 'expand_all_functions' and 'ipa_passes', respectivelly.
>
> The main point of this is that these functions
This Go frontend patch by Than McIntosh revamps the way the exporter
tracks exported types and imported packages that need to be mentioned
in the export data.
The previous implementation wasn't properly handling the case where an
exported non-inlinable function refers to an imported type whose
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.
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 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
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
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
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
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
>>> +++
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
>
>
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
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;
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
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
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
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,
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 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
>
>
>
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
>
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
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
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
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
> *
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) <
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 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
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
>
>
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
>
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
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
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
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
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
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
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):
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
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
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
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
> >
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
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
> > >
>
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:
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
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
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
> 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
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
> 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
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
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
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
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
>> > +++
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
>
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
>
>
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
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
*
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
在 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
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
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
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
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
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);
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
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
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
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.
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,
> }
> }
>
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
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
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 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)) ===
>>
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
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
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`)
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
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
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 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",
在 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
> 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
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
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.
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
> 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
> 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,
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
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
1 - 100 of 114 matches
Mail list logo
