On Thu, 29 Oct 2009, Toon Moene wrote:
> Richard Guenther wrote:
>
> > On Thu, 29 Oct 2009, Toon Moene wrote:
> >
> > > You wrote:
> > >
> > > > I refrained from adding a 4000 file testcase ;)
> > > Never mind - I have one. I didn'
On Fri, Oct 30, 2009 at 1:54 PM, Paolo Carlini wrote:
> Jerry Quinn wrote:
>> I've reverted the patch.
>>
> Thanks Jerry for your quick feedback.
I think it was just
static tree
-tinfo_name (tree type)
+tinfo_name (tree type, bool mark_private)
{
const char *name;
+ int length;
tree nam
On Fri, Oct 30, 2009 at 2:15 PM, Paolo Carlini wrote:
> Richard Guenther wrote:
>> where you replaced build_string (strlen (name) + 1, name) with
>> build_string (strlen (name), name). I don't know if this renders the
>> ABIs incompatible, but I doubt it - it would be
On Fri, Oct 30, 2009 at 3:22 PM, Rahul Kharche wrote:
> Hi Richi,
>
> Following up your suggestion on PR41488, I am continuing to test with
> loop header copy before FRE in GCC 4.4.1. One regression I am trying
> to tackle is from the test case below.
>
> typedef struct {
> int degree;
> int c[(
ab them in isolation.
Richard.
> Cheers,
> Rahul
>
> -----Original Message-
> From: Richard Guenther [mailto:richard.guent...@gmail.com]
> Sent: 30 October 2009 14:50
> To: Rahul Kharche
> Cc: rgue...@gcc.gnu.org; gcc@gcc.gnu.org; sdkteam-gnu
> Subject: Re: RFC PR
On Wed, Nov 4, 2009 at 8:19 PM, Toon Moene wrote:
> Jan,
>
> I had some time to study the example I sent you a couple of weeks ago.
>
> According to visible inspection of the source code, there are 5 functions
> (subroutines in Fortran parlance) that are called once:
>
> MAIN calls
> HLPROG call
On Wed, Nov 4, 2009 at 10:30 PM, Andrew Pinski wrote:
> On Wed, Nov 4, 2009 at 1:20 PM, Toon Moene wrote:
>> You don't happen to recall the bug number ?
>
> It might be related to PR 41735 which I noticed when looking at the
> generated assembly and trying to compare 4.5 to 4.4.
Yes indeed. Hon
On Fri, Nov 6, 2009 at 10:46 AM, Eric Botcazou wrote:
>> In a desparate try to get some testcases which do have BLKmode bit-fields
>> I bootstrapped and regtested the below patch (as part of a larger patch,
>> though) on seven architectures with all languages (on two without Ada).
>
> Yet it's eas
On Sat, Nov 7, 2009 at 1:24 PM, Grigori Fursin wrote:
> Hi Basile et al,
>
>> My suggestion to ICI friends is : just propose quickly your needed plugin
>> events, and make
>> your ICI a GPLv3 plugin.
>> When you can show that your ICI plugin to an *unmodified* gcc-4.5 brings
>> some value, GCC
>
On Sun, Nov 8, 2009 at 6:35 PM, Terrence Miller wrote:
> < Forwarded due to missing address>
>
> Original Message
> Subject: Re: new plugin events
> Date: Sun, 08 Nov 2009 18:25:21 +0100
> From: Basile STARYNKEVITCH
> To: Terrence Miller
> References: <4ae72a
On Sun, Nov 8, 2009 at 9:47 PM, Joern Rennecke wrote:
> Quoting Richard Guenther :
>
>> On Sun, Nov 8, 2009 at 6:35 PM, Terrence Miller
>
> ...
>>>
>>> For example, as far as I know, no common Linux distribution provides a
>>> package for any ki
On Sun, Nov 8, 2009 at 10:03 PM, Richard Guenther
wrote:
> On Sun, Nov 8, 2009 at 9:47 PM, Joern Rennecke wrote:
>> Quoting Richard Guenther :
>>
>>> On Sun, Nov 8, 2009 at 6:35 PM, Terrence Miller
>>
>> ...
>>>>
>>>> For exampl
On Sun, Nov 8, 2009 at 10:13 PM, Gerald Pfeifer wrote:
> On Sun, 8 Nov 2009, Joern Rennecke wrote:
>> With a plugin, the developer can simply point the user at the place where
>> he can download the plugin for his current version, and we can get quick
>> feedback on the usefulness of the new optim
On Mon, Nov 9, 2009 at 10:44 AM, Tobias Burnus wrote:
> On 11/09/2009 12:03 AM, Basile STARYNKEVITCH wrote:
>> is gcc-trunk -flto -O2 aimed for medium sized programs (something like
>> bash), or for bigger ones (something like the linux kernel, the Xorg
>> server, the Qt or GTK graphical toolkit l
On Mon, Nov 9, 2009 at 1:35 PM, Diego Novillo wrote:
> On Sun, Nov 8, 2009 at 18:03, Basile STARYNKEVITCH
> wrote:
>
>> Perhaps the question is when not to use -flto and use -fwhopr instead?
>
> I don't think anyone has systematically tried to determine these
> limits. The original design tried
On Mon, Nov 9, 2009 at 5:50 PM, Dennis Clarke wrote:
>
>>> you can buy a support contract for it then you have a valid platform in
>>> commercial use.
>>
>> You can get support for the OpenSolaris distribution if you like
>
> I just went and looked ... you are correct, they have three levels in
>
On Thu, Nov 12, 2009 at 10:59 AM, Jack Howarth wrote:
> I am a tad confused by this thread. Is MPC going to be mandatory
> along side of gmp/mpfr for the gcc 4.5 release or is this further
> out into the future than that? Thanks in advance for any clarifications.
It's going to be mandatory.
Ri
2009/11/14 Toon Moene :
> Jan Hubicka wrote:
>
>> -fno-ipa-cp should work around your problem for time being.
>
> Indeed it did. Some figures:
>
> hlprog (the main forecast program):
>
> link time optimization time: 3:20 minutes
> top memory usage: 920 Mbyte
>
> Inliner report:
>
> Inli
On Sat, Nov 14, 2009 at 2:13 PM, Steven Bosscher wrote:
> On Sat, Nov 14, 2009 at 8:51 PM, Richard Guenther
> wrote:
>> Note that some optimizers (for example value-numbering) contain cut-offs
>> so that they are turned off for large functions as otherwise compile-time
&
On Sun, Nov 15, 2009 at 8:07 AM, Toon Moene wrote:
> Steven Bosscher wrote:
>
>> On Sat, Nov 14, 2009 at 11:12 PM, Richard Guenther
>> wrote:
>
>>> I don't even remember which other passes have this kind of cut-offs ..
>>
>> At least CPROP, LCM-
On Thu, Nov 19, 2009 at 2:55 PM, Mark Wielaard wrote:
> On Thu, 2009-11-19 at 19:15 +0530, M. Mohan Kumar wrote:
>> On 11/19/2009 04:30 PM, Mark Wielaard wrote:
>> > On Wed, 2009-11-18 at 18:19 +0530, M. Mohan Kumar wrote:
>> >> Are VTA patches part of mainline gcc now? If not, where could we get
On Thu, Nov 19, 2009 at 4:45 PM, H. Peter Anvin wrote:
> On 11/19/2009 07:37 AM, Thomas Gleixner wrote:
>>
>> modified function start on a handful of functions only seen with gcc
>> 4.4.x on x86 32 bit:
>>
>> push %edi
>> lea 0x8(%esp),%edi
>> and $0xfff0,%esp
>>
On Thu, Nov 19, 2009 at 4:49 PM, Richard Guenther
wrote:
> On Thu, Nov 19, 2009 at 4:45 PM, H. Peter Anvin wrote:
>> On 11/19/2009 07:37 AM, Thomas Gleixner wrote:
>>>
>>> modified function start on a handful of functions only seen with gcc
>>> 4.4.x on x
On Thu, Nov 19, 2009 at 4:54 PM, H. Peter Anvin wrote:
> On 11/19/2009 07:44 AM, Andrew Haley wrote:
>>
>> We're aligning the stack properly, as per the ABI requirements. Can't
>> you just fix the tracer?
>>
>
> "Per the ABI requirements?" We're talking 32 bits, here.
Hm, even with
void bar (i
On Thu, Nov 19, 2009 at 6:59 PM, Steven Rostedt wrote:
> On Thu, 2009-11-19 at 09:39 -0800, Linus Torvalds wrote:
>
>> > This modification leads to a hard to solve problem in the kernel
>> > function graph tracer which assumes that the stack looks like:
>> >
>> > return address
>> >
On Fri, Nov 20, 2009 at 4:18 PM, David Edelsohn wrote:
> On Fri, Nov 20, 2009 at 10:05 AM, Ian Bolton wrote:
>> From some simple experiments (see below), it appears as though GCC aims
>> to
>> create a lop-sided tree when there are constants involved (func1 below),
>> but a balanced tree when the
On Fri, Nov 20, 2009 at 9:06 PM, Dave Korn
wrote:
> Piotr Wyderski wrote:
>> Kai Tietz wrote:
>>
>>> This error you get is more related to used binutils version.The
>>> warning you get looks more like a cripled '-Wl,--tsaware'.
>>
>> Thanks, that looks like a good explanation.
>
> Yes, I added th
On Wed, Nov 25, 2009 at 10:30 AM, Piotr Wyderski
wrote:
> Trunk 154492 is uncompilable on Cygwin because
> of incorrect data types in LTO. It compiles with the
> attached fixes, but I have no write access to the
> repository. Could someone please apply them?
I see only whitespace changes. Please
On Wed, Nov 25, 2009 at 2:52 PM, Bingfeng Mei wrote:
> Hello,
> It seems to me that tree balancing risk of producing wrong result due
> to overflow of subexpression.
>
> Say a = INT_MIN, b = 10, c = 10, d = INT_MAX.
>
> If
> ((a + b) + c) + d))
>
> becomes
> ((a + b) + (c + d))
>
> c + d will over
Author: hjl
Date: Wed Nov 25 10:55:54 2009
New Revision: 154645
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154645
Log:
Remove trailing white spaces.
WTF?
Thankyouverymuch.
This 1) wasn't posted or approved 2) is bad as it breaks svn blame
3) chokes all branches.
What's up?
Richard
On Wed, 25 Nov 2009, Richard Guenther wrote:
>
> Author: hjl
> Date: Wed Nov 25 10:55:54 2009
> New Revision: 154645
>
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154645
> Log:
> Remove trailing white spaces.
>
> WTF?
>
> Thankyouverymu
On Wed, 25 Nov 2009, Richard Kenner wrote:
> > Can someone please remove this revision from the subversion database
> > on the server and fix things up? If that's not possible at least
> > the revision should be reverted.
>
> Why the latter? I agree with the problems this can cause, but if they
On Wed, 25 Nov 2009, Richard Kenner wrote:
> > And local patches. Basically _no_ patch will apply anymore as HJ changed
> > every single file.
>
> That's an exaggeration since only a few lines in each file were change. The
> vast majority of outstanding patches won't be affected.
>
> > In an
On Wed, 25 Nov 2009, Dave Korn wrote:
> Joseph S. Myers wrote:
>
> > Doing it right at the end of branch-to-trunk merges for a release (which
> > is where we are right now, just after merges from Graphite) is probably
> > the optimal timing in terms of minimising the amount of branches that wil
On Wed, 25 Nov 2009, Richard Kenner wrote:
> > In my mind it's very simple: trailing whitespace poses exactly _no_
> > problem (except of being against the coding standard),
>
> It's against the coding standards for a very good reason, which is that it
> makes patching harder because you have l
On Wed, 25 Nov 2009, Richard Guenther wrote:
> On Wed, 25 Nov 2009, Richard Kenner wrote:
>
> > > In my mind it's very simple: trailing whitespace poses exactly _no_
> > > problem (except of being against the coding standard),
> >
> > It's again
On Wed, 25 Nov 2009, Dave Korn wrote:
> Kaveh R. GHAZI wrote:
>
> > I think we need to take a deep breath and relax. First of all, HJ didn't
> > need approval for this patch. Whether it's useful or not, it aligns with
> > our stated coding standards and it clearly qualifies as obvious under t
On Thu, Nov 26, 2009 at 12:04 AM, Tom Tromey wrote:
>> "Basile" == Basile STARYNKEVITCH writes:
>
> Basile> Of course, not every one has it (notably those working on non-linux
> Basile> systems), but for those who have it, requiring that every C file
> Basile> inside GCC has been automaticall
On Thu, Nov 26, 2009 at 9:56 AM, Paolo Bonzini wrote:
> On 11/26/2009 12:20 AM, Alexandre Oliva wrote:
>>
>> sed -i 's,[ \t]*$,,' probably won't work, if there are all-blanks lines
>> being left alone in the patch (so the rx will match the patch markers
>> too), but something slightly more elabora
On Sat, Nov 28, 2009 at 4:13 PM, Paul Edwards wrote:
> I think I have found a bug in gcc, that still exists in gcc 4.4
>
> I found the problem on 3.2.3 though.
>
> While MVS and VM have basically been working fine, when I did
> the port to MUSIC/SP I started getting strange compilation failures.
>
On Sat, Nov 28, 2009 at 4:26 PM, Tim Prince wrote:
> Toon Moene wrote:
>>
>> H.J. Lu wrote:
>>>
>>> On Sat, Nov 28, 2009 at 3:21 AM, Toon Moene wrote:
L.S.,
Due to the discussion on register allocation, I went back to a hobby of
mine: Studying the assembly output of the c
On Sat, Nov 28, 2009 at 5:31 PM, Tim Prince wrote:
> Richard Guenther wrote:
>>
>> On Sat, Nov 28, 2009 at 4:26 PM, Tim Prince wrote:
>>>
>>> Toon Moene wrote:
>>>>
>>>> H.J. Lu wrote:
>>>>>
>>>>> On Sat, N
On Sat, Nov 28, 2009 at 5:35 PM, Paul Edwards wrote:
>>> Anyway, I tracked down the particular malloc() which gave changed
>>> behaviour depending on whether the malloc() did a memory initialization
>>> to NULs or not.
>
>> Well, GC hands out non-zeroed memory - the callers are responsible
>> for
On Sat, Nov 28, 2009 at 11:43 PM, Shaun Jackman wrote:
> When assigning a bool to a single bit of a bitfield located in the
> bit-addressable region of memory, better code is produced by
> if (flag)
> bitfield.bit = true;
> else
> bitfield.bit = false;
>
will branch,
do a release candidate and open trunk for the next stage 1.
It is very unlikely that this happens before mid January.
A status report will be sent at the start of "stage 4".
Richard.
--
Richard Guenther
Novell / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuern
On Sun, Nov 29, 2009 at 3:07 PM, Nicolai Josuttis wrote:
> Hi everybody,
>
> I am currently starting to work on a new edition of my
> C++ Library book and from what I see, you already have
> good support of a couple of new feature. Great!
> So, I start to try g++ 4.4.2 out now...
>
> However, both
On Sun, 29 Nov 2009, Kaveh R. GHAZI wrote:
> On Sun, 29 Nov 2009, Richard Guenther wrote:
>
> >
> > This is a remainder to not catch you in surprise when we announce
> > the end of stage 3. Starting Dec 1st the trunk will go into
> > regression and documentati
On Sun, Nov 29, 2009 at 9:18 PM, Daniel Berlin wrote:
>>
>> Such a thing already existed a few years ago (IIRC Haifa had something
>> that Dan picked up and passed on to me). But it never brought any
>> benefits. I don't have the pass anymore, but perhaps Dan still has a
>> copy of it somewhere.
>
.
--
Richard Guenther
Novell / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex
On Wed, 2 Dec 2009, Ralf Wildenhues wrote:
> Hello Richard,
>
> * Richard Guenther wrote on Wed, Dec 02, 2009 at 01:32:24PM CET:
> > The trunk is in regression and documentation fixes only mode,
> > Stage 3 has ended yesterday. Release branch rules are now
> > in effe
2009/12/6 Frédéric L. W. Meunier :
> Will there be a 4.3.5 release ?
>
> Looking at http://gcc.gnu.org/ml/gcc/2009-08/msg00066.html , yes, but 4.4.2
> was released almost two months ago.
I expect so.
Richard.
On Fri, Dec 11, 2009 at 5:16 AM, Aravinda wrote:
> Hi,
>
> Im trying to identify all indirect references in a loop so that, after
> this analysis, I have a list of tree_nodes of pointer_type that are
> dereferenced in a loop along with their step size, if any.
>
> E.g.
> while(i++ < n)
> {
> *(p
d add a -glto or -fi-really-want-to-debug option.
Or of course hope I can reasonably fix the ICEs I run into and
deal with the remaining cases as bugs?
The patch has proven useful debugging miscompiles in its current
state already.
Thanks,
Richard.
2009-12-11 Richard Guenther
* t
On Sat, 12 Dec 2009, Richard Guenther wrote:
> On Fri, 11 Dec 2009, Richard Guenther wrote:
>
> >
> > The following draft patch disables the debuginfo disabling when using
> > -flto or -fwhopr and fixes up things so that for C debugging (mostly)
> > works.
> &
On Fri, 11 Dec 2009, Richard Guenther wrote:
>
> The following draft patch disables the debuginfo disabling when using
> -flto or -fwhopr and fixes up things so that for C debugging (mostly)
> works.
>
> The main question I have is how to proceed further here (with the
On Sun, 13 Dec 2009, Michael Matz wrote:
> Hi,
>
> On Sun, 13 Dec 2009, Richard Guenther wrote:
>
> > *** free_lang_data_in_decl (tree decl)
> > *** 4380,4408
> > }
> > }
> >
> > ! if (TREE_CODE (d
On Mon, Dec 14, 2009 at 2:08 PM, Revital1 Eres wrote:
> Hello,
>
>> I unroll the following code one times in a gimpile pass.
>
> Can you please post the flags you used and the full test?
> I can try to reproduce this.
insn 53 (set (mem/s:SF (reg:SI 234 [ ivtmp.51 ]) (reg:SF 245))
//reg245->a[i]
On Tue, 15 Dec 2009, Diego Novillo wrote:
> On Sun, Dec 13, 2009 at 15:51, Richard Guenther wrote:
>
> > + /* ??? We could free non-constant DECL_SIZE, DECL_SIZE_UNIT
> > + and DECL_FIELD_OFFSET. But it's cheap enough to not do
> > + that and refra
On Wed, Dec 16, 2009 at 7:50 PM, Jean Christophe Beyler
wrote:
> Dear all,
>
> Found on http://gmplib.org/.
>
> "N.B. gcc 4.3.2 miscompiles GMP 4.3.x on 64-bit machines. The problem
> is specific to that very release; specifically gcc 4.3.1 and 4.3.3
> seem to work fine."
>
> Since porting to a ne
On Thu, Dec 17, 2009 at 12:29 PM, Laurent GUERBY wrote:
> Hi,
>
> FYI I just did a ~2 hours presentation of the GCC project to
> my local LUG in Toulouse, France:
>
> http://toulibre.org
>
> The 43 slides presentation in english is available here
> in PDF and openoffice format:
>
> http://guerby.o
On Thu, Dec 17, 2009 at 1:07 PM, Revital1 Eres wrote:
>
> Hello,
>
> Is there a way to pass to the unroller the maximum number of iterations
> of the loop such that it can decide to avoid unrolling if
> the maximum number is small.
>
> To be more specific, I am referring to the following case:
>
2009/12/17 Zdenek Dvorak :
> Hi,
>
>> > Is there a way to pass to the unroller the maximum number of iterations
>> > of the loop such that it can decide to avoid unrolling if
>> > the maximum number is small.
>> >
>> > To be more specific, I am referring to the following case:
>> > After the vecto
On Thu, Dec 17, 2009 at 6:09 PM, David Daney wrote:
> Jamie Lokier wrote:
>>
>> Uwe Kleine-König wrote:
>>>
>>> Use the new unreachable() macro instead of for(;;);
>>> *(int *)0 = 0;
>>> /* Avoid "noreturn function does return" */
>>> - for (;;);
>>> + unreachable();
>>
On Thu, Dec 24, 2009 at 1:32 AM, Joern Rennecke wrote:
> Quoting Joern Rennecke :
>>
>> Right now, to make a new target hook, you have to add a new field in
>> target.h, define a new default in target-def.h, place the new macro
>> in exactly the right position there of the right initializer macro,
On Sat, Dec 26, 2009 at 1:14 AM, Jerry Quinn wrote:
> http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00690.html
>
> [cc'ing gcc since it might be the better forum for this]
>
Ok.
Thanks,
Richard.
On Sat, Dec 26, 2009 at 2:07 AM, Daniel Berlin wrote:
>> In general it will be tricky for latter passes to clean up the messes.
>> The fundamental problem is that the address computation is exposed to
>> PRE prematurely (for a given target ) at GIMPLE level.
>
>
> Yeah, i'm not sure PRE can reall
On Thu, Dec 31, 2009 at 12:04 AM, Andrew Hutchinson
wrote:
>
> Dave Korn wrote:
>>
>> Rafael Espindola wrote:
>>
It's not a valid option for ld. It *is* a valid option for the
collect2
driver/wrapper executable that gcc uses to invoke ld, which suggests to
me
that t
On Sun, Jan 3, 2010 at 6:46 AM, Joshua Haberman wrote:
> The aliasing policies that GCC implements seem to be more strict than
> what is in the C99 standard. I am wondering if this is true or whether
> I am mistaken (I am not an expert on the standard, so the latter is
> definitely possible).
>
>
On Sun, Jan 3, 2010 at 10:55 PM, Joshua Haberman wrote:
> Richard Guenther gmail.com> writes:
>> On Sun, Jan 3, 2010 at 6:46 AM, Joshua Haberman
> gmail.com> wrote:
>> > The aliasing policies that GCC implements seem to be more strict than
>> > what is in
On Sun, Jan 3, 2010 at 11:54 PM, Joshua Haberman wrote:
> Richard Guenther gmail.com> writes:
>> On Sun, Jan 3, 2010 at 10:55 PM, Joshua Haberman
> gmail.com> wrote:
>> > This is why perfect warnings about this issue are not possible; if we
>> > see a downcas
On Mon, Jan 4, 2010 at 12:19 AM, Joshua Haberman wrote:
> By the way, here is one case I tested where I was surprised GCC was not
> more aggressive:
>
> extern void bar();
> int foo(int *i) {
> if(*i) bar();
> return *i;
> }
>
> With GCC 4.4.1 -O3 (Ubuntu, x86-64) this reloads *i if bar i
On Tue, Jan 5, 2010 at 9:46 AM, Eric Fisher wrote:
> Hi,
>
> I found that sometimes -fno-tree-dominator-opts will bring a big speed
> promotion. This is because that pass_dominator tries to thread jumps.
> But sometimes this will cause that the loop's exit bb does not
> dominator its latch bb agai
On Tue, Jan 5, 2010 at 2:40 PM, torbenh wrote:
>
> hi...
>
> i am new to this list.
>
> i am trying to something like:
>
> struct Ramp
> {
> float phase;
> inline float process() { return phase++; }
> } ramp;
>
> void fill_buffer( float *buf, size_t nframes )
> {
> for( size_t i=0; i
On Tue, Jan 5, 2010 at 4:03 PM, torbenh wrote:
> On Tue, Jan 05, 2010 at 02:46:30PM +0100, Richard Guenther wrote:
>> On Tue, Jan 5, 2010 at 2:40 PM, torbenh wrote:
>>
>> The -fno-alias-X things do not make much sense for user code (they
>> have been historicall
On Tue, Jan 5, 2010 at 5:39 PM, torbenh wrote:
> On Tue, Jan 05, 2010 at 04:27:33PM +0100, Richard Guenther wrote:
>> On Tue, Jan 5, 2010 at 4:03 PM, torbenh wrote:
>> > On Tue, Jan 05, 2010 at 02:46:30PM +0100, Richard Guenther wrote:
>> >> On Tue, Jan 5, 2
On Wed, Jan 6, 2010 at 4:25 PM, torbenh wrote:
> On Wed, Jan 06, 2010 at 02:27:15PM +0100, Richard Guenther wrote:
>> On Tue, Jan 5, 2010 at 5:39 PM, torbenh wrote:
>> > On Tue, Jan 05, 2010 at 04:27:33PM +0100, Richard Guenther wrote:
>> >> On Tue, Jan 5, 2
On Wed, Jan 6, 2010 at 4:45 PM, Richard Guenther
wrote:
> On Wed, Jan 6, 2010 at 4:25 PM, torbenh wrote:
>> On Wed, Jan 06, 2010 at 02:27:15PM +0100, Richard Guenther wrote:
>>> On Tue, Jan 5, 2010 at 5:39 PM, torbenh wrote:
>>> > On Tue, Jan 05, 2010 at 04:27:33PM
On Wed, Jan 6, 2010 at 4:45 PM, torbenh wrote:
> On Wed, Jan 06, 2010 at 04:25:59PM +0100, torbenh wrote:
>> On Wed, Jan 06, 2010 at 02:27:15PM +0100, Richard Guenther wrote:
>> > On Tue, Jan 5, 2010 at 5:39 PM, torbenh wrote:
>> > > On Tue, Jan 05, 2010 at 04:2
On Wed, Jan 6, 2010 at 7:20 PM, Nick Stoughton wrote:
> On Sun, 2010-01-03 at 10:31 -0800, Patrick Horgan wrote:
>> Richard Guenther wrote:
>> > On Sun, Jan 3, 2010 at 6:46 AM, Joshua Haberman
>> > wrote:
>> >
>> >> ... elision by patrick of part
On Thu, Jan 7, 2010 at 12:29 PM, Andrew Haley wrote:
> On 01/06/2010 07:24 PM, Joshua Haberman wrote:
>
>> In the notes that Nick referenced it says:
>>
>> Is there anybody that thinks the rules are clear enough? No one is
>> really able to interpret them. So it seems that they are not
>>
On Sun, Jan 10, 2010 at 10:36 PM, Andrew Hutchinson
wrote:
>
>
> Kai Tietz wrote:
>>
>> Well, open call there aren't that much but point of interest is in
>> 'c-pch.c: fd = open (name, O_RDONLY | O_BINARY, 0666);' as it uses
>> O_BINARY, too. See also for pattern in libiberty mkstemps.c
>>
>> Reg
On Mon, Jan 11, 2010 at 4:46 PM, Paulo J. Matos wrote:
> Hi all,
>
> I am using gcc 4.3.4 to loop through the gimple tree to find
> CALL_EXPR. This is what I have (even though I tried several variants,
> none of which worked):
> tree body_stmt = DECL_SAVED_TREE (current_function_decl);
> while
On Mon, Jan 11, 2010 at 7:15 PM, Matthias Klose wrote:
> A rebuild test of the current Debian unstable distribution on
> x86_64-linux-gnu was done, one rebuild test with the current gcc-4.4 from
> the branch, and another one with GCC trunk 20100107. The latter did show
> about 200 additional build
On Mon, Jan 11, 2010 at 8:39 PM, Paulo J. Matos wrote:
> On Mon, 2010-01-11 at 17:51 +0100, Richard Guenther wrote:
>> On Mon, Jan 11, 2010 at 4:46 PM, Paulo J. Matos wrote:
>> > Hi all,
>> >
>> > I am using gcc 4.3.4 to loop through the gimple tree to find
On Tue, Jan 12, 2010 at 12:13 PM, Paulo J. Matos wrote:
> On Tue, Jan 12, 2010 at 10:43 AM, Richard Guenther
> wrote:
>>
>> Because it talks about trees as used by the C / C++ frontends
>> and it is way out of date anyway.
>>
>
> Thanks, the tree iterator
On Mon, Jan 18, 2010 at 11:24 AM, Paulo J. Matos wrote:
> Hi,
>
> As a continuation of my previous issue, what's the difference between
> cfun and current_function_decl and which one should I use to walk the
> tree during TARGET_FUNCTION_OK_FOR_SIBCALL?
>
> [In the internals document I only found
On Mon, Jan 18, 2010 at 1:40 PM, Paulo J. Matos wrote:
> On Mon, Jan 18, 2010 at 10:30 AM, Richard Guenther
> wrote:
>> On Mon, Jan 18, 2010 at 11:24 AM, Paulo J. Matos wrote:
>>> Hi,
>>>
>>> As a continuation of my previous issue, wha
On Mon, Jan 18, 2010 at 2:05 PM, Paulo J. Matos wrote:
> On Mon, Jan 18, 2010 at 12:58 PM, Richard Guenther
> wrote:
>>
>> Yes. During expansion we destroy the trees.
>>
>
> Is there a way to avoid tree destruction? Maybe through a flag?
> If not, what I ne
On Fri, Jan 22, 2010 at 1:48 PM, sandeep soni wrote:
> Hi,
>
> I posted this question on the mailing list gcc-h...@gcc.gnu.org
> but did not get any reply about it.
>
> I have bootstrapped gcc 4.4.2 on my machine and now i have to make
> changes in gcc code. However, I dont know how to make
On Sat, Jan 23, 2010 at 4:16 PM, Olivier Galibert wrote:
> On Sat, Jan 23, 2010 at 09:21:47AM -0500, Joern Rennecke wrote:
>> [This started on gcc-patches]
>> Quoting Richard Guenther :
> [...]
>> > bool all_critical_edge_p = true;
>> > all_critica
On Sat, Jan 23, 2010 at 5:34 PM, Franz Fehringer wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi all,
>
> I have two hopefully not too dull questions about the gcc fixincludes
> mechanism:
> 1) When after the initial fixinclude run (parts of) new software is
> installed into /usr/i
On Sat, Jan 23, 2010 at 5:43 PM, Franz Fehringer wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> understood.
> but an OS update could lead to updated C runtime headers?
Yes.
Richard.
On Sat, Jan 23, 2010 at 5:47 PM, Steve White wrote:
> Hi,
>
> I recently revised some speed tests of basic CPU operations.
> There were a few surprises, but one was that, a test of double-precision
> divide was a factor of ten slower when compiled with gcc than with the
> Intel compiler icc.
>
> T
On Sat, Jan 23, 2010 at 6:33 PM, Steve White wrote:
> Hi, Andrew!
>
> Thanks for the suggestion, but it didn't make any difference for me.
> Neither the speed nor the assembler was significantly altered.
>
> Which version of gcc did you use? Mine is 4.4.1.
>
> I threw everything at it:
> g
On Sun, Jan 24, 2010 at 10:32 PM, Steve White wrote:
> Richard,
>
> Could you provide us with a good reference for the latencies and other
> speed issues of SSE operations? What I've found is scattered and hard
> to compare.
>
> Frankly, I was under the misconception that each of these SSE operat
On Mon, Jan 25, 2010 at 1:24 PM, Piotr Wyderski
wrote:
> I have a hash function hash(T v) overloaded for
> all integral types. I want to provide a variant for
> float and double, which should work as follows:
> take the floating-point value, treat its binary
> representation as uint32_t/uint64_t a
On Mon, Jan 25, 2010 at 3:42 PM, Erik Trulsson wrote:
> On Mon, Jan 25, 2010 at 02:19:04PM +0100, Richard Guenther wrote:
>> On Mon, Jan 25, 2010 at 1:24 PM, Piotr Wyderski
>> wrote:
>> > I have a hash function hash(T v) overloaded for
>> > all integral types
On Tue, Jan 26, 2010 at 8:13 PM, David Edelsohn wrote:
> I am pleased to announce that the GCC Steering Committee has
> accepted the contribution of the gccgo front-end and gcc-specific runtime
> for the Go language with Ian Taylor appointed maintainer. The GCC
> Release Managers will deci
On Thu, Jan 28, 2010 at 5:13 PM, Byron Stanoszek wrote:
> I've recently upgraded to GCC 4.3.2 from 4.2.2, and I noticed a strange
> change in how volatile bitmask structures are optimized.
>
> Consider the following code:
>
> /* 32-bit MMIO */
> struct hardware {
> int parm1:8;
> int :4;
> int
On Fri, Jan 29, 2010 at 11:29 AM, Piotr Wyderski
wrote:
> Steven Bosscher wrote:
>
Only RMs may set priority.
>>>
>>> I beg your pardon? Where in the docs does it say that?
>>
>> I don't know that, but it's been discussed many times on this list.
>
> As a mere mortal I've used the priority s
801 - 900 of 2444 matches
Mail list logo
