Richard Biener writes:
> On Wed, May 9, 2018 at 1:29 PM, Richard Sandiford
> wrote:
>> Richard Biener writes:
>>> On Wed, May 9, 2018 at 12:34 PM, Richard Sandiford
>>> wrote:
The SLP unrolling factor is calculated by finding the smallest
scalar type for each SLP statement and taking
On May 9, 2018 10:52:05 PM GMT+02:00, Jakub Jelinek wrote:
>Hi!
>
>glibc <= 2.23 has buggy nextafterl/nexttowardl as can be seen on the
>nextafter-2.c testcase.
>
>Do we want to workaround this bug, e.g. with the following patch?
Works for me. Was the reason to test the target libc to test the co
Replacing a division feeding a division helps only when the
second division is the only user, and "fusing" the divisions is
downright bad if another user of the result of first division is
a modulus of the same value as the second division, forming a
divmod pair. See the test-case, where for the t
Hi,
On Tue, May 08, 2018 at 05:04:33PM -0700, Carl Love wrote:
> On Tue, 2018-05-08 at 11:24 -0500, Segher Boessenkool wrote:
> > What ISA version is required for the TH field to do anything? Will
> > it work on older machines too (just ignored)? What assembler version
> > is required?
>
> I we
On Thu, May 03, 2018 at 01:22:10PM -0400, Michael Meissner wrote:
> 2018-05-03 Michael Meissner
>
> * config/rs6000/rs6000.c (mode_supports_d_form): Rename
> mode_supports_vmx_dform to mode_supports_d_form. Add an optional
> argument to say which reload register class to use.
On Thu, May 03, 2018 at 01:20:32PM -0400, Michael Meissner wrote:
> 2018-05-03 Michael Meissner
>
> * config/rs6000/rs6000.c (mode_supports_vmx_dform): Move these
> functions to be next to the other mode_supports functions.
> (mode_supports_dq_form): Likewise.
Okay for trunk,
Hi Mike,
On Thu, May 03, 2018 at 01:17:03PM -0400, Michael Meissner wrote:
> 2018-05-03 Michael Meissner
>
> * config/rs6000/rs6000.c (mode_supports_dq_form): Rename
> mode_supports_vsx_dform_quad to mode_supports_dq_form.
> (mode_supports_vsx_dform_quad): Likewise.
> (
On Fri, 2018-05-04 at 14:05 -0700, Andrew Pinski wrote:
>
> > (thunderx2t99_loadpair): Fix cpu unit ordering.
> I think the original ordering was correct. The address calculation
> happens before the actual load.
> thunderx2t99_asimd_load1_ldp would have a similar issue.
>
> Thanks,
> And
I plan to commit the attach patch on Saturday unless someone objects.
2018-05-09 Steven G. Kargl
PR fortran/70870
* data.c (gfc_assign_data_value): Check that a data object does
not also have default initialization.
2018-05-09 Steven G. Kargl
PR fortran/708
I paln to commit the attached patch on Saturday unless
someone objects.
2018-05-09 Steven G. Kargl
PR fortran/85521
* array.c (gfc_resolve_character_array_constructor): Substrings
with upper bound smaller than lower bound are zero length strings.
2018-05-09 Steven G.
I plan to commit the attached patch on Saturday unless
someone voices an objection.
2018-05-09 Steven G. Kargl
PR fortran/85687
* check.c (gfc_check_rank): Check that the argument is a data object.
2018-05-09 Steven G. Kargl
PR fortran/85687
* gfortran.dg/
Several recent changes to the master version of cmd/go improve the
gofrontend support. These changes are partially copies of existing
gofrontend differences, and partially new code. This libgo patch makes
the gofrontend match the upstream code.
The changes included here come from:
https://gola
On Wed, May 2, 2018 at 3:05 PM, Jim Wilson wrote:
> This improves the code for a switch statement on targets that sign-extend
> function arguments, such as RISC-V. Given a simple testcase
> ...
> gcc/
> * expr.c (do_tablejump): When converting index to Pmode, if we have a
>
On Tue, May 1, 2018 at 11:52 AM, Jim Wilson wrote:
> gcc/
> PR target/84797
> * config.gcc (riscv*-*-*): Handle --with-multilib-list.
> * config/riscv/t-withmultilib: New.
> * config/riscv/withmultilib.h: New.
> * doc/install.texi: Document RISC-V --
Hi!
The following patch on top of the earlier ix86_*fold_builtin patch adds
folding also for the *s{ll,rl,ra}v* builtins.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2018-05-09 Jakub Jelinek
PR target/85323
* config/i386/i386.c (ix86_fold_builtin): Fo
Hi!
glibc <= 2.23 has buggy nextafterl/nexttowardl as can be seen on the
nextafter-2.c testcase.
Do we want to workaround this bug, e.g. with the following patch?
Regtested on x86_64-linux (with glibc 2.26). Ok for trunk?
2018-05-09 Jakub Jelinek
PR tree-optimization/85699
On Wed, May 09, 2018 at 11:01:18AM -0400, Jason Merrill wrote:
> On Wed, May 9, 2018 at 10:47 AM, Jakub Jelinek wrote:
> > On Wed, May 09, 2018 at 10:40:26AM -0400, Jason Merrill wrote:
> >> On Wed, May 9, 2018 at 4:55 AM, Jakub Jelinek wrote:
> >> > On Tue, May 08, 2018 at 11:28:18PM -0400, Jaso
OK, thanks.
On Wed, May 9, 2018 at 1:19 PM, Thomas Rix wrote:
> This patch defines the dwarf 5 forms.
> DW_FORM_strx1, DW_FORM_strx2, DW_FORM_strx3, DW_FORM_strx4
> And similar for addrx.
>
> Tom
>
>
>
Hi!
On Wed, May 09, 2018 at 09:07:49AM -0700, Carl Love wrote:
> 2018-05-09 Carl Love
> * gcc.target/powerpc/builtins-8-runnable.c: New builtin test file.
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/builtins-8-runnable.c
> @@ -0,0 +1,98 @@
> +/* { dg-do run { target { powerpc
This is the first of several planned patches to address shortcomings in
existing documentation of PowerPC built-in functions. The focus of this
particular patch is to improve documentation of basic built-in functions
that do not require inclusion of special header files.
A summary of this patch
This patch defines the dwarf 5 forms.
DW_FORM_strx1, DW_FORM_strx2, DW_FORM_strx3, DW_FORM_strx4
And similar for addrx.
Tom
0001-Define-DW_FORM_strx-and-DW_FORM_addrx.patch
Description: 0001-Define-DW_FORM_strx-and-DW_FORM_addrx.patch
GCC Maintainers:
The following patch adds tests for the vec_expte, vec_loge, and vec_re
builtins.
The patch for the test case was tested on
powerpc64le-unknown-linux-gnu (Power 8 LE)
powerpc64-unknown-linux-gnu (Power 8 BE)
powerpc64le-unknown-linux-gnu (Power 9 LE).
Please let me
On 11/17/2017 09:45 AM, Tom de Vries wrote:
Hi,
GOACC_enter_exit_data has this prototype:
...
void
GOACC_enter_exit_data (int device, size_t mapnum,
void **hostaddrs, size_t *sizes,
unsigned short *kinds,
int async, int num_
On 05/09/2018 03:50 AM, Thomas Schwinge wrote:
>> In addition to XPASS'ing devicetpr-1.f90, this patch [...]
>
> Apart from one remaining XFAIL for "-Os" (see PR80995), I now too see the
> following XPASSes on my main development machine:
>
> PASS: libgomp.oacc-fortran/deviceptr-1.f90 -DACC_
Applied.
On Tue, May 8, 2018 at 7:47 PM, Joshua Watt wrote:
> On Wed, Apr 18, 2018, 05:20 Pedro Alves wrote:
>
>> On 04/17/2018 11:10 PM, Joshua Watt wrote:
>> > On Tue, 2018-04-17 at 22:50 +0100, Pedro Alves wrote:
>> >> On 04/17/2018 06:24 PM, Joshua Watt wrote:
>> >>> Ping? I'd really like to
On Wed, May 9, 2018 at 10:47 AM, Jakub Jelinek wrote:
> On Wed, May 09, 2018 at 10:40:26AM -0400, Jason Merrill wrote:
>> On Wed, May 9, 2018 at 4:55 AM, Jakub Jelinek wrote:
>> > On Tue, May 08, 2018 at 11:28:18PM -0400, Jason Merrill wrote:
>> >> Maybe add a type parameter that defaults to size
On Mittwoch, 9. Mai 2018 11:08:02 CEST Jakub Jelinek wrote:
> On Tue, May 08, 2018 at 01:25:35PM +0200, Allan Sandfeld Jensen wrote:
> > 2018-05-08 Allan Sandfeld Jensen
>
> 2 spaces between date and name and two spaces between name and email
> address.
>
> > gcc/
> >
> > PR
On Wed, May 09, 2018 at 10:40:26AM -0400, Jason Merrill wrote:
> On Wed, May 9, 2018 at 4:55 AM, Jakub Jelinek wrote:
> > On Tue, May 08, 2018 at 11:28:18PM -0400, Jason Merrill wrote:
> >> Maybe add a type parameter that defaults to size_type_node...
> >>
> >> > + ret = fold_convert_loc (lo
On Wed, May 9, 2018 at 4:55 AM, Jakub Jelinek wrote:
> On Tue, May 08, 2018 at 11:28:18PM -0400, Jason Merrill wrote:
>> Maybe add a type parameter that defaults to size_type_node...
>>
>> > + ret = fold_convert_loc (loc, TREE_TYPE (expr),
>> > + fold_offsetof_1
OK.
On Wed, May 9, 2018 at 6:05 AM, Eric Botcazou wrote:
>> So it isn't clear to me if a cxx_make_decl_one_only is the way to go. Maybe
>> doing the recalculation in comdat_linkage and maybe_make_one_only only
>> would be sufficient.
>
> Patch to that effect attached, tested on x86-64/Linux, OK
* gcc.target/aarch64/sve/vcond_6.c: Add missing brace.
diff --git a/gcc/testsuite/gcc.target/aarch64/sve/vcond_6.c
b/gcc/testsuite/gcc.target/aarch64/sve/vcond_6.c
index a59f08d553..f41c94c400 100644
--- a/gcc/testsuite/gcc.target/aarch64/sve/vcond_6.c
+++ b/gcc/testsuite/gcc.target/aarch
On 05/01/2018 10:50 PM, Tom de Vries wrote:
On 11/17/2017 02:18 PM, Tom de Vries wrote:
Hi,
I've factored out 3 new functions to test properties of enum acc_async_t:
...
typedef enum acc_async_t {
/* Keep in sync with include/gomp-constants.h. */
acc_async_noval = -1,
acc_async_sync
On 09/05/18 13:30, Luis Machado wrote:
Hi Kyrill,
On 05/08/2018 11:09 AM, Kyrill Tkachov wrote:
Hi Luis,
On 07/05/18 15:28, Luis Machado wrote:
Hi,
On 02/08/2018 10:45 AM, Luis Machado wrote:
Hi Kyrill,
On 02/08/2018 09:48 AM, Kyrill Tkachov wrote:
Hi Luis,
On 06/02/18 15:04, Luis Macha
I promised Martin to look into adding more information to
gcc.gnu.org/about.html for new contributors.
This isn't the actual meat, but a number of changes I found
while preparing for that.
Applied (last weekend actually).
Gerald
Split a long sentence. Adjust the intro. Add a note to add
[www
To satisfy the CopyConstructible requirement a callable object stored in
a std::function must behave the same when copied from a const or
non-const source. If copying a non-const object doesn't produce an
equivalent copy then the behaviour is undefined. But we can make our
std::function more toler
The following fixes the same issue with scalar BB costing as I fixed
earlier this year with the loop scalar costing. We are currently
comparing apples and oranges on x86 where the add_stmt_cost hook
uses costs dependent on the stmt operation while the old hook
does not (cannot).
Fixed as follows
On Wed, May 09, 2018 at 09:33:30AM +0200, Eric Botcazou wrote:
> > Now, neither of the two branches needs to have LR restored at all,
> > because both of the branches end up in an infinite loop.
> >
> > This patch makes spread_component return a boolean saying if anything
> > was changed, and if s
Hi Kyrill,
On 05/08/2018 11:09 AM, Kyrill Tkachov wrote:
Hi Luis,
On 07/05/18 15:28, Luis Machado wrote:
Hi,
On 02/08/2018 10:45 AM, Luis Machado wrote:
Hi Kyrill,
On 02/08/2018 09:48 AM, Kyrill Tkachov wrote:
Hi Luis,
On 06/02/18 15:04, Luis Machado wrote:
Thanks for the feedback Kyrill.
On Wed, May 9, 2018 at 1:29 PM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Wed, May 9, 2018 at 12:34 PM, Richard Sandiford
>> wrote:
>>> The SLP unrolling factor is calculated by finding the smallest
>>> scalar type for each SLP statement and taking the number of required
>>> lanes
On Wed, May 9, 2018 at 1:23 PM, Peryt, Sebastian
wrote:
> I have rebased this patch to the latest trunk and addressed comments. Also,
> there was a test in changelog,
> but not in the patch itself - this has been added.
>
> Is it ok for trunk and backport to GCC-8 after few days?
>
> gcc/
>
>
On Wed, May 9, 2018 at 1:25 AM, Jan Hubicka wrote:
>> On Tue, 8 May 2018, Jan Hubicka wrote:
>>
>> > > On Tue, May 8, 2018 at 8:14 AM, Jan Hubicka wrote:
>> > > > Hi,
>> > > > with lto, incremental linking can be meaninfuly done in three ways:
>> > > > 1) read LTO file and produce non-LTO .o fil
On Tue, May 8, 2018 at 1:58 PM, Peryt, Sebastian
wrote:
> Sorry, forgot attachment.
>
> Sebastian
>
>
> -Original Message-
> From: Peryt, Sebastian
> Sent: Tuesday, May 8, 2018 1:56 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Uros Bizjak ; Kirill Yukhin ;
> Peryt, Sebastian
> Subject: [PATCH]
On Tue, May 8, 2018 at 1:34 PM, Peryt, Sebastian
wrote:
> Hi,
>
> This patch adds support for WAITPKG instructions.
>
> Is it ok for trunk and after few day for backport to GCC-8?
>
> 2018-05-08 Sebastian Peryt
>
> gcc/
>
> * common/config/i386/i386-common.c (OPTION_MASK_ISA_WAITPKG_SET
Richard Biener writes:
> On Wed, May 9, 2018 at 12:34 PM, Richard Sandiford
> wrote:
>> The SLP unrolling factor is calculated by finding the smallest
>> scalar type for each SLP statement and taking the number of required
>> lanes from the vector versions of those scalar types. E.g. for an
>> i
I have rebased this patch to the latest trunk and addressed comments. Also,
there was a test in changelog,
but not in the patch itself - this has been added.
Is it ok for trunk and backport to GCC-8 after few days?
gcc/
* common/config/i386/i386-common.c (OPTION_MASK_ISA_PTWRITE_SET,
This patch adds usadv64qi expander, so the compiler is able to
vectorize with 512bit vpsadbw insn.
2017-05-09 Uros Bizjak
PR target/85693
* config/i386/sse.md (usadv64qi): New expander.
Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
OK for mainline?
Uros.
diff --git
On Wed, May 9, 2018 at 12:34 PM, Richard Sandiford
wrote:
> The SLP unrolling factor is calculated by finding the smallest
> scalar type for each SLP statement and taking the number of required
> lanes from the vector versions of those scalar types. E.g. for an
> int32->int64 conversion, it's the
Hi Cesar!
On Mon, 7 May 2018 08:49:26 -0700, Cesar Philippidis
wrote:
> This patch teaches both the Fortran FE and the gimplifier how to only
> utilize one data mapping for OpenACC deviceptr clauses. [...]
Thanks! (I didn't verify your code changes.)
> In addition to XPASS'ing devicetpr-1.f
Hi,
the nvptx trap* define_insns are implemented using the ptx insn 'trap' .
The ptx insn 'trap' may however return, and therefore the ptx insn
'exit' is needed after the 'trap'.
Fixed by attached patch.
Build x86_64 with nvptx accelerator.
Committed to trunk.
Thanks,
- Tom
[nvptx] Make tr
The SLP unrolling factor is calculated by finding the smallest
scalar type for each SLP statement and taking the number of required
lanes from the vector versions of those scalar types. E.g. for an
int32->int64 conversion, it's the vector of int32s rather than the
vector of int64s that determines
On Tue, 8 May 2018, Jan Hubicka wrote:
> Hi,
> this patch adds the symtab support for LTO incremental linking. Most of the
> code path is same for both modes of incremental link except hat we want to
> produce LTO object file rather than compile down to assembly.
>
> Only non-obvious changes are
On Tue, 8 May 2018, Jan Hubicka wrote:
> Hi,
> this patch prevents lto-option to store some flags that does not make snese
> to store,
> in partiuclar dumpdir and -fresolution. These definitly should not be
> preserved from
> compile time to link time and in case of incremental linking they caus
> So it isn't clear to me if a cxx_make_decl_one_only is the way to go. Maybe
> doing the recalculation in comdat_linkage and maybe_make_one_only only
> would be sufficient.
Patch to that effect attached, tested on x86-64/Linux, OK for mainline?
2018-05-09 Eric Botcazou
cp/
PR c++/8
On Tue, 8 May 2018, Jan Hubicka wrote:
> Hi,
> this patch makes lto-wrapper to look for -flinker-output=rel and in this
> case confiugre lto1 in non-WHOPR mode + disable section renaming.
>
> Bootstrapped/regtested x86_64-linux with rest of incremental link patchset.
> OK?
>
> * lto-wrappe
On Tue, 8 May 2018, Jan Hubicka wrote:
> Hi,
> for incremental linking of LTO objects we need to copy debug sections from
> source object files into destination without renaming them from .gnu.debuglto
> into the standard debug section (because they will again be LTO debug section
> in the resulti
On Fri, May 4, 2018 at 8:37 PM, Jakub Jelinek wrote:
> Hi!
>
> This patch adds parsing of if and nontemporal clauses for simd construct
> and also adds parsing of (optional) cancel modifier for if clause on cancel
> directive.
>
> While nontemporal clause is just an optimization (we still want to
On Tue, May 8, 2018 at 5:56 PM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Tue, May 8, 2018 at 3:25 PM, Richard Sandiford
>> wrote:
>>> We build up the input to IFN_STORE_LANES one vector at a time.
>>> In RTL, each of these vector assignments becomes a write to
>>> subregs of the f
On 07/05/18 12:39 -0400, Ed Smith-Rowland wrote:
All,
We were using a different convention for P_l^m assoc_legendre(int l,
int m, FloatTp x)
- the so-called Condon-Shortley convention which includes (-1)^m.
This unfortunately is common.
This factor is taken out to match the standard. Th
On Tue, May 08, 2018 at 01:25:35PM +0200, Allan Sandfeld Jensen wrote:
> 2018-05-08 Allan Sandfeld Jensen
2 spaces between date and name and two spaces between name and email
address.
> gcc/
>
> PR tree-optimization/85692
> * tree-ssa-forwprop.c (simplify_vector_cons
On 08/05/18 16:51 -0700, Ian Lance Taylor via libstdc++ wrote:
On Tue, May 8, 2018 at 12:54 PM, François Dumont wrote:
I'll go with this version for now but I'll look into libbacktrace.
It will be perhaps the occasion to play with autoconf & al tools to find out
if I can use libbacktrace.
I
On Tue, May 08, 2018 at 11:28:18PM -0400, Jason Merrill wrote:
> Maybe add a type parameter that defaults to size_type_node...
>
> >
> > --- gcc/c/c-fold.c.jj 2018-01-17 22:00:12.310228253 +0100
> > +++ gcc/c/c-fold.c 2018-05-08 21:52:43.303940175 +0200
> > @@ -473,7 +473,8 @@ c_fully_fold_
> On Tue, 8 May 2018, Jan Hubicka wrote:
>
> > > On Tue, May 8, 2018 at 8:14 AM, Jan Hubicka wrote:
> > > > Hi,
> > > > with lto, incremental linking can be meaninfuly done in three ways:
> > > > 1) read LTO file and produce non-LTO .o file
> > > > this is current behaviour of gcc -r or ld -
> 2018-05-07 Eric Botcazou
>
> PR rtl-optimization/85638
> * bb-reorder.c: Include common/common-target.h.
> (create_forwarder_block): New function extracted from...
> (fix_up_crossing_landing_pad): ...here. Rename into...
> (dw2_fix_up_crossing_landing_pad): ...t
On Tue, 8 May 2018, Jan Hubicka wrote:
> > On Tue, May 8, 2018 at 8:14 AM, Jan Hubicka wrote:
> > > Hi,
> > > with lto, incremental linking can be meaninfuly done in three ways:
> > > 1) read LTO file and produce non-LTO .o file
> > > this is current behaviour of gcc -r or ld -r with plugin
> Now, neither of the two branches needs to have LR restored at all,
> because both of the branches end up in an infinite loop.
>
> This patch makes spread_component return a boolean saying if anything
> was changed, and if so, it is called again. This obviously is finite
> (there is a finite num
> 2018-05-08 Segher Boessenkool
>
> PR rtl-optimization/85645
> * regrename.c (build_def_use): Also kill the chains that include the
> destination of a REG_CFA_REGISTER note.
OK, thanks.
--
Eric Botcazou
> 2018-05-08 Segher Boessenkool
>
> PR rtl-optimization/85645
> * regcprop.c (copyprop_hardreg_forward_1): Don't propagate into an
> insn that has a REG_CFA_REGISTER note.
OK, thanks.
--
Eric Botcazou
67 matches
Mail list logo
