This fixes a non-conformance issue in std::packaged_task which we've
decided should be addressed for 4.8
std::function cannot be used with non-CopyConstructible targets, so
this replaces std::function in the implementation of
std::packaged_task.
PR libstdc++/56492
* include/std/fu
On 03/15/2013 01:42 PM, Tilo Schwarz wrote:
Hi,
this is a ping for
[Patch, libfortran] PR51825 - Fortran runtime error: Cannot match namelist
object name
http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00316.html
Regards,
Tilo
OK, once trunk opens. Thanks for patch. Do you have commit
LRA branch has been merged with trunk @ 196686.
The branch was successfully bootstrapped on x86/x86-64.
Committed as rev. 196690.
Ok. If the use case is to enable the test of the same application
binary (not the per function unit test) with CPU mocking at runtime
(via environment variable or application specific flags), the proposed
changes make sense.
David
On Fri, Mar 15, 2013 at 3:49 PM, Sriraman Tallam wrote:
> On Fri
The branch was merged with trunk @ r196686.
The branch was successfully bootstrapped on x86 and x86-64.
Committed as rev. 196689.
The following patch fixes all s390 GCC testsuite failures (in comparison
with reloads). The problem was in unaligned access in a shared library
code which was result of unaligned stack of generated code.
The patch was also successfully bootstrapped on x86/x86-64.
Committed as rev. 196685.
20
On Fri, Mar 15, 2013 at 3:37 PM, Xinliang David Li wrote:
> On Fri, Mar 15, 2013 at 2:55 PM, Sriraman Tallam wrote:
>> Hi,
>>
>>This patch is meant for google/gcc-4_7 but I want this to be
>> considered for trunk when it opens again. This patch makes it easy to
>> test for code coverage of mu
On Fri, Mar 15, 2013 at 2:55 PM, Sriraman Tallam wrote:
> Hi,
>
>This patch is meant for google/gcc-4_7 but I want this to be
> considered for trunk when it opens again. This patch makes it easy to
> test for code coverage of multiversioned functions. Here is a
> motivating example:
>
> __attr
On Sun, 30 Sep 2012, Marc Glisse wrote:
On Sat, 29 Sep 2012, Eric Botcazou wrote:
this patch lets the compiler try to rewrite:
(vec_concat (vec_select x [a]) (vec_select x [b]))
as:
vec_select x [a b]
or even just "x" if appropriate.
[...]
Why not generalizing to all kinds of VEC_SELECTs
Hi,
This patch is meant for google/gcc-4_7 but I want this to be
considered for trunk when it opens again. This patch makes it easy to
test for code coverage of multiversioned functions. Here is a
motivating example:
__attribute__((target ("default"))) int foo () { ... return 0; }
__attribute_
Fix inconsistency between Makefile.am and Makefile.in under libstdc++.
The inconsistency was introduced by
svn+ssh://gcc.gnu.org/svn/gcc/branches/google/gcc-4_7@194664
Since the re-generated Makefile.in has not changed (thus not included
in the patch), this modification should have no impact.
Hi
Hi,
this is a ping for
[Patch, libfortran] PR51825 - Fortran runtime error: Cannot match namelist
object name
http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00316.html
Regards,
Tilo
On 03/15/2013 05:27 PM, Jakub Jelinek wrote:
Queued for gomp-4_0-branch (to be created next week). Comments?
I heard from colleagues on the Fortran Standardization Committee
(http://j3-fortran.org) that 4.0 doubled in size w.r.t. the 3.x standard.
I wish you lots of success implementing th
Hi,
At present, the libcall helpers implementing atomic operations
(__sync_val_compare_and_swap_X) for char and short types suffer from
a type mismatch. This is leading to test failures, i.e.:
FAIL: gcc.dg/atomic-compare-exchange-1.c execution test
FAIL: gcc.dg/atomic-compare-exchange-2.c executi
Hi Richard,
There are a couple of embedded comments, plus new patch attached. Are we there
yet?
Thanks,
Catherine
> -Original Message-
> From: Richard Sandiford [mailto:rdsandif...@googlemail.com]
> Sent: Thursday, March 14, 2013 4:55 PM
> To: Moore, Catherine
> Cc: gcc-patches@gcc.gnu.o
ok.
David
On Fri, Mar 15, 2013 at 10:53 AM, Jing Yu wrote:
> Got new regression failures when using gold to run gcc regression
> tests. The failures are related to LIPO (b/8397853).
> Since LIPO won't be available for Powerpc64 target until the end of
> 2013Q2, mark these tests expected failure.
Got new regression failures when using gold to run gcc regression
tests. The failures are related to LIPO (b/8397853).
Since LIPO won't be available for Powerpc64 target until the end of
2013Q2, mark these tests expected failure.
OK for google/gcc-4_7?
Tested:
Extract testresults from nightly bui
On 15/03/13 16:37, Gerald Pfeifer wrote:
On Fri, 15 Mar 2013, Marcus Shawcroft wrote:
OK for stage-1.
This may be a naive question, but with AArch64 being a new port
and these changes being port-specific, with no impact on anything
else, have you considered asking the release managers to be mo
On Fri, 15 Mar 2013, Marcus Shawcroft wrote:
> OK for stage-1.
This may be a naive question, but with AArch64 being a new port
and these changes being port-specific, with no impact on anything
else, have you considered asking the release managers to be more
aggressive in applying things?
Of cour
Hi!
As the updated comments show, OpenMP 4.0 (rc2 so far) has added a bunch of
new #pragma omp {,update,capture} forms. Here is C++ support for that,
depending on http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00546.html
Queued for gomp-4_0-branch (to be created next week). Comments?
I'm afraid C
Hi!
While working on OpenMP 4.0 atomics support, I've run into this
pasto. Acked by Jason privately, queued for 4.8.1 and 4.9.
2013-03-15 Jakub Jelinek
* tree.c (cp_tree_equal): Fix a pasto.
--- gcc/cp/tree.c.jj2013-03-11 10:04:11.0 +0100
+++ gcc/cp/tree.c 2013-03-
On 2013-02-13 22:23, Hurugalawadi, Naveen wrote:
bove
+(define_insn "*andsi3_compare0_uxtw"
+ [(set (reg:CC_NZ CC_REGNUM)
+ (compare:CC_NZ
+(and:SI (match_operand:SI 1 "register_operand" "%r,r")
+(match_operand:SI 2 "aarch64_logical_operand" "r,K"))
+(const_
On 14/03/13 12:49, Tejas Belagod wrote:
Hi,
Attached is a patch that implements the framework necessary for implementing
NEON Intrinsics' builtins in Tree/Gimple rather than RTL. For this it uses the
target hook TARGET_FOLD_BUILTIN and folds all the builtins for NEON Intrinsics
into equivalent t
On 14/03/13 15:34, Ian Bolton wrote:
We couldn't generate EXTR for AArch64 ... until now!
This patch includes the pattern and a test.
Full regression testing for Linux and bare-metal passed.
OK for trunk stage-1?
Thanks,
Ian
2013-03-14 Ian Bolton
gcc/
* config/aarch64/aarch64.md
On 14/03/13 15:42, Ian Bolton wrote:
We couldn't generate ROR (preferred alias of EXTR when both source
registers are the same) for AArch64, when rotating by an immediate,
... until now!
This patch includes the pattern and a test.
Full regression testing for Linux and bare-metal passed.
OK for
On 14/03/13 15:52, Ian Bolton wrote:
We couldn't generate SBC for AArch64 ... until now!
This really patch includes the main pattern, a zero_extend form
of it and a test.
Full regression testing for Linux and bare-metal passed.
OK for trunk stage-1?
Thanks,
Ian
2013-03-14 Ian Bolton
gcc
> Please consider this as a reminder to review the patch posted at
> following link:-
> http://gcc.gnu.org/ml/gcc-patches/2013-01/msg01374.html
>
> The patch is slightly modified to use CC_NZ mode instead of CC.
>
> Please review the patch and let me know if its okay?
>
Hi Naveen,
With the CC_
On Fri, Mar 15, 2013 at 08:00:50AM -0500, Gabriel Dos Reis wrote:
> On Fri, Mar 15, 2013 at 3:51 AM, Richard Biener
> wrote:
> > On Thu, Mar 14, 2013 at 10:08 PM, Marc Glisse wrote:
> >> On Thu, 14 Mar 2013, Jakub Jelinek wrote:
> >>
> >>> I wonder if it wouldn't be better to fold the target buil
On Fri, Mar 15, 2013 at 3:51 AM, Richard Biener
wrote:
> On Thu, Mar 14, 2013 at 10:08 PM, Marc Glisse wrote:
>> On Thu, 14 Mar 2013, Jakub Jelinek wrote:
>>
>>> I wonder if it wouldn't be better to fold the target builtins only later
>>> on
>>> (e.g. guard the folding with cfun && gimple_in_ssa_
On Thu, 14 Mar 2013, Richard Biener wrote:
>
> This extracts pieces from the already posted patch series that are
> most worthwhile and applicable for backporting to both 4.8 and 4.7.
> It also re-implements the limiting of the maximum number of memory
> references to consider for LIMs dependence
Hi Tobias,
> The issue is a regression which exists since GCC 4.4. The fix is rather
> obvious (see also PR).
>
> Build and regtested on x86-64-gnu-linux.
> OK for the trunk and the two maintained branches, 4.6 and 4.7?
yes, looks good to me (pretty much obvious).
It seems the 4.8 release is qui
Ian Lance Taylor writes:
> On Thu, Mar 14, 2013 at 9:53 AM, Rainer Orth wrote:
>
>> I found that this patch
>>
>> 2012-12-04 Ian Lance Taylor
>> * godump.c (find_dummy_types): Output a dummy type if we couldn't
>> output the real type.
>>
>>
>>
>> fixes the problem, so I'd like t
On Thu, Feb 28, 2013 at 08:32:02AM -0700, Tom Tromey wrote:
> 2013-02-27 Tom Tromey
>
> * libsupc++/unwind-cxx.h: Include sys/sdt.h if detected.
> (PROBE2): New macro.
> * libsupc++/eh_throw.cc (__cxa_throw, __cxa_rethrow): Add probe.
> * libsupc++/eh_catch.cc (__cxa_beg
On Thu, Mar 14, 2013 at 10:08 PM, Marc Glisse wrote:
> On Thu, 14 Mar 2013, Jakub Jelinek wrote:
>
>> I wonder if it wouldn't be better to fold the target builtins only later
>> on
>> (e.g. guard the folding with cfun && gimple_in_ssa_p (cfun) (or if we have
>> any predicate that is set starting w
The issue is a regression which exists since GCC 4.4. The fix is rather
obvious (see also PR).
Build and regtested on x86-64-gnu-linux.
OK for the trunk and the two maintained branches, 4.6 and 4.7?
Tobias
2013-03-15 Tobias Burnus
PR fortran/56615
* trans-intrinsic.c (gfc_conv_intrinsic_t
Hi!
As this supposedly affects all targets that don't default to DWARF debug
info, I've committed this fix as obvious to force using
-fvar-tracking-assignments everywhere.
Tested on x86_64-linux and with cross to hppa2.0w-hp-hpux11.11.
2013-03-15 Jakub Jelinek
PR debug/56307
36 matches
Mail list logo
