On 9/10/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Richard Guenther wrote:
>
> >> What is an example program in that meets the requirements I gave above
> >> -- i.e., allows the compiler to prove that two same-typed pointers do
> >> not alias (whether by the compiler's cleverness, use of "restr
GCC 4.2.2 RC1 is now available from:
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2.2-RC-20070909
If you want to help test this release candidate, please download files
from the directory given above, rather than checking out from SVN, so
that we can catch any packaging problems. If you find
> Jan Hubicka wrote:
>
> > I am still planning to do some retuning of inliner (our inline limits
> > wasn't revisited for inclusion of SSA optimizers).
>
> Assuming that the tuning is essentially twiddling constants, I'm not
> overly worried. If you're planning to adjust the algorithms
> substan
> I succeed past this failure if I revert Zdenek's iv-opts patch
(r128272).
Same here. The failure also occurs on all hppa targets.
Dave
--
J. David Anglin [EMAIL PROTECTED]
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Richard Guenther wrote:
>> What is an example program in that meets the requirements I gave above
>> -- i.e., allows the compiler to prove that two same-typed pointers do
>> not alias (whether by the compiler's cleverness, use of "restrict", or
>> whatever), but where the compiler must still assum
I succeed past this failure if I revert Zdenek's iv-opts patch
(r128272).
David
On Sun, 9 Sep 2007, Jan Hubicka wrote:
>> [bootstrap/33352] invalid rtl sharing -- bootstrap failure compiling
>> libgomp/team.c on i386
> I can definitly take alook on it, however i386-linux bootstrap fine for
> me. Can I have testcase?
After a couple of days of failure (at least four nightly
On 9/9/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Richard Guenther wrote:
> > On 9/9/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> >> But, I don't think that even the C meaning is safe in C++ for use with
> >> the library declaration of . I'm also somewhat skeptical of the
> >> idea that we w
Richard Guenther wrote:
> On 9/9/07, Roger Sayle <[EMAIL PROTECTED]> wrote:
>>> This is an optimization pass which leads to dramatically better code on
>>> at least one SPEC benchmark. Ian, Roger, Diego, would one of you care
>>> to review this?
>
> Btw, diego already approved the patch.
I apolo
"Richard Guenther" <[EMAIL PROTECTED]> writes:
[...]
| I don't know of any place we would use such information. At least
|
| int *p = new int;
| int *q = new int;
| if (p == q)
|
| cannot be simplified as both pointers may be NULL?
The above does not use the no-throw operator new, so n
"Richard Guenther" <[EMAIL PROTECTED]> writes:
[...]
| > It's worse than that:
| >
| > char *pool;
| > void set_pool(char *p) { pool = p; }
| > void *operator new(size_t s) { // return stuff from pool. }
| >
| > bool f() {
| > char *p = new char[1024];
| > set_pool (p);
| >
Mark Mitchell <[EMAIL PROTECTED]> writes:
[...]
| This seems like a useful optimization to me, and I understand that it
| will work 99.99% of the time
Except for people writing allocators :-)
-- Gaby
On 9/9/07, Roger Sayle <[EMAIL PROTECTED]> wrote:
>
> > This is an optimization pass which leads to dramatically better code on
>
> > at least one SPEC benchmark. Ian, Roger, Diego, would one of you care
> > to review this?
Btw, diego already approved the patch.
> My concern is that as formulate
Richard Guenther wrote:
> On 9/9/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
>> But, I don't think that even the C meaning is safe in C++ for use with
>> the library declaration of . I'm also somewhat skeptical of the
>> idea that we will never do any optimization on pointer comparisons.
>> What
This is an optimization pass which leads to dramatically better code on
at least one SPEC benchmark. Ian, Roger, Diego, would one of you care
to review this?
My concern is that as formulated, conditional store elimination is not
always a win.
Transforming
if (cond)
*p = x;
int
Richard Guenther wrote:
> A better one:
>
> int *p = new int;
> foo(p);
> int *q = new int;
>
> if foo deletes p then q may be equal to p. But alias analysis still
> (validly!) says they don't alias.
Yes, I agree that this is safe. (Either "p" is still valid and
therefore different from
On 9/9/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
>
> But, I don't think that even the C meaning is safe in C++ for use with
> the library declaration of . I'm also somewhat skeptical of the
> idea that we will never do any optimization on pointer comparisons.
> What design principle in the comp
Richard Guenther wrote:
>> We should optimize away things like:
>>
>> int *p = new int;
>> if (!p)
>> cerr << "Could not allocate memory\n";
>
> We don't I believe.
That's a missed-optimization, and independent of any attributes on
"operator new". It's a property of the new *expression*
On 9/9/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
> On 9/9/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> > Richard Guenther wrote:
> >
> > > I don't know of any place we would use such information. At least
> > >
> > > int *p = new int;
> > > int *q = new int;
> > > if (p == q)
> > >
>
On 9/9/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Richard Guenther wrote:
>
> > I don't know of any place we would use such information. At least
> >
> > int *p = new int;
> > int *q = new int;
> > if (p == q)
> >
> > cannot be simplified as both pointers may be NULL?
>
> They cannot be
Richard Guenther wrote:
> I don't know of any place we would use such information. At least
>
> int *p = new int;
> int *q = new int;
> if (p == q)
>
> cannot be simplified as both pointers may be NULL?
They cannot be NULL; new-expressions throw an exception if the
allocation fails. (Of
On 9/9/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Richard Guenther wrote:
>
> >> char *pool;
> >> void set_pool(char *p) { pool = p; }
> >> void *operator new(size_t s) { // return stuff from pool. }
> >>
> >> bool f() {
> >> char *p = new char[1024];
> >> set_pool (p);
> >>
Vladimir,
On Fri, 15 Jun 2007, Vladimir N. Makarov wrote:
> Sorry, it is even make me a bit scary becuase I don't know when the SC
> decides that we need more maintainers and what maintainers. When should
> we propose. After that I am just starting to think who usually propose
> them.
I know
Richard Guenther wrote:
>> char *pool;
>> void set_pool(char *p) { pool = p; }
>> void *operator new(size_t s) { // return stuff from pool. }
>>
>> bool f() {
>> char *p = new char[1024];
>> set_pool (p);
>> char *i = new char;
>> return (p == i);
>> }
>>
>> In other
On 9/9/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
>
> Which brings back the fact that you cannot implement malloc in C
> (you certainly remember the discussions about C++ placement new
> handling wrt aliasing). To re-use the machinery we invented there
> we would need to place a CHANGE_DYNAMI
On 9/9/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Joe Buck wrote:
>
> >> In the case of "malloc", and assuming that all of the machinery for
> >> malloc is hidden away in some piece of the program we're not talking
> >> about, all three definitions apply. Each pointer returned by malloc is
> >
Joe Buck wrote:
>> In the case of "malloc", and assuming that all of the machinery for
>> malloc is hidden away in some piece of the program we're not talking
>> about, all three definitions apply. Each pointer returned by malloc is
>> an island unto itself; there's no conforming way to get there
On 9/9/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Richard Guenther wrote:
>
> >> Probably the most common use of a custom new is to allocate memory from
> >> a user-controlled pool instead of the standard free store. Somewhere in
> >> the program there will be a pointer to the complete pool, wh
Jagasia, Harsha wrote:
> I still plan to submit a patch for the x86 target cost model tuning.
Assuming that this isn't too dramatic, I'll leave approval of that
during Stage 3 to the x86 back-end maintainers.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Jan Hubicka wrote:
> I am still planning to do some retuning of inliner (our inline limits
> wasn't revisited for inclusion of SSA optimizers).
Assuming that the tuning is essentially twiddling constants, I'm not
overly worried. If you're planning to adjust the algorithms
substantially, then I'd
Richard Guenther wrote:
> There is
>
> http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01978.html
>
> for example, which is not suitable for stage3.
This is an optimization pass which leads to dramatically better code on
at least one SPEC benchmark. Ian, Roger, Diego, would one of you care
to rev
On Sun, Sep 09, 2007 at 12:24:13PM -0700, Mark Mitchell wrote:
> The term "cannot alias" is not fully defined. It could mean "cannot
> have the same value as any other pointer of the same type". It could
> mean "cannot have the same value as any other pointer, when both
> pointers are cast to `vo
> Kaveh R GHAZI writes:
Kaveh> Program received signal SIGSEGV, Segmentation fault.
Kaveh> 0x002cf780 in reload_combine_note_store (dst=0xff0b90e0, set= optimized out>, data=0x0)
Kaveh> at ../../egcc-SVN20070909/gcc/postreload.c:1018
Kaveh> 1018 reg_state[i].store_ruid = reload_co
Richard Guenther wrote:
>> Probably the most common use of a custom new is to allocate memory from
>> a user-controlled pool instead of the standard free store. Somewhere in
>> the program there will be a pointer to the complete pool, which aliases
>> every pointer returned by that version of new.
On Mon, Sep 10, 2007 at 05:33:24AM +1200, Ross Smith wrote:
> > [...] If the request succeeds, the value returned shall be a nonnull
> > pointer value (4.10) p0 different from any previously returned value
> > p1, unless that value p1 was subsequently passed to an operator delete.
>
> That's no
On Sun, 9 Sep 2007, David Edelsohn wrote:
> Kaveh> The stage2 gcc cannot compile this simple program. The stage1
> Kaveh> compiler can, so looks like stage2 was miscompiled. Running it under
> Kaveh> gdb doesn't yield any useful info.
>
> I am seeing the same failure on AIX. The SEGV on A
> Kaveh R GHAZI writes:
Kaveh> Rats, I'm getting another bootstap failure on sparc-sun-solaris2.10.
Kaveh> This time it happens in stage2 building libgcc. What happens is that
Kaveh> when it runs configure for stage2 libgcc, I get:
Kaveh> checking for suffix of object files...
Kaveh> configu
Rats, I'm getting another bootstap failure on sparc-sun-solaris2.10.
This time it happens in stage2 building libgcc. What happens is that
when it runs configure for stage2 libgcc, I get:
checking for suffix of object files...
configure: error: cannot compute suffix of object files
Rask Ingemann Lambertsen wrote:
> On Tue, Sep 04, 2007 at 07:40:19PM -0700, Mark Mitchell wrote:
>> Are there Stage 1 or Stage 2 patches in need of review? I'll do my best
>> to either (a) convince someone to review them, or (b) review them myself.
>
> http://gcc.gnu.org/ml/gcc-patches/2007-08/ms
Martin Jambor wrote:
> Well, there's mine :-) Specifically, its the "Switch initializations
> conversion:" http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00215.html
Do you have an FSF copyright assignment on file? This patch is big
enough that we would not be able to include it without that.
> Ja
On 9/9/07, Ross Smith <[EMAIL PROTECTED]> wrote:
> Gabriel Dos Reis wrote:
> > Joe Buck <[EMAIL PROTECTED]> writes:
> >
> > | On Sat, Sep 08, 2007 at 04:33:50PM -0500, Gabriel Dos Reis wrote:
> > | > "Richard Guenther" <[EMAIL PROTECTED]> writes:
> > | >
> > | > | On 9/8/07, Chris Lattner <[EMAIL P
Gabriel Dos Reis wrote:
Joe Buck <[EMAIL PROTECTED]> writes:
| On Sat, Sep 08, 2007 at 04:33:50PM -0500, Gabriel Dos Reis wrote:
| > "Richard Guenther" <[EMAIL PROTECTED]> writes:
| >
| > | On 9/8/07, Chris Lattner <[EMAIL PROTECTED]> wrote:
| > | > I understand, but allowing users to override
Uros Bizjak wrote:
Hello!
I would like to bring a strange optimization problem to the attention of
RTL expert. The problem is outlined in PR rtl-optimization/33353, the
core of the problem is that passes that follow RTL fwprop1 pass simply
don't process REG_EQUAL notes that mark constant resu
Richard Guenther writes:
> On 9/9/07, Matthias Klose <[EMAIL PROTECTED]> wrote:
> > this is now PR 33368, only seen when building with BOOT_CFLAGS="-O2"
> > CFLAGS="-g -O2", an oversight on my side.
> >
> > Seems to be introduced by r128190.
>
> CFLAGS="-g -O2' pulls in all of the nasty dependence
On 9/9/07, Matthias Klose <[EMAIL PROTECTED]> wrote:
> this is now PR 33368, only seen when building with BOOT_CFLAGS="-O2"
> CFLAGS="-g -O2", an oversight on my side.
>
> Seems to be introduced by r128190.
CFLAGS="-g -O2' pulls in all of the nasty dependence on a working host
compiler. Which is?
this is now PR 33368, only seen when building with BOOT_CFLAGS="-O2"
CFLAGS="-g -O2", an oversight on my side.
Seems to be introduced by r128190.
Matthias
Matthias Klose writes:
> seen with r128264, was sucessful on 20070906
>
> Matthias
>
> make[5]: Leaving directory
> `/scratch/packages
On 08/09/2007, Joe Buck <[EMAIL PROTECTED]> wrote:
>
> It still seems odd, and this restriction could make the coding of
> templates more complex.
Agreed, but I'm not sure making reinterpret_cast convenient to use is
a noble aim :-)
It should be used a last resort, in the knowledge that the resul
On Tue, 4 Sep 2007, Dave Korn wrote:
> On 04 September 2007 10:05, me wrote:
>> The point of this is that __COUNTER__ would assign consecutive numbers
>
>> I can not find g++'s equivalent & wonder how I could achieve the same
>> thing?
> This feature was just added recently. It will be in all upco
> On Sat, 8 Sep 2007, Andrew Pinski wrote:
> > Rerun the command without the ">/dev/null 2>&1", libtool likes to say
> > that PIC mode will give the same output as non PIC mode (which is not
> > always true).
>
> Blind me. Obviously that redirection removed all traces of the real
> error. Ahem.
Hello!
I would like to bring a strange optimization problem to the attention of
RTL expert. The problem is outlined in PR rtl-optimization/33353, the
core of the problem is that passes that follow RTL fwprop1 pass simply
don't process REG_EQUAL notes that mark constant result.
For the testca
Hello,
I get the following error while bootstrapping on ppc64 -r128289:
cc/../include -I../../gcc/gcc/../libcpp/include
-I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd
-I../libdecnumber\
-DTARGET_NAME=\"powerpc64-unknown-linux-gnu\" \
-c ../../gcc/gcc/
51 matches
Mail list logo
