From: Zhouyi Zhou
In function setup_left_conflict_sizes_p, left conflict subnodes sizes
are computed in a down-to-up fashion through the regnodes foreast.
Speed up the process from prevent node itself to involve in this
computation.
Bootstrap and regtest scheduled on x86_64 GNU/Linux
Signed-
On 03/10/2015 05:55 PM, Jason Merrill wrote:
On 03/10/2015 08:07 PM, Aldy Hernandez wrote:
On 03/10/2015 04:59 PM, Jason Merrill wrote:
On 03/10/2015 07:10 PM, Aldy Hernandez wrote:
-/* Remove any copies of empty classes. We check that the RHS
- has a simple form so that TAR
On 03/10/2015 08:07 PM, Aldy Hernandez wrote:
On 03/10/2015 04:59 PM, Jason Merrill wrote:
On 03/10/2015 07:10 PM, Aldy Hernandez wrote:
-/* Remove any copies of empty classes. We check that the RHS
- has a simple form so that TARGET_EXPRs and non-empty
- CONSTRUCTO
On 03/10/2015 04:59 PM, Jason Merrill wrote:
On 03/10/2015 07:10 PM, Aldy Hernandez wrote:
-/* Remove any copies of empty classes. We check that the RHS
- has a simple form so that TARGET_EXPRs and non-empty
- CONSTRUCTORs get reduced properly, and we leave the retur
On 03/10/2015 07:10 PM, Aldy Hernandez wrote:
- /* Remove any copies of empty classes. We check that the RHS
- has a simple form so that TARGET_EXPRs and non-empty
- CONSTRUCTORs get reduced properly, and we leave the return
- slot optimization al
Agreed, we want (op1, op0) in this case. I think this demonstrates that
the existing code is wrong to sometimes return (op0, op1), since we
might be using the result as an lvalue. Better would be to always
gimplify op0 to an lvalue, gimplify_and_add the rhs, and finally return
the gimplified l
Honza,
On 10 March 2015 at 20:09, Yvan Roux wrote:
> On 10 March 2015 at 19:18, Jan Hubicka wrote:
>>> Hi
>>>
>>> On 9 March 2015 at 17:07, Yvan Roux wrote:
>>> > Hi,
>>> >
>>> > As added in the PR, this issue is also present on 4.9 branch and
>>> > affects at least arm-linux-gnueabihf target (
On 3/10/2015 21:18, Jonathan Wakely wrote:
> On 10/03/15 20:55 +0100, John Marino wrote:
>> On 3/10/2015 20:23, Jonathan Wakely wrote:
>>> John, assuming I'm right that dragonfly supports all these features,
>>> could you test this change? (You'll need the same change on line
>>> 19555 of the libs
This patch completes the description of the coarray library functions,
invoked for -fcoarray=lib.
OK for the trunk?
(The currently documented functions can be seen at
https://gcc.gnu.org/onlinedocs/gfortran/Coarray-Programming.html )
Tobias
* gfortran.texi (_gfortran_caf_sync_all, _gfortra
OK.
Jason
On 10/03/15 20:55 +0100, John Marino wrote:
On 3/10/2015 20:23, Jonathan Wakely wrote:
John, assuming I'm right that dragonfly supports all these features,
could you test this change? (You'll need the same change on line
19555 of the libstdc++-v3/configure script.)
Sure, I can test it. How
On 3/10/2015 20:23, Jonathan Wakely wrote:
> It has just occurred to me we might want to make this change for GCC5:
>
>
> diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
> index 1727140..0b8c0f0 100644
> --- a/libstdc++-v3/acinclude.m4
> +++ b/libstdc++-v3/acinclude.m4
> @@ -12
On 03/10/15 13:23, Jonathan Wakely wrote:
It has just occurred to me we might want to make this change for GCC5:
diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index 1727140..0b8c0f0 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -1219,11 +1219,11
On Tue, Mar 10, 2015 at 8:14 PM, Jakub Jelinek wrote:
> The following testcase fails, because the RTL pattern of bmi2_bzhi_*3
> didn't really model (not even close) what the instruction was doing,
> so when combiner attempted to simplify it for constant arguments, it
> simplified it into somethin
On Tue, Mar 10, 2015 at 7:24 AM, Jakub Jelinek wrote:
> Ok for trunk.
Committed.
Thanks!
--
Regards,
Tim Shen
It has just occurred to me we might want to make this change for GCC5:
diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index 1727140..0b8c0f0 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -1219,11 +1219,11 @@ AC_DEFUN([GLIBCXX_ENABLE_LIBSTDCXX_TIME]
Hi!
This patch documents knl. The PR is asking for also documenting
slm, but I believe those were intentionally removed from the documentation
as deprecated aliases, at least that is my reading of the
2013-12-23 H.J. Lu
Tocar Ilya
...
* doc/invoke.texi: Replace corei7,
Hi!
current_class_ptr could be just NULL or a PARM_DECL in the past,
but now it can also be ADDR_EXPR of a PLACEHOLDER_EXPR, which obviously
doesn't have DECL_CONTEXT.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
Jason acked it in the PR, committed to trunk.
2015-03-10 J
Hi!
The following testcase fails, because the RTL pattern of bmi2_bzhi_*3
didn't really model (not even close) what the instruction was doing,
so when combiner attempted to simplify it for constant arguments, it
simplified it into something wrong.
Fixed thusly, verified we don't regress on combin
On 10 March 2015 at 19:18, Jan Hubicka wrote:
>> Hi
>>
>> On 9 March 2015 at 17:07, Yvan Roux wrote:
>> > Hi,
>> >
>> > As added in the PR, this issue is also present on 4.9 branch and
>> > affects at least arm-linux-gnueabihf target (as reported in PR61207).
>> >
>> > I've backported it in the 4
Hi,
On 03/10/2015 07:10 PM, Jason Merrill wrote:
Ah. So here we can ignore any template instantiation or
specialization, with a comment that check_explicit_specialization will
handle them. But I suspect that checking the decl itself will be
better; I would expect checking the context to lead
On 10/03/15 12:10 -0600, Sandra Loosemore wrote:
Errr. If GCC 5 implements (present tense) this new feature, why
is the description written mostly in the future tense? :-(
When compiling such a function, GCC will do as described.
I'm happy to change it though, how's the attached revision
On 03/10/15 07:36, James Norris wrote:
Hi!
Ping.
Note that the GCC trunk is in regression bugfix stage, so this patch may
(is likely?) be deferred until the next stage1 development cycle.
jeff
> Hi
>
> On 9 March 2015 at 17:07, Yvan Roux wrote:
> > Hi,
> >
> > As added in the PR, this issue is also present on 4.9 branch and
> > affects at least arm-linux-gnueabihf target (as reported in PR61207).
> >
> > I've backported it in the 4.9 branch with the attached patch. The
> > difference
On 03/10/2015 11:43 AM, Jonathan Wakely wrote:
+Return by converting move constructor
+
+GCC 5 implements
+http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1579";>DR
1579
+which means that in a function like:
+
+
+ X
+ foo()
+ {
+Y y;
+return y;
+ }
+
+
+GCC will first a
> Hi!
>
> On Fri, Feb 20, 2015 at 19:49:03 +0100, Jan Hubicka wrote:
> > > On Fri, Feb 20, 2015 at 02:15:24PM +0100, Thomas Schwinge wrote:
> > > > > * ipa-devirt.c (odr_subtypes_equivalent_p): Fix formating.
> > > > > (compare_virtual_tables): Be smarter about skipping typeinfos;
> >
Since nullptr always converts to false it doesn't make much sense to
recommend using 'true' instead.
Committed to CVS.
Index: porting_to.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/porting_to.html,v
retrieving revision 1.6
diff
Hi,
this patch fixes leak in decl_in_states. We have quite few cases where we can
get rid of a node from symbol table without going through
function_in_decl_state. Most important being in lto-symtab merging.
Bootstrapped/regtested x86_64-linux, comitted.
Honza
* lto.c (read_cgraph_and_s
This change shouldn't cause many porting headaches, but it did cause
one package to fail to build (due to a bug in the package), so it's
worth documenting.
Committed to CVS.
Index: porting_to.html
===
RCS file: /cvs/gcc/wwwdocs/htdoc
... in any case, I can confirm that the below also passes testing. Not
sure if it makes sense to add the check also to the other call site,
can't figure out a testcase...
Thanks,
Paolo.
/
Index: cp/decl.c
===
--- c
On 02/25/2015 05:40 PM, Maxim Ostapenko wrote:
On 02/16/2015 10:58 AM, Maxim Ostapenko wrote:
Hi,
when testing I noticed, that if compile with both -fsanitize=address and
-fstack-protector for 32-bit architectures and run with
ASAN_OPTIONS=detect_stack_use_after_return=1, libsanitizer fails w
In this testcase we refer to an alias template specialization where the
arguments to the alias-template are non-dependent, but some of the
arguments to the underlying class template are dependent, so we need to
check at both levels.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 574e38e
On Mon, 9 Mar 2015, Ian Lance Taylor wrote:
> I committed this patch to gcc-5/changes.html to mention the new go and
> gofmt programs.
Thanks for doing this, Ian. I committed a small markup fix on
top of it.
Gerald
Index: changes.html
Hi
On 9 March 2015 at 17:07, Yvan Roux wrote:
> Hi,
>
> As added in the PR, this issue is also present on 4.9 branch and
> affects at least arm-linux-gnueabihf target (as reported in PR61207).
>
> I've backported it in the 4.9 branch with the attached patch. The
> difference with the trunk code
Hi,
On 03/10/2015 05:19 PM, Jason Merrill wrote:
On 03/10/2015 11:50 AM, Paolo Carlini wrote:
+ /* Don't get fooled by, eg:
+
+ template class C
+ {
+ template
+ C(const C&, bool = false);
+ };
+
+ template <>
+ template
+ C::C(const C&, bool); */
+
+ i
On 03/09/2015 11:35 PM, Jeff Law wrote:
On 03/09/15 16:22, Aldy Hernandez wrote:
Hello gentlemen.
The problem here is that we pick up the system's CFLAGS and pass it down
to the target libraries. This causes havoc when, for instance, CFLAGS
is -march=x86-64 and the target is powerpc-linux.
I
On Mar 9, 2015, Jeff Law wrote:
> On 03/09/15 08:38, Richard Biener wrote:
>> On Fri, Mar 6, 2015 at 7:04 PM, Alexandre Oliva wrote:
>>> On Feb 26, 2015, Alexandre Oliva wrote:
>>>
So far, all the differences I looked at were caused by padding at the
end of BBs, and by jump stmts wi
On 03/10/2015 11:50 AM, Paolo Carlini wrote:
+ /* Don't get fooled by, eg:
+
+ template class C
+ {
+ template
+ C(const C&, bool = false);
+ };
+
+ template <>
+ template
+ C::C(const C&, bool); */
+
+ if (DECL_FUNCTION_MEMBER_P (decl)
+ && CLASSTYP
On 10 Mar 18:11, Ilya Enkovich wrote:
> Hi,
>
> This patch changes rtx cost for address constants to 0 similar to what we
> have in address cost hook beacuse we expect them to be propagated into
> address expression anyway. Bootstrapped and tested on
> x86_64-unknown-linux-gnu. OK for trunk o
On 10 Mar 18:00, Ilya Enkovich wrote:
> Hi,
>
> This patch allows propagation of loop invariants for i386 if propagated value
> is a constant to be used in address operand. Bootstrapped and tested on
> x86_64-unknown-linux-gnu. OK for trunk or stage 1?
>
> Thanks,
> Ilya
Updated ChangeLog an
On 10 Mar 16:17, Jakub Jelinek wrote:
> On Tue, Mar 10, 2015 at 05:54:46PM +0300, Ilya Enkovich wrote:
> > This patches set addresses the problem of inefficient usage of x86
> > addressing modes in PIC. Looking into generated 32bit PIC assembler we may
> > see lots of 'leal @GOTOFF, %reg' instr
Hi,
my fix for c++/15339 caused this regression, where we now reject the
below valid testcase. I think we can handle the problem by adding an
early return to check_redeclaration_no_default_args.
Tested x86_64-linux.
Thanks,
Paolo.
///
/cp
2015-03-10 Paolo Carlini
This PR exposes a bug where we weren't properly updating gsi in case of just
removing the unnecessary UBSAN_OBJECT_SIZE call. In such a case we need to
remove the statement using the gsi passed down to ubsan_expand_objsize_ifn,
not with a copy of it, because we rely on gsi_remove to update the ite
[stage1 ping]
On 22-02-15 14:13, Tom de Vries wrote:
On 19-02-15 14:03, Richard Biener wrote:
On Thu, 19 Feb 2015, Tom de Vries wrote:
On 19-02-15 11:29, Tom de Vries wrote:
Hi,
I'm posting this patch series for stage1:
- 0001-Disable-lang_hooks.gimplify_expr-in-free_lang_data.patch
- 0002-A
Totally fine with me. Thanks.
2015-03-10 0:20 GMT-07:00 Tobias Burnus :
> Hi Alessandro,
>
> Alessandro Fanfarillo wrote:
>>
>> Thanks for the quick response. Patch built and regtested on
>> x86_64-unknown-linux-gnu.
>
>
> Actually, I also was about to send a reworked patch myself - see attachment
[stage1 ping]
[was: Postpone expanding va_arg until pass_stdarg]
On 24-02-15 07:48, Tom de Vries wrote:
On 23-02-15 11:09, Tom de Vries wrote:
On 23-02-15 09:26, Michael Matz wrote:
Hi,
On Sun, 22 Feb 2015, Tom de Vries wrote:
Btw, I'm wondering if as run-time optimization we can tentatively
On Tue, Mar 10, 2015 at 05:54:46PM +0300, Ilya Enkovich wrote:
> This patches set addresses the problem of inefficient usage of x86 addressing
> modes in PIC. Looking into generated 32bit PIC assembler we may see lots of
> 'leal @GOTOFF, %reg' instructions. Almost in all cases this
> constant
Hi,
This patch changes rtx cost for address constants to 0 similar to what we have
in address cost hook beacuse we expect them to be propagated into address
expression anyway. Bootstrapped and tested on x86_64-unknown-linux-gnu. OK
for trunk or stage 1?
Thanks,
Ilya
--
gcc/
2015-03-10 Ilya
This is just a small addendum to the option and specs handling:
- Document new avr-gcc command options
- Change -march= to -mmcu= in some test cases
- Add comfigure test to detect whether gas supports -mrmw and --mlink-relax.
- Use result of these tests in specs generatio, i.e. omit respective
Hi,
This patch allows propagation of loop invariants for i386 if propagated value
is a constant to be used in address operand. Bootstrapped and tested on
x86_64-unknown-linux-gnu. OK for trunk or stage 1?
Thanks,
Ilya
--
gcc/
2015-03-10 Ilya Enkovich
PR target/65103
* gcc
On Tue, Mar 10, 2015 at 02:13:49PM +, Jonathan Wakely wrote:
> On 9 March 2015 at 10:56, Tim Shen wrote:
> > I guess this patch doesn't break abi compatibility, so if everything
> > is Ok, I'm gonna patch it to 4.9 too.
>
> It doesn't change the ABI directly, but it does change the layout of
>
Hi,
This patches set addresses the problem of inefficient usage of x86 addressing
modes in PIC. Looking into generated 32bit PIC assembler we may see lots of
'leal @GOTOFF, %reg' instructions. Almost in all cases this constant
value may be propagated into following address operand, but it do
On Tue, 10 Mar 2015, Richard Biener wrote:
>
> This removes the old vestige loop to find a gsi for a stmt (from times
> where gsi_for_stmt was O(n)).
>
> PR44563 shows gimple_split_block quite high in the profile (this
> patch doesn't fix that) as the tail loop setting BB on all stmts
> moved to
On 9 March 2015 at 10:56, Tim Shen wrote:
> I guess this patch doesn't break abi compatibility, so if everything
> is Ok, I'm gonna patch it to 4.9 too.
It doesn't change the ABI directly, but it does change the layout of
the match_results' data on the heap. It mean that instantiations of
e.g. __r
Hi Richard and Eric,
On Mon, 9 Mar 2015 15:30:31, Richard Biener wrote:
>> Reg-tested on x86_64 successfully and ARM is still running.
ARM completed without regressions meanwhile.
>>
>> Is it OK for trunk?
>
> Looks ok to me apart from
>
> /* Check for cases of unaligned fields that must be spli
Hi!
Ping.
Thanks!
On 02/16/2015 12:26 PM, James Norris wrote:
This fixes the validation of the argument to the deviceptr clause.
Bootstrapped and regtested on x86_64-unknown-linux-gnu.
OK to commit to trunk?
Jim
Okay everywhere.
Thanks, David
On Tue, Mar 10, 2015 at 8:10 AM, Jakub Jelinek wrote:
> On Tue, Mar 10, 2015 at 10:36:24PM +1030, Alan Modra wrote:
>> On Tue, Mar 10, 2015 at 12:08:50PM +0100, Markus Trippelsdorf wrote:
>> > On 2015.03.10 at 08:56 +0100, Jakub Jelinek wrote:
>> > > https://gcc.gn
Hi!
On Fri, Feb 20, 2015 at 19:49:03 +0100, Jan Hubicka wrote:
> > On Fri, Feb 20, 2015 at 02:15:24PM +0100, Thomas Schwinge wrote:
> > > > * ipa-devirt.c (odr_subtypes_equivalent_p): Fix formating.
> > > > (compare_virtual_tables): Be smarter about skipping typeinfos;
> > > >
Hi!
Ping.
On Thu, 19 Feb 2015 09:39:52 +0100, I wrote:
> On Wed, 18 Feb 2015 18:04:21 +0100, I wrote:
> > On Mon, 13 Oct 2014 14:33:11 +0400, Ilya Verbin wrote:
> > > On 13 Oct 12:19, Jakub Jelinek wrote:
> > > > On Sat, Oct 11, 2014 at 06:49:00PM +0400, Ilya Verbin wrote:
> > > > > 2. -foffload
Hi!
All the "offloading folks" agree, but we need someone to "formally
approve" this patch?
On Fri, 20 Feb 2015 22:27:43 +0300, Ilya Verbin wrote:
> On Fri, Feb 20, 2015 at 10:27:26 +0100, Thomas Schwinge wrote:
> > On Thu, 19 Feb 2015 10:28:46 +0100, Bernd Schmidt
> > wrote:
> > > issue when
On 03/10/2015 11:27 AM, Richard Biener wrote:
> Is this fixing a regression in some way?
Not really. The optimization supposed to fold the bswap in that case is not
that old:
https://gcc.gnu.org/ml/gcc-patches/2013-05/msg01378.html
The underlying problem however is probably visible in one wa
On Tue, Mar 10, 2015 at 10:36:24PM +1030, Alan Modra wrote:
> On Tue, Mar 10, 2015 at 12:08:50PM +0100, Markus Trippelsdorf wrote:
> > On 2015.03.10 at 08:56 +0100, Jakub Jelinek wrote:
> > > https://gcc.gnu.org/ml/gcc-patches/2013-03/msg00288.html
> > > for similar issue on aarch64.
> > > You real
On Tue, Mar 10, 2015 at 12:08:50PM +0100, Markus Trippelsdorf wrote:
> On 2015.03.10 at 08:56 +0100, Jakub Jelinek wrote:
> > https://gcc.gnu.org/ml/gcc-patches/2013-03/msg00288.html
> > for similar issue on aarch64.
> > You really don't want to use MULTIARCH_DIRNAME for the powerpc64le* case,
> >
On Tue, Mar 10, 2015 at 12:47:54PM +0100, Markus Trippelsdorf wrote:
> On 2015.01.26 at 23:22 -0500, Ed Smith-Rowland wrote:
> > Gerald,
> >
> > Could I get a hand on checking in this last addition?
> >
> > -m 'Add a blurb to htdocs/gcc-5/changes.html to explain the
> > __has_cpp_attribute and
>
This removes the old vestige loop to find a gsi for a stmt (from times
where gsi_for_stmt was O(n)).
PR44563 shows gimple_split_block quite high in the profile (this
patch doesn't fix that) as the tail loop setting BB on all stmts
moved to the new block shows quadratic behavior when inlining
N ca
On 2015.01.26 at 23:22 -0500, Ed Smith-Rowland wrote:
> Gerald,
>
> Could I get a hand on checking in this last addition?
>
> -m 'Add a blurb to htdocs/gcc-5/changes.html to explain the
> __has_cpp_attribute and
> the equivalent __has_attribute macros.'
>
> Thanks,
Ping?
And maybe add a word
On Tue, Mar 10, 2015 at 11:38 AM, Marek Polacek wrote:
> On Tue, Mar 10, 2015 at 11:33:13AM +0100, Richard Biener wrote:
>> Isn't cfun->decl much more likely to work?
>
> Dunno, if that's the case, then:
Ok (or use cfun ? cfun->decl : current_function_decl).
Thanks,
Richard.
> 2015-03-10 Marek
On 2015.03.10 at 08:56 +0100, Jakub Jelinek wrote:
> On Tue, Mar 10, 2015 at 08:32:59AM +0100, Markus Trippelsdorf wrote:
> > On 2015.03.10 at 17:58 +1030, Alan Modra wrote:
> > > On Tue, Mar 10, 2015 at 07:13:48AM +0100, Markus Trippelsdorf wrote:
> > > > This patch breaks the build on ppc64le:
>
On Tue, 10 Mar 2015, Jakub Jelinek wrote:
> On Tue, Mar 10, 2015 at 11:53:56AM +0100, Richard Biener wrote:
> > 2015-03-09 Richard Biener
> >
> > PR middle-end/44563
> > * tree-inline.c (copy_cfg_body): Skip block mapped to entry/exit
> > for redirect_all_calls.
> >
> > Index: gcc
CFG cleanup currently searches for calls that became noreturn and
fixes them up (splitting block and removing the fallthru). Previously
that was technically necessary as propagation may have turned an
indirect call into a direct noreturn call and the CFG verifier would
have barfed. Today we guar
Oleg Endo wrote:
> I think the same should be done in t-sh and in t-linux we could add the
> SH1 little endian exception, too ... just in case (see attached patch).
> I'm not sure whether TM_MULTILIB_EXCEPTIONS_CONFIG is needed in t-linux
> or not. Moreover, I don't understand why t-linux doesn't
On Tue, Mar 10, 2015 at 11:53:56AM +0100, Richard Biener wrote:
> 2015-03-09 Richard Biener
>
> PR middle-end/44563
> * tree-inline.c (copy_cfg_body): Skip block mapped to entry/exit
> for redirect_all_calls.
>
> Index: gcc/tree-inline.c
>
This improves PR44563 a lot by not walking the block before/after
the call being inlined for redirect_all_calls - that block will
have up to 10 (unrelated) calls.
Bootstrapped on x86_64-unknown-linux-gnu, regtest in progress.
Will apply to trunk after that succeeded.
Thanks,
Richard.
2015-
On Tue, Mar 10, 2015 at 11:33:13AM +0100, Richard Biener wrote:
> Isn't cfun->decl much more likely to work?
Dunno, if that's the case, then:
2015-03-10 Marek Polacek
* gdbinit.in (pcfun): Define and document.
diff --git gcc/gdbinit.in gcc/gdbinit.in
index 10fe5ad..436de06 100644
---
On Tue, Mar 10, 2015 at 11:31 AM, Marek Polacek wrote:
> Typing "call debug_function (current_function_decl, 0)" every time I want to
> see
> the current function is bothersome, the more so if I accidentally tap TAB and
> gdb
> tries to autocomplete the current word (argh!). The following adds
Typing "call debug_function (current_function_decl, 0)" every time I want to see
the current function is bothersome, the more so if I accidentally tap TAB and
gdb
tries to autocomplete the current word (argh!). The following adds an alias so
I
can just type "pcfun" and be happy.
Ok?
2015-03-10
On Tue, Mar 10, 2015 at 10:19 AM, Andreas Krebbel
wrote:
> On 03/10/2015 10:12 AM, Steven Bosscher wrote:
>> On Tue, Mar 10, 2015 at 8:57 AM, Andreas Krebbel wrote:
>>>
>>> * gcc/ifcvt.c (if_convert):
>>>
>>
>> ...yes...?
>
> Damn. mklog is still not able to do the complete job for me ;)
>
Hi,
Currentl we loose returned bounds when functions are merged. This patch fixes
it by adding returne bounds support for cgraph_node::expand_thunk.
Bootstrapped and tested on x86_64-unknown-linux-gnu. OK for trunk?
Thanks,
Ilya
--
gcc/
2015-03-06 Ilya Enkovich
* cgraphunit.c (c
On 09/03/15 12:47, Jonathan Wakely wrote:
On 13/02/15 13:48 +, Matthew Wahab wrote:
Some DOS line endings were introduced into the char/isctype.cc file
when I committed this change These aren't visible in a terminal or
with svn diff but do show up in emacs. This is causing the test to
fail i
On Tue, 10 Mar 2015, James Greenhalgh wrote:
>
> Hi,
>
> The purpose of this test is to ensure the compiler does the right
> thing when a pointer with larger assumed alignment is assigned to
> a pointer with smaller assumed alignment. It checks for this with a
> vector testcase expected to gener
On 03/10/2015 10:12 AM, Steven Bosscher wrote:
> On Tue, Mar 10, 2015 at 8:57 AM, Andreas Krebbel wrote:
>>
>> * gcc/ifcvt.c (if_convert):
>>
>
> ...yes...?
Damn. mklog is still not able to do the complete job for me ;)
> Tiny nail, huge hammer. This triggers a full re-scan of all insns
Hi,
The purpose of this test is to ensure the compiler does the right
thing when a pointer with larger assumed alignment is assigned to
a pointer with smaller assumed alignment. It checks for this with a
vector testcase expected to generate fixups for alignment.
For ARM targets we're perfectly h
On Tue, Mar 10, 2015 at 8:57 AM, Andreas Krebbel wrote:
>
> * gcc/ifcvt.c (if_convert):
>
...yes...?
> diff --git a/gcc/ifcvt.c b/gcc/ifcvt.c
> index a3e3e5c..d2040af 100644
> --- a/gcc/ifcvt.c
> +++ b/gcc/ifcvt.c
> @@ -4626,6 +4626,13 @@ if_convert (bool after_combine)
>
On Tue, 2015-03-10 at 08:19 +0900, Kaz Kojima wrote:
> Yoshinori Sato wrote:
> >>* config/sh/t-linux (MULTILIB_EXCEPTIONS): Define for m2a cases.
> [snip]
> > It works fine.
>
> Thanks for checking. I've committed it on trunk as revision 221287.
>
> Regards,
> kaz
>
I think the same
Hi,
The SH specific test gcc.target/sh/pr54680.c has started to fail
recently. This is because of improved IPA optimizations. For this test
the IPA optimization should be turned off.
Tested with
make -k check-gcc RUNTESTFLAGS="sh.exp=pr54680.c --target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m
On Tue, 10 Mar 2015, Jan Hubicka wrote:
> >
> > This reduces the time spent in cgraph call-site hash by providing
> > inline version of htab_hash_pointer.
> >
> > Bootstrap / regtest on x86_64-unknown-linux-gnu in progress.
> >
> > Ok?
> >
> > Thanks,
> > Richard.
> >
> > 2015-03-09 Richard
On Mon, 2015-03-09 at 08:53 +0900, Kaz Kojima wrote:
> Oleg Endo wrote:
> > Backporting of the fix went into GCC 5 seems to intrusive for the
> > released branches. Hence I'd propose to remove the problematic patterns
> > altogether, as they can silently generate wrong code. The attached
> > pat
Hi,
the combine pass sometimes gets confused by already dead compares
which are remains of the if conversion pass. This e.g. happens in
gcc.dg/builtin-bswap-7.c. Compiling with -march=z196 the if blocks
are modified to make use of load on condition. This duplicates the
compare insn but unfortuna
On Tue, Mar 10, 2015 at 08:32:59AM +0100, Markus Trippelsdorf wrote:
> On 2015.03.10 at 17:58 +1030, Alan Modra wrote:
> > On Tue, Mar 10, 2015 at 07:13:48AM +0100, Markus Trippelsdorf wrote:
> > > This patch breaks the build on ppc64le:
> >
> > Works for me with your configure options.
> >
> > >
> From: Steven Bosscher [mailto:stevenb@gmail.com]
> Sent: Monday, March 09, 2015 7:48 PM
> To: Thomas Preud'homme
> Cc: GCC Patches; Eric Botcazou
> Subject: Re: [PATCH, stage1] Move insns without introducing new
> temporaries in loop2_invariant
>
> On Thu, Mar 5, 2015 at 10:53 AM, Thomas Pre
On 2015.03.10 at 17:58 +1030, Alan Modra wrote:
> On Tue, Mar 10, 2015 at 07:13:48AM +0100, Markus Trippelsdorf wrote:
> > This patch breaks the build on ppc64le:
>
> Works for me with your configure options.
>
> > trippels@gcc2-power8 gcc_build_dir % ../gcc/configure --with-cpu=power8
> > --dis
On Tue, Mar 10, 2015 at 07:13:48AM +0100, Markus Trippelsdorf wrote:
> This patch breaks the build on ppc64le:
Works for me with your configure options.
> trippels@gcc2-power8 gcc_build_dir % ../gcc/configure --with-cpu=power8
> --disable-libsanitizer --disable-bootstrap --disable-libstdcxx-pch
Hi Alessandro,
Alessandro Fanfarillo wrote:
Thanks for the quick response. Patch built and regtested on
x86_64-unknown-linux-gnu.
Actually, I also was about to send a reworked patch myself - see
attachment. Additional changes compared to your last patch:
* Add the assembler statement to lib
93 matches
Mail list logo
