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.
(arm_coproc
OK.
Jason
The reported problem was due to creating a CONSTRUCTOR with pointer
type, expecting it to be an array; now we only build a CONSTRUCTOR for
array type. While I was looking at this issue I noticed that the
user-defined type case also had problems, because it was still using T()
instead of {} to
On 06/20/2011 10:23 AM, Jason Merrill wrote:
strip_typedefs needs to propagate DECL_USER_ALIGN as well as attributes
in the attribute list.
...except that we don't want to retain attributes on template type
arguments, since they aren't part of mangling, so you could get a class
template insta
This fixes bugs introduced by r175063. OK for trunk if there are no
test regressions?
-Easwaran
2011-06-20 Easwaran Raman
PR rtl-optimization/49429
* expr.c (emit_block_move_hints): Mark MEM_EXPR(x) and
MEM_EXPR(y) addressable if emit_block_move_via_libcall is
On Tue, Jun 21, 2011 at 12:29:01AM +0200, Janus Weil wrote:
> 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).
We were streaming out the original names_size which includes the
built-in names which are not streamed out.
This only streams out the actual number of streamed names as names_size.
It appears names_size is not even used anywhere in the code
(or at least I couldn't find any use of it with `grep "n
Richard Henderson wrote:
>On 06/20/2011 04:39 PM, H. Peter Anvin wrote:
>> sys_foo:
>> cmpl$10, %edi
>> jae .L1
>>
>> movqfoo_table(,%rdi,3), %rax
>> retq
>> .L1:
>> movq$-EINVAL, %rax
>> retq
>>
>> Enter this function with a non-normalized %rdi and
On 06/20/2011 05:33 PM, Richard Henderson wrote:
> The current code generation for -mflat uses 3 insn patterns
> which emit up two three insns (sort of) emulating the save
Lest I get sent back for remedial English, that was supposed
to be "emit two or three" but fingers got ahead of brain.
r~
The current code generation for -mflat uses 3 insn patterns
which emit up two three insns (sort of) emulating the save
instruction.
The problem is that the unwind info is only produced at the
end of any pattern, leaving a 1 or 2 insn hole for which the
unwind info is not correct.
I tried to figur
On Tue, Jun 7, 2011 at 1:50 PM, H.J. Lu wrote:
> On Wed, Jun 1, 2011 at 2:23 AM, Ira Rosen wrote:
>> Hi,
>>
>> The vectorizer expects widening multiplication pattern to be:
>>
>> type a_t, b_t;
>> TYPE a_T, b_T, prod_T;
>>
>> a_T = (TYPE) a_t;
>> b_T = (TYPE) b_t;
>> prod_T =
On 06/20/2011 04:39 PM, H. Peter Anvin wrote:
> sys_foo:
> cmpl$10, %edi
> jae .L1
>
> movqfoo_table(,%rdi,3), %rax
> retq
> .L1:
> movq$-EINVAL, %rax
> retq
>
> Enter this function with a non-normalized %rdi and you have a security
> hole even
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
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
wrote:
> On Mon, Jun 20, 2011 at 6:15 PM, Xin
>
> 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
> rega
On 06/20/2011 03:53 PM, Andrew MacLeod wrote:
> On 06/20/2011 06:33 PM, Richard Henderson wrote:
> If you want to standardize it with SYNC_ for all cases, I will create all
> the new ones that way.
I do think the name of all the bits related to handling a builtin
function should match the builti
On 06/20/2011 06:33 PM, Richard Henderson wrote:
On 06/20/2011 09:22 AM, Andrew MacLeod wrote:
builtins.c:expand_builtin_lock_test_and_set (enum machine_mode mode, tree exp,
builtins.c:case BUILT_IN_LOCK_TEST_AND_SET_1:
builtins.c:case BUILT_IN_LOCK_TEST_AND_SET_2:
builtins.c:case BU
On 06/20/2011 07: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.
>
> No. Pr
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 t
On 06/20/2011 09:22 AM, Andrew MacLeod wrote:
> builtins.c:expand_builtin_lock_test_and_set (enum machine_mode mode, tree exp,
> builtins.c:case BUILT_IN_LOCK_TEST_AND_SET_1:
> builtins.c:case BUILT_IN_LOCK_TEST_AND_SET_2:
> builtins.c:case BUILT_IN_LOCK_TEST_AND_SET_4:
>
> whereas eve
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
> -Original Message-
> From: Joseph Myers [mailto:jos...@codesourcery.com]
> Sent: Monday, June 20, 2011 4:03 PM
> To: Weddington, Eric
> Cc: Georg-Johann Lay; gcc-patches@gcc.gnu.org; cherty...@gmail.com;
> ae...@post.ru
> Subject: RE: Remove TARGET_HELP hook
>
> On Mon, 20 Jun 2011, We
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 load/st
Thanks,
Patch has been committed to trunk as revision 175230.
Changpeng
From: Uros Bizjak [ubiz...@gmail.com]
Sent: Monday, June 20, 2011 1:38 PM
To: Fang, Changpeng
Cc: H.J. Lu; gcc-patches@gcc.gnu.org; hubi...@ucw.cz; rguent...@suse.de
Subject: Re: [PATC
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, a
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 tai
On Mon, Jun 20, 2011 at 03:54:59PM +0200, Jakub Jelinek wrote:
> 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 t
> -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
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
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 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[
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 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
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
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 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
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
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
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:
>> > +
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.
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
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
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
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 -
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 *-*
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
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
> 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
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 benchmarks on lates
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
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, 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
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 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
> -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
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
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
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
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
-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
[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
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 -
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 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]
-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 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
"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 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
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 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, 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 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
*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, 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
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.
>
-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 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
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
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:
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
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
>
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
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
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
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
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
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
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
>
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
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 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: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
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 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
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
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
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
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
--
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
1 - 100 of 127 matches
Mail list logo
