On Fri, 17 Jun 2011 11:41:21 +0200
Pierre Vittet pier...@pvittet.com wrote:
Thoses two patchs have already been approved (see
http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01159.html).
I haven't write permission currently, could someone commit them?
ChangeLogs have to be applied on
On Fri, 17 Jun 2011, Michael Matz wrote:
Hi,
On Thu, 16 Jun 2011, Richard Guenther wrote:
If people want to not create useless conversions in the first place,
though, I suspect there are lots of places that create useless
conversions in the compiler.
Yeah, the above looks it
Hello,
this patch adds to fold_binary_loc some missing optimization for binary
and operations on truth-not expressions.
Added cases are:
(!X X) is always zero.
(X !X) is always zero.
(X == 0) X is always zero.
X (X == 0) is always zero.
!X 1 is X == 0
ChangeLog
2011-06-20 Kai Tietz
2011/6/17 Jeff Law l...@redhat.com:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/17/11 08:12, Zdenek Dvorak wrote:
if we do, we definitely should not -- the only point of such a
construction is
to bypass the pointer arithmetics restrictions,
Ok, we don't. Where does the C
The following patch
[build, libgcc] Correctly apply c_flags in shared-object.mk
http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01055.html
has remained unreviewed for a week. It needs a libgcc or build
maintainer to review.
Thanks.
Rainer
--
Mike Stump mikest...@comcast.net writes:
On Jun 17, 2011, at 10:47 AM, Nathan Froyd wrote:
I've done a lot of g++-only testsuite runs lately
I think it is reasonable to have even more of them, say, if you have
16 cores and just test c++... I wonder what the scaling is like as we
approach
Hi,
tested x86_64-linux, committed to mainline.
Thanks,
Paolo.
PS: Dodji, this is the tricky C++ issue we were talking about.
2011-06-20 Daniel Krugler daniel.krueg...@googlemail.com
Paolo Carlini paolo.carl...@oracle.com
* include/std/tuple (__conv_types,
On Sat, Jun 18, 2011 at 9:03 PM, Easwaran Raman era...@google.com wrote:
The gimple for test2_31 before RTL expansion contains:
# .MEMD.2034_2 = VDEF .MEMD.2034_1(D)
s1D.2035 = s1D.1255;
The RHS is a PARM_DECL. It doesn't have TREE_ADDRESSABLE and the LHS
has, which makes sense. But then
On Sat, Jun 18, 2011 at 10:56 AM, Xinliang David Li davi...@google.com wrote:
Compiling the test case in the patch with -O2 -m32 without the fix,
the program will abort. The problem is a var decl whose address is
taken is not marked as addressable leading to bad SSA update (missing
VUSE).
On Sun, Jun 19, 2011 at 2:51 PM, Jan Hubicka hubi...@ucw.cz wrote:
On Sat, 11 Jun 2011, Jan Hubicka wrote:
Hi,
this patch complettes the same body alias rework by removing the old
same body
alias code and adding new representation. Same body aliases are now
separate
On several platforms (e.g. Solaris 10/x86), several gnattools fail to
link:
Undefined first referenced
symbol in file
libintl_gettext ../../libcommon.a(diagnostic.o)
libintl_textdomain
On Mon, Jun 20, 2011 at 1:24 AM, Eric Botcazou ebotca...@adacore.com wrote:
if T is a non-volatile composite type with volatile components, and O is an
object of type T, are the optimizers allowed to remove the assignment O :=
O?
Good question, that I'm not really qualified to answer. Any
On Mon, Jun 20, 2011 at 12:23 PM, Kai Tietz ktiet...@googlemail.com wrote:
Hello,
this patch adds to fold_binary_loc some missing optimization for binary
and operations on truth-not expressions.
Added cases are:
(!X X) is always zero.
(X !X) is always zero.
(X == 0) X is always zero.
I had long meant to revisit libmudflap support on Solaris and finally
got to it this weekend.
libmudflap could always be used with GNU ld since it relies on --wrap,
but recent builds of Solaris 11 (snv_125 and up) include -z wrap/--wrap
support in the Sun linker, too.
One generic issue came up
2011/6/20 Richard Guenther richard.guent...@gmail.com:
On Mon, Jun 20, 2011 at 12:23 PM, Kai Tietz ktiet...@googlemail.com wrote:
Hello,
this patch adds to fold_binary_loc some missing optimization for binary
and operations on truth-not expressions.
Added cases are:
(!X X) is always zero.
Hi,
This fixes PR49385. We were allowing mem - mem moves earlier. Thanks
to Revital for spotting this. Tested on qemu with arm-linux-gnueabi
cross and committed to trunk.
Cheers
Ramana
2011-06-20 Ramana Radhakrishnan ramana.radhakrish...@linaro.org
PR target/49385
*
I don't think we should move this kind of undefinedness from C to
the GIMPLE semantics. What do other languages allow that
we have to support (what did KR C specify?).
I don't think there is a formal specification of KR C, just the (somewhat
informal) book. On topic of pointer arithmetics,
I don't think we should move this kind of undefinedness from C to
the GIMPLE semantics. What do other languages allow that
we have to support (what did KR C specify?).
I don't think there is a formal specification of KR C, just the (somewhat
informal) book. On topic of pointer
As the next step in moving libgcc parts to toplevel libgcc, this patch
moves unwinder-related files and configuration. Since the patch affects
many parts of the compiler and targets I cannot test, I'm liberally
copying the affected maintainers.
Overall, what the patch does is simple:
* Move all
On Mon, Jun 20, 2011 at 2:25 PM, Zdenek Dvorak rakd...@kam.mff.cuni.cz wrote:
I don't think we should move this kind of undefinedness from C to
the GIMPLE semantics. What do other languages allow that
we have to support (what did KR C specify?).
I don't think there is a formal
Hi,
This patch removes ix86/avx branch and mentions avx2 branch. OK
to install?
H.J.
Index: svn.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/svn.html,v
retrieving revision 1.162
diff -u -p -r1.162 svn.html
--- svn.html3 Jun
On 06/17/2011 08:20 PM, Mike Stump wrote:
On Jun 17, 2011, at 10:47 AM, Nathan Froyd wrote:
I've done a lot of g++-only testsuite runs lately
I think it is reasonable to have even more of them, say, if you have 16 cores
and just test c++... I wonder what the scaling is like as we approach
Hi,
On Mon, 20 Jun 2011, Richard Guenther wrote:
of the specifications; rather, we should consider whether there is a
situation where a user could reasonably expect NULL + 0 to be valid.
In the example by Richard,
int __attribute__((noinline)) foo (void *p, int i)
{
return p +
On Jun 20, 2011, at 4:06 AM, Rainer Orth wrote:
I've got a patch to do this, prompted by the use of UltraSPARC-T2
machines with 8 cores/8 strands which are quite slow on their own:
[build, testsuite, v3] Increase gcc, g++, gfortran and libstdc++-v3
testsuite parallelism
On Jun 20, 2011, at 6:41 AM, Rainer Orth wrote:
Christian Bruel christian.br...@st.com writes:
2011-06-16 Christian Bruel christian.br...@st.com
PR 49139/43654
Please use the correct PR number format here:
PR middle-end/49139
PR middle-end/43654
Otherwise
On 06/20/2011 03:51 PM, H.J. Lu wrote:
Promote pointers to Pmode when passing/returning in registers is
a security concern.
Whuh?
* combine.c (cant_combine_insn_p): Check zero/sign extended
hard registers.
This part is OK.
Bernd
On Mon, Jun 20, 2011 at 09:28:56AM -0400, Jason Merrill wrote:
On 06/17/2011 08:20 PM, Mike Stump wrote:
On Jun 17, 2011, at 10:47 AM, Nathan Froyd wrote:
I've done a lot of g++-only testsuite runs lately
I think it is reasonable to have even more of them, say, if you have 16
cores and
On 06/20/2011 03:41 PM, Rainer Orth wrote:
Christian Bruelchristian.br...@st.com writes:
2011-06-16 Christian Bruelchristian.br...@st.com
PR 49139/43654
Please use the correct PR number format here:
PR middle-end/49139
PR middle-end/43654
Otherwise the
On Mon, Jun 20, 2011 at 6:53 AM, Bernd Schmidt ber...@codesourcery.com wrote:
On 06/20/2011 03:51 PM, H.J. Lu wrote:
Promote pointers to Pmode when passing/returning in registers is
a security concern.
Whuh?
Peter, do you think it is safe to assume upper 32bits are zero in
user space for
The PR pointed out that explicit conversion operators are more
restricted than normal ones even in direct-initialization; the return
type must be convertible to the target type with no more than a
qualification conversion.
Tested x86_64-pc-linux-gnu, applying to trunk
commit
strip_typedefs needs to propagate DECL_USER_ALIGN as well as attributes
in the attribute list.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit fd43d02986ccbd7c43014ea093fe06f94d3d0af7
Author: Jason Merrill ja...@redhat.com
Date: Sun Jun 19 22:20:03 2011 -0400
PR c++/48138
*
A variadic template can take no arguments, so it's a default constructor.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 9f50baae331019464a94de275ae370cfebb30600
Author: Jason Merrill ja...@redhat.com
Date: Sun Jun 19 21:55:11 2011 -0400
PR c++/49205
* call.c
If we see an enum as a scope for a declarator-id, we should avoid
setting ctype in the first place as it can't possibly be right.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 5800b6d699b10f0c15355b8f37fa9beb7957ea72
Author: Jason Merrill ja...@redhat.com
Date: Sun Jun 19 22:38:46
C++0x specifies that a reference to reference produced by template
argument substitution collapses to a single reference.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit b66f8ede160d3f3375d7cd68988f3d498d51cc41
Author: Jason Merrill ja...@redhat.com
Date: Sun Jun 19 10:01:02 2011 -0400
Joseph S. Myers schrieb:
On Fri, 17 Jun 2011, Georg-Johann Lay wrote:
So here is my question: Would it be big deal to teach optabs to
expand plus:di, minus:di as libcall? Maybe even compare is
feasible? Like so:
I don't know what the best approach would be, but for just about
any
Here describable_type thought that a particular INDIRECT_REF was
describable, but it really wasn't. Fixed by removing describable_type
entirely; we can just try to deduce, and defer until instantiation if it
doesn't work.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit
Apparently it's ill-formed to explicitly specify a capture for a
variable that would be captured the same way by default, so I've added
this as a pedwarn.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit ec4717b67c17d8970828f4f9c81ac8794f65a44f
Author: Jason Merrill ja...@redhat.com
Date:
On 06/20/2011 07:01 AM, H.J. Lu wrote:
On Mon, Jun 20, 2011 at 6:53 AM, Bernd Schmidt ber...@codesourcery.com
wrote:
On 06/20/2011 03:51 PM, H.J. Lu wrote:
Promote pointers to Pmode when passing/returning in registers is
a security concern.
No. Promoting *NON*-pointers (or rather,
On Mon, Jun 20, 2011 at 8:06 AM, Jakub Jelinek ja...@redhat.com wrote:
On Mon, Jun 20, 2011 at 01:50:26PM +0200, Kai Tietz wrote:
Ok.
Richard.
Applied at revision 175206 to trunk.
There is no need to post such notices to gcc-patches, we have the gcc-cvs
mailing list where this is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/20/11 08:33, H. Peter Anvin wrote:
On 06/20/2011 07:01 AM, H.J. Lu wrote:
On Mon, Jun 20, 2011 at 6:53 AM, Bernd Schmidt ber...@codesourcery.com
wrote:
On 06/20/2011 03:51 PM, H.J. Lu wrote:
Promote pointers to Pmode when passing/returning
On Mon, Jun 20, 2011 at 7:33 AM, H. Peter Anvin h...@zytor.com wrote:
On 06/20/2011 07:01 AM, H.J. Lu wrote:
On Mon, Jun 20, 2011 at 6:53 AM, Bernd Schmidt ber...@codesourcery.com
wrote:
On 06/20/2011 03:51 PM, H.J. Lu wrote:
Promote pointers to Pmode when passing/returning in registers is
On Mon, 20 Jun 2011, Richard Guenther wrote:
On Sun, Jun 19, 2011 at 2:51 PM, Jan Hubicka hubi...@ucw.cz wrote:
On Sat, 11 Jun 2011, Jan Hubicka wrote:
Hi,
this patch complettes the same body alias rework by removing the old
same body
alias code and adding new
*PING*
On 06/16/2011 08:27 AM, Tobias Burnus wrote:
This patch adds ISO_Fortran_Env's LOCK_TYPE, tons of constraint checks
and a simple implementation for -fcoarray=single.
With the implementation of LOCK_TYPE and (UN)LOCK, gfortran can now
parse all coarrays constructs of Fortran 2008.
On Mon, Jun 20, 2011 at 10:37:30AM -0400, NightStrike wrote:
On Mon, Jun 20, 2011 at 8:06 AM, Jakub Jelinek ja...@redhat.com wrote:
On Mon, Jun 20, 2011 at 01:50:26PM +0200, Kai Tietz wrote:
Applied at revision 175206 to trunk.
There is no need to post such notices to gcc-patches, we have
On Mon, Jun 20, 2011 at 7:40 AM, Jeff Law l...@redhat.com wrote:
Peter, do you think it is safe to assume upper 32bits are zero in
user space for x32? Kernel isn't a problem since pointer is 64bit
in kernel and we don't pass pointers on stack to kernel.
As I have already stated, if we
On Sun, Jun 19, 2011 at 11:04:12PM -0400, David Edelsohn wrote:
On Sun, Jun 19, 2011 at 10:03 AM, Alan Modra amo...@gmail.com wrote:
* config/rs6000/rs6000.c (create_TOC_reference): Wrap high part
of toc-relative address in CONST.
(rs6000_delegitimize_address):
On Mon, 20 Jun 2011, Rainer Orth wrote:
* Move all remaining unwinder-only macros to libgcc: UNW_IVMS_MODE,
MD_UNW_COMPATIBLE_PERSONALITY_P, MD_FROB_UPDATE_CONTEXT.
I don't see any sign of macros being poisoned in system.h. For macros
used in target-independent unwinder code - at least
On Mon, 20 Jun 2011, Matthias Klose wrote:
- PR45078; vxworks-dummy.h is included for cpu_type in arm,
i386, mips, sh and sparc but only installed when it's i386; copy it
manually anytime.
I don't think you should list particular config/ headers in PLUGIN_HEADERS
in Makefile.in;
Joseph S. Myers jos...@codesourcery.com writes:
On Mon, 20 Jun 2011, Rainer Orth wrote:
* Move all remaining unwinder-only macros to libgcc: UNW_IVMS_MODE,
MD_UNW_COMPATIBLE_PERSONALITY_P, MD_FROB_UPDATE_CONTEXT.
I don't see any sign of macros being poisoned in system.h. For macros
On 06/20/2011 07:43 AM, H.J. Lu wrote:
On Mon, Jun 20, 2011 at 7:33 AM, H. Peter Anvin h...@zytor.com wrote:
On 06/20/2011 07:01 AM, H.J. Lu wrote:
On Mon, Jun 20, 2011 at 6:53 AM, Bernd Schmidt ber...@codesourcery.com
wrote:
On 06/20/2011 03:51 PM, H.J. Lu wrote:
Promote pointers to Pmode
On Mon, 20 Jun 2011, Rainer Orth wrote:
Certainly: your wiki entry gives a good overview. For the moment, I'll
probably concentrate on the build side of things, though. I may attack
gthr* stuff and fp-bit.[ch] next, both of which I can at least partially
test on my targets.
fp-bit.[ch] has
On Mon, Jun 20, 2011 at 10:47 AM, Jakub Jelinek ja...@redhat.com wrote:
On Mon, Jun 20, 2011 at 10:37:30AM -0400, NightStrike wrote:
On Mon, Jun 20, 2011 at 8:06 AM, Jakub Jelinek ja...@redhat.com wrote:
On Mon, Jun 20, 2011 at 01:50:26PM +0200, Kai Tietz wrote:
Applied at revision 175206 to
On 06/20/2011 07:20 AM, Georg-Johann Lay wrote:
A libcall could be added in TARGET_INIT_LIBCALLS, so a new hook is not
needed. All that's needed is that optabs tests for presence of such
an entry and prefers it over inline expansion (and prefers insn over
libcall). It appears that + and -
[Dropping the target maintainers from the Cc: since this isn't relevant
to the patch at hand.]
Joseph S. Myers jos...@codesourcery.com writes:
On Mon, 20 Jun 2011, Rainer Orth wrote:
Certainly: your wiki entry gives a good overview. For the moment, I'll
probably concentrate on the build
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/20/11 09:34, NightStrike wrote:
On Mon, Jun 20, 2011 at 10:47 AM, Jakub Jelinek ja...@redhat.com wrote:
On Mon, Jun 20, 2011 at 10:37:30AM -0400, NightStrike wrote:
On Mon, Jun 20, 2011 at 8:06 AM, Jakub Jelinek ja...@redhat.com wrote:
On
When moving hooks used in opts.c to the common hooks structure so they
can be called from the driver, I did not move the TARGET_HELP hook
because this hook is obsoleted by the generic Enum .opt facility (only
being used to print list of enumerated arguments to options).
Instead, this patch
It is used to indicate the fact the var decl needs to have a memory
home (addressable) -- is there another way to do this? this is to
avoid the following situation:
1) after SRA before update SSA, the IR looks like:
MEM[ SR_123] = ...
other_var = SR_123; (x)
In this case,
On 06/17/2011 02:12 PM, Andrew MacLeod wrote:
--- machmode.h (working copy)
*** extern enum machine_mode ptr_mode;
*** 275,278
--- 275,291
/* Target-dependent machine mode initialization - in insn-modes.c. */
extern void init_adjust_machine_modes (void);
+ /*
Richard Henderson schrieb:
On 06/20/2011 07:20 AM, Georg-Johann Lay wrote:
A libcall could be added in TARGET_INIT_LIBCALLS, so a new hook is not
needed. All that's needed is that optabs tests for presence of such
an entry and prefers it over inline expansion (and prefers insn over
libcall).
-Original Message-
From: Joseph Myers [mailto:jos...@codesourcery.com]
Sent: Monday, June 20, 2011 9:47 AM
To: gcc-patches@gcc.gnu.org
Cc: cherty...@gmail.com; ae...@post.ru; Weddington, Eric
Subject: Remove TARGET_HELP hook
When moving hooks used in opts.c to the common hooks
On Wed, 18 May 2011, Joseph S. Myers wrote:
On Wed, 18 May 2011, DJ Delorie wrote:
At this point, though, I'm tempted to say there's no such thing as a
target libiberty and rip all the target-libiberty rules out, and let
Yes please. I've been arguing for that for some time.
2011/6/20 Weddington, Eric eric.wedding...@atmel.com:
-Original Message-
From: Joseph Myers [mailto:jos...@codesourcery.com]
Sent: Monday, June 20, 2011 9:47 AM
To: gcc-patches@gcc.gnu.org
Cc: cherty...@gmail.com; ae...@post.ru; Weddington, Eric
Subject: Remove TARGET_HELP hook
On Mon, 20 Jun 2011, Weddington, Eric wrote:
I assume that this new method still prints out the avr mcu list in a
similar fashion?
Yes. Any enumerated options get such lists printed as long as there is a
help text on the Enum entry in the .opt file.
--
Joseph S. Myers
Is it ok to backport patches, with Changelogs below, already in trunk to gcc
4.6? These patches are for AVX-256bit load store splitting. These patches
make significant performance difference =3% to several CPU2006 and
Polyhedron benchmarks on latest AMD and Intel hardware. If ok, I will post
On Mon, 20 Jun 2011, Hans-Peter Nilsson wrote:
It seems none in approval capacity have any objection to
(figuratively) s/target-libiberty//g in toplevel/configure.ac on
all branches. Is an --enable-target-libiberty or
--with-target-libiberty needed? (I'd just rather not.)
There should be
On Mon, Jun 20, 2011 at 9:58 AM, harsha.jaga...@amd.com wrote:
Is it ok to backport patches, with Changelogs below, already in trunk to gcc
4.6? These patches are for AVX-256bit load store splitting. These patches
make significant performance difference =3% to several CPU2006 and
Polyhedron
On Mon, Jun 20, 2011 at 9:58 AM, harsha.jaga...@amd.com wrote:
Is it ok to backport patches, with Changelogs below, already in trunk
to gcc
4.6? These patches are for AVX-256bit load store splitting. These
patches
make significant performance difference =3% to several CPU2006 and
On Thu, Apr 28, 2011 at 01:20, Michael Witten mfwit...@gmail.com wrote:
See the following emails for a few inlined patches
to /trunk/gcc/doc/extend.texi (revision 172911):
[1] Docs: extend.texi: Add missing semicolon for consistency
[2] Docs: extend.texi: Remove trailing blanks from lines
Hi,
I checked this patch into x32 branch.
H.J.
---
commit f68fa52c0474cbacd8c2e0cf41d2f472baebdf7c
Author: H.J. Lu hjl.to...@gmail.com
Date: Wed Jun 15 11:26:28 2011 -0700
Also allow x32 for gcc.dg/pr44194-1.c.
diff --git a/gcc/testsuite/ChangeLog.x32 b/gcc/testsuite/ChangeLog.x32
index
I had long meant to do another round of cleanups of the Solaris
configuration, which has much duplication and inconsistencies between
the SPARC and x86 versions.
The following patch is the result of this work. It consists of several
parts:
* Move the common Solaris parts in config.gcc to the
On Jun 20, 2011, at 8:38 AM, Jeff Law wrote:
do not need != cannot
This has been discussed several times. So no, this noise isn't at all
useful nor welcome.
useful or welcome TO YOU. Obviously, it's useful to us.
Umm, it's neither welcome nor useful to many folks -- that's why the
Joseph S. Myers schrieb:
When moving hooks used in opts.c to the common hooks structure so they
can be called from the driver, I did not move the TARGET_HELP hook
because this hook is obsoleted by the generic Enum .opt facility (only
being used to print list of enumerated arguments to
Hi,
I modified the patch as H.J. suggested (patch attached).
Is it OK to commit to trunk now?
Thanks,
Changpeng
From: H.J. Lu [hjl.to...@gmail.com]
Sent: Friday, June 17, 2011 5:44 PM
To: Fang, Changpeng
Cc: Richard Guenther; gcc-patches@gcc.gnu.org
On Mon, Jun 20, 2011 at 8:03 PM, Fang, Changpeng changpeng.f...@amd.com wrote:
I modified the patch as H.J. suggested (patch attached).
Is it OK to commit to trunk now?
Yes, this is OK for trunk.
Thanks,
Uros.
On Mon, Jun 20, 2011 at 7:19 AM, William J. Schmidt
wschm...@linux.vnet.ibm.com wrote:
On Thu, 2011-06-16 at 09:49 -0700, Richard Henderson wrote:
On 06/16/2011 04:35 AM, Richard Guenther wrote:
+ /* Bit-field insertion needs several shift and mask operations. */
+ case
On 06/20/2011 12:38 PM, Bernd Schmidt wrote:
D'oh. Blackfin has a (clrsb:HI (operand:SI)) instruction, so adding this
showed a problem with some of the existing simplify_const_unop cases:
for ffs/clz/ctz/clrsb/parity/popcount, we should look at the mode of the
operand, rather than the mode of
Variants of scan-assembler, used in the dg-final steps of a test, do
not check that the output file exists, so it's reported as an error.
With this patch, if the file is missing then the check is reported as
unresolved using the same message as for pass/fail, and the reason for
the unresolved test
On Mon, Jun 20, 2011 at 6:15 PM, Xinliang David Li davi...@google.com wrote:
It is used to indicate the fact the var decl needs to have a memory
home (addressable) -- is there another way to do this? this is to
avoid the following situation:
1) after SRA before update SSA, the IR looks like:
On Mon, Jun 20, 2011 at 8:43 PM, Andrew Pinski pins...@gmail.com wrote:
On Mon, Jun 20, 2011 at 7:19 AM, William J. Schmidt
wschm...@linux.vnet.ibm.com wrote:
On Thu, 2011-06-16 at 09:49 -0700, Richard Henderson wrote:
On 06/16/2011 04:35 AM, Richard Guenther wrote:
+ /* Bit-field
On Mon, Jun 20, 2011 at 1:54 PM, Richard Guenther
richard.guent...@gmail.com wrote:
Yeah, well. We have mostly no target dependency in those gimple
statement speed/size cost metric, so the above 3 is matching
how the expansion to gimple shift/mask stmts would measure.
Except RTH has mentioned
-Original Message-
From: Joseph Myers [mailto:jos...@codesourcery.com]
Sent: Monday, June 20, 2011 1:20 PM
To: Georg-Johann Lay
Cc: gcc-patches@gcc.gnu.org; cherty...@gmail.com; ae...@post.ru;
Weddington, Eric
Subject: Re: Remove TARGET_HELP hook
On Mon, 20 Jun 2011,
Dear Paul,
Paul Richard Thomas wrote:
I have checked out the code for any obvious style or other minor
errors and all looks well. However, I had a look at 8.5.6 LOCK and
UNLOCK statements in the standard and can only confess to feeling
very stupid tonight because I could not make head nor tail
On Mon, 20 Jun 2011, Weddington, Eric wrote:
As it's auto-generated: must it reside in repository?
The machinery for selecting .opt files to use and for using them (both in
the compiler and in .pot generation) expects them all to be in the source
directory.
Right. So, as I
The patch that disables default setting of unaligned load splitting for bdver1
has been committed
to trunk as revision 175230.
Here is the patch: http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01518.html.
H. J., is there anything else that is pending to fix at this moment regarding
avx256
Hi all,
while I continue working on some of the yet unsolved parts of this PR,
I'm already posting a simple patch which fixes the part with
duplicate save warnings on CLASS variables (which is a regression on
4.6 and trunk). The warnings are silenced by making the vtab and
default initialization
This patch speeds up the C/C++/ObjC/ObjC++ compiler a little bit by optimizing
lookup_attribute() and is_attribute_p(). The main change is that these
functions
are now inline.
Benchmarking the C compiler (--enable-checking=release) compiling postgresql
from
source shows that total compilation
The patch that disables default setting of unaligned load splitting
for bdver1 has been committed
to trunk as revision 175230.
Here is the patch: http://gcc.gnu.org/ml/gcc-patches/2011-
06/msg01518.html.
H. J., is there anything else that is pending to fix at this moment
regarding
Good point -- but why does SRA have to be so complicated? If it just
do structure expansion and let subsequent phases to clean it up, would
it be simpler? Anyway this is off the topic.
Thanks,
David
On Mon, Jun 20, 2011 at 1:47 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Mon,
On 06/20/2011 03:49 PM, Richard Henderson wrote:
As I have already stated, if we *cannot* require pointers to be
zero-extended on entry to the kernel, we're going to have to have
special entry points for all the x32 system calls except the ones that
don't take pointers.
If it's a security
Hi,
This patch maintains iWMMXT intrinsics code,
adds WMMX pipeline description
and supports iWMMXT auto-vectorization.
Ran Arm testsuite on arm-linux-gnueabi.
*gcc/config/arm/elf.h: Add option -mwmmxt.
*gcc/config/arm/arm.opt: Same.
*gcc/config/arm/arm.c (arm_option_override): Same.
90 matches
Mail list logo
