On Fri, Jun 14, 2013 at 8:40 PM, Jason Merrill 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 comments, so
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 include in system.h, because removing it will
result in errors due to an inclusion of . It's probable
that bo
Hi,
tested x86_64-linux, committed mainline and 4_8-branch.
Thanks,
Paolo.
//
2013-06-15 Paolo Carlini
PR libstdc++/57619
* include/bits/unordered_map.h (unordered_map<>::insert,
unordered_multimap<>::insert): Use std::forward, not std::move.
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 e
On Fri, Jun 14, 2013 at 11:48 AM, "Jürgen Urban" wrote:
> Hello Richard,
>
> I updated the patch as requested.
>
>> Richard Sandiford 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
>>
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
* ggc-page.c (ggc_pch_write_object) : Remove erroneous
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
OK.
Jason
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 instrume
Hello Richard,
I updated the patch as requested.
> Richard Sandiford 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. Jürgen wants to have
On Fri, Jun 14, 2013 at 1:43 AM, Richard Biener
wrote:
> On Fri, Jun 14, 2013 at 4:52 AM, Sriraman Tallam wrote:
>> On Thu, Jun 13, 2013 at 12:40 PM, Jan Hubicka wrote:
* tree-inline.c (expand_call_inline): Allow the error to be flagged
in early inline pass.
* ip
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 mis
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
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
==
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
* decl2.c (cp_omp_mappable_type): No longer static. Handle array
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 cha
2013-06-14 Vidya Praveen
* MAINTAINERS (Write After Approval): Add myself.
Index: MAINTAINERS
===
--- MAINTAINERS (revision 200091)
+++ MAINTAINERS (working copy)
@@ -487,6 +487,7 @@
Paul Pluzhnikov
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
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_mlsl): New pattern
to support
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
>>
>> ---
>>
>>
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 ne
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
* config/aarch64/aarch64-si
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
* config/aarch64/aarch64-simd.md (*aarch64_mlal_lo):
New p
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#’
Given the usual issues with prettyprinting expressions, I think we can
sti
On Wed, Jun 12, 2013 at 11:59 PM, Sandra Loosemore
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 of doing
> accesses
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
> ad
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 };
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
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
pre
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 aroun
On Fri, Jun 14, 2013 at 10:38 AM, Alan Modra 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 wrote:
>> > The following patch fixes PR57134 by
>> > a) excluding bitfield expansion when EXPAND_MEMORY, and
>> > b) passing down t
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
On Fri, Jun 14, 2013 at 10:43:34AM +0200, Richard Biener wrote:
> On Fri, Jun 14, 2013 at 4:52 AM, Sriraman Tallam wrote:
> > On Thu, Jun 13, 2013 at 12:40 PM, Jan Hubicka wrote:
> >>> * tree-inline.c (expand_call_inline): Allow the error to be flagged
> >>> in early inline pass.
> >>
> On Fri, Jun 14, 2013 at 4:52 AM, Sriraman Tallam wrote:
> > On Thu, Jun 13, 2013 at 12:40 PM, Jan Hubicka wrote:
> >>> * tree-inline.c (expand_call_inline): Allow the error to be flagged
> >>> in early inline pass.
> >>> * ipa-inline.c (inline_always_inline_functions): Pretend
> 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
>
On Fri, Jun 14, 2013 at 4:52 AM, Sriraman Tallam wrote:
> On Thu, Jun 13, 2013 at 12:40 PM, Jan Hubicka wrote:
>>> * tree-inline.c (expand_call_inline): Allow the error to be flagged
>>> in early inline pass.
>>> * ipa-inline.c (inline_always_inline_functions): Pretend always_in
On Fri, Jun 14, 2013 at 4:31 AM, Mike Stump 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 -Wcast-qual -Wmissing-f
On Thu, Jun 13, 2013 at 10:45:38AM +0200, Richard Biener wrote:
> On Wed, Jun 12, 2013 at 4:48 AM, Alan Modra 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 where
> > t
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
39 matches
Mail list logo
