On Fri, May 21, 2010 at 6:13 PM, Xinliang David Li wrote:
> On Fri, May 21, 2010 at 2:24 AM, Richard Guenther
> wrote:
>> On Thu, May 20, 2010 at 11:21 PM, Xinliang David Li
>> wrote:
>>> On Thu, May 20, 2010 at 2:18 PM, Steven Bosscher
>>> wrote:
&
On Fri, May 21, 2010 at 7:30 PM, Xinliang David Li wrote:
> On Fri, May 21, 2010 at 2:24 AM, Richard Guenther
> wrote:
>> On Thu, May 20, 2010 at 11:21 PM, Xinliang David Li
>> wrote:
>>> On Thu, May 20, 2010 at 2:18 PM, Steven Bosscher
>>> wrote:
&
On Fri, May 21, 2010 at 10:29 PM, Xinliang David Li wrote:
> On Fri, May 21, 2010 at 10:35 AM, Richard Guenther
> wrote:
>> On Fri, May 21, 2010 at 7:30 PM, Xinliang David Li
>> wrote:
>>> On Fri, May 21, 2010 at 2:24 AM, Richard Guenther
>>> wrote:
&
Status
==
The GCC 4.3.5 release has been created and uploaded, it will
be announced once the mirrors had a chance to pick it up.
The 4.3 branch is open again for regression and documentation fixes.
Previous Report
===
http://gcc.gnu.org/ml/gcc/2010-05/msg00253.html
I will co
On Sat, May 22, 2010 at 10:29 PM, Steve Kargl
wrote:
> Guys,
>
> I only read the gcc@ archive, so sorry about breaking the thread.
> Testing with gfortran finds
>
> FreeBSD's libelf with no patches.
>
> === gfortran Summary ===
>
> # of expected passes 34177
> # of unexpe
On Sun, May 23, 2010 at 9:09 PM, Gerald Pfeifer wrote:
> On Sat, 22 May 2010, Richard Guenther wrote:
>> The GCC 4.3.5 release has been created and uploaded, it will
>> be announced once the mirrors had a chance to pick it up.
>> [...]
>> I will continue to send status
On Mon, May 24, 2010 at 4:52 AM, Steve Kargl
wrote:
> Kai,
>
> I tested your patch posted here:
>
> http://gcc.gnu.org/ml/gcc/2010-05/msg00445.html
>
> to address the issue
>
> % cat x.c
> int main() { }
> % gccvs -flto x.c
> % gccvs -fwhopr x.c
> lto1: fatal error: elf_update() failed:
On Mon, May 24, 2010 at 1:50 AM, FX wrote:
>> The current trunk does require flex.
>> The build dies pretty quickly unless flex is available.
>>
>
>
> Was the flex dependency recently reintroduced? It used to be that if you
> update trunk with contrib/gcc_update (instead of svn up), it sets the
>
On Tue, May 25, 2010 at 10:02 PM, Easwaran Raman wrote:
> On Fri, May 21, 2010 at 10:30 AM, Xinliang David Li
> wrote:
>>
>> On Fri, May 21, 2010 at 2:24 AM, Richard Guenther
>> wrote:
>> > On Thu, May 20, 2010 at 11:21 PM, Xinliang David Li
>> > wr
On Wed, May 26, 2010 at 4:27 PM, roy rosen wrote:
> Hi,
>
> I have tried vectorization and encountered a problem which I can see
> is common to some ports (I tried ia64 and bfin).
>
> For this function:
>
> #define ts unsigned short
> void f(ts* __restrict__ a, ts* __restrict__ b, ts* __restrict__
On Wed, May 26, 2010 at 5:38 PM, Eric Botcazou wrote:
>> When I run the test suite with Ada, I have two test suite failures,
>> for lto6.adb and lto8.adb. The failure mode is the same for both, see
>> end of this mail. Are these failures expected?
>
> That's an LTO bug: it can change the personali
On Wed, May 26, 2010 at 5:42 PM, Xinliang David Li wrote:
> On Wed, May 26, 2010 at 2:58 AM, Richard Guenther
> wrote:
>> On Tue, May 25, 2010 at 10:02 PM, Easwaran Raman wrote:
>>> On Fri, May 21, 2010 at 10:30 AM, Xinliang David Li
>>> wrote:
>>>
On Wed, May 26, 2010 at 5:53 PM, Bingfeng Mei wrote:
> Hi, Richard,
> With resolution file generated by GOLD (or I am going to hack gnu LD), is
> externally_visible attribute still needed to annotate those symbols accessed
> from non-LTO objects when compiling with -fwhole-program.
Yes it is. W
On Wed, May 26, 2010 at 6:08 PM, Eric Botcazou wrote:
>> You could "fix" this by walking all functions and check if only
>> one real language personality routine remains and promote
>> the generic C personality uses to that. Of course you need then
>> to be able to identify the C personality whic
On Wed, May 26, 2010 at 6:05 PM, Richard Guenther
wrote:
> On Wed, May 26, 2010 at 5:42 PM, Xinliang David Li wrote:
>> On Wed, May 26, 2010 at 2:58 AM, Richard Guenther
>> wrote:
>>> On Tue, May 25, 2010 at 10:02 PM, Easwaran Raman wrote:
>>>> On Fri, May
On Thu, May 27, 2010 at 1:37 PM, Paolo Bonzini wrote:
> On 05/27/2010 12:33 PM, Amker.Cheng wrote:
>>
>> while GCC3.4.4 treats the long long multiplication just like simple
>> ones, which generates only one
>> mult insn for each statement, like
>>
>> In my understanding, It‘s not necessary using t
On Fri, May 28, 2010 at 11:25 PM, Ian Lance Taylor wrote:
> "Vakatov, Denis (NIH/NLM/NCBI) [E]" writes:
>
>> Ian Lance Taylor wrote:
>>
>>> We should handle must_use_result and warn_unused_result similarly, except
>>> that adding a cast to (void) disables the warn_unused_result warning.
>>> Pe
On Sat, May 29, 2010 at 3:13 AM, Dave Korn wrote:
> On 29/05/2010 01:17, Ian Lance Taylor wrote:
>> Dave Korn writes:
>>
>>> On 28/05/2010 22:25, Ian Lance Taylor wrote:
>>>
The warn_unused_result extension was implemented specifically to catch
security problems. Permitting developers
On Sat, May 29, 2010 at 3:16 AM, Dave Korn wrote:
> On 29/05/2010 01:14, Ian Lance Taylor wrote:
>> Dave Korn
>>> there is *no* circumstances
>>> under which ignoring the return from *any* function is *always* a bug.
>
>> For practical purposes, it is always a bug to ignore the return value
>>
The GNU Compiler Collection version 4.3.5 has been released.
GCC 4.3.5 is a bug-fix release containing fixes for regressions and
serious bugs in GCC 4.3.4. This release is available from the
FTP servers listed at:
http://www.gnu.org/order/ftp.html
Please do not contact me directly regarding
On Mon, May 31, 2010 at 12:41 PM, Robert Dewar wrote:
> 徐持恒 wrote:
>
>> I have FUD on the use of "advanced" C++ features like template(even
>> standard template), namespace, exceptions. This is partly because my
>> favorite source code analyzer can not handle them properly. I have
>> tried to use
On Mon, May 31, 2010 at 12:59 PM, Robert Dewar wrote:
> 徐持恒 wrote:
>>
>> On Mon, May 31, 2010 at 6:41 PM, Robert Dewar wrote:
>>
>>> It's a pity to exclude namespaces, the advantage of breaking the
>>> single-big-namespace model are evident.
>>
>> Yes, the advantage of namespace is obvious.
>>
>>
On Mon, May 31, 2010 at 4:58 PM, Gabriel Dos Reis
wrote:
> On Mon, May 31, 2010 at 3:42 AM, Basile Starynkevitch
> wrote:
>> On Mon, May 31, 2010 at 01:39:08AM -0500, Gabriel Dos Reis wrote:
>>> On Mon, May 31, 2010 at 12:28 AM, Basile Starynkevitch
>>> wrote:
>>>
>>> > At last, there is a very
On Mon, May 31, 2010 at 5:09 PM, Steven Bosscher wrote:
> On Mon, May 31, 2010 at 5:03 PM, Richard Guenther
> wrote:
>> And we definitely should not do so just because we can. I see
>> little value in turning our tree upside-down just because we now
>> can use C++ and
On Mon, May 31, 2010 at 5:29 PM, David Fang wrote:
>> For example, I think it goes without question that at this point we are
>> limiting ourselves to C++98 (plus "long long" so that we have a 64-bit
>> integer type); C++0x features should not be used. Using multiple
>> inheritance, templates (ot
On Mon, May 31, 2010 at 5:53 PM, Diego Novillo wrote:
> On Mon, May 31, 2010 at 11:09, Steven Bosscher wrote:
>> On Mon, May 31, 2010 at 5:03 PM, Richard Guenther
>> wrote:
>>> And we definitely should not do so just because we can. I see
>>> little value in
On Mon, May 31, 2010 at 6:22 PM, Diego Novillo wrote:
>
> Now that the SC and the FSF have agreed to this, we should decide whether we
> switch and how. So, I would like comments on the following questions:
>
> 1- Should we switch to C++?
Yes.
> 2- What is the cost in terms of build time?
I wa
On Thu, Feb 18, 2010 at 1:26 AM, Paolo Bonzini wrote:
>>> Maybe we can use this in AC_CHECK_DECLS instead of having a new
>>> separate macro. If there is a parenthesis in the name call the new
>>> version, if there is none, call the old one.
>>
>> You shouldn't need to keep the old version around
On Tue, Jun 1, 2010 at 4:48 PM, Mark Mitchell wrote:
> Ian Lance Taylor wrote:
>
>> I have written a proposed set of C++ coding conventions on the wiki at
>> http://gcc.gnu.org/wiki/CppConventions
>>
>> This is only a preliminary proposal. It requires fleshing out and
>> discussion.
>
> Thank
On Tue, Jun 1, 2010 at 12:00 PM, Richard Guenther
wrote:
> On Mon, May 31, 2010 at 6:22 PM, Diego Novillo wrote:
>>
>> Now that the SC and the FSF have agreed to this, we should decide whether we
>> switch and how. So, I would like comments on the following questions:
>
On Tue, Jun 1, 2010 at 6:32 PM, Vladimir Makarov wrote:
> Richard Guenther wrote:
>>
>> On Tue, Jun 1, 2010 at 12:00 PM, Richard Guenther
>> wrote:
>>
>>>
>>> On Mon, May 31, 2010 at 6:22 PM, Diego Novillo
>>> wrote:
>>>
>&
On Tue, Jun 1, 2010 at 6:58 PM, Ian Lance Taylor wrote:
> Richard Guenther writes:
>
>> Overall the wiki document looks good. I'd like to disallow
>>
>> * Operators may only be overloaded for types which implement numeric
>> values, where the overloaded op
On Tue, Jun 1, 2010 at 6:37 PM, Robert Dewar wrote:
> Richard Guenther wrote:
>>
>> On Tue, Jun 1, 2010 at 4:48 PM, Mark Mitchell
>> wrote:
>>>
>>> Ian Lance Taylor wrote:
>>>
>>>> I have written a proposed set of C++ codin
On Wed, Jun 2, 2010 at 1:38 AM, Ian Lance Taylor wrote:
> DJ Delorie writes:
>
>>> I did mean that all virtual functions should be protected.
>>
>> This forbids the most useful thing about virtual functions - letting
>> child classes implement a public ABI defined by the base class.
>
> There are
On Wed, Jun 2, 2010 at 2:49 AM, Gabriel Dos Reis
wrote:
> On Tue, Jun 1, 2010 at 7:38 PM, DJ Delorie wrote:
>>
>> "Hargett, Matt" writes:
As noted earlier I think we do want to use some STL classes.
>>>
>>> I agree with Mark's earlier declaration that it is relatively
>>> straight-forward,
On Wed, Jun 2, 2010 at 12:00 PM, Bingfeng Mei wrote:
> Hi,
>
> For the following simple example,
>
> int main(void)
> {
> int a=0;
> switch (a)
> {
> case 0:
> int b=2;
> break;
> }
> }
>
> GCC will complain:
> tst.c: In function 'main':
> tst.c:7:6: error: a label can only be
On Wed, Jun 2, 2010 at 1:51 PM, David Edelsohn wrote:
> On Wed, Jun 2, 2010 at 2:07 AM, Laurynas Biveinis
> wrote:
>> Hello all -
>>
>> All the patches from gc-improv merge have been approved. Due to the
>> scope of the changes, the merge will need trunk freeze. Thus I am
>> planning to do it nex
On Wed, Jun 2, 2010 at 3:04 PM, Gabriel Dos Reis
wrote:
> On Wed, Jun 2, 2010 at 4:19 AM, Richard Guenther
> wrote:
>
>> I'd like us to stick with C comments only. I defintely do not like
>> a mix of both styles and I can't see an advantage of C++ comments.
>
On Wed, Jun 2, 2010 at 6:03 PM, Tom Tromey wrote:
>> "Basile" == Basile Starynkevitch writes:
>
> Basile> Still, my concerns on C++ is mostly gengtype related. I believe we
> need
> Basile> to keep a garbage collector even with C++, and I believe that changing
> Basile> gengtype to follow C+
On Thu, Jun 3, 2010 at 1:49 AM, Michael Meissner
wrote:
> As I was about to check in the -mrecip changes for powerpc on GCC 4.6, I
> figured to get a start on documentation, and I was going to edit the
> gcc-4.6/changes.html file. I realize this is early in the cycle, but did we
> want to create
On Thu, Jun 3, 2010 at 9:01 AM, Ira Rosen wrote:
>
>
> Steven Bosscher wrote on 02/06/2010 06:13:36 PM:
>
>>
>> On Wed, May 26, 2010 at 7:16 PM, Mark Mitchell
> wrote:
>> > Ulrich Weigand wrote:
>> >
>> >>> So the question is: The goal is to have hooks, not macros, right? If
>> >>> so, can revie
On Thu, Jun 3, 2010 at 12:51 PM, Robert Dewar wrote:
> Steven Bosscher wrote:
>
>> Indeed. It is, well, perhaps not surprising, but quite annoying (to me
>> at least) that a possible move to C++ as implementation language of
>> GCC is so much bigger news than all the amazing amounts of work done
>
On Thu, Jun 3, 2010 at 1:14 PM, Ira Rosen wrote:
>
>
> Richard Guenther wrote on 03/06/2010 02:00:00
> PM:
>
>> >> tree-vectorizer.h:#ifndef TARG_COND_TAKEN_BRANCH_COST
>> >> tree-vectorizer.h:#ifndef TARG_COND_NOT_TAKEN_BRANCH_COST
>> >&
On Fri, Jun 4, 2010 at 6:38 PM, Joseph S. Myers wrote:
> On Tue, 1 Jun 2010, Artem Shinkarov wrote:
>
>> This is a reworked patch of Andrew Pinski "Subscripting on vector
>> types" in terms of GSoC 2010 [Artjoms Sinkarovs].
>
> We can't consider it without a copyright assignment.
>
>> The document
On Fri, Jun 4, 2010 at 11:39 PM, Andrew Pinski wrote:
> On Tue, Jun 1, 2010 at 12:21 PM, Artem Shinkarov
> wrote:
>
> + error_at (loc, "index value is out of bound");
>
> That is wrong. The Cell C/C++ language document says out of bounds
> accesses are undefined (that is at runtime).
I thi
On Tue, Jun 1, 2010 at 9:21 PM, Artem Shinkarov
wrote:
> This is a reworked patch of Andrew Pinski "Subscripting on vector
> types" in terms of GSoC 2010 [Artjoms Sinkarovs].
>
> This patch allows to index individual elements of vector type in C.
> For example: vec[i], where vec is a vector with a
On Sat, Jun 5, 2010 at 10:49 PM, Andrew Pinski wrote:
> On Sat, Jun 5, 2010 at 3:10 AM, Richard Guenther
> wrote:
>> On Fri, Jun 4, 2010 at 11:39 PM, Andrew Pinski wrote:
>>> On Tue, Jun 1, 2010 at 12:21 PM, Artem Shinkarov
>>> wrote:
>>>
>>> +
On Tue, Jun 8, 2010 at 3:01 PM, Bingfeng Mei wrote:
> Hi,
> Sorry for coming back to this issue after a while. I am still puzzled
> by this. The following are two test files:
>
> a.c
>
> #include
> #include
> extern int foo(int);
> void bar()
> {
> printf("bar\n");
> }
> extern int src[], dst[]
On Tue, Jun 8, 2010 at 4:15 PM, Bingfeng Mei wrote:
> Thanks. But why "v" is linked correctly here? Shouldn't it
> be treated as static with -fwhole-program?
Works for me without the linker plugin as well:
> gcc-4.5 -O2 -o t t1.o t2.o -flto -fwhole-program -B
> /abuild/rguenther/trunk-g/gcc
gin bug that causes bar
to be resolved.
Richard.
> Thanks,
> Bingfeng
>
>> -----Original Message-
>> From: Richard Guenther [mailto:richard.guent...@gmail.com]
>> Sent: 08 June 2010 15:18
>> To: Bingfeng Mei
>> Cc: Jan Hubicka; gcc@gcc.gnu.org; Cary Cout
On Wed, Jun 9, 2010 at 7:43 PM, Cary Coutant wrote:
>>> Yes, this is also what I saw without plugin. I just wonder why "v"
>>> is linked with plugin if resolution file is not used to eliminate need
>>> of externally_visible attribute here.
>>
>> Probably because of the same linker-plugin bug t
On Thu, Jun 10, 2010 at 10:26 PM, Andi Kleen wrote:
> Hi Honza,
>
> Here's an idea to make it easier to manually annotate
> large C code bases for hot/cold functions where
> it's too difficult to use profile feedback.
>
> It's fairly common here to call function through
> function pointers in manu
On Fri, Jun 11, 2010 at 2:04 PM, Bingfeng Mei wrote:
> Hi,
>
> I am still puzzled by the effect of LTO/-fwhole-program.
> For the following simple tests:
>
> a.c:
>
> #include
> int v;
>
> extern void bar();
> int main()
> {
> v = 5;
> bar();
>
> printf("v = %d\n", v);
> return 0;
> }
>
> b.c
On Fri, Jun 11, 2010 at 2:22 PM, Manuel López-Ibáñez
wrote:
> On 11 June 2010 14:07, Richard Guenther wrote:
>> On Fri, Jun 11, 2010 at 2:04 PM, Bingfeng Mei wrote:
>>> Hi,
>>>
>>> I am still puzzled by the effect of LTO/-fwhole-program.
>>>
On Fri, Jun 11, 2010 at 2:36 PM, Manuel López-Ibáñez
wrote:
> On 11 June 2010 14:23, Richard Guenther wrote:
>> On Fri, Jun 11, 2010 at 2:22 PM, Manuel López-Ibáñez
>> wrote:
>>> On 11 June 2010 14:07, Richard Guenther wrote:
>>>> On Fri, Jun 11, 2010 at 2:
On Fri, Jun 11, 2010 at 2:57 PM, Manuel López-Ibáñez
wrote:
> On 11 June 2010 14:40, Richard Guenther wrote:
>> On Fri, Jun 11, 2010 at 2:36 PM, Manuel López-Ibáñez
>> wrote:
>>> On 11 June 2010 14:23, Richard Guenther wrote:
>>>> On Fri, Jun 11,
On Fri, Jun 11, 2010 at 3:21 PM, Dave Korn wrote:
> On 11/06/2010 13:59, Richard Guenther wrote:
>
>> Well, we can't. We specifically support mixed LTO/non LTO objects
>> (think of shared libraries for example). With the linker-plugin and gold
>> we can do bet
>> Sent: 11 June 2010 14:21
>> To: Richard Guenther
>> Cc: Manuel López-Ibáñez; Bingfeng Mei; gcc@gcc.gnu.org; Jan Hubicka
>> Subject: Re: Issue with LTO/-fwhole-program
>>
>> On 11/06/2010 13:59, Richard Guenther wrote:
>>
>> > Well, we can'
On Fri, Jun 11, 2010 at 9:41 PM, Manuel López-Ibáñez
wrote:
> On 11 June 2010 20:48, Cary Coutant wrote:
>>> But if I understand correctly, mixed LTO/non-LTO + whole-program is
>>> almost never correct. So we should really emit a warning for this
>>> specific combination. I think making this mist
On Sat, Jun 12, 2010 at 3:32 PM, David Brown wrote:
> Ian Lance Taylor wrote:
>>
>> Manuel López-Ibáñez writes:
>>
>>> This also means that linking your program with non-LTO+whole-program
>>> code may lead to miscompilations without any warning, which is really
>>> bad. I don't think it is a reas
On Sun, Jun 13, 2010 at 4:29 PM, Ilya K wrote:
> Hi all.
> (I have never used these maillists before. Sorry if something wrong here.)
>
> I am newbie in gcc and I need some help.
>
> I am performing some research work in theme of code optimization.
> Now I have to write my own optimization pass fo
On Mon, Jun 14, 2010 at 9:26 AM, David Brown wrote:
> On 14/06/2010 06:43, Ian Lance Taylor wrote:
>>
>> David Brown writes:
>>
>>> After doing a bit more reading and thinking, it seems to me that
>>> -fwhole-program will be used in most cases where LTO is used. You use
>>> -flto when compiling
On Mon, Jun 14, 2010 at 11:27 AM, David Brown wrote:
> On 14/06/2010 11:22, Dave Korn wrote:
>>
>> On 14/06/2010 05:43, Ian Lance Taylor wrote:
>>>
>>> David Brown writes:
>>>
After doing a bit more reading and thinking, it seems to me that
-fwhole-program will be used in most cases whe
On Tue, Jun 15, 2010 at 4:03 AM, Diego Novillo wrote:
> I have been thinking about doing some cleanups to the pass manager.
> The goal would be to have the pass manager be the central driver of
> every action done by the compiler. In particular, the front ends
> should make use of it and the call
On Tue, Jun 15, 2010 at 11:26 AM, Basile Starynkevitch
wrote:
> Hello All,
>
> I am in the process of merging 4.6 (i.e. current trunk) into the GCC
> MELT branch. However, I want very much the same source code to be able
> to run as a plugin to 4.5 & as a plugin to 4.6. So precisely, I want
> to h
On Wed, Jun 16, 2010 at 5:52 PM, Siarhei Siamashka
wrote:
> Hello,
>
> Currently gcc (at least version 4.5.0) does a very poor job generating single
> precision floating point code for ARM Cortex-A8.
>
> The source of this problem is the use of VFP instructions which are run on a
> slow nonpipelin
On Fri, Jun 18, 2010 at 10:32 PM, PeteGarbett
wrote:
>
> I see nothing in the GCC 4.5 release notes about
> plugin support being language specific, and yet if I using the treehydra
> plugin with Ada (admittedly using a patched GCC 4.3.4 as per the dehydra
> notes), I get this
>
> gnat1: warning: c
On Mon, Jun 21, 2010 at 5:25 PM, Bernd Schmidt wrote:
> In PR43902, Jim has posted a patch to add support for widening
> multiply-accumulate to tree-ssa-math-opts. They are represented as a
> GIMPLE_SINGLE_RHS with a WIDEN_MULT_PLUS_EXPR tree which holds the
> actual operands of the multiply-accu
I am starting a review of the changes I made on the mem-ref2 branch
in preparation for a merge to trunk. This is a request for testing.
I have personally bootstrapped and tested on x86_64-unknown-linux
and powerpc64-linux (both with 32bit multilibs included and for
all languages). I also regula
On Thu, Jun 24, 2010 at 10:24 PM, Eric Botcazou wrote:
>> In addition, it appears at first glance that GCC is either no longer
>> inlining at -Os, even when it would be a size advantage to do so, or is
>> making some very poor inlining choices.
>>
>> e.g. +72 nsTArray::nsTArray(nsTArray const
On Fri, Jun 25, 2010 at 8:34 AM, Eric Botcazou wrote:
>> Minus whitespace changes it seems to be
>>
>> ! if (lhs_free && (is_gimple_reg (rhs) ||
>> is_gimple_min_invariant (rhs)))
>> rhs_free = true;
>>
>> vs.
>>
>> ! if (lhs_free
>> ! && (is_gimple_
On Fri, Jun 25, 2010 at 8:15 AM, Jonathan Adamczewski
wrote:
> On 25/06/10 06:39, Richard Guenther wrote:
>> There are btw. some bugs wrt accounting of functions called once
>> being inlined in 4.5 which were fixed on trunk which allow extra
>> inlining.
>>
>
> Ar
On Fri, Jun 25, 2010 at 12:45 PM, Eric Botcazou wrote:
>> I do think so.
>
> Huh? What do your version and mine return for the following assignment?
>
> void foo (int i)
> {
> struct S s;
> s.a = i;
> }
>
>> Which in the following example makes i = *p not likely eliminated
>> but makes j = *q l
On Fri, Jun 25, 2010 at 1:02 PM, Richard Guenther
wrote:
> On Fri, Jun 25, 2010 at 12:45 PM, Eric Botcazou wrote:
>>> I do think so.
>>
>> Huh? What do your version and mine return for the following assignment?
>>
>> void foo (int i)
>> {
>> s
On Sun, Jun 27, 2010 at 11:43 AM, Manuel López-Ibáñez
wrote:
> On 27 June 2010 11:32, Tobias Burnus wrote:
>> Gerald Pfeifer wrote:
>>> We actually do have an issue with the Bugzilla instance on gcc.gnu.org
>>> being rather old, so if anyone with Bugzilla foo wants to donate time
>>> and effort,
The trunk is frozen for all changes starting this Wednesday, 20:00 UTC
in preparation for merging the mem-ref2 branch. The freeze is expected
to last until early Friday morning. An explicit un-freeze mail will
be sent as a reply to this mail.
Thanks.
Richard.
On Mon, 28 Jun 2010, Arnaud Charlet wrote:
> > The trunk is frozen for all changes starting this Wednesday, 20:00 UTC
>
> Web will be the 30th, not the 28th, can you confirm the date?
Whoops sorry - 30th indeed. This is what you get for picking the
date off your clock instead of looking at a ca
On Mon, 28 Jun 2010, Jack Howarth wrote:
> On Mon, Jun 28, 2010 at 02:59:39PM +0200, Richard Guenther wrote:
> >
> > The trunk is frozen for all changes starting this Wednesday, 20:00 UTC
> > in preparation for merging the mem-ref2 branch. The freeze is expected
> >
On Tue, Jun 29, 2010 at 1:55 AM, Ian Lance Taylor wrote:
> Artem Shinkarov writes:
>
>> I'm trying to implement a support for vector shuffling. For this
>> purpose I would like to introduce a built-in function and lower it
>> down in the veclower pass. However the problem is, that I don't want
>>
On Tue, Jun 29, 2010 at 1:42 AM, Jonathan Wakely wrote:
> On 29 June 2010 00:19, Basile Starynkevitch wrote:
>> On Mon, 2010-06-28 at 16:08 -0700, Ian Lance Taylor wrote:
>>> Basile Starynkevitch writes:
>>>
>>> > * I don't know exactly what should be wished with respect to templates.
>>> > Tom T
On Tue, Jun 29, 2010 at 4:16 AM, Tom Tromey wrote:
> Ian> In Tom's interesting idea, we would write the mark function by hand for
> Ian> each C++ type that we use GTY with.
>
> I think we should be clear that the need to write a mark function for a
> new type is a drawback of this approach. Perha
The trunk is frozen now. I am in the process of committing a
last trunk-to-branch merge and start testing of the merge
(and the trunk for comparison) on x86_64-linux, ppc64-linux
and ia64-linux including multilibs where appropriate.
Thanks for your cooperation,
Richard.
On Wed, Jun 30, 2010 at 10:49 PM, Paolo Carlini
wrote:
> On 06/30/2010 09:59 PM, Richard Guenther wrote:
>> The trunk is frozen now. I am in the process of committing a
>> last trunk-to-branch merge and start testing of the merge
>> (and the trunk for comparison) on x86_
On Thu, Jul 1, 2010 at 2:48 PM, David Brown wrote:
> I was perhaps over-generalising - obviously anything that depends on target
> specifics will be dependent on the target. And I'd also expect some things
> to change in the plugin interface between major gcc versions - while it
> would be nice t
On Thu, Jul 1, 2010 at 3:23 PM, Joern Rennecke wrote:
> Quoting Richard Guenther :
>
>> Re-compiling the same plugin sources for different gcc versions is
>> not supported. Of course you might be lucky for minor version
>> changes such as 4.5.3 to 4.5.4.
>
> I thi
On Thu, Jul 1, 2010 at 5:02 PM, Bingfeng Mei wrote:
> Hi,
> I did some experiments to convert cross-reference table
> to resolution files. Patches are attached and still crude.
>
> The initial idea is to have as little as possible change
> in GNU LD. It turns out that cross reference table doesn't
On Thu, Jul 1, 2010 at 5:30 PM, Richard Earnshaw wrote:
>
> On Wed, 2010-06-16 at 08:09 -0700, Andrew Pinski wrote:
>>
>> Sent from my iPhone
>>
>> On Jun 16, 2010, at 6:04 AM, Richard Guenther > > wrote:
>>
>> > On Wed, Jun 16, 2010 at
On Thu, Jul 1, 2010 at 10:29 PM, Taras Glek wrote:
> On 06/30/2010 03:06 PM, Jan Hubicka wrote:
>>
>> If you can find actual simple examples where -Os is losing size and speed
>> we can try
>> to do something about them.
>>
>
> According to our code size reports, inlining is completely screwed for
On Thu, Jul 1, 2010 at 11:36 PM, Taras Glek wrote:
> On 07/01/2010 02:27 PM, Richard Guenther wrote:
>>
>> On Thu, Jul 1, 2010 at 10:29 PM, Taras Glek wrote:
>>>
>>> On 06/30/2010 03:06 PM, Jan Hubicka wrote:
>>>>
>>>> If you can
On Mon, 28 Jun 2010, Richard Guenther wrote:
> The trunk is frozen for all changes starting this Wednesday, 20:00 UTC
> in preparation for merging the mem-ref2 branch. The freeze is expected
> to last until early Friday morning. An explicit un-freeze mail will
> be sent as a reply
On Fri, Jul 2, 2010 at 4:06 PM, Frank Ch. Eigler wrote:
> Joern Rennecke writes:
>
>> [...] But if the function is very simple, the only reason to keep
>> it would be if its address was taken somewhere, or if we tailcall
>> it.
>
> ... or to make it available from gdb as an inferior call.
We do
On Mon, Jul 5, 2010 at 1:54 PM, Tom de Vries wrote:
>> Interesting. My first reaction is that this is an invalid use of the
>> garbage collector. I think there is really only one valid function
>> that can be used as an if_marked function: one which checks
>> ggc_marked_p on the structure.
>
>
>
On Mon, Jul 5, 2010 at 5:57 PM, Tom de Vries wrote:
> Hi,
>
>>> The tree_map_base_marked_p checks ggc_marked_p on the from field. During
>>> ggc_scan_cache_tab, if the from field is live, also the to field is
>>> marked
>>> live.
>>> I wrote some code to do sanity testing and found a similar scena
On Tue, Jul 6, 2010 at 6:12 PM, Tom de Vries wrote:
> Hi Richard,
>
>>> I can image a few ways to go from here:
>>> - leave as is, fix this when it really bothers us (risk: exchange a known
>>> problem for unknown hard-to-debug and/or hard-to-reproduce problems)
>>> - instrument if_marked function
On Tue, Jul 13, 2010 at 4:50 PM, Paolo Bonzini wrote:
> On 07/08/2010 10:58 PM, Maxiwell Garcia wrote:
>>
>> Hi,
>>
>> I am writing a paper about instruction-set architecture simulators. In
>> first time, I used gcc-4.4.0 and the compilation time reached 33
>> minutes (with -O3) for my simulator a
On Tue, Jul 13, 2010 at 5:26 PM, Paolo Bonzini wrote:
> On 07/13/2010 04:53 PM, Richard Guenther wrote:
>>
>> On Tue, Jul 13, 2010 at 4:50 PM, Paolo Bonzini wrote:
>>>
>>> On 07/08/2010 10:58 PM, Maxiwell Garcia wrote:
>>>>
>>>>
On Mon, Jul 19, 2010 at 11:12 AM, Ian Lance Taylor wrote:
> "Amker.Cheng" writes:
>
>> I found although there are standard pattern names such as "ceilm2/floorm2",
>> there is no insn pattern in mips.md for such float insns on mips target.
>> further more, there is no ceil/floor rtl code in rtl.
/gcc/2010-04/msg00321.html
The next status report will be sent by me.
--
Richard Guenther
Novell / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex
The 4.5 branch is frozen for preparation of a 4.5.1 release candidate
and the 4.5.1 release. Please refrain from checking in non-documentation
changes without release manager approval.
Thanks,
Richard.
any issues to
bugzilla.
The branch remains frozen and all checkins until after the final
release of GCC 4.5.1 require explicit RM approval.
If all goes well, I'd like to release 4.5.1 before Aug 1st.
Richard.
--
Richard Guenther
Novell / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg
1301 - 1400 of 2444 matches
Mail list logo
