On Sat, Oct 1, 2011 at 9:03 AM, JonY wrote:
> Hi,
>
> I followed Paolo's suggestion with the os_defines.h trick. I duplicated
> os/mingw32/ to os/mingw32-w64/ for this to work, since there aren't any
> built-in defines to tell the 2 apart unless you include some headers
> like _mingw.h.
>
> Patch
Hi,
I followed Paolo's suggestion with the os_defines.h trick. I duplicated
os/mingw32/ to os/mingw32-w64/ for this to work, since there aren't any
built-in defines to tell the 2 apart unless you include some headers
like _mingw.h.
Patch attached, comments?
Index: configure.host
=
Here is an example. In the attached file, foo.c contains only two
functions, 'sum' and 'main'. The function 'sum' gets inlined into
'main' (with -O2).
gcc --coverage -O2 foo.c
./a.out
gcov -b foo.c
Now the coverage data for the 'if' condition in 'sum' looks like this:
(in attached file foo.c.gcov
Yes, this will improve test coverage option's usability, but please
provide the example to explain the issues.
David
On Fri, Sep 30, 2011 at 6:12 PM, Sharad Singhai wrote:
> This patch disables early inlining when --coverage option is
> specified. This improves coverage data in presence of other
ok.
David
On Fri, Sep 30, 2011 at 6:54 PM, Easwaran Raman wrote:
> This fixes two issues with sampled profile collection. It delays
> cleanup of instrumentation_to_be_sampled after all callgraph nodes
> have been instrumented and prevents gcov_sample_counter_decl and
> gcov_sampling_rate_decl f
This fixes two issues with sampled profile collection. It delays
cleanup of instrumentation_to_be_sampled after all callgraph nodes
have been instrumented and prevents gcov_sample_counter_decl and
gcov_sampling_rate_decl from being garbage collected.
Ok for google/gcc-4_6 and google/main branche
This patch disables early inlining when --coverage option is
specified. This improves coverage data in presence of other
optimizations, specially with -O2 where early inlining changes the
control flow graph sufficiently enough to generate seemingly very odd
source coverage.
Bootstrapped okay and r
This patch makes detect_type_change analysis assume that only ADDR_EXPRs can be
assigned to vtable entries.
Initially, the patch made a less strict assumption that constants are not
assigned to vtables. I then bumped the assumption to "only ADDR_EXPRs can be
assigned to vtables". I have this
On 09/28/2011 07:34 AM, Nick Clifton wrote:
> -(define_insn "smaxsi3"
> - [(set (match_operand:SI 0 "register_operand" "=r,r,r,r,r,r")
> - (smax:SI (match_operand:SI 1 "register_operand" "%0,0,0,0,0,0")
> - (match_operand:SI 2 "rx_source_operand"
> -
From: Richard Henderson
Date: Fri, 30 Sep 2011 14:03:52 -0700
> (3) Use optimize-mode-switching to minimize the number of changes
> to the global state. This includes the use of SIAM vs %fsr,
> especially when a subroutine call could have changed the
> global rounding mode.
On Fri, 30 Sep 2011, Richard Henderson wrote:
> Specifically, in-compiler support for #pragma STDC FENV_ACCESS and the
> various routines. We ought to be able to track the rounding
> mode (and other relevant parameters) on a per-expression basis, tagging
> each floating-point operation with the
Moving test gcc.target/i386
* testsuite/gcc.dg/builtin_target.c: Remove.
* testsuite/gcc.target/i386/builtin_target.c: New file.
On Fri, Sep 30, 2011 at 2:33 PM, Richard Henderson wrote:
> On 09/30/2011 02:09 PM, Sriraman Tallam wrote:
>> * testsuite/gcc.dg/builtin_target.c
On 09/30/2011 02:09 PM, Sriraman Tallam wrote:
> * testsuite/gcc.dg/builtin_target.c: Specify target as ix86 or
> x86_64.
>
> Index: gcc.dg/builtin_target.c
> ===
> --- gcc.dg/builtin_target.c (revision 179400)
> +++ gcc
This is now submitted.
Thanks,
-Sri.
On Fri, Sep 30, 2011 at 2:09 PM, Sriraman Tallam wrote:
> * testsuite/gcc.dg/builtin_target.c: Specify target as ix86 or
> x86_64.
>
> Index: gcc.dg/builtin_target.c
> ===
> --- gcc
On 09/30/2011 12:14 PM, Artem Shinkarov wrote:
> Ok, in the attachment there is a patch which fixes mentioned errors.
The changes are ok. I would have committed it for you, only the patch
isn't against mainline. There are 4 rejects.
r~
On 30/09/2011, at 6:56 PM, Maxim Kuvyrkov wrote:
> 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
* testsuite/gcc.dg/builtin_target.c: Specify target as ix86 or
x86_64.
Index: gcc.dg/builtin_target.c
===
--- gcc.dg/builtin_target.c (revision 179400)
+++ gcc.dg/builtin_target.c (working copy)
@@ -1,6 +1,6 @@
On 09/30/2011 12:59 AM, David Miller wrote:
>
> I tried to add the 'siam' instruction too but that one is really
> difficult because it influences the behavior of every float operation
> and I couldnt' find an easy way to express those dependencies. I
> tried a few easy approaches but I couldn't
On Fri, Sep 30, 2011 at 1:51 PM, Diego Novillo wrote:
> On 11-09-30 16:50 , Sriraman Tallam wrote:
>>
>> ChangeLog entry:
>>
>>
>> * testsuite/g++.dg/tree-prof/callgraph-profiles/C: Add
>> dg-require-section-exclude. * testsuite/lib/target-supports.exp
>> (check_ifunc_available): N
On 11-09-30 16:50 , Sriraman Tallam wrote:
ChangeLog entry:
* testsuite/g++.dg/tree-prof/callgraph-profiles/C: Add
dg-require-section-exclude. * testsuite/lib/target-supports.exp
(check_ifunc_available): New proc. *
testsuite/lib/target-supports-dg.exp (dg-require-section-
On Fri, Sep 30, 2011 at 1:48 PM, Diego Novillo wrote:
> On 11-09-30 16:44 , Sriraman Tallam wrote:
>>
>> Disable running of callgraph-profiles.C is section attribute "e" is not
>> supported.
>
> OK with a ChangeLog entry.
>
> Was the original patch sent to trunk? I don't recall.
This was only se
ChangeLog entry:
* testsuite/g++.dg/tree-prof/callgraph-profiles/C: Add
dg-require-section-exclude. * testsuite/lib/target-supports.exp
(check_ifunc_available): New proc. *
testsuite/lib/target-supports-dg.exp (dg-require-section-exclude): New
proc.
On Fri, Sep 30, 20
On 11-09-30 16:44 , Sriraman Tallam wrote:
Disable running of callgraph-profiles.C is section attribute "e" is not
supported.
OK with a ChangeLog entry.
Was the original patch sent to trunk? I don't recall.
Diego.
Disable running of callgraph-profiles.C is section attribute "e" is not
supported.
Index: lib/target-supports-dg.exp
===
--- lib/target-supports-dg.exp (revision 179400)
+++ lib/target-supports-dg.exp (working copy)
@@ -100,6 +100,
On 09/30/2011 11:28 AM, Jason Merrill wrote:
+linemap_location_before_p (struct line_maps *set,
+ source_location pre,
+ source_location post)
+{
+ bool pre_from_macro_p, post_from_macro_p;
+
+ if (pre == post)
+return false;
+
+ pre_from_
On 30/09/2011, at 6:56 PM, Maxim Kuvyrkov wrote:
> 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
On Fri, 30 Sep 2011, Ramana Radhakrishnan wrote:
> On 26 July 2011 10:01, Dr. David Alan Gilbert
> wrote:
> >
> > +
> > +extern unsigned int __write(int fd, const void *buf, unsigned int count);
>
> Why are we using __write instead of write?
Because plain write is in the user's namespace in IS
On 09/29/2011 06:13 PM, Jiangning Liu wrote:
>
>
>> -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 re
On 09/30/2011 09:08 AM, Bernd Schmidt wrote:
> gcc/
> * regrename.h: New file.
> * regrename.c: Include it. Also include "emit-rtl.h".
> (struct du_head, struct du_chain, du_head_p DEF_VEC and
> DEF_VEC_ALLOC_P): Move to regrename.h.
> (do_replace): Remove decla
> I hope that the new version looks a little bit better.
Nearly ok. Some trivial fixes, and then please commit.
> + rtx_v0 = expand_normal (v0);
> + rtx_mask = expand_normal (mask);
> +
> + create_output_operand (&ops[0], target, mode);
> + create_input_operand (&ops[3], rtx_mask, mode);
> +
On Fri, Sep 30, 2011 at 05:17:00PM +0200, Jakub Jelinek wrote:
> Here is the updated patch, bootstrapped/regtested on x86_64-linux and
> i686-linux, committed to trunk. Will work on 4.6 backport of the str{,n}cat
> part.
And here is the backport I've just committed. 4.6 doesn't handle
BUILT_IN_*
Diego asked me what this flag was for; I looked, and found it to be a
write-only flag. So out it goes.
Tested x86_64-pc-linux-gnu, applied to trunk.
commit 59817b6e5fa3fafbce5fa2b1a111b2aa37eea091
Author: Jason Merrill
Date: Tue Sep 27 10:45:07 2011 -0400
* cp-tree.h (TREE_NEGATED_INT)
Patch http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00625.html was
approved by Jason last December but I never got around to checking
it in. Paolo Carlini said in PR44473 that it was already approved
and doesn't need a new approval, so I checked it in after a
bootstrap and regtest of c,c++ for i686
Artem Shinkarov schrieb:
On Fri, Sep 30, 2011 at 4:54 PM, Jakub Jelinek wrote:
On Fri, Sep 30, 2011 at 04:48:41PM +0100, Artem Shinkarov wrote:
Most likely we can. The question is what do we really want to check
with this test. My intention was to check that a programmer can
statically get c
On Fri, Sep 30, 2011 at 9:45 AM, Ramana Radhakrishnan
wrote:
> On 26 July 2011 10:01, Dr. David Alan Gilbert
> wrote:
>>
>> +
>> +extern unsigned int __write(int fd, const void *buf, unsigned int count);
>
> Why are we using __write instead of write?
>
> A comment elaborating that this file shou
On 09/27/2011 02:02 PM, Bernd Schmidt wrote:
> Here's a new version of the entire shrink-wrapping patch with the
> trap_if test replaced by the outgoing_edges_match change, the condjump_p
> bug fixed, and the dump output and testcase adjusted a bit. Bootstrapped
> and tested on i686-linux and mips-
On Fri, Sep 16, 2011 at 01:08:13AM +0200, Mikael Morin wrote:
>
> OK for trunk?
>
> Mikael
>
> patchset layout:
> - patches 1..4:
> Preliminary cleanups.
> Those are quite independant on the rest.
> Patch 4 is optional.
>
> - patches 5..13:
> Step by step move from s
On 26 July 2011 10:01, Dr. David Alan Gilbert wrote:
>
> +
> +extern unsigned int __write(int fd, const void *buf, unsigned int count);
Why are we using __write instead of write?
A comment elaborating that this file should only be in the static
libgcc and never in the dynamic libgcc would be use
Hi,
I checked in this patch as an obvious fix.
H.J.
---
Index: doc/extend.texi
===
--- doc/extend.texi (revision 179396)
+++ doc/extend.texi (working copy)
@@ -6722,8 +6722,8 @@ return the new value. That is,
builtin as @co
This is the final piece which makes use of all the previous regrename
patches, and transforms this loop (which occurs in a popular embedded
benchmark):
sploop 2
.L4:
ldh .d1t1 *A6++[1], A7
ldh .d1t1 *++A5[1], A8
nop 4
On Fri, Sep 30, 2011 at 4:54 PM, Jakub Jelinek wrote:
> On Fri, Sep 30, 2011 at 04:48:41PM +0100, Artem Shinkarov wrote:
>> Most likely we can. The question is what do we really want to check
>> with this test. My intention was to check that a programmer can
>> statically get correspondence of the
The main purpose of this patch is to move some declarations to a new
file, regrename.h, and make regrename_analyze and do_replace callable
from elsewhere. The second patch will add code to c6x.c to make use of
this from the modulo-scheduling code.
This also adds a small amount of new functionality
On Fri, Sep 30, 2011 at 4:11 AM, Kirill Yukhin wrote:
> Okay, seems maintainers have no objections
>
> Could anybody please commit that to wwwdocs?
>
Your patch can't be applied. Please provide a proper patch.
Thanks.
--
H.J.
On Fri, Sep 30, 2011 at 04:48:41PM +0100, Artem Shinkarov wrote:
> Most likely we can. The question is what do we really want to check
> with this test. My intention was to check that a programmer can
> statically get correspondence of the types, in a sense that sizeof
> (float) == sizeof (int) and
On Fri, Sep 30, 2011 at 4:43 PM, Jakub Jelinek wrote:
> On Fri, Sep 30, 2011 at 05:36:47PM +0200, Georg-Johann Lay wrote:
>> >> The target has
>> >>
>> >> 2 = sizeof (short)
>> >> 2 = sizeof (int)
>> >> 4 = sizeof (long int)
>> >> 8 = sizeof (long long int)
>> >>
>> >> Could you fix that? I.e. par
On Fri, Sep 30, 2011 at 05:36:47PM +0200, Georg-Johann Lay wrote:
> >> The target has
> >>
> >> 2 = sizeof (short)
> >> 2 = sizeof (int)
> >> 4 = sizeof (long int)
> >> 8 = sizeof (long long int)
> >>
> >> Could you fix that? I.e. parametrize sizeof(int) out or skip the test by
> >> means of
> >>
Artem Shinkarov schrieb:
> On Fri, Sep 30, 2011 at 4:01 PM, Georg-Johann Lay wrote:
>> Artem Shinkarov schrieb:
>>> Here is a new version of the patch which considers the changes from
>>> 2011-09-02 Richard Guenther
>>>
>>>
>>> ChangeLog
>>>
>>> 20011-09-06 Artjoms Sinkarovs
>>>
>>>gcc/
Hi Nick,
>> Experiments show that the
>> existing multi-if-block support isn't terribly effective on FRV;
>> before-after comparisons show that by turning it off, there are three
>> spots in gcc that are meaningfully changed, and below 20 in the C
>> benchmarks of SPEC2k.
>>
>> FRV also doesn't bu
On 09/29/2011 05:21 PM, Dodji Seketeli wrote:
+ When the token is /not/ an argument for a macro, xI is the same
+ location as yI. Otherwise, xI is either the virtual location of
+ that argument token if it comes from a macro expansion itself, or
+ its spelling location.
I think
Hi Bernd,
Experiments show that the
existing multi-if-block support isn't terribly effective on FRV;
before-after comparisons show that by turning it off, there are three
spots in gcc that are meaningfully changed, and below 20 in the C
benchmarks of SPEC2k.
FRV also doesn't build in mainline,
2011/7/22 Richard Sandiford :
> zhr...@ispras.ru writes:
>> This patch fixes the compiler segfault found while regtesting trunk with SMS
>> on
>> IA64 platform. Segfault happens on test gcc.dg/pr45259.c with -fmodulo-sched
>> enabled. The following jump instruction is given as argument for
>> do
Ping.
The following RTL patches need reviews:
[PATCH 4/9] Move the SMS pass earlier
http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01811.html
[PATCH 7/9] New assertion in rtl_lv_add_condition_to_bb
http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01808.html
[PATCH 8/9] Extend simple_rhs_p
http://gcc.gnu.
On Fri, 30 Sep 2011, Tristan Gingold wrote:
> If you prefer a target hook, I'm fine with that. I will write such a patch.
>
> I don't think it must be restricted to system headers, as it is possible
> that the user 'imports' such a function (and define it in one of VMS
> favorite languages suc
On Fri, Sep 30, 2011 at 12:35:49PM +0200, Richard Guenther wrote:
> On Fri, Sep 30, 2011 at 12:23 PM, Jakub Jelinek wrote:
> > On Fri, Sep 30, 2011 at 10:25:35AM +0200, Richard Guenther wrote:
> >> > This patch teaches PTA/aliasing about strdup/strndup (that the passed in
> >> > string is just rea
On Fri, Sep 30, 2011 at 4:01 PM, Georg-Johann Lay wrote:
> Artem Shinkarov schrieb:
>> Here is a new version of the patch which considers the changes from
>> 2011-09-02 Richard Guenther
>>
>>
>> ChangeLog
>>
>> 20011-09-06 Artjoms Sinkarovs
>>
>> gcc/
>> * fold-const.c (constant_bo
On Fri, Sep 30, 2011 at 10:57:25AM +0200, Richard Guenther wrote:
> Definitely. Seeing a decl will enable better offset-based
> disambiguation.
Ok, here is an updated patch. Bootstrapped/regtested on x86_64-linux
and i686-linux, ok for trunk?
2011-09-30 Jakub Jelinek
* fold-const.c
On Fri, Sep 30, 2011 at 03:14:12PM +0200, Richard Guenther wrote:
> Ah, indeed. I'll have a look at the updated patch.
Here is what I've committed after bootstrapping/regtesting it on
x86_64-linux and i686-linux and Richard's approval on IRC.
2011-09-30 Jakub Jelinek
PR tree-optimiza
Artem Shinkarov schrieb:
> Here is a new version of the patch which considers the changes from
> 2011-09-02 Richard Guenther
>
>
> ChangeLog
>
> 20011-09-06 Artjoms Sinkarovs
>
>gcc/
>* fold-const.c (constant_boolean_node): Adjust the meaning
>of boolean for vector typ
>>> On 30.09.11 at 14:34, Richard Guenther wrote:
> On Fri, Sep 30, 2011 at 1:43 PM, Jan Beulich wrote:
>> Split out LTO's writing of top level asm nodes in preparation of extending
>> what needs to be written out when top level asm-s get enhanced to accept a
>> limited set of input operands.
>
On Sep 30, 2011, at 4:43 PM, Joseph S. Myers wrote:
> On Thu, 29 Sep 2011, 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 name
On Thu, 29 Sep 2011, 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 its ABI which
On Fri, 30 Sep 2011 09:24:03 +0200
Tristan Gingold wrote:
>
> On Sep 29, 2011, at 5:54 PM, Basile Starynkevitch wrote:
> > I believe that such an extension is useful on other systems, even when
> > their ABI don't
> > pass the number of arguments.
> >
> > The use case I would have in mind is w
On Mon, 26 Sep 2011, Jakub Jelinek wrote:
> Hi!
>
> Adding Joseph and Jason to CC.
>
> On Mon, Sep 26, 2011 at 04:56:20PM +0200, Richard Guenther wrote:
> > Let's see what kind of fallout we get ;) For example, if the
> > following is valid C code I expect we will vectorize the second
> > loop
On Tue, Sep 27, 2011 at 04:26:47PM -0300, Alexandre Oliva wrote:
> On Sep 20, 2011, Jakub Jelinek wrote:
>
> > For NOTE_INSN_CALL_ARG_LOCATION, the locations aren't location lists, but
> > a single location at the point of the call. They are independent of
> > all other locations, so any kind of
It seems that the following three tests don't fail anymore anywhere for
some time, so the following patch removes the three xfail's to avoid the
noise from XPASSes.
Tested with the approrpriate runtest invocation on i386-pc-solaris2.11.
Ok for mainline?
Rainer
2011-09-30 Rainer Orth
This is the patch to add log output to LEGITIMIZE_RELOAD_ADDRESS.
The code is moved from macro in avr.h to a new function in avr.c.
Functionality is the same, but IMO it's more convenient to have it as function
than as a quite long macro.
Ok for trunk?
PR target/50566
* config/a
On 11-09-27 13:23 , Jan Hubicka wrote:
sync and pr34850 tests doesn't pass with slim LTO. The reason is that they
excpects diagnostics that is output too late in compilation (usually at
expansion time). These should be probably fixed as QOI issue but they are not
real bug - the diagnostics will
On 29 Sep 2011, at 15:37, Arnaud Charlet wrote:
No functional change, just factor out the common LIBGNAT_TARGET_PAIRS
across the port.
OK for trunk?
OK
regrettably, I'd allowed my ppc and x86 trees to get out of sync, and
the applied patch was not correct on powerpc.
corrected by a parti
> -Original Message-
> From: Georg-Johann Lay [mailto:a...@gjlay.de]
> Sent: Friday, September 30, 2011 6:18 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Denis Chertykov; Weddington, Eric
> Subject: Re: [Patch,AVR]: PR50566: Better log output with -mdeb/-mlog=
> [3/n]
>
> This adds log output
This fixes PR50574, we shouldn't compare vector mode sizes because
vectors can have BLKmode in gimple.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2011-09-30 Richard Guenther
PR middle-end/50574
* tree-cfg.c (verify_gimple_comparison): Com
On Thu, Sep 29, 2011 at 3:15 PM, Tom de Vries wrote:
> 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
>>> BIGG
Hi Dave,
The nit-picky bit - There are still a number of formatting issues with
your patch . Could you run your patch through
contrib/check_GNU_style.sh and correct these. These are typically
around problems with the number of spaces between a full stop and the
end of comment, lines with trailing
On Fri, Sep 30, 2011 at 01:54:16PM +0100, Jan Beulich wrote:
> >>> On 30.09.11 at 14:47, Jakub Jelinek wrote:
> > On Fri, Sep 30, 2011 at 12:43:54PM +0100, Jan Beulich wrote:
> >> This is so that use of symbols referenced in these asm()-s can be
> >> properly tracked by the compiler, just like is
On Fri, Sep 30, 2011 at 2:44 PM, Jakub Jelinek wrote:
> On Fri, Sep 30, 2011 at 02:26:40PM +0200, Richard Guenther wrote:
>> > It is boolean only in some testcases, the is_bool stuff discussed at the
>> > beginning above was originally just an early return
>> > if (TREE_CODE (TREE_TYPE (exp)) !=
Richard Sandiford writes:
> In contrast, after the tree optimisers have handed off the initial IL,
um, I meant frontend :-)
> the tree optimisers are more or less in full control.
Richard
>>> On 30.09.11 at 14:42, Richard Guenther wrote:
> On Fri, Sep 30, 2011 at 1:43 PM, Jan Beulich wrote:
>> This is so that use of symbols referenced in these asm()-s can be
>> properly tracked by the compiler, just like is the case for all other
>> asm()-s. I'm particularly looking forward to use
On Fri, Sep 30, 2011 at 2:46 PM, Richard Sandiford
wrote:
> "Jiangning Liu" writes:
>>> You seem to feel strongly about this because it's a wrong-code bug that
>>> is very easy to introduce and often very hard to detect. And I
>>> defintely
>>> sympathise with that. If we were going to to do it
>>> On 30.09.11 at 14:47, Jakub Jelinek wrote:
> On Fri, Sep 30, 2011 at 12:43:54PM +0100, Jan Beulich wrote:
>> This is so that use of symbols referenced in these asm()-s can be
>> properly tracked by the compiler, just like is the case for all other
>> asm()-s. I'm particularly looking forward t
On Fri, Sep 30, 2011 at 12:43:54PM +0100, Jan Beulich wrote:
> This is so that use of symbols referenced in these asm()-s can be
> properly tracked by the compiler, just like is the case for all other
> asm()-s. I'm particularly looking forward to use this in the Linux
> kernel. It is certainly not
"Jiangning Liu" writes:
>> You seem to feel strongly about this because it's a wrong-code bug that
>> is very easy to introduce and often very hard to detect. And I
>> defintely
>> sympathise with that. If we were going to to do it in a target-
>> independent
>> way, though, I think it would be
On Fri, Sep 30, 2011 at 02:26:40PM +0200, Richard Guenther wrote:
> > It is boolean only in some testcases, the is_bool stuff discussed at the
> > beginning above was originally just an early return
> > if (TREE_CODE (TREE_TYPE (exp)) != BOOLEAN_TYPE)
> > return;
> > before the loop, but it tur
On Fri, Sep 30, 2011 at 1:43 PM, Jan Beulich wrote:
> This is so that use of symbols referenced in these asm()-s can be
> properly tracked by the compiler, just like is the case for all other
> asm()-s. I'm particularly looking forward to use this in the Linux
> kernel. It is certainly not very us
On Fri, Sep 30, 2011 at 1:43 PM, Jan Beulich wrote:
> Split out LTO's writing of top level asm nodes in preparation of extending
> what needs to be written out when top level asm-s get enhanced to accept a
> limited set of input operands.
Ok with ...
> gcc/
> 2011-09-30 Jan Beulich
>
>
On Fri, Sep 30, 2011 at 1:11 PM, Jakub Jelinek wrote:
> On Fri, Sep 30, 2011 at 12:33:07PM +0200, Richard Guenther wrote:
>> > + low = build_int_cst (TREE_TYPE (exp), 0);
>> > + high = low;
>> > + in_p = 0;
>> > + strict_overflow_p = false;
>> > + is_bool = TREE_CODE (TREE_TYPE (exp)) == BOOL
This adds log output to avr_address_cost.
Ok for trunk?
Johann
PR target/50566
* config/avr/avr-protos.h (avr_log_t): New field address_cost.
* config/avr/avr.c (avr_address_cost): Use it.
* config/avr/avr-log.c (avr_log_set_avr_log): Initialize it.
(avr_l
I intent to commit the attached patch in the next days.
Do you have suggestions for a better wording or other items which should
be listed?
For the current version, see http://gcc.gnu.org/gcc-4.7/changes.html#fortran
Tobias
Index: changes.html
=
> -Original Message-
> From: Richard Sandiford [mailto:rdsandif...@googlemail.com]
> Sent: Friday, September 30, 2011 4:15 PM
> To: Jiangning Liu
> Cc: 'Jakub Jelinek'; 'Richard Guenther'; Andrew Pinski; gcc-
> patc...@gcc.gnu.org
> Subject: Re: [PATCH] Fix stack red zone bug (PR38644)
>
This is so that use of symbols referenced in these asm()-s can be
properly tracked by the compiler, just like is the case for all other
asm()-s. I'm particularly looking forward to use this in the Linux
kernel. It is certainly not very useful in PIC code, at least not with
some extra care.
gcc/
20
Split out LTO's writing of top level asm nodes in preparation of extending
what needs to be written out when top level asm-s get enhanced to accept a
limited set of input operands.
gcc/
2011-09-30 Jan Beulich
* lto-cgraph.c (output_cgraph): Remove processing of 'cgraph_asm_nodes',
This is so that use of symbols referenced in these asm()-s can be
properly tracked by the compiler, just like is the case for all other
asm()-s. I'm particularly looking forward to use this in the Linux
kernel. It is certainly not very useful in PIC code, at least not with
some extra care.
Changes
On Fri, Sep 30, 2011 at 10:03 AM, Revital Eres wrote:
> Hello,
>
>> This
>> + /* Skip instructions that do not set a register. */
>> + if (set && !REG_P (SET_DEST (set)))
>> + continue;
>> is ok. Can you also prevent !set insns from having reg_moves? (To be updated
>> once auto_i
On Fri, Sep 30, 2011 at 12:33:07PM +0200, Richard Guenther wrote:
> > + low = build_int_cst (TREE_TYPE (exp), 0);
> > + high = low;
> > + in_p = 0;
> > + strict_overflow_p = false;
> > + is_bool = TREE_CODE (TREE_TYPE (exp)) == BOOLEAN_TYPE;
>
> Effective boolean are also TYPE_PRECISION () ==
Okay, seems maintainers have no objections
Could anybody please commit that to wwwdocs?
Thanks, K
On Tue, Sep 27, 2011 at 8:19 PM, Gerald Pfeifer wrote:
> On Tue, 27 Sep 2011, Kirill Yukhin wrote:
>> So, if you are ok, let's wait a couple of days for maintainers inputs.
>
> Yep, looks good. Un
On Fri, Sep 30, 2011 at 00:09, Andi Kleen wrote:
> 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_spl
On 29/09/11 12:27, Richard Guenther wrote:
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
On Thu, Sep 29, 2011 at 11:15 PM, Jakub Jelinek wrote:
> 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 i
On Sep 30, 2011, at 11:10 AM, Gabriel Dos Reis wrote:
> On Thu, Sep 29, 2011 at 10:10 AM, 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
On Thu, Sep 29, 2011 at 10:10 AM, 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
> it
On Fri, Sep 30, 2011 at 10:56 AM, Jakub Jelinek wrote:
> Hi!
>
> On Fri, Sep 30, 2011 at 10:34:28AM +0200, Richard Guenther wrote:
>> Hmm, I don't think this change is ok. We rely on maybe_fold_reference
>> to re-fold mem-refs to valid gimple form (from propagating say
>> &a.b.c to MEM[p, 4] whic
On Fri, 30 Sep 2011, Jakub Jelinek wrote:
> On Fri, Sep 30, 2011 at 09:50:09AM +0200, Richard Guenther wrote:
> > Hmm, in fwprop can you limit your change to non-invariant addresses?
> > That is, we do want to propagate invariant addresses over
> > restrict casts, because that will give us _more_
1 - 100 of 113 matches
Mail list logo
