On 03/10/2017 09:20 AM, Martin Sebor wrote:
On 03/10/2017 05:57 AM, Rainer Orth wrote:
Hi Segher,
On Fri, Feb 10, 2017 at 11:56:39AM +0100, Rainer Orth wrote:
Segher Boessenkool writes:
As stated in the PR, this test now passes on aarch64, ia64, powerpc,
and s390x. This patch disables the
On Fri, 2017-03-10 at 07:33 +0100, Jakub Jelinek wrote:
> On Thu, Mar 09, 2017 at 12:45:28PM -0500, David Malcolm wrote:
> > PR target/79926 notes that in:
> >
> > sorry ("%s instructions aren't allowed in %s service routine",
> >isa, (cfun->machine->func_type == TYPE_EXCEPTION
> >
On Thu, 9 Mar 2017, Bill Schmidt wrote:
> The one statement I've made that I'm not quite confident is that
> __float128 is an alias for _Float64x on hppa HP-UX. This was not
> clear in the original text, so I'd appreciate confirmation or
> correction on this point.
It can't simultaneously be an
On Thu, 9 Mar 2017, David Malcolm wrote:
> gcc/ChangeLog:
> PR target/79925
> * config/aarch64/aarch64.c (aarch64_validate_mcpu): Quote the
> full command-line argument, rather than just "str".
> (aarch64_validate_march): Likewise.
> (aarch64_validate_mtune): Likewise
On Thu, 9 Mar 2017, David Malcolm wrote:
> However, we're deep in stage 4 of the development cycle. Looking at
> our development plan
> https://gcc.gnu.org/develop.html
> it's not clear to me how such changes fit into our schedule: the plan
> seems to make no mention of how i18n and translation
On Mon, 6 Mar 2017, Marek Polacek wrote:
> I didn't like that the function implicit_decl_warning is
> a) missing a comment,
> b) missing braces in an if were confusing,
> b) wrongly formatted,
>else
> if ()
>is ugly.
>
> This patches fixes the above.
>
> Bootstrapped/regtested on x8
On Fri, 2017-03-10 at 09:24 +, Kyrill Tkachov wrote:
> On 10/03/17 06:24, Jakub Jelinek wrote:
> > On Thu, Mar 09, 2017 at 12:45:25PM -0500, David Malcolm wrote:
> > > gcc/ChangeLog:
> > > PR translation/79923
> > > * auto-profile.c (get_combined_location): Convert leading
> > > character
In this PR, we have a few insns involved in two instruction combinations:
insn 16: set r100
insn 27: some calculation
insn 28: some calculation
insn 32: using r100
insn 33: using r100
insn 35: some calculation
Then we combine insns 27, 28 and 33, producing two output insns, As a
result, insn 28
Hi,
On 10/03/2017 16:57, Jason Merrill wrote:
On Fri, Mar 10, 2017 at 9:58 AM, Paolo Carlini wrote:
As such, the broken declaration cannot be rejected by the code we have in
finish_struct, something must happen earlier than that. It seems to me that
xref_tag_1 can be a good place, per the belo
On Mar 10, 2017, Alexandre Oliva wrote:
> Now, if there's something you dislike about maps, we could make it a
> doubly-linked list, or maybe even a singly-linked list.
Scratch that, there's a use that may remove after a lookup by base_addr,
so a singly-linked list would require a linear walk of
Ping (minus the require-effective-target line, as Uros pointed out).
Bernd
On 03/03/2017 02:51 PM, Bernd Schmidt wrote:
This is an ICE where setup_pressure_classes fails if xmm0 is a global
reg. Instead of GENERAL/FLOAT/SSE/MMX_REGS, it computes only
SSE_FIRST_REG as the third register class.
On Mar 10, 2017, Richard Biener wrote:
>>> So - if we fix this can we fix it by properly sorting things?
>> I don't see a way to do better, considering there's no real ID we could
>> use for sorting. Do you?
> Just use the ID you use but instead of maintaining a hash-map and traverse
> that co
Hello.
As briefly discussed in the PR, there are BB that do not correspond to a real
line in source
code. profile.c emits locations for all BBs that have a gimple statement
belonging to a line.
I hope these should be marked in gcov utility and not added in --all-block mode
to counts of lines.
On Thu, 2017-03-09 at 21:12 -0700, Martin Sebor wrote:
> On 03/09/2017 10:45 AM, David Malcolm wrote:
> > gcc/ChangeLog:
> > PR driver/79875
> > * opts.c (parse_sanitizer_options): Add missing question mark
> > to
> > "did you mean" message.
> > ---
> > gcc/opts.c | 2 +-
> > 1 file ch
On March 10, 2017 6:56:40 PM GMT+01:00, Jakub Jelinek wrote:
>Hi!
>
>The following patch teaches VRP that IMAGPART_EXPR of
>ATOMIC_COMPARE_EXCHANGE ifn call is always 0 or 1. We cast it to bool
>afterwards, but this hint allows VRP to:
>--- pr79981.c.103t.vrp1_ 2017-03-10 15:39:29.0
These files won't build on targets that do not have AltiVec enabled,
breaking the build, unless we tell GAS that Altivec insns are fine.
The alternative is to not build these files in that case, which is much
more complicated.
Tested on powerpc64-linux {-m64,-m32}, powerpc64le-linux, and on
powerp
Thanks! Committed in revision 246046.
> On Mar 10, 2017, at 1:14 PM, Segher Boessenkool
> wrote:
>
> On Fri, Mar 10, 2017 at 12:16:31PM -0600, Bill Schmidt wrote:
>> Jakub observed that these built-ins are no longer reachable (and
>> haven't been for quite a while). Time to chuck them out.
>>
On Fri, Mar 10, 2017 at 12:16:31PM -0600, Bill Schmidt wrote:
> Jakub observed that these built-ins are no longer reachable (and
> haven't been for quite a while). Time to chuck them out.
>
> Bootstrapped and tested on powerpc64le-unknown-linux-gnu with
> (surprise!) no regressions. Is this ok f
On 03/10/2017 08:03 PM, David Malcolm wrote:
print-rtl.c:rtx_writer::print_rtx_operand_code_0 has some special
-casing for SYMBOL_REF, but if I'm reading things right we don't yet
dump SYMBOL_REF_BLOCK and SYMBOL_REF_BLOCK_OFFSET, so we'd need to dump
these somehow.
Yeah. Perhaps as an extra ta
On Fri, 2017-03-10 at 00:36 +0100, Bernd Schmidt wrote:
> On 03/09/2017 08:28 PM, David Malcolm wrote:
> > The root cause is an out-of-bounds memory write in the RTL dump
> > reader when handling SYMBOL_REFs with SYMBOL_FLAG_HAS_BLOCK_INFO
> > set.
> >
> > Such SYMBOL_REFs are normally created by
On Fri, Mar 10, 2017 at 07:52:37PM +0100, Bernd Schmidt wrote:
> On 03/10/2017 06:53 PM, Jakub Jelinek wrote:
> > +
> > +template
> > +static inline rtx
> > +ix86_delegitimize_address_tmpl (rtx x)
> > {
>
> Why is this a template and not a function arg?
That was just an attempt to ensure that t
On 03/10/2017 06:53 PM, Jakub Jelinek wrote:
+
+template
+static inline rtx
+ix86_delegitimize_address_tmpl (rtx x)
{
Why is this a template and not a function arg?
Bernd
Hi all,
The attached patch fixes this PR by properly stashing the internal unit created
by parent so that it may be correctly accessed by the child DTIO procedure.
Note the included test case. The Fortran Standard requires that the iotype be
passed to the child routine so that it is aware of
Hi,
Jakub observed that these built-ins are no longer reachable (and
haven't been for quite a while). Time to chuck them out.
Bootstrapped and tested on powerpc64le-unknown-linux-gnu with
(surprise!) no regressions. Is this ok for trunk?
Thanks,
Bill
2017-03-10 Bill Schmidt
* con
Hi!
The following patch teaches VRP that IMAGPART_EXPR of
ATOMIC_COMPARE_EXCHANGE ifn call is always 0 or 1. We cast it to bool
afterwards, but this hint allows VRP to:
--- pr79981.c.103t.vrp1_2017-03-10 15:39:29.0 +0100
+++ pr79981.c.103t.vrp1 2017-03-10 15:48:15.051608067 +0100
This fixes float128 on BE and on 32-bit.
The configure tests need to use -mabi=altivec for 32-bit, since it is
not the default there. That also enables the "vector" keyword, used by
the tests. To do this it temporarily adds a few flags to the CFLAGS
variable.
It also fixes a syntax error in the
Hi!
On the testcase in the PR (too large for our testsuite) we waste several
gigabytes of memory from allocations in ix86_delegitimize_address called
from find_base_{value,term}.
E.g. for find_base_term
(plus:SI (value:SI 1:1 @0x2c60f50/0x2c50f40)
(const:SI (plus:SI (unspec:SI [
Hi,
This patch fixes an error caused by my changing of the signal constants
on MIPS in r244026. While that patch worked on mipsel, ada fails to
bootstrap with it on mips64el with the error:
s-osinte.ads:610:07: component "sa_flags" overlaps "sa_handler" at line 608
../gcc-interface/Makefile:297:
The semantics of alias templates are still pretty unclear, but this
testcase looks like it ought to work. I decided to make it work by
treating partial ordering specially; while normally a use of a
non-transparent alias template compares as distinct from its
expansion, as necessary for proper rede
On Mar 10, 2017, at 8:22 AM, Jiong Wang wrote:
>
> I am seeing this failure on arm and aarch64 bare-metal environment where
> newlib are used.
>
> This patch also XFAIL this testcase on newlib.
>
> OK for trunk?
That's fine, if you want. The other solution is to actually fix newlib, which
w
Just so there's no duplication of effort -- I'll follow up with a patch to
remove the
outdated built-in.
-- Bill
Bill Schmidt, Ph.D.
GCC for Linux on Power
Linux on Power Toolchain
IBM Linux Technology Center
wschm...@linux.vnet.ibm.com
> On Mar 10, 2017, at 8:24 AM, Bill Schmidt wrote:
>
> J
On 07/02/17 16:01, Mike Stump wrote:
On Feb 7, 2017, at 2:20 AM, Rainer Orth wrote:
No. In fact, I'd go for something like this:
2017-02-07 Dominik Vogt
Rainer Orth
* g++.dg/tls/thread_local-order2.C: Only xfail execution on
*-*-solaris*.
# HG changeset patc
On 03/10/2017 05:57 AM, Rainer Orth wrote:
Hi Segher,
On Fri, Feb 10, 2017 at 11:56:39AM +0100, Rainer Orth wrote:
Segher Boessenkool writes:
As stated in the PR, this test now passes on aarch64, ia64, powerpc,
and s390x. This patch disables the xfails for those targets.
As I'd mentioned
On Fri, Mar 10, 2017 at 10:20 AM, Jonathan Wakely wrote:
> On 09/03/17 19:46 +, Jonathan Wakely wrote:
>>
>> On 03/03/17 10:47 -0500, David Edelsohn wrote:
>>>
>>> This patch caused a new regression on AIX.
>>
>>
>> I'm unable to bootstrap on either gcc111 or gcc119 so I can't test
>> the fix.
On Fri, Mar 10, 2017 at 9:58 AM, Paolo Carlini wrote:
> As such, the broken declaration cannot be rejected by the code we have in
> finish_struct, something must happen earlier than that. It seems to me that
> xref_tag_1 can be a good place, per the below patchlet, which passes testing
> on x86_64
On Fri, Mar 10, 2017 at 01:57:31PM +0100, Rainer Orth wrote:
> I just noticed that nothing has happened at all in a month, so anything
> is better than the tests XPASSing on a number of targets.
>
> So the patch is ok for mainline with sparc*-*-* added to the target
> lists and a reference to PR t
On 19/02/17 17:53 +0200, Ville Voutilainen wrote:
This has not been adopted by LEWG/LWG yet, but was submitted
as a proposed resolution for a new LWG issue; optional can't
current be compared to a T, and an optional can't be compared
to something non-T that is comparable to a T. This approach fix
OK.
On Tue, Mar 7, 2017 at 2:03 PM, Jakub Jelinek wrote:
> Hi!
>
> Apparently in error recovery, populate_clone_array can't return fns
> with all NULLs. maybe_thunk_body used to handle that fine, but
> the newly added ctor_omit_inherited_parms call ICEs.
>
> Fixed thusly, bootstrapped/regtested
On 09/03/17 19:46 +, Jonathan Wakely wrote:
On 03/03/17 10:47 -0500, David Edelsohn wrote:
This patch caused a new regression on AIX.
I'm unable to bootstrap on either gcc111 or gcc119 so I can't test
the fix.
export CONFIG_SHELL=/usr/bin/bash
PATH=/opt/freeware/bin:$PATH
$gccsrcdir/conf
OK.
On Fri, Mar 10, 2017 at 6:48 AM, Marek Polacek wrote:
> Not sure of the validity of the test, but clang accepts it and so do we,
> with this patch. We shouldn't attempt to dereference a pointer that
> could be NULL without checking it first.
>
> Bootstrapped/regtested on x86_64-linux, ok for
OK.
On Tue, Mar 7, 2017 at 2:00 PM, Jakub Jelinek wrote:
> Hi!
>
> Doing copy_node on error_mark_node doesn't work too well, lots of spots
> in the compiler assume there is just a single error_mark_node and compare
> it using pointer comparison, rather than checking for TREE_CODE () ==
> ERROR_MA
Hi,
PR 77333 is a i686-windows target bug, which however has its root in
our general mechanism of adjusting gimple statements when redirecting
call graph edge. Basically, these three things trigger it:
1) IPA-CP figures out that the this parameter of a C++ class method is
unused and because t
Hi,
if you like, this ICE is closely related to c++/60848, but occurs when
we don't have (yet) a broken definition of std::initializer_list, only a
declaration, which is nonetheless able to cause an ICE at the beginning
of build_list_conv, as called by implicit_conversion for the testcase at
On Fri, Mar 10, 2017 at 03:31:39PM +0100, Rainer Orth wrote:
> Hi Toma,
>
> >> I just noticed that nothing has happened at all in a month, so anything
> >> is better than the tests XPASSing on a number of targets.
> >>
> >> So the patch is ok for mainline with sparc*-*-* added to the target
> >>
Hi Toma,
>> I just noticed that nothing has happened at all in a month, so anything
>> is better than the tests XPASSing on a number of targets.
>>
>> So the patch is ok for mainline with sparc*-*-* added to the target
>> lists and a reference to PR testsuite/79356 in the comment.
>>
>> I'd stil
Jumping in so we can continue the Will/Bill confusion: ;)
The official prototypes from the original AltiVec PIM are:
vector unsigned short vec_mule (vector unsigned char, vector unsigned char);
vector signed short vec_mule (vector signed char, vector signed char);
vector unsigned int vec_mule (v
On Fri, Mar 10, 2017 at 08:08:06AM -0600, Will Schmidt wrote:
> > > --- /dev/null
> > > +++ b/gcc/testsuite/gcc.target/powerpc/fold-vec-mule-misc.c
> > > @@ -0,0 +1,61 @@
> > > +/* PR target/79941 */
> > > +
> > > +/* { dg-do run } */
> > > +/* { dg-require-effective-target powerpc_vsx_ok } */
> >
>
> I just noticed that nothing has happened at all in a month, so anything
> is better than the tests XPASSing on a number of targets.
>
> So the patch is ok for mainline with sparc*-*-* added to the target
> lists and a reference to PR testsuite/79356 in the comment.
>
> I'd still be very grat
On 03/09/2017 04:26 PM, Segher Boessenkool wrote:
> That looks correct. Okay for trunk, thanks! Does it need backporting
> as well?
The -mupper-regs-di support is new in GCC 7 and I verified the testcase
compiles fine with GCC 5/6, so no backporting necessary.
-Pat
On Thu, 2017-03-09 at 17:24 -0600, Segher Boessenkool wrote:
> Hi Will,
>
> On Thu, Mar 09, 2017 at 10:52:52AM -0600, Will Schmidt wrote:
> > Per PR79941, we are folding the vec_mul{e,o}* operations improperly. Those
> > entries were added to the intrinsics-to-be-folded list where the generic
> >
Hello.
Currently, __builtin_ia32_bndret is used for all functions that have non-void
return type. I think the right fix is to return bounds just for a bounded type.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Martin
>From f4ad5003a42ca95187305a9b
On Fri, Mar 10, 2017 at 02:09:20PM +0100, Martin Liška wrote:
> Hello.
>
> This is follow-up patch which I agreed on with Jakub.
> It enables CHKP with LSAN and majority of UBSAN options.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Mart
Hello.
This is follow-up patch which I agreed on with Jakub.
It enables CHKP with LSAN and majority of UBSAN options.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Martin
>From a410d5e4e028d34dc00b4aa637cdcd3986b971d8 Mon Sep 17 00:00:00 2001
From:
Hi Segher,
> On Fri, Feb 10, 2017 at 11:56:39AM +0100, Rainer Orth wrote:
>> Segher Boessenkool writes:
>>
>> > As stated in the PR, this test now passes on aarch64, ia64, powerpc,
>> > and s390x. This patch disables the xfails for those targets.
>>
>> As I'd mentioned in PR tree-optimization/
On 10/03/17 12:12 +, Richard Sandiford wrote:
libstdc++-v3 configure checks whether old glibc inline definitions
of isnan would conflict with the libstdc++-v3 definitions and
works around them if so. But if g++ 6.x build A is used to build
another g++ 6.x B, the configure step for B will pic
libstdc++-v3 configure checks whether old glibc inline definitions
of isnan would conflict with the libstdc++-v3 definitions and
works around them if so. But if g++ 6.x build A is used to build
another g++ 6.x B, the configure step for B will pick up the math.h
installed alongside A instead of the
On 10/03/17 19:36 +0800, Xi Ruoyao wrote:
Hi,
This was resent to be in both libstdc++ and gcc-patches list.
Thanks.
The ill-formed checking in binary_heap::push_heap has made it
O(n). Remove this checking.
The checking certainly looks redundant, I wouldn't say ill-formed
though (that's a f
Not sure of the validity of the test, but clang accepts it and so do we,
with this patch. We shouldn't attempt to dereference a pointer that
could be NULL without checking it first.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2017-03-10 Marek Polacek
PR c++/79967
*
Hi,
This was resent to be in both libstdc++ and gcc-patches list.
The ill-formed checking in binary_heap::push_heap has made it
O(n). Remove this checking.
Since assert_valid also checks if (*this) is a legal heap, we can
remove is_heap and the assertions using it completely.
Bootstrapped and t
On Fri, Mar 10, 2017 at 07:18:24PM +0800, Xi Ruoyao wrote:
> Hi,
>
> The ill-formed checking in binary_heap::push_heap has made it
> O(n). Remove this checking.
>
> Since assert_valid also checks if (*this) is a legal heap, we can
> remove is_heap and the assertions using it completely.
I think
Hi,
The ill-formed checking in binary_heap::push_heap has made it
O(n). Remove this checking.
Since assert_valid also checks if (*this) is a legal heap, we can
remove is_heap and the assertions using it completely.
Bootstrapped and tested on x86_64-linux-gnu.
2017-03-09 Xi Ruoyao
PR
> On Mar 10, 2017, at 10:20 , Richard Biener wrote:
>
>> Is this one OK ?
>
> Ok.
Committing, thanks!
On Fri, Mar 10, 2017 at 12:02 AM, Alexandre Oliva wrote:
> On Mar 8, 2017, Richard Biener wrote:
>
>> On Wed, Mar 8, 2017 at 12:58 AM, Alexandre Oliva wrote:
>>> Don't let pointer randomization change the order in which we process
>>> store chains. This may cause SSA_NAMEs to be released in di
On 10/03/17 09:30, Jakub Jelinek wrote:
On Fri, Mar 10, 2017 at 09:24:18AM +, Kyrill Tkachov wrote:
On 10/03/17 06:24, Jakub Jelinek wrote:
On Thu, Mar 09, 2017 at 12:45:25PM -0500, David Malcolm wrote:
gcc/ChangeLog:
PR translation/79923
* auto-profile.c (get_combined_loc
On Fri, Mar 10, 2017 at 09:24:18AM +, Kyrill Tkachov wrote:
>
> On 10/03/17 06:24, Jakub Jelinek wrote:
> > On Thu, Mar 09, 2017 at 12:45:25PM -0500, David Malcolm wrote:
> > > gcc/ChangeLog:
> > > PR translation/79923
> > > * auto-profile.c (get_combined_location): Convert leading
> > >
On 10/03/17 06:24, Jakub Jelinek wrote:
On Thu, Mar 09, 2017 at 12:45:25PM -0500, David Malcolm wrote:
gcc/ChangeLog:
PR translation/79923
* auto-profile.c (get_combined_location): Convert leading
character of diagnostics to lower case and remove trailing period.
On Thu, Mar 9, 2017 at 10:24 PM, Olivier Hainque wrote:
>> Yes, unconditionally.
>
> Here's an adjusted patch, pleasantly simpler indeed
> (thanks again for the suggestion).
>
> Test passes fine as well.
>
> Is this one OK ?
Ok.
Richard.
> Olivier
>
> * tree-switch-conversion (array_val
67 matches
Mail list logo
