On Fri, 14 Jun 2013, Jan Hubicka wrote:
Ok, not streaming and comparing TREE_USED gets it improved to
I will try to gather better data tomorrow. My mozilla build died on disk
space,
but according to stats we are now at about 7GB of GGC memory after merging.
I was playing with
On Thu, Jun 13, 2013 at 10:45:38AM +0200, Richard Biener wrote:
On Wed, Jun 12, 2013 at 4:48 AM, Alan Modra amo...@gmail.com wrote:
The following patch fixes PR57134 by
a) excluding bitfield expansion when EXPAND_MEMORY, and
b) passing down the EXPAND_MEMORY modifier in a couple of places
On Fri, Jun 14, 2013 at 4:31 AM, Mike Stump mikest...@comcast.net wrote:
When doing a -j16 build of top of the trunk from a little while ago, with our
wide-int patches in it, I hit:
g++ -c -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables
-W -Wall -Wwrite-strings
On Fri, Jun 14, 2013 at 4:52 AM, Sriraman Tallam tmsri...@google.com wrote:
On Thu, Jun 13, 2013 at 12:40 PM, Jan Hubicka hubi...@ucw.cz wrote:
* tree-inline.c (expand_call_inline): Allow the error to be flagged
in early inline pass.
* ipa-inline.c
On Fri, 14 Jun 2013, Jan Hubicka wrote:
Ok, not streaming and comparing TREE_USED gets it improved to
I will try to gather better data tomorrow. My mozilla build died on disk
space,
but according to stats we are now at about 7GB of GGC memory after
merging.
I was
On Fri, Jun 14, 2013 at 4:52 AM, Sriraman Tallam tmsri...@google.com wrote:
On Thu, Jun 13, 2013 at 12:40 PM, Jan Hubicka hubi...@ucw.cz wrote:
* tree-inline.c (expand_call_inline): Allow the error to be flagged
in early inline pass.
* ipa-inline.c
On Fri, Jun 14, 2013 at 10:43:34AM +0200, Richard Biener wrote:
On Fri, Jun 14, 2013 at 4:52 AM, Sriraman Tallam tmsri...@google.com wrote:
On Thu, Jun 13, 2013 at 12:40 PM, Jan Hubicka hubi...@ucw.cz wrote:
* tree-inline.c (expand_call_inline): Allow the error to be flagged
in
On Fri, Jun 14, 2013 at 08:18:19AM +0930, Alan Modra wrote:
On Thu, Jun 13, 2013 at 05:42:17PM +0200, Jakub Jelinek wrote:
On Fri, Jun 14, 2013 at 01:07:01AM +0930, Alan Modra wrote:
@@ -5774,10 +5818,11 @@ offsettable_ok_by_alignment (rtx op, HOST_WIDE_INT
type = TREE_TYPE (decl);
On Fri, Jun 14, 2013 at 10:38 AM, Alan Modra amo...@gmail.com wrote:
On Thu, Jun 13, 2013 at 10:45:38AM +0200, Richard Biener wrote:
On Wed, Jun 12, 2013 at 4:48 AM, Alan Modra amo...@gmail.com wrote:
The following patch fixes PR57134 by
a) excluding bitfield expansion when EXPAND_MEMORY,
Alan Modra wrote:
On Wed, Jun 12, 2013 at 04:22:46PM +0100, Tejas Belagod wrote:
From the IR above, it seems that result of widening the high part
(vect__12.6_40) is being stored at offset 0 from _29 and result of
widening the low part goes into *(_29 + 16). Shouldn't this be the
other way
Hi,
As reported in pr57540, gcc chooses bad address mode, resulting in A)
invariant part of address expression is not kept or hoisted; b) additional
computation which should be encoded in address expression. The reason is
when gcc runs into addr+offset (which is invalid) during expanding, it
On Fri, Jun 14, 2013 at 10:59:52AM +0200, Jakub Jelinek wrote:
On Fri, Jun 14, 2013 at 08:18:19AM +0930, Alan Modra wrote:
It is handling !DECL_P trees, which must be local. I know I saw
STRING_CST here when I wrote offsettable_ok_by_alignment, hence the
use of CONSTANT_ALIGNMENT. I'm not
On Fri, Jun 14, 2013 at 08:12:02PM +0930, Alan Modra wrote:
As for the
typedef int vec_align __attribute__ ((vector_size(16), aligned(32)));
vec_align x = { 0, 0, 0, 0 };
Le 13/06/2013 19:56, Tobias Burnus a écrit :
Mikael Morin wrote:
This fixes the problem, but shouldn't the fix be in gfc_expr_attr
instead?
I tried it - but it does not work: In many case, one actually needs a
function, e.g. for procedure pointers or for C_FUNLOC. Thus, I had to
add an
On Wed, Jun 12, 2013 at 11:59 PM, Sandra Loosemore
san...@codesourcery.com wrote:
Background: on ARM and some other targets, the ABI requires that volatile
bit-fields be accessed atomically in a mode that corresponds to the declared
type of the field, which conflicts with GCC's normal behavior
Hi,
maybe we can resolve this one too, it remained assigned to me too much time.
Currently the diagnostic is completely broken:
cannot apply ‘offsetof’ to member function ‘#‘indirect_ref’ not
supported by dump_decl#declaration error’
Given the usual issues with prettyprinting expressions, I
Hello,
This patch adds support to SMLAL/SMLSL/UMLAL/UMLSL instructions and adds tests
for the same. Regression test run for aarch64-none-elf with no regressions.
OK?
~VP
---
gcc/ChangeLog
2013-06-14 Vidya Praveen vidyaprav...@arm.com
* config/aarch64/aarch64-simd.md
On 14/06/13 14:55, Vidya Praveen wrote:
Hello,
This patch adds support to SMLAL/SMLSL/UMLAL/UMLSL instructions and adds tests
for the same. Regression test run for aarch64-none-elf with no regressions.
OK?
~VP
---
gcc/ChangeLog
2013-06-14 Vidya Praveen vidyaprav...@arm.com
*
On Fri, Jun 14, 2013 at 12:54:40PM +0200, Jakub Jelinek wrote:
On Fri, Jun 14, 2013 at 08:12:02PM +0930, Alan Modra wrote:
I see your point, but for there to be a real problem we'd need
a) A library exporting such a type with (supposed) increased
alignment, and,
b) gcc would need to
On 14/06/13 15:33, Marcus Shawcroft wrote:
On 14/06/13 14:55, Vidya Praveen wrote:
Hello,
This patch adds support to SMLAL/SMLSL/UMLAL/UMLSL instructions and adds
tests
for the same. Regression test run for aarch64-none-elf with no regressions.
OK?
~VP
---
gcc/ChangeLog
2013-06-14
On 14/06/13 16:01, Richard Earnshaw wrote:
On 14/06/13 15:33, Marcus Shawcroft wrote:
On 14/06/13 14:55, Vidya Praveen wrote:
[...]
to support SMLAL/UMLAL instructions for 64 bit vector modes.
* config/aarch64/aarch64-simd.md (*aarch64_sumlslmode): New pattern
to
First: I did another trunk to branch merge (Revision 200091).
Dominique Dhumieres wrote:
The failures for coarray_lib_alloc_2.f90 and coarray_lib_alloc_3.f90 are fixed
with the followin patch:
I think that's a bug in the compiler (on the branch). A derived type
without any components should
2013-06-14 Vidya Praveen vidyaprav...@arm.com
* MAINTAINERS (Write After Approval): Add myself.
Index: MAINTAINERS
===
--- MAINTAINERS (revision 200091)
+++ MAINTAINERS (working copy)
@@ -487,6 +487,7 @@
Paul
On 06/14/2013 06:31 AM, Richard Biener wrote:
I think we can split the patch up, so let me do piecewise approval of changes.
The changes that remove the packedp flag passing around and remove
the warning code are ok. The store_bit_field_1 change is ok, as is
the similar extract_bit_field_1
Hi!
This patch improves cp_omp_mappable_type, fixes reference to pointer based
array sections, and diagnoses if map/to/from clauses don't have decls
or array sections with mappable type.
2013-06-14 Jakub Jelinek ja...@redhat.com
* decl2.c (cp_omp_mappable_type): No longer static.
Hey guys,
The documentation states that the return types on the x86
__builtin_ia32_cmp*s builtins are integer vectors. This is
inconsistent with the source. These builtins actually return floating
point vectors. Here is a small patch to update the documentation.
-Cameron
Index: doc/extend.texi
This gccgo patch from Rémy Oudompheng fixes unsafe.Offsetof applied to a
field in an embedded struct. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline and 4.8 branch.
Ian
diff -r ea256b8b5c75 go/expressions.cc
--- a/go/expressions.cc Wed Jun 12 15:27:10 2013
On Fri, 2013-06-14 at 00:08 +0100, James Greenhalgh wrote:
I see only minor cosmetic differences (Placement of labels,
numbering of labels) between the two generated assembly files.
Perhaps you could share the flags you were using and I can try to
figure out which paths I seem to be
On Fri, Jun 14, 2013 at 1:43 AM, Richard Biener
richard.guent...@gmail.com wrote:
On Fri, Jun 14, 2013 at 4:52 AM, Sriraman Tallam tmsri...@google.com wrote:
On Thu, Jun 13, 2013 at 12:40 PM, Jan Hubicka hubi...@ucw.cz wrote:
* tree-inline.c (expand_call_inline): Allow the error to be
Hello Richard,
I updated the patch as requested.
Richard Sandiford rdsandif...@googlemail.com writes:
I can't approve the Makefile.in bits. I've cc'ed Ian, who's the libgcc
maintainer. Ian: the problem is that _muldi3.o on 64-bit targets
is actually an implementation of __multi3.
This patch is needed mainly for ubsan, but since it is an independent
change, I'd like to get this one into trunk. It adds proper parsing of the
-fsanitize= option, currently -fsanitize=thread and -fsanitize=address
are hardcoded in common.opt. It allows user to specify what exactly
to
OK.
Jason
I'm committing this as an obvious fix to a thinko on my part. The problem was
I didn't think about the case where quad memory instructions were available,
but not VSX instructions. The quad memory support was added to the VSX
implementation of movti for 64-bit, but it wasn't added to the non-VSX
ggc_pch_write_object's parameter d is marked with ATTRIBUTE_UNUSED,
but in fact it is used in 4 places at the end of the function.
Successfully bootstrapped on x86_64-unknown-linux-gnu.
OK for trunk?
2013-06-14 David Malcolm dmalc...@redhat.com
* ggc-page.c (ggc_pch_write_object) d:
On Fri, Jun 14, 2013 at 11:48 AM, Jürgen Urban juergenur...@gmx.de wrote:
Hello Richard,
I updated the patch as requested.
Richard Sandiford rdsandif...@googlemail.com writes:
I can't approve the Makefile.in bits. I've cc'ed Ian, who's the libgcc
maintainer. Ian: the problem is that
Patch didn't survive a kernel lto build. LTO test cases are tricky as usual,
but I can give you a objdir
or core file if you want.
-Andi
/backup/lsrc/git/linux-lto-2.6/lib/decompress_unlzo.c:79:8: internal compiler
error: in expand_expr_real_1, at expr.c:9361
parse += 7;
^
0x5e87d5
Hi,
tested x86_64-linux, committed mainline and 4_8-branch.
Thanks,
Paolo.
//
2013-06-15 Paolo Carlini paolo.carl...@oracle.com
PR libstdc++/57619
* include/bits/unordered_map.h (unordered_map::insert,
unordered_multimap::insert): Use
1. tree_template_info still contains constraint_info. That will change
in a subsequent patch. I'm kind of waiting for specializations to get
TEMPLATE_DECLs.
Makes sense.
2. I left the cstdlib include in system.h, because removing it will
result in errors due to an inclusion of algorithm. It's
On Fri, Jun 14, 2013 at 8:40 PM, Jason Merrill ja...@redhat.com wrote:
+// \Gamma, P |- Delta\Gamma, Q |- \Delta
Are the \ for TeX markup or something? You're missing one on the left Delta
here.
yes, I think the backslash was for LaTeX, but we get warnings about having
backslash in
39 matches
Mail list logo
