Hi all,
The attached patch is part 1 of a 2 part patch. This part fixes a few problems
with handling of advance= and EOR conditions. This does not resolve the
original case in the PR but gets some issues out of the way so I can continue.
The most notable change is that per standard, child I
Since I've also spent some time on this: my take on this is that the C++ FE
should just follow C FE's suit and reject such initializations where
possible; it seems they've never worked reliably anyway, and bring more
harm than good. I don't see that rejecting such code would cause too much
troubl
GDB has had a work-around that uses the typedef name as the name of an
anonymous class, struct or union, when introducing them through libcc1's
C++ API. It didn't do that for enums, that remained anonymous, and GCC
warned about using types without linkage as members of types with
linkage, which en
When two VALUEs are recorded in the cselib equivalence table such that
they are equivalent to each other XORed with the same expression, if
we started a cselib equivalence test between say the odd one and the
even one, we'd end up recursing to compare the even one with the odd
one, and then again,
I'm not 100% sure I understand what changes you're suggesting
but the attached patch does what I think you're after. Is that
what you had in mind?
Looks good.
Thanks. I just committed it to trunk but forgot to ask for approval
to backport it to 6 and 5.
Martin
On Tue, Mar 21, 2017 at 08:41:01PM +0100, Jakub Jelinek wrote:
> On Tue, Mar 21, 2017 at 03:27:02PM -0400, Jason Merrill wrote:
> > OK.
> >
> > On Tue, Mar 21, 2017 at 11:38 AM, Marek Polacek wrote:
> > > This patch fixes a bogus maybe-uninitialized warning reported in the PR.
> > > The issue is
2017-03-12 1:04 GMT+01:00 Daniel Krügler :
> 2017-03-11 23:14 GMT+01:00 Daniel Krügler :
>> 2017-03-11 23:09 GMT+01:00 Tim Song :
>>> On Sat, Mar 11, 2017 at 3:37 PM, Daniel Krügler
>>> wrote:
2017-03-11 21:23 GMT+01:00 Tim Song :
> On Sat, Mar 11, 2017 at 1:32 PM, Daniel Krügler
> w
2017-03-12 13:16 GMT+01:00 Daniel Krügler :
> The following is an *untested* patch suggestion, please verify.
>
> Notes: My interpretation is that hash should be
> defined outside of the _GLIBCXX_COMPATIBILITY_CXX0X block, please
> double-check that course of action.
>
> I noticed that the preexist
Hi!
For non-gimple reg types var = x ? y : z; is gimplified as
x ? (var = y) : (var = z);. The problem is that if var is TREE_READONLY,
we can gimplify one of those assignments by promoting them to TREE_STATIC
(if not addressable) and making the initializer into their DECL_INITIAL.
That doesn't w
On Tue, Mar 21, 2017 at 06:53:34PM +0100, Jakub Jelinek wrote:
> On Tue, Mar 21, 2017 at 08:41:43AM +0100, Jakub Jelinek wrote:
> > On Tue, Mar 21, 2017 at 08:38:20AM +1000, Richard Henderson wrote:
> > > On 03/21/2017 07:15 AM, Jakub Jelinek wrote:
> > > > Not really sure what we should do if both
On Tue, Mar 21, 2017 at 03:27:02PM -0400, Jason Merrill wrote:
> OK.
>
> On Tue, Mar 21, 2017 at 11:38 AM, Marek Polacek wrote:
> > This patch fixes a bogus maybe-uninitialized warning reported in the PR.
> > The issue is that we're not able to fold away useless CLEANUP_POINT_EXPRs,
> > as e.g. i
On Tue, Mar 21, 2017 at 11:08 AM, Martin Sebor wrote:
> On 03/20/2017 10:27 PM, Jason Merrill wrote:
>>
>> On Mon, Mar 20, 2017 at 7:58 PM, Martin Sebor wrote:
>>>
>>> On 03/20/2017 05:51 PM, Jason Merrill wrote:
On Mon, Mar 20, 2017 at 7:04 PM, Martin Sebor wrote:
>
>
> At
On Tue, Mar 21, 2017 at 2:40 PM, Martin Sebor wrote:
> On 03/20/2017 03:11 PM, Jason Merrill wrote:
>>
>> On Thu, Feb 23, 2017 at 6:33 PM, Jason Merrill wrote:
>>>
>>> On Thu, Feb 23, 2017 at 12:56 PM, Martin Sebor wrote:
On 02/22/2017 05:43 PM, Jason Merrill wrote:
>
> On Wed,
OK.
On Tue, Mar 21, 2017 at 11:38 AM, Marek Polacek wrote:
> This patch fixes a bogus maybe-uninitialized warning reported in the PR.
> The issue is that we're not able to fold away useless CLEANUP_POINT_EXPRs,
> as e.g. in
> if (<>)
>// bogus warning
> Here, the cleanup_point was built as
This conversion is ambiguous because of its implicit context; when we
try to give the error, we need to preserve that context; a conversion
in the context of direct-initialization shouldn't get here anyway.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit d7be189d5b2761f10f9c9a8de4c17d3e4d761
On 03/20/2017 03:11 PM, Jason Merrill wrote:
On Thu, Feb 23, 2017 at 6:33 PM, Jason Merrill wrote:
On Thu, Feb 23, 2017 at 12:56 PM, Martin Sebor wrote:
On 02/22/2017 05:43 PM, Jason Merrill wrote:
On Wed, Feb 22, 2017 at 3:44 PM, Martin Sebor wrote:
On 02/22/2017 11:02 AM, Jason Merrill w
Martin, Richard,
I've read up on the thread, but I'm not sure where you guys are with an
actual patch. From what I Richard nailed it in BZ with the comment that
the BB should not be associated with any source line. That's a new
thing, so I think the gcov format needs extending (at least).
g
On Jan 27, 2017, Alexandre Oliva wrote:
> On Oct 19, 2016, Alexandre Oliva wrote:
>> On Sep 23, 2016, Alexandre Oliva wrote:
>>> On Aug 30, 2016, Alexandre Oliva wrote:
Handling non-template friends is kind of easy, [...]
>>> Regstrapped on x86_64-linux-gnu and i686-linux-gnu, I'd failed
On Mär 21 2017, Gerald Pfeifer wrote:
> On Sun, 19 Mar 2017, Andreas Schwab wrote:
>>> @anchor{sparc-x-linux}
>>> @heading sparc-*-linux*
>> The section is now empty. Should it be removed at all?
>
> I considered that, but then figured we do want to keep this as
> an indicator this is a suppor
On Tue, Mar 21, 2017 at 12:57:43PM -0500, Aaron Sawdey wrote:
> Both the fails in 80123 are a situation where vsx_splat_ for V2DI
> generates rtl for a mtvsrdd but constraint wr doesn't prevent
> allocation of r0 for the input. So new constraint wA combines the
> attributes of wr and b -- it is BAS
r244727 and r243310 from the gcc trunk are needed in the gcc-6-branch
to build gcc for the msp430 target with C and C++ support.
Would it be possible for these patches to be backported to the
gcc-6-branch? The gcc-5-branch builds for msp430 with C and C++
support, so isn't this technically a regre
Both the fails in 80123 are a situation where vsx_splat_ for V2DI
generates rtl for a mtvsrdd but constraint wr doesn't prevent
allocation of r0 for the input. So new constraint wA combines the
attributes of wr and b -- it is BASE_REGS if 64-bit and NO_REGS
otherwise.
Currently doing bootstrap/reg
This patch fixes a gcc 6. In gcc 6 we see an IDENTIFIER for functions
(some) member fns that really resolve at parse time. We resolve them to
the same thing at instantiation time, so users don't see a problem.
Current GCC is cleaned up, so we see the actual decls when we need to.
(and if we d
On Tue, Mar 21, 2017 at 08:41:43AM +0100, Jakub Jelinek wrote:
> On Tue, Mar 21, 2017 at 08:38:20AM +1000, Richard Henderson wrote:
> > On 03/21/2017 07:15 AM, Jakub Jelinek wrote:
> > > Not really sure what we should do if both i1 and i2 are frame related,
> > > shall
> > > we check for each of t
On Sun, 19 Mar 2017, Bill Schmidt wrote:
> On Fri, 2017-03-17 at 21:44 +, Joseph Myers wrote:
> > On Fri, 17 Mar 2017, Bill Schmidt wrote:
> >
> > > Joseph, any further comments, or may I commit this?
> >
> > Is there a current patch version somewhere reflecting all comments so far?
> >
> T
On 21 March 2017 at 16:54, Bill Schmidt wrote:
> On Mar 21, 2017, at 10:18 AM, Christophe Lyon
> wrote:
>>
>> Since this was committed (r246319), I've noticed that
>> GCC cross-compiler fails to build glibc for target aarch64-linux-gnu.
>>
>> I'm seeing:
>> In function '_IO_vfscanf_internal':
>>
On Mon, Mar 13, 2017 at 09:23:51AM +0100, marxin wrote:
> gcc/ChangeLog:
>
> 2017-03-13 Martin Liska
>
> PR target/79906
> * config/rs6000/rs6000.c (rs6000_inner_target_options): Show
> error message instead of an ICE.
>
> gcc/testsuite/ChangeLog:
>
> 2017-03-13 Martin Lis
On Mar 21, 2017, at 10:18 AM, Christophe Lyon
wrote:
>
> Since this was committed (r246319), I've noticed that
> GCC cross-compiler fails to build glibc for target aarch64-linux-gnu.
>
> I'm seeing:
> In function '_IO_vfscanf_internal':
> cc1: internal compiler error: in gimplify_modify_expr, a
On 03/14/2017 07:04 PM, David Malcolm wrote:
Successfully bootstrapped®rtested on x86_64-pc-linux-gnu.
OK for trunk? (either now in stage 4, or for next stage1?)
gcc/ChangeLog:
PR translation/80001
* omp-offload.c (oacc_loop_fixed_partitions): Make diagnostics
more amena
On Tue, Mar 21, 2017 at 09:08:49AM -0600, Martin Sebor wrote:
> On 03/20/2017 10:27 PM, Jason Merrill wrote:
> > On Mon, Mar 20, 2017 at 7:58 PM, Martin Sebor wrote:
> > > On 03/20/2017 05:51 PM, Jason Merrill wrote:
> > > > On Mon, Mar 20, 2017 at 7:04 PM, Martin Sebor wrote:
> > > > >
> > > >
On 03/15/2017 02:29 PM, Martin Sebor wrote:
PR 80047 - fixincludes/fixincl.c: PVS-Studio: Improper Release
of Memory Before Removing Last Reference (CWE-401) points out
that the fixincludes program calls getcwd with the first argument
set to NULL, apparently a Glibc extension, to have the functio
On 03/20/2017 12:51 PM, Marek Polacek wrote:
We crash with this invalid testcase because we aren't properly checking what we
are passing down to get_range_info, i.e., we can't pass a pointer. So fixed by
checking the argument first, and calling alloca_type_and_limit if it is of a
wrong type.
Bo
This patch fixes a bogus maybe-uninitialized warning reported in the PR.
The issue is that we're not able to fold away useless CLEANUP_POINT_EXPRs,
as e.g. in
if (<>)
// bogus warning
Here, the cleanup_point was built as <>,
which cp_fold_r reduces to <>, but leaves it as that and
passes it t
On 03/21/2017 09:15 AM, Jakub Jelinek wrote:
On Tue, Mar 21, 2017 at 09:08:49AM -0600, Martin Sebor wrote:
As I understand the schedule, the release is expected sometime
in early April. I leave on April 2 for a week, so I have only
until then. I don't think that leaves enough time. I'd be
unc
Hi
On 21 March 2017 at 09:03, Richard Biener wrote:
> On Mon, Mar 20, 2017 at 8:15 PM, Bill Schmidt
> wrote:
>> Hi,
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79908 shows a case where
>> pass_stdarg ICEs attempting to gimplify a COMPLEX_EXPR with side
>> effects as an lvalue. This occur
On Tue, Mar 21, 2017 at 09:08:49AM -0600, Martin Sebor wrote:
> As I understand the schedule, the release is expected sometime
> in early April. I leave on April 2 for a week, so I have only
> until then. I don't think that leaves enough time. I'd be
> uncomfortable taking on a project this late
Hi!
doloop_condition_get computes cmp in several places, and in one of them
wants to fail if the condition inside of it isn't NE against const0_rtx.
The problem with that is that nothing checked what cmp is yet,
/* Check for (set (pc) (if_then_else (condition)
On 03/20/2017 10:27 PM, Jason Merrill wrote:
On Mon, Mar 20, 2017 at 7:58 PM, Martin Sebor wrote:
On 03/20/2017 05:51 PM, Jason Merrill wrote:
On Mon, Mar 20, 2017 at 7:04 PM, Martin Sebor wrote:
Attached is a minimal patch to avoid an ICE in CHKP upon
encountering one form of an initialize
Hi!
As mentioned in the PR, combiner sometimes artificially splits a parallel
into two instructions, the first one not really in the insn stream, both
with the same uid and PREV_INSN (i1) == 0 and NEXT_INSN (i1) == i2.
In that case, calling reg_used_between_p (x, y, i1) crashes the compiler,
becau
On 03/15/2017 02:29 PM, Bernd Schmidt wrote:
I suggest we apply the following and close the PR as INVALID (not a
bug). Ok?
Agreed. I've already taken care of BZ. So just apply the patch to the
trunk.
Jeff
Hi,
> From: Segher Boessenkool
> On Mon, Mar 20, 2017 at 10:08:25PM +, Moore, Catherine wrote:
> > I'm okay with the workaround for stage 4, but would like to see the pr
> > remain
> open until a proper fix is installed on trunk.
>
> Yeah.
>
Sure, I'll keep it open.
> > Toma, would you be
On 21.03.2017 13:31, Georg-Johann Lay wrote:
On 21.03.2017 13:07, Senthil Kumar Selvaraj wrote:
Hi,
The test assumes 32 bit ints, and expects a constant in the
dump that is only valid for 32 bit ints. This trivial patch
fixes that by explicitly specifying __UINT32_TYPE__ as the type.
Committe
On 21.03.2017 13:07, Senthil Kumar Selvaraj wrote:
Hi,
The test assumes 32 bit ints, and expects a constant in the
dump that is only valid for 32 bit ints. This trivial patch
fixes that by explicitly specifying __UINT32_TYPE__ as the type.
Committed as obvious.
Regards
Senthil
gcc/testsuite/
On Tue, Mar 21, 2017 at 11:55 AM, Martin Liška wrote:
> Hello.
>
> Apart from introduction of gcov-dump.texi file, I also fixed installation of
> gcov-tool.1 man page.
> Patch can also build PDF documentation. I'm attaching the new man page.
Ok.
Thanks,
Richard.
> Thanks,
> Martin
Hi,
The test assumes 32 bit ints, and expects a constant in the
dump that is only valid for 32 bit ints. This trivial patch
fixes that by explicitly specifying __UINT32_TYPE__ as the type.
Committed as obvious.
Regards
Senthil
gcc/testsuite/ChangeLog
2017-03-21 Senthil Kumar Selvaraj
Only now we get a testcase using __builtin_va_arg_pack() and friends
two levels deep which doesn't work since we (reliably) perform inlining
bottom-up.
The following fixes the bug by simply not replacing the builtins
with garbage in case the caller wasn't passing args but an argument
pack itself.
On 03/17/2017 01:17 PM, Rainer Orth wrote:
> Jakub Jelinek writes:
>
>> 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 o
> > From: Matthew Fortune
> >
> > I think the skip is OK here. I'd like to get Catherine's opinion on
> > this though too. I don't think we should change the definition of __PIC__
> > for -fPIC on MIPS as multi-got solves 'most' issues. If we start trying to
> > figure out what __PIC__ should mean
Hello.
Currently running tests and as the patch is pre-approved by Richi, I'm going to
install
it afterwards.
Martin
>From 78af53942b50d6bb47959d263336072f1d7ff6ed Mon Sep 17 00:00:00 2001
From: marxin
Date: Tue, 21 Mar 2017 11:57:27 +0100
Subject: [PATCH] Fix another profiledbootstrap warning
Hello.
Apart from introduction of gcov-dump.texi file, I also fixed installation of
gcov-tool.1 man page.
Patch can also build PDF documentation. I'm attaching the new man page.
Thanks,
Martin
>From f86849be31029555efee8f5f7b8157ae7d468519 Mon Sep 17 00:00:00 2001
From: marxin
Date: Tue, 21 Mar
On 20/03/17 17:27, Andreas Schwab wrote:
> On Mär 20 2017, "Richard Earnshaw (lists)" wrote:
>
>> I don't have access to an ILP32 run-time environment, so I'm not sure
>> how I'll be able to check this out. There are some pointer checks in
>> the code so it's possible something is going awry. C
On Tue, Mar 21, 2017 at 12:05 AM, Brad Spengler wrote:
> Hi,
>
> As requested in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80094
> i'm attaching a patch for the issue described.
>
> Specifically:
> when the plugin_name_args_tab hash table has its 11th entry inserted, it
> trigers a hash table r
Hi Martin,
On 13/03/17 08:25, marxin wrote:
gcc/testsuite/ChangeLog:
2017-03-13 Martin Liska
* g++.dg/ext/mv8.C: Add aarch64* targets.
gcc/ChangeLog:
2017-03-13 Martin Liska
* config/aarch64/aarch64.c (aarch64_process_target_attr):
Show error message instead
PING^ + adding aarch64 maintainer.
Thanks,
Martin
PING^ + adding power maintainer.
Thanks,
Martin
On Tue, 21 Mar 2017, Jakub Jelinek wrote:
> On Tue, Mar 21, 2017 at 09:12:51AM +0100, Richard Biener wrote:
> > > libtsan atomics aren't throwing, so if we transform atomics which
> > > are throwing with -fnon-call-exceptions, we need to clean up EH stuff.
> > >
> > > Bootstrapped/regtested on x8
On Mon, 20 Mar 2017, Jakub Jelinek wrote:
> On Fri, Mar 17, 2017 at 02:42:27PM +0100, Richard Biener wrote:
> > 2017-03-17 Richard Biener
> >
> > PR tree-optimization/80032
> > * gimplify.c (gimple_push_cleanup): Add force_uncond parameter,
> > if set force the cleanup to happen un
On Tue, Mar 21, 2017 at 09:12:51AM +0100, Richard Biener wrote:
> > libtsan atomics aren't throwing, so if we transform atomics which
> > are throwing with -fnon-call-exceptions, we need to clean up EH stuff.
> >
> > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> Huh, bu
On Mon, 20 Mar 2017, Jakub Jelinek wrote:
> Hi!
>
> libtsan atomics aren't throwing, so if we transform atomics which
> are throwing with -fnon-call-exceptions, we need to clean up EH stuff.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Huh, but this means with TSAN w
On Mon, 20 Mar 2017, Jakub Jelinek wrote:
> Hi!
>
> libtsan only handles the standard memory model values, so I've added
> just in case some new unknown memory model is used bail outs (keeping
> the __atomic_* builtins instead of transforming them to __tsan_atomic*).
> Except that at -O0 (or if u
On Mon, 20 Mar 2017, Jakub Jelinek wrote:
> Hi!
>
> divisor is unsigned int parameter, if it is 0x8000, we invoke UB.
> val is wide_int, so (int) -divisor achieves the same result without UB.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Ok.
Thanks,
Richard.
> 2
On Mon, Mar 20, 2017 at 8:15 PM, Bill Schmidt
wrote:
> Hi,
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79908 shows a case where
> pass_stdarg ICEs attempting to gimplify a COMPLEX_EXPR with side
> effects as an lvalue. This occurs when the LHS of a VA_ARG has been
> cast away. This patch, c
On Tue, Mar 21, 2017 at 08:38:20AM +1000, Richard Henderson wrote:
> On 03/21/2017 07:15 AM, Jakub Jelinek wrote:
> > Not really sure what we should do if both i1 and i2 are frame related, shall
> > we check for each of the CFA reg notes if they are available and equal?
> > Or punt if either of the
On 21 March 2017 at 09:17, Jakub Jelinek wrote:
> I've tested in the mean time the following patch with both gcc from yesterday
> where
> pr35878_3.C fails as expected, and with the latest cc1plus where
> it succeeds both with -m32 and -m64. Scanning the tree dump has the
> advantage that you te
On Tue, Mar 21, 2017 at 09:03:54AM +0200, Ville Voutilainen wrote:
> On 21 March 2017 at 08:55, Ville Voutilainen
> wrote:
> >>> +// { dg-options "-O2 --std=gnu++11" }
> >>
> >> -O2 -std=gnu++11 is enough, no need for double dash --std=gnu++11.
> >>
> >>> +// { dg-do compile }
> >>> +// { dg-final
On 21 March 2017 at 08:55, Ville Voutilainen
wrote:
>>> +// { dg-options "-O2 --std=gnu++11" }
>>
>> -O2 -std=gnu++11 is enough, no need for double dash --std=gnu++11.
>>
>>> +// { dg-do compile }
>>> +// { dg-final { scan-assembler "test.*%rdi, %rdi" { target i?86-*-*
>>> x86_64-*-* } } }
>>
>>
66 matches
Mail list logo
