hi all,
We found that gcc would run out of memory on Windows when compiling a *big*
function (10 lines).
More investigation shows that gcc crashes at the function *compute_avail*,
in tree-fre pass. *compute_avail* collects information from basic blocks,
so memory is allocated to record infor
Ping ^ 2
OK to 4.8?
> -Original Message-
> From: Joey Ye [mailto:joey...@arm.com]
> Sent: Monday, January 20, 2014 10:47
> To: gcc-patches@gcc.gnu.org
> Subject: RE: [PATCH][4.8] Backport strict-volatile-bitfields fixes to 4.8
>
> Ping
>
> > -Original Message-
> > From: Joey Ye
Hi,
This small patch intends to add missing armv7e-m in the documentation of ARM
option -march. I will commit it to trunk and then back port to 4.7/4.8
branch as obvious.
BR,
Terry
2014-02-08 Terry Guo
* doc/invoke.texi: Document ARM -march=armv7e-m.
diff --git a/gcc/doc/invoke.texi
On Fri, Feb 07, 2014 at 04:37:22PM -0800, Richard Henderson wrote:
> >> Thoughts on how this might really be solved?
> >
> > Add a VIEW_CONVERT_EXPR around the rhs of the debug statement.
>
> Well, ok, though I'm pretty sure that the debug info will pretty much barf on
> that immediately.
Why?
On 02/07/2014 03:12 PM, Richard Biener wrote:
> On February 7, 2014 8:35:16 PM GMT+01:00, Richard Henderson
> wrote:
>> In the testcases with the PR, we have a bit of type punning going on,
>>
>> *(int *) &s2.f = 0;
>> s2 = s1;
>>
>> which SRA trasforms to
>>
>> # DEBUG s2 => 0
>> MEM[(int *)
On Thu, Feb 06, 2014 at 06:25:16PM +0100, Jan Hubicka wrote:
> > The expr.[ch]/function.h/tree-tailcall.c bits are ok.
> > I see your changes clash with my PR60077 fix, does your patch make them
> > obsolete and you take care of using proper alignment info?
> > If so, at least the two tests from th
Hi Jakub,
This should fix PR 59834
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59834) on i686-linux.
Thanks,
Balaji V. Iyer.
> -Original Message-
> From: Jakub Jelinek [mailto:ja...@redhat.com]
> Sent: Friday, February 7, 2014 6:51 PM
> To: Iyer, Balaji V; Richard Biener
> Cc:
Hi!
install_builtin calls build_fn_decl, which sets TREE_NOTHROW by default.
In most cases I think that is desirable, but __cilkrts_rethrow apparently
conditionally throws an exception, thus marking it TREE_NOTHROW is very much
undesirable and the fact that the testcase happened to work (except fo
On February 7, 2014 8:35:16 PM GMT+01:00, Richard Henderson
wrote:
>In the testcases with the PR, we have a bit of type punning going on,
>
> *(int *) &s2.f = 0;
> s2 = s1;
>
>which SRA trasforms to
>
> # DEBUG s2 => 0
> MEM[(int *)&s2] = 0;
> # DEBUG s2 => s1$f_7
> # DEBUG s2$g => s1$g_6
>
As outlined in the PR, we end up generating poor code because of the
existence of the ashldi_extsi insn in the m68k backend.
The pattern recognizes that left shifting a DImode value by 32 deposits
the low part of the input into the high part of the output and clears
the low part of the output.
On 6 February 2014 16:42:05 Jakub Jelinek wrote:
Hi!
As discussed on IRC, this patch introduces two new attributes,
so that the C library (and other headers) have a way to
a) tell the compiler something about functions like aligned_alloc
or memalign
b) tell the compiler the alignment of poi
On 02/07/14 02:17, Richard Biener wrote:
diff --git a/gcc/expr.c b/gcc/expr.c
index 878a51b..9609c45 100644
--- a/gcc/expr.c
+++ b/gcc/expr.c
@@ -7708,6 +7708,11 @@ expand_expr_addr_expr_1 (tree exp, rtx target, enum
machine_mode tmode,
modifier == EXPAND_INITIALIZER
On 02/07/14 11:20, Vladimir Makarov wrote:
The following patch improves code size for ARM. Before the patch
CSiBE size generated by GCC configured --with-arch=armv7-a
--with-fpu=vfpv3-d16 --with-float=hard (with -mthumb) was
2414926
After the patch the size is
2396798
For comparison, when
On Sat, Feb 8, 2014 at 3:06 AM, Marek Polacek wrote:
> On Sat, Feb 08, 2014 at 02:51:03AM +0530, Prathamesh Kulkarni wrote:
>> On Sat, Feb 8, 2014 at 2:22 AM, Joseph S. Myers
>> wrote:
>> > On Sat, 8 Feb 2014, Prathamesh Kulkarni wrote:
>> >
>> >> This patch removes C_EXPR_APPEND macro in c-tree
Le 07/02/2014 19:18, Paul Richard Thomas a écrit :
> Dear All,
>
> I propose to add the attached to the testsuite. It is the testcase
> from PR60066, which was fixed by the patch for PR59066.
>
> OK for trunk, 4.8 and 4.7?
>
Yes, sure.
Mikael.
On Sat, Feb 08, 2014 at 02:51:03AM +0530, Prathamesh Kulkarni wrote:
> On Sat, Feb 8, 2014 at 2:22 AM, Joseph S. Myers
> wrote:
> > On Sat, 8 Feb 2014, Prathamesh Kulkarni wrote:
> >
> >> This patch removes C_EXPR_APPEND macro in c-tree.h
> >> OK for trunk ?
> >
> > Thanks, this is OK with the or
On Sat, Feb 8, 2014 at 2:22 AM, Joseph S. Myers wrote:
> On Sat, 8 Feb 2014, Prathamesh Kulkarni wrote:
>
>> This patch removes C_EXPR_APPEND macro in c-tree.h
>> OK for trunk ?
>
> Thanks, this is OK with the orphan comment "A varray of c_expr_t." also
> removed (please send the revised patch if
On Fri, Feb 7, 2014 at 12:59 PM, Misty De Meo wrote:
> On Fri, Feb 7, 2014 at 11:09 AM, Ian Lance Taylor wrote:
>> On Fri, Feb 7, 2014 at 9:06 AM, Misty De Meo wrote:
>>> Revision 192853 added a new test for availability of _Unwind_GetIPInfo
>>> in the system unwinder to the configure script of
On Fri, Feb 7, 2014 at 11:09 AM, Ian Lance Taylor wrote:
> On Fri, Feb 7, 2014 at 9:06 AM, Misty De Meo wrote:
>> Revision 192853 added a new test for availability of _Unwind_GetIPInfo
>> in the system unwinder to the configure script of libbacktrace:
>> http://repo.or.cz/w/official-gcc.git/commi
On Sat, 8 Feb 2014, Prathamesh Kulkarni wrote:
> This patch removes C_EXPR_APPEND macro in c-tree.h
> OK for trunk ?
Thanks, this is OK with the orphan comment "A varray of c_expr_t." also
removed (please send the revised patch if you'd like someone to commit it
for you).
Although this is smal
This patch removes C_EXPR_APPEND macro in c-tree.h
OK for trunk ?
* c-parser.c (c_parser_get_builtin_args): replace calls to
C_EXPR_APPEND (cexpr_list, expr) by vec_safe_push (cexpr_list, expr)
* c-tree.h (C_EXPR_APPEND): removed
Index: gcc/c/c-parser.c
==
Le 07/02/2014 21:42, Mikael Morin a écrit :
> maybe add gcc_assert to
> make it clear that fini->proc_tree should be set at this point.
Or better: a comment ;-)
Le 06/02/2014 23:40, Janus Weil a écrit :
> Hi Mikael,
>
> thanks for your comments ...
>
>>> attached is a small patch which fixes an ICE-on-invalid regression
>>> with finalization. In the PR, Dominique objected to the patch, but I
>>> think it's the correct thing to do after all. The line that
In the testcases with the PR, we have a bit of type punning going on,
*(int *) &s2.f = 0;
s2 = s1;
which SRA trasforms to
# DEBUG s2 => 0
MEM[(int *)&s2] = 0;
# DEBUG s2 => s1$f_7
# DEBUG s2$g => s1$g_6
s2 ={v} {CLOBBER};
Note that it has chosen not to expand s1.f like s1.g, but t
On Fri, Feb 7, 2014 at 9:06 AM, Misty De Meo wrote:
> Revision 192853 added a new test for availability of _Unwind_GetIPInfo
> in the system unwinder to the configure script of libbacktrace:
> http://repo.or.cz/w/official-gcc.git/commitdiff/a4a5a77adfc9c28d6963e5ae054c997d57cfc7fa
> It was apparen
> But after all I think that the patch should not hurt. After giving it
> some second thoughts, the only alternative I could see is this:
>
> Index: gcc/fortran/resolve.c
> ===
> --- gcc/fortran/resolve.c(revision 207485)
> +++ gcc
The following patch improves code size for ARM. Before the patch
CSiBE size generated by GCC configured --with-arch=armv7-a
--with-fpu=vfpv3-d16 --with-float=hard (with -mthumb) was
2414926
After the patch the size is
2396798
For comparison, when the reload pass is used the size is
24001
cpplib-4.9-b20140202.fi.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'cpplib' has been submitted
by the Finnish team of translators. The file is available at:
http://translationproject.org/latest/cpplib/fi.po
(This file, 'cpplib-4.9-b20140202
Dear All,
I propose to add the attached to the testsuite. It is the testcase
from PR60066, which was fixed by the patch for PR59066.
OK for trunk, 4.8 and 4.7?
On 5 February 2014 12:38, pault at gcc dot gnu.org
wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60066
>
> Paul Thomas changed
On Fri, 7 Feb 2014, Andreas Krebbel wrote:
> Hi,
>
> on S/390 128 bit atomic operations are not allowed for misaligned
> operands. The expanders are supposed to FAIL in that case. While it
> works for the other routines atomic_load/store it does not work
> currently during compare and swap expa
On 02/06/14 08:37, nick clifton wrote:
Hi Jeff,
According to our coding conventions, the ability to build with something
other than gcc is still desirable. You could argue that you're unlikely
to be bootstrapping on a mn103 with something other than GCC and if
you're building a cross, you coul
On 02/06/14 13:39, Benno Schulenberg wrote:
[Oops, had a wrong bug number in the subject line.]
Below patch fixes another miswording in an error message,
reported by Roland Stigge. Please apply.
2014-02-06 Benno Schulenberg
PR translation/52289
* fortran/resolve.c (resolve_ordi
I meant to install this a week or so ago, but got sidetracked by other
more pressing issues.
Installed on the trunk as obvious.
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 5703bb5..ce9c066 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,7 @@
+2014-02-07 Jeff Law
+
+ *
On Fri, Feb 7, 2014 at 1:22 AM, Richard Biener
wrote:
> On Thu, Feb 6, 2014 at 10:30 PM, Xinliang David Li wrote:
>> Hi the following patch removes the 'state' print for
>> -ftree-tree-vectorize option which does not make sense anymore. Ok for
>> trunk?
>
> Hmm, isn't it more appropriate to remov
Revision 192853 added a new test for availability of _Unwind_GetIPInfo
in the system unwinder to the configure script of libbacktrace:
http://repo.or.cz/w/official-gcc.git/commitdiff/a4a5a77adfc9c28d6963e5ae054c997d57cfc7fa
It was apparently added to fix a bug building with GCC 4.0 on Mac OS X
10.5
> "Jakub" == Jakub Jelinek writes:
Jakub> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Ok. Thanks.
Tom
> On Fri, Feb 07, 2014 at 12:50:22AM +0100, Jan Hubicka wrote:
> > Don't we want to check opt_for_fn (node->decl, cp) instead and arrange
> > -fipa-cp
> > to be false when !optimize?
>
> I can easily imagine using
> !opt_for_fn (node->decl, optimize)
> || !opt_for_fn (node->decl, flag_ipa_cp)
> On Thu, 6 Feb 2014, Jan Hubicka wrote:
>
> > Hi,
> > at WPA we currently read trees accessed by jump functions and then copy them
> > to remove location that is already known to be UNKNOWN and then keep copying
> > them for every inline clone introduced (and there are many for firefox)
> >
> >
On Fri, Feb 07, 2014 at 02:33:41PM +, Iyer, Balaji V wrote:
> > So, the issues I see:
> > 1) what is iter.1, why do you have it at all, and, after all, the iterator
> > is a class
> > that needs to be constructed/destructed in the general way, so creating any
> > further copies of something is
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Jakub Jelinek
> Sent: Friday, February 7, 2014 9:03 AM
> To: Iyer, Balaji V
> Cc: 'Jason Merrill'; 'Jeff Law'; 'Aldy Hernandez'; 'gcc-patches@gcc.gnu.org';
> 'r...@redhat.com'
On Wed, Feb 05, 2014 at 05:27:26AM +, Iyer, Balaji V wrote:
> Attached, please find a fixed patch (diff.txt) that will do as you
> requested (model _Cilk_for like a #pragma omp parallel for). Along with this,
> I have also attached two Changelog entries (1 for C and 1 for C++).
>
On Fri, 7 Feb 2014, Jakub Jelinek wrote:
> On Fri, Feb 07, 2014 at 10:02:29AM +0100, Richard Biener wrote:
> > > + if (TREE_CODE (position) != INTEGER_CST
> > > + || TREE_INT_CST_HIGH (position)
> > > + || TREE_INT_CST_LOW (position) < 1
> > > + || TREE_INT_CST_LOW (position) > arg
On Fri, Feb 07, 2014 at 10:02:29AM +0100, Richard Biener wrote:
> > + if (TREE_CODE (position) != INTEGER_CST
> > + || TREE_INT_CST_HIGH (position)
> > + || TREE_INT_CST_LOW (position) < 1
> > + || TREE_INT_CST_LOW (position) > arg_count)
>
> You make it easier for wide-int folks i
Hi,
The below fixes some more typos in GCC's error messages.
When found okay, please apply.
2014-02-07 Benno Schulenberg
* config/arc/arc.c (arc_init): Fix typo in error message.
* config/i386/i386.c (ix86_expand_builtin): Likewise.
(split_stack_prologue_scratch_regn
On Fri, Feb 07, 2014 at 12:58:37PM +0100, Andreas Krebbel wrote:
> 2014-02-07 Andreas Krebbel
>
> * optabs.c (expand_atomic_compare_and_swap): Allow expander to
> fail.
Ok.
> --- a/gcc/optabs.c
> +++ b/gcc/optabs.c
> @@ -7383,12 +7383,13 @@ expand_atomic_compare_and_swap (rtx *pta
On Fri, Feb 07, 2014 at 02:12:44PM +0100, Andreas Krebbel wrote:
> 2014-02-07 Andreas Krebbel
>
> * gcc.dg/gcc-have-sync-compare-and-swap.c: Align the 16 byte
> variable used for atomic operations.
Ok.
> --- a/gcc/testsuite/gcc.dg/gcc-have-sync-compare-and-swap.c
> +++ b/gcc/tests
On Fri, Feb 07, 2014 at 10:33:45AM +0100, Richard Biener wrote:
> Thus like the following.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, ok for trunk
> at this stage?
>
> Thanks,
> Richard.
>
> 2014-02-07 Richard Biener
>
> PR middle-end/60092
> * gimple-low.c (lower_b
Hi,
the S/390 expanders reject operands not being naturally aligned. This
makes the gcc-have-sync-compare-and-swap.c failing.
The attached patch adds an alignment attribute to the data
type used in the check to make it succeed on S/390 again.
In the future perhaps it would be more appropriate t
Hi,
on S/390 atomic operands need to be naturally aligned. Otherwise the
instruction throws an specification exception. With the patch the
expanders reject operands not being properly aligned.
This only works if the expander code actually allows atomic expanders
to fail. This did not seem to b
Hi,
on S/390 128 bit atomic operations are not allowed for misaligned
operands. The expanders are supposed to FAIL in that case. While it
works for the other routines atomic_load/store it does not work
currently during compare and swap expansion.
The patch just turns an expand_insn into maybe_e
Hi,
there has been a ICE on solaris 9 and 10 when dumping ASM_INPUT objects
without valid source loation at print-rtl.c.
print_rtx did not check for this, and tried to print NULL with printf format %s.
This happens to be handled by glibc's printf to print "(null)" but not on
solaris.
Attached i
On Fri, Feb 7, 2014 at 11:13 AM, Uros Bizjak wrote:
>> This (should be) the last patch for AVX-512 support in v4.9.
>>
>> It improves correspondence between ICC, SDM [1], and official
>> intrinsics guide [2].
>>
>> What was done:
>> - Fixed shifts such as VPSLLD and friends. Actual instruction
On Fri, Feb 7, 2014 at 10:49 AM, Kirill Yukhin wrote:
> This (should be) the last patch for AVX-512 support in v4.9.
>
> It improves correspondence between ICC, SDM [1], and official
> intrinsics guide [2].
>
> What was done:
> - Fixed shifts such as VPSLLD and friends. Actual instruction
>
On 04/02/14 12:27, Richard Sandiford wrote:
> This patch adds return and simple_return patterns to the s390 backend,
> which eanbles shrink-wrapping and conditional returns to be used.
>
> Perhaps the only subtle thing is the handling of call-clobbered base
> registers. The idea is to emit the in
On 04/02/14 12:19, Richard Sandiford wrote:
> This patch fixes the CFA notes used when an epilogue restores a GPR from
> an FPR. It also makes sure that s390_optimize_prologue preserves the
> CFA information.
>
> Tested in the same way as the previous patch. OK to install?
>
> Thanks,
> Richard
On 04/02/14 12:14, Richard Sandiford wrote:
> s390_emit_prologue performs some optimisations on the function before
> emitting the prologue. It also rewrites constant pool accesses to make
> the base register explicit.
>
> Doing this in the prologue pattern makes the interaction with direct
> ret
On Thu, 6 Feb 2014, Richard Biener wrote:
> On Thu, 6 Feb 2014, Richard Biener wrote:
>
> >
> > This re-writes posix_memalign calls to
> >
> > posix_memalign (ptr, align, size);
> > tem = *ptr;
> > tem = __builtin_assume_aligned (align);
> > *ptr = tem;
> >
> > during C
On Fri, Feb 7, 2014 at 7:40 AM, Yury Gribov wrote:
>> As can be seen here:
>>
>> http://cbuild.validation.linaro.org/build/cross-validation/gcc/207533/report-build-info.html
>> this has caused some regressions on armv5t targets.
>
> IMHO this is expected: with this patch we prohibited unaligned lo
On Thu, Feb 6, 2014 at 10:30 PM, Xinliang David Li wrote:
> Hi the following patch removes the 'state' print for
> -ftree-tree-vectorize option which does not make sense anymore. Ok for
> trunk?
Hmm, isn't it more appropriate to remove 'Report' from ftree-vectorize
in common.opt? Or simply treat
On Thu, Feb 6, 2014 at 8:33 PM, Jeff Law wrote:
>
> expand_expr has, for as long as I can remember, had the ability to ignore
> the desired mode provided by its callers and instead returning something in
> a completely different mode. It's always been the caller's responsibility
> to deal with th
On Thu, Feb 6, 2014 at 7:56 PM, Mike Stump wrote:
> On Nov 25, 2013, at 3:09 AM, Richard Biener
> wrote:
>> please add streamer_read/write_wi () helpers to data-streamer*
>>
>> replicating the above loop N times is too ugly.
>
> Agreed. Below is the patch to collapse the code. Thanks.
Ok.
>
On Thu, 6 Feb 2014, Jakub Jelinek wrote:
> Hi!
>
> As discussed on IRC, this patch introduces two new attributes,
> so that the C library (and other headers) have a way to
> a) tell the compiler something about functions like aligned_alloc
>or memalign
> b) tell the compiler the alignment of
On Thu, 6 Feb 2014, Jakub Jelinek wrote:
> On Thu, Feb 06, 2014 at 11:00:14AM +0100, Richard Biener wrote:
> > Ah, so __builtin_setjmp_receiver is like setjmp in this regard
> > and setjmp is LEAF (it's a stmt that doesn't direct control-flow
> > anywhere else). So __builtin_setjmp_receiver shoul
On Thu, 6 Feb 2014, Jan Hubicka wrote:
> Hi,
> according to memory stats this is relatively common reason for garbage left
> after tree merging.
>
> Bootstrapped/regtested x86_64-linux, OK?
As CONSTRUCTOR_ELTS is a vec<, va_gc> please use
if (CODE_CONTAINS_STRUCT (code, TS_CONSTRUCTOR))
v
On Thu, 6 Feb 2014, Jan Hubicka wrote:
> Hi,
> at WPA we currently read trees accessed by jump functions and then copy them
> to remove location that is already known to be UNKNOWN and then keep copying
> them for every inline clone introduced (and there are many for firefox)
>
> This patch makes
On Thu, 6 Feb 2014, Jan Hubicka wrote:
> Hi,
> I did some memory measurements for Firefox. We seems in shape in exception of
> linemaps that takes about 20% of memory and I also noticed that we produce a
> lot
> of garbage by copy_tree_r. Analyzing the reasons for copy_tree_r I found two
> abo
On Fri, Feb 07, 2014 at 12:50:22AM +0100, Jan Hubicka wrote:
> Don't we want to check opt_for_fn (node->decl, cp) instead and arrange
> -fipa-cp
> to be false when !optimize?
I can easily imagine using
!opt_for_fn (node->decl, optimize)
|| !opt_for_fn (node->decl, flag_ipa_cp)
but guaranteein
68 matches
Mail list logo
