On Fri, 17 Jun 2011 11:41:21 +0200
Pierre Vittet 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 gcc/c-family/ChangeL
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, th
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
operation supported by GCC it makes
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 Tie
2011/6/17 Jeff Law :
> -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 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 larger N. :-)
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
Paolo Carlini
* include/std/tuple (__conv_types, __one_by_one_convertible,
__all_convertible): Add.
(
On Sat, Jun 18, 2011 at 9:03 PM, Easwaran Raman 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 the move
On Sat, Jun 18, 2011 at 10:56 AM, Xinliang David Li 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). (the triaging used
On Sun, Jun 19, 2011 at 2:51 PM, Jan Hubicka 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
>> > > separat
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 ../../libcommon.a(intl.o)
On Mon, Jun 20, 2011 at 1:24 AM, Eric Botcazou 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 language lawye
On Mon, Jun 20, 2011 at 12:23 PM, Kai Tietz 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.
> X & (X ==
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 wi
2011/6/20 Richard Guenther :
> On Mon, Jun 20, 2011 at 12:23 PM, Kai Tietz 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
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 automatically posted to.
On gcc-patches it just adds unnecessary noise.
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
PR target/49385
* config/arm/thumb2.md (*thumb2_movhi_insn
> 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 K&R C specify?).
I don't think there is a formal specification of K&R C, just the (somewhat
informal) book. On topic of pointer arithmetic
> > 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 K&R C specify?).
>
> I don't think there is a formal specification of K&R C, just the (somewhat
> informal) book. On topic of pointe
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 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 K&R C specify?).
>>
>> I don't think there is a formal specification of K&R
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 la
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)
> > {
> >
In addition to the approved part of the patch, I finally got the
testsuite and a full Linux distribution to build without false warnings,
with the additional following changes:
* two false warnings detected during a Linux distrib rebuild
- __typeof (__error) doesn't propagate the inline keyw
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
>h
Hi,
On Sun, 19 Jun 2011, William J. Schmidt wrote:
> At the risk of being obvious...it seems you could easily combine C1 and
> C2 into a single "bitfield descriptor" TREE_INT_CST operand by using
> both the high and low portions of the constant. Accessor macros could
> be used to hide the sli
Christian Bruel writes:
> 2011-06-16 Christian Bruel
>
> PR 49139/43654
Please use the correct PR number format here:
PR middle-end/49139
PR middle-end/43654
Otherwise the check-in notices don't get into the PRs.
Thanks.
Rainer
--
Two issues with the installation of plugin header files.
- the c-family/* headers are used with the the c-family/ prefix
in include directives. therefore they must not installed into
the flattened plugin include dir, but kept in the subdir.
- PR45078; vxworks-dummy.h is included for cpu_t
PR34734 produces annoying, false warnings if __attribute__((progmem))
is used in conjunction with C++. DECL_INITIAL is not yet set up in
avr_handle_progmem_attribute.
Johann
PR target/34734
* config/avr/avr.c (avr_handle_progmem_attribute): Move warning
about uninitialize
On Mon, Jun 20, 2011 at 3:32 PM, Christian Bruel wrote:
> In addition to the approved part of the patch, I finally got the testsuite
> and a full Linux distribution to build without false warnings, with the
> additional following changes:
>
> * two false warnings detected during a Linux distrib re
On Jun 20, 2011, at 6:41 AM, Rainer Orth wrote:
> Christian Bruel writes:
>
>> 2011-06-16 Christian Bruel
>>
>> PR 49139/43654
>
> Please use the correct PR number format here:
>
> PR middle-end/49139
>PR middle-end/43654
>
> Otherwise the check-in notices don't get
Promote pointers to Pmode when passing/returning in registers is
a security concern. This patch removes ix86_promote_function_mode,
which exposes:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47725
There are 2 different patches for PR 47725:
http://gcc.gnu.org/ml/gcc-patches/2011-02/threads.html
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
> >co
On 06/20/2011 03:41 PM, Rainer Orth wrote:
Christian Bruel writes:
2011-06-16 Christian Bruel
PR 49139/43654
Please use the correct PR number format here:
PR middle-end/49139
PR middle-end/43654
Otherwise the check-in notices don't get into the PRs.
OK
On Mon, Jun 20, 2011 at 6:53 AM, Bernd Schmidt 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 x32? Kernel isn't
Hi,
On Sun, 19 Jun 2011, Mike Stump 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 language
>
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 8f60db54d602164cda
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 BIT_FIELD_EXPR:
> > + return 3;
>
> ... depending on the target, of course.
>
Agre
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
Date: Sun Jun 19 22:20:03 2011 -0400
PR c++/48138
* tree.c (strip_type
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
Date: Sun Jun 19 21:55:11 2011 -0400
PR c++/49205
* call.c (sufficient_parms_p): Allow param
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
Date: Sun Jun 19 22:38:46 2011 -0400
PR
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
Date: Sun Jun 19 10:01:02 2011 -0400
PR c++/3708
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
>
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 9ffe8ed0665020e0
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
Date: Sat Jun 18 15:
On 06/20/2011 07:01 AM, H.J. Lu wrote:
> On Mon, Jun 20, 2011 at 6:53 AM, Bernd Schmidt
> 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, requiring non-pointers
On Mon, Jun 20, 2011 at 8:06 AM, Jakub Jelinek 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 automatica
-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
>> wrote:
>>> On 06/20/2011 03:51 PM, H.J. Lu wrote:
Promote pointers to Pmode when passing/returning in register
On Mon, Jun 20, 2011 at 7:33 AM, 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
>> 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.
>
On Mon, 20 Jun 2011, Richard Guenther wrote:
> On Sun, Jun 19, 2011 at 2:51 PM, Jan Hubicka 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
*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. (Howe
On Mon, Jun 20, 2011 at 10:37:30AM -0400, NightStrike wrote:
> On Mon, Jun 20, 2011 at 8:06 AM, Jakub Jelinek 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 the gc
On Mon, Jun 20, 2011 at 7:40 AM, Jeff Law 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 *cannot*
On Sun, Jun 19, 2011 at 11:04:12PM -0400, David Edelsohn wrote:
> On Sun, Jun 19, 2011 at 10:03 AM, Alan Modra wrote:
> >* config/rs6000/rs6000.c (create_TOC_reference): Wrap high part
> >of toc-relative address in CONST.
> >(rs6000_delegitimize_address): Recognize changed
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 MD
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; pro
"Joseph S. Myers" 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
> used in target-i
On 06/20/2011 07:43 AM, H.J. Lu wrote:
> On Mon, Jun 20, 2011 at 7:33 AM, 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
>>> wrote:
On 06/20/2011 03:51 PM, H.J. Lu wrote:
> Promote pointers to Pmode when passing/returni
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/18/11 03:10, Ramana Radhakrishnan wrote:
> This seems to have triggered
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452
>
> on arm-linux-gnueabi
>
> Might well be a DUP of PR49429 but I haven't looked at it yet.
It is effectively a dupli
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]
On Mon, Jun 20, 2011 at 10:47 AM, Jakub Jelinek wrote:
> On Mon, Jun 20, 2011 at 10:37:30AM -0400, NightStrike wrote:
>> On Mon, Jun 20, 2011 at 8:06 AM, Jakub Jelinek wrote:
>> > On Mon, Jun 20, 2011 at 01:50:26PM +0200, Kai Tietz wrote:
>> >> Applied at revision 175206 to trunk.
>> >
>> > There
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" 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 side of things, tho
-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 wrote:
>> On Mon, Jun 20, 2011 at 10:37:30AM -0400, NightStrike wrote:
>>> On Mon, Jun 20, 2011 at 8:06 AM, Jakub Jelinek wrote:
On Mon, Jun 20, 2011 at 01:5
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 converts
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, SR
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);
+ /* Memory
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
>> l
> -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
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.
>
> h
2011/6/20 Weddington, Eric :
>
>
>> -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 movi
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
jos...@codesourcery
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
backp
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 b
On Mon, Jun 20, 2011 at 9:58 AM, 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 benchmarks on lates
Folks,
I think that implementation of the patch is not as good. It introduces
working with specific instructions in ix86_expand_multi_arg_builtin(),
however before it was really generic.
It operated only on abstract insns, only number/type of arguments was
matter. But now there’re INSN_CODE switche
> On Mon, Jun 20, 2011 at 9:58 AM, 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 bench
On Thu, Apr 28, 2011 at 01:20, Michael Witten 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
> [3] Docs: e
Hi,
I checked this patch into x32 branch.
H.J.
---
commit f68fa52c0474cbacd8c2e0cf41d2f472baebdf7c
Author: H.J. Lu
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 43af9dd..ab8dd76 100
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 -
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 optio
This is an optimization patch that implements extzv for 1-bit extracts.
The nice thing is that AVR can do this easily with a BLD/CLR/BST
sequence, without putting pressure on d-regs and without the
requirement of source being in the same register as destination.
extzv can also be seen in conjunct
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 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
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 BIT_FIELD_EXPR:
>> > +
Is it ok to backport patches, with Changelogs below, already in trunk to gcc
4.6? These patches are significant enough bugs fror recent AMD and Intel
hardware. If ok and unless the individual authors want to backport, I will
post backported patches for commit approval.
[PATCH] Handle misaligned TF
Dear Tobias,
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 of the
example. Thus, I
On Mon, 20 Jun 2011, Georg-Johann Lay wrote:
> > Index: gcc/config/avr/avr-tables.opt
> > ===
> > --- gcc/config/avr/avr-tables.opt (revision 0)
> > +++ gcc/config/avr/avr-tables.opt (revision 0)
>
> As it's auto-generated: must
Hello All,
Reference http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00477.html - I
am essentially pinging it, but improving the ChangeLog entry.
The attached patch to trunk 175201 makes cc1, cc1plus, ... lto1 also
search a language specific subdirectory.
# gcc/ChangeLog entry ##
2011-06-20
On 06/16/2011 06:25 PM, Richard Henderson wrote:
> On 06/16/2011 05:44 AM, Bernd Schmidt wrote:
>> +@deftypefn {Built-in Function} int __builtin_clrsb (unsigned int x)
>> +Returns the number of leading redundant sign bits in @var{x}, starting
>> +at the most significant bit position.
>> +@end defty
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
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 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:
>
> MEM[
On Mon, Jun 20, 2011 at 8:43 PM, Andrew Pinski wrote:
> On Mon, Jun 20, 2011 at 7:19 AM, William J. Schmidt
> 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
On Mon, Jun 20, 2011 at 1:54 PM, Richard Guenther
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 there is already a way
> -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, Ge
1 - 100 of 127 matches
Mail list logo
