This is a final candidate patch to add code-hoisting to GIMPLE.
I've already committed several patches fixing fallout and the following
one adds -fno-code-hoisting (I renamed the option) to a few testcases.
I filed PRs for the cases code-hoisting exposes missed optimization
opportunities in passe
On Mon, 4 Jul 2016, Steven Bosscher wrote:
> On Mon, Jul 4, 2016 at 1:26 PM, Richard Biener wrote:
> >
> > The following patch is Stevens code-hoisting based on PRE forward-ported
> > and fixed for bootstrap plus the case of hoisting code across loops
> > which we generally do not want (expression
> I removed the empty directories
>
>gcc/common/config/mep
>gcc/config/mep
>libgcc/config/mep
https://gcc.gnu.org/backends.html needs to be updated accordingly.
--
Eric Botcazou
On Thu, 7 Jul 2016, Bernd Edlinger wrote:
> Hi,
>
> this patch re-factors the TYPE_ALIGN_OK into a new TYPE_LANG_FLAG,
> and removes one of the 9 parameters of get_inner_reference. It therefore
> simplifies the middle end slightly.
>
> It is quite a while ago, when I last proposed a similar pat
On Fri, 1 Jul 2016, Alexander Monakov wrote:
> On Thu, 23 Jun 2016, Alexander Monakov wrote:
> > Hi,
> >
> > I've discovered that this assert in my patch was too restrictive:
> >
> > + if (DECL_HAS_VALUE_EXPR_P (pv->decl))
> > + {
> > + gcc_checking_assert (lookup_attribute ("omp decla
> The discussion last time ended with a mail from you that TYPE_ALIGN_OK
> is "somehow" relevant in the Ada FE, but I didn't see any feedback
> from Eric nor results from the "extended" testing we wanted to perform.
TYPE_ALIGN_OK is definitely relevant in the Ada FE, the question being whether
it
> > + && (register_operand (operands[1], SFmode)
> > + || register_operand (operands[2], SFmode))"
This condition is necessary for reload cases.
> And, with this patch applied, I get a build error:
>
> In file included from ./tm.h:43:0,
> from /path/to/gcc/gcc/ba
On Thu, Jul 7, 2016 at 4:35 PM, Alan Hayward wrote:
> Ping.
Ok.
Richard.
>
> From: Alan Hayward
> To: "gcc-patches at gcc dot gnu dot org" org>
> Date: Wed, 29 Jun 2016 08:49:34 +0100
> Subject: [PATCH] PR 71667 - Handle live operations with DEBUG uses
> Authentication-results: sourceware.org
On Fri, 8 Jul 2016, Eric Botcazou wrote:
> > The discussion last time ended with a mail from you that TYPE_ALIGN_OK
> > is "somehow" relevant in the Ada FE, but I didn't see any feedback
> > from Eric nor results from the "extended" testing we wanted to perform.
>
> TYPE_ALIGN_OK is definitely re
On 07/07/2016 04:40 PM, Jan Hubicka wrote:
>>
>> Why is the behavior only undefined for step 1 if the last iteration IV
>> increment overflows?
>> Doesn't this apply to all step values?
>
> This is what Fortran standard says:
>
> The iteration count is established and is the value of the expres
On 07/07/2016 05:53 PM, Tobias Burnus wrote:
> On Thu, Jul 07, 2016 at 02:13:12PM +0200, Tobias Burnus wrote:
>> marxin wrote:
>>> gcc/fortran/ChangeLog:
>>>
>>> 2016-07-01 Martin Liska
>>> * lang.opt (Wundefined-do-loop): New option.
>>>* resolve.c (gfc_resolve_iterator): Warn for W
On Fri, Jul 08, 2016 at 10:33:45AM +0200, Martin Liška wrote:
> On 07/07/2016 04:40 PM, Jan Hubicka wrote:
> >>
> >> Why is the behavior only undefined for step 1 if the last iteration IV
> >> increment overflows?
> >> Doesn't this apply to all step values?
> >
> > This is what Fortran standard sa
PING^1
On 06/23/2016 12:56 PM, Martin Liška wrote:
> Hello.
>
> Following patch changes minimum of ira-max-loops-num to 1.
> Having the minimum equal to zero does not make much sense.
>
> Ready after it finishes reg&bootstrap on x86_64-linux?
>
> Thanks,
> Martin
>
On Fri, Jul 08, 2016 at 12:37:55PM +0930, Alan Modra wrote:
> The regression tests passed. I've been looking at differences in
> gcc/*.o and find many cases like the following.
>
> orig/combine.o
> 1508: 01 00 3f 2c cmpdi r31,1
> 150c: ff ff ff 3b addir31,r31,-1
>
> On Fri, Jul 08, 2016 at 10:33:45AM +0200, Martin Liška wrote:
> > On 07/07/2016 04:40 PM, Jan Hubicka wrote:
> > >>
> > >> Why is the behavior only undefined for step 1 if the last iteration IV
> > >> increment overflows?
> > >> Doesn't this apply to all step values?
> > >
> > > This is what For
On Fri, Jul 08, 2016 at 11:03:35AM +0200, Jan Hubicka wrote:
> > On Fri, Jul 08, 2016 at 10:33:45AM +0200, Martin Liška wrote:
> > > On 07/07/2016 04:40 PM, Jan Hubicka wrote:
> > > >>
> > > >> Why is the behavior only undefined for step 1 if the last iteration IV
> > > >> increment overflows?
> >
> This is what Fortran standard says:
>
> The iteration count is established and is the value of the expression
> (m2-m1+m3)/m3 unless that value is negative,
> in which case the iteration count is 0.
>
> My reading of this is that the do statement is undefined when
On Fri, Jul 08, 2016 at 01:28:05AM +0930, Alan Modra wrote:
> BTW, both pr70098 and pr71763 are triggered by combine, not
> loop-doloop as I was thinking earlier. See rtl dumps for the
> testcases. I doubt the "optimization" done by combine here is worth
> keeping, since loop-doloop.c ought to al
Hi!
I have created new branch unified-autovect based on ToT.
Please find attached the patch adding information about new branch
"unified-autovect" in the documentation.
Is it ok to commit?
- Thanks and regards,
Sameera D.
unified-autovec-doc.patch
Description: unified-autovec-doc.patch
Hi Richard,
For the following test-case:
int f(int x, int y)
{
int ret;
if (x == y)
ret = x ^ y;
else
ret = 1;
return ret;
}
I was wondering if x ^ y should be folded to 0 since
it's guarded by condition x == y ?
optimized dump shows:
f (int x, int y)
{
int iftmp.0_1;
Hi James,
Please find the patch after taking care of your comments.
> Did you see those patches, and did you consider whether there would be a
> benefit to doing the same for Vulcan?
In our simulation environment, we did not observe any performance gain
for specfp2006.
However, we did it to keep
On 06/14/2016 11:24 PM, Segher Boessenkool wrote:
On Wed, Jun 08, 2016 at 06:43:23PM +0200, Bernd Schmidt wrote:
On 06/08/2016 05:16 PM, Segher Boessenkool wrote:
There is no standard naming for this as far as I know. I'll gladly
use a better name anyone comes up with.
Maybe just subpart?
* Claudiu Zissulescu [2016-07-08 08:18:00
+]:
> > > + && (register_operand (operands[1], SFmode)
> > > + || register_operand (operands[2], SFmode))"
>
> This condition is necessary for reload cases.
>
> > And, with this patch applied, I get a build error:
> >
> > In file inclu
>
>../src/configure --target=arc-elf32 --enable-languages=c --with-cpu=arc700
>make all-gcc
>
My bad, my build environment was polluted, I can see the error as well. I need
to upstream another patch that fixes the named problem.
Best,
Claudiu
On Fri, 8 Jul 2016, Prathamesh Kulkarni wrote:
> Hi Richard,
> For the following test-case:
>
> int f(int x, int y)
> {
>int ret;
>
>if (x == y)
> ret = x ^ y;
>else
> ret = 1;
>
>return ret;
> }
>
> I was wondering if x ^ y should be folded to 0 since
> it's guarded
This patch adds support for a ARC EM version called QuarkSE.
This patch needs to be consider together with this previous patch:
https://gcc.gnu.org/ml/gcc-patches/2016-06/msg02044.html
Thanks,
Claudiu
gcc/
2016-05-25 Claudiu Zissulescu
* config/arc/arc-arches.def: Add FPX quarkse ins
> > gcc/
> > 2016-05-09 Claudiu Zissulescu
> >
> > * config/arc/arc.c (arc_process_double_reg_moves): Change.
> > * config/arc/arc.md (movsi_insn): Disable unsupported move
> > instructions for ARCv2 cores.
> > (movdi): Use prepare_move_operands.
> > (movsf, movdf): Use move_
On Fri, 8 Jul 2016, Richard Biener wrote:
> On Fri, 8 Jul 2016, Prathamesh Kulkarni wrote:
>
> > Hi Richard,
> > For the following test-case:
> >
> > int f(int x, int y)
> > {
> >int ret;
> >
> >if (x == y)
> > ret = x ^ y;
> >else
> > ret = 1;
> >
> >return ret;
> >
Don't use CPU macros, use CPU feature macros.
libgcc/
2016-05-26 Claudiu Zissulescu
* config/arc/lib1funcs.S (__mulsi3): Use feature defines instead
of checking for cpus.
(__umulsidi3, __umulsi3_highpart, __udivmodsi4, __divsi3)
(__modsi3, __clzsi2): Likewise.
-
This is a set of two libgcc patches that is adding support for QuarkSE
processor as well as it is changing the guarding of the ARC libgcc
support routines from cpu macros to feature macros.
Ok to apply?
Claudiu
Claudiu Zissulescu (2):
[ARC] [libgcc] Add support for QuarkSE processor.
[ARC] [l
libgcc/
2016-05-26 Claudiu Zissulescu
* config/arc/dp-hack.h (ARC_OPTFPE): Define.
(__ARC_NORM__): Use instead ARC_OPTFPE.
* config/arc/fp-hack.h: Likewise.
* config/arc/lib1funcs.S (ARC_OPTFPE): Define.
(__ARC_MPY__): Use it insetead of __ARC700__ and __
[New thread now that I actually have a tested patch :)].
I think detecting potentially problematic uses of alloca would
be useful, especially when done in an intelligent way like in
your patch (as opposed to simply diagnosing every call to
the function regardless of the value of its argument).
On 06/23/2016 12:56 PM, Martin Liška wrote:
Following patch changes minimum of ira-max-loops-num to 1.
Having the minimum equal to zero does not make much sense.
Ready after it finishes reg&bootstrap on x86_64-linux?
Hmm, why wouldn't a number of zero make sense if you want try to have
all lo
On 07/08/2016 01:52 PM, Bernd Schmidt wrote:
int maxidx = MIN (IRA_MAX_LOOPS_NUM, n);
for (i = 0; i < maxidx; i++)
{
Gah, that's not right, that'll swap the numbers of kept/removed loops.
I think the right answer is simply
for (i = 0; i < n - IRA_MAX_LOOPS_NUM; i++)
Bernd
On Fri, Jul 08, 2016 at 12:42:34PM +0200, Bernd Schmidt wrote:
> On 06/14/2016 11:24 PM, Segher Boessenkool wrote:
> >On Wed, Jun 08, 2016 at 06:43:23PM +0200, Bernd Schmidt wrote:
> >>On 06/08/2016 05:16 PM, Segher Boessenkool wrote:
> >>>There is no standard naming for this as far as I know. I'l
Hi Richard,
> This is a final candidate patch to add code-hoisting to GIMPLE.
>
> I've already committed several patches fixing fallout and the following
> one adds -fno-code-hoisting (I renamed the option) to a few testcases.
> I filed PRs for the cases code-hoisting exposes missed optimization
>
On Fri, 8 Jul 2016, Rainer Orth wrote:
> Hi Richard,
>
> > This is a final candidate patch to add code-hoisting to GIMPLE.
> >
> > I've already committed several patches fixing fallout and the following
> > one adds -fno-code-hoisting (I renamed the option) to a few testcases.
> > I filed PRs for
> On Jul 8, 2016, at 12:14 AM, Segher Boessenkool
> wrote:
>
> On Thu, Jul 07, 2016 at 03:40:28PM -0500, Bill Schmidt wrote:
>>> PR71297 reports that we ICE when __builtin_vec_ld or __builtin_vec_st is
>>> provided with an incorrect number of arguments. This patch fixes it by
>>> bypassing spe
Andi Kleen writes:
Ping^2!
> Andi Kleen writes:
>
> Ping!
>
>> This fixes some of the problems with profile test cases running with autofdo
>> There are still remaining failures that need to be addressed, but this is the
>> low hanging fruit.
>>
>> -Andi
>>
>>
--
a...@linux.intel.com -- Speak
On Thu, Jul 7, 2016 at 9:18 PM, Jason Merrill wrote:
> On Tue, Jun 28, 2016 at 10:00 AM, Richard Biener
> wrote:
>> On Thu, Jun 16, 2016 at 6:15 PM, Jakub Jelinek wrote:
>>> On Thu, Jun 16, 2016 at 11:28:48AM -0400, Jason Merrill wrote:
gimple_predicate
rhs_predicate_for (tree lhs)
>
Hi Richard,
>> I've just bootstrapped the patch on sparc-sun-solaris2.12, which
>> uncovered a couple of testsuite failures:
>>
>> +FAIL: gcc.dg/tree-ssa/split-path-5.c scan-tree-dump-times split-paths
>> "Duplicat
>> ing join block" 2
>> +FAIL: gcc.dg/tree-ssa/split-path-5.c scan-tree-dump-times
Hi.
This is my second attempt of the patch where I generate all tests on fly.
Firstly, params-options.h is used to generate a list of options in form of:
"predictable-branch-outcome"=2,0,50
"inline-min-speedup"=10,0,0
"max-inline-insns-single"=400,0,0
...
The list is then loaded in params.ext wh
On 07/08/2016 01:59 PM, Bernd Schmidt wrote:
>
> Gah, that's not right, that'll swap the numbers of kept/removed loops.
>
> I think the right answer is simply
> for (i = 0; i < n - IRA_MAX_LOOPS_NUM; i++)
>
>
> Bernd
Thank you for the help, I've been testing the suggested change.
Martin
On Fri, 2016-07-08 at 07:11 -0500, Segher Boessenkool wrote:
> On Fri, Jul 08, 2016 at 12:42:34PM +0200, Bernd Schmidt wrote:
> > On 06/14/2016 11:24 PM, Segher Boessenkool wrote:
> > > On Wed, Jun 08, 2016 at 06:43:23PM +0200, Bernd Schmidt wrote:
> > > > On 06/08/2016 05:16 PM, Segher Boessenkool
If you configure either GCC 6.x or trunk with the --with-cpu=power9 option, it
will enable __float128 support, since power9 has the ISA 3.0 hardware IEEE
128-bit floating point instructions. However, the libquadmath and libstdc++
libraries have not been fixed to enable the PowerPC support, and the
This backports a doc change to the gcc-5-branch. The patch doesn't
include the updated issues lists, since they're just copied from
upstream and are already on trunk and gcc-6-branch.
The list of implemented DRs is slightly different to the one on trunk,
because not all of them are fixed on gcc-5
On Thu, Jul 07, 2016 at 03:18:13PM -0400, Jason Merrill wrote:
> How about this? I also have a patch to handle assignment order
> entirely in the front end, but my impression has been that you wanted
> to make this change for other reasons as well.
So what exactly is supposed to be the evaluation
On Fri, Jul 08, 2016 at 09:16:03AM -0400, David Malcolm wrote:
> As far as I understand the idea, there are a number of target-specific
> things that are to be done during a function call, and the optimization
> tries to detect which of optimize each of these separately.
>
> Some synonyms and near
Hi Richard,
Thanks for your help - your patch looks much better.
Here is new patch in which additional argument was added to determine
source loop of reference.
Bootstrap and regression testing did not show any new failures.
Is it OK for trunk?
ChangeLog:
2016-07-08 Yuri Rumyantsev
PR tree-o
On Thu, Jul 07, 2016 at 05:13:56PM +0100, Jiong Wang wrote:
> Several data-processing instructions are agnostic to the type of their
> operands. This patch add the mapping between them and those bit- and
> lane-manipulation instructions.
>
> No ARMv8.2-A FP16 extension hardware support is required
On Fri, Jul 08, 2016 at 09:31:33AM -0400, Michael Meissner wrote:
> * gcc.target/powerpc/p9-lxvx-stxvx-3.c: Add -mfloat128 option.
Is that the only testcase that needs updating?
> --- gcc/config/rs6000/rs6000-cpus.def (revision 238127)
> +++ gcc/config/rs6000/rs6000-cpus.def (working copy)
On Fri, Jul 08, 2016 at 10:17:14AM -0400, Michael Meissner wrote:
> > >/* IEEE 128-bit floating point hardware instructions imply enabling
> > > __float128. */
> > >if (TARGET_FLOAT128_HW
> > > - && (rs6000_isa_flags & (OPTION_MASK_P9_VECTOR
> > > - | OPTIO
On 07/07/2016 04:15 PM, Richard Biener wrote:
> I think it's fine though the inliners initializer handling looks
> incredibly fragile to me ;)
>
> Richard.
OK, installed in trunk. May I install the patch to all active branches?
Reg&bootstrap works for all of them.
On Fri, Jul 08, 2016 at 09:13:50AM -0500, Segher Boessenkool wrote:
> On Fri, Jul 08, 2016 at 09:31:33AM -0400, Michael Meissner wrote:
> > * gcc.target/powerpc/p9-lxvx-stxvx-3.c: Add -mfloat128 option.
>
> Is that the only testcase that needs updating?
>
> > --- gcc/config/rs6000/rs6000-cpus
Hello
Following patch fixes fallout caused by the patch set:
https://gcc.gnu.org/ml/gcc-regression/2016-07/msg00097.html
Ready after it finished regression tests?
Thanks,
Martin
>From c5dd7ad62f795cce560c7f1bb8767b7ed9298d8a Mon Sep 17 00:00:00 2001
From: marxin
Date: Fri, 8 Jul 2016 15:51:54 +0
On 07/08/2016 02:54 PM, Martin Liška wrote:
> On 07/08/2016 01:59 PM, Bernd Schmidt wrote:
>>
>> Gah, that's not right, that'll swap the numbers of kept/removed loops.
>>
>> I think the right answer is simply
>> for (i = 0; i < n - IRA_MAX_LOOPS_NUM; i++)
>>
>>
>> Bernd
>
> Thank you for the hel
Not that getting the terminology right isn't important, but it would be
nice if Segher could get a review for the rest of the content, too. :)
Bill
> On Jul 8, 2016, at 8:45 AM, Segher Boessenkool
> wrote:
>
> On Fri, Jul 08, 2016 at 09:16:03AM -0400, David Malcolm wrote:
>> As far as I unders
On Fri, Jul 08, 2016 at 12:43:35AM -0500, Segher Boessenkool wrote:
> On Thu, Jul 07, 2016 at 03:42:55PM -0500, Pat Haugen wrote:
> > The following patch corrects the constraint so that we only generate
> > 'stxsiwx' on Power8 or later hardware. Ok for trunk after successful
> > bootstrap/regtest
Ping.
I believe I need review of the selftest.h change; the rest I think I
can self-approve, if need be.
https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01340.html
On Fri, 2016-06-17 at 17:41 -0400, David Malcolm wrote:
> This patch adds explicit testing of lexing a source file,
> generalizing
Hi,
While investigating the root cause a testsuite regression for the
ARM/embedded-5-branch GCC in gcc.dg/vect/slp-perm-5.c, we found that the bug
seems to also affect trunk. The bug manifests itself as an ICE in cselib due to
a parallel insn with two SET to the same register. When processing t
I've had a request to backport the allocator propagation support for
std::__cxx11::string to the gcc-5-branch. That was done for 6cc-6 by
this patch: https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00784.html
The patch also fixed the fact that moving strings was not noexcept.
Does anyone see any p
Fixed in trunk with r238168, test case included. Thanks!
Bill
> On Jul 8, 2016, at 7:29 AM, Bill Schmidt wrote:
>
>>
>> On Jul 8, 2016, at 12:14 AM, Segher Boessenkool
>> wrote:
>>
>> On Thu, Jul 07, 2016 at 03:40:28PM -0500, Bill Schmidt wrote:
PR71297 reports that we ICE when __buil
On 07/07/16 10:34, James Greenhalgh wrote:
To make backporting easier, could you please write a very simple
standalone test that exposes this bug, and submit this patch with just
that simple test? I've already OKed the functional part of this patch, and
I'm happy to pre-approve a simple testcase
On Jul 8, 2016, at 8:07 AM, Thomas Preudhomme
wrote:
> While investigating the root cause a testsuite regression for the
> ARM/embedded-5-branch GCC in gcc.dg/vect/slp-perm-5.c, we found that the bug
> seems to also affect trunk.
Hum... If in 6.x, and safe to back port to 6, a back port would
On 06/30/2016 10:47 AM, Jakub Jelinek wrote:
> The Fortran parser apparently relies in functions that have still undecided
> kind of the result that ST_GET_FCN_CHARACTERISTICS artificial statement is
> returned before any executable statements in the function.
> In normal statements that is ensure
On Fri, Jul 08, 2016 at 09:13:50AM -0700, Cesar Philippidis wrote:
> On 06/30/2016 10:47 AM, Jakub Jelinek wrote:
>
> > The Fortran parser apparently relies in functions that have still undecided
> > kind of the result that ST_GET_FCN_CHARACTERISTICS artificial statement is
> > returned before any
On 07/08/2016 09:18 AM, Jakub Jelinek wrote:
> On Fri, Jul 08, 2016 at 09:13:50AM -0700, Cesar Philippidis wrote:
>> On 06/30/2016 10:47 AM, Jakub Jelinek wrote:
>>
>>> The Fortran parser apparently relies in functions that have still undecided
>>> kind of the result that ST_GET_FCN_CHARACTERISTICS
On 06/07/16 21:46 +0200, François Dumont wrote:
Don't you plan to add it to the testsuite ?
Done with the attached aptch.
On my side I rebase part of my patch to reorganize a little bit code.
I reintroduced _M_realloc_insert which isolates the code of
_M_insert_aux used when we need to reall
On Fri, Jul 08, 2016 at 09:19:01AM -0700, Cesar Philippidis wrote:
> 2016-07-08 Cesar Philippidis
>
> gcc/fortran/
> * parse.c (matcha): Define.
> (decode_oacc_directive): Add spec_only local var and set it. Use
> matcha to parse acc data, enter data, exit data, host_da
On 07/08/2016 09:31 AM, Jakub Jelinek wrote:
> On Fri, Jul 08, 2016 at 09:19:01AM -0700, Cesar Philippidis wrote:
>> 2016-07-08 Cesar Philippidis
>>
>> gcc/fortran/
>> * parse.c (matcha): Define.
>> (decode_oacc_directive): Add spec_only local var and set it. Use
>> matcha t
On Fri, Jul 08, 2016 at 09:58:57AM -0700, Cesar Philippidis wrote:
> >> +#define matcha(keyword, subr, st) \
> >> +do { \
> >> + if (spec_only && gfc_match (keyword) == MATCH_YES) \
> >> + goto do_spec_only;
On July 8, 2016 4:23:31 PM GMT+02:00, "Martin Liška" wrote:
>On 07/07/2016 04:15 PM, Richard Biener wrote:
>> I think it's fine though the inliners initializer handling looks
>> incredibly fragile to me ;)
>>
>> Richard.
>
>OK, installed in trunk. May I install the patch to all active branches?
>
On 07/08/2016 01:30 AM, Richard Biener wrote:
On Mon, 4 Jul 2016, Steven Bosscher wrote:
On Mon, Jul 4, 2016 at 1:26 PM, Richard Biener wrote:
The following patch is Stevens code-hoisting based on PRE forward-ported
and fixed for bootstrap plus the case of hoisting code across loops
which we
On 07/08/2016 10:25 AM, Jakub Jelinek wrote:
> On Fri, Jul 08, 2016 at 09:58:57AM -0700, Cesar Philippidis wrote:
+#define matcha(keyword, subr, st) \
+do { \
+ if (spec_only && gfc_match (keyword) == M
On Fri, Jul 08, 2016 at 11:26:12AM -0700, Cesar Philippidis wrote:
> There's probably no advantage. I just didn't want to change something
> that wasn't broken. But from a consistency standpoint, I agree that all
> of the directives except for routine and declare could use matcha. This
> patch make
On 07/06/2016 11:22 AM, Bernd Schmidt wrote:
On 07/05/2016 12:41 PM, Richard Biener wrote:
On Fri, Jul 1, 2016 at 3:10 PM, Manish Goregaokar
wrote:
Added a test:
Ok if this passed bootstrap/regtest.
+ return flag_delete_null_pointer_checks
+&& (tree_expr_nonzero_warnv_p (
This patch adds a new phony target to gcc/Makefile.in to make it easy
to run the selftests under valgrind, via "make selftest-valgrind".
This phony target isn't a dependency of anything; it's purely for
convenience (it takes about 4-5 seconds on my box).
Doing so uncovered a few leaks in the selft
Yes, that’s correct. It has been moved before the libiberty library in the list
now. Bootstrapped the system with the changes as well.
PFA the updated patch
--
Thanks,
Ayush Goel
On 8 July 2016 at 2:29:04 AM, Manuel López-Ibáñez (lopeziba...@gmail.com) wrote:
> On 7 July 2016 at 13:48, ayus
On Fri, Jul 8, 2016 at 9:42 AM, Jakub Jelinek wrote:
> On Thu, Jul 07, 2016 at 03:18:13PM -0400, Jason Merrill wrote:
>> How about this? I also have a patch to handle assignment order
>> entirely in the front end, but my impression has been that you wanted
>> to make this change for other reasons
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71621
The patch was successfully bootstrapped and tested on x86/x86-64.
Committed as rev. 238178
Index: ChangeLog
===
--- ChangeLog (revision 238175)
+++ Chan
This patch implements precise tracking of source locations for the
individual chars within string literals, so that we can e.g. underline
specific ranges in -Wformat diagnostics.
It should also enable fixing PR inline-asm/57950 ("wrong line numbers
in error messages for inline assembler statements
While working on another patch, I noticed that the dummy object used
for a generic lambda conversion operator was mistakenly created by
casting nullptr to the lambda closure type, rather than a pointer to
that type. Fixed thus.
commit 972a2e5d623b46b32f9de4633b60d5ecf95fc5df
Author: Jason Merrill
For a while I've been meaning to rename
lvalue_or_rvalue_with_address_p to glvalue_p; we've had that term for
a long time.
Then while I was at it, I decided to fix the name "lvalue_p", which
for a long time has really meant "glvalue or class prvalue". I've
invented the name "obvalue" for this cat
On Jun 27, 2016 12:53 PM, "Richard Biener" wrote:
>
> On Thu, Jun 23, 2016 at 9:39 PM, Jason Merrill wrote:
> > My earlier patch for 50800 fixed the ICE by consistently stripping
> > non-mangled attributes from template arguments, and mangling those that
> > affect type identity. At the C++ meet
2016-07-08 Steven G. Kargl
PR fortran/68426
* simplify (gfc_simplify_spread): Adjust locus.
Index: simplify.c
===
--- simplify.c (revision 238178)
+++ simplify.c (working copy)
@@ -6183,8 +6183,7 @@ gfc_simplify
On Wed, Jun 22, 2016 at 2:25 AM, Andrew Sutton
wrote:
>> > I've run into some trouble building cmcstl2: declarator requirements
>> > on a function can lead to constraints that tsubst_constraint doesn't
>> > handle. What was your theory of only handling a few _CONSTR codes
>> > there? This is blo
The FT32 binutils use a bias to distinguish between RAM and flash
addresses.
This fix adds an ASM_OUTPUT_SYMBOL_REF() that unbiases references to
RAM symbols.
Only references to RAM objects have the bias applied. Flash objects
(that is, objects in ADDR SPACE 1) are not biased, so for these no bia
Yep, there are some test issues -- I don't have time right now but
plan to investigate further later.
-Manish
On Sat, Jul 9, 2016 at 12:06 AM, Jeff Law wrote:
> On 07/06/2016 11:22 AM, Bernd Schmidt wrote:
>>
>> On 07/05/2016 12:41 PM, Richard Biener wrote:
>>>
>>> On Fri, Jul 1, 2016 at 3:10 PM
On Fri, Jul 8, 2016 at 12:46 PM, David Malcolm wrote:
> This patch adds a new phony target to gcc/Makefile.in to make it easy
> to run the selftests under valgrind, via "make selftest-valgrind".
> This phony target isn't a dependency of anything; it's purely for
> convenience (it takes about 4-5 s
On 2016.06.28 at 11:21 -0700, Gary Funck wrote:
> On 06/20/16 04:55:16, H.J. Lu wrote:
> > TImode register referenced in debug insn can be converted to V1TImode
> > by scalar to vector optimization. We need to convert a debug insn if
> > it has a variable in a TImode register.
>
> We have a situa
90 matches
Mail list logo
