https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62037
--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org ---
Firstly, a warning doesn't mean you cannot do it, you just get a warning.
Secondly, that's the correct behaviour, see
http://c-faq.com/ansi/constmismatch.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62002
Igor Zamyatin izamyatin at gmail dot com changed:
What|Removed |Added
CC||izamyatin at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62036
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
As pointed out at
http://stackoverflow.com/questions/25115189/optimization-bug-regarding-gcc-stdthread#comment39095137_25115189
(where you apparently copied this code from) there's a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62037
Michael Rolnik mrolnik at gmail dot com changed:
What|Removed |Added
Status|RESOLVED|CLOSED
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62036
--- Comment #2 from Cameron dacamara.cameron at gmail dot com ---
Welp looks like my friend got to it before I did. My bad. Carry on and good
work!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62037
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61510
jgreenhalgh at gcc dot gnu.org changed:
What|Removed |Added
Target|cris-axis-elf, |cris-axis-elf,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62023
Rainer Orth ro at gcc dot gnu.org changed:
What|Removed |Added
CC||jason at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62022
Rainer Orth ro at gcc dot gnu.org changed:
What|Removed |Added
CC||jason at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61294
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
CC||amodra at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62033
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62002
--- Comment #3 from Viacheslav Chernyshev astellar at ro dot ru ---
No, fcilkplus switch triggers compilation error when code is perfectly valid.
Your example is wrong, as in C++ this pointer is an implicit first argument of
member function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61923
--- Comment #6 from Vladimir Makarov vmakarov at gcc dot gnu.org ---
Author: vmakarov
Date: Wed Aug 6 15:35:49 2014
New Revision: 213674
URL: https://gcc.gnu.org/viewcvs?rev=213674root=gccview=rev
Log:
2014-08-06 Vladimir Makarov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61923
--- Comment #7 from Vladimir Makarov vmakarov at gcc dot gnu.org ---
Author: vmakarov
Date: Wed Aug 6 15:40:26 2014
New Revision: 213675
URL: https://gcc.gnu.org/viewcvs?rev=213675root=gccview=rev
Log:
2014-08-06 Vladimir Makarov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62002
--- Comment #4 from Igor Zamyatin izamyatin at gmail dot com ---
Right, it is mentioned explicitly in the docs. Will take a look
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61923
--- Comment #8 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
Thanks Vladimir.
I can now build my kernel with GCC_COMPARE_DEBUG=1 without any issues.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61749
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Assignee|jgreenhalgh at gcc dot gnu.org |ktkachov at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61393
--- Comment #9 from torvald at gcc dot gnu.org ---
Alex, can you confirm that this is fixed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55641
--- Comment #9 from Tom Tromey tromey at gcc dot gnu.org ---
I think this happens due to this code in gen_variable_die:
tree type = TREE_TYPE (decl_or_origin);
if (decl_by_reference_p (decl_or_origin))
add_type_attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61954
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
Uroš Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
Summary|reflect.go:test13reflect2 |recover.go:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62023
--- Comment #3 from Jason Merrill jason at gcc dot gnu.org ---
(In reply to Jonathan Wakely from comment #1)
Which means the __gthread_active_p() function in libgcc/gthr-posix.h is
returning false
Looks like there's a Solaris-specific version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60874
Uroš Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
Target Milestone|4.10.0 |4.9.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62038
Bug ID: 62038
Summary: Out of range branch target in thunk
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62039
Bug ID: 62039
Summary: concept checking for std::prev
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62036
Cameron dacamara.cameron at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51253
Cameron dacamara.cameron at gmail dot com changed:
What|Removed |Added
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62040
Bug ID: 62040
Summary: internal compiler error: in
simplify_const_unary_operation, at simplify-rtx.c:1555
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62040
--- Comment #1 from davidxl xinliangli at gmail dot com ---
Created attachment 33264
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33264action=edit
test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62040
--- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org ---
(insn 144 82 145 2 (set (reg:V2DI 33 v1 [orig:96 D.2914 ] [96])
(vec_concat:V2DI (reg:DI 32 v0 [orig:95 D.2915 ] [95])
(vec_duplicate:DI (const_int 0 [0]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62040
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Target||aarch64*-*-*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62041
Bug ID: 62041
Summary: vector fneg codegen uses a subtract instead of an xor
(x86-64)
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43906
--- Comment #2 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org ---
Author: paolo
Date: Wed Aug 6 19:09:08 2014
New Revision: 213682
URL: https://gcc.gnu.org/viewcvs?rev=213682root=gccview=rev
Log:
/cp
2014-08-06 Paolo Carlini
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43906
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51312
--- Comment #11 from Paolo Carlini paolo.carlini at oracle dot com ---
I'm having a look at the issue and it seems rather different than I (we)
thought. Suffices to say that it does not affect constexpr non-operator member
functions, and that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62042
Bug ID: 62042
Summary: Missing optimization of copying non-limited objects
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61510
Hans-Peter Nilsson hp at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62039
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62014
Evandro Menezes e.menezes at samsung dot com changed:
What|Removed |Added
Status|WAITING |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51312
--- Comment #12 from Paolo Carlini paolo.carlini at oracle dot com ---
build_expr_type_conversion is the answer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51744
Alan Modra amodra at gmail dot com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61994
Jason Merrill jason at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61994
--- Comment #2 from Jason Merrill jason at gcc dot gnu.org ---
Author: jason
Date: Thu Aug 7 01:44:06 2014
New Revision: 213688
URL: https://gcc.gnu.org/viewcvs?rev=213688root=gccview=rev
Log:
PR c++/61994
* init.c (build_vec_init):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60417
--- Comment #8 from Jason Merrill jason at gcc dot gnu.org ---
Author: jason
Date: Thu Aug 7 01:44:11 2014
New Revision: 213689
URL: https://gcc.gnu.org/viewcvs?rev=213689root=gccview=rev
Log:
PR c++/60417
* init.c (build_vec_init):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62043
Bug ID: 62043
Summary: [4.9/4.10 Regression] GCC hangs / aborts / double free
or corruption (!prev) on invalid input
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62043
--- Comment #1 from Dmitry Gorbachev d.g.gorbachev at gmail dot com ---
Created attachment 33266
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33266action=edit
Backtrace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61767
--- Comment #2 from reubendb at gmail dot com ---
I don't know why this is the case, but adding an allocatable variable in the
type definition of MessageTemplate above avoids the ICE, i.e the following does
not produce ICE:
module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51843
--- Comment #2 from Dmitry Gorbachev d.g.gorbachev at gmail dot com ---
No ICE with GCC 4.9/4.10, the attribute is silently ignored.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62043
--- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org ---
The sorry should be a fatal error now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62044
Bug ID: 62044
Summary: ICE in USE statement with RENAME for extended derived
type
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55592
Alan Modra amodra at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
On 5 August 2014 21:59, Richard Biener richard.guent...@gmail.com wrote:
On Mon, Aug 4, 2014 at 11:09 AM, Zhenqiang Chen zhenqiang.c...@arm.com
wrote:
-Original Message-
From: Bin.Cheng [mailto:amker.ch...@gmail.com]
Sent: Monday, August 04, 2014 4:41 PM
To: Zhenqiang Chen
Cc:
Jakub Jelinek wrote:
On Sat, Aug 02, 2014 at 12:09:24AM +0300, Janne Blomqvist wrote:
--- libgfortran/runtime/memory.c.jj 2014-06-18 08:50:33.0 +0200
+++ libgfortran/runtime/memory.c2014-08-01 14:41:08.385856116 +0200
@@ -56,7 +56,9 @@ xmallocarray (size_t nmemb, size_t
* PING * – of the patch with the obvious change mentioned by Alessandro
(i.e. using if(is_lock_type))?
Tobias
On 1 August 2014 21:57, Alessandro Fanfarillo wrote:
Hello,
I was implementing lock/unlock on the library side when I found a
possible problem in the patch:
if (is_lock_type ==
Hi,
On 08/06/2014 06:41 AM, Braden Obrzut wrote:
I can confirm that this is caused by a change to pt.c that happened, I
think, the day before my last patch.
This can be fixed by first checking that the template is a function
template at that line in pt.c. Since variable templates can't be
Thanks for looking at this.
Bootstrapped and reg-tested on x86_64-unknown-linux-gnu.
2014-08-06 0:18 GMT+04:00 Jeff Law l...@redhat.com:
On 08/04/14 00:08, Alexander Ivchenko wrote:
Hi,
libcilkrts is compiled with -nostdlib, that means we have to
explicitly specify the pthread library we
On Tue, 5 Aug 2014, Jeff Law wrote:
On 08/05/14 08:36, Marek Polacek wrote:
On Mon, Aug 04, 2014 at 02:04:36PM +0200, Richard Biener wrote:
Looks like .fre can optimize q - (q - 1) into 1:
bb 2:
q.0_3 = (long int) MEM[(void *)i + 4B];
_5 = (long int) i;
- _6 =
On Tue, Aug 05, 2014 at 02:14:21PM -0600, Jeff Law wrote:
My concern is the code we're removing discusses the need to simplify when
these expressions are in static initializers. What's going to ensure that
we're still simplifying instances which appear in static initializers? I
don't see
On Wed, Aug 06, 2014 at 10:22:19AM +0200, Marek Polacek wrote:
On Tue, Aug 05, 2014 at 02:14:21PM -0600, Jeff Law wrote:
My concern is the code we're removing discusses the need to simplify when
these expressions are in static initializers. What's going to ensure that
we're still
On 05/08/14 12:18, Kyrill Tkachov wrote:
Hi all,
This is a cleanup to replace usages of GET_CODE (x) == CONST_INT with
CONST_INT_P (x) and GET_CODE (x) == REG with REG_P (x). No functional
changes.
Tested on aarch64-none-elf and bootstrapped on aarch64-linux.
Ok for trunk?
Thanks,
On Wed, Aug 06, 2014 at 10:26:29AM +0200, Jakub Jelinek wrote:
Well, if you are going to implement it in fwprop AND fold-const, then the
natural place to fix that would be in *.pd on the match-and-simplify branch.
True. So I guess I'll have to put this one on hold for a while...
Marek
On Wed, 6 Aug 2014, Marek Polacek wrote:
On Tue, Aug 05, 2014 at 02:14:21PM -0600, Jeff Law wrote:
My concern is the code we're removing discusses the need to simplify when
these expressions are in static initializers. What's going to ensure that
we're still simplifying instances which
On Wed, 6 Aug 2014, Marek Polacek wrote:
On Wed, Aug 06, 2014 at 10:26:29AM +0200, Jakub Jelinek wrote:
Well, if you are going to implement it in fwprop AND fold-const, then the
natural place to fix that would be in *.pd on the match-and-simplify branch.
True. So I guess I'll have to put
On Wed, Aug 06, 2014 at 10:28:13AM +0200, Richard Biener wrote:
On Wed, 6 Aug 2014, Marek Polacek wrote:
On Wed, Aug 06, 2014 at 10:26:29AM +0200, Jakub Jelinek wrote:
Well, if you are going to implement it in fwprop AND fold-const, then the
natural place to fix that would be in *.pd on
On 05/08/14 22:29, Jeff Law wrote:
On 08/03/14 08:02, Richard Sandiford wrote:
This also fixes what I think is a bug: find_memory used to stop at the
first MEM it found. If that MEM was nonvolatile and nonconstant, we'd
return MEMREF_NORMAL even if there was another volatile MEM.
gcc/
On 06/08/14 06:54, Hale Wang wrote:
Refer to: https://gcc.gnu.org/ml/gcc-patches/2014-06/msg01429.html.
Sorry for an extra whitespace.
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of Hale Wang
Sent: 2014年8月6日 13:50
To:
On Wed, Aug 6, 2014 at 3:28 AM, tsaund...@mozilla.com wrote:
From: Trevor Saunders tsaund...@mozilla.com
hi,
just what it says on the tin.
bootstrapped + regtested on x86_64-unknown-linux-gnu, also bootstrapped on
i686-unknown-linux-gnu, ran config-list.mk, ok? gcc/
Ok.
Time to remove
On Wed, Aug 6, 2014 at 3:28 AM, tsaund...@mozilla.com wrote:
From: Trevor Saunders tsaund...@mozilla.com
hi,
just what it says on the tin.
bootstrapped + regtested on x86_64-unknown-linux-gnu, also bootstrapped on
i686-unknown-linux-gnu, ran config-list.mk, ok? gcc/
Ok.
Thanks,
Hi!
I've cleaned up the testcase some more, tested on 4.8/4.9/trunk that
it fails without the sched-deps.c fix too (both -m32 and -m64) and
works with the fix. Committed to all branches.
2014-08-06 Jakub Jelinek ja...@redhat.com
PR rtl-optimization/61801
*
The following fixes the remaining ICEs I see when testing all
languages (but ada and go).
The tree-cfg.c hunk highlights one change in the behavior
of fold_stmt, namely that it now follows SSA edges by default.
Maybe that's undesired? On a related note, fold_stmt_inplace
preserves the actual
On 5 August 2014 21:29, Siva Chandra wrote:
Hi Jonathan,
Thanks a lot for taking a look. The patch in question, and the GDB
support, do not yet work with Python3. If that is a necessary
requirement, I can make the changes and send a new version of the
patch.
Some GNU/Linux distros already
Forgot the patch~
On Wed, Aug 6, 2014 at 10:32 AM, Bin.Cheng amker.ch...@gmail.com wrote:
On Fri, Jul 25, 2014 at 8:35 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Thu, Jul 17, 2014 at 11:08 AM, Bin Cheng bin.ch...@arm.com wrote:
Hi,
As quoted from the function
On Wed, 6 Aug 2014, Richard Biener wrote:
The following fixes the remaining ICEs I see when testing all
languages (but ada and go).
The tree-cfg.c hunk highlights one change in the behavior
of fold_stmt, namely that it now follows SSA edges by default.
Maybe that's undesired? On a
On Wed, 6 Aug 2014, David Edelsohn wrote:
D'oh, there's even a predicate procedure in our test framework already to
cover it. Thanks for straightening me out, an updated patch follows.
This scores:
UNSUPPORTED: gcc.dg/pr44194-1.c
in my testing, like the previous version. OK to
Hi,
The issue was firstly observed on NDK gcc since TLS is not supported
in Android bionic. I also see the same failure on gcc configured for
linux with –disable-tls, libgomp make check log:
FAIL: libgomp.c/affinity-1.c execution test
FAIL: libgomp.c/icv-2.c execution test
FAIL:
Fixed with the following, committed. Incidentially this is the
only constant folding pattern that also applies to floats - otherwise
the use of the integer_* predicates prevent that.
Richard.
2014-08-06 Richard Biener rguent...@suse.de
* match-constant-folding.pd (minus @0 @0):
Here's a patch for the more conservative option.
- Braden Obrzut
2014-08-06 Braden Obrzut ad...@maniacsvault.net
* pt.c (check_explicit_specialization): Ensure tmpl is a function
template before checking if it is inline for COMDAT.
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index
The following fixes PR61320 - we were not properly treating
explicitely misaligned loads as misaligned.
Tested by various people on their STRICT_ALIGN targets, applied
to trunk and branch.
Richard.
2014-08-06 Richard Biener rguent...@suse.de
PR tree-optimization/61320
*
The only thing that I don't like about that, is that the user would
still have stdio.h fixed if gcc is built with sysroots older than r10.
But I guess it is not that critical :)
We still have to remove fix for compiler.h:
diff --git a/fixincludes/ChangeLog b/fixincludes/ChangeLog
index
On Wed, Aug 06, 2014 at 11:03:02AM +0100, Maciej W. Rozycki wrote:
On Wed, 6 Aug 2014, David Edelsohn wrote:
D'oh, there's even a predicate procedure in our test framework already to
cover it. Thanks for straightening me out, an updated patch follows.
This scores:
UNSUPPORTED:
On 08/03/14 17:44, Mircea Namolaru wrote:
2014-08-03 Mircea Namolarumircea.namol...@inria.fr
Replacement of isl-int by isl_val
* graphite-clast-to-gimple.c: include isl/val.h, isl/val_gmp.h
(compute_bounds_for_param): use isl_val instead of isl_int
On Tue, Aug 5, 2014 at 4:21 PM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Aug 05, 2014 at 04:17:41PM +0200, Richard Biener wrote:
what's the semantic of setting SRP_SIGNED_AND_UNSIGNED
on the subreg? That is, for the created (subreg:lhs_mode
(reg:PROMOTE_MODE of ssa N))?
Rewrite the constraint-checking code so that it doesn't instantiate
concept definitions. Instead of doing a simple constexpr evaluation on
the associated constraints, this now iterates over the decomposed
assumptions to determine satisfaction.
2014-08-06 Andrew Sutton andrew.n.sut...@gmail.com
On Wed, Aug 6, 2014 at 8:34 AM, Zhenqiang Chen
zhenqiang.c...@linaro.org wrote:
On 5 August 2014 21:59, Richard Biener richard.guent...@gmail.com wrote:
On Mon, Aug 4, 2014 at 11:09 AM, Zhenqiang Chen zhenqiang.c...@arm.com
wrote:
-Original Message-
From: Bin.Cheng
On 06/08/14 22:09, Richard Biener wrote:
On Tue, Aug 5, 2014 at 4:21 PM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Aug 05, 2014 at 04:17:41PM +0200, Richard Biener wrote:
what's the semantic of setting SRP_SIGNED_AND_UNSIGNED
on the subreg? That is, for the created (subreg:lhs_mode
On Wed, Aug 6, 2014 at 3:21 PM, Kugan kugan.vivekanandara...@linaro.org wrote:
On 06/08/14 22:09, Richard Biener wrote:
On Tue, Aug 5, 2014 at 4:21 PM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Aug 05, 2014 at 04:17:41PM +0200, Richard Biener wrote:
what's the semantic of setting
On Wed, Aug 6, 2014 at 2:47 AM, Jonathan Wakely jwakely@gmail.com wrote:
Some GNU/Linux distros already build GDB using Python3, so they will
be unable to use these xmethods.
However, I think it can be committed now and fixed later.
For the libstdc++ side, it is a very small fix (using
The following avoids recursing for popping SCCs.
LTO bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2014-08-06 Richard Biener rguent...@suse.de
PR lto/62034
* lto-streamer-in.c (lto_input_tree_1): Assert we do not read
SCCs here.
Wasn't done properly.
Committed.
Richard.
2014-08-06 Richard Biener rguent...@suse.de
* tree-ssa-forwprop.c (pass_forwprop::execute): Properly
clean EH info on folded stmts.
Index: gcc/tree-ssa-forwprop.c
===
Hi,
On Wed, Jul 30, 2014 at 06:56:05PM +0200, Martin Jambor wrote:
Hi,
IPA-CP can wreck havoc to transactional memory support as described in
the summary of the PR in bugzilla. It seems the cause is that IPA-CP
clones of nodes created by trans-mem do not have their tm_clone flag
set. For
Hi,
On Wed, Aug 6, 2014 at 4:51 AM, Alexander Ivchenko aivch...@gmail.com wrote:
We still have to remove fix for compiler.h:
Correct. Thank you.
Bruce, I think I formally have to ask for your approval again :)
I don't think so. You've selected one of the changes we wrote about,
so With
On 07/30/2014 04:56 PM, Marat Zakirov wrote:
On 07/23/2014 05:33 PM, Marat Zakirov wrote:
Hi all!
This is a friendly reminder message.
On 07/17/2014 03:22 PM, Marat Zakirov wrote:
On 07/16/2014 01:32 PM, Kyrill Tkachov wrote:
On 16/07/14 10:22, Marat Zakirov wrote:
Christophe,
Please
As discussed in the other thread, I can't just remove folding from the
C FE and implement it on GIMPLE level, because that regressed some of
those not-really-kosher static initializers. Instead, fold-const.c
has to be taught how to fold PTR0 - (PTR1 p+ A). (Now it sounds so
obvious.) I added
This is OK thanks.
Ramana
This avoids shadowing the outer ops[] array with inner ones
during code generation. This makes the results of inner
expressions disappear ... oops.
Applied.
Richard.
2014-08-06 Richard Biener rguent...@suse.de
* genmatch.c (gen_transform): Add depth parameter everywhere.
We fold stmts from non-SSA so when we simplify a single stmt
into multiple ones (like strcat (x, foo) - memcpy (x + strlen (foo),
)) then gimple_build fails because it unconditionally builds
SSA names.
Fixed.
Richard.
2014-08-06 Richard Biener rguent...@suse.de
* gimple-fold.c
$subject, applied.
Richard.
2014-08-06 Richard Biener rguent...@suse.de
* gimple-fold.h (gimple_simplify): Add two-parameter builtin
function overload.
* gimple-match-head.c (gimple_simplify): Implement it.
Index: gcc/gimple-fold.h
On Wed, 6 Aug 2014, Richard Biener wrote:
$subject, applied.
Err, too fast. Fixed.
Richard.
2014-08-06 Richard Biener rguent...@suse.de
* gimple-match-head.c (gimple_simplify): Fix implementation.
Index: gcc/gimple-match-head.c
On 06/08/14 15:14, Ramana Radhakrishnan wrote:
This is OK thanks.
Ramana
Hmm, minor nit.
(define_insn *thumb1_movhi_insn
[(set (match_operand:HI 0 nonimmediate_operand =l,l,m,*r,*h,l)
- (match_operand:HI 1 general_operand l,m,l,*h,*r,I))]
+ (match_operand:HI 1
On 08/05/2014 10:48 AM, Paolo Carlini wrote:
+ (VOID_TYPE_P (TREE_TYPE (type1))
+ || comptypes (TYPE_MAIN_VARIANT (TREE_TYPE (type0)),
+TYPE_MAIN_VARIANT (TREE_TYPE (type1)),
+
101 - 200 of 465 matches
Mail list logo
