> Hi,
>
> Thanks a lot. Basically, I want to obtain dynamic basic block frequency at
> RTL
> level just before register allocation. Look at the following piece of
> code(a.c):
>
> void foo(int i, int *a, int *p) {
> int x1,j;
> for(j=0;j<200;j++) {
> x1=a[i]+j;
> *p=99;
> a[i]=x
Hi,
I've been having some trouble building gcc 4.0.1 for mips target on a
mingw host
The build fails at this point
/c/projects/devkitPro/sources/psp/gcc/gcc/xgcc
-B/c/projects/devkitPro/sources/psp/gcc/gcc/
-Bc:/devkitPro/devkitPSP_4.0.1/psp/bin/
-Bc:/devkitPro/devkitPSP_4.0.1/psp/lib/ -is
We compile the following code with gcc (historically 2.95.3,
egcs-2.91.66 or VC5/6 on Windows).
template class mapTags {
public:
typedef void (X::*thisfunc)();
static commandTags mustags[];
std::map quickfindtag;
// Looks up function call for this name, and does it, if defined
int
Original Message
>From: Dave Murphy
>Sent: 20 July 2005 11:21
> I've been having some trouble building gcc 4.0.1 for mips target on a
> mingw host
No you aren't. You're using a modified version of the gcc-4.0.1 sources
and you're targetting PSP. That may be a MIPS backend, but it's a
Michael Gatford <[EMAIL PROTECTED]> wrote:
> std::map::const_iterator functionIterator =
> quickfindtag.find(funcname);
It's missing a typename keyword here:
typename std::map::const_iterator functionIterator =
See: http://gcc.gnu.org/gcc-3.4/changes.html, C++ section.
--
Giovanni Baj
This is not the correct mailing list for help using gcc, it is for help
developing gcc. Use gcc-help in future please.
Michael Gatford wrote:
>
>
>std::map::const_iterator functionIterator =
> quickfindtag.find(funcname);
put "typename" at the beginning of this line.
Chris
Original Message
>From: Dave Korn
>Sent: 20 July 2005 11:56
Couple of minor corrections:
>
>
HOST_WIDE_INT tsize = cfun->machine->frame.total_size;
>
> if (!flag_inhibit_size_directive)
> {
> /* .frame FRAMEREG, FRAMESIZE, RETREG */
> fprintf (file,
>
Hi, all
Function inlining for FORTRAN programs always fails. If no one engages in it, I
will give a try.
Would you please give me some clues?
Canqun Yang
Creative Compiler Research Group.
National University of Defense Technology, China.
On Wednesday 20 July 2005 15:35, Canqun Yang wrote:
> Hi, all
>
> Function inlining for FORTRAN programs always fails.
Not entirely true. Inlining of contained procedures works fine (or it did last
time I checked). This should include inlining of siblings within a module.
> If no one engages in
On Jul 19, 2005, at 7:26 PM, Greg Schafer wrote:
This is just a headsup for any folks running 3.4.x testsuite under
Linux
2.6.12 kernels (stock Linus).
:-(
I always run a modified Linus. :-)
Hi,
I don't think Paul's example is completely correct, I've created PR22571
with some more info.
Cheers,
Joost
On Wednesday 20 July 2005 17:22, Paul Brook wrote:
> To implement (b) this needs to be changed to:
>
> - Do everything up until gfc_generate{,_module}_code as normal.
> - Save the results somewhere and repeat for each PU.
> - Identify calls for procedures for which we have definitions, and link
> t
On Wednesday 20 July 2005 16:52, Joost VandeVondele wrote:
> Hi,
>
> I don't think Paul's example is completely correct, I've created PR22571
> with some more info.
Ah, this makes thing somewhat simpler. For some reason I though my example was
legal.
I think this makes it possible to implement m
Michael Gatford wrote:
We compile the following code with gcc (historically 2.95.3,
egcs-2.91.66 or VC5/6 on Windows).
std::map quickfindtag;
Shouldn't 'string' be 'std::string' also?
I have just installed Fedora Core 4 and am trying to compile it with
gcc 4.0.0 (Redhat 4.0.0-8). Howeve
I am seeing a 20% slowdown with feedback optimization.
Does anyone have any thoughts on this.
These are the steps I followed
1. Compiled the application using -fprofile-generate.
I used this flag both in the compile flags and as part
of the link flags. I also had to use libgcov.a during
the link p
On Wednesday 20 July 2005 18:53, girish vaitheeswaran wrote:
> I am seeing a 20% slowdown with feedback optimization.
> Does anyone have any thoughts on this.
My first thought is that you should probably first tell what compiler
you are using.
Gr.
Steven
I am using gcc 3.4.3
-girish
>
>
> --- Steven Bosscher <[EMAIL PROTECTED]> wrote:
>
> > On Wednesday 20 July 2005 18:53, girish
> > vaitheeswaran wrote:
> > > I am seeing a 20% slowdown with feedback
> > optimization.
> > > Does anyone have any thoughts on this.
> >
> > My first thought is th
On Wed, Jul 20, 2005 at 10:45:01AM -0700, girish vaitheeswaran wrote:
> > --- Steven Bosscher <[EMAIL PROTECTED]> wrote:
> >
> > > On Wednesday 20 July 2005 18:53, girish vaitheeswaran wrote:
> > > > I am seeing a 20% slowdown with feedback optimization.
> > > > Does anyone have any thoughts on th
This is on Intel Pentium4 on Linux.
-girish
--- Janis Johnson <[EMAIL PROTECTED]> wrote:
> On Wed, Jul 20, 2005 at 10:45:01AM -0700, girish
> vaitheeswaran wrote:
> > > --- Steven Bosscher <[EMAIL PROTECTED]> wrote:
> > >
> > > > On Wednesday 20 July 2005 18:53, girish
> vaitheeswaran wrote:
>
All,
Is it possible (or if not, desirable) to be able to multilib
around the top level --enable-threads option? On systems
where the threads library is separate from libc, being
able to do so makes sense, as you would only want a threaded
version of (say) libstdc++ if your app is threaded. Otherw
> Kean Johnston writes:
Kean> Is it possible (or if not, desirable) to be able to multilib
Kean> around the top level --enable-threads option? On systems
Kean> where the threads library is separate from libc, being
Kean> able to do so makes sense, as you would only want a threaded
Kean> versio
David Edelsohn wrote:
The AIX configuration of GCC multilibs thread support.
Thank you David, I will go look there.
I also noticed that the threads support calls what are really
the UI (UNIX International) threads "Solaris" threads. UnixWare
supports the same threading API, and I'd like
> On Wed, Jul 20, 2005 at 10:45:01AM -0700, girish vaitheeswaran wrote:
> > > --- Steven Bosscher <[EMAIL PROTECTED]> wrote:
> > >
> > > > On Wednesday 20 July 2005 18:53, girish vaitheeswaran wrote:
> > > > > I am seeing a 20% slowdown with feedback optimization.
> > > > > Does anyone have any th
I started with a clean slate in my build environment
and did not have any residual files hanging around.
Are the steps I have indicated in my earlier email
correct. Is there a way I can break down the problem
into a smaller sub-set of flags and eliminate the flag
causing the performance problem. Wh
While fighting with the x86-darwin alignment rules, I noticed that
-malign-double
doesn't seem to affect __alignof__(double). This seems like a bug, but
the
alignof doc has so many qualifications I'm not sure exactly what it's
supposed to
do. Is this broken? Thanks.
On Tue, Jul 19, 2005 at 04:21:04PM -0400, Daniel Jacobowitz wrote:
>On Tue, Jul 19, 2005 at 04:14:04PM -0400, Christopher Faylor wrote:
>>Ok. Given that 'cp' was an acceptable fallback in the original version
>>of the above script, I wonder why 'cp' wasn't used instead of creating
>>a shell script
On Wed, Jul 20, 2005 at 10:10:03PM -0400, Christopher Faylor wrote:
> On Tue, Jul 19, 2005 at 04:21:04PM -0400, Daniel Jacobowitz wrote:
> >On Tue, Jul 19, 2005 at 04:14:04PM -0400, Christopher Faylor wrote:
> >>Ok. Given that 'cp' was an acceptable fallback in the original version
> >>of the abov
> Except that "cp" is already used as a fallback for when "ln" doesn't
> work. If the tool is likely not to work after a "cp" then shouldn't the
> fallback condition be to always create a shell script (or .bat file)?
One could argue that, in the case with ln/cp, we *know* we're dealing
with GNU
On Wed, Jul 20, 2005 at 10:25:06PM -0400, DJ Delorie wrote:
>> Except that "cp" is already used as a fallback for when "ln" doesn't
>> work. If the tool is likely not to work after a "cp" then shouldn't the
>> fallback condition be to always create a shell script (or .bat file)?
>
>One could argue
I have run across a problem building xplor-nih with the g95
compiler from www.g95.org from which I understand gfortran is
derived. Xplor-nih is a mix of c, c++ and fortran code. The
main calling program a c shell which call the fortran subroutines.
These fortran subroutines in turn can call th
> Is that actually true, though? Doesn't GNU ld try to locate files
> relative to its invoked path?
Sometimes, for sysroots and ldscripts. I wouldn't expect MinGW (or
any native linker) to use this feature. GCC usually passes ld
whatever path specifications it needs.
> Since we know that ming
On Wed, Jul 20, 2005 at 10:40:39PM -0400, Christopher Faylor wrote:
> On Wed, Jul 20, 2005 at 10:25:06PM -0400, DJ Delorie wrote:
> >> Except that "cp" is already used as a fallback for when "ln" doesn't
> >> work. If the tool is likely not to work after a "cp" then shouldn't the
> >> fallback con
On Wed, Jul 20, 2005 at 10:58:05PM -0400, DJ Delorie wrote:
>
> > Is that actually true, though? Doesn't GNU ld try to locate files
> > relative to its invoked path?
>
> Sometimes, for sysroots and ldscripts. I wouldn't expect MinGW (or
> any native linker) to use this feature. GCC usually pas
On Wed, Jul 20, 2005 at 10:58:05PM -0400, DJ Delorie wrote:
>> Is that actually true, though? Doesn't GNU ld try to locate files
>> relative to its invoked path?
>
>Sometimes, for sysroots and ldscripts. I wouldn't expect MinGW (or
>any native linker) to use this feature. GCC usually passes ld
>
On Wed, Jul 20, 2005 at 11:10:49PM -0400, DJ Delorie wrote:
>>Wouldn't that mean that 'cp' is a valid fallback even for non-GNU lds?
>
>We don't know what *else* a non-gnu linker/assembler might need.
I guess what I'm trying to get at here is some feeling for whether the
shell script method is the
> I build mingw cross toolchains with sysroots :-) That'll be affected
> by this change. Of course, currently I cross-build them from
> --build=i686-linux, so it doesn't affect me directly.
The problem case is build=mingw, not host=mingw. I suppose a
mingw-hosted (and -built) cross compiler mig
> Wouldn't that mean that 'cp' is a valid fallback even for non-GNU lds?
We don't know what *else* a non-gnu linker/assembler might need.
>A thought occurs to me... we *know* how to build build-system
>executables, like gen*.exe. Why can't we have small C programs that
>know where as/ld are, know how to exec them portably (libiberty), etc?
You already have a not-so-small C program that's supposed to know where
as and ld are. Unfor
Heck, it can even search $PATH for us.
That sounds like a good idea to me.
Please assign the bug to me. I am not receiving Bugzilla mail for some
reason, I guess I'll have to subscribe to gcc-bugs and use procmail.
Paolo
39 matches
Mail list logo
