This rewrites the riscv libgcc function to use macros for function
definitions, to add the missing type and size directives, and to make
future changes easier.
This was tested with make check with rv32i and rv64i builds, with and
without -msave-restore, to force all of the modified functions to be
The attached patch enforces F2008:C631, which of course is
/* F2008:C631 (R626) A type-param-value in a type-spec shall be an
asterisk if and only if each allocate-object is a dummy argument
for which the corresponding type parameter is assumed. */
Regression tested on x86_64-*-freebsd.
2
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83317
The patch was successfully boostrapped and tested on x86-64.
Committed as rev. 255517
Index: ChangeLog
===
--- ChangeLog (revision 255516)
+++ Chan
On 12/08/2017 02:34 PM, David Malcolm wrote:
On Mon, 2017-12-04 at 18:05 -0700, Martin Sebor wrote:
On 12/04/2017 01:58 PM, David Malcolm wrote:
On Mon, 2017-12-04 at 12:18 -0700, Martin Sebor wrote:
On 12/04/2017 05:41 AM, Rainer Orth wrote:
Within test last week, 64-bit Solaris/SPARC bootst
On Mon, 2017-12-04 at 18:05 -0700, Martin Sebor wrote:
> On 12/04/2017 01:58 PM, David Malcolm wrote:
> > On Mon, 2017-12-04 at 12:18 -0700, Martin Sebor wrote:
> > > On 12/04/2017 05:41 AM, Rainer Orth wrote:
> > > > Within test last week, 64-bit Solaris/SPARC bootstrap began to
> > > > fail:
> >
Hello,
This patch was sent in May, now everything is in place to commit the
OpenRISC gdb port upstream except for the OK from GCC on this patch.
Are there any concerns? Who will commit this to GCC?
On Mon, May 29, 2017 at 11:48 PM, Stafford Horne wrote:
> * ChangeLog:
>
> 2017-02-12 Stafford
On Dec 8, 2017, at 11:08 AM, Will Schmidt wrote:
>
>
> Hi,
> Add support for gimple folding of splat_u{8,16,32}.
> Testcase coverage is primarily handled by existing tests
> testsuite/gcc.target/powerpc/fold-vec-splat_*.c
>
> One new test added to verify we continue to receive
> an 'invalid arg
Hi,
I noticed the location of the Power ELFv2 ABI document was out of date,
so I committed the following change.
Thanks,
Bill
Index: htdocs/readings.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/readings.html,v
retrieving revision 1.28
On Fri, Dec 08, 2017 at 07:42:21PM +0100, Thomas Koenig wrote:
>
> the attached patch fixes a case where simplification wasn't done
> correctly for maxval and minval with character variables.
>
> Regression-tested. OK for trunk?
>
OK.
--
Steve
On December 8, 2017 6:49:21 PM GMT+01:00, Bin Cheng wrote:
>Hi,
>While I am still trying to reproduce and verify the issue (valgrind
>checking runs very slow for me),
>It's clear I made stupid mistake using free for newed vector. This
>simple patch fixes it.
>Bootstrap and test ongoing. Is it OK
On 8 December 2017 at 17:05, Richard Sandiford
wrote:
> Christophe Lyon writes:
>> Hi Richard,
>> On 7 December 2017 at 10:31, James Greenhalgh
>> wrote>> On Tue, Dec 05, 2017 at 05:57:37PM +, Richard Sandiford wrote:
Three related regression fixes:
- We can't use asserts lik
Hi!
This bug has been already fixed by Eric in r254188.
Regtested on x86_64-linux -m64/-m32, verified it FAILs with the patch reverted
on both, committed to trunk as obvious.
2017-12-08 Jakub Jelinek
PR rtl-optimization/81595
* gcc.c-torture/compile/pr81595.c: New test.
--- g
Patch attached.
* plugin-api.h (ld_plugin_get_wrap_symbols): New
plugin interface.
On Fri, Dec 8, 2017 at 11:01 AM, Sriraman Tallam wrote:
> Hi,
>
>This patch was approved for binutils by Cary:
> https://sourceware.org/ml/binutils/2017-12/msg00023.html
>
>Is it ok to apply this to GCC
Hi,
This patch was approved for binutils by Cary:
https://sourceware.org/ml/binutils/2017-12/msg00023.html
Is it ok to apply this to GCC include/plugin-api.h ?
Thanks
Sri
Hello world,
the attached patch fixes a case where simplification wasn't done
correctly for maxval and minval with character variables.
Regression-tested. OK for trunk?
Regards
Thomas
2017-12-08 Thomas Koenig
PR fortran/83316
* arith.c (gfc_character2character): Ne
Hi!
What is going on with this patch, will anybody commit it?
This is also http://gcc.gnu.org/PR80631 apparently.
The patch doesn't apply cleanly to current trunk due to the
reduc_code -> reduc_fn changes.
As it doesn't apply, I can't easily check what the patch generates
on the PR80631 testcas
Hi,
While I am still trying to reproduce and verify the issue (valgrind checking
runs very slow for me),
It's clear I made stupid mistake using free for newed vector. This simple
patch fixes it.
Bootstrap and test ongoing. Is it OK?
Thanks,
bin
2017-12-06 Bin Cheng
PR tree-optimiza
Hi,
On Fri, 8 Dec 2017, Richard Biener wrote:
> OK.
> Don't you need to adjust existing unroll and jam testcases?
Ahem... that's at least what the regression testing told me as well :)
Fixed in what I checked in (the only testcase we had was the one I added
yesterday)
Ciao,
Michael.
On 12/08/2017 10:34 AM, Jakub Jelinek wrote:
On Fri, Dec 08, 2017 at 10:25:48AM -0700, Martin Sebor wrote:
While testing the patch I noticed it issues some diagnostics
multiple times. It would be nice if the last (redundant)
pedantic warning in the error case below could be avoided.
You mean
On Fri, Dec 08, 2017 at 10:25:48AM -0700, Martin Sebor wrote:
> While testing the patch I noticed it issues some diagnostics
> multiple times. It would be nice if the last (redundant)
> pedantic warning in the error case below could be avoided.
You mean completely drop the pedwarn "initialization
On 12/08/2017 09:15 AM, Jakub Jelinek wrote:
Hi!
Martin's patch a few years ago started allowing flexible array members
inside of nested aggregates, similarly to what we were doing in C.
But C rejects cases where we in nested context try to initialize a flexible
array member with a non-empty ini
Hi,
Add support for gimple folding of splat_u{8,16,32}.
Testcase coverage is primarily handled by existing tests
testsuite/gcc.target/powerpc/fold-vec-splat_*.c
One new test added to verify we continue to receive
an 'invalid argument, must be a 5-bit immediate' error
when we try to splat
On 12/08/2017 09:20 AM, Jakub Jelinek wrote:
> Hi!
>
> There is no get_base_ref_and_offset function and AFAIK never has been,
> my guess is these comments meant get_ref_base_and_extent.
> Ok for trunk?
>
> 2017-12-08 Jakub Jelinek
>
> * ipa-polymorphic-call.c (noncall_stmt_may_be_vtbl_p
On December 8, 2017 5:45:23 PM GMT+01:00, Jan Hubicka wrote:
>> On December 8, 2017 4:51:16 PM GMT+01:00, Jan Hubicka
> wrote:
>> >>
>> >> This restores the vec_construct cost dependence on the vector
>element
>> >> count. Honza removed this (accidentially?) during the rework.
>> >>
>> >> Boots
On December 8, 2017 5:44:31 PM GMT+01:00, Michael Matz wrote:
>Hi,
>
>the predicate for feasiblity of unroll-and-jam was a bit nonsensical.
>Properly check for non-head-controlled loops, and also check all BBs of
>
>the outer loop for any instructions that would inhibit fusion (before
>we
>neve
> On December 8, 2017 4:51:16 PM GMT+01:00, Jan Hubicka wrote:
> >>
> >> This restores the vec_construct cost dependence on the vector element
> >> count. Honza removed this (accidentially?) during the rework.
> >>
> >> Bootstrap / regtest running on x86_64-unknown-linux-gnu, ok for
> >trunk?
>
Hi,
the predicate for feasiblity of unroll-and-jam was a bit nonsensical.
Properly check for non-head-controlled loops, and also check all BBs of
the outer loop for any instructions that would inhibit fusion (before we
never checked header or latch).
Richi also asked me to reuse the -floop-un
Hi,
On Fri, Dec 08 2017, Jakub Jelinek wrote:
> Hi!
>
> There is no get_base_ref_and_offset function and AFAIK never has been,
> my guess is these comments meant get_ref_base_and_extent.
I am quite sure that is the case.
> Ok for trunk?
Well, my opinion is that it obviously is.
Thanks,
Marti
On Fri, Dec 8, 2017 at 3:18 PM, Bin.Cheng wrote:
> On Fri, Dec 8, 2017 at 2:40 PM, Richard Biener
> wrote:
>> On Fri, Dec 8, 2017 at 1:43 PM, Bin.Cheng wrote:
>>> On Fri, Dec 8, 2017 at 12:17 PM, Richard Biener
>>> wrote:
On Fri, Dec 8, 2017 at 12:46 PM, Bin Cheng wrote:
> Hi,
> T
Hi!
There is no get_base_ref_and_offset function and AFAIK never has been,
my guess is these comments meant get_ref_base_and_extent.
Ok for trunk?
2017-12-08 Jakub Jelinek
* ipa-polymorphic-call.c (noncall_stmt_may_be_vtbl_ptr_store): Fix
a comment typo, get_base_ref_and_offse
Hi!
Martin's patch a few years ago started allowing flexible array members
inside of nested aggregates, similarly to what we were doing in C.
But C rejects cases where we in nested context try to initialize a flexible
array member with a non-empty initializer, because that is something that
can't
On December 8, 2017 4:51:16 PM GMT+01:00, Jan Hubicka wrote:
>>
>> This restores the vec_construct cost dependence on the vector element
>> count. Honza removed this (accidentially?) during the rework.
>>
>> Bootstrap / regtest running on x86_64-unknown-linux-gnu, ok for
>trunk?
>
>Hmm, the fal
Christophe Lyon writes:
> Hi Richard,
> On 7 December 2017 at 10:31, James Greenhalgh
> wrote>> On Tue, Dec 05, 2017 at 05:57:37PM +, Richard Sandiford wrote:
>>> Three related regression fixes:
>>>
>>> - We can't use asserts like:
>>>
>>> gcc_assert (GET_MODE_SIZE (mode) == 16);
>>>
>>>
On 12/08/2017 04:30 AM, Jakub Jelinek wrote:
On Fri, Dec 08, 2017 at 11:32:54AM +0100, Rainer Orth wrote:
Jakub Jelinek writes:
On Fri, Dec 08, 2017 at 10:43:58AM +0100, Rainer Orth wrote:
The line numbers are completely misleading, unfortunately. Hadn't
SUBTARGET_ATTRIBUTE_TABLE been used
>
> This restores the vec_construct cost dependence on the vector element
> count. Honza removed this (accidentially?) during the rework.
>
> Bootstrap / regtest running on x86_64-unknown-linux-gnu, ok for trunk?
Hmm, the false parameter to ix86_vec_cost is supposed to do that. It uses:
if (!
On December 8, 2017 3:58:11 PM GMT+01:00, Jakub Jelinek
wrote:
>On Fri, Dec 08, 2017 at 03:44:03PM +0100, Richard Biener wrote:
>>
>> The following fixes spurious uninit warnings for zero-sized arrays.
>>
>> Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
>>
>> Richard.
>>
>> 20
On 12/08/2017 07:50 AM, Sebastian Perta wrote:
> Hello,
>
> The following patch improves code size for 64 bit and for RL78:
> it emits a library function call instead of emitting code for the 64 bit
> min for every single time.
> The and function which was added in libgcc is hand written, so more
Hi!
The Power ISA documentation is now available without registration.
I have committed the wwwdocs patch below.
Enjoy,
Segher
Index: htdocs/readings.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/readings.html,v
retrieving revision
On Fri, Dec 8, 2017 at 2:40 PM, Richard Biener
wrote:
> On Fri, Dec 8, 2017 at 1:43 PM, Bin.Cheng wrote:
>> On Fri, Dec 8, 2017 at 12:17 PM, Richard Biener
>> wrote:
>>> On Fri, Dec 8, 2017 at 12:46 PM, Bin Cheng wrote:
Hi,
This simple patch makes interchange even more conservative fo
On Fri, Dec 08, 2017 at 03:44:03PM +0100, Richard Biener wrote:
>
> The following fixes spurious uninit warnings for zero-sized arrays.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
>
> Richard.
>
> 2017-12-08 Richard Biener
>
> PR middle-end/81782
> * tree-s
Hi All,
My previous patch had two issues with the new test cases.
It seems that depending on which DejaGnu version you have
dg-additional-options will add the options before or after the
ones added by the test suite. Which means I can't use it to override
the default options.
For this I use a pr
Hello,
The following patch improves code size for 64 bit and for RL78:
it emits a library function call instead of emitting code for the 64 bit
min for every single time.
The and function which was added in libgcc is hand written, so more optimal
than what GCC generates.
The change can easily be
The following fixes spurious uninit warnings for zero-sized arrays.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2017-12-08 Richard Biener
PR middle-end/81782
* tree-ssa-uninit.c (warn_uninitialized_vars): Properly
handle accesses outside of
On Fri, Dec 8, 2017 at 1:43 PM, Bin.Cheng wrote:
> On Fri, Dec 8, 2017 at 12:17 PM, Richard Biener
> wrote:
>> On Fri, Dec 8, 2017 at 12:46 PM, Bin Cheng wrote:
>>> Hi,
>>> This simple patch makes interchange even more conservative for small loops
>>> with constant initialized simple reduction.
Hi!
On Thu, Dec 07, 2017 at 07:01:03PM -0200, Alexandre Oliva wrote:
[ Big snip; thanks for all the detailed information! ]
> Still, I'm concerned I haven't caught all of the cases in which
> adjusting REG_N_SETS would be needed: we might have dropped multiple
> SETs of the same pseudo, each wit
Hi!
I'd like to ping two patches:
http://gcc.gnu.org/ml/gcc-patches/2017-11/msg02521.html
PR c++/83205 - diagnose invalid std::tuple_size::value for structured
bindings; the follow-up with plural spelling is approved
already
http://gcc.gnu.org/ml/gcc-patches/2
Hi Richard,
On 7 December 2017 at 10:31, James Greenhalgh wrote:
> On Tue, Dec 05, 2017 at 05:57:37PM +, Richard Sandiford wrote:
>> Three related regression fixes:
>>
>> - We can't use asserts like:
>>
>> gcc_assert (GET_MODE_SIZE (mode) == 16);
>>
>> in aarch64_print_operand because
On Thu, Dec 07, 2017 at 11:03:10AM -0700, Martin Sebor wrote:
> On 12/07/2017 09:55 AM, Jakub Jelinek wrote:
> > On Wed, Dec 06, 2017 at 05:30:53PM +0100, Jakub Jelinek wrote:
> > > On Wed, Dec 06, 2017 at 09:20:15AM -0700, Martin Sebor wrote:
> > > > Attached is a patch with the comment updated/si
On Tue, Oct 24, 2017 at 10:58 AM, H.J. Lu wrote:
> On Tue, Oct 24, 2017 at 10:40 AM, Andi Kleen wrote:
>> "H.J. Lu" writes:
>>> --- /dev/null
>>> +++ b/gcc/testsuite/gcc.target/i386/pr82699-4.c
>>> @@ -0,0 +1,11 @@
>>> +/* { dg-do compile { target { *-*-linux* && { ! ia32 } } } } */
>>> +/* { dg
On Thu, Dec 07, 2017 at 09:28:32PM +0100, Marc Glisse wrote:
> On Thu, 7 Dec 2017, Jakub Jelinek wrote:
>
> > When committing the previous PR81281 patch, I've removed all the @@0 cases
> > on plus:c, used @0 instead, to make sure we don't regress.
> >
> > This patch readds those where possible.
Hello,
The following patch improves both the speed and code size for 64 bit
unsigned min for RL78:
it emits a library function call instead of emitting code for the 64 bit
min for every single time.
The unsigned min function which was added in libgcc is hand written, so more
optimal than what GCC
Hi Jakub,
> On Fri, Dec 08, 2017 at 01:47:35PM +0100, Rainer Orth wrote:
>> >> the new testcase FAILs on Solaris/x86 with /bin/as:
>> >>
>> >> +FAIL: g++.dg/opt/pr83252.C -std=gnu++11 execution test
>> >> +FAIL: g++.dg/opt/pr83252.C -std=gnu++14 execution test
>> >> +FAIL: g++.dg/opt/pr83252.C
On Tue, Oct 24, 2017 at 5:31 AM, H.J. Lu wrote:
> PLT should be avoided with shadow stack in 32-bit mode if more than 2
> parameters are passed in registers since only 2 parameters can be passed
> in registers for external function calls via PLT with shadow stack
> enabled.
>
> OK for trunk if the
Hi!
> +// *** TODO: add checs for the adds tests
Did you forget this part?
Also the same trivial things as the previous patch.
The rest looks fine, okay for trunk. Thanks!
Segher
Hi Carl,
On Thu, Dec 07, 2017 at 08:56:07AM -0800, Carl Love wrote:
> * config/rs6000/altivec.h (vec_extract_fp32_from_short[h|l]): Add
> #defines.
Line too long.
> * gcc.target/powerpc/builtins-3-p8.c (test_vsi_packs_[vui|vsi
> vssi|vusi], test_vsi_packsu-[vssi|vusi|vsll|vull
On Fri, Dec 08, 2017 at 01:47:35PM +0100, Rainer Orth wrote:
> >> the new testcase FAILs on Solaris/x86 with /bin/as:
> >>
> >> +FAIL: g++.dg/opt/pr83252.C -std=gnu++11 execution test
> >> +FAIL: g++.dg/opt/pr83252.C -std=gnu++14 execution test
> >> +FAIL: g++.dg/opt/pr83252.C -std=gnu++98 exec
Hi Jakub,
>> the new testcase FAILs on Solaris/x86 with /bin/as:
>>
>> +FAIL: g++.dg/opt/pr83252.C -std=gnu++11 execution test
>> +FAIL: g++.dg/opt/pr83252.C -std=gnu++14 execution test
>> +FAIL: g++.dg/opt/pr83252.C -std=gnu++98 execution test
>>
>> ld.so.1: pr83252.exe: fatal: pr83252.exe:
On Fri, Dec 08, 2017 at 01:38:36PM +0100, Rainer Orth wrote:
> Hi Jakub,
>
> > On Wed, Nov 29, 2017 at 05:21:22PM -0500, Vladimir Makarov wrote:
> >> The following patch fixes
> >>
> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80818
> >>
> >> The patch was successfully tested and bootstr
On Fri, Dec 8, 2017 at 12:17 PM, Richard Biener
wrote:
> On Fri, Dec 8, 2017 at 12:46 PM, Bin Cheng wrote:
>> Hi,
>> This simple patch makes interchange even more conservative for small loops
>> with constant initialized simple reduction.
>> The reason is undoing such reduction introduces new da
Hi Jakub,
> On Wed, Nov 29, 2017 at 05:21:22PM -0500, Vladimir Makarov wrote:
>> The following patch fixes
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80818
>>
>> The patch was successfully tested and bootstrapped on x86_64. The patch
>> has no test because it is hard to check the pro
On Thu, 7 Dec 2017, Tom de Vries wrote:
> Hi,
>
> I'm currently debugging a problem in lra, and got a bit lost in the 20k+ lines
> dump file.
>
> I observed that:
> - the lra dump file is one of the biggest ones
> - lra itself consists of a looping of sub-passes.
>
> So, I've:
> - written a dum
On Wed, Dec 6, 2017 at 11:21 AM, Eric Botcazou wrote:
>> 6.1 Extensions implemented in GNU Fortran
>> 7.2 GNU Fortran Compiler Directives
>>
>> 6.1 describes extension covering legacy code and vendor extensions.
>> 7.2 describes other !$GCC directives. Currently, the section is
>> mainly calling
On Fri, Dec 8, 2017 at 12:46 PM, Bin Cheng wrote:
> Hi,
> This simple patch makes interchange even more conservative for small loops
> with constant initialized simple reduction.
> The reason is undoing such reduction introduces new data reference and
> cond_expr, which could cost too much in a
This restores the vec_construct cost dependence on the vector element
count. Honza removed this (accidentially?) during the rework.
Bootstrap / regtest running on x86_64-unknown-linux-gnu, ok for trunk?
Thanks,
Richard.
2017-12-08 Richard Biener
PR target/83008
* config/i38
Hi,
This simple patch makes interchange even more conservative for small loops with
constant initialized simple reduction.
The reason is undoing such reduction introduces new data reference and
cond_expr, which could cost too much in a small
loop.
Test gcc.target/aarch64/pr62178.c is fixed with t
Hello,
the ICE with --enable-checking=rtl reported in PR 82960 was caused by
spu.c:pad_bb using INSN_CODE on RTX with INSN_P false (specifically,
on jump_table_data). Add checks to handle this case.
Tested on spu-elf, committed to mainline.
Bye,
Ulrich
ChangeLog:
PR target/82960
On Fri, Dec 08, 2017 at 11:32:54AM +0100, Rainer Orth wrote:
> Jakub Jelinek writes:
>
> > On Fri, Dec 08, 2017 at 10:43:58AM +0100, Rainer Orth wrote:
> >> The line numbers are completely misleading, unfortunately. Hadn't
> >> SUBTARGET_ATTRIBUTE_TABLE been used at the end of the (very short)
>
Hi,
the testcase triggers ICE because loop iterates too many times. We used to
work around by capping all counts to 1 but that leads to many problems
during IPA profile propagation (because there is no way to determine
frequency of call given frequency of entry when entry frequency is 0).
Thi
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2017-12-08 Richard Biener
* gimple-loop-interchange.cc (tree_loop_interchange::interchange):
Provide -fopt-info-loop feedback when we interchange in a nest.
Index: gcc/gimple-loop-interchange.cc
=
A quirk in the historical naming of some ARMv6 products means that the
main CPU name implies the presence or otherwise of the floating point unit.
This causes problems when using -mfpu=auto with -mcpu=native: the driver is
picking a CPU that does not support a floating-point unit, even though
one m
On Fri, Dec 8, 2017 at 1:18 AM, Jeff Law wrote:
>
> So the underlying issue here is quite simple. Given something like
>
> x = (cond) ? res1 : res2;
>
> EVRP analysis will compute the resultant range using vrp_meet of the
> ranges for res1 and res2. Seems pretty natural.
>
> vrp_meet makes optim
Hi Christoph,
> >> > gcc/testsuite/
> >> > 2017-11-06 Tamar Christina
> >> >
> >> > PR target/82641
> >> > * gcc.target/arm/pragma_arch_attribute_2.c: New.
> >> > * gcc.target/arm/pragma_arch_attribute_2.c: New.
> >> > * gcc.target/arm/pragma_arch_attribute_3.c: New.
> >> >
On Fri, Dec 8, 2017 at 1:18 AM, Jeff Law wrote:
>
> So the underlying issue here is quite simple. Given something like
>
> x = (cond) ? res1 : res2;
>
> EVRP analysis will compute the resultant range using vrp_meet of the
> ranges for res1 and res2. Seems pretty natural.
>
> vrp_meet makes optim
When GCC invokes the assembler it generates a sanitized version of the
user-specified -march option to pass through, since the assembler does
not understand all the new FPU-related architectural options.
Unfortunately it goes too far and strips off all the architectural
extensions, including some t
In PR83304 two insns are combined, where the I2 uses a register that
has a REG_DEAD note on an insn after I2 but before I3. In such a case
move_deaths should move that death note. But move_deaths only looks
at the reg_stat[regno].last_death insn, and that field can be zeroed
out (previously, use_
Hi Alexandre,
On 07/12/17 21:01, Alexandre Oliva wrote:
On Jul 7, 2017, Segher Boessenkool wrote:
> I meant, just double check if your new
> code does the correct thing for the set count.
Sorry this took me so long to get back to. Even this was difficult for
me to answer for sure, then and
When gcc runs with the new -mfpu=auto option (either explicitly or when
that's the default behaviour) then this option is not passed through to
the assembler as we cannot rely on the assembler understanding it
(currently it doesn't understand it at all, but in future that might
change). That means
On Fri, Dec 8, 2017 at 10:39 AM, Richard Biener wrote:
> On Fri, 8 Dec 2017, Bin.Cheng wrote:
>
>> On Fri, Dec 8, 2017 at 9:54 AM, Richard Biener wrote:
>> > On Fri, 8 Dec 2017, Bin.Cheng wrote:
>> >
>> >> On Fri, Dec 8, 2017 at 8:29 AM, Richard Biener wrote:
>> >> > On Fri, 8 Dec 2017, Christop
On Fri, 8 Dec 2017, Bin.Cheng wrote:
> On Fri, Dec 8, 2017 at 9:54 AM, Richard Biener wrote:
> > On Fri, 8 Dec 2017, Bin.Cheng wrote:
> >
> >> On Fri, Dec 8, 2017 at 8:29 AM, Richard Biener wrote:
> >> > On Fri, 8 Dec 2017, Christophe Lyon wrote:
> >> >
> >> >> On 8 December 2017 at 09:07, Richa
Jakub Jelinek writes:
> On Fri, Dec 08, 2017 at 10:43:58AM +0100, Rainer Orth wrote:
>> The line numbers are completely misleading, unfortunately. Hadn't
>> SUBTARGET_ATTRIBUTE_TABLE been used at the end of the (very short)
>> sparc_attribute_table, I wouldn't have seen what was wrong.
>>
>> Th
On Fri, Dec 08, 2017 at 10:43:58AM +0100, Rainer Orth wrote:
> The line numbers are completely misleading, unfortunately. Hadn't
> SUBTARGET_ATTRIBUTE_TABLE been used at the end of the (very short)
> sparc_attribute_table, I wouldn't have seen what was wrong.
>
> The following patch fixes the pro
On Fri, Dec 8, 2017 at 9:54 AM, Richard Biener wrote:
> On Fri, 8 Dec 2017, Bin.Cheng wrote:
>
>> On Fri, Dec 8, 2017 at 8:29 AM, Richard Biener wrote:
>> > On Fri, 8 Dec 2017, Christophe Lyon wrote:
>> >
>> >> On 8 December 2017 at 09:07, Richard Biener wrote:
>> >> > On Thu, 7 Dec 2017, Bin.Ch
On Fri, 8 Dec 2017, Bin.Cheng wrote:
> On Fri, Dec 8, 2017 at 8:29 AM, Richard Biener wrote:
> > On Fri, 8 Dec 2017, Christophe Lyon wrote:
> >
> >> On 8 December 2017 at 09:07, Richard Biener wrote:
> >> > On Thu, 7 Dec 2017, Bin.Cheng wrote:
> >> >
> >> >> On Wed, Dec 6, 2017 at 1:29 PM, Richa
On Fri, Dec 8, 2017 at 8:29 AM, Richard Biener wrote:
> On Fri, 8 Dec 2017, Christophe Lyon wrote:
>
>> On 8 December 2017 at 09:07, Richard Biener wrote:
>> > On Thu, 7 Dec 2017, Bin.Cheng wrote:
>> >
>> >> On Wed, Dec 6, 2017 at 1:29 PM, Richard Biener wrote:
>> >> >
>> >> > The following fixe
Hi Martin,
> Ping: https://gcc.gnu.org/ml/gcc-patches/2017-08/msg01034.html
>
> The attached C++ only patch is rebased on the top of trunk.
>
> The remaining patches in the series (C FE and the back ends)
> have been approved.
your patch broke Solaris bootstrap:
/vol/gcc/src/hg/trunk/local/gcc/c
> On Dec 7, 2017, at 23:57 , Jeff Law wrote:
>
>>* dwarf2out.c (dwarf2out_do_cfi_startproc): Only emit
>>.cfi_personality or .cfi_lsda if the eh data format is dwarf2.
>>
> OK.
Now in, thanks Jeff!
On 7 December 2017 at 20:28, Martin Sebor wrote:
> On 12/07/2017 06:46 AM, Christophe Lyon wrote:
>>
>> Hi Martin,
>>
>>
>> On 6 December 2017 at 00:51, Jeff Law wrote:
>>>
>>> On 12/05/2017 04:47 PM, Martin Sebor wrote:
PR middle-end/82646 - bogus -Wstringop-overflow with
-D_FORTI
On Fri, 8 Dec 2017, Christophe Lyon wrote:
> On 8 December 2017 at 09:07, Richard Biener wrote:
> > On Thu, 7 Dec 2017, Bin.Cheng wrote:
> >
> >> On Wed, Dec 6, 2017 at 1:29 PM, Richard Biener wrote:
> >> >
> >> > The following fixes a vectorization issue that appears when trying
> >> > to vecto
On 8 December 2017 at 09:07, Richard Biener wrote:
> On Thu, 7 Dec 2017, Bin.Cheng wrote:
>
>> On Wed, Dec 6, 2017 at 1:29 PM, Richard Biener wrote:
>> >
>> > The following fixes a vectorization issue that appears when trying
>> > to vectorize the bwaves mat_times_vec kernel after interchange was
The following adds two testcases for PR81303, one verifying we interchange
the loop and a second that verifies we can vectorize the result.
Tested on x86_64-unknown-linux-gnu, applied.
Richard.
2017-12-08 Richard Biener
PR tree-optimization/81303
* gfortran.dg/pr81303.f: New
Hi Tamar,
On 1 December 2017 at 09:57, Tamar Christina wrote:
> Ping,
>
> This patch has also been bootstrapped and no issues.
>
>> -Original Message-
>> From: Tamar Christina
>> Sent: Tuesday, November 21, 2017 17:29
>> To: Tamar Christina ; gcc-patches@gcc.gnu.org
>> Cc: nd ; Ramana Ra
Hello Julia,
On 24 Oct 11:20, Koval, Julia wrote:
> Hi,
> This patch enables VPDPWSSDS instruction. The doc for isaset and instruction:
> https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf
>
> Ok for trunk?
Your patch is
On Thu, 7 Dec 2017, Bin.Cheng wrote:
> On Wed, Dec 6, 2017 at 1:29 PM, Richard Biener wrote:
> >
> > The following fixes a vectorization issue that appears when trying
> > to vectorize the bwaves mat_times_vec kernel after interchange was
> > performed by the interchange pass. That interchange i
Hello Julia,
On 24 Oct 11:06, Koval, Julia wrote:
> Hi,
> This patch enables VPDPWSSD instruction. The doc for isaset and instruction:
> https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf
>
> Ok for trunk?
Your patch is O
On 24 Oct 10:57, Koval, Julia wrote:
> Hi,
> This patch enables VPDPBUSDS instruction. The doc for isaset and instruction:
> https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf
>
> Ok for trunk?
Patch is OK. I've checked i
95 matches
Mail list logo
