I forgot to update this after adding the late DCE pass. We now have
zero calls to free in .optimized.
Tested on x86_64-unknown-linux-gnu.
Richard.
2016-02-11 Richard Biener
* g++.dg/tree-ssa/pr61034.C: Adjust.
Index: gcc/testsuite/g++.dg/tree-ssa/pr61034.C
On Wed, Feb 10, 2016 at 5:25 PM, Bernd Schmidt wrote:
> On 02/09/2016 09:44 PM, David Malcolm wrote:
>>
>> This is a bug in a new feature, so it isn't a regression as such, but
>> it's fairly visible, and I believe the fix is relatively low-risk
>> (error-handling of typos of command-line options)
On Wed, 10 Feb 2016, Jakub Jelinek wrote:
> Hi!
>
> During profiledbootstrap on ppc64 I've noticed a -Wmaybe-uninitialized
> warning in vect_schedule_slp_instance, when built with -fprofile-generate.
> While it is clearly a false positive, IMHO it is completely unnecessary
> to use here two varia
On Wed, 10 Feb 2016, Jakub Jelinek wrote:
> Hi!
>
> Markus has pointed out to a reduced testcase which still ICEs even with the
> PR69241 fix. In that case the function with TREE_ADDRESSABLE return type
> does not return at all (and -Wreturn-type properly diagnoses it).
> For that case the follo
Hi,
The attached patch fixes PR 69713. For details please see the comments
in the PR.
Tested on trunk and sh-elf with
make -k check RUNTESTFLAGS="--target_board=sh-sim\{-m2/-ml,-m2/-mb,
-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"
Committed to trunk as r233324, 5 branch as r233326 and 4.9 branc
This is PR68973 part 1, the fix for the regression of g++.dg/pr67211.C
on powerpc64-linux -mcpu=power7, which turns out to be a reload
problem.
Due to uses elsewhere in vsx instructions, reload chooses to put
psuedo 185 in fr31, which can't be used as a base register in the
following:
(se
Hi!
I've committed following backports of my trunk commits to gcc-4_9-branch
after bootstrapping/regtesting them on x86_64-linux and i686-linux.
Jakub
2016-02-11 Jakub Jelinek
Backported from mainline
2015-11-19 Jakub Jelinek
PR preprocessor/60736
*
Hi!
There are two issues here: 1. "avoid offloading" mechanism, and 2. "avoid
offloading" policy.
On Wed, 10 Feb 2016 21:07:29 +0100, Bernd Schmidt wrote:
> On 02/10/2016 06:37 PM, Thomas Schwinge wrote:
> > On Wed, 10 Feb 2016 17:37:30 +0100, Bernd Schmidt
> > wrote:
> >> IIUC it's also disab
On 9 February 2016 at 13:42, Richard Biener wrote:
>
> It turns out if-conversions poor job on
>
> if (a)
>x[i] = ...;
> else
>x[i] = ...;
>
> results in bogus uninit warnings of x[i] for a variety of reasons.
> First of all forwprop (aka match.pd simplification) doesn't fixup
> all of i
On Thu, 11 Feb 2016, Christophe Lyon wrote:
> On 9 February 2016 at 13:42, Richard Biener wrote:
> >
> > It turns out if-conversions poor job on
> >
> > if (a)
> >x[i] = ...;
> > else
> >x[i] = ...;
> >
> > results in bogus uninit warnings of x[i] for a variety of reasons.
> > First of
On 09/02/16 21:06 +, Jonathan Wakely wrote:
This adds a note to the porting document about the (shockingly
widespread) problem of calling member functions through null pointers,
which GCC 6 no longer tolerates.
Following some comments about (bool)os I'm also tweaking another part
of the doc
Ping.
Thanks,
Kyrill
On 05/02/16 09:50, Kyrill Tkachov wrote:
Ping
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg02309.html
Thanks,
Kyrill
On 29/01/16 14:27, Kyrill Tkachov wrote:
Hi all,
Similar to aarch64, the arm port also suffers from PR target/69161 when combine
tries to propagate a CCm
On 10/02/16 22:36 -0800, Mike Stump wrote:
I’m seeing:
/home/mrs/work1/gcc/libstdc++-v3/testsuite/special_functions/18_riemann_zeta/check_value.cc:
In function 'void test(const testcase_riemann_zeta (&)[Num], Tp)':
/home/mrs/work1/gcc/libstdc++-v3/testsuite/special_functions/18_riemann_zeta/che
PING
On Tue, 2 Feb 2016 18:37:27 +0100
Andre Vehreschild wrote:
> Hi all,
>
> the attached patch fixes a regression that was most likely introduced
> by one of my former patches, when in an associate() the rank of the
> associated variable could not be determined at parse time correctly.
> The
Dear Andre,
That's very clever! OK for trunk
Thanks for the patch
Paul
On 11 February 2016 at 13:05, Andre Vehreschild wrote:
> PING
>
> On Tue, 2 Feb 2016 18:37:27 +0100
> Andre Vehreschild wrote:
>
>> Hi all,
>>
>> the attached patch fixes a regression that was most likely introduced
>> by
On 10/02/16 10:39, James Greenhalgh wrote:
On Wed, Feb 10, 2016 at 10:32:16AM +, Kyrill Tkachov wrote:
Hi James,
On 10/02/16 10:11, James Greenhalgh wrote:
On Thu, Feb 04, 2016 at 01:50:31PM +, Kyrill Tkachov wrote:
Hi all,
As part of the target attributes and pragmas support for GC
On Thu, Feb 11, 2016 at 01:10:33PM +, Kyrill Tkachov wrote:
> >>>Why not just keep the last string you printed, and use a string compare
> >>>to decide whether to print or not? Sure we'll end up doing a bit more
> >>>work, but the logic becomes simpler to follow and we don't need to pass
> >>>a
This is PR68973 part 2, the failure of a boost test, caused by a
splitter emitting an invalid move in reload_vsx_from_gprsf:
emit_move_insn (op0_di, op2);
op0 can be any vsx reg, but the mtvsrd destination constraint in
movdi_internal64 is "wj", which only allows fp regs. I'm not sure why
we ha
Does this look ok?
Index: porting_to.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/porting_to.html,v
retrieving revision 1.9
diff -u -r1.9 porting_to.html
--- porting_to.html 10 Feb 2016 17:21:54 - 1.9
+++ porting_to.h
On 02/11/2016 10:45 AM, Alan Modra wrote:
Due to uses elsewhere in vsx instructions, reload chooses to put
psuedo 185 in fr31, which can't be used as a base register in the
following:
What code exactly makes the choice of fr31? I assume this is in
reg_renumber, so it's IRA and not reload that
Hi,
Some SH specific test cases have started showing failures recently.
This one was easy. Committed as r233346.
Cheers,
Oleg
gcc/testsuite/ChangeLog:
* gcc.target/sh/pr54089-8.c: Adjust optimization level.
Index: gcc/testsuite/gcc.target/sh/pr54089-8.c
==
I've (mostly) ported gcc-python-plugin to gcc 6. The attached patch
for the gcc website starts a new "Plugin issues" section, and covers
the biggest issue I ran into (FWIW the suggested compatibility typedef
is the one I committed to gcc-python-plugin).
Validates.
OK to commit?Index: htdocs/gcc-
This patch has bootstrapped and tested on powerpc64le-unknown-linux-gnu
with no regressions. Is this ok for the trunk?
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48344 for the original
problem report. The error resulted because gcc's processing of
command-line options within gcc initia
On 02/10/2016 03:03 PM, Richard Biener wrote:
Ok, the following is in testing now.
Ok?
Thanks,
Richard.
2016-02-10 Richard Biener
PR rtl-optimization/69291
* ifcvt.c (noce_try_store_flag_constants): Do not allow
subexpressions affected by changing the result.
Ok
On 11/02/16 15:20 +0100, Marek Polacek wrote:
Does this look ok?
Looks OK, although how about stressing that it was only allowed as an
extension previously, e.g. ...
Index: porting_to.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/g
On 02/11/2016 12:49 AM, David Wohlferd wrote:
I believe the attached patch addresses all the other outstanding comments.
Bernd Edlinger made some thorough comments; I'll just add a few more. I
don't think this is a patch we're considering for gcc-6, at least not
for the initial release - I im
On Thu, 2016-02-11 at 10:16 +0100, Richard Biener wrote:
> On Wed, Feb 10, 2016 at 5:25 PM, Bernd Schmidt
> wrote:
> > On 02/09/2016 09:44 PM, David Malcolm wrote:
> > >
> > > This is a bug in a new feature, so it isn't a regression as such,
> > > but
> > > it's fairly visible, and I believe the
On 02/11/2016 04:12 PM, Kelvin Nilsen wrote:
* opts-global.c (handle_common_deferred_options): Introduce and
initialize two global variables to remember command-line options
specifying a stack-limiting register.
* opts.h: Add extern declarations of the two new g
On 02/11/2016 11:01 AM, Thomas Schwinge wrote:
The "avoid offloading" mechanism. Owed to the non-shared-memory
offloading architecture, if the compiler/runtime decides to "avoid
offloading", then this has to apply to *all* code offloading, for data
consistency reasons. Do we agree on that?
N
On 02/11/2016 08:40 AM, Bernd Schmidt wrote:
But again, if someone feels the docs patch as posted is preferrable, go
ahead and approve it (for stage1 I assume).
TBH, I haven't looked at the documentation patch at all; I've been
ignoring this issue because (a) I thought the technical details w
Hi!
While the cgraph versioning code is able to deal with clobber stmts that
refer to SSA_NAMEs set by basic blocks not split into the versioned
function, and similarly with debug stmts (clobbers refererring to those
are removed and debug stmts reset), on the main part that doesn't happen,
because
On Thu, Feb 11, 2016 at 10:22:24AM +0100, Richard Biener wrote:
> The other option is to simply not split the function in this case.
Here is a better fix (but it needs the other patch I've sent, so that
what is return_bb stays the same).
This patch arranges for the case where there is return_bb,
Hi!
Until recently, integer_zerop would STRIP_NOPS, so that change regressed
some cases in the -Waddress warning that affect some real-world code.
The following patch re-adds stripping of nops for that case (but doesn't try
to fold it further).
With this patch, for C and C++98 we get the same beha
On Thu, Feb 11, 2016 at 03:26:13PM +, Jonathan Wakely wrote:
> On 11/02/16 15:20 +0100, Marek Polacek wrote:
> >Does this look ok?
>
> Looks OK, although how about stressing that it was only allowed as an
> extension previously, e.g. ...
So like this? I've also added a note about stricter fl
Hi Paul, hi all,
thanks for the review. Committed as r233351.
Regards,
Andre
On Thu, 11 Feb 2016 13:36:44 +0100
Paul Richard Thomas wrote:
> Dear Andre,
>
> That's very clever! OK for trunk
>
> Thanks for the patch
>
> Paul
>
> On 11 February 2016 at 13:05, Andre Vehreschild wrote
On 11/02/16 17:39 +0100, Marek Polacek wrote:
On Thu, Feb 11, 2016 at 03:26:13PM +, Jonathan Wakely wrote:
On 11/02/16 15:20 +0100, Marek Polacek wrote:
>Does this look ok?
Looks OK, although how about stressing that it was only allowed as an
extension previously, e.g. ...
So like this?
PR64682 is a problem in distribute_notes, where it has trouble putting
a REG_DEAD note for a reg that is set twice in the right spot. My fix
for that did the wrong thing for PR69567. And then my attempted fix
for that one made PR64682 fail again.
Instead, let's just lose the note in such complic
On Thu, Feb 11, 2016 at 05:01:58PM +, Jonathan Wakely wrote:
> On 11/02/16 17:39 +0100, Marek Polacek wrote:
> >On Thu, Feb 11, 2016 at 03:26:13PM +, Jonathan Wakely wrote:
> >>On 11/02/16 15:20 +0100, Marek Polacek wrote:
> >>>Does this look ok?
> >>
> >>Looks OK, although how about stress
On 02/11/2016 09:39 AM, Marek Polacek wrote:
On Thu, Feb 11, 2016 at 03:26:13PM +, Jonathan Wakely wrote:
On 11/02/16 15:20 +0100, Marek Polacek wrote:
Does this look ok?
Looks OK, although how about stressing that it was only allowed as an
extension previously, e.g. ...
So like this?
Hi,
aarch64 supports section anchors but it appears
check_effective_target_section_anchors() doesn't contain entry for it.
This patch adds for entry for aarch64.
OK for trunk ?
Thanks,
Prathamesh
diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index 6459
On Thu, Feb 11, 2016 at 6:04 AM, Alan Modra wrote:
> This is PR68973 part 2, the failure of a boost test, caused by a
> splitter emitting an invalid move in reload_vsx_from_gprsf:
> emit_move_insn (op0_di, op2);
>
> op0 can be any vsx reg, but the mtvsrd destination constraint in
> movdi_interna
On 11 February 2016 at 14:10, Kyrill Tkachov
wrote:
>
> On 10/02/16 10:39, James Greenhalgh wrote:
>>
>> On Wed, Feb 10, 2016 at 10:32:16AM +, Kyrill Tkachov wrote:
>>>
>>> Hi James,
>>>
>>> On 10/02/16 10:11, James Greenhalgh wrote:
On Thu, Feb 04, 2016 at 01:50:31PM +, Kyrill T
On Thu, Feb 11, 2016 at 7:14 AM, Jeff Law wrote:
> On 02/09/2016 04:08 AM, Bin Cheng wrote:
>>
>> Hi,
>> When counting cost for loop inv, GCC checks if a loop inv can be
>> propagated into its use site (a memory reference). If it cannot be
>> propagated, we increase its cost so that it's expensiv
On Thu, Feb 11, 2016 at 10:09:19AM -0700, Martin Sebor wrote:
> It''s interesting that when the example is modified to use a double
> initializer it is rejected with a hard error even in C++ 03 mode
> when -Wpedantic (but not -Werror) is used. That seems like a bug.
> If it isn't, it might be wort
On 11/02/16 17:57, Christophe Lyon wrote:
On 11 February 2016 at 14:10, Kyrill Tkachov
wrote:
On 10/02/16 10:39, James Greenhalgh wrote:
On Wed, Feb 10, 2016 at 10:32:16AM +, Kyrill Tkachov wrote:
Hi James,
On 10/02/16 10:11, James Greenhalgh wrote:
On Thu, Feb 04, 2016 at 01:50:31PM +
Hi!
I'd like to ping a C++ P1 fix for PR69658:
http://gcc.gnu.org/ml/gcc-patches/2016-02/msg00352.html
Jakub
On 11 February 2016 at 19:04, Kyrill Tkachov
wrote:
>
> On 11/02/16 17:57, Christophe Lyon wrote:
>>
>> On 11 February 2016 at 14:10, Kyrill Tkachov
>> wrote:
>>>
>>> On 10/02/16 10:39, James Greenhalgh wrote:
On Wed, Feb 10, 2016 at 10:32:16AM +, Kyrill Tkachov wrote:
>
> H
David Edelsohn wrote:
> On Thu, Feb 11, 2016 at 6:04 AM, Alan Modra wrote:
> > This is PR68973 part 2, the failure of a boost test, caused by a
> > splitter emitting an invalid move in reload_vsx_from_gprsf:
> > emit_move_insn (op0_di, op2);
> >
> > op0 can be any vsx reg, but the mtvsrd destina
On Wed, Feb 10, 2016 at 4:45 AM, Jerry DeLisle wrote:
> The attached patch reverts the guilty code. We were trying to honor delim=NONE
> on namelist reads which is invalid.
>
> Test cases updated. Regression tested on x86-64.
>
> OK for trunk and back port in about a week?
For namelist_38.90, I t
On 02/09/2016 06:45 PM, Jerry DeLisle wrote:
> The attached patch reverts the guilty code. We were trying to honor delim=NONE
> on namelist reads which is invalid.
>
> Test cases updated. Regression tested on x86-64.
>
> OK for trunk and back port in about a week?
>
No response yet. Since thi
struct X {
const static double i = 3.14;
};
error: floating-point literal cannot appear in a constant-expression
const static double i = 3.14;
^~~~
Hm, indeed; I hadn't notice that. Dunno if is a bug (clang++ accepts this
with a warning). I've ad
On Thu, Feb 11, 2016 at 11:45:37AM -0700, Martin Sebor wrote:
> >> struct X {
> >> const static double i = 3.14;
> >> };
> >>
> >> error: floating-point literal cannot appear in a constant-expression
> >> const static double i = 3.14;
> >>^~~~
> >
> >Hm, in
On Sat, Feb 6, 2016 at 10:20 PM, Thomas Koenig wrote:
> Hi Andre,
>
>> In preventing memory clutter I like to advise the use of:
>>
>> char u_name[GFC_MAX_SYMBOL_LEN + 1];
>>
>> and safe us all the dynamic memory allocation/free.
>
>
> We're really talking micro-optimizations here, but well ... ;-
On 02/11/2016 11:25 AM, Jakub Jelinek wrote:
+ && !integer_zerop (tree_strip_nop_conversions (op1)))
Maybe cp_fold rather than tree_strip_nop_conversions?
Jason
Hi!
On Thu, Feb 11, 2016 at 01:56:09PM -0500, Jason Merrill wrote:
> On 02/11/2016 11:25 AM, Jakub Jelinek wrote:
> >+ && !integer_zerop (tree_strip_nop_conversions (op1)))
>
> Maybe cp_fold rather than tree_strip_nop_conversions?
Is it safe to call cp_fully_fold (typeck.c only calls i
On Thu, Feb 11, 2016 at 08:44:24PM +0100, Jakub Jelinek wrote:
> Hi!
>
> On Thu, Feb 11, 2016 at 01:56:09PM -0500, Jason Merrill wrote:
> > On 02/11/2016 11:25 AM, Jakub Jelinek wrote:
> > >+ && !integer_zerop (tree_strip_nop_conversions (op1)))
> >
> > Maybe cp_fold rather than tree_stri
On 02/11/2016 02:22 AM, Richard Biener wrote:
On Wed, 10 Feb 2016, Jakub Jelinek wrote:
Hi!
Markus has pointed out to a reduced testcase which still ICEs even with the
PR69241 fix. In that case the function with TREE_ADDRESSABLE return type
does not return at all (and -Wreturn-type properly d
This patch adds an __array_size keyword for the C, C++, Objective C and
Objective C++ languages which is similar to the sizeof keyword, but
yields the size of the specified array in elements, not bytes, and will
not accept expressions of pointer type.
At the moment, I am only looking for feedback,
On 02/11/2016 02:44 PM, Jakub Jelinek wrote:
Hi!
On Thu, Feb 11, 2016 at 01:56:09PM -0500, Jason Merrill wrote:
On 02/11/2016 11:25 AM, Jakub Jelinek wrote:
+ && !integer_zerop (tree_strip_nop_conversions (op1)))
Maybe cp_fold rather than tree_strip_nop_conversions?
Is it safe
The flexible array addition looks great to me. Thank you!
Great. I'll commit the patch.
Actually, there is one other thing that might be wort mentioning
about flexible array members.
The type and mangling of flexible array members has changed. While
in GCC 5 and prior the type of a flexible
On Thu, Feb 11, 2016 at 01:36:49PM -0700, Martin Sebor wrote:
> >>The flexible array addition looks great to me. Thank you!
> >
> >Great. I'll commit the patch.
>
> Actually, there is one other thing that might be wort mentioning
> about flexible array members.
>
> The type and mangling of flexi
On Thu, Feb 11, 2016 at 9:04 AM, Segher Boessenkool
wrote:
> PR64682 is a problem in distribute_notes, where it has trouble putting
> a REG_DEAD note for a reg that is set twice in the right spot. My fix
> for that did the wrong thing for PR69567. And then my attempted fix
> for that one made PR
Actually, there is one other thing that might be wort mentioning
about flexible array members.
The type and mangling of flexible array members has changed. While
in GCC 5 and prior the type of a flexible array member is an array
of zero elements (a GCC extension), in 6 it is that of an array of
After looking at Bernd Schmidt and Jakub Jelinek's suggestions, I came to
conclusion that earlyclobber was not needed in this case, and I removed it. I
bootstrapped the compiler using profiledbootstrap and lto options and it
succeeded build and running make check. Just to be sure, I also did a
pr
On Thu, Feb 11, 2016 at 09:34:29AM -0800, David Edelsohn wrote:
> On Thu, Feb 11, 2016 at 6:04 AM, Alan Modra wrote:
> > This is PR68973 part 2, the failure of a boost test, caused by a
> > splitter emitting an invalid move in reload_vsx_from_gprsf:
> > emit_move_insn (op0_di, op2);
> >
> > op0
On Thu, Feb 11, 2016 at 07:38:15PM +0100, Ulrich Weigand wrote:
> For the most part, this patch doesn't really change anything in the
> interaction with reload as far as I can see. The changes introduced
> by the patch do make sense to me. In particular, replacing the two
> patterns p8_mtvsrd_1 a
The more than decennnial rtl-optimization/19705 - -fno-branch-count-reg
doesn't prevent decrement and branch instructions on a count register
points out that the documentation of the option leads one to expect
that it prevents the decrement and branch instruction from appearing
in the instruction
OK.
Jason
On Thu, Feb 11, 2016 at 04:55:58PM -0500, Michael Meissner wrote:
> This is one of the cases I wished the reload support had the ability to
> allocate 2 scratch temporaries instead of 1. As I said in my other message,
> TFmode was a hack to get two registers to use.
Another concern I had about th
On Thu, 11 Feb 2016, Stuart Brady wrote:
> Documentation and test code are currently absent from the patch, but I
For proposed features, I find documentation and testcases of much more
value than the rest of the implementation. Critical issues to define and
cover thoroughly in tests include th
On Fri, Feb 12, 2016 at 08:54:19AM +1030, Alan Modra wrote:
> On Thu, Feb 11, 2016 at 04:55:58PM -0500, Michael Meissner wrote:
> > This is one of the cases I wished the reload support had the ability to
> > allocate 2 scratch temporaries instead of 1. As I said in my other message,
> > TFmode was
Hi!
While working on the -Waddress fix I've posted earlier today, I've noticed
that the C and C++ FE disagree on the spelling - C uses US english spelling,
while C++ uses UK english spelling.
This patch switches to US english spelling of these 2 words, in
diagnostics, documentation and comments as
Dear all,
in attachment the EVENT patch for gcc-5-branch directly back-ported
from the trunk.
Built and regtested on x86_64-pc-linux-gnu. I plan to commit this
patch this evening (Feb 12th, CET).
Cheers,
Alessandro
2015-12-17 17:19 GMT+01:00 Alessandro Fanfarillo :
> Great! Thanks.
>
> 2015-12
On 02/11/2016 10:59 AM, Bin.Cheng wrote:
Hi Jeff,
Thanks for detailed review. I also think a generic canonical
interface for RTL is much better. I will give it a try. But with
high chance it's a next stage1 stuff.
That is, of course, fine. However, if you do get something ready, I'd
support
Hi!
When expanding shifts with invalid shift counts (negative or too large),
the shift count on the GIMPLE level is typically an int mode INTEGER_CST,
but when it is passed down through various layers up to
expand_binop_directly, we only have one known mode (other than operand
modes, but that is V
ping!
2016-02-05 19:19 GMT+01:00 Janus Weil :
> Hi all,
>
> I have slightly updated the patch now to avoid string-breaking issues
> (even if it may not be a problem at all, as mentioned by Jospeh). Also
> I removed the questionable part in intrinsic.c that I was not sure
> about.
>
> This version
On 02/11/2016 03:57 PM, Jakub Jelinek wrote:
Hi!
While working on the -Waddress fix I've posted earlier today, I've noticed
that the C and C++ FE disagree on the spelling - C uses US english spelling,
while C++ uses UK english spelling.
This patch switches to US english spelling of these 2 words
So I've never thought much about our Complex support and I don't have a
lot of confidence in the coverage for our testsuite for these changes.
So I'd really appreciate someone with more experience thinking about
this issue for a bit.
I was looking at 33562 (P2), figuring it was DSE, which I
On Wed, Feb 10, 2016 at 2:46 PM, Jakub Jelinek wrote:
> On Wed, Feb 10, 2016 at 05:42:17PM -0500, Michael Meissner wrote:
>> This patch disables -mcpu=power8/-mtune=power8 from setting -mpower8-fusion
>> and
>> -mcpu=power9/-mtune=power9 from setting -mpower9-fusion. I will look at the
>> earlyc
On Thu, Feb 11, 2016 at 1:43 PM, Michael Meissner
wrote:
> After looking at Bernd Schmidt and Jakub Jelinek's suggestions, I came to
> conclusion that earlyclobber was not needed in this case, and I removed it. I
> bootstrapped the compiler using profiledbootstrap and lto options and it
> succeed
On Thu, Feb 11, 2016 at 04:14:59PM -0800, David Edelsohn wrote:
> On Thu, Feb 11, 2016 at 1:43 PM, Michael Meissner
> wrote:
> > After looking at Bernd Schmidt and Jakub Jelinek's suggestions, I came to
> > conclusion that earlyclobber was not needed in this case, and I removed it.
> > I
> > boo
On Thu, Feb 11, 2016 at 10:38 AM, Ulrich Weigand wrote:
> David Edelsohn wrote:
>> On Thu, Feb 11, 2016 at 6:04 AM, Alan Modra wrote:
>> > This is PR68973 part 2, the failure of a boost test, caused by a
>> > splitter emitting an invalid move in reload_vsx_from_gprsf:
>> > emit_move_insn (op0_d
On 02/11/2016 10:38 AM, Janne Blomqvist wrote:
> On Wed, Feb 10, 2016 at 4:45 AM, Jerry DeLisle wrote:
>> The attached patch reverts the guilty code. We were trying to honor
>> delim=NONE
>> on namelist reads which is invalid.
>>
>> Test cases updated. Regression tested on x86-64.
>>
>> OK for tr
On 02/12/2016 12:26 AM, Jakub Jelinek wrote:
When expanding shifts with invalid shift counts (negative or too large),
the shift count on the GIMPLE level is typically an int mode INTEGER_CST,
but when it is passed down through various layers up to
expand_binop_directly, we only have one known mod
This seems fairly straightforward:
(insn 213 455 216 6 (set (reg:SI 266)
(mem/u/c:SI (post_inc:SI (reg/f:SI 267)) [4 S4 A32])) 748
{*thumb1_movsi_insn}
(expr_list:REG_EQUAL (const_int -1044200508 [0xc1c2c3c4])
(expr_list:REG_INC (reg/f:SI 267)
(nil
On Thu, Feb 11, 2016 at 03:29:05PM +0100, Bernd Schmidt wrote:
> On 02/11/2016 10:45 AM, Alan Modra wrote:
>
> >Due to uses elsewhere in vsx instructions, reload chooses to put
> >psuedo 185 in fr31, which can't be used as a base register in the
> >following:
>
> What code exactly makes the choic
Hi Jason,
Your recent fix for PR c++/10200 seems to have fixed this longstanding
PR too. Should I add its test case to the testsuite and close the PR?
gcc/testsuite/ChangeLog:
PR c++/11814
* g++.dg/lookup/template4.C: New test.
---
gcc/testsuite/g++.dg/lookup/template4.C | 16 +
In r227188 I introduced driver::finalize () which resets
all state within gcc.c, allowing the driver code to embedded
inside libgccjit and run repeatedly in-process.
Running this on s390x revealed a bug in this cleanup:
I was cleaning up "specs" via:
XDELETEVEC (specs);
and this wa
On 2016.02.08 at 09:49 -0700, Jeff Law wrote:
> On 01/18/2016 08:52 PM, Kugan wrote:
> >
> >2016-01-19 Kugan Vivekanandarajah
> >
> > PR middle-end/66726
> > * tree-ssa-reassoc.c (optimize_range_tests): Handle tcc_compare stmt
> > whose result is used in PHI.
> > (maybe_optimize_
On 12/02/16 17:18, Markus Trippelsdorf wrote:
On 2016.02.08 at 09:49 -0700, Jeff Law wrote:
On 01/18/2016 08:52 PM, Kugan wrote:
2016-01-19 Kugan Vivekanandarajah
PR middle-end/66726
* tree-ssa-reassoc.c (optimize_range_tests): Handle tcc_compare stmt
whose result
why not simply -Wbasic-asm ?
Since both you and Bernd favor this shorter name, I have changed it.
Indentation wrong here. The whole block must be indented by 2 spaces.
Fixed.
Comments should end with dot space space */
Fixed.
the DECL_ATTRIBUTES should be at the same column as the "nak
I don't think this is a patch we're considering for gcc-6, at least
not for the initial release - I imagine it could be backported from
gcc-7 at some point.
Actually, it was my intent that this apply to v6. It's not like there
is a significant change here. We're documenting long-time behav
On 2/11/2016 8:03 AM, Sandra Loosemore wrote:
On 02/11/2016 08:40 AM, Bernd Schmidt wrote:
But again, if someone feels the docs patch as posted is preferrable, go
ahead and approve it (for stage1 I assume).
TBH, I haven't looked at the documentation patch at all; I've been
ignoring this issu
On 02/11/2016 06:28 PM, Bernd Schmidt wrote:
This seems fairly straightforward:
(insn 213 455 216 6 (set (reg:SI 266)
(mem/u/c:SI (post_inc:SI (reg/f:SI 267)) [4 S4 A32])) 748
{*thumb1_movsi_insn}
(expr_list:REG_EQUAL (const_int -1044200508 [0xc1c2c3c4])
(expr_li
On 02/11/2016 10:12 PM, David Malcolm wrote:
In r227188 I introduced driver::finalize () which resets
all state within gcc.c, allowing the driver code to embedded
inside libgccjit and run repeatedly in-process.
Running this on s390x revealed a bug in this cleanup:
I was cleaning up "specs" via:
95 matches
Mail list logo
