Hi!
GCC on the following testcase warns
warning: use of memory input without lvalue in asm operand 0 is deprecated
[enabled by default]
starting with 4.6, but the source actually had an lvalue there (I don't
think we should forbid for input operands const qualified memory).
On "m" (1) in the sour
On 30/09/2011, at 4:02 PM, Maxim Kuvyrkov wrote:
> On 24/09/2011, at 2:19 AM, Martin Jambor wrote:
>
>> However, both of these are really 4.8 material and since the patches
>> probably need only minor updates, it might be worthwhile to do that so
>> that gcc can handle the "embarrassing" simple c
I updated the patch according to your comments. Ok now?
-Andi
gcc/lto/:
2011-09-29 H.J. Lu
Andi Kleen
PR lto/50568
* lto.c (lto_splay_tree_delete_id): New.
(lto_splay_tree_compare_ids): Likewise.
(lto_splay_tree_lookup): Likewise.
(lto_s
On 11-09-29 23:01 , Delesley Hutchins wrote:
This patch suppresses bogus warnings that are caused when annotalysis
is run with the IPA-SRA optimization (i.e. -O2 or higher). IPA-SRA
creates clones of functions in which some arguments have been eliminated,
even if those arguments are used in the
On 24/09/2011, at 2:19 AM, Martin Jambor wrote:
> However, both of these are really 4.8 material and since the patches
> probably need only minor updates, it might be worthwhile to do that so
> that gcc can handle the "embarrassing" simple cases. So I will do
> that (though it might need to wait
This patch suppresses bogus warnings that are caused when annotalysis
is run with the IPA-SRA optimization (i.e. -O2 or higher). IPA-SRA
creates clones of functions in which some arguments have been eliminated,
even if those arguments are used in the thread safety annotations;
this renders the att
On 11-09-29 20:57 , H.J. Lu wrote:
diff --git a/gcc/lto/lto.c b/gcc/lto/lto.c
index 77eb1a1..9c6770a 100644
--- a/gcc/lto/lto.c
+++ b/gcc/lto/lto.c
@@ -93,6 +93,93 @@ lto_obj_create_section_hash_table (void)
return htab_create (37, hash_name, eq_name, free_with_string);
}
+/* Delete a al
"H.J. Lu" writes:
> Hi,
>
> On 32bit hosts, like Linux/ia32, HOST_WIDE_INT is 64bit. But lto and
> lto-plugin still uses 32bit int in symbol ID handling. As the result,
> LTO is totally broken on Linux/ia32. This patch switches symbol ID
> to HOST_WIDE_INT in lto.c and long long in lto-plugin.
> -Original Message-
> From: Jakub Jelinek [mailto:ja...@redhat.com]
> Sent: Thursday, September 29, 2011 6:14 PM
> To: Jiangning Liu
> Cc: 'Richard Guenther'; Andrew Pinski; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] Fix stack red zone bug (PR38644)
>
> On Thu, Sep 29, 2011 at 06:08
Hi,
On 32bit hosts, like Linux/ia32, HOST_WIDE_INT is 64bit. But lto and
lto-plugin still uses 32bit int in symbol ID handling. As the result,
LTO is totally broken on Linux/ia32. This patch switches symbol ID
to HOST_WIDE_INT in lto.c and long long in lto-plugin.c. Since
symbol ID is generate
On 25/09/2011, at 11:21 PM, Jan Hubicka wrote:
>>
>> I wonder why we bother to record so many predicates though.
>
> Yep, I wonder if it comes from some real testcase? I didn't see functions
> that
> reach the limit and still be inlinable very often in practice.
This patch wasn't inspired by
Hello Ian,
I'll re-jig with the typographical changes (sorry that were so
many ... )
... and re-post - but I'd like to clear up a couple of points first.
On 30 Sep 2011, at 00:00, Ian Lance Taylor wrote:
-#define GNU_SECTION_NAMES "__section_names"
Are we sure it is OK to drop support for
Iain Sandoe writes:
This patch looks basically OK but it seems to have a number of
extraneous changes which make it harder to review.
> libiberty:
>
> PR target/48108
> * simple-object-mach-o.c (GNU_SECTION_NAMES): Remove.
> (GNU_WRAPPER_SECTS, GNU_WRAPPER_INDEX,
> GNU_
On 09/29/11 23:32, Vladimir Makarov wrote:
> Bernd, sorry for the delay.
No problem.
> I thought for long time about this approach because we already have
> selective scheduler which with some modifications could be used for
> this. Selective scheduler was implemented for Itanium, designed to
No problem. Will do.
-DeLesley
On Thu, Sep 29, 2011 at 2:44 PM, Diego Novillo wrote:
> On 11-09-29 17:24 , Delesley Hutchins wrote:
>>
>> That seems much cleaner! LGTM. Are you submitting the patch? I can
>> submit the test case.
>
> I tested it on an unclean tree, sorry. I'd rather leave
On 11-09-29 17:24 , Delesley Hutchins wrote:
That seems much cleaner! LGTM. Are you submitting the patch? I can
submit the test case.
I tested it on an unclean tree, sorry. I'd rather leave the testing and
final submit to you.
Thanks. Diego.
On 09/27/2011 08:36 AM, Bernd Schmidt wrote:
Ping:
http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00811.html
Bernd, sorry for the delay.
I thought for long time about this approach because we already have
selective scheduler which with some modifications could be used for
this. Selective sc
That seems much cleaner! LGTM. Are you submitting the patch? I can
submit the test case.
-DeLesley
On Thu, Sep 29, 2011 at 1:50 PM, Diego Novillo wrote:
> On 11-09-29 15:19 , Delesley Hutchins wrote:
>
>> However, I'm not convinced that it will work in all cases. I wish I
>> could come up
Hi!
On Mon, Sep 26, 2011 at 06:41:10PM +0200, Jakub Jelinek wrote:
> which would be invalid to call with foo (a, 32); given the above, but
> it isn't obvious to the compiler what value y has. With -DWORKAROUND
> the PT decls in (restr) look correct, without that not (supposedly because
> of the f
Hi!
This patch teaches PTA/aliasing about strdup/strndup (that the passed in
string is just read and doesn't escape in any way, and that otherwise it
acts as malloc or other allocation calls.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2011-09-29 Jakub Jelinek
Hi!
This patch implements a fold_range_test like optimization on GIMPLE, inside
tree-ssa-reassoc and tweaks fold-const.c so that most of the code can be
shared in between the two.
The advantage of the reassoc optimization is that it doesn't attempt to
merge just 2 ranges at a time, instead it sort
On 11-09-29 15:19 , Delesley Hutchins wrote:
However, I'm not convinced that it will work in all cases. I wish I
could come up with a test case, but like I said, I don't understand
enough about clones to understand what's happening here. If you are
confident that DECL_CLONED_FUNCTION_P is corr
For this month I tried many different heuristics of spilling and
assignment in LRA (about 10 of them, including spilling for inheritance
reloads). Here is the best what I found. The major idea is to assign
and spill for pseudos which are ordered by threads (set of reload
pseudos connected by
On 09/29/2011 01:19 PM, Dodji Seketeli wrote:
+ For a token that is /not/ an argument for a parameter of a
+ function-like macro, each yI is the spelling location of the Ith
+ token of the replacement-list in the definition of the macro.
+ "Spelling location" means the location of
The ICE occurs when decl is a TEMPLATE_DECL; that's the corner case
that causes a problem. The patch that you and Ollie suggest does stop
the ICE for our particular example; I assume because the template in
question is not a clone, and so the predicate fails further on.
However, I'm not convinced
From: Jakub Jelinek
Date: Thu, 29 Sep 2011 10:12:58 +0200
> On the other side, I'm surprised you don't need to prefix gcm_name with GCM:
> - when you have more than one mode iterator in a pattern, IMHO you should
> make it clear which mode you are talking about. Maybe it works, but which
> one i
On Wed, Sep 28, 2011 at 5:49 AM, Andi Kleen wrote:
> From: Andi Kleen
>
> I had some trouble with random build failures in a large LTO project
> and it turned out to be random seed collisions in a highly parallel build
> (thanks to Honza for suggesting that)
>
> There were multiple problems:
> -
On 09/29/2011 02:09 PM, Janus Weil wrote:
Hi all,
I just committed as obvious another pair of accepts-invalid fixes:
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179345
Also I would like to thank Vittorio for the large number of bug
reports he has been delivering lately. (I could make a c
Hi Guys,
I am applying the attached patch to fix the FRV backend so that the
frv-elf toolchain will build.
The patch to frv_function_prologue was actually created by Bernd, and
I have been using it in my local tree for some time now. It works
around a problem generating dwarf2 debug in
On 11-09-29 13:21 , Delesley Hutchins wrote:
I don't have a test case, but look at the definitions of the two
macros in cp/cp-tree.h. DECL_CLONED_FUNCTION_P calls
decl_cloned_function_p, passing true as the second argument, while
DECL_CLONED_FUNCTION makes the same call, but passes false. Now l
> OK. Here are some simple benchmarks. I simulated heavy use of
> reflection with 1000 classes that each had about a thousand base
> classes. I also created a super-simple typelist class
>
> template struct typelist {}; // Variadic templates rock
>
> If bases returns a typelist, the program take
I don't have a test case, but look at the definitions of the two
macros in cp/cp-tree.h. DECL_CLONED_FUNCTION_P calls
decl_cloned_function_p, passing true as the second argument, while
DECL_CLONED_FUNCTION makes the same call, but passes false. Now look
at the definition of decl_cloned_function_
2011/9/29 Georg-Johann Lay :
> This is the second patch in this series.
>
> Functions that formerly used fprintf/debug_rtx now use avr_edump and the use
> sites of TARGET_ALL_DEBUG are mapped to respective flags of avr_log.
>
> avr_log_vadump uses %b to print bool.
>
> The patch adds outputs for th
Richard,
in gimplify_vla_decl, the alloca argument seems to be the size of the vla in
units:
...
t = build_call_expr (t, 1, DECL_SIZE_UNIT (decl));
...
I wonder why we are going through this 8 vs. BITS_PER_UNIT conversion here:
...
elem_type = build_nonstandard_integer_type (BITS_PER_UNIT, 1
On Thu, 29 Sep 2011 17:10:26 +0200
Tristan Gingold wrote:
> Hi,
>
> DEC-C, the DEC compiler provided on VMS, has added to ANSI-C at least one
> extension that is difficult to work-around as it is used in the system
> headers: varargs without named argument. It makes sense on VMS because of
>
On Thu, Sep 29, 2011 at 11:26, Ollie Wild wrote:
> On Thu, Sep 29, 2011 at 10:13 AM, Delesley Hutchins
> wrote:
>>
>> Unfortunately, DECL_CLONED_FUNCTION_P is not actually a predicate that
>> allows you
>> to call DECL_CLONED_FUNCTION safely. Look at the definition of the macros;
>> despite
>
On Thu, Sep 29, 2011 at 10:13 AM, Delesley Hutchins wrote:
>
> Unfortunately, DECL_CLONED_FUNCTION_P is not actually a predicate that allows
> you to call DECL_CLONED_FUNCTION safely. Look at the definition of the
> macros; despite what the comments say, DECL_CLONED_FUNCTION_P may return true
On 09/29/2011 03:44 AM, Artem Shinkarov wrote:
> Here is a new version of the patch which hopefully fixes all the
> formatting issues and uses expand_simple_binop instead of force_reg in
> binary operations.
>
> Ok?
Well, it's certainly not perfect by any means. But I guess I can fix
things up m
Hi,
DEC-C, the DEC compiler provided on VMS, has added to ANSI-C at least one
extension that is difficult to work-around as it is used in the system headers:
varargs without named argument. It makes sense on VMS because of its ABI which
pass the number of arguments used.
This patch allows suc
I think what you're looking for is:
if (DECL_CLONED_FUNCTION_P (clone) && DECL_CLONED_FUNCTION (clone) == decl)
That's a much cleaner implementation.
Ollie
On Tue, Sep 27, 2011 at 6:18 PM, Delesley Hutchins wrote:
>
> This patch fixes a bug in the parser which cause an internal compiler
> erro
> No functional change, just factor out the common LIBGNAT_TARGET_PAIRS
> across the port.
> OK for trunk?
OK
> ada:
>
> * gcc-interface/Makefile.in (Darwin): Factor LIBGNAT_TARGET_PAIRS
> across the port.
No functional change, just factor out the common LIBGNAT_TARGET_PAIRS
across the port.
OK for trunk?
Iain
ada:
* gcc-interface/Makefile.in (Darwin): Factor LIBGNAT_TARGET_PAIRS
across the port.
Index: gcc/ada/gcc-interface/Makefile.in
==
On 19 September 2011 08:54, Ira Rosen wrote:
>
> Bootstrapped on powerpc64-suse-linux, tested on powerpc64-suse-linux
> and arm-linux-gnueabi
> OK for mainline?
Sorry I missed this patch. Is there any reason why we need unspecs in
this case ? Can't this be represented by subregs and zero/ sign
e
This is the second patch in this series.
Functions that formerly used fprintf/debug_rtx now use avr_edump and the use
sites of TARGET_ALL_DEBUG are mapped to respective flags of avr_log.
avr_log_vadump uses %b to print bool.
The patch adds outputs for the results of avr_rtx_costs and wraps the w
On 20 September 2011 11:12, Richard Sandiford
wrote:
> Ping for:
>
> http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00626.html
>
> which allows taking the vector subreg of a structure mode to be treated
> as "cheap" (because direct register references are allowed). At the
> moment we treat them
On 09/28/2011 11:53 AM, Richard Guenther wrote:
> On Wed, Sep 28, 2011 at 11:34 AM, Tom de Vries wrote:
>> Richard,
>>
>> I got a patch for PR50527.
>>
>> The patch prevents the alignment of vla-related allocas to be set to
>> BIGGEST_ALIGNMENT in ccp. The alignment may turn out smaller after fold
On Thu, Sep 29, 2011 at 3:02 PM, Jakub Jelinek wrote:
> Hi!
>
> On Mon, Sep 26, 2011 at 04:33:05PM +0200, Richard Guenther wrote:
>> Btw, can you add a changes.html entry for this?
>
> Like this?
Yes.
Thanks,
Richard.
> --- htdocs/gcc-4.7/changes.html 27 Sep 2011 18:42:56 - 1.38
> +++
Hi!
On Mon, Sep 26, 2011 at 04:33:05PM +0200, Richard Guenther wrote:
> Btw, can you add a changes.html entry for this?
Like this?
--- htdocs/gcc-4.7/changes.html 27 Sep 2011 18:42:56 - 1.38
+++ htdocs/gcc-4.7/changes.html 29 Sep 2011 12:56:42 -
@@ -124,6 +124,48 @@ void bar (void)
On Thu, 2011-09-29 at 10:03 +0100, Tobias Grosser wrote:
> On 09/29/2011 09:58 AM, Richard Guenther wrote:
> > On Thu, Sep 29, 2011 at 12:10 AM, William J. Schmidt
> > wrote:
> >> Hi there,
> >>
> >> Ping. I'm seeking approval for this fix on trunk and 4_6-branch.
> >> Thanks!
> >
> > Ok.
> Yes,
Hi all,
I just committed as obvious another pair of accepts-invalid fixes:
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179345
Also I would like to thank Vittorio for the large number of bug
reports he has been delivering lately. (I could make a comment about
his great talent for writing inv
On Thu, Sep 29, 2011 at 12:00 PM, Richard Guenther
wrote:
> On Wed, Sep 28, 2011 at 4:23 PM, Richard Guenther
> wrote:
>> On Mon, Sep 26, 2011 at 5:43 PM, Richard Guenther
>> wrote:
>>> On Mon, Sep 26, 2011 at 4:25 PM, Richard Guenther
>>> wrote:
On Wed, Sep 7, 2011 at 5:06 PM, Joseph S. M
2011/9/29 Georg-Johann Lay :
> Georg-Johann Lay wrote:
>> This is a tentative patch for better support of logging information for avr
>> BE
>> developers.
>>
>> There are situations where it is more convenient to let the compiler produce
>> information than to debug into the compiler. One example
This makes sure that opaque vector types are treated as compatible
with their non-opaque variant (something that they certainly should be).
I made them variant types instead of completely separate types,
also making sure we properly share them.
Bootstrapped and tested on x86_64-unknown-linux-gnu
Hi!
On Thu, Sep 29, 2011 at 03:14:40PM +0400, Michael Zolotukhin wrote:
+/* { dg-options "-O2 -march=atom -mtune=atom -m64 -dp" } */
The testcases are wrong, -m64 or -m32 should never appear in dg-options,
ins
Georg-Johann Lay wrote:
> This is a tentative patch for better support of logging information for avr BE
> developers.
>
> There are situations where it is more convenient to let the compiler produce
> information than to debug into the compiler. One example are -da dumps.
>
> This patch proposes
On Thu, Sep 29, 2011 at 12:51 PM, Bernd Schmidt wrote:
> On 09/29/11 11:26, Richard Guenther wrote:
>> Maybe that was the PR the patch is about, but surely we can't treat
>> a memcpy (p, ..) like *p. Which means we'd use the declared type
>> of p only. And we can do so only for parameters (inter
On Sep 29, 2011, at 1:27 AM, Iain Sandoe wrote:
> ... so here is a patch that implements a wrapper scheme on top of mach-o
> (used presently only for LTO - but in the most general sense available
> elsewhere to mach-o should the problem re-emerge).
> OK for trunk and 4.6 ?
Ok for all my bits.
On 09/29/11 11:26, Richard Guenther wrote:
> Maybe that was the PR the patch is about, but surely we can't treat
> a memcpy (p, ..) like *p. Which means we'd use the declared type
> of p only. And we can do so only for parameters (intermediate conversions
> are dropped), which would make the case
On Thu, Sep 29, 2011 at 06:08:50PM +0800, Jiangning Liu wrote:
> As far as I know different back-ends are implementing different
> prologue/epilogue in GCC. If one day this part can be refined and abstracted
> as well, I would say solving this stack-red-zone problem in shared
> prologue/epilogue co
> -Original Message-
> From: Richard Guenther [mailto:richard.guent...@gmail.com]
> Sent: Thursday, September 29, 2011 5:03 PM
> To: Jiangning Liu
> Cc: Andrew Pinski; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] Fix stack red zone bug (PR38644)
>
> On Thu, Sep 29, 2011 at 5:13 AM, Jia
On Wed, Sep 28, 2011 at 4:23 PM, Richard Guenther
wrote:
> On Mon, Sep 26, 2011 at 5:43 PM, Richard Guenther
> wrote:
>> On Mon, Sep 26, 2011 at 4:25 PM, Richard Guenther
>> wrote:
>>> On Wed, Sep 7, 2011 at 5:06 PM, Joseph S. Myers
>>> wrote:
This looks like it has the same issue with ma
On Thu, Sep 29, 2011 at 11:20 AM, Jakub Jelinek wrote:
> On Thu, Sep 29, 2011 at 11:11:12AM +0200, Richard Guenther wrote:
>> On Wed, Sep 28, 2011 at 10:08 PM, Jakub Jelinek wrote:
>> > On Wed, Sep 28, 2011 at 09:56:27PM +0200, Richard Guenther wrote:
>> >> There is nothing like "very likely alig
On Thu, Sep 29, 2011 at 10:27 AM, Tom de Vries wrote:
> On 09/29/2011 12:21 AM, Tom de Vries wrote:
>> On 09/24/2011 11:31 AM, Richard Guenther wrote:
>>> On Tue, Sep 20, 2011 at 1:13 PM, Tom de Vries
>>> wrote:
Hi Richard,
I have a patch for PR43814. It introduces an option that
Andrew Pinski writes:
> On Mon, Sep 26, 2011 at 7:28 PM, Jiangning Liu wrote:
>>
>> Sorry, for this bug, I don’t see your valuable comments previously in either
>> bug zilla and the [RFC] I sent out long time ago in gcc mail list. What I
>> see is a bunch of people agreed this problem should be
On Thu, Sep 29, 2011 at 11:11:12AM +0200, Richard Guenther wrote:
> On Wed, Sep 28, 2011 at 10:08 PM, Jakub Jelinek wrote:
> > On Wed, Sep 28, 2011 at 09:56:27PM +0200, Richard Guenther wrote:
> >> There is nothing like "very likely aligned" ;) Note that what is new is
> >
> > On non-strict align
On Wed, Sep 28, 2011 at 10:08 PM, Jakub Jelinek wrote:
> On Wed, Sep 28, 2011 at 09:56:27PM +0200, Richard Guenther wrote:
>> There is nothing like "very likely aligned" ;) Note that what is new is
>
> On non-strict aligned targets there is no reason not to have something like
> "very likely alig
On 09/29/2011 09:58 AM, Richard Guenther wrote:
On Thu, Sep 29, 2011 at 12:10 AM, William J. Schmidt
wrote:
Hi there,
Ping. I'm seeking approval for this fix on trunk and 4_6-branch.
Thanks!
Ok.
Yes, also looks good from me. Though, you may want to move the forward
declaration after the "
On Thu, Sep 29, 2011 at 5:13 AM, Jiangning Liu wrote:
>
>
>> -Original Message-
>> From: Richard Guenther [mailto:richard.guent...@gmail.com]
>> Sent: Wednesday, September 28, 2011 5:56 PM
>> To: Jiangning Liu
>> Cc: Andrew Pinski; gcc-patches@gcc.gnu.org
>> Subject: Re: [PATCH] Fix stack
On Thu, Sep 29, 2011 at 12:10 AM, William J. Schmidt
wrote:
> Hi there,
>
> Ping. I'm seeking approval for this fix on trunk and 4_6-branch.
> Thanks!
Ok.
Thanks,
Richard.
> Bill
>
> On Tue, 2011-09-13 at 17:55 -0500, William J. Schmidt wrote:
>> Greetings,
>>
>> The code to build scops (stati
It appears that the number of sections in a mach-o file is to be
limited to 256.
Whilst we all (probably) agree that the documentation is not clear
about this, there is likely little point in jumping up and down...
It's a show-stopper for LTO with current darwin tool-chains where 'as'
error
On 09/29/2011 12:21 AM, Tom de Vries wrote:
> On 09/24/2011 11:31 AM, Richard Guenther wrote:
>> On Tue, Sep 20, 2011 at 1:13 PM, Tom de Vries wrote:
>>> Hi Richard,
>>>
>>> I have a patch for PR43814. It introduces an option that assumes that
>>> function
>>> arguments of pointer type are aligne
On Thu, Sep 29, 2011 at 04:01:55AM -0400, David Miller wrote:
> --- a/gcc/config/sparc/sparc.md
> +++ b/gcc/config/sparc/sparc.md
> @@ -8148,17 +8148,16 @@
>[(set_attr "type" "edge")])
>
> (define_code_iterator gcond [le ne gt eq])
> -(define_code_attr gcond_name [(le "le") (ne "ne") (gt "gt
Thanks to Uros Bizjak for pointing this out.
Committed to trunk.
* config/sparc/sparc.md (gcond_name): Delete unnecessary code attr.
(VIS pixel-compare insn): Just use .
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@179335
138bc75d-0d04-0410-961f-82ee72b054a4
---
gcc/ChangeL
From: Uros Bizjak
Date: Thu, 29 Sep 2011 09:04:37 +0200
> Hello!
>
>> This is heavily inspired by a proof-of-concept patch David
>> Bremner sent to me the other week.
>>
>> * config/sparc/sparc.md (UNSPEC_FCMPLE, UNSPEC_FCMPNE,
>> UNSPEC_FCMPGT, UNSPEC_FCMPEQ): Delete and reduce to...
Commited to trunk.
gcc/
* config/sparc/sparc.md (UNSPEC_ARRAY8, UNSPEC_ARRAY16,
UNSPEC_ARRAY32): New unspec.
(define_attr type): New type 'array'.
(array{8,16,32}_vis): New patterns.
* config/sparc/ultra1_2.md: Add reservations for 'array'.
* confi
Hello!
> This is heavily inspired by a proof-of-concept patch David
> Bremner sent to me the other week.
>
> * config/sparc/sparc.md (UNSPEC_FCMPLE, UNSPEC_FCMPNE,
> UNSPEC_FCMPGT, UNSPEC_FCMPEQ): Delete and reduce to...
> (UNSPEC_FCMP): New unspec.
> (gcond): New code iter
76 matches
Mail list logo
