2013/6/19 Jeff Law :
>
> * gcc.dg/tree-ssa/forwprop-28.c: New test.
>
In the gnu coding standard we have a space before
the open-parentheses. Would that be great to have
testcase follow this convention as well? :)
If so, then...
>
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/forwprop-28
The change also affects vectorizer in avx case which could be seen for
gcc.dg/tree-ssa/loop-19.c test.
After the change report says
loop-19_bad.c:16: note: === vect_analyze_data_refs_alignment ===
loop-19_bad.c:16: note: vect_compute_data_ref_alignment:
loop-19_bad.c:16: note: can't force alignme
On Wed, Jun 19, 2013 at 11:01:59AM +0400, Igor Zamyatin wrote:
> The change also affects vectorizer in avx case which could be seen for
> gcc.dg/tree-ssa/loop-19.c test.
>
> After the change report says
>
> loop-19_bad.c:16: note: === vect_analyze_data_refs_alignment ===
> loop-19_bad.c:16: note:
On Wed, Jun 19, 2013 at 03:02:38PM +0800, Chung-Ju Wu wrote:
> In the gnu coding standard we have a space before
> the open-parentheses. Would that be great to have
> testcase follow this convention as well? :)
>
> If so, then...
Testcases generally don't need to follow the coding conventions,
t
Right, as you did for other cases. It works here as well.
Thanks,
Igor
On Wed, Jun 19, 2013 at 11:05 AM, Jakub Jelinek wrote:
> On Wed, Jun 19, 2013 at 11:01:59AM +0400, Igor Zamyatin wrote:
>> The change also affects vectorizer in avx case which could be seen for
>> gcc.dg/tree-ssa/loop-19.c t
2013/6/19 Jakub Jelinek :
> On Wed, Jun 19, 2013 at 03:02:38PM +0800, Chung-Ju Wu wrote:
>> In the gnu coding standard we have a space before
>> the open-parentheses. Would that be great to have
>> testcase follow this convention as well? :)
>>
>> If so, then...
>
> Testcases generally don't need
On Wed, Jun 19, 2013 at 11:12:21AM +0400, Igor Zamyatin wrote:
> Right, as you did for other cases. It works here as well.
Patch preapproved.
Jakub
As reported by Andi the following trivial fix fixes the ICE.
Committed as obvious.
Richard.
2013-06-19 Richard Biener
* expr.c (expand_expr_real_1): Use SCOPE_FILE_SCOPE_P to check
for global context.
Index: gcc/expr.c
===
On Tue, 18 Jun 2013, Andi Kleen wrote:
> On Tue, Jun 18, 2013 at 08:04:15PM +0200, Andi Kleen wrote:
> > > Just confirmed with the small build. It does. Running the large build
> > > now.
> >
> > Large build worked too.
>
> Also it seems to be drastically faster. I haven't done a proper
> meas
On Tue, Jun 18, 2013 at 10:45:53PM +, Joseph S. Myers wrote:
> On Tue, 18 Jun 2013, Jakub Jelinek wrote:
>
> > On Tue, Jun 18, 2013 at 04:42:51PM +0200, Marek Polacek wrote:
> > > Ok, should be done now (together with other nit-fixes).
> > > Regtested/bootstrapped on x86_64-linux, ok for trunk
2013/6/18 Sebastian Huber :
> Hello Chung-Ju,
>
>
> On 06/18/2013 05:12 AM, Chung-Ju Wu wrote:
>>
>> 2013/6/18 David Edelsohn :
>>>
>>> gcc/testsuite/ChangeLog
>>> 2013-06-17 Sebastian Huber
>>>
>>> PR target/55033
>>> * gcc.target/powerpc/pr55033.c: Fix options.
>>>
>>> Okay.
>>>
>>> Thanks, Da
On Wed, Jun 19, 2013 at 9:22 AM, Jakub Jelinek wrote:
> On Wed, Jun 19, 2013 at 11:12:21AM +0400, Igor Zamyatin wrote:
>> Right, as you did for other cases. It works here as well.
>
> Patch preapproved.
I wonder how much code breaks these days when we enable -fno-common by
default? ...
Richard.
On Wed, Jun 19, 2013 at 10:38:47AM +0200, Richard Biener wrote:
> On Wed, Jun 19, 2013 at 9:22 AM, Jakub Jelinek wrote:
> > On Wed, Jun 19, 2013 at 11:12:21AM +0400, Igor Zamyatin wrote:
> >> Right, as you did for other cases. It works here as well.
> >
> > Patch preapproved.
>
> I wonder how mu
On Tue, Jun 18, 2013 at 10:25 PM, Jakub Jelinek wrote:
> On Tue, Jun 18, 2013 at 04:42:51PM +0200, Marek Polacek wrote:
>> Ok, should be done now (together with other nit-fixes).
>> Regtested/bootstrapped on x86_64-linux, ok for trunk?
>
> Looks good to me, the only thing I'm worried about are how
On Wed, Jun 19, 2013 at 10:45:28AM +0200, Richard Biener wrote:
> Btw, how to handle the issue with LTO and different -fsanitize options
> at compile vs. link-time? Can TUs without -fsanitize options be LTO
> linked with -fsanitize? Then lto-wrapper should union -fsanitize
> options from all TUs
... I have no committed this simple doc update. Also, a 4_8-branch
version, attached below.
Thanks,
Paolo.
2013-06-19 Paolo Carlini
PR c++/56544
* doc/cpp.texi [Standard Predefined Macros, __cplusplus]: Document
that now in C++ the value is corre
> The following patch removed pool_range/neg_pool_range attributes from
> several instructions as a cleanup, which I believe to have been
> incorrect:
>
> http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01036.html
>
> On a Mentor-local branch, this caused problems with instructions like:
>
> (insn
Am 19.06.2013 01:50, schrieb Ian Lance Taylor:
> This patch to gccgo changes the representation of values of function
> type. They used to be a pointer to function code, like a C function
> pointer. They are now a pointer to a struct. The first field of the
> struct points to the function code.
This templates the pointer-map implementation (actually it copies
the implementation, leaving the old interface unchanged) providing
a templated value type. That's suitable to replace the various
users requesting a pointer-to-integer-type map, like I noticed
for the two LTO tree recording mechani
> I don't see how a target hook is required for the command-line idea.
> Targets already have a perfectly working way of changing the default
> of a command-line option.
That's true.. sorry, my bad.
Anyway, could somebody take a look at the patch itself?
--Alexander
>> 2013/4/23 Alexander Ivc
On 18/06/13 15:47, Sofiane Naci wrote:
Hi,
This patch updates the documentation for "type" attribute. It complements
the changes proposed in the previous patch
OK for trunk?
-
Thanks
Sofiane=
OK.
Am 27.11.2012 19:14, schrieb Meador Inge:
> On 11/26/2012 09:05 AM, Richard Biener wrote:
>
>> On Wed, Nov 7, 2012 at 10:51 PM, Meador Inge
>> wrote:
>>> Ping ^ 4.
>>
>> Ok.
>
> Thanks for the review. Committed to trunk.
This did break gcc-ar and gcc-nm; now a regression on the 4.8 branch.
$
On Wed, Jun 19, 2013 at 02:03:34PM +0200, Matthias Klose wrote:
> Am 27.11.2012 19:14, schrieb Meador Inge:
> > On 11/26/2012 09:05 AM, Richard Biener wrote:
> >
> >> On Wed, Nov 7, 2012 at 10:51 PM, Meador Inge
> >> wrote:
> >>> Ping ^ 4.
> >>
> >> Ok.
> >
> > Thanks for the review. Committed
On 18/06/13 19:06, Steven Bosscher wrote:
> BTW I don't understand how a label satisfying the following can be
> true for a label before a jump table:
>
> if (LABEL_P (insn)
> && (LABEL_PRESERVE_P (insn) || LABEL_NAME (insn)))
>
> LABEL_PRESERVE_P should never be set on a label be
Am 19.06.2013 14:03, schrieb Matthias Klose:
> $ gcc-ar-4.8 -h
> gcc-ar-4.8: Cannot find plugin 'liblto_plugin.so'
>
> the plugin is *not* installed with x permission flags (which seems to be the
> standard for shared libraries). You did change the code to use find_a_file
> which searches only f
On 18/06/13 17:22, Meador Inge wrote:
Ping.
On 06/06/2013 01:23 PM, Meador Inge wrote:
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" "")
+
On Wed, 19 Jun 2013, Richard Biener wrote:
>
> This templates the pointer-map implementation (actually it copies
> the implementation, leaving the old interface unchanged) providing
> a templated value type. That's suitable to replace the various
> users requesting a pointer-to-integer-type map,
On Fri, Jun 7, 2013 at 3:22 PM, Pat Haugen wrote:
> This patch adds instruction scheduling support for the Power8 processor.
> Bootstrap/regression test with no new failures. Ok for trunk?
>
>
> 2013-06-07 Michael Meissner
> Pat Haugen
> Peter Bergner
>
> * config/rs6000/p
On Wed, Jun 19, 2013 at 6:08 AM, Jeff Law wrote:
>
> The notable changes since the last version:
>
> First, it should properly handle signed single bit types, though I haven't
> tested it with real code.
>
> Second, the transformation is only applied when the result is used in a
> conditional. Th
On Wed, Jun 19, 2013 at 2:19 AM, Matthias Klose wrote:
>
> so this did change the soname for libgo to 5 on the trunk, and to 4 on the
> branch. We had this discussion before, and then decided to revert this kind
> of
> change on the 4.7 branch. This time the release notes had a hint that the Go
> -Original Message-
> From: Steve Ellcey [mailto:sell...@mips.com]
> Sent: 14 June 2013 19:07
>
> With my version the compiler calls gimple_duplicate_sese_region from
> duplicate_blocks 60 times. With your patch it calls
> gimple_duplicate_sese_region from duplicate_thread_path 16 times.
Hi!
If say /usr/bin/gcc-ar doesn't find /usr//bin/ar (and a few others),
it gives up unless CROSS_DIRECTORY_STRUCTURE, while e.g. collect2 looks for
ld, nm etc. in $PATH. The collect2.c snippet is:
/* Search the compiler directories for `ld'. We have protection against
recursive calls in
Hi,
when I implemented Core/1123 "Destructors should be noexcept by
default", unfortunately I caused this regression, present now in
mainline and 4_8-branch.
When the destructor is user provided, with no exception specifications,
and the type has data members (not bases, those are already Ok
On 06/19/2013 01:02 AM, Chung-Ju Wu wrote:
2013/6/19 Jeff Law :
* gcc.dg/tree-ssa/forwprop-28.c: New test.
In the gnu coding standard we have a space before
the open-parentheses. Would that be great to have
testcase follow this convention as well? :)
If so, then...
No reason not t
On 06/18/2013 12:27 PM, Andrew Sutton wrote:
There was a bug in instantiation_dependent_expr_r that would cause
trait expressions like __is_class(int) to be marked as type dependent.
It was always testing the 2nd operand, even for unary traits
(NULL_TREE turns out to be type dependent).
I fixed
Am 19.06.2013 15:20, schrieb Jakub Jelinek:
> Here is so far untested attempt to do that in gcc-{ar,nm,ranlib} too, ok if
> bootstrap/regtest passes and testing shows it works (for 4.8 too, in 4.7 it
> worked)?
works for me, checked with a 4.8 native build and install.
Matthias
On Wed, Jun 19, 2013 at 03:20:33PM +0200, Jakub Jelinek wrote:
> Hi!
>
> If say /usr/bin/gcc-ar doesn't find /usr//bin/ar (and a few others),
> it gives up unless CROSS_DIRECTORY_STRUCTURE, while e.g. collect2 looks for
> ld, nm etc. in $PATH. The collect2.c snippet is:
Looks good. Thanks for fi
I.e. the arguments after your patch are exactly swapped. This is usually
harmless, but not always, so that should be corrected before check in.
The change in cselib.c:cselib_invalidate_mem has the same problem.
Well, I have already committed the patch, so attached is a patch to fix
things up.
L
On Tue, Jun 18, 2013 at 10:02 PM, Oleg Endo wrote:
> On Tue, 2013-06-18 at 18:09 +0800, Bin.Cheng wrote:
>> On Tue, Jun 18, 2013 at 3:52 AM, Oleg Endo wrote:
>> >
>> > My observation is, that legitimizing addressing modes in the backend by
>> > looking at one isolated address works, but doesn't g
A 2011 change to collect2 to use the standard diagnostics
infrastructure broke collect2's cleanup of temp files when an error
occurs. This prototype of a patch implements the minimal conversion
of collect2 to use atexit().
If this is the right direction, all calls to collect_exit() can be
convert
(Re-sending to the proper list. Sorry for the noise at gcc@.)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57643
The HTM fastpath didn't handle a situation in which a relaxed
transaction executed unsafe code that in turn starts a transaction; it
simply tried to wait for the "other" transaction, no
> Especially if it is -O0 only, I don't see why you think so. Just dg-skip-if
> it for -O1+ if you believe it is unreliable for some reason, but if you
> look at the parameter value after the prologue, not showing the right value
> at -O0 would be a serious bug everywhere. Having some GDB testcas
Am 19.06.2013 14:10, schrieb Jakub Jelinek:
> On Wed, Jun 19, 2013 at 02:03:34PM +0200, Matthias Klose wrote:
>> Am 27.11.2012 19:14, schrieb Meador Inge:
>>> On 11/26/2012 09:05 AM, Richard Biener wrote:
>>>
On Wed, Nov 7, 2012 at 10:51 PM, Meador Inge
wrote:
> Ping ^ 4.
On Wed, 2013-06-19 at 16:57 +0200, Torvald Riegel wrote:
> (Re-sending to the proper list. Sorry for the noise at gcc@.)
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57643
>
> The HTM fastpath didn't handle a situation in which a relaxed
> transaction executed unsafe code that in turn starts a
On Wed, 2013-06-19 at 10:49 -0500, Peter Bergner wrote:
> This is due to the following in _ITM_inTransaction():
>
> 47 if (tx && (tx->nesting > 0))
> (gdb) p tx
> $2 = (GTM::gtm_thread *) 0x10901bf0
> (gdb) p tx->nesting
> $3 = 1
> (gdb) step
> 49 if (tx->state & gtm_thread::STATE_IR
On 19 June 2013 15:57, Jeff Law wrote:
> On 06/19/2013 01:02 AM, Chung-Ju Wu wrote:
>>
>> 2013/6/19 Jeff Law :
>>>
>>>
>>> * gcc.dg/tree-ssa/forwprop-28.c: New test.
>>>
>>
>> In the gnu coding standard we have a space before
>> the open-parentheses. Would that be great to have
>> testca
>> +// If the types of the underlying templates match, compare
>> +// their constraints. The declarations could differ there.
>> +if (types_match)
>> + types_match = equivalent_constraints (get_constraints
>> (olddecl),
>> +
On 06/18/13 16:37:04, Gary Funck wrote:
> The initialization function is currently generated in tree form in the
> usual way (it will be gimplified when the gimple pass is run).
>
> The code that is being generated is roughly equivalent to:
>
> static void
> __upc_init_decls (void)
>
On Wed, 19 Jun 2013, Joern Rennecke wrote:
> > I.e. the arguments after your patch are exactly swapped. This is usually
> > harmless, but not always, so that should be corrected before check in.
> > The change in cselib.c:cselib_invalidate_mem has the same problem.
>
> Well, I have already commi
On Jun 19, 2013, at 1:44 AM, Jakub Jelinek wrote:
> On Wed, Jun 19, 2013 at 10:38:47AM +0200, Richard Biener wrote:
>> On Wed, Jun 19, 2013 at 9:22 AM, Jakub Jelinek wrote:
>>> On Wed, Jun 19, 2013 at 11:12:21AM +0400, Igor Zamyatin wrote:
Right, as you did for other cases. It works here as
On Jun 19, 2013, at 1:38 AM, Richard Biener wrote:
> On Wed, Jun 19, 2013 at 9:22 AM, Jakub Jelinek wrote:
>> On Wed, Jun 19, 2013 at 11:12:21AM +0400, Igor Zamyatin wrote:
>>> Right, as you did for other cases. It works here as well.
>>
>> Patch preapproved.
>
> I wonder how much code breaks t
Hello Everyone,
This patch will replace the array sizes in array notation test suite
functions from a hard-coded value to a #defined one. The main reason for doing
this is that it will get easier in future if I want to experiment with
different array sizes. In some cases this change was
Steven and Richard,
I saw the email about the s390 switch statement
http://gcc.gnu.org/ml/gcc-patches/2013-06/msg01026.html
and tested this patch on MIPS to see if using NEXT_INSN instead of
next_real_insn fixed PR 56942. It did, so is this the right long
term fix for MIPS? Is it OK to
On Wed, 19 Jun 2013, David Edelsohn wrote:
> A 2011 change to collect2 to use the standard diagnostics
> infrastructure broke collect2's cleanup of temp files when an error
> occurs. This prototype of a patch implements the minimal conversion
> of collect2 to use atexit().
>
> If this is the rig
On 06/19/2013 10:02 AM, Bernhard Reutner-Fischer wrote:
On 19 June 2013 15:57, Jeff Law wrote:
On 06/19/2013 01:02 AM, Chung-Ju Wu wrote:
2013/6/19 Jeff Law :
* gcc.dg/tree-ssa/forwprop-28.c: New test.
In the gnu coding standard we have a space before
the open-parentheses. Wo
This is bug that triggers on m68k. The loop unroller creates a MULT
expression and tries to force it into a register, which causes a libcall
to be generated. Since args are pushed we create a
(use (mem (plus virtual_outgoing_args scratch)))
in CALL_INSN_FUNCTION_USAGE. Since we're past vregs, the
On Wed, Jun 19, 2013 at 05:29:42PM +0200, Matthias Klose wrote:
> well, I did fix this assumption last year in gcc.c, then lets fix it in other
> places too, just adding a mode parameter to the public find_a_file function.
> Testing the attached patch.
Ok, provided you:
1) write proper ChangeLog
2
On Wed, Jun 19, 2013 at 6:36 PM, Steve Ellcey wrote:
> Steven and Richard,
>
> I saw the email about the s390 switch statement
>
> http://gcc.gnu.org/ml/gcc-patches/2013-06/msg01026.html
>
> and tested this patch on MIPS to see if using NEXT_INSN instead of
> next_real_insn fixed PR 56942.
Hello,
sorry, but this patch was intended for review on the rtems-devel list.
This patch should not go into GCC at this point.
On 18/06/13 21:04, Rempel, Cynthia wrote:
Hi,
Forwarding this patch to gcc-patches...
Cheers!
Cindy
From: rtems-devel-boun
"Steve Ellcey " writes:
> 2013-06-19 Steve Ellcey
>
> PR target/56942
> * config/mips/mips.md (casesi_internal_mips16_):
> Use NEXT_INSN instead of next_real_insn.
OK, thanks.
Richard
Richard Sandiford writes:
> Vladimir Makarov writes:
>> Index: lra.c
>> ===
>> --- lra.c(revision 199753)
>> +++ lra.c(working copy)
>> @@ -306,11 +306,11 @@ lra_emit_add (rtx x, rtx y, rtx z)
>>|| (disp != NULL_RTX &
On Wed, 2013-06-19 at 14:19 +0100, James Greenhalgh wrote:
> Please let me know if this fixes the performance issues you
> were seeing and if you have any other comments.
>
> FWIW I've bootstrapped and regression tested this version of
> the patch on x86_64 and ARM with no regressions.
>
> Thank
On 13-06-19 1:23 AM, Wei Mi wrote:
Ping.
On Wed, Jun 12, 2013 at 2:44 PM, Wei Mi wrote:
Hi,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57518
pr57518 happened because update_equiv_regs in IRA marked a reg
equivalent with a mem, lowered its mem_cost in scan_one_insn, set
NO_REGS to its rclass
On 13-06-19 2:31 PM, Richard Sandiford wrote:
Richard Sandiford writes:
Vladimir Makarov writes:
Index: lra.c
===
--- lra.c (revision 199753)
+++ lra.c (working copy)
@@ -306,11 +306,11 @@ lra_emit_add (rtx x, rtx y,
Patch preapproved. Jakub
Hi,
Checked into trunk: http://gcc.gnu.org/ml/gcc-cvs/2013-06/msg00646.html
Thanks, K
On Wed, 2013-06-19 at 10:57 -0500, Peter Bergner wrote:
> On Wed, 2013-06-19 at 10:49 -0500, Peter Bergner wrote:
> > This is due to the following in _ITM_inTransaction():
> >
> > 47if (tx && (tx->nesting > 0))
> > (gdb) p tx
> > $2 = (GTM::gtm_thread *) 0x10901bf0
> > (gdb) p tx->nesting
> >
Vladimir Makarov writes:
> On 13-06-19 2:31 PM, Richard Sandiford wrote:
>> Richard Sandiford writes:
>>> Vladimir Makarov writes:
Index: lra.c
===
--- lra.c (revision 199753)
+++ lra.c (working copy)
@@ -
On Wed, Jun 19, 2013 at 8:27 AM, Tobias Burnus wrote:
>> Attached patch initializes return variable in get_fpu_except_flags.
>> Additionally, it uses __asm__ and __volatile__ consistently, as
>> recommended for header files and unifies a bunch of formatting issues
>> throughout the file.
>
>
> OK
Still no chance to have a look ?
I think that that patch is a really safe one. Those that do not use
hint won't be impacted. Those that are already using it without any
reason might experiment a small performance issue if they found the way
to always use the worst possible hint.
Fran
Quoting Michael Matz :
That's not good. You now have different order of parameters between
anti_dependence and canon_anti_dependence. That will be mightily
confusing, please instead change the caller. Currently these predicates
take their arguments in the order of the corresponding instructio
> Patch preapproved.
Checked into 4.8 branch:
http://gcc.gnu.org/ml/gcc-cvs/2013-06/msg00648.html
Thanks, K
On 06/17/2013 06:02 PM, Sandra Loosemore wrote:
I had another thought: perhaps -fstrict-volatile-bitfields could remain
the default on targets where it currently is, but it can be overridden
by an appropriate -std= option. Perhaps also GCC could give an error if
-fstrict-volatile-bitfields is
Am 19.06.2013 19:46, schrieb Jakub Jelinek:
> On Wed, Jun 19, 2013 at 05:29:42PM +0200, Matthias Klose wrote:
>> well, I did fix this assumption last year in gcc.c, then lets fix it in other
>> places too, just adding a mode parameter to the public find_a_file function.
>> Testing the attached patc
On 06/19/13 09:26:30, Gary Funck wrote:
> The variable declaration tree node looks about right to me.
> However, it never makes it into the output assembler file.
>
> What is the recommended method for making sure that the
> static variable created above is associated with the current
> translatio
Should the patch be ported to in 48 branch?
thanks,
David
On Wed, Jun 19, 2013 at 11:46 AM, Vladimir Makarov wrote:
> On 13-06-19 1:23 AM, Wei Mi wrote:
>>
>> Ping.
>>
>> On Wed, Jun 12, 2013 at 2:44 PM, Wei Mi wrote:
>>>
>>> Hi,
>>>
>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57518
>>>
>>
In Go it is not valid to use unsafe.Offsetof with a reference to an
embedded field that is accessed via an embedded pointer, because there
is no reasonable answer to return in that case. Unfortunately gccgo was
returning bogus results for that case. This patch from Rémy Oudompheng
fixes it to ret
Yes, I think so.
Regards,
Wei.
On Wed, Jun 19, 2013 at 2:00 PM, Xinliang David Li wrote:
> Should the patch be ported to in 48 branch?
>
> thanks,
>
> David
>
> On Wed, Jun 19, 2013 at 11:46 AM, Vladimir Makarov
> wrote:
>> On 13-06-19 1:23 AM, Wei Mi wrote:
>>>
>>> Ping.
>>>
>>> On Wed, Jun 1
+jakub who manages GCC 4.8 releases.
David
On Wed, Jun 19, 2013 at 2:28 PM, Wei Mi wrote:
> Yes, I think so.
>
> Regards,
> Wei.
>
> On Wed, Jun 19, 2013 at 2:00 PM, Xinliang David Li wrote:
>> Should the patch be ported to in 48 branch?
>>
>> thanks,
>>
>> David
>>
>> On Wed, Jun 19, 2013 at 1
Hi,
This patch fixes a bad merge in r199218.
Removing cgraph noded in early-ipa should be allowed.
Otherwise, we got ICE in tree-eipa_sra with
-freorder-funtions=callgraph (without -fripa)
Tested with regressions and google banchmarks.
Thanks,
-Rong
patch.diff
Description: Binary data
lgtm.
On Wed, Jun 19, 2013 at 3:41 PM, Rong Xu wrote:
> Hi,
>
> This patch fixes a bad merge in r199218.
> Removing cgraph noded in early-ipa should be allowed.
> Otherwise, we got ICE in tree-eipa_sra with
> -freorder-funtions=callgraph (without -fripa)
>
> Tested with regressions and google ban
On Wed, 2013-06-19 at 14:43 -0500, Peter Bergner wrote:
> On Wed, 2013-06-19 at 10:57 -0500, Peter Bergner wrote:
> > On Wed, 2013-06-19 at 10:49 -0500, Peter Bergner wrote:
> > > This is due to the following in _ITM_inTransaction():
> > >
> > > 47 if (tx && (tx->nesting > 0))
> > > (gdb
On Wed, 19 Jun 2013, Sandra Loosemore wrote:
> On 06/17/2013 06:02 PM, Sandra Loosemore wrote:
> >
> > I had another thought: perhaps -fstrict-volatile-bitfields could remain
> > the default on targets where it currently is, but it can be overridden
> > by an appropriate -std= option. Perhaps a
I hope the following patch fixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57604
Although I have no specific hardware to check this.
The patch also adds a comment about one recent change as it was done in
the same function.
The patch was successfully bootstrapped and tested on x86/x86-64 a
Hi again,
On 06/19/2013 03:37 PM, Paolo Carlini wrote:
Hi,
when I implemented Core/1123 "Destructors should be noexcept by
default", unfortunately I caused this regression, present now in
mainline and 4_8-branch.
When the destructor is user provided, with no exception
specifications, and t
On Wed, 19 Jun 2013, DJ Delorie wrote:
>
> Third revision, mostly the same as the last, haven't heard any additional
> feedback in the last few weeks. Ok to commit yet?
> [libgcc]
>
> * config.host (msp*-*-elf): New.
> * config/msp430/: New port.
A random spotting; copyright header r
> A random spotting; copyright header replacement miss, including
> but maybe not limited to:
Doh! I'll scan them all and fix them. Thanks!
At 2013-05-24 15:19:36,"Chung-Ju Wu" wrote:
> 2013/5/24 Xinyu Qi :
> > Hi,
> >
> > For this simple case, compiled with option -march=iwmmxt -O, #define
> > N 64 signed int b[N]; signed long long j[N], d[N]; void foo (void) {
> > int i;
> > for (i = 0; i < N; i++)
> > j[i] = d[i] << b[i]
On 06/19/2013 05:10 PM, Joseph S. Myers wrote:
I don't think it's right to depend on the standard version like this. The
existing semantics for GNU C and C++ follow the memory model for all
standard versions, and that's the sort of thing that shouldn't depend on
the target architecture. In the
On Thu, 2013-06-20 at 00:51 +0200, Torvald Riegel wrote:
> On Wed, 2013-06-19 at 14:43 -0500, Peter Bergner wrote:
> >> I'm having trouble seeing why/when _ITM_inTransaction() is
> >> returning something other than inIrrevocableTransaction. I'll see if I can
> >> determine why and will report bac
On Wed, Jun 19, 2013 at 7:55 PM, Sandra Loosemore
wrote:
> On 06/19/2013 05:10 PM, Joseph S. Myers wrote:
>>
>>
>> I don't think it's right to depend on the standard version like this. The
>> existing semantics for GNU C and C++ follow the memory model for all
>> standard versions, and that's the
On Wed, Jun 19, 2013 at 9:21 AM, Jason Merrill wrote:
> On 06/18/2013 12:27 PM, Andrew Sutton wrote:
>>
>> There was a bug in instantiation_dependent_expr_r that would cause
>> trait expressions like __is_class(int) to be marked as type dependent.
>> It was always testing the 2nd operand, even for
Hi,
[patch update] Support .eh_frame in crt1 x86_64 glibc (PR libgcc/57280,
libc/15407)
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00775.html
Message-ID: <20130514191244.ga12...@host2.jankratochvil.net>
Thanks,
Jan
92 matches
Mail list logo
