On Wed, Sep 2, 2009 at 10:06 PM, Basile
STARYNKEVITCH wrote:
> Hello All,
>
> My feeling is that the Link Time Optimisation (LTO) effort should be soon
> (=is expected to be, or is already) merged inside GCC trunk (future 4.5).
>
> Several years ago, I asked if there is any possibility for an addit
On Wed, Sep 2, 2009 at 10:24 PM, Basile
STARYNKEVITCH wrote:
> Richard Guenther wrote:
>>
>> On Wed, Sep 2, 2009 at 10:06 PM, Basile
>> STARYNKEVITCH wrote:
>>>
>>> Hello All,
>>>
>>> My feeling is that the Link Time Optimisation (LTO) eff
As we've got quite some build problems on some targets and we clashed
with VTA, free-lang-data, expand and scheduler changes it's a good
time to slush the trunk for a short time.
Thus, starting from now the trunk is in regression and documentation
fixes only mode.
Please help sorting out issues
On Fri, Sep 4, 2009 at 1:00 AM, Richard Henderson wrote:
> Can someone tell me how to debug this:
>
>> splitting
>> /home/rth/work/gcc/bld-sjlj/gcc/testsuite/ada/acats0/tests/c3/c35502i.ada
>> into:
>> c35502i.adb
>> BUILD c35502i.adb
>> gnatmake --GCC="/home/rth/work/gcc/bld-sjlj/gcc/xgcc
>> -B/
On Fri, Sep 4, 2009 at 9:01 PM, Margaret Doll wrote:
>
>
> Begin forwarded message:
>
>> From: Margaret Doll
>> Date: September 4, 2009 12:07:51 PM EDT
>> To: gcc@gcc.gnu.org
>> Subject: Re: make bootstrap and make not working for gcc-4.4.1
>>
>>
>> On Sep 4, 2009, at 10:42 AM, Paolo Carlini wrote
On Thu, 3 Sep 2009, Richard Guenther wrote:
> As we've got quite some build problems on some targets and we clashed
> with VTA, free-lang-data, expand and scheduler changes it's a good
> time to slush the trunk for a short time.
>
> Thus, starting from now the t
On Fri, Sep 11, 2009 at 4:11 PM, Bingfeng Mei wrote:
> Hello,
> I notice the restrict qualifier doesn't work properly in trunk any more.
> In the following example, the memory accesses of a, b, c don't have different
> alias set attached any more. Instead, the generic alias set of 2 is used
> for
On Mon, Sep 14, 2009 at 3:52 AM, John David Anglin
wrote:
> Hi Martin,
>
>> Having said that, if anybody has problems with this patch going in,
>> please speak out now rather than later.
>
> I very much appreciate the work you have done on this problem. However,
> the patch doesn't work as expect
On Mon, Sep 14, 2009 at 3:18 AM, Gary Funck wrote:
>
> Recently, we have been working on upgrading GCC/UPC (see
> http://gccupc.org) to the GCC trunk. Previously,
> we've sync'ed with the latest stable release, but
> now we want to stay more current.
>
> When built with GCC versions 4.0 through 4
On Wed, Sep 16, 2009 at 12:39 AM, Oliver Kellogg
wrote:
> Hi,
>
> Looking at ggc-page.c:175ff.,
>
> static const size_t extra_order_size_table[] = {
> sizeof (struct var_ann_d),
> sizeof (struct tree_decl_non_common),
> sizeof (struct tree_field_decl),
> sizeof (struct tree_parm_decl),
> size
On Fri, 18 Sep 2009, Jack Howarth wrote:
> Richard,
>We have an analysis on the cause of the breakage of
> exception handling at r147995 on x86_64-apple-darwin10 (PR41260)...
>
> http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025908.html
> http://lists.cs.uiuc.edu/pipermail/llvmdev
cc/2009-08/msg00427.html
The next report will be sent by me announcing Stage 3 begin.
--
Richard Guenther
Novell / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex
On Sun, 20 Sep 2009, Steven Bosscher wrote:
> On Sat, Sep 19, 2009 at 10:57 PM, Richard Guenther wrote:
> > Since the last status report we have merged the VTA branch and pieces
> > of the LTO branch. The named address-spaces changes are still pending
> > review but I e
On Sun, 20 Sep 2009, Dave Korn wrote:
> Richard Guenther wrote:
>
> > The trunk is in Stage 1. Stage 1 will end on Sep 30th. After Stage 1
> > Stage 3 follows with only bugfixes and no new features allowed.
> > Stage 3 will end Nov 30th.
I'll answer your and Ja
On Sun, Sep 20, 2009 at 9:38 AM, Maxim Kuvyrkov wrote:
> I'm investigating an ICE on m68k architecture. I'm not quite sure what is
> the right way to fix the bug so I welcome any feedback on the below
> analysis.
>
> Compilation fails on the assert in dwarf2out.c:based_loc_descr():
>
> /* We on
On Sun, Sep 20, 2009 at 1:18 PM, Maxim Kuvyrkov wrote:
> Richard Guenther wrote:
>>
>> On Sun, Sep 20, 2009 at 9:38 AM, Maxim Kuvyrkov
>> wrote:
>
> ...
>>>
>>> This code uses eliminate_regs(), which implicitly assumes
>>> reload_comple
On Sun, 20 Sep 2009, Dave Korn wrote:
> Richard Guenther wrote:
>
> > Note that Stage 3 isn't that strict as it may sound. Maintainers have
> > quite amount of flexibility deciding what is considered a bug and thus
> > a bugfix during Stage 3 (note that Stage3
As commented to my last status report develop.html does not reflect
reality anymore. The following tries to adjust it carefully in
this respect.
Ok for www?
Thanks,
Richard.
2009-09-20 Richard Guenther
* develop.html: Adjust to reflect recent practice.
Index: develop.html
On Sun, Sep 20, 2009 at 6:10 PM, Andreas Schwab wrote:
> Why is postreload converting (set (REGX) (CONST_INT A)) ... (set (REGX)
> (CONST_INT B)) into (set (STRICT_LOW_PART (REGX)) (CONST_INT B))? That
> looks like a pessimisation especially if the constants are small, since
> STRICT_LOW_PART mus
On Sun, 20 Sep 2009, Theodore Papadopoulo wrote:
> Richard Guenther wrote:
> > As commented to my last status report develop.html does not reflect
> > reality anymore. The following tries to adjust it carefully in
> > this respect.
> >
> > Schedule
> >
On Tue, Sep 22, 2009 at 1:52 PM, Rahul Kharche wrote:
> The following causes missed loop optimizations in O2 from creating
> unnecessary loop induction variables. Or, is a case of IV opts not
> able to coalesce copies of induction variables. A previous post related
> to this was made in PR41026 wh
On Wed, Sep 23, 2009 at 2:38 AM, Janis Johnson wrote:
> I've been implementing ISO/IEC TR 24733, "an extension for the
> programming language C++ to support decimal floating-point arithmetic",
> in GCC. It might be ready as an experimental feature for 4.5, but I
> would particularly like to get i
On Thu, Sep 24, 2009 at 8:25 AM, Paolo Bonzini wrote:
> On 09/24/2009 08:24 AM, Ian Lance Taylor wrote:
>>
>> We already have the hooks, they have just been stuck in plugin.c when
>> they should really be in the generic backend. See register_pass.
>>
>> (Sigh, every time I looked at this I said "
Present: Jakub Jelinek, Jan Hubicka, Martin Jambor, Michael Matz,
Paolo Bonzini, Petr Baudis, Richard Guenther
Not present but invited: Andreas Schwab, Zdenek Dvorak
The objective of this meeting was to have a discussion about the
development of GCC (and dependent tools and libraries
While looking at PR38747 again I was diving into the alias.c code
and tried to confirm that it does what I think it does for
VIEW_CONVERT_EXPR. And in fact it basically does.
In general there are odds between what get_alias_set does if you
pass it a reference tree compared to what it does if yo
On Thu, 24 Sep 2009, Jason Merrill wrote:
> On 09/20/2009 08:07 AM, Dave Korn wrote:
> > Richard Guenther wrote:
> > > On Sun, 20 Sep 2009, Dave Korn wrote:
> >
> > > >BTW, why don't we call this more-flexible-stage-3 "stage 2" any more?
On Thu, 24 Sep 2009, Joseph S. Myers wrote:
> On Thu, 24 Sep 2009, Richard Guenther wrote:
>
> > We discussed about features we don't like (PCH and -combine). PCH
> > is used but has the issue that improper use is not diagnosed and PCH
> > seems to be unmaintain
On Fri, Sep 25, 2009 at 9:14 PM, Gabriel Dos Reis wrote:
> On Fri, Sep 25, 2009 at 1:42 PM, Jason Merrill wrote:
>>
>>> other than having been merged into trunk (for example, it may have been
>>> replaced by another branch without all changes being merged into trunk).
>>
>> My inclination would b
On Sat, 26 Sep 2009, Eric Botcazou wrote:
> > With VIEW_CONVERT_EXPR you can also easily create the situation
> > where for a reference tree, let it be VIEW_CONVERT_EXPR (X.a).b
> > like commonly seen in Ada, the alias-set of the outermost component
> > is not a subset of that of the innermost on
On Sun, 27 Sep 2009, Gerald Pfeifer wrote:
> On Sun, 20 Sep 2009, Richard Guenther wrote:
> > As commented to my last status report develop.html does not reflect
> > reality anymore. The following tries to adjust it carefully in
> > this respect.
>
> I believe you got
On Mon, Sep 28, 2009 at 5:58 PM, Diego Novillo wrote:
> In preparation for the final merge into mainline. I need to test
> the branch on various platforms. Richi is currently testing on
> i586, ppc, ppc64, ia64, s390, s390x.
I have bootstrapped and tested i586, x86_64, ppc, ppc64, ia64,
s390 (o
On Tue, Sep 29, 2009 at 11:06 AM, Richard Guenther
wrote:
> On Mon, Sep 28, 2009 at 5:58 PM, Diego Novillo wrote:
>> In preparation for the final merge into mainline. I need to test
>> the branch on various platforms. Richi is currently testing on
>> i586, ppc, ppc64, ia6
On Tue, Sep 29, 2009 at 11:43 AM, Richard Guenther
wrote:
> On Tue, Sep 29, 2009 at 11:06 AM, Richard Guenther
> wrote:
>> On Mon, Sep 28, 2009 at 5:58 PM, Diego Novillo wrote:
>>> In preparation for the final merge into mainline. I need to test
>>> the branch o
On Tue, Sep 29, 2009 at 2:22 PM, Joseph S. Myers
wrote:
> On Tue, 29 Sep 2009, Richard Guenther wrote:
>
>> The summary is as follows, extra errors compared to a run
>> without the merge patch applied:
>>
>> i586:
>>
>> FAIL: gcc.dg/attr-warn-unused-
On Mon, Sep 28, 2009 at 5:58 PM, Diego Novillo wrote:
> In preparation for the final merge into mainline. I need to test
> the branch on various platforms. Richi is currently testing on
> i586, ppc, ppc64, ia64, s390, s390x.
I have successfully bootstrapped on
{i586,x86_64,ppc,ppc64,ia64,s390,s
On Tue, Sep 29, 2009 at 2:39 PM, Richard Guenther
wrote:
> On Tue, Sep 29, 2009 at 2:22 PM, Joseph S. Myers
> wrote:
>> On Tue, 29 Sep 2009, Richard Guenther wrote:
>>
>>> The summary is as follows, extra errors compared to a run
>>> without the merge patch
On Wed, 30 Sep 2009, Gerald Pfeifer wrote:
> On Tue, 29 Sep 2009, Dave Korn wrote:
> > We have ~48 hours left for stage 1 and I can't be confident of getting
> > it reviewed in the remaining time, so I'd like to make a special
> > request: can you, as RM, please say that this is OK in principle
On Tue, Sep 29, 2009 at 8:23 PM, David Edelsohn wrote:
> On Thu, Aug 20, 2009 at 4:48 AM, Richard Guenther
> wrote:
>
>> Can't we use graphite to re-roll loops? That is, compress the
>> polyhedron by introducing a new parameter? But maybe I am
>> not good at
On Wed, Sep 30, 2009 at 2:35 PM, Joseph S. Myers
wrote:
> On Wed, 30 Sep 2009, Richard Guenther wrote:
>
>> New failures for head-i586
>
>> FAIL: 26_numerics/headers/cmath/fabs_inline.cc (test for excess errors)
>
> This is a failure of a non-LTO test, so a regression.
On Wed, Sep 30, 2009 at 7:36 PM, Rainer Orth
wrote:
> Diego Novillo writes:
>
>> In preparation for the final merge into mainline. I need to test
>> the branch on various platforms. Richi is currently testing on
>> i586, ppc, ppc64, ia64, s390, s390x.
>>
>> If anyone has free cycles I would app
19 - 3
P2 108 - 3
P37 + 1
--- ---
Total 134 - 5
Previous Report
===
http://gcc.gnu.org/ml/gcc/2009-09/msg00357.html
The next report will be sent by Jakub.
--
Richard Guenther
Novell
On Wed, 30 Sep 2009, Gabriel Dos Reis wrote:
> On Wed, Sep 30, 2009 at 6:23 PM, Richard Guenther wrote:
> >
> > Status
> > ==
> >
> > The trunk is in Stage 3.
>
> some of us are living in a timezone where it is still September 30, 2009. :-/
Sorry ;)
On Thu, Oct 1, 2009 at 2:47 AM, Dave Korn
wrote:
>
> Hi everyone,
>
> I'm using g++.old-deja/g++.brendan/new3.C as a testcase to investigate a
> problem with dllimport at the moment, and noticed something a bit unusual:
>
> Here is the CIE data from new3.C as compiled with gcc-4.3.4
>
>>
On Thu, 1 Oct 2009, Diego Novillo wrote:
> There should not be any more functional changes to the LTO merge
> needed for the final merge into mainline. I am waiting for the final
> round of testing and finishing up documentation changes requested by
> Joseph.
>
> I expect this to be done by tomo
On Thu, 1 Oct 2009, Joe Buck wrote:
> On Thu, Oct 01, 2009 at 05:00:10PM -0700, Andi Kleen wrote:
> > Richard Guenther writes:
> > >
> > > The wish for more granular and thus smaller debug information (things like
> > > -gfunction-arguments which would prop
On Fri, 2 Oct 2009, Diego Novillo wrote:
>
> I have committed today's round of feedback to the branch. It incorporates
> richi's fixes for C++ and enables LTO testing on builtins.exp (which is
> interesting for LTO as it includes multiple files)
>
> I am still not sure whether I will do the fin
On Fri, 2 Oct 2009, Diego Novillo wrote:
> On Fri, Oct 2, 2009 at 18:16, Richard Guenther wrote:
>
> > Done. If all goes well I think we should merge - waiting even more
> > doesn't really add to the quality and it just takes extra ressources
> > to work on the br
On Sat, Oct 3, 2009 at 12:43 PM, Pranav Bhandarkar
wrote:
> Hi,
>
> Is it possible for a component_ref node to have its arg 0 to be NULL ?
> I would think not because from tree.def I gather that arg 0 tells me
> what structures field this component_ref refers to. For convenience, I
> have pasted h
On Sat, Oct 3, 2009 at 4:34 PM, Diego Novillo wrote:
> On Sat, Oct 3, 2009 at 10:30, Toon Moene wrote:
>
>> So tomorrow I plan to svn up my gcc trunk, recompile it for C and Fortran,
>> recompile our Weather Forecasting system with it, and see what happens (the
>> compile of the Weather code does
On Sat, Oct 3, 2009 at 11:12 PM, Diego Novillo wrote:
> The LTO branch has been merged into trunk at revision 152434.
...
> To enable LTO, simply add the flag '-flto' to both compile and
> link commands. It doesn't really matter whether you compile and
> link in separate invocations or a single o
On Sat, Oct 3, 2009 at 11:12 PM, Diego Novillo wrote:
> The LTO branch has been merged into trunk at revision 152434.
Btw, I think this deserves a news entry on the main page as well as (obviously)
an entry for gcc-4.5/changes.html.
Richard.
On Sun, Oct 4, 2009 at 3:45 AM, Ryan Hill wrote:
> On Sat, 3 Oct 2009 17:12:17 -0400
> Diego Novillo wrote:
>
>> Instructions on how to enable LTO support are described in the
>> manual. The following is a summary:
>>
>> - Install libelf 0.8.12+ (http://www.mr511.de/software/libelf-0.8.12.tar.gz
ppreciate some pointers about where I should look, If I want
> to fix this ?
Look at
2009-07-14 Richard Guenther
Andrey Belevantsev
* tree-ssa-alias.h (refs_may_alias_p_1): Declare.
(pt_solution_set): Likewise.
* tree-ssa-alias.c (refs_may_alias_p_1):
On Wed, Oct 7, 2009 at 8:53 AM, Charles J. Tabony
wrote:
> Fellow GCC developers,
>
> Does GCC make any effort to collapse control-flow that is guaranteed to
> have undefined behavior? Such an optimization would improve performance
> of Proc_2 from Dhrystone:
>
>
> typedef int One_Fifty;
> t
On Wed, Oct 7, 2009 at 12:24 PM, Paolo Carlini wrote:
> Hi,
>
> today I'm seeing an ABI check failure in mainline, x86_64-linux, 11
> incompatible symbols: my preliminary analysis shows that the problem is
> the recurring one, simple, but annoying: some small functions are not
> inlined anymore, t
On Wed, Oct 7, 2009 at 2:33 PM, Jan Hubicka wrote:
>> Anyway, as regards *which* specific functions are not inlined, I would
>> say all the functions which break the ABI test as newly exported symbols
>> should be checked, like the above, 'std::ios_base::getloc() const'. I'm
>> attaching below a c
On Wed, 7 Oct 2009, David Edelsohn wrote:
> I am pleased to announce that the GCC Steering Committee has
> appointed Diego Novillo, Rafael Avila de Espindola, and Richard Guenther
> as LTO Reviewers, and Rafael Avila de Espindola and Cary Coutant as
> LTO Plugin Reviewers.
>
On Wed, Oct 7, 2009 at 4:25 PM, Vladimir Makarov wrote:
> Jan Hubicka wrote:
>>
>> So things seems to work now plus minus as expected. I.e. LTO builds
>> seems similar to combined builds and whole-programs improves code size
>> quite noticeably.
>> Runtime results for gzip are pretty much unchang
On Wed, Oct 7, 2009 at 4:37 PM, Tobias Grosser
wrote:
> I try to analyse this code:
> --
> int foo (int N)
> {
> int ftab[257];
> int i, j;
>
> for (i = 0; i < N - 7488645; i++)
> j = ftab [i];
>
> return j;
> }
>
On Wed, Oct 7, 2009 at 5:16 PM, Tobias Grosser
wrote:
> On Wed, 2009-10-07 at 16:42 +0200, Richard Guenther wrote:
>> On Wed, Oct 7, 2009 at 4:37 PM, Tobias Grosser
>> wrote:
>> > I try to analyse this code:
>> > -
On Wed, Oct 7, 2009 at 5:35 PM, Tobias Grosser
wrote:
> On Wed, 2009-10-07 at 17:23 +0200, Richard Guenther wrote:
>> On Wed, Oct 7, 2009 at 5:16 PM, Tobias Grosser
>> wrote:
>> > On Wed, 2009-10-07 at 16:42 +0200, Richard Guenther wrote:
>> >> On Wed, Oc
On Wed, Oct 7, 2009 at 7:21 PM, Tobias Grosser
wrote:
> On Wed, 2009-10-07 at 18:30 +0200, Tobias Grosser wrote:
>> On Wed, 2009-10-07 at 17:44 +0200, Richard Guenther wrote:
>> > On Wed, Oct 7, 2009 at 5:35 PM, Tobias Grosser
>> > wrote:
>> > > On
On Sat, Oct 10, 2009 at 12:55 PM, Toon Moene wrote:
> Gcc's man page says:
>
> -finline-functions-called-once
> Consider all "static" functions called once for inlining into
> their caller even if they are not marked "inline". If a call
> to a given function is
On Sat, Oct 10, 2009 at 1:34 PM, Toon Moene wrote:
> Richard Guenther wrote:
>
>> On Sat, Oct 10, 2009 at 12:55 PM, Toon Moene wrote:
>
>> Well, I think that we should try to not do this across the whole program.
>> Simply for the reason that a gigantic main funct
On Sat, Oct 10, 2009 at 1:46 PM, Richard Guenther
wrote:
> On Sat, Oct 10, 2009 at 1:34 PM, Toon Moene wrote:
>> Richard Guenther wrote:
>>
>>> On Sat, Oct 10, 2009 at 12:55 PM, Toon Moene wrote:
>>
>>> Well, I think that we should try to not do this acros
On Sat, Oct 10, 2009 at 3:40 PM, Toon Moene wrote:
> Toon Moene wrote:
>
>> Richard Guenther wrote:
>
>>> Or rather for testing the effect of inlining all functions called once
>>> use the following
>&
On Sat, Oct 10, 2009 at 6:24 PM, Jeff Law wrote:
> On 10/10/09 09:17, Daniel Jacobowitz wrote:
>>
>> On Sat, Oct 10, 2009 at 02:31:25PM +0200, Jan Hubicka wrote:
>>
>>>
>>> My solution would be probably to pass -fdump-ipa-inline parameter to lto
>>> compilation and read the log. It lists the inli
On Sun, Oct 11, 2009 at 6:04 PM, Rainer Emrich
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> libtool: link: gcc -shared .libs/lto-plugin.o
> -
> -L/SCRATCH/tmp.dYgZv17836/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/install/lib64
is there a libiberty in that path?
> - -lelf
> -
>
On Sun, Oct 11, 2009 at 6:21 PM, Richard Guenther
wrote:
> On Sun, Oct 11, 2009 at 6:04 PM, Rainer Emrich
> wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> libtool: link: gcc -shared .libs/lto-plugin.o
>> -
>> -L/SCRATCH/tmp
On Mon, Oct 12, 2009 at 10:53 AM, Rainer Emrich
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Richard Guenther schrieb:
>> On Sun, Oct 11, 2009 at 6:21 PM, Richard Guenther
>> wrote:
>>> On Sun, Oct 11, 2009 at 6:04 PM, Rainer Emrich
>>>
On Mon, Oct 12, 2009 at 4:31 PM, Bingfeng Mei wrote:
> Hello,
> I ran into an issue with the LTO merges when updating to current trunk.
> The problem is that my target calls a few functions/uses some data structures
> in the gcc directory: c_language, paragma_lex, c_register_pragma, etc.
>
> gcc -
On Tue, Oct 13, 2009 at 2:47 PM, Bingfeng Mei wrote:
> Hello,
> I just had the first taste with the latest LTO merge on our port.
> Compiler is configured with LTO enabled and built correctly.
> I tried the following example:
>
> a.c
> extern void foo(int);
> int main()
> { foo(20);
> return 1;
On Tue, Oct 13, 2009 at 5:18 PM, Bingfeng Mei wrote:
>
>
>> -Original Message-----
>> From: Richard Guenther [mailto:richard.guent...@gmail.com]
>> Sent: 13 October 2009 16:15
>> To: Bingfeng Mei
>> Cc: gcc@gcc.gnu.org
>> Subject: Re: LTO ques
On Tue, Oct 13, 2009 at 8:31 PM, Toon Moene wrote:
> Jeff Law wrote:
>
>> On 10/10/09 09:17, Daniel Jacobowitz wrote:
>
>>> On Sat, Oct 10, 2009 at 02:31:25PM +0200, Jan Hubicka wrote:
>>>
My solution would be probably to pass -fdump-ipa-inline parameter to lto
compilation and read
On Sat, Oct 17, 2009 at 12:44 AM, Justin Seyster wrote:
> I'm currently porting a plug-in that used to target the 4.3.0-based
> plug-in branch to the new top-of-tree plug-in system. I'm really
> stymied by a bug whose source I just cannot track down! Usually that
> means there is an error in my
On Sat, Oct 17, 2009 at 3:47 PM, Andrew Hutchinson
wrote:
> I have been adding rotate capability to AVR port and have come across what I
> think is bug in
> optabs.c: expand_binop()
>
> This occurs during a rotate expansion. For example
>
> target = op0 rotated by op1
>
> In the particular situa
We're waisting 8 bytes for every gimple_seq_node_d on x86_64 just
because we might be allocating a structure with a long double
element (16 byte aligned). I grepped and didn't find traces of
such a use, so - can we just document that callers need to
round up allocation sizes to multiples of the r
On Sun, 18 Oct 2009, Richard Guenther wrote:
>
> We're waisting 8 bytes for every gimple_seq_node_d on x86_64 just
> because we might be allocating a structure with a long double
> element (16 byte aligned). I grepped and didn't find traces of
> such a use, so -
On Mon, Oct 19, 2009 at 3:19 AM, Joel Sherrill
wrote:
> Hi,
>
> I got a random unsolicited email about arc-elf since
> I pop up in google a lot asking cross compiler questions.
> I decided to try to build it and as PR41747 indicates
> 4.3.4, 4.4.1, and the head all fail building libgcc2.c
> in the
On Tue, Oct 20, 2009 at 1:34 AM, Justin Seyster wrote:
> Thanks a lot for the help! It looks like creating a temporary
> took care of it.
>
> On Sat, Oct 17, 2009 at 7:41 AM, Richard Guenther
> wrote:
>> I think the call you insert is not of valid gimple form - an addre
On Tue, Oct 20, 2009 at 1:54 AM, tbp wrote:
> On Mon, Oct 19, 2009 at 7:34 PM, Ian Lance Taylor wrote:
>> Please file a bug report.
>> __attribute__((optimize())) is definitely only half-baked.
> Apparently the code i've posted is just a variation around that 1 year
> old PR 37565 and if that doe
On Thu, Oct 22, 2009 at 8:31 AM, Pranav Bhandarkar
wrote:
> Hi,
>
> A possible silly question about the dead store elimination pass. From
> the documentation it is clear that the store S1 below is removed by
> this pass (in dse.c)
>
> *(addr) = value1; // S1
> .
> .
> *(addr) = va
On Fri, 23 Oct 2009, Eric Botcazou wrote:
> Hi Richard,
>
> I just (re-)discovered that the new TBAA machinery is quite aggressive and
> breaks cases that used to work in Ada (-O2 testcase for SPARC64 attached).
>
> The problem boils down to this:
>
> D.1416_1 = (struct p__rec &) &r.F;
> r
On Fri, 23 Oct 2009, Eric Botcazou wrote:
> > I didn't find (or could construct) a single C or C++ testcase that
> > wasn't fine with the new default, so I switched it (IIRC the default
> > is disambiguating the most cases).
>
> Yes, the default is the optimistic answer and a few tests rely on it
On Sat, Oct 24, 2009 at 1:01 AM, Dave Korn
wrote:
>
> Hi everyone,
>
> Sorry for posting a dumb question, but it's not my strongest area: now that
> cygwin is handling i18n and unicode and "all that stuff", I started seeing a
> whole slew of test failures, e.g.:
>
>> FAIL: g++.dg/debug/pr22514
On Sun, Oct 25, 2009 at 12:08 PM, Steven Bosscher wrote:
> Hi,
>
> I tried to bootstrap gcc this morning and got the following build failure:
>
> /home/stevenb/devel/build/./prev-gcc/xgcc
> -B/home/stevenb/devel/build/./prev-gcc/
> -B/opt/x86_64-unknown-linux-gnu/bin/
> -B/opt/x86_64-unknown-linux
On Sun, Oct 25, 2009 at 12:24 PM, Steven Bosscher wrote:
> On Sun, Oct 25, 2009 at 12:18 PM, Richard Guenther
> wrote:
>> On Sun, Oct 25, 2009 at 12:08 PM, Steven Bosscher
>> wrote:
>>> Hi,
>>>
>>> I tried to bootstrap gcc this morning and got the f
On Sun, Oct 25, 2009 at 7:42 PM, Toon Moene wrote:
> Toon Moene wrote:
>>
>> As follows:
>>
>> g++ -DHAVE_CONFIG_H -I. -I../../gcc/gold -I../../gcc/gold
>> -I../../gcc/gold/../include -I../../gcc/gold/../elfcpp
>> -DLOCALEDIR="\"/usr/snp/share/locale\"" -DBINDIR="\"/usr/snp/bin\""
>> -DTOOLBINDIR
On Mon, Oct 26, 2009 at 2:59 PM, Ian Lance Taylor wrote:
> Basile STARYNKEVITCH writes:
>
>> Are you suggesting me to upload to bugzilla the nearly 3000
>> preprocessed forms of the files? I could do that, but the *.i files
>> totalize more than one gigabyte. A bzip2 compressed tar archive of
>>
On Mon, Oct 26, 2009 at 3:39 PM, Basile STARYNKEVITCH
wrote:
> Richard Guenther wrote:
>>
>> On Mon, Oct 26, 2009 at 2:59 PM, Ian Lance Taylor wrote:
>>>
>>> Basile STARYNKEVITCH writes:
>>>
>>>> Are you suggesting me to upload to bugzilla t
On Mon, Oct 26, 2009 at 4:39 PM, Aldy Hernandez wrote:
> Hi folks.
>
> In this PR the problem is that a call to fold_build2_loc() returns one
> of the original arguments unchanged. In the code below we take this
> result and change its location before returning it.
>
> tem = fold_build2_loc
On Mon, Oct 26, 2009 at 5:37 PM, Aldy Hernandez wrote:
>> > ? ? ?tem = fold_build2_loc (loc, code, type,
>> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? fold_convert_loc (loc, TREE_TYPE (op0),
>> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? TREE_OPERAND (arg0, 1)),
>> > op1);
>> > ? ? ?protected_set_expr_loc
On Mon, Oct 26, 2009 at 6:28 PM, Aldy Hernandez wrote:
>> That wasn't my question.
>>
>> tem = fold_build2_loc (loc, code, type,
>> fold_convert_loc (loc, TREE_TYPE (op0),
>> TREE_OPERAND (arg0, 1)), op1);
>> prote
On Mon, Oct 26, 2009 at 10:42 PM, Aldy Hernandez wrote:
>> Certainly better. But I fail to see why a different location would be
>> better than the original here. I assume all tokens have a correct initial
>> location. Then why is for example for int i; in (int) i the location of
>> the conver
On Tue, Oct 27, 2009 at 1:15 PM, Basile STARYNKEVITCH
wrote:
> Hello All,
>
> I feel that the current plugin hooks, that is the set of plugin events
> enumerated in the enum plugin_event of gcc/gcc-plugin.h and the associated
> API in gcc/plugin.h (e.g. register_attribute) is perhaps still incompl
On Tue, Oct 27, 2009 at 4:06 PM, Basile STARYNKEVITCH
wrote:
> Ian Lance Taylor wrote:
>>
>> Basile STARYNKEVITCH writes:
>>
>>> * propose a simple patch to add the PLUGIN_REGISTER_PRAGMA event now?
>>
>> Do this.
>
> Will do probably tommorow or this evening!
>>
>> On the other hand, skimming yo
On Tue, Oct 27, 2009 at 4:48 PM, Basile STARYNKEVITCH
wrote:
> Richard Guenther wrote:
>>
>> The fix is not to add a hook to replace the pass manager but instead
>> to make the GCC pass manager more flexible itself.
>
> I leave that task to my ICI friends (i
On Wed, Oct 28, 2009 at 6:34 PM, Basile STARYNKEVITCH
wrote:
> Hello All,
>
> Is there some way from a plugin to read and to write some plugin specific
> LTO data?
>
> When glancing in lto-streamer.h I believe I see no such things. But I don't
> understand all the details.
>
> I was thinking of e.
On Wed, Oct 28, 2009 at 8:34 PM, Basile STARYNKEVITCH
wrote:
> Hello All
>
> Rafael Espindola wrote:
>>>
>>> I have a concrete example here: plugin-specific pragmas (see
>>> PLUGIN_REGISTER_PRAGMA on http://gcc.gnu.org/wiki/plugin%20hook for
>>> details)
>>>
>>> I have two imaginary use cases here
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't understand why lto1 said this:
>
> /usr/snp/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../x86_64-unknown-linux
> -gnu/bin/ld: fatal error: could
701 - 800 of 2444 matches
Mail list logo
