On 07/04/2017 12:23 PM, Tom de Vries wrote:
On 07/04/2017 12:05 PM, Tom de Vries wrote:
On 07/03/2017 04:24 PM, Tom de Vries wrote:
On 07/03/2017 04:08 PM, Thomas Schwinge wrote:
Hi!
On Mon, 26 Jun 2017 17:29:11 +0200, Jakub Jelinek
wrote:
On Mon, Jun 26, 2017 at 03:26:57PM +, Joseph M
On 08/28/2017 04:33 PM, Alan Modra wrote:
> On Mon, Aug 28, 2017 at 08:27:35AM -0600, Jeff Law wrote:
>> So sorry for the horrible delay. What was the final resolution here? I
>> saw a lot of back and forth with HJ and yourself. 80044 is
>> CLOSED/WONTFIX and 81170 has a patch attached to it, bu
This is a two part patchkit to improve DOM's ability to derive constant
equivalences that arise as a result of traversing a particular edge in
the CFG.
Until now we only allowed a single NAME = NAME|CONST equivalence to be
associated with an edge in the CFG. Patch #1 generalizes that code so
that
ping^3
Thanks,
Kugan
On 11 August 2017 at 16:09, Kugan Vivekanandarajah
wrote:
> Ping^2?
>
> Thanks,
> Kugan
>
> On 21 July 2017 at 20:12, Kugan Vivekanandarajah
> wrote:
>> Ping ?
>>
>> Thanks,
>> Kugan
>>
>> On 27 June 2017 at 11:20, Kugan Vivekanandarajah
>> wrote:
>>> https://gcc.gnu.org/m
One of the local programmers tried to use the __builtin_unpack_vector_int128
function, but his second argument was not the constant 0 or 1. The compiler
put the 2nd argument into a register, but there wasn't a valid insn for this,
and raised an insn not found message. GCC should warn about this i
Ping: https://gcc.gnu.org/ml/gcc-patches/2017-08/msg01087.html
On 08/24/2017 02:43 PM, Martin Sebor wrote:
The bulk of this patch touches what I think is considered
the middle-end (attribs.c) so let me include its maintainers,
Ian, Jeff, and Richard:
https://gcc.gnu.org/ml/gcc-patches/2017-08
Ping #2: https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00912.html
On 08/23/2017 01:46 PM, Martin Sebor wrote:
Ping: https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00912.html
Jeff, is this version good to commit or are there any other
changes you'd like to see?
Martin
On 08/14/2017 04:40 PM, Ma
On Aug 28, 2017, at 3:56 PM, Bill Schmidt wrote:
>
> Hi,
>
> PR81833 identifies a problem with the little-endian vector multiply-sum
> instructions. The original implementation is quite poor (and I am allowed
> to say that, since it was mine). This patch fixes the code properly.
>
> The revi
On 08/24/2017 04:09 PM, Jeff Law wrote:
On 08/22/2017 02:45 AM, Richard Biener wrote:
On Mon, Aug 21, 2017 at 10:10 PM, Martin Sebor wrote:
On 08/09/2017 10:14 AM, Jeff Law wrote:
On 08/06/2017 05:08 PM, Martin Sebor wrote:
Well, simply because the way as implemented isn't a must-alias qu
On 08/22/2017 02:45 AM, Richard Biener wrote:
On Mon, Aug 21, 2017 at 10:10 PM, Martin Sebor wrote:
On 08/09/2017 10:14 AM, Jeff Law wrote:
On 08/06/2017 05:08 PM, Martin Sebor wrote:
Well, simply because the way as implemented isn't a must-alias query
but maybe one that's good enough for
On Mon, Aug 28, 2017 at 08:27:35AM -0600, Jeff Law wrote:
> So sorry for the horrible delay. What was the final resolution here? I
> saw a lot of back and forth with HJ and yourself. 80044 is
> CLOSED/WONTFIX and 81170 has a patch attached to it, but is still in the
> ASSIGNED state.
The patch
The following patch allows shrink-wrapping to succeed in the presence of
non-volatile CR save/restore. The movesi_from_cr define_insn used to
list all CRs as used, even though it's only the non-volatile values that
we are interested in saving/restoring. This prevented the prolog from
being moved pa
Hi,
PR81833 identifies a problem with the little-endian vector multiply-sum
instructions. The original implementation is quite poor (and I am allowed
to say that, since it was mine). This patch fixes the code properly.
The revised code still uses UNSPECs for these ops, which is not strictly
ne
Hi Thomas,
>>> I think an unconditional warning is OK
>>> in this case because
>>>
>>> - Assigning to a pointer from an obvious non-contiguous target
>>>is not useful at all, that I can see
>>
>>
>> I guess you're talking about a *contiguous* pointer here,
>
> Correct.
>
>> and in that
>> case
> On Aug 28, 2017, at 7:37 AM, Richard Biener
> wrote:
>
> Not sure, but would it be fixed in a similar way when writing
> ?
Thanks, Richard, that works very well. I decided this was a good opportunity
to also
simplify the control flow a little with early returns. Here's the result.
Boots
Hi
Here is the always equal allocator optimization for associative
containers.
Tested under Linux x86_64.
* include/bits/stl_tree.h
(_Rb_tree_impl(_Rb_tree_impl&&, _Node_allocator&&)): New.
(_Rb_tree(_Rb_tree&&, _Node_allocator&&, std::true_type)): New.
(_Rb_tree(_Rb_t
On 08/28/2017 01:05 PM, Richard Sandiford wrote:
>
>> As for the name, get_nonvoid? Ugh. Not sure. Open to suggestions.
>
> I'd rather avoid "nonvoid", since the use of VOIDmode for "no mode" is
> really an implementation detail in things like opt_mode .
> Other possiblities might be:
Yea, goo
Hi
Any news for this patch ?
It does remove a constructor:
-_Fwd_list_impl(const _Node_alloc_type& __a)
-: _Node_alloc_type(__a), _M_head()
It was already unused before the patch. Do you think it has ever
been used and so do I need to restore it ?
I eventuall
Some quick tests show that memory use increased by 1.5% Compilation
time reduced by 1% to 3%
Your comment on IRC about not needing a identifier->decl map, just a
decl hash, because the decl already has the identifier is a good one. I
recall considering that when converting namespaces, but th
Jeff Law writes:
> On 08/11/2017 12:24 PM, Richard Sandiford wrote:
>> Jeff Law writes:
>>> On 07/13/2017 02:40 AM, Richard Sandiford wrote:
GET_MODE_WIDER previously returned VOIDmode if no wider mode existed.
That would cause problems with stricter mode classes, since VOIDmode
is
2017-08-28 10:31 GMT+02:00 Thomas Koenig :
> Hi Janus,
>
>> the attached patch fixes a bogus warning. The purpose of the warning
>> is to detect cases where a pointer lives longer than its target. If
>> the target itself is (1) a pointer or (2) a component of a DT pointer,
>> we do not know about t
When I added the optimization for loading 32-bit values directly into the
vector registers from memory to convert to IEEE 128-bit floating point, I
forgot to make sure the address did not have PRE_INCREMENT, etc. addressing.
I checked the compiler on a little endian power8 system. Is it ok to che
On Aug 28, 2017, at 1:40 PM, Bill Schmidt wrote:
>
>>
>> On Aug 28, 2017, at 12:57 PM, Bill Schmidt
>> wrote:
>>
>> On Aug 28, 2017, at 7:37 AM, Richard Biener
>> wrote:
>>>
>>> On Thu, Aug 3, 2017 at 9:34 PM, Bill Schmidt
>>> wrote:
Hi,
Here's v2 of the patch with Jakub's
> On Aug 28, 2017, at 12:57 PM, Bill Schmidt
> wrote:
>
> On Aug 28, 2017, at 7:37 AM, Richard Biener
> wrote:
>>
>> On Thu, Aug 3, 2017 at 9:34 PM, Bill Schmidt
>> wrote:
>>> Hi,
>>>
>>> Here's v2 of the patch with Jakub's suggestions incorporated. Bootstrapped
>>> and tested on powerpc6
On Mon, Aug 28, 2017 at 11:42:53AM -0600, Jeff Law wrote:
> On 07/17/2017 08:35 AM, Joerg Sonnenberger wrote:
> > Hello,
> > attached patch fixes inconsistent handling of section flags when using
> > the section attribute, i.e.:
> >
> > __attribute__((section("writable1"))) int foo1;
> > __attribu
Hi,
I think I found a bug in r17465:
...
* cse.c (simplify_ternary_operation): Handle more IF_THEN_ELSE
simplifications.
diff --git a/gcc/cse.c b/gcc/cse.c
index e001597..3c27387 100644
--- a/gcc/cse.c
+++ b/gcc/cse.c
@@ -4713,6 +4713,17 @@ simplify_ternary_operation (code, mode,
On 08/10/2017 03:14 PM, Michael Collison wrote:
> Hi all,
>
> One issue that we keep encountering on aarch64 is GCC not making good use of
> the flag-setting arithmetic instructions
> like ADDS, SUBS, ANDS etc. that perform an arithmetic operation and compare
> the result against zero.
> They ar
On Fri, 2017-08-25 at 15:37 +0100, Szabolcs Nagy wrote:
> the use of ifunc in gcc target libraries was a mistake
> in my opinion, there are several known bugs in the ifunc
> design and uclibc/musl/bionic don't plan to support it.
> but at this point i dont have a better proposal for doing
> runtim
On 08/11/2017 12:24 PM, Richard Sandiford wrote:
> Jeff Law writes:
>> On 07/13/2017 02:40 AM, Richard Sandiford wrote:
>>> GET_MODE_WIDER previously returned VOIDmode if no wider mode existed.
>>> That would cause problems with stricter mode classes, since VOIDmode
>>> isn't for example a valid s
On Aug 28, 2017, at 7:37 AM, Richard Biener wrote:
>
> On Thu, Aug 3, 2017 at 9:34 PM, Bill Schmidt
> wrote:
>> Hi,
>>
>> Here's v2 of the patch with Jakub's suggestions incorporated. Bootstrapped
>> and tested on powerpc64le-linux-gnu with no regressions. Is this ok for
>> trunk?
>>
>> Even
On 07/17/2017 08:35 AM, Joerg Sonnenberger wrote:
> Hello,
> attached patch fixes inconsistent handling of section flags when using
> the section attribute, i.e.:
>
> __attribute__((section("writable1"))) int foo1;
> __attribute__((section("readonly1"))) const int foo1c;
> __attribute__((section("
On Mon, Aug 28, 2017 at 9:10 AM, Joseph Myers wrote:
> On Tue, 8 Aug 2017, H.J. Lu wrote:
>
>> This patch adds -static-pie to GCC driver to create static PIE. A static
>> position independent executable (PIE) is similar to static executable,
>> but can be loaded at any address without a dynamic l
Hi,
On Mon, 28 Aug 2017, Nathan Sidwell wrote:
> This patch replaces the sorted field vector with a hash map. Lookup for
> non-function members of a complete class is now O(1), not O(log(n)).
> We still do linear lookup when the class is incomplete. Fixing that is
> still on the todo list.
On Mon, 28 Aug 2017, Joseph Myers wrote:
> On Sat, 26 Aug 2017, Richard Biener wrote:
>
> > On August 26, 2017 12:51:57 AM GMT+02:00, Joseph Myers
> > wrote:
> > >I'm seeing a build failure for s390x-linux-gnu that looks like it could
> > >be
> > >related to this change (build was OK at r25133
This patch replaces the sorted field vector with a hash map. Lookup for
non-function members of a complete class is now O(1), not O(log(n)). We
still do linear lookup when the class is incomplete. Fixing that is
still on the todo list.
This permits moving a bunch of sorted_field_vec handlin
On Sat, 26 Aug 2017, Richard Biener wrote:
> On August 26, 2017 12:51:57 AM GMT+02:00, Joseph Myers
> wrote:
> >I'm seeing a build failure for s390x-linux-gnu that looks like it could
> >be
> >related to this change (build was OK at r251332, failed at r251358).
>
> Can you please open a bug? C
On Tue, 8 Aug 2017, H.J. Lu wrote:
> This patch adds -static-pie to GCC driver to create static PIE. A static
> position independent executable (PIE) is similar to static executable,
> but can be loaded at any address without a dynamic linker. All linker
> input files must be compiled with -fpie
On Tue, 8 Aug 2017, Martin Liška wrote:
> Hi.
>
> As mentioned in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39851#c0 we need
> to call targetm.target_option.override () in order to properly report which
> ISA options are enabled for a -march/-mtune. Currently, opts.c uses just
> #include "comm
Hi Rainer,
> On 28 Aug 2017, at 16:33, Rainer Orth wrote:
>
> Hi Mike,
>
>> On Aug 12, 2017, at 9:03 AM, Rainer Orth
>> wrote:
>>>
>>> The new gcc.dg/pie-static-[12].c testcases FAIL on several systems:
>>>
>>> * Solaris 11.4 has PIE support, but lacks static libc, libm
>>>
>>> * Linux wit
Hi Mike,
> On Aug 12, 2017, at 9:03 AM, Rainer Orth
> wrote:
>>
>> The new gcc.dg/pie-static-[12].c testcases FAIL on several systems:
>>
>> * Solaris 11.4 has PIE support, but lacks static libc, libm
>>
>> * Linux without the static libc, libm installed
>>
>> The following patch fixes this
On 07/03/2017 12:37 PM, David Malcolm wrote:
> This patch improves our C/C++ frontends' handling of missing
> symbols, by making c_parser_require and cp_parser_require use
> "better" locations for the diagnostic, and insert fix-it hints,
> under certain circumstances (see the comments in the patch
this patch moves the FIELD_VEC creation routines from class.c to
name-lookup.c
It's slightly more than a simple move as I include the following renaming:
insert_into_classtype_sorted_fields -> set_class_bindings
insert_late_enum_def_into_classtype_sorted_fields ->
insert_late_enum_def_bindings
On 06/22/2017 09:28 AM, Alan Modra wrote:
> PR80044 notes that -static and -pie together behave differently when
> gcc is configured with --enable-default-pie as compared to configuring
> without (or --disable-default-pie). This patch removes that
> difference. In both cases you now will have -st
I committed this update to my post of
https://gcc.gnu.org/ml/gcc-patches/2017-08/msg01011.html, deciding it
now sufficiently obvious :)
nathan
--
Nathan Sidwell
2017-08-28 Nathan Sidwell
* gcc.c (execute): Fold SIGPIPE handling into switch
statement. Adjust internal error message.
Index
Hi Janus,
I think an unconditional warning is OK
in this case because
- Assigning to a pointer from an obvious non-contiguous target
is not useful at all, that I can see
I guess you're talking about a *contiguous* pointer here,
Correct.
and in that
case I would argue that, beyond be
Hello,
The code in record_address_regs shown in the following patch assumes that
if a given target cannot have two registers in a memory address, then the
sole register, if present, must be the leftmost operand in the PLUS chain.
I think this is not true if the target uses unspecs to signify spec
Hi Richard,
I discussed with the original author, have looked into the ARM cache matters
in greater detail and certainly agree with your general concerns.
There are pieces related to the insn cache clearing in the code, but I can
see how architecture specific everything is here, indeed not approp
On Mon, Aug 28, 2017 at 10:57 AM, Dominik Inführ
wrote:
> Hi,
>
> As discussed on IRC: This patches fixes the calculation of the scalar costs
> of SLP vectorization. I’ve added a test case and the auto_vec allocation is
> now reused for all children of a node.
Looks good to me and thanks for th
On Mon, Aug 28, 2017 at 10:16 AM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Thu, Aug 17, 2017 at 1:06 PM, Richard Sandiford
>> wrote
>>> Richard Biener writes:
On Thu, Aug 17, 2017 at 11:49 AM, Richard Sandiford
wrote:
> Internal functions that map directly to an op
On Thu, Aug 3, 2017 at 9:34 PM, Bill Schmidt
wrote:
> Hi,
>
> Here's v2 of the patch with Jakub's suggestions incorporated. Bootstrapped
> and tested on powerpc64le-linux-gnu with no regressions. Is this ok for
> trunk?
>
> Eventually this should be backported to all active releases as well.
> O
On Fri, Aug 25, 2017 at 9:51 PM, Jeff Law wrote:
> On 07/31/2017 01:47 AM, Martin Liška wrote:
>> I would like to ping this. Input from other people will be appreciated ;)
> I think the thing to keep in mind here is that IIUC this only affects
> things when we've configured using the --with-stage1
On Fri, Aug 25, 2017 at 4:26 PM, Alexandre Oliva wrote:
> On Aug 23, 2017, Richard Biener wrote:
>
if they are not a problem up until here why care now?
>
>>> IIRC we do have a limit for VTA notes too, but there's a C++ testcase
>>> (g++.dg/tree-ssa/pr14703.C) that expands and inlines fibona
Ping (for this and patch 3/3 in the thread).
On Wed, 2 Aug 2017, Alexander Monakov wrote:
> Similar to mem_thread_fence issue from the patch 1/3, RTL representation of
> __atomic_signal_fence must be a compiler barrier. We have just one backend
> offering this pattern, and it does not place a co
The following avoids invalid flag combinations on removed sections
and fixes a word-size bug I noticed when doing so.
LTO bootstrap / testing in progress on x86_64-unknown-linux-gnu.
Richard.
2017-08-28 Richard Biener
PR lto/81968
* simple-object-elf.c (simple_object_elf_cop
I am testing the following to cure -gsplit-dwarf with early type
pruning.
It looks like we have zero testsuite coverage for -gsplit-dwarf
(or my grep skills are broken).
No testcase, g++.dg/[dwarf2/] isn't set up to do link tests.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
Rich
The following fixes a failure to account for lhs_offset (or rather
to consistently use the same offset in op0 and off).
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2017-08-28 Richard Biener
PR tree-optimization/81977
* tree-ssa-sccvn.c (vn
This involved renaming the rather general-sounding "enum direction" to
"enum pad_direction" to avoid a conflict with the Fortran frontend.
Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu.
Also tested by checking that there were no extra warnings or changes in
testsuite asse
The lack of function comments in msp430.c and rl78.c is deliberate;
the local style there is to define the hook macro immediately before
the function as a form of documentation.
Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu.
Also tested by checking that there were no extr
On Mon, 28 Aug 2017, Jon Beniston wrote:
> Hi Richard,
>
> >- if (nunits < 1) /* Support V1SI. */
> >+ if (nunits < 1 || (nunits == 1 && !reduct_p))
> > return NULL_TREE;
> >
> >doesn't seem to be against trunk which has
> >
> > if (nunits <= 1)
> >return NULL_TREE;
> >
> >so what hap
Hi,
As discussed on IRC: This patches fixes the calculation of the scalar costs of
SLP vectorization. I’ve added a test case and the auto_vec allocation is now
reused for all children of a node.
diff --git a/gcc/testsuite/gcc.dg/vect/costmodel/x86_64/costmodel-vect-slp.c
b/gcc/testsuite/gcc.dg
The SVE patches change the size of a machine_mode from a compile-time
constant to a runtime invariant. However, target-specific code can
continue to treat the modes as constant-sized if the target only has
constant-sized modes.
The main snag with this approach is that target-independent code stil
Hi Janus,
the attached patch fixes a bogus warning. The purpose of the warning
is to detect cases where a pointer lives longer than its target. If
the target itself is (1) a pointer or (2) a component of a DT pointer,
we do not know about the lifetime of the target at compile time and no
warning
Hi Richard,
>- if (nunits < 1) /* Support V1SI. */
>+ if (nunits < 1 || (nunits == 1 && !reduct_p))
> return NULL_TREE;
>
>doesn't seem to be against trunk which has
>
> if (nunits <= 1)
>return NULL_TREE;
>
>so what happens if you just change that to
>
> if (nunits < 1)
>return N
This patch adds helper functions that say which of the two modes
involved in a subreg is the larger, preferring the outer mode in
the event of a tie. It also converts IRA and reload to track modes
instead of byte sizes, since this is slightly more convenient when
variable-sized modes are added lat
This patch adds routines for converting a SUBREG_BYTE offset into a
memory address offset. The two only differ for paradoxical subregs,
where SUBREG_BYTE is always 0 but the memory address offset can be
negative.
Tested on aarch64-linux-gnu and x86_64-linux-gnu, and by checking
there was no chang
Richard Biener writes:
> On Thu, Aug 17, 2017 at 1:06 PM, Richard Sandiford
> wrote
>> Richard Biener writes:
>>> On Thu, Aug 17, 2017 at 11:49 AM, Richard Sandiford
>>> wrote:
Internal functions that map directly to an optab can only throw an
exception for -fnon-call-exceptions. Thi
On Sun, 27 Aug 2017, Jon Beniston wrote:
> Hi,
>
> I have an out-of-tree GCC port and it is struggling supporting
> auto-vectorization on some dot product instructions. For example, I have an
> instruction that takes three operands which are all 32-bit general
> registers. The second and third o
67 matches
Mail list logo
