Hello,
Thanks for testing the patch.
> FAIL: gcc.dg/sms-8.c scan-rtl-dump-times sms "SMS loop with subreg in lhs" 1
Does the attached patch resolve the failure with sms-8.c?
If so I'll re-submit it.
Thanks,
Revital
Index: testsuite/gcc.dg/sms-2.c
Misdetected as Athlon by GCC, K6-2+ and K6-3+ are processors that support
extended 3DNow! but don't support extended MMX or CMOV.
I don't own a K6-2 or Athlon machine. Can anybody have the patch tested?
2011-05-16 Zuxy Meng
PR i386/48743
* config/i386/cpuid.h (bit_MMXEXT): New
* config/i386/cp
Per some other changes in the last couple of weeks.
It would be really, really good if one of you Java guys could go
through the FAQ and remove obsolete entries. (Or just let me know
about any changes and I'll make them for you.)
Gerald
2011-05-15 Gerald Pfeifer
* faq.html: Use ,
On 05/15/2011 07:07 PM, Jonathan Wakely wrote:
On 15 May 2011 23:19, Jason Merrill wrote:
OK for trunk and 4.6.
The bug isn't present on the 4.6 branch and I'm not sure where the
change should go, if it's needed at all, so I've only committed it to
trunk.
Ah, my mistake. Sounds good.
Jason
On Sun, May 15, 2011 at 7:52 PM, Nathan Froyd wrote:
> On 05/15/2011 08:49 PM, Gabriel Dos Reis wrote:
>> On Sun, May 15, 2011 at 7:13 PM, Nicola Pero
>> wrote:
>>> This patch adds a new GTY option, "atomic", which is similar to the
>>> identical option you have with Boehm GC
>>> and which can b
On 05/15/2011 08:49 PM, Gabriel Dos Reis wrote:
> On Sun, May 15, 2011 at 7:13 PM, Nicola Pero
> wrote:
>> This patch adds a new GTY option, "atomic", which is similar to the
>> identical option you have with Boehm GC
>> and which can be used with pointers to inform the GC/PCH machinery that they
On Sun, May 15, 2011 at 7:13 PM, Nicola Pero
wrote:
> This patch adds a new GTY option, "atomic", which is similar to the identical
> option you have with Boehm GC
> and which can be used with pointers to inform the GC/PCH machinery that they
> point to an area of memory that
[...]
> This patch
This patch adds a new GTY option, "atomic", which is similar to the identical
option you have with Boehm GC
and which can be used with pointers to inform the GC/PCH machinery that they
point to an area of memory that
contains no pointers (and hence needs no scanning).
The reason for adding this
On 15 May 2011 23:19, Jason Merrill wrote:
> OK for trunk and 4.6.
The bug isn't present on the 4.6 branch and I'm not sure where the
change should go, if it's needed at all, so I've only committed it to
trunk.
Hi,
I checked in this patch to put back mode on operand 1 in
tls_global_dynamic_64 patterns.
H.J.
---
commit 6eddaa2187ccb80fe8515705778b5818033cfb2d
Author: H.J. Lu
Date: Fri May 13 10:35:16 2011 -0700
Rename tls_global_dynamic_64 to tls_global_dynamic_64_.
diff --git a/gcc/ChangeLog.x
OK.
Jason
OK for trunk and 4.6.
Jason
> The patch is OK, but it doesn't change anything for c52103x as this is a
> pure gimplifier problem. Try running ACATS at -O0:
Or just compile the attached reduced testcase at -O0:
c52103x.adb: In function 'C52103X':
c52103x.adb:1:1: error: type mismatch in binary truth expression
boolean
syste
> With this patch (which would describe why it gimplifier sees
> integer-type nodes here):
>
> Index: gcc/gcc/ada/gcc-interface/trans.c
> ===
> --- gcc.orig/gcc/ada/gcc-interface/trans.c 2011-05-12
> 20:06:01.0 +0200
> +++
The patch is a follow-up to the patch at
http://gcc.gnu.org/ml/fortran/2011-05/msg00067.html. With that patch,
all* my coarray example compile (and run with -fcoarray=single or
-fcoarray=lib -lcaf_single).
Build and regtested on x86-64-linux with two regtest failures: (a) The
never workinggfo
2011/5/15 Kai Tietz :
> 2011/5/15 Eric Botcazou :
>>> Well, I mean by artificial here, that gimplification is done via
>>> gimplify_expr API. As FE and ME have here different assumptions. The
>>> ME uses internally most boolean_type_node and IMHO it should be the
>>> variant used there. As this co
2011/5/15 Eric Botcazou :
>> Well, I mean by artificial here, that gimplification is done via
>> gimplify_expr API. As FE and ME have here different assumptions. The
>> ME uses internally most boolean_type_node and IMHO it should be the
>> variant used there. As this conversation to a single boole
Hello!
2011-05-15 Uros Bizjak
* config/i386/i386.md (floating point move splitters): Fix
usage of standard_80387_constant_p.
* config/i386/i386.c (ix86_preferred_reload_class): Ditto.
Tested on x86_64-pc-linux-gnu {,-m32}, committed to mainline SVN.
Uros.
Index: i386.
> The attached patch fixes SMS testsuite failures seen on PowerPC and SPU.
On powerpc-apple-darwin9 the patch fixes all the SMS failures but for
FAIL: gcc.dg/sms-8.c scan-rtl-dump-times sms "SMS loop with subreg in lhs" 1
with -m64. Also tested on x86_64-apple-darwin10 without regression.
Thank
Hi,
let's noexcept-ify ;) Tested x86_64-linux, committed.
Paolo.
/
2011-05-15 Paolo Carlini
* include/bits/c++config (_GLIBCXX_NOEXCEPT, _GLIBCXX_USE_NOEXCEPT):
Add.
* include/std/limits: Use the latter everywhere.
(numeric_limits, numeric
Hello!
optimize_size clears TARGET_INTEGER_DFMODE_MOVES, so we can simplify
movdf_internal insn condition a bit.
2011-05-15 Uros Bizjak
* config/i386/i386.md (*movdf_internal): Simplify insn condition.
Tested on x86_64-pc-linux-gnu {,-m32}, committed to mainline SVN.
Uros.
Index: c
On Fri, May 6, 2011 at 4:02 PM, Jan Hubicka wrote:
> Hi,
> given that the patch has received feedback and I have weekend for fixing the
> fallout, I decided to commit the following version today. It contains fix in
> visibility handling of thunks that has shown in Mozilla build.
>
>
> * cg
> Well, I mean by artificial here, that gimplification is done via
> gimplify_expr API. As FE and ME have here different assumptions. The
> ME uses internally most boolean_type_node and IMHO it should be the
> variant used there. As this conversation to a single boolean_type
> (with recast to resu
2011-05-15 Dmitry Gorbachev
* gengtype-state.c (read_state_param_structs): Initialize "previous".
--- gcc/gengtype-state.c
+++ gcc/gengtype-state.c
@@ -2137,7 +2137,7 @@ read_state_param_structs (type_p *param_structs)
int nbparamstructs = 0;
int countparamstructs = 0;
type_p
Hi,
just consistently handle the various "type traits" RIDs in alphabetical
order (+ update the comments to mention the most recent ones). Tested
x86_64-linux.
Ok for mainline?
Paolo.
/c-family
2011-05-15 Paolo Carlini
* c-common.c (c_common_reswords): Reord
Hi
http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01973.html
Use ldrd and strd to access two consecutive words
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00490.html
Compute attr length for thumb2 insns
thanks
Carrot
Hi,
so, here is take 3 (sigh). Compared to take 2, it no longer uses
stdio, since opening a stdio FILE stream probably malloc()'s a buffer,
which is not async-signal-safe.
Regtested on x86_64-unknown-linux-gnu, Ok for trunk?
2011-05-15 Janne Blomqvist
PR libfortran/48931
* co
> On Fri, May 13, 2011 at 5:54 AM, Paolo Bonzini wrote:
> > On 05/13/2011 03:03 AM, Rong Xu wrote:
> >>
> >> * gcc/coverage.c (revision 173717): set a flag if building
> >> for Linux kernel.
> >> * gcc/tree-profile.c (revision 173717): don't emit TLS
> >> declarations for L
The previous patch was slightly over-zealous. Committed the following fix:
Index: gfortran.texi
===
--- gfortran.texi (revision 173769)
+++ gfortran.texi (working copy)
@@ -2611,7 +2611,7 @@ standard error. Default: @code
cp/ChangeLog
PR c++/48994
* parser.c (cp_parser_perform_range_for_lookup): Call complete_type.
testsuite/ChangeLog
PR c++/48994
* g++.dg/cpp0x/range-for18.C: New.
Tested x86_64-linux, ok for trunk?
Index: cp/parser.c
==
On Sat, May 14, 2011 at 22:40, Janne Blomqvist
wrote:
> Hi
>
> the current version of showing the backtrace is not async-signal-safe
> as it uses backtrace_symbols() which, in turn, uses malloc(). The
> attached patch changes the backtrace printing functionality to instead
> use backtrace_symbols_
31 matches
Mail list logo
