On Wed, Jun 5, 2013 at 11:40 PM, Andrew Pinski wrote:
> On Wed, Jun 5, 2013 at 12:23 PM, Jakub Jelinek wrote:
>> On Wed, Jun 05, 2013 at 11:44:07AM -0700, Andrew Pinski wrote:
>>> On Wed, Jun 5, 2013 at 10:57 AM, Marek Polacek wrote:
>>> > Comments, please?
>>> I think it might be better to do h
On Wed, Jun 5, 2013 at 6:11 PM, Xinliang David Li wrote:
> Right, except that in the context of FDO/autoFDO, where this happens
> the most (note in FDO case, it can happen with fresh profile too for
> multi-threaded programs), it is not that important to handle -- the
> mismatch path will never be
On Thu, Jun 6, 2013 at 1:21 AM, Jakub Jelinek wrote:
> On Thu, Jun 06, 2013 at 11:46:19AM +0400, Konstantin Serebryany wrote:
>> If we are going to import the ubsan run-time from LLVM's
>> projects/compiler-rt/lib/ubsan,
>> we may also need to update the contents of
>> libsanitizer/sanitizer_commo
Early *ping*.
http://gcc.gnu.org/ml/fortran/2013-06/msg00027.html
Tobias Burnus wrote:
Dear all,
Due to copying the attributes, the temporary variable could get marked
as function (attr.function, attr.flavor == FL_PROCEDURE). This either
lead to leaking those attributes into the assembler fil
Hi,
I have just backported the following revisions from to linaro/gcc-4_8-branch:
r198970 (as r199696),
r199241 (as r199700),
r198497-198500 (as r199703),
r198680 (as r199710),
r198928,198973,199203 (as r199718)
I have also merged the gcc-4_8-branch into linaro/gcc-4_8-branch up to
revision r1996
* PING *
Attached is a rediff - including the later posted additional test case
(http://gcc.gnu.org/ml/fortran/2013-05/msg00141.html)
On May 31, 2013 18:39, Tobias Burnus wrote:
This patch adds finalization support for INTENT(out) for
nonallocatable dummy arguments.
Additionally, it addres
On Thu, Jun 06, 2013 at 01:26:06AM -0700, Andrew Pinski wrote:
> On Thu, Jun 6, 2013 at 1:21 AM, Jakub Jelinek wrote:
> > On Thu, Jun 06, 2013 at 11:46:19AM +0400, Konstantin Serebryany wrote:
> >> If we are going to import the ubsan run-time from LLVM's
> >> projects/compiler-rt/lib/ubsan,
> >> w
On Thu, Jun 6, 2013 at 12:26 PM, Andrew Pinski wrote:
> On Thu, Jun 6, 2013 at 1:21 AM, Jakub Jelinek wrote:
>> On Thu, Jun 06, 2013 at 11:46:19AM +0400, Konstantin Serebryany wrote:
>>> If we are going to import the ubsan run-time from LLVM's
>>> projects/compiler-rt/lib/ubsan,
>>> we may also n
On Thu, Jun 06, 2013 at 12:41:56PM +0400, Konstantin Serebryany wrote:
> As for libstdc++, I completely agree, we don't want to depend on it,
> and we don't.
ubsan actually needs
U _ZTIN10__cxxabiv117__class_type_infoE@@CXXABI_1.3
U _ZTIN10__cxxabiv120__si_class_t
+rich...@metafoo.co.uk
On Thu, Jun 6, 2013 at 12:21 PM, Jakub Jelinek wrote:
> On Thu, Jun 06, 2013 at 11:46:19AM +0400, Konstantin Serebryany wrote:
>> If we are going to import the ubsan run-time from LLVM's
>> projects/compiler-rt/lib/ubsan,
>> we may also need to update the contents of
>> lib
On Wed, Jun 5, 2013 at 4:06 PM, Teresa Johnson wrote:
> On Wed, May 29, 2013 at 7:57 AM, Teresa Johnson wrote:
>> On Thu, May 23, 2013 at 6:18 AM, Teresa Johnson wrote:
>>> On Wed, May 22, 2013 at 2:05 PM, Teresa Johnson
>>> wrote:
Revised patch included below. The spacing of my pasted in
On Thu, Jun 6, 2013 at 12:44 PM, Jakub Jelinek wrote:
> On Thu, Jun 06, 2013 at 12:41:56PM +0400, Konstantin Serebryany wrote:
>> As for libstdc++, I completely agree, we don't want to depend on it,
>> and we don't.
>
> ubsan actually needs
> U _ZTIN10__cxxabiv117__class_type_info
On Thu, Jun 06, 2013 at 12:55:17PM +0400, Konstantin Serebryany wrote:
> > ubsan actually needs
> > U _ZTIN10__cxxabiv117__class_type_infoE@@CXXABI_1.3
> > U _ZTIN10__cxxabiv120__si_class_type_infoE@@CXXABI_1.3
> > U _ZTIN10__cxxabiv121__vmi_class_
On Thu, Jun 6, 2013 at 12:59 PM, Jakub Jelinek wrote:
> On Thu, Jun 06, 2013 at 12:55:17PM +0400, Konstantin Serebryany wrote:
>> > ubsan actually needs
>> > U _ZTIN10__cxxabiv117__class_type_infoE@@CXXABI_1.3
>> > U _ZTIN10__cxxabiv120__si_class_type_infoE@@CXXAB
Le 05/06/2013 14:49, Tobias Burnus a écrit :
> Now with attached patch.
>
> Tobias Burnus wrote:
>> I accidentally attached a slightly out-dated patch. The old patch
>> permitted CLASS<->TYPE differences in cases where the characteristic
>> had to match (e.g. dummy arguments in a proc-pointer assi
Hi,
The patch enhance prepare_shrink_wrap by doing copyprop for the entry
block. This exposes more opportunities for shrink-wrapping. These
kinds of copies often occur when incoming argument registers are moved
to call-saved registers because their values are live across one or
more calls during
Hi!
I pushed the following two obvious patches to trunk:
commit 6731634deb51e8aebd43b7fc34fe8330d6a0edba
Author: tschwinge
Date: Thu Jun 6 10:04:34 2013 +
libgomp/
* config/posix/ptrlock.h: Fix comment.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@199724
138bc75d-
[Resending with less text/html]
On Thu, Jun 6, 2013 at 1:55 AM, Konstantin Serebryany
wrote:
> On Thu, Jun 6, 2013 at 12:44 PM, Jakub Jelinek wrote:
> > On Thu, Jun 06, 2013 at 12:41:56PM +0400, Konstantin Serebryany wrote:
> >> As for libstdc++, I completely agree, we don't want to depend on it
On 06/06/2013 02:07 AM, Jakub Jelinek wrote:
Jason, does
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3675.html#1457
apply just to C++11/C++14, or to C++03 too?
The committee hasn't said anything about which DRs since C++03 apply to
it. I take the position that most do, but not th
On Thu, Jun 6, 2013 at 11:55 AM, Zhenqiang Chen wrote:
> The patch enhance prepare_shrink_wrap by doing copyprop for the entry
> block. This exposes more opportunities for shrink-wrapping. These
> kinds of copies often occur when incoming argument registers are moved
> to call-saved registers bec
On 05/06/13 17:49, Kyrylo Tkachov wrote:
Hi all,
This patch restricts predication for the various atomics patterns in
sync.md by using the new predicable_short_it mechanism. The load/store
exclusive and the acquire/release instructions cannot be contained
inside IT blocks in ARMv8 so the logic b
On 05/06/13 17:58, Kyrylo Tkachov wrote:
Hi all,
ARMv8-style IT blocks don't allow load/store multiple instructions (ldm,
stm), so this patch disables the predicable forms of the corresponding
patterns. The ldm/stm patterns are generated through an Ocaml script,
which is updated to reflect the n
This shrinks LTO_tree_pickle_reference and all LTO headers by
using uhwi streaming instead of fixed-size streaming for
streamer_write_hwi_in_range/streamer_read_hwi_in_range.
LTO_tree_pickle_reference are the most issued records so it's
worth optimizing its placement so it can use a 1 byte record.
On 29/05/13 18:15, Meador Inge wrote:
Hi All,
This patch fixes a bug in one of the ARM peephole2 optimizations. The
peephole2 optimization in question was changed to use the CC-updating
form for all of the instructions produced by the peephole so that the
encoding will be smaller when compiling
The C++11/C++14 undefined behavior of left signed shift can be tested
similarly, if ((unsigned type for op0's type) op0) >> (precm1 - y)
is greater than one, then it is undefined behavior.
Jason, does
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/
n3675.html#1457
apply just to C++11/C+
On Thu, Jun 06, 2013 at 03:26:19PM +0200, Segher Boessenkool wrote:
> >The C++11/C++14 undefined behavior of left signed shift can be tested
> >similarly, if ((unsigned type for op0's type) op0) >> (precm1 - y)
> >is greater than one, then it is undefined behavior.
> >Jason, does
> >http://www.open
Hi all,
This patch updates the fixed-point math patterns in arm-fixed.md to
conform to new IT block rules in ARMv8. The add/sub instructions can be
placed in an IT block if they use the low registers.
The other more exotic variants (ssub, uqadd etc) do not have 16-bit
encodings and can therefore n
There's a well-known benchmark which uselessly likes to declare local
variables as static. There exist at least two implementations to demote
these to normal register variables. See the discussion thread here:
http://gcc.gnu.org/ml/gcc-patches/2008-07/msg00982.html
These days, however, we can ski
On 2013-06-05 14:34 , Brooks Moses wrote:
I've tested the adjusted line-stripping parts of the refactored code
by adding and removing spaces in lines in my xfails file and
confirming that things are still correctly matched.
Is this refactoring also OK to commit?
Ah, thanks. That's a bette
Hi,
On Tue, Jun 04, 2013 at 05:19:02PM -0700, Dehao Chen wrote:
> attached is a testcase that would cause problem when source has changed:
>
> $ g++ test.cc -O2 -fprofile-generate -DOLD
> $ ./a.out
> $ g++ test.cc -O2 -fprofile-use
> test.cc:34:1: internal compiler error: in operator[], at vec.h:
On Thu, Jun 6, 2013 at 4:11 PM, Martin Jambor wrote:
> Hi,
>
> On Tue, Jun 04, 2013 at 05:19:02PM -0700, Dehao Chen wrote:
>> attached is a testcase that would cause problem when source has changed:
>>
>> $ g++ test.cc -O2 -fprofile-generate -DOLD
>> $ ./a.out
>> $ g++ test.cc -O2 -fprofile-use
>>
As the test case shows, it can happen (-fcheck=bounds) that se.pre has a
value. Hence, the patch removes se.pre from the assert and adds the pre
block to the block.
Build, regtested and committed (Rev. 199736) on x86-64-gnu-linux.
Tobias
2013-06-06 Tobias Burnus
PR fortran/57542
* trans.
On Thu, Jun 6, 2013 at 3:42 PM, Bernd Schmidt wrote:
> There's a well-known benchmark which uselessly likes to declare local
> variables as static. There exist at least two implementations to demote
> these to normal register variables. See the discussion thread here:
> http://gcc.gnu.org/ml/gcc
On 06/05/2013 04:01 PM, Jonathan Wakely wrote:
On 5 June 2013 20:18, Ed Smith-Rowland wrote:
Greetings,
This patch implements quoted string manipulators for C++14.
27.7.6 - Quoted manipulators[quoted.manip].
The idea is to allow round trip insert and extract of strings with spaces.
On 06/06/13 14:36, Kyrylo Tkachov wrote:
Hi all,
This patch updates the fixed-point math patterns in arm-fixed.md to
conform to new IT block rules in ARMv8. The add/sub instructions can be
placed in an IT block if they use the low registers.
The other more exotic variants (ssub, uqadd etc) do no
The attached test case failed with an ICE for function result variables
as in that case the function decl was used.
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
Other pending patches:
* 4.8/4.9 regression with defined assignment:
http://gcc.gnu.org/ml/fortran/2013-06/msg00047.ht
On 06/06/2013 04:52 PM, Richard Biener wrote:
> + /* We cannot optimize away a static used in multiple functions (as
> +might happen in C++). */
> + && !DECL_NONLOCAL(var)
>
> it may also happen trivially with inlining. Which means a local pass can
> never
> "remove" vars safe
Hi, Martin,
Yes, your patch can fix my case. Thanks a lot for the fix.
With the fix, value profiling will still promote the wrong indirect
call target. Though it will not be inlining, but it results in an
additional check. How about in check_ic_target, after calling
gimple_check_call_matching_typ
On Thu, Jun 6, 2013 at 5:10 PM, Bernd Schmidt wrote:
> On 06/06/2013 04:52 PM, Richard Biener wrote:
>> + /* We cannot optimize away a static used in multiple functions (as
>> +might happen in C++). */
>> + && !DECL_NONLOCAL(var)
>>
>> it may also happen trivially with inlining.
Add new libitm failures to x86_64-grtev3-linux-gnu.xfail.
Okay for google/gcc-4_8? google/main? Thanks.
Index: contrib/testsuite-management/x86_64-grtev3-linux-gnu.xfail
===
--- contrib/testsuite-management/x86_64-grtev3-linux-gnu
On 2013-06-06 11:33 , Simon Baldwin wrote:
Add new libitm failures to x86_64-grtev3-linux-gnu.xfail.
Okay for google/gcc-4_8? google/main? Thanks.
OK.
Diego.
This patch addresses the following FAILs on armv6-m:
FAIL: g++.sum:g++.old-deja/g++.jason/thunk2.C -std=gnu++11 execution test
FAIL: g++.sum:g++.old-deja/g++.jason/thunk2.C -std=gnu++98 execution test
The source of the problem is the use of ARM thunk offsets for Thumb1.
This test is using mu
Hi, I'm finally going through the current code on the branch, sorry for
the delay.
* gcc/system.h (cstdlib): Include to avoid poisoned
declaration errors.
Poisoned declarations of what? This seems redundant with the #include
just below.
+ /* Concepts-related keywords *
On Wed, Jun 5, 2013 at 12:13 PM, Michael Meissner
wrote:
> On Wed, Jun 05, 2013 at 10:28:02AM -0400, David Edelsohn wrote:
>> +;; The canonical form is to have the negated elment first, so we need to
>> +;; reverse arguments.
>>
>> Please fix the typo in the comment: "element".
>
> Ok. I need to
On 06/06/13 16:43, Cesar Philippidis wrote:
This patch addresses the following FAILs on armv6-m:
FAIL: g++.sum:g++.old-deja/g++.jason/thunk2.C -std=gnu++11 execution test
FAIL: g++.sum:g++.old-deja/g++.jason/thunk2.C -std=gnu++98 execution test
The source of the problem is the use of ARM
On 31/05/13 18:57, Eric Botcazou wrote:
Hi,
as diagnosed by Doug, the VxWorks port cannot be built since:
2011-05-18 Joseph Myers
which reorganized the ARM options and turned arm_fp16_format from a global
variable defined in arm.c into an option variable, leading to:
In file included from
Hi all,
The constraint for iordi3_insn should take into account that we don't
have an orr instruction to deal with inverted immediate in ARM mode, but
we do in Thumb2 mode (orn). I had tried to reuse the De
constraint from the anddi3 case, but that's not appropriate in all
cases, causing an ICE in
Hi all,
This patch cleans up the anddi3_insn pattern by removing duplicate
alternatives and redundant attribute setters.
It also restricts the splitting to after reload and when we know that
we're not using the NEON versions.
Tested arm-none-eabi on qemu.
Ok for trunk?
Thanks,
Kyrill
2013-06-0
On 31/05/13 18:59, Eric Botcazou wrote:
The ARM/VxWorks port uses APCS frames and therefore ip to establish frames
with a frame pointer. Now, for nested functions, ip is also the static chain
register so it needs to be preserved when the frame is being established.
There is code to that effect
gimple_check_call_matching_types is called by check_ic_target. Instead
of moving the check out of this guard function, may be enhancing the
interface to allow it to guard with different strictness?
David
On Thu, Jun 6, 2013 at 8:10 AM, Dehao Chen wrote:
> Hi, Martin,
>
> Yes, your patch can fix
On Thu, Jun 6, 2013 at 7:11 AM, Martin Jambor wrote:
> Hi,
>
> On Tue, Jun 04, 2013 at 05:19:02PM -0700, Dehao Chen wrote:
>> attached is a testcase that would cause problem when source has changed:
>>
>> $ g++ test.cc -O2 -fprofile-generate -DOLD
>> $ ./a.out
>> $ g++ test.cc -O2 -fprofile-use
>>
On 06/06/2013 08:02 AM, Richard Earnshaw wrote:
> (define_insn "add3"
> - [(set (match_operand:FIXED 0 "s_register_operand" "=r")
> -(plus:FIXED (match_operand:FIXED 1 "s_register_operand" "r")
> -(match_operand:FIXED 2 "s_register_operand" "r")))]
> + [(set (match_operand:FIXED
On 06/06/13 17:26, Richard Henderson wrote:
On 06/06/2013 08:02 AM, Richard Earnshaw wrote:
(define_insn "add3"
- [(set (match_operand:FIXED 0 "s_register_operand" "=r")
-(plus:FIXED (match_operand:FIXED 1 "s_register_operand" "r")
-(match_operand:FIXED 2 "s_register_operand"
On 06/06/13 17:08, Kyrylo Tkachov wrote:
Hi all,
The constraint for iordi3_insn should take into account that we don't
have an orr instruction to deal with inverted immediate in ARM mode, but
we do in Thumb2 mode (orn). I had tried to reuse the De
constraint from the anddi3 case, but that's not
Hello!
This patch avoids ABI check failure on alpha.
2013-06-06 Uros Bizjak
* config/abi/post/alpha-linux-gnu/baseline_symbols.txt: Update.
Tested on alphaev68-pc-linux-gnu.
OK for mainline?
Uros.
Index: config/abi/post/alpha-linux-gnu/baseline_symbols.txt
=
Committed as Rev. 199746 to the GCC 4.7 branch.
Tobias
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog (Revision 199745)
+++ gcc/fortran/ChangeLog (Arbeitskopie)
@@ -1,3 +1,12 @@
+2013-06-06 Tobias Burnus
+
+ Backport f
Hi Jason,
Thanks for the comments. I just went ahead and fixed all the editorial
issues. Comments and questions below:
>> * gcc/system.h (cstdlib): Include to avoid poisoned
>> declaration errors.
>
> Poisoned declarations of what? This seems redundant with the #include
> just
On 06/06/2013 08:11 AM, Richard Earnshaw wrote:
> I understand (and agree with) this bit...
>
>> +(define_peephole2
>> + [(set (reg:CC CC_REGNUM)
>> +(compare:CC (match_operand:SI 0 "register_operand" "")
>> +(match_operand:SI 1 "arm_rhs_operand" "")))
>> + (cond_exec (ne (reg:
This patch:
2013-05-31 Kaushik Phatak
* config/rl78/rl78.md (mulqi3,mulhi3): New define_expands.
(*mulqi3_rl78,*mulhi3_rl78,*mulhi3_g13): New define_insns.
Uses a "U" constraint which isn't defined in rl78/constraints.md
What should that constraint do? Could you post
The default for the max instructions in peeled loops was reduced on
trunk in r193570. This is causing a performance regression on an internal
benchmark. This change will revert to the old higher limits.
Google ref b/8839137.
Bootstrapped and tested. Ok for google/4_8?
Thanks,
Teresa
2013-06-06
On 2013-06-06 16:22 , Teresa Johnson wrote:
The default for the max instructions in peeled loops was reduced on
trunk in r193570. This is causing a performance regression on an internal
benchmark. This change will revert to the old higher limits.
Google ref b/8839137.
Bootstrapped and tested. O
On 06/06/2013 01:47 PM, Andrew Sutton wrote:
I never did understand why this happens. Compiling with GCC-4.6, I get
these errors originating in logic.cc from an include of .
This is what I get:
/usr/include/c++/4.6/cstdlib:76:8: error: attempt to use poisoned "calloc"
Ah, I see: adding the inc
We should make the default setting right for our environment. The
patch is trivial to maintain.
thanks,
David
On Thu, Jun 6, 2013 at 1:26 PM, Diego Novillo wrote:
> On 2013-06-06 16:22 , Teresa Johnson wrote:
>>
>> The default for the max instructions in peeled loops was reduced on
>> trunk in
ok. Wht is the rational for dropping the limit in trunk? Ideally,
the limit should be lifted up and to enable other heuristics to kick
in.
David
On Thu, Jun 6, 2013 at 1:22 PM, Teresa Johnson wrote:
> The default for the max instructions in peeled loops was reduced on
> trunk in r193570. This
On 05/24/2013 01:00 AM, Paolo Carlini wrote:
On 05/23/2013 10:01 PM, François Dumont wrote:
Some feedback regarding this patch ?
Two quick ones: what if the hint is wrong? I suppose the insertion
succeeds anyway, it's only a little waste of time, right?
Right.
Is it possible that for instanc
The following patch fixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57459
The bug occurs in case of rare combination when insn uses inherited and
original value, the pseudo is input and output and the pseudo value (as
insn result) is unused.
The patch was successfully bootstrapped and test
Hi,
committed to mainline.
Thanks,
Paolo.
//
2013-06-06 Paolo Carlini
PR c++/43652
* g++.dg/parse/error53.C: New.
Index: g++.dg/parse/error53.C
===
--- g++.dg/parse/error53.C (revision 0)
++
The following patch fixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57468
The patch actually restore the LRA behaviour for x86/x86-64 before rev.
199298. The revision was added for PPC SDmode value correct
generation. So it is really needed for PPC64 and badly hurts x86/x86-64
performance
I checked in the tests that went with power8 patches #3 and #4 (which have been
committed) as subversion id 199768.
2013-06-06 Michael Meissner
Pat Haugen
Peter Bergner
* gcc.target/powerpc/p8vector-builtin-1.c: New test to test
power8 builtin function
On Thu, Jun 6, 2013 at 1:33 PM, Xinliang David Li wrote:
> ok. Wht is the rational for dropping the limit in trunk? Ideally,
> the limit should be lifted up and to enable other heuristics to kick
> in.
Here is the message about it from Honza:
http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01193
On Tue, Jun 04, 2013 at 11:45:12PM +0930, Alan Modra wrote:
> This patch allows the user to specify -mfp-in-toc/-msum-in-toc options
> without being overridden when -fsection-anchors or -mcmodel != small
> is in effect. I also change the default to -mno-fp-in-toc for
> -mcmodel=medium, because -mc
> From: Jan Hubicka
> Date: Wed, 5 Jun 2013 16:18:52 +0200
> * class.c (emit_register_classes_in_jcr_section): Use DECL_PRESERVE_P
> instead of mark_decl_referenced.
>
> * decl2.c (maybe_make_one_only): Use forced_by_abi instad of
> mark_decl_referenced.
>
This fixes a bug where cfgexpand would ICE when using far pointers,
because the SImode pointers weren't "valid" with the default macro.
Committed.
* config/rl78/rl78.c (rl78_valid_pointer_mode): New, implements
TARGET_VALID_POINTER_MODE.
Index: gcc/config/rl78/rl78.c
Hi,
this issue seems just another case of:
http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02472.html
thus we are ICEing because TYPE_STUB_DECL is null and we want to use
TYPE_MAIN_DECL.
Tested x86_64-linux.
Thanks,
Paolo.
///
/cp
2013-06-07 Paolo Carlini
On Thu, Jun 6, 2013 at 7:40 PM, Alan Modra wrote:
> On Tue, Jun 04, 2013 at 11:45:12PM +0930, Alan Modra wrote:
>> This patch allows the user to specify -mfp-in-toc/-msum-in-toc options
>> without being overridden when -fsection-anchors or -mcmodel != small
>> is in effect. I also change the defa
> The patch actually restore the LRA behaviour for x86/x86-64 before rev.
> 199298. The revision was added for PPC SDmode value correct generation. So it
> is really needed for PPC64 and badly hurts x86/x86-64 performance (by doing
> secondary memory reloads when one pseudo is spilled).
Bootstrapped and regression tested powerpc64-linux. OK to apply?
* src/powerpc/linux64_closure.S (ffi_closure_LINUX64): Support
little-endian.
* src/powerpc/ppc_closure.S (ffi_closure_SYSV): Likewise.
Index: libffi/src/powerpc/linux64_closure.S
===
Hello,
Is this OK for trunk? It involves very few changes (the patch is cut
and pasted below) and does not cause any bootstrap issues on my x86_64 running
SuSE.
Thanks,
-Balaji V. Iyer.
> -Original Message-
> From: Iyer, Balaji V
> Sent: Monday, June 03, 2013 8:44 PM
> To: gcc
force_const_mem() isn't supposed to handle VOIDmode or BLKmode, so the
check for VOIDmode when aligning is needless. If we ever did get one
of these modes in a constant pool, this
pool->offset += GET_MODE_SIZE (mode);
won't add to the pool size, and output_constant_pool_2() will hit a
gcc_unre
OK.
Jason
A while back I noticed an error-recovery issue with fields of incomplete
type: later references to such fields would give an error that the name
was undeclared, which is not the case. This patch improves that situation.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit cf2d44c5b95890d6b7de
I recently implemented capture of C++14 VLAs, but the VLA in this
testcase is not valid C++14, so capturing it isn't supported. But we
still shouldn't ICE.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit c0ecc17471e7859ba36f3f8d095e5666e525f84f
Author: Jason Merrill
Date: Thu Jun 6 22
On Thu, Jun 6, 2013 at 9:34 PM, Alan Modra wrote:
> Bootstrapped and regression tested powerpc64-linux. OK to apply?
>
> * src/powerpc/linux64_closure.S (ffi_closure_LINUX64): Support
> little-endian.
> * src/powerpc/ppc_closure.S (ffi_closure_SYSV): Likewise.
This patch
ping...
On Tue, Jun 4, 2013 at 10:02 AM, Dehao Chen wrote:
> Hi, Dodji,
>
> Thanks for helping update the patch. The new patch passed all
> regression test and can fix the problem in my huge source file. I
> added ChangeLog entry to the patch. Could any libcpp maintainers help
> check if it is ok
I've prepared a patch check for args for indirect call value profiling.
Testing on-going. Is it ok for trunk if testing is good?
Thanks,
Dehao
gcc/ChangeLog:
2013-06-06 Dehao Chen
* tree-flow.h (gimple_check_call_matching_types): Add new argument.
* gimple-low.c (gimple_check
On Tue, Apr 02, 2013 at 02:05:13PM +1030, Alan Modra wrote:
> suspicious. For instance, you might wonder why it is correct to have
> if (decl && !DECL_P (decl))
> decl = NULL_TREE;
> before calling get_section(). The answer is that get_section() is not
> prepared to handle !DECL_P trees whe
This one should be submitted and discussed in trunk.
thanks,
David
On Thu, Jun 6, 2013 at 9:39 PM, Dehao Chen wrote:
> I've prepared a patch check for args for indirect call value profiling.
>
> Testing on-going. Is it ok for trunk if testing is good?
>
> Thanks,
> Dehao
>
> gcc/ChangeLog:
> 20
I stumbled over this while looking at regressions triggered when moving
certain branch-cost driven transformations from fold-const.c to a later
point in the pipeline.
The coalescing we do as part of the out-of-ssa process restricts itself
to only coalescing when the types of the underlying o
88 matches
Mail list logo
