[Transfering this to the fortran list]
Hi Christian,
I did the commit that introduced these new symbols
_gfortran_{reshape,transpose}_r{4,8}. They come from
${srcdir}/libgfortran/generated/{reshape,transpose}_r{4,8}.c
and this file should be present indeed at revision 114896:
$ svn info libg
On 6/24/06, FX Coudert <[EMAIL PROTECTED]> wrote:
[Transfering this to the fortran list]
Hi Christian,
I did the commit that introduced these new symbols
_gfortran_{reshape,transpose}_r{4,8}. They come from
${srcdir}/libgfortran/generated/{reshape,transpose}_r{4,8}.c
and this file should be pre
well, I didn't do a full bootstrap, I did a "bubblestrap" ... maybe
that was the issue then. before running the next bubblestrap, what
files do you recommend me to remove so that they get stage wise
properly rebuilt?
Hum... I'm not sure, but I think the safe steps here are:
- check the origina
On 6/24/06, FX Coudert <[EMAIL PROTECTED]> wrote:
> well, I didn't do a full bootstrap, I did a "bubblestrap" ... maybe
> that was the issue then. before running the next bubblestrap, what
> files do you recommend me to remove so that they get stage wise
> properly rebuilt?
Hum... I'm not sure,
No negative responses, so I'll enter it in bugzilla.
Andrew Walrond
Mark Mitchell <[EMAIL PROTECTED]> writes:
[...]
| And, "extern template" is a GNU
| extension which says "there's an explicit instantiation elsewhere; you
| needn't bother implicitly instantiating here".
FWIW, "extern template" is now part of C++0x.
| I'm
Stupid, stupid.
While creating a minimal test case, my mistake becomes apparent, so
please disregard. In case you're wondering, adding 'explicit' to the
main Bifilter constructor stops the first parameter in
Bifilter _bif(new Filter(),Bifilter::DELETE_ON_DESTRUCTION);
being implicitly convert
div_comp_red_2.f90: In function 'MAIN__':
div_comp_red_2.f90:1: internal compiler error: Bus error
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
I reported this bug as PR 28151. It's not target-specific (it happens
On 6/24/06, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
On Fri, 2006-06-23 at 15:07 -0700, Ian Lance Taylor wrote:
> You omitted the RTL loop optimizer passes, which still do quite a bit
> of work despite the tree-ssa loop passes. Also if-conversion and some
> minor passes, though they are less r
On Jun 23, 2006, at 7:42 PM, Jack Howarth wrote:
I have run into a build problem with tonights gcc trunk on
MacOS X which didn't exist in yesterdays
svn pull. The gcc trunk build on MacOS X 10.4.6 crashes with...
I can reproduce this, something is miscompiling cc1plus.
-- Pinski
Steven Bosscher wrote:
Every time some RTL optimizer is re-re-re-re-re-evaluated, it turns
out we lose without it. Good luck to you, but I think you're seriously
underestimating the complexity of things here.
Its clearly not as good as a new register allocator would be, but the
effort to be
Snapshot gcc-4.2-20060624 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20060624/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
Thanks for everybody who replied. I have extracted some information
from the replies and described it in
http://gcc.gnu.org/wiki/TestingGCC, see "Interpretation of testsuite
results". Please review and edit as you see fit.
--
Laurynas
2006/6/23, Steven Bosscher <[EMAIL PROTECTED]>:
Don't write off Boehm's GC just yet. You can't expect to beat
something that has seen a lot of tuning for GCC with something that
you got working only a few days ago. There are a lot of special tricks
especially in ggc-page that may put it at an ad
Hi,
> combine.c: top mem usage: 52180k (13915k). GC execution time 0.66
> (0.61) 4% (4%). User running time: 0m16 (0m14).
Are these with checking on or off? Normally checking is on, you have
to go out of your way to turn it off. If it were on, the real
numbers are going to look much worse tha
On Jun 24, 2006, at 1:43 PM, Laurynas Biveinis wrote:
An excellent suggestion, although my primary working platform is
valgrind-less Cygwin, but I will find a way to gather cache usage
data.
You could try to use Vtune though.
Thanks,
Andrew Pinski
2006/6/23, David Nicol <[EMAIL PROTECTED]>:
Is it possible to turn garbage collection totally off for a null-case
run-time comparison or would that cause thrashing except for very
small jobs?
It should be possible to adopt ggc-none for usage in GCC proper with
little effort. Shouldn't cause tra
Gabriel Dos Reis wrote:
Mark Mitchell <[EMAIL PROTECTED]> writes:
| I'm just not comfortable with the idea of #pragmas affecting
| instantiations. (I'm OK with them affecting specializations, though; in
| that case, the original template has basically no impact, so I think
| it's fine to treat t
Jason Merrill wrote:
> Yep. I'm sympathetic to Mark's position, but still tend to believe that
> the #pragma should affect explicit instantiations.
I don't feel strongly enough to care; let's do make sure, however, that
we clearly document the precedence, so that people know what to expect.
Tha
On Sat, 2006-06-24 at 13:04 +0200, Steven Bosscher wrote:
> On 6/24/06, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
> > On Fri, 2006-06-23 at 15:07 -0700, Ian Lance Taylor wrote:
> >=
> > In general, I didnt mention anything that tends not to increase register
> > pressure, at least not in any signif
On Sat, 2006-06-24 at 12:36 -0400, Vladimir N. Makarov wrote:
> Steven Bosscher wrote:
> As for Andrew's proposal, my opinion is that all this
> transformations are done too early and we need them to do again on
> rtl sometime.
>
> o coalescing. CSE can create more moves but more important thi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Danny Smith wrote:
> Adding a real __cxa_atexit to mingw runtime is of course also possible,
> but I thought I'd attempt the easy options first.
When you say "runtime", do you mean libstdc++ or something
like libmingwex.a in "mingw-runtime"? If you me
Andrew MacLeod wrote:
o register pressure relief through live range splitting and/or
rematerialization. We have no accurate information here, because
after that there are passes which change the pressure like insn
Sure, Im not suggesting that RABLET will reduce the register pressure
23 matches
Mail list logo
