Thanks a lot for your input, I think I understand some of that code better now.
I stumbled upon a solution last night, on realizing that the problem
was with the DFmode powidf2 and seeing that I had not defined the
movsf or movdf insns (because I thought I shouldn't need them, having
no HW floatin
Richard Guenther wrote:
> Well, we have that now:
>
> int *q = new int;
> delete q;
> int *p = new int;
> delete p;
> if (q != p)
> cout << "different";
>
> we cannot optimize the test to be always true. The point is that alias
> analysis tells us something about accesses to *q an
Peter Bergner wrote:
> On Tue, 2007-09-04 at 19:40 -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.
>
> It has only been four days since I posted the patch, but I am
Alexandre Oliva wrote:
> I think it would be nice to offer this new debug info generation
> machinery, at least as an option, in GCC 4.3, so I'd like to request
> some more time to make it fully functional before I post the very
> large patches.
Thank you for letting me know.
> Making it optiona
Jakub Jelinek wrote:
> I have a bunch of tiny patches, nevertheless all Stage 2 material, as
> they add new features:
I'd like a middle-end maintainer to review this one:
> redundant zero store elimination optimization (simplistic version,
> but nevertheless is able to trigger many times during
On Mon, Sep 10, 2007 at 12:22:11PM +0200, Tomas Svensson wrote:
> static bool
> legitimate_offset_address_p (enum machine_mode mode ATTRIBUTE_UNUSED, rtx
> addr)
> {
> rtx reg, offset;
>
> if (GET_CODE (addr) != PLUS)
> return false;
>
> reg = XEXP (addr, 0);
> offset = XEXP (addr,
Snapshot gcc-4.1-20070910 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070910/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Tomas Svensson wrote:
It seems that gcc has emitted rtl describing a memory reference (mem
(plus (mem (plus (reg ..) (const_int ..))) (const_int ..))), which
should not have been permitted by GO_IF_LEGITIMATE_ADDRESS since it
only allows (mem (plus (reg ..) (const ..))), and forbids a second
leve
Hi,
thanks for looking at the patch.
On Sun, Sep 09, 2007 at 11:42:55AM -0700, Mark Mitchell wrote:
> 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 c
On Aug 9, 2007, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> We entered Stage 2 on July 6th. I plan to put us into Stage 3 on
> September 10th. At that point, we will accept only bug-fixes -- no
> more new features until Stage 1 for GCC 4.4.
I was hoping I'd have the new debug info infrastructur
On 9/10/07, Tom Tromey <[EMAIL PROTECTED]> wrote:
> > "Mark" == Mark Mitchell <[EMAIL PROTECTED]> writes:
>
> Mark> If the compiler treats:
> Mark> int *p = new int;
> Mark> any differently from:
> Mark> int &r = *new int;
> Mark> then we're missing an optimization opportunity.
>
> AFAIK we
On Tue, Sep 04, 2007 at 07:40:19PM -0700, Mark Mitchell wrote:
> Summary
> ===
>
> We are closing in on Stage 3, previously announced for September 10th.
> At this point, I'm not aware of any reason to delay that date. Are
> there any Stage 2 patches that people don't think will be submitted
On Tue, 2007-09-04 at 19:40 -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.
It has only been four days since I posted the patch, but I am
waiting for a review of the n
>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.
The patch involves some x86 back-end bits, which Honza has already
appro
> "Mark" == Mark Mitchell <[EMAIL PROTECTED]> writes:
Mark> If the compiler treats:
Mark> int *p = new int;
Mark> any differently from:
Mark> int &r = *new int;
Mark> then we're missing an optimization opportunity.
AFAIK we don't have a way to mark a function as "cannot return NULL".
This
On Tue, Sep 04, 2007 at 07:40:19PM -0700, Mark Mitchell wrote:
> We are closing in on Stage 3, previously announced for September 10th.
> At this point, I'm not aware of any reason to delay that date. Are
> there any Stage 2 patches that people don't think will be submitted by
> that point?
>
> A
Hi,
On Sun, Sep 09, 2007 at 12:56:25PM -0700, Mark Mitchell wrote:
> For a particular implementation of "operator new" (such as the one in
> libstdc++), you can of course make it safe in the same way as "malloc";
> hide the implementation somewhere the rest of the program can't see it
> (modulo LT
Hi!
Sorry for taking so long, but bootstarping really takes forever under
SGI (especially as I wasn't getting that much CPU time): I was able to
build '128233' sources (see hereafter).
Thanks a lot!
Philippe
PS: the output of check:
=== gcc Summary ===
# of expected passes
On 9/10/07, Rask Ingemann Lambertsen <[EMAIL PROTECTED]> wrote:
>It would help a lot if you post your GO_IF_LEGITIMATE_ADDRESS.
It's really very basic:
# define GO_IF_LEGITIMATE_ADDRESS(MODE, X, ADDR) \
{ if (legitimate_address_p (MODE, X, true)) goto ADDR; }
and in the .c-file:
bool
le
On Mon, Sep 10, 2007 at 09:54:57AM +0200, Tomas Svensson wrote:
>
> /cygdrive/c/home/risc/src/gcc-4.1.2/gcc/libgcc2.c: In function '__powidf2':
> /cygdrive/c/home/risc/src/gcc-4.1.2/gcc/libgcc2.c:1559: error: insn
> does not satisfy its constraints:
> (insn 114 153 117
> /cygdrive/c/home/risc/src/
On 10 September 2007 08:55, Tomas Svensson wrote:
> I am porting gcc to a new target architecture, and have come across a
> problem when the make process tries to compile libgcc. The error I get
> is included below.
>
> It seems that gcc has emitted rtl describing a memory reference (mem
> (plus
I am porting gcc to a new target architecture, and have come across a
problem when the make process tries to compile libgcc. The error I get
is included below.
It seems that gcc has emitted rtl describing a memory reference (mem
(plus (mem (plus (reg ..) (const_int ..))) (const_int ..))), which
sh
22 matches
Mail list logo
