Dominique Dhumieres wrote:
> In comment #7 of PR0, Richard Guenther asked the following question
> I cannot answer:
>
>> Btw, is it mandated by the fortran standard to pass a scalar as array
>> reference?
>
> Does anyone knows the answer? or should it be asked on comp.lang.fortran?
>
Here,
On 9/7/07, Tim Prince <[EMAIL PROTECTED]> wrote:
> Dominique Dhumieres wrote:
> > In comment #7 of PR0, Richard Guenther asked the following question
> > I cannot answer:
> >
> >> Btw, is it mandated by the fortran standard to pass a scalar as array
> >> reference?
> >
> > Does anyone knows the
Salut Dominique, moin Richard, hello all,
(Answering Richard's question from PR0.)
Dominique Dhumieres wrote:
>> Btw, is it mandated by the fortran standard to pass a scalar as array
>> reference?
>>
> Does anyone knows the answer? or should it be asked on comp.lang.fortran?
>
The sta
2007/9/7, Christian Joensson <[EMAIL PROTECTED]>:
> 2007/9/6, Kaveh R. GHAZI <[EMAIL PROTECTED]>:
> > (Sorry, first one bounced from gcc@ because it was over 400k)
> >
> > Hi Jan,
> >
> > On sparc-sun-solaris2.10, I'm getting new bootstrap failures in stage2
> > complaining several times about rtl
> Does anyone knows the answer? or should it be asked on comp.lang.fortran?
It's very specific to the problem at hand, so I doubt c.l.f could give
us much input on that. As I understand, in this case, it actually is
the right thing to do.
FX
In comment #7 of PR0, Richard Guenther asked the following question
I cannot answer:
> Btw, is it mandated by the fortran standard to pass a scalar as array
> reference?
Does anyone knows the answer? or should it be asked on comp.lang.fortran?
TIA
Dominique
At revision 128228, the patch enables me to go from stage1 to stage3, but
bootstrap
still fails with:
libtool: compile: /opt/gcc/darwin_buildw/gcc/gcj
-B/opt/gcc/darwin_buildw/powerpc-apple-darwin8/ppc64/libjava/
-B/opt/gcc/darwin_buildw/gcc/ -fclasspath=
-fbootclasspath=../../../../gcc-4.3-w
This is now PR0 handled by Richard Guenther.
Dominique
On Thu, 6 Sep 2007, Jan Hubicka wrote:
> Ah, I see.
> The attached patch seems to work on my testcase too.
>
> Honza
>
> Index: reorg.c
> ===
> --- reorg.c (revision 128145)
> +++ reorg.c (working copy)
> @@ -3863,17 +3863,6 @@ db
Hi,
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 submi
> At revision 128228, the patch enables me to go from stage1 to stage3, but
> bootstrap
> still fails with:
>
> libtool: compile: /opt/gcc/darwin_buildw/gcc/gcj
> -B/opt/gcc/darwin_buildw/powerpc-apple-darwin8/ppc64/libjava/
> -B/opt/gcc/darwin_buildw/gcc/ -fclasspath=
> -fbootclasspath=../..
>
>
> This second patch also allows bootstrap to complete on my sparc box.
Thanks for testing and good news,
I will commit the patch
Honza
>
> Thanks,
> --Kaveh
> --
> Kaveh R. Ghazi[EMAIL PROTECTED]
Hi
My builds on i386-pc-solaris2.10 have failed again once the SCCVN patch
was re-applied:
$ make bootstrap-lean ...
[ ... snip ... ]
make[2]: Entering directory `/export/home/arth/gnu/gcc-0907'
make[3]: Entering directory `/export/home/arth/gnu/gcc-0907'
rm -f stage_current
make[3]: Leaving dire
Hi,
when trying to analyse dynamically allocated objects in C++, I came
across the need to identify results of the new operator (at least the
non-overridden standard one) as malloc-allocated. The cleanest
approach would probably be to mark the new operator function with the
malloc att
Snapshot gcc-4.3-20070907 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20070907/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
On Fri, 7 Sep 2007, Martin Jambor wrote:
> Index: libstdc++-v3/libsupc++/new
> ===
> --- libstdc++-v3/libsupc++/new(revision 128207)
> +++ libstdc++-v3/libsupc++/new(working copy)
> @@ -92,7 +92,8 @@
> * Placement n
On Sep 7, 2007, at 1:53 PM, Martin Jambor wrote:
Hi,
when trying to analyse dynamically allocated objects in C++, I came
across the need to identify results of the new operator (at least the
non-overridden standard one) as malloc-allocated. The cleanest
approach would probably be t
On Sep 7, 2007, at 1:53 PM, Martin Jambor wrote:
> [ giving operator new the malloc property ]
On Fri, Sep 07, 2007 at 06:30:33PM -0700, Chris Lattner wrote:
> It is unclear whether this is safe. Nothing in the standard AFAIK
> requires the operator new be implemented in terms of malloc, and
Joe Buck <[EMAIL PROTECTED]> writes:
| On Sep 7, 2007, at 1:53 PM, Martin Jambor wrote:
| > [ giving operator new the malloc property ]
|
| On Fri, Sep 07, 2007 at 06:30:33PM -0700, Chris Lattner wrote:
| > It is unclear whether this is safe. Nothing in the standard AFAIK
| > requires the oper
19 matches
Mail list logo
