Hi,
Please consider this as a reminder to review the patch posted at
following link:-
http://gcc.gnu.org/ml/gcc-patches/2013-01/msg00388.html
Please review the patch and let me know if its okay?
Thanks & Regards,
Naveen.H.S
Hi,
Please consider this as a reminder to review the patch posted at
following link:-
http://gcc.gnu.org/ml/gcc-patches/2013-01/msg00463.html
Please review the patch and let me know if its okay?
Thanks & Regards,
Naveen.H.S
Hi,
Please consider this as a reminder to review the patch posted at
following link:-
http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00765.html
Please review the patch and let me know if its okay?
Thanks & Regards,
Naveen.H.S
At 2013-01-22 19:58:43,"Ramana Radhakrishnan" wrote:
> On 01/22/13 09:21, Xinyu Qi wrote:
> > Ping,
> >
> > Fix ChangeLog
>
> The ChangeLog format includes .
>
>
>
> If you want a patch accepted in the future, please help by creating the
> Changelog entry in the correct format, i.e. fill i
On 01/22/2013 07:24 PM, Siddhesh Poyarekar wrote:
> Cc'ing Carlos on this so that he's aware of it.
>
> Siddhesh
>
> Jakub Jelinek wrote:
>
> On Sat, Jan 19, 2013 at 12:22:23PM -0500, Jason Merrill wrote:
>> Siddhesh has a patch to implement the thread atexit functionality in
>> glibc in order
On Tue, Jan 22, 2013 at 02:20:23PM +0100, Torvald Riegel wrote:
> > @@ -116,11 +116,10 @@ GOMP_task (void (*fn) (void *), void *data, void (
> > }
> >else
> > fn (data);
> > - if (team != NULL)
> > + if (task.children != NULL)
>
> Why does this not need an acquire barrier
Cc'ing Carlos on this so that he's aware of it.
Siddhesh
Jakub Jelinek wrote:
On Sat, Jan 19, 2013 at 12:22:23PM -0500, Jason Merrill wrote:
> Siddhesh has a patch to implement the thread atexit functionality in
> glibc in order to integrate better with the dynamic loader and run
> the cleanups
Hi Janne,
PING**2
this is OK. Thanks a lot for the work you put into this!
Thomas
On 18 January 2013 09:50, Richard Biener wrote:
>> Fixed by this patch, OK for trunk and 4.7?
>
> I don't think mentioning what old GCC versions did is necessary, thus, ok
> without
>
> +Since GCC 4.7 it is only possible to download the full source distribution,
> +not specific components.
> +In GC
Committed as obvious.
* doc/extend.texi (__int128): Improve grammar.
commit b907a92691dbabe5755bc82c5e66718c8b255f4c
Author: Jonathan Wakely
Date: Tue Jan 22 21:36:04 2013 +
* doc/extend.texi (__int128): Improve grammar.
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.tex
Hello!
Attached patch removes DImode immediate -> memory alternatives from
64bit move patterns. We were lying to a register allocator about this,
and various fixups were needed after reload to split invalid moves.
Split moves to adjacent memory location violated assumption that moves
of arguments
Hi Richard,
I hope that I have addressed all of your comments in this cleaned up patch.
There are a couple of items that have been omitted that I plan to submit as
follow-on patches. The use of jraddiusp and the use of short delay slots have
both been deferred. You had suggested a function na
Marek Polacek wrote:
>On Tue, Jan 22, 2013 at 06:44:40PM +0100, Zdenek Dvorak wrote:
>> > I was however worried that we might end up with an edge
>> > coming out of BB
>> > from different loop heading into the header. In this case setting
>up
>> > loop's latch as the source of the latch edge wou
OK.
Jason
On Tue, Jan 22, 2013 at 06:44:40PM +0100, Zdenek Dvorak wrote:
> > I was however worried that we might end up with an edge
> > coming out of BB
> > from different loop heading into the header. In this case setting up
> > loop's latch as the source of the latch edge would be wrong.
>
> Actually, t
On Tue, Jan 22, 2013 at 03:30:06PM +0100, Richard Biener wrote:
> Marek Polacek wrote:
>
> >We ICEd on attached testcase because we didn't properly detected the
> >latch edge. Furthermore, I think the code for re-computing latches
> >is somehow broken at the moment. In fix_loop_structure we hav
Hi,
> > > We ICEd on attached testcase because we didn't properly detected the
> > > latch edge. Furthermore, I think the code for re-computing latches
> > > is somehow broken at the moment. In fix_loop_structure we have
> > > /* If there was no latch, schedule the loop for removal. */
>
On Tue, Jan 22, 2013 at 05:26:02PM +0100, Zdenek Dvorak wrote:
> Hi,
>
> > We ICEd on attached testcase because we didn't properly detected the
> > latch edge. Furthermore, I think the code for re-computing latches
> > is somehow broken at the moment. In fix_loop_structure we have
> > /* I
> Now in the form of a tested patch (regtested on x86_64-linux and
> i686-linux). Ok for trunk?
>
> dg-additional-options unfortunately isn't supported in libstdc++ testsuite,
> so had to use second dg-options, and also the \(, \) were wrong and resulted
> in no matches.
Looks good to me (but ca
On 22 January 2013 17:00, Jakub Jelinek wrote:
>
> Now in the form of a tested patch (regtested on x86_64-linux and
> i686-linux). Ok for trunk?
OK, thanks.
> dg-additional-options unfortunately isn't supported in libstdc++ testsuite,
> so had to use second dg-options, and also the \(, \) were w
Ping^3?
Thanks,
Kyrill
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Kyrylo Tkachov
> Sent: 14 January 2013 17:32
> To: gcc-patches@gcc.gnu.org
> Cc: Ramana Radhakrishnan; Richard Earnshaw
> Subject: RE: [PATCH][ARM][2/3]
Ping^3?
Thanks,
Kyrill
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Kyrylo Tkachov
> Sent: 14 January 2013 17:32
> To: gcc-patches@gcc.gnu.org
> Cc: Ramana Radhakrishnan; Richard Earnshaw
> Subject: RE: [PATCH][ARM][1/3]
On Mon, Jan 21, 2013 at 03:05:45PM +0100, Jakub Jelinek wrote:
> On Sun, Jan 13, 2013 at 10:06:05PM -0800, Andi Kleen wrote:
> > 2013-01-12 Andi Kleen
> > Jonathan Wakely
> >
> > PR libstdc++/55223
> > * testsuite/29_atomics/atomic_flag/test_and_set/explicit-hle.cc:
> >
Hi!
libasan relies on being linked before -lpthread, -lstdc++ and -lc, but so
far nothing was ensuring that. Not only e.g. -lstdc++ could come before
-lasan when -lstdc++ was added by g++ language specific driver handling,
but also if the user specifies -lstdc++, -lpthread or -lc somewhere on
the
On 01/22/2013 09:49 AM, Jakub Jelinek wrote:
Hi!
While glibc fprintf allows printing %s with NULL argument as (null),
other C libraries aren't that forgiving. If loc isn't UNKNOWN_LOCATION,
but say BUILTINS_LOCATION, UNKNOWN_LOCATION with an associated BLOCK etc.,
we might ICE on those hosts.
Hi!
While glibc fprintf allows printing %s with NULL argument as (null),
other C libraries aren't that forgiving. If loc isn't UNKNOWN_LOCATION,
but say BUILTINS_LOCATION, UNKNOWN_LOCATION with an associated BLOCK etc.,
we might ICE on those hosts. The patch also changes find_loop_location,
so t
Hi!
This patch fixes the following testcase, where *strset* insn got matched
just from a store followed by increment, instead of being expanded from
builtin memset. This is undesirable, because the stos? insns require
specific hard registers for both operands and thus tie hands of the RA,
so whil
Hi!
Fortran OOP is still to be considered completely unsupported in OpenMP,
but this patch just attempts to fix this because it was easy to do so.
The select_type_temporary vars are artificial (created by the compiler,
not user vars), we shouldn't emit them into debug info, nor they should be
priv
Hi,
> We ICEd on attached testcase because we didn't properly detected the
> latch edge. Furthermore, I think the code for re-computing latches
> is somehow broken at the moment. In fix_loop_structure we have
> /* If there was no latch, schedule the loop for removal. */
> if (!first
Hi,
today I had a look to this PR, maybe it's simple enough to be fixed at
this time. The issue is that we ICE in check_initializer in:
init = build_functional_cast (type, init, tf_none);
- if (init != error_mark_node)
+ if (TREE_CODE (init) == TARGET_EXPR)
Pushing into the right access scope isn't enough if we defer the check
until after we leave the scope...
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 31d44658775ceaedddefbeac8c7ea735be8f3576
Author: Jason Merrill
Date: Tue Jan 22 10:50:53 2013 -0500
PR c++/56071
* pt.c (ma
Hi,
I ran into PR driver/47785 when doing some testing with an option passed
to the testsuite and I chose to fix this by putting out
COLLECT_AS_OPTIONS as though these are options for the driver by
prepending them with a "'-Wa", and suffixing them with a "'" character
and additionally providi
Marek Polacek wrote:
>We ICEd on attached testcase because we didn't properly detected the
>latch edge. Furthermore, I think the code for re-computing latches
>is somehow broken at the moment. In fix_loop_structure we have
> /* If there was no latch, schedule the loop for removal. */
>
On Tue, Jan 22, 2013 at 01:01:24PM +0100, Jakub Jelinek wrote:
> On Tue, Jan 22, 2013 at 10:22:00PM +1030, Alan Modra wrote:
> > On Tue, Jan 22, 2013 at 12:19:21PM +0100, Jakub Jelinek wrote:
> > > Looks good to me.
> >
> > Thanks for the amazingly quick review! Committed revision 195370.
>
> Ac
We ICEd on attached testcase because we didn't properly detected the
latch edge. Furthermore, I think the code for re-computing latches
is somehow broken at the moment. In fix_loop_structure we have
/* If there was no latch, schedule the loop for removal. */
if (!first_latch)
On Tue, Jan 22, 2013 at 12:21 AM, Paul Pluzhnikov
wrote:
> This patch sets destructed vector into an invalid state, such that
> subsequent calls to begin(), end(), size(), etc. all throw logic_error.
>
> Google ref b/7248326
>
> Ok for google/gcc-4_7 and google/integration?
OK.
Diego.
On Tue, 2013-01-22 at 21:33 +1030, Alan Modra wrote:
> SPEComp2012 376.kdtree shows a huge regression after my PR51376 fix,
> with the benchmark, which finishes normally in a few minutes, failing
> to complete after hours of running on a power7 machine. Using a
> reduced data set showed typically
Ramana Radhakrishnan writes:
> The patch by itself is OK but surprisingly I never saw this earlier. Your
> ping has removed the date from the original post so I couldn't track it
> down.
You can follow the references and look up the message-id via
http://mid.gmane.org/.
Andreas.
--
Andreas Sc
On Tue, Jan 22, 2013 at 10:22:00PM +1030, Alan Modra wrote:
> On Tue, Jan 22, 2013 at 12:19:21PM +0100, Jakub Jelinek wrote:
> > Looks good to me.
>
> Thanks for the amazingly quick review! Committed revision 195370.
Actually, there is one thing I'm worried about, -lgomp doesn't link against
-la
On 01/22/13 09:21, Xinyu Qi wrote:
Ping,
Fix ChangeLog
The ChangeLog format includes .
If you want a patch accepted in the future, please help by creating the
Changelog entry in the correct format, i.e. fill in the author's name as
well as email address as below. I've created an entry
On Tue, Jan 22, 2013 at 12:19:21PM +0100, Jakub Jelinek wrote:
> Looks good to me.
Thanks for the amazingly quick review! Committed revision 195370.
Is the patch OK for 4.7 too?
--
Alan Modra
Australia Development Lab, IBM
On Tue, Jan 22, 2013 at 09:33:25PM +1030, Alan Modra wrote:
> Bootstrapped and regression tested powerpc64-linux. OK to apply?
>
> PR libgomp/51376
> PR libgomp/56073
> * task.c (GOMP_task): Revert 2011-12-09 change.
> (GOMP_taskwait): Likewise. Instead use atomic load wi
SPEComp2012 376.kdtree shows a huge regression after my PR51376 fix,
with the benchmark, which finishes normally in a few minutes, failing
to complete after hours of running on a power7 machine. Using a
reduced data set showed typically over a 200x slowdown. So, why is
this happening? Well, it a
On 01/15/13 16:31, Janis Johnson wrote:
On 01/14/2013 03:04 PM, Janis Johnson wrote:
Test gcc.target/arm/neon-vld1_dupQ.c started failing with r194594, a C
front end change that causes the test to get warnings. The test passes
local variables of type int64x1_t to functions declared with argumen
On 01/21/13 10:55, Jakub Jelinek wrote:
Hi!
As can be seen on the testcase, this backend bug is still reproduceable even
on trunk, the backend just can't rely on cstoredi4 or cbranchdi4 expansion
not being performed with two constants, unless it has predicates that
disallow it (Steven's patch in
Hi,
barring objections, I'm going to commit as obvious the below, which
removes a left over bit of documentation, thus completing
http://gcc.gnu.org/viewcvs?view=revision&revision=97318
Thanks,
Paolo.
2013-01-22 Paolo Carlini
PR c++/56067
* doc/invoke
This is a patchlet to fix a (potential) regression introduced by the use of
N_Expression_With_Actions in some constructs.
Tested on x86_64-suse-linux, applied on the mainline.
2013-01-22 Eric Botcazou
* gcc-interface/trans.c (gnat_to_gnu) : Do
not translate the Etype of the
It's not really a regression, but the fix is trivial: top-level pragma
Optimize is ignored (as other pragmas for which gigi must do something).
Tested on x86_64-suse-linux, applied on the mainline.
2013-01-22 Eric Botcazou
* gcc-interface/trans.c (Pragma_to_gnu) : Use optimize_size
This patch makes it so that an exception handler is installed around the main
entry point to catch unhandled exceptions on SEH targets.
Tested on x86_64-suse-linux, applied on the mainline.
2013-01-22 Tristan Gingold
* gcc-interface/gigi.h (ADT_unhandled_except_decl,
ADT_unh
On Mon, Jan 21, 2013 at 5:22 PM, Vladimir Makarov wrote:
> I'd prefer the above change than just keeping
> lra_invalidate_insn_data call. I think it is more safe solution for other
> parts of LRA code.
I agree, but unfortunately the compiler does not...
With that lra.c change, I get extra fails:
Ping,
Fix ChangeLog
* config/arm/arm.h (FIRST_IWMMXT_GR_REGNUM): Add comment.
* config/arm/iwmmxt.md (WCGR0): Update.
(WCGR1, WCGR2, WCGR3): Likewise.
> Hi,
>
> It is necessary to sync the constants WCGR0 to WCGR3 in iwmmxt.md with
> the IWMMXT_GR_REGNUM in arm.h.
>
>
Hi!
Documentation bug fixed thusly:
2013-01-22 Jakub Jelinek
PR libquadmath/56072
* libquadmath.texi (M_PI_2q, M_PI_4q): Fix up description.
--- libquadmath/libquadmath.texi.jj 2013-01-04 13:44:36.0 +0100
+++ libquadmath/libquadmath.texi2013-01-22 09:21:19
52 matches
Mail list logo
