On Wed, 2 Jul 2014, Andrey Turetskiy wrote:
> > * Don't duplicate the logic for what's a hosted POSIX system; refactor it
> > to a common fragment in config/ (I guess it needs to be a shell script
> > fragment there rather than an actual autoconf macro, since you're using
> > that logic in configu
Just a small clean-up in preparation for the FOR_EACH_SUBRTX patches.
insn_contains_asm can be tested more directly using extract_asm_operands,
which doesn't involve any subcalls and should therefore be more efficient
than calling for_each_rtx.
Tested on x86_64-linux-gnu. OK to install?
Thanks,
I think this should fix it.
Applying to trunk.
commit 939c2c7101765c2ac83c85871fa38cc2278a2e18
Author: Jason Merrill
Date: Wed Jul 30 17:19:23 2014 -0400
PR lto/53808
PR c++/61659
* pt.c (push_template_decl_real): Don't set DECL_COMDAT on friends.
diff --git a/gcc/cp/pt.c b/g
On 07/30/2014 04:44 PM, Jason Merrill wrote:
Why not do this in cp_parser_id_expression?
I did mention this in the original mail, is this definitely the way it
should be done? Andrew pointed this out to me before sending in the
patch, my initial investigation into doing so seemed to show it w
On Jul 22, 2014, at 12:14 PM, Mike Stump wrote:
> On Jul 22, 2014, at 4:01 AM, Kyrill Tkachov wrote:
>> These tests use very large arrays as part of their loop interchange testing
>> so they don't fit into the 1MiB binary size limit imposed by -mcmodel=tiny.
>> This causes errors at link-time.
Hi
Now that patch on testsuite allocator is in I would like to
reactivate this one. Here it is again.
See previous answer below regarding modification of
_M_begin/_M_cbegin.
2014-07-30 François Dumont
PR libstdc++/29988
* include/bits/stl_tree.h (_Rb_tree_reu
Jiong Wang writes:
> + /* If we have
> +
> +(ior (lshiftrt A imm1) (and (ashiftrt (A imm2)) mask))
> +
> + where imm1 = imm2 + 1
> +mask = ((1 << imm1) - 1) << (mode_size (A) - imm1)
> +
> + then we may simplify this into
> +
> +(ashiftrt A imm1).
> +
> +
On Mon, 7 Jul 2014, Sylvestre Ledru wrote:
> Hello,
>
> On 17/06/2014 19:41, Joseph S. Myers wrote:
> > On Tue, 17 Jun 2014, Sylvestre Ledru wrote:
> >
> >> OK. I will do that.
> >> We should test the following:
> >> * default => run just -Wreturn-type
> >> * -Wreturn-type => Run both
> >> * -Wr
On 07/30/2014 11:24 PM, Tom Tromey wrote:
>> "Chen" == Chen Gang writes:
>
> Chen> I shall stop making this kind of patch, next. The reason is that I worry
> Chen> about what I have done have negative effect to others. And next, I shall
> Chen> try to send another kinds of patches for gcc whe
On Thu, 24 Jul 2014, Chen Gang wrote:
> strlen() will get string length excluding '\0', but strcpy() will append
> '\0' in the end, so need XNEWVEC additional byte, or cause memory over
> flow.
OK assuming it passed regression testing (with ChangeLog entry as usual,
and you need to say what plat
On 07/30/2014 11:32 PM, Andrew Haley wrote:
> On 07/30/2014 04:01 PM, Chen Gang wrote:
>> I shall stop making this kind of patch, next. The reason is that I worry
>> about what I have done have negative effect to others. And next, I shall
>> try to send another kinds of patches for gcc when I have
On 07/31/2014 06:12 AM, Joseph S. Myers wrote:
> On Thu, 24 Jul 2014, Chen Gang wrote:
>
>> strlen() will get string length excluding '\0', but strcpy() will append
>> '\0' in the end, so need XNEWVEC additional byte, or cause memory over
>> flow.
>
> OK assuming it passed regression testing (wit
On Thu, 31 Jul 2014, Chen Gang wrote:
> On 07/31/2014 06:12 AM, Joseph S. Myers wrote:
> > On Thu, 24 Jul 2014, Chen Gang wrote:
> >
> >> strlen() will get string length excluding '\0', but strcpy() will append
> >> '\0' in the end, so need XNEWVEC additional byte, or cause memory over
> >> flow.
On Thu, 3 Jul 2014, Adhemerval Zanella wrote:
> + /* Generates the equivalent of feclearexcept (FE_ALL_EXCEPT):
> +
> + double fenv_clear = __builtin_mffs ();
> + *(uint64_t)&fenv_clear &= 0xLL;
> + __builtin_mtfsf (0xff, fenv_clear); */
> +
> + /* Mask to clear ever
On 07/31/2014 06:29 AM, Joseph S. Myers wrote:
> On Thu, 31 Jul 2014, Chen Gang wrote:
>
>> On 07/31/2014 06:12 AM, Joseph S. Myers wrote:
>>> On Thu, 24 Jul 2014, Chen Gang wrote:
>>>
strlen() will get string length excluding '\0', but strcpy() will append
'\0' in the end, so need XNE
On Tue, Jul 29, 2014 at 10:56 AM, Peter Bergner wrote:
> ..after cleaning up the conflicting long double builtins and fixing a
> few bugs in the test cases, I'd like to resubmit the following:
>
> Currently, the IBM long double routines in libgcc use a union to construct
> a long double from two d
On Tue, Jul 29, 2014 at 5:33 PM, Andrew Dixie wrote:
> Hi,
>
> The following patch moves dwarf unwind information from the data
> section to the read-only/text section on AIX. This means the memory
> for the unwind information can be shared across multiple processes.
>
> The frame tables are stil
Hi David,
On Thu, Jul 31, 2014 at 2:22 PM, David Edelsohn wrote:
> As the comment in the code states DWARF2 unwind info was placed in the
> data section to prevent the AIX linker from garbage collecting it.
> How are you avoiding that problem?
That comment is very old. I'm not sure what the ori
On 07/30/14 16:29, Joseph S. Myers wrote:
On Thu, 31 Jul 2014, Chen Gang wrote:
On 07/31/2014 06:12 AM, Joseph S. Myers wrote:
On Thu, 24 Jul 2014, Chen Gang wrote:
strlen() will get string length excluding '\0', but strcpy() will append
'\0' in the end, so need XNEWVEC additional byte, or c
On 07/30/14 08:23, Andi Kleen wrote:
From: Andi Kleen
gcc/:
2014-07-30 Andi Kleen
* ipa-devirt.c (polymorphic_call_target_hasher::hash):
Convert to inchash.
OK once hashinc namespace is approved.
jeff
On 07/30/14 08:23, Andi Kleen wrote:
From: Andi Kleen
gcc/:
2014-07-29 Andi Kleen
* tree-ssa-sccvn.c (vn_reference_op_compute_hash): Convert to
inchash.
(vn_reference_compute_hash): Dito.
(vn_nary_op_compute_hash): Dito.
(vn_phi_compute_hash): Dito.
On 07/30/14 08:23, Andi Kleen wrote:
From: Andi Kleen
gcc/:
2014-07-30 Andi Kleen
* asan.c (asan_mem_ref_hasher::hash): Convert to inchash.
OK once inchash namespace changes are approved.
jeff
On 07/30/14 08:23, Andi Kleen wrote:
From: Andi Kleen
Convert dwarf2out and rtl.c to the new inchash interface.
I moved the rtl hash code to another file to avoid having to link
all the hash code into the generator functions.
v2: Removed ??? comment.
gcc/:
2014-07-29 Andi Kleen
On 07/30/14 08:23, Andi Kleen wrote:
From: Andi Kleen
Change class inchash to move into a inchash namespace as requested.
The class is now inchash::hash
Rename iterative_hstate_expr to inchash::add_expr
... and convert existing users. It wasn't possible to use hash::,
because that lead to name
On 07/30/14 15:26, Richard Sandiford wrote:
Just a small clean-up in preparation for the FOR_EACH_SUBRTX patches.
insn_contains_asm can be tested more directly using extract_asm_operands,
which doesn't involve any subcalls and should therefore be more efficient
than calling for_each_rtx.
Tested
On 07/30/14 09:20, Bingfeng Mei wrote:
Yes, that fix is better. Here are updated patches. LTO-bootstrapped and tested.
OK?
Bingfeng
Index: ChangeLog
===
--- ChangeLog (revision 213152)
+++ ChangeLog (working copy)
@@ -1,3 +1,1
On 2014.07.30 at 17:31 -0400, Jason Merrill wrote:
> I think this should fix it.
Indeed it does. Thanks.
--
Markus
On 07/30/14 09:01, Chen Gang wrote:
Hello All:
I shall stop making this kind of patch, next. The reason is that I worry
about what I have done have negative effect to others. And next, I shall
try to send another kinds of patches for gcc when I have time.
Many persons or companies use open sour
On 07/29/14 02:35, Richard Biener wrote:
The following fixes the second bug you'll hit very fast when writing
testcases for -ftrapv (maybe not so often in "real" scenarios). There
are several places in the optimization pipeline where after constant
folding we fail to generate trapping instructi
On 07/31/2014 11:09 AM, Jeff Law wrote:
> On 07/30/14 16:29, Joseph S. Myers wrote:
>> On Thu, 31 Jul 2014, Chen Gang wrote:
>>
>>> On 07/31/2014 06:12 AM, Joseph S. Myers wrote:
On Thu, 24 Jul 2014, Chen Gang wrote:
> strlen() will get string length excluding '\0', but strcpy() will
On 06/19/14 14:52, Tom Tromey wrote:
Tom> I've edited this one down by removing the auto-generated stuff , and
Tom> then compressed it.
Here's a new version of patch #5.
I've removed the generated code; let's see if it gets through without
compression.
I think this addresses all the reviews:
*
On 07/30/14 08:34, Yury Gribov wrote:
On 07/18/2014 05:38 PM, Jakub Jelinek wrote:
Do you error out on -fsanitize=thread -fsanitize=kernel-address ?
Perhaps -fsanitize=kernel-address -fsanitize=address should be
invalid too?
Yes, all these combinations are invalid.
But you don't error out on
On 07/22/14 03:03, Marc Glisse wrote:
I note you don't catch return &localvar in the isolation code -- it
looks like you just catch those which potentially flow from PHIs.
I thought I was handling it in the find_explicit_erroneous_behaviour
part of the patch (as opposed to the implicit part whi
On 07/30/14 05:54, Marc Glisse wrote:
On Tue, 29 Jul 2014, David Malcolm wrote:
On Tue, 2014-07-29 at 19:36 +0200, Marc Glisse wrote:
On Sun, 27 Jul 2014, Richard Sandiford wrote:
Marc Glisse writes:
Hello,
I followed the advice in this discussion:
https://gcc.gnu.org/ml/gcc-patches/2014-
On 07/28/14 16:39, David Wohlferd wrote:
On 7/28/2014 12:42 PM, Jeff Law wrote:
On 07/27/14 01:26, David Wohlferd wrote:
I'm not sure which maintainer to cc for inline asm stuff?
I have a release on file with the FSF, but don't have SVN write access.
Problem:
extract_insn() in recog.c will I
On 07/31/2014 12:10 PM, Jeff Law wrote:
> On 07/30/14 09:01, Chen Gang wrote:
>> Hello All:
>>
>> I shall stop making this kind of patch, next. The reason is that I worry
>> about what I have done have negative effect to others. And next, I shall
>> try to send another kinds of patches for gcc wh
Could you please advise me how is it better to answer the following
questions of Sven:
> In what way is it "not optimal"?
> That is, what are your optimality criteria?
(I could answer them, but I don't want to miss anything)
--
Cheers, Roman Gareev.
Now that GCC 4.9 branch is opened again and GCC 4.8 branch still open, is the
following backported patch ok for both branches?
Best regards,
Thomas
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
> Sent
101 - 138 of 138 matches
Mail list logo
