On Fri, Oct 21, 2016 at 1:33 AM, Joseph Myers wrote:
> On Fri, 21 Oct 2016, Uros Bizjak wrote:
>
>> 2016-10-21 Uros Bizjak
>>
>> * config/i386/i386.c (ix86_fold_builtin): Handle IX86_BUILTIN_INFQ
>> and IX86_BUILTIN_HUGE_VALQ here ...
>> (ix86_expand_builtin): ... not here.
>>
>> Bo
On Fri, 21 Oct 2016, kugan wrote:
> Hi,
>
> On 20/10/16 23:15, Jan Hubicka wrote:
> > > Hi Richard,
> > >
> > >
> > > On 20/10/16 18:41, Richard Biener wrote:
> > > > On Thu, 20 Oct 2016, kugan wrote:
> > > >
> > > > >
> > > > >
> > > > > On 20/10/16 01:26, Jan Hubicka wrote:
> > > > > > > >
> Because boolean_type_node was different? Well, are really _all_ boolean
> types this way or can you keep using BOOLEAN_TYPE for boolean_type_node for
> things like interfacing to C and C++ (and the builtins, etc.) and use
> ENUMERAL_TYPE for the cases where bool can have non zero/one values?
Th
On 21/10/16 18:16, Richard Biener wrote:
On Fri, 21 Oct 2016, kugan wrote:
Hi,
On 20/10/16 23:15, Jan Hubicka wrote:
Hi Richard,
On 20/10/16 18:41, Richard Biener wrote:
On Thu, 20 Oct 2016, kugan wrote:
On 20/10/16 01:26, Jan Hubicka wrote:
Would excluding weak symbols (I believe I
On Thu, Oct 20, 2016 at 6:32 PM, Bin.Cheng wrote:
> On Wed, Oct 12, 2016 at 9:50 AM, Richard Biener
> wrote:
>> On Wed, Oct 12, 2016 at 10:29 AM, Bin.Cheng wrote:
>>> On Wed, Oct 12, 2016 at 9:12 AM, Richard Biener
>>> wrote:
On Tue, Oct 11, 2016 at 5:03 PM, Bin Cheng wrote:
> Hi,
>>>
> Btw, isn't this the issue? You'd need to avoid this as well I guess:
>
> /* Special case comparing booleans against a constant as we
> know the value of OP0 on both arms of the branch. i.e., we
> can record an equivalence for OP0 rather than COND.
>
>
> That's also overcomplicated.
Yes, I agree that's too heavy.
> rtx *ptail = ®_NOTES (to_insn);
> while (*ptail != NULL_RTX)
>ptail = &XEXP (*ptail, 1);
>
> gives you a pointer to the end which you can then use to append,
> unconditionally. As mentioned above, I think it would be simpler to
On 20 October 2016 at 18:51, Jonathan Wakely wrote:
> On 20/10/16 10:40 +0100, Jonathan Wakely wrote:
>>
>> Please CC the libstdc++ list for libstdc++ patches, this is a
>> requirement for patch submission, see https://gcc.gnu.org/lists.html
>>
>>
>> On 20/10/16 09:55 +0200, Christophe Lyon wrote:
[ccying Ramana]
On 20 October 2016 at 18:34, Jonathan Wakely wrote:
> On 20/10/16 09:26 -0700, Mike Stump wrote:
>>
>> On Oct 20, 2016, at 5:20 AM, Jonathan Wakely wrote:
>>>
>>>
>>> I am considering leaving this in the ARM backend to force people to
>>> think what they want to do about thread s
On Thu, Oct 20, 2016 at 11:33:14PM +, Joseph Myers wrote:
> On Fri, 21 Oct 2016, Uros Bizjak wrote:
>
> > 2016-10-21 Uros Bizjak
> >
> > * config/i386/i386.c (ix86_fold_builtin): Handle IX86_BUILTIN_INFQ
> > and IX86_BUILTIN_HUGE_VALQ here ...
> > (ix86_expand_builtin): ... not
On Thu, 20 Oct 2016, Jeff Law wrote:
> On 09/30/2016 07:22 AM, Tamar Christina wrote:
> > Hi All,
> >
> > This is v2 of the patch which adds an optimized route to the fpclassify
> > builtin
> > for floating point numbers which are similar to IEEE-754 in format.
> >
> > I have addressed most comm
On Fri, 21 Oct 2016, kugan wrote:
>
>
> On 21/10/16 18:16, Richard Biener wrote:
> > On Fri, 21 Oct 2016, kugan wrote:
> >
> > > Hi,
> > >
> > > On 20/10/16 23:15, Jan Hubicka wrote:
> > > > > Hi Richard,
> > > > >
> > > > >
> > > > > On 20/10/16 18:41, Richard Biener wrote:
> > > > > > On T
On Fri, Oct 7, 2016 at 2:08 PM, Andrew Pinski wrote:
> Hi,
> This patch adds ilp32 multi-arch support. This is needed to support
> multi-arch on Debian like systems.
>
> OK? Bootstrapped and tested on aarch64-linux-gnu with no regressions.
> Also tested with ilp32 with a newly built toolchain
On Fri, Oct 21, 2016 at 9:40 AM, Eric Botcazou wrote:
>> Btw, isn't this the issue? You'd need to avoid this as well I guess:
>>
>> /* Special case comparing booleans against a constant as we
>> know the value of OP0 on both arms of the branch. i.e., we
>> can
Currently, GCC only support DW_OP_EXPRESSION in dwarf module, this patch
extend the support to DW_OP_VAL_EXPRESSION which share the same code
mostly the same code with DW_OP_EXPRESSION.
Meanwhile the existed dwarf expression parser only allows expressions
which can be represented using GCC RTL.
On 06/10/16 14:57, Andre Vieira (lists) wrote:
> Hello,
>
> This patch tackles the issue reported in PR71607. This patch takes a
> different approach for disabling the creation of literal pools. Instead
> of disabling the patterns that would normally transform the rtl into
> actual literal pools,
SPARC can expose the CC register before reload so the implementation is direct
as on x86 and ARM. Like ARM, there is no support for multiplication at all,
but support for 64-bit operations in 32-bit mode; the latter would give rise
to complex patterns for signed arithmetic involving TImode in 3
On 21/10/16 08:43, Eric Botcazou wrote:
That's also overcomplicated.
Yes, I agree that's too heavy.
rtx *ptail = ®_NOTES (to_insn);
while (*ptail != NULL_RTX)
ptail = &XEXP (*ptail, 1);
Thanks very much Bernd, yes, this is better. And through manipulating
pointer directly, those bidire
On Fri, Oct 21, 2016 at 11:18:31AM +0200, Eric Botcazou wrote:
> /* For sub-word operations, if target doesn't have them, start
>with precres widening right away, otherwise do it only
>if the most simple cases can't be used. */
> if (WORD_REGISTER_OPERATIONS
> &
On 10/21/2016 02:36 AM, David Malcolm wrote:
+ /* Test dumping of hard regs. This is inherently target-specific due
+ to the name. */
+#ifdef I386_OPTS_H
+ ASSERT_RTL_DUMP_EQ ("(reg:SI ax)", gen_raw_REG (SImode, 0));
+#endif
Generally putting in target dependencies like this isn't somet
On 10/21/2016 09:43 AM, Eric Botcazou wrote:
I disagree: there are currently n ways of copying NOTEs in the RTL middle-end,
with different properties each time. We need only one primitive in rtlanal.c.
I feel the fact that they have different properties means we shouldn't
try to unify them: w
See
https://gcc.gnu.org/ml/gcc/2016-10/msg00165.html
for the background. This causes pthread_cond_wait in glibc to write out
of bounds on i386.
Fix was suggested by Jim Wilson.
Tested on x86_64-redhat-linux-gnu, with no new regressions. Also tested
against the i386 glibc reproducer, and
Dear All,
I had the attached patch more or less working at the end of January.
However, there was a regression with submodule_6.f03, which I had
quite a struggle with and only resolved yesterday.
Until now, select type used the hash value to do the type selection
with the inevitable consequence t
On 20 October 2016 at 15:02, Richard Biener wrote:
> On Wed, 19 Oct 2016, Jeff Law wrote:
>
>> On 10/15/2016 11:59 PM, Prathamesh Kulkarni wrote:
>> > Hi,
>> > After approval from Bernd Schmidt, I committed the patch to remove
>> > optab functions for
>> > sdivmod_optab and udivmod_optab in optabs
Bernd Schmidt writes:
> On 10/18/2016 02:15 PM, Senthil Kumar Selvaraj wrote:
>> Will do both the changes and re-run the reg tests. Ok for trunk if the
>> tests pass for x86_64-pc-linux and avr?
>>
> Probably but let's see the patch first.
How does this look?
Bootstrapped and reg tested x86_64-
Richard Biener:
> On Tue, Oct 18, 2016 at 2:35 PM, Ximin Luo wrote:
>>
>> Thanks, I'll add the Changelog entry. My computer isn't very powerful, so I
>> didn't bootstrap it yet, I only tested it on a stage1 compiler, on Debian
>> testing/unstable. I'll find some time to bootstrap it and test it
On 10/21/2016 12:46 PM, Senthil Kumar Selvaraj wrote:
How does this look?
Looks good, thanks.
Bernd
Apart from fixing a memleak this is unchanged from the last posting
which means it still has no support for Mach-O or [X]COFF.
Boostrapped / tested on x86_64-unknown-linux-gnu.
Richard.
2016-10-21 Richard Biener
include/
* simple-object.h (simple_object_copy_lto_debug_sectio
Hi all,
On 21/10/16 09:00, Christophe Lyon wrote:
[ccying Ramana]
Ramana is currently OoO all of this week.
Kyrill
On 20 October 2016 at 18:34, Jonathan Wakely wrote:
On 20/10/16 09:26 -0700, Mike Stump wrote:
On Oct 20, 2016, at 5:20 AM, Jonathan Wakely wrote:
I am considering leavin
Hi Ian,
> This patch to libgo rewrites the interface code from C to Go.
>
> I started to copy the Go 1.7 interface code, but the gc and gccgo
> representations of interfaces are too different. So instead I rewrote
> the gccgo interface code from C to Go. The code is largely the same
> as it was,
This is the main part of the early LTO debug support. The main parts
of the changes are to dwarf2out.c where most of the changes are related
to the fact that we eventually have to output debug info twice, once
for the early LTO part and once for the fat part of the object file.
Bootstrapped and
Hello,
as requested by Hartmut, I've updated the MAINTAINERS file to show
his new email address since the old one no longer works.
Bye,
Ulrich
Index: MAINTAINERS
===
--- MAINTAINERS (revision 241398)
+++ MAINTAINERS (working copy)
@
On Thu, Oct 20, 2016 at 11:53:49PM -0400, Ryan Burn wrote:
> Are exception classes required to support emplace new construction
> like that? With this change, Intel's TBB library no longer compiles
> because its exception class declares it's own new operator (see
> https://github.com/wjakob/tbb/blo
On 21/10/16 14:36 +0300, Gleb Natapov wrote:
On Thu, Oct 20, 2016 at 11:53:49PM -0400, Ryan Burn wrote:
Are exception classes required to support emplace new construction
like that? With this change, Intel's TBB library no longer compiles
because its exception class declares it's own new operato
On 21/10/16 12:44 +0100, Jonathan Wakely wrote:
On 21/10/16 14:36 +0300, Gleb Natapov wrote:
On Thu, Oct 20, 2016 at 11:53:49PM -0400, Ryan Burn wrote:
Are exception classes required to support emplace new construction
like that? With this change, Intel's TBB library no longer compiles
because
On 10/20/2016 08:30 PM, Jakub Jelinek wrote:
This patch changes these two manually maintained arrays into normal
vec.h vectors.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Looks good. For safety, could you make a before/after comparison on one
large sourcefile to make
On Fri, Oct 21, 2016 at 12:44:39PM +0100, Jonathan Wakely wrote:
> On 21/10/16 14:36 +0300, Gleb Natapov wrote:
> > On Thu, Oct 20, 2016 at 11:53:49PM -0400, Ryan Burn wrote:
> > > Are exception classes required to support emplace new construction
> > > like that? With this change, Intel's TBB libr
On 21/10/16 11:13, Bernd Schmidt wrote:
On 10/21/2016 09:43 AM, Eric Botcazou wrote:
I disagree: there are currently n ways of copying NOTEs in the RTL
middle-end,
with different properties each time. We need only one primitive in
rtlanal.c.
I feel the fact that they have different propertie
This makes us derive ranges for loop IVs in EVRP using
adjust_range_with_scevs. It also allows us to derive ranges from
conditions in loop preheaders (I think that's still broken because
we force simple preheaders and predecessor search doesn't follow
forwarders -- sth for a followup).
Bootstra
On 10/21/2016 02:04 PM, Jiong Wang wrote:
+ /* Locate the end of existing REG_NOTES in NEW_RTX. */
+ rtx *ptail = ®_NOTES (new_rtx);
+ while (*ptail != NULL_RTX)
+ptail = &XEXP (*ptail, 1);
I was thinking along the lines of something like this (untested,
emit-rtl.c part omitted). Eri
On Fri, Oct 21, 2016 at 02:58:26PM +0300, Gleb Natapov wrote:
> On Fri, Oct 21, 2016 at 12:44:39PM +0100, Jonathan Wakely wrote:
> > On 21/10/16 14:36 +0300, Gleb Natapov wrote:
> > > On Thu, Oct 20, 2016 at 11:53:49PM -0400, Ryan Burn wrote:
> > > > Are exception classes required to support emplac
On Tue, 18 Oct 2016, Kyrill Tkachov wrote:
> Hi Richard,
>
> This patch is a merge of [1] and [2] and implements the manual merging of
> bitfields
> as outlined in [1] but actually makes it work on BYTES_BIG_ENDIAN too.
> It caused me a lot of headeache because the bit offset is counted from the
Hi Andre,
Committed to trunk as revision 241403.
Thanks for the review.
Paul
On 20 October 2016 at 11:43, Andre Vehreschild wrote:
> Hi Paul,
>
> after looking at your patch again, I understood why these extra copies are
> needed. May be a comment would prevent future gfortran hackers from try
On 21/10/16 15:33 +0300, Gleb Natapov wrote:
On Fri, Oct 21, 2016 at 02:58:26PM +0300, Gleb Natapov wrote:
On Fri, Oct 21, 2016 at 12:44:39PM +0100, Jonathan Wakely wrote:
> On 21/10/16 14:36 +0300, Gleb Natapov wrote:
> > On Thu, Oct 20, 2016 at 11:53:49PM -0400, Ryan Burn wrote:
> > > Are exce
On Tue, Oct 18, 2016 at 07:10:07PM +0100, Wilco Dijkstra wrote:
> James Greenhalgh wrote:
> On Mon, Oct 17, 2016 at 12:38:36PM +, Wilco Dijkstra wrote:
>
> >> + /* We need two add/sub instructions, each one perform part of the
> >> + addition/subtraction, but don't this if the addend can
On 21/10/16 13:57 +0100, Jonathan Wakely wrote:
On 21/10/16 15:33 +0300, Gleb Natapov wrote:
On Fri, Oct 21, 2016 at 02:58:26PM +0300, Gleb Natapov wrote:
On Fri, Oct 21, 2016 at 12:44:39PM +0100, Jonathan Wakely wrote:
On 21/10/16 14:36 +0300, Gleb Natapov wrote:
> On Thu, Oct 20, 2016 at 11:
Hi Richard,
On 21/10/16 13:37, Richard Biener wrote:
On Tue, 18 Oct 2016, Kyrill Tkachov wrote:
Hi Richard,
This patch is a merge of [1] and [2] and implements the manual merging of
bitfields
as outlined in [1] but actually makes it work on BYTES_BIG_ENDIAN too.
It caused me a lot of headeach
On Wed, Oct 19, 2016 at 01:39:16PM +0200, Martin Liška wrote:
> >From 7f1648ef3480c6db856e567153cf9bb838c77d4f Mon Sep 17 00:00:00 2001
> From: marxin
> Date: Mon, 17 Oct 2016 15:58:50 +0200
> Subject: [PATCH] Do not disable aggressive loop opts for
> -fsanitize=unreachable or leak
>
> gcc/Chang
Ping.
https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00982.html
Thanks,
Kyrill
On 13/10/16 09:11, Kyrill Tkachov wrote:
On 12/10/16 17:49, Martin Sebor wrote:
On 10/12/2016 06:43 AM, Kyrill Tkachov wrote:
On 12/10/16 11:18, Kyrill Tkachov wrote:
On 12/10/16 10:57, Kyrill Tkachov wrote:
O
On Sat, Oct 15, 2016 at 07:38:40PM -0700, Andrew Pinski wrote:
> On Wed, Nov 25, 2015 at 11:59 AM, Andrew Pinski wrote:
> Here is finally an updated (fixed) patch (I did not implement the two
> implementer big.LITTLE support yet, that will be for a different patch
> since I also fixed the part no
I happened to notice that the gnat.dg testsuite run is slow even on a
reasonably fast SPARC machine (3.6 GHz SPARC T5) and together with the
libgomp testsuite (PR libgomp/66005) dominates bootstrap time: within a
make -j96 -k check, it takes 1h 18m 37s. For unknown reasons,
check-gnat isn't parall
This patch adds an alternate CPU level naming following the
architecture level number in the Principles of Operations manual. So
instead of having z196, zEC12, and z13 you can use arch9, arch10, and
arch11. The old cpu names stay valid and should preferably be used.
The alternate names are suppo
On Thu, Oct 20, 2016 at 2:27 PM, Jakub Jelinek wrote:
> + if ((dwarf_version >= 4 || !dwarf_strict)
Why >=4? Isn't this a DWARF 5 feature?
OK with that change.
Jason
> Ok for mainline (and eventually for 5 and 6 branches given the small
> size and low risk of the patch)?
I'm not familiar with lang_checks_parallelized, but that's OK with me on
principle.
Arno
The following patch works around quite a number of i386 testcases
FAILing on Solaris/x86, as reported in the PR. To avoid tons of
testsuite noise, the following patch adds -mno-stackrealign to the
affected testcases and will thus benefit other targets that default to
-mstackrealign, too.
Bootstra
On Wed, Oct 12, 2016 at 04:07:53PM +0200, Martin Liška wrote:
> > Ok, first let me list some needed follow-ups that don't need to be handled
> > right away:
> > - r237814-like changes for ASAN_MARK
>
> Yes, that's missing. I'm wondering whether the same approach would be viable
> as
> the {un}poi
On Fri, Oct 21, 2016 at 09:58:01AM -0400, Jason Merrill wrote:
> On Thu, Oct 20, 2016 at 2:27 PM, Jakub Jelinek wrote:
> > + if ((dwarf_version >= 4 || !dwarf_strict)
>
> Why >=4? Isn't this a DWARF 5 feature?
It is actually DWARF 4 already.
Looking at DWARF4 DW_AT_* additions, we also don't
On Fri, Oct 21, 2016 at 4:17 PM, Rainer Orth
wrote:
> The following patch works around quite a number of i386 testcases
> FAILing on Solaris/x86, as reported in the PR. To avoid tons of
> testsuite noise, the following patch adds -mno-stackrealign to the
> affected testcases and will thus benefit
On Fri, Oct 21, 2016 at 04:01:48PM +0200, Rainer Orth wrote:
> I happened to notice that the gnat.dg testsuite run is slow even on a
> reasonably fast SPARC machine (3.6 GHz SPARC T5) and together with the
> libgomp testsuite (PR libgomp/66005) dominates bootstrap time: within a
> make -j96 -k chec
Hi Jakub,
On Thu, Oct 20, 2016 at 5:21 PM, Andre Vieira (lists)
wrote:
> <2><8f5>: Abbrev Number: 38 (DW_TAG_member)
> <8f6> DW_AT_specification: <0x8be>
> <8fa> DW_AT_linkage_name: (indirect string, offset: 0x4a0):
> _ZN6BANANA1sE
> <8fe> DW_AT_location: 5 byte block: 3 64
On Fri, Oct 21, 2016 at 10:40 AM, Jakub Jelinek wrote:
> On Fri, Oct 21, 2016 at 09:58:01AM -0400, Jason Merrill wrote:
>> On Thu, Oct 20, 2016 at 2:27 PM, Jakub Jelinek wrote:
>> > + if ((dwarf_version >= 4 || !dwarf_strict)
>>
>> Why >=4? Isn't this a DWARF 5 feature?
>
> It is actually DWARF
On Fri, Oct 21, 2016 at 03:57:34PM +0100, Yao Qi wrote:
> Hi Jakub,
>
> On Thu, Oct 20, 2016 at 5:21 PM, Andre Vieira (lists)
> wrote:
> > <2><8f5>: Abbrev Number: 38 (DW_TAG_member)
> > <8f6> DW_AT_specification: <0x8be>
> > <8fa> DW_AT_linkage_name: (indirect string, offset: 0x4a0)
Hi!
This patch adds folding for the new ia32 md builtins.
If they can be folded into constant, it is done in ix86_fold_builtin,
if they can fold to corresponding generic __builtin_c[lt]z* (which have
e.g. the advantage that VRP knows about what values it can have etc.),
it is done in gimple_fold_b
Hi!
While looking at the bextr/bextri/bzhi/pdep/pext intrinsics,
I've noticed some ugly formatted code in the headers, this patch fixes
what I found. Because the headers are installed, IMHO it is more important
to keep them properly formatted.
Bootstrapped/regtested on x86_64-linux and i686-linu
On Fri, Oct 21, 2016 at 5:23 PM, Jakub Jelinek wrote:
> Hi!
>
> This patch adds folding for the new ia32 md builtins.
> If they can be folded into constant, it is done in ix86_fold_builtin,
> if they can fold to corresponding generic __builtin_c[lt]z* (which have
> e.g. the advantage that VRP know
On Fri, Oct 21, 2016 at 05:28:42PM +0200, Uros Bizjak wrote:
> On Fri, Oct 21, 2016 at 5:23 PM, Jakub Jelinek wrote:
> > Hi!
> >
> > This patch adds folding for the new ia32 md builtins.
> > If they can be folded into constant, it is done in ix86_fold_builtin,
> > if they can fold to corresponding
Hi!
This patch on top of the just posted patch adds folding for a couple more
builtins (though, hundreds or thousands of other md builtins remain unfolded
even though they actually could be folded for e.g. const arguments).
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
201
On 13/10/16 18:34 +0100, Jonathan Wakely wrote:
This splits the large (2200 lines) header into smaller
pieces, so there are separate headers for:
- std::less, std::equal_to etc. (already in their own header)
- std::__invoke (already in its own header)
- std::reference_wrapper (often used on its
On Fri, Oct 21, 2016 at 5:31 PM, Jakub Jelinek wrote:
> On Fri, Oct 21, 2016 at 05:28:42PM +0200, Uros Bizjak wrote:
>> On Fri, Oct 21, 2016 at 5:23 PM, Jakub Jelinek wrote:
>> > Hi!
>> >
>> > This patch adds folding for the new ia32 md builtins.
>> > If they can be folded into constant, it is do
On Fri, Oct 21, 2016 at 5:26 PM, Jakub Jelinek wrote:
> Hi!
>
> This patch on top of the just posted patch adds folding for a couple more
> builtins (though, hundreds or thousands of other md builtins remain unfolded
> even though they actually could be folded for e.g. const arguments).
>
> Bootst
On Fri, Oct 21, 2016 at 5:28 PM, Jakub Jelinek wrote:
> Hi!
>
> While looking at the bextr/bextri/bzhi/pdep/pext intrinsics,
> I've noticed some ugly formatted code in the headers, this patch fixes
> what I found. Because the headers are installed, IMHO it is more important
> to keep them properl
On 19/10/16 12:48 +0200, Eelis van der Weegen wrote:
This is the same optimization as was recently applied to std::shuffle.
It reduces the runtime of the following program by 20% on my machine:
int main()
{
std::vector a(1), b(1000);
std::mt19
On 21/10/16 14:59, James Greenhalgh wrote:
> On Sat, Oct 15, 2016 at 07:38:40PM -0700, Andrew Pinski wrote:
>> On Wed, Nov 25, 2015 at 11:59 AM, Andrew Pinski wrote:
>> Here is finally an updated (fixed) patch (I did not implement the two
>> implementer big.LITTLE support yet, that will be for a d
On Fri, Oct 21, 2016 at 04:57:22PM +0100, Richard Earnshaw (lists) wrote:
> On 21/10/16 14:59, James Greenhalgh wrote:
> > On Sat, Oct 15, 2016 at 07:38:40PM -0700, Andrew Pinski wrote:
> >> On Wed, Nov 25, 2015 at 11:59 AM, Andrew Pinski wrote:
> >> Here is finally an updated (fixed) patch (I did
On Wed, Oct 12, 2016 at 04:56:52PM +0100, James Greenhalgh wrote:
> On Wed, Sep 28, 2016 at 05:17:14PM +0100, James Greenhalgh wrote:
> > On Wed, Sep 21, 2016 at 10:42:03AM +0100, James Greenhalgh wrote:
> > > On Tue, Sep 13, 2016 at 10:31:28AM +0100, James Greenhalgh wrote:
> > > > On Tue, Sep 06,
Hi Richard, Jeff,
Fair enough, I understand the reservations both of you have.
I'll spend some time experimenting with what kind of code I'd
Get out of it from lowering early and come up with an updated
Patch.
Thanks!
Tamar
> -Original Message-
> From: Richard Biener [mailto:rguent...@s
On 06/09/16 10:19, James Greenhalgh wrote:
Hi,
This patch adds patterns for conversion from 64-bit integer to 16-bit
floating-point values under AArch64 targets which don't have support for
the ARMv8.2-A 16-bit floating point extensions.
We implement these by first saturating to a SImode (we k
> I'm not strongly against your patch, I'm just very surprised it is really
> needed (acats is much larger, check-gnat is small).
In what unit do you count? ACATS has fewer tests than gnat.dg nowadays.
--
Eric Botcazou
This implements some DR resolutions for the filesystem lib.
Tested x86_64-linux, committed to trunk.
commit 03db1baaa50ea8d97b4442fffaae4e68a03eebad
Author: Jonathan Wakely
Date: Thu Oct 20 19:26:47 2016 +0100
LWG2720 implement filesystem::perms::symlink_nofollow
* include/exp
On Fri, 2016-10-21 at 12:04 +0200, Bernd Schmidt wrote:
> On 10/21/2016 02:36 AM, David Malcolm wrote:
> > + /* Test dumping of hard regs. This is inherently target
> > -specific due
> > + to the name. */
> > +#ifdef I386_OPTS_H
> > + ASSERT_RTL_DUMP_EQ ("(reg:SI ax)", gen_raw_REG (SImode,
This patch changes gcc to emit DW_OP_form_tls_address rather than
DW_OP_GNU_push_tls_address. This is PR debug/77315.
DW_OP_form_tls_address was added in DWARF 3, and this patch uses the
DWARF version to decide which opcode to emit.
Note that gdb did not implement the DWARF 3 opcode until recent
On Fri, Oct 21, 2016 at 11:17:33AM -0600, Tom Tromey wrote:
> This patch changes gcc to emit DW_OP_form_tls_address rather than
> DW_OP_GNU_push_tls_address. This is PR debug/77315.
>
> DW_OP_form_tls_address was added in DWARF 3, and this patch uses the
> DWARF version to decide which opcode to
> "Jakub" == Jakub Jelinek writes:
Jakub> I admit I haven't looked at the GDB changes, but how will the debugger
know
Jakub> if it is an emutls emulation or normal ELF TLS, if the same op is used
Jakub> in both cases?
Because gdb never implemented DW_OP_form_tls_address, that emultls case
h
On Oct 21, 2016, at 9:54 AM, Eric Botcazou wrote:
>
>> I'm not strongly against your patch, I'm just very surprised it is really
>> needed (acats is much larger, check-gnat is small).
>
> In what unit do you count? ACATS has fewer tests than gnat.dg nowadays.
The only unit that matters, wall s
On 10/20/2016 03:32 AM, Richard Biener wrote:
Starting with some high level design comments. If these conflict with
comments from others, let me know and we'll work through the issues.
I don't really like introducing code conditional on the target capabilities
this early in the gimple optimizat
On Oct 21, 2016, at 7:01 AM, Rainer Orth wrote:
>
> I happened to notice that the gnat.dg testsuite run is slow
> 2.6 GHz AMD Opteron 8435, -j24 43m 24s => 33m 4s
> 2.93 GHz Intel Xeon X7350, -j16 30m 7s => 9m 8s
> 2.67 GHz Intel Xeon X7542, -j48 14m 56s => 5m 50s
>
> Se
Committed as obvious.
M libgfortran/ChangeLog
M libgfortran/io/io.h
r241422 = 268e62788f36198cb64a3ce953daacbd3b0107ee (refs/remotes/svn/trunk)
2016-10-21 Jerry DeLisle
PR libfortran/78055
* io/io.h (st_parameter_dt): Restore GFC_IO_INT to maintai
On October 21, 2016 3:29:15 PM GMT+02:00, Kyrill Tkachov
wrote:
>Hi Richard,
>
>On 21/10/16 13:37, Richard Biener wrote:
>> On Tue, 18 Oct 2016, Kyrill Tkachov wrote:
>>
>>> Hi Richard,
>>>
>>> This patch is a merge of [1] and [2] and implements the manual
>merging of
>>> bitfields
>>> as outline
Hi
I configured libstdc++ to use gnu-version-namespace and there are a
number of failures, see below. But none of them related to this patch so
is it ok to commit ?
The results:
FAIL: libstdc++-abi/abi_check
3709 symbols reported as added. I don't know what to think about
it. I see
On Wed, Oct 19, 2016 at 11:10 PM, kugan
wrote:
> Hi,
>
>
> On 20/10/16 02:54, Andrew Pinski wrote:
>>
>> On Wed, Oct 19, 2016 at 1:01 AM, Christophe Lyon
>> wrote:
>>>
>>> On 18 October 2016 at 09:34, Richard Biener wrote:
On Mon, 17 Oct 2016, Richard Biener wrote:
>
> Thi
Hi!
This patch changes the .debug_info headers to follow the current
specification (I still hope the useless padding1/padding2 fields will be
removed), and also changes the -gsplit-dwarf stuff to move dwo_id into
the header and use DW_UT_{skeleton,split_*}.
Bootstrapped/regtested on x86_64-linux
Some quick comments before I go offline ...
On 21/10/16 21:21 +0200, François Dumont wrote:
Hi
I configured libstdc++ to use gnu-version-namespace and there are
a number of failures, see below. But none of them related to this
patch so is it ok to commit ?
The results:
FAIL: libstdc++
We were warning that shifting a uint64_t right by 32 bits exceeded the
width of the type because we didn't do any conversion when
substituting the 32-bit _X of Test2 for _Val in Test.
This patch fixes this by doing conversions for value-dependent (but
not type-dependent) arguments in convert_templ
It was bugging me that the default debug_tree of a TEMPLATE_PARM_INDEX
didn't give the name of the template parameter, so I'm adding the
corresponding _DECL to the dump.
commit 56ee7ba41e0a1b6568f157a5a82230cb8f57
Author: Jason Merrill
Date: Fri Oct 21 15:29:04 2016 -0400
* ptre
The latest patch works as expected for me, both with an operand
and with stdin. But since I'm not empowered to approve it one
of the others reviewers will need to give it their blessing.
Thanks
Martin
On 10/21/2016 07:56 AM, Kyrill Tkachov wrote:
Ping.
https://gcc.gnu.org/ml/gcc-patches/2016-1
On Thu, 2016-10-20 at 11:22 +0200, Bernd Schmidt wrote:
> > Recognizing by SCRATCH wouldn't catch everything, I believe. You
> > should
> > be able to check n_dups and dup_loc in recog_data to identify cases
> > where you need to ensure something is restored with pointer
> > equality.
Thanks. I a
This patch to libgo copies the lfstack code from the Go 1.7 runtime to
libgo. The older gccgo-specific copy of lfstack had some
modifications that work on Solaris; those are implemented in a
superior form in the new version. Bootstrapped and ran Go testsuite
on x86_64-pc-linux-gnu. Bootstrapped
On Fri, 2016-10-07 at 15:12 -0400, David Malcolm wrote:
> Amongst many other changes, r146451 added this cast:
>
> -#define GET_MODE_CLASS(MODE) mode_class[MODE]
> +#define GET_MODE_CLASS(MODE) ((enum mode_class) mode_class[MODE])
>
> making a cast in go-lang.c redundant; remove it.
>
> Succ
Hi!
This patch extends -Wint-in-bool-context to warn for multiplications if
used in boolean context. This is rarely useful, and where used, could
be easily replaced with && for instance. I think that multiplications in
boolean context should be warned about, regardless of the used
data type.
Thi
> "Jakub" == Jakub Jelinek writes:
Jakub> Also, as this effectively requires the latest unreleased GDB under the
Jakub> default options for something that has been working previously, I wonder
Jakub> if it e.g. for some time shouldn't be guarded with dwarf_version >= 5
Here's what that looks
1 - 100 of 119 matches
Mail list logo
