Re: -fprofile-arcs
> 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]=x1;
> }
> }
>
> main() {
> int *a,*p,i=0;
> int x1,x2,x3,x4;
> a=malloc(sizeof(int));
> p=malloc(sizeof(int));
> a[0]=0;
> foo(0,a,p);
> printf("\n%d ",*p);
> for(i=0;i<1;i++) {
> printf(" %d ",a[i]);
> }
> }
>
> This code was executed using "gcc -O3 -fprofile-arcs --param
> max-unroll-times=0 a.c".
> "a.out" was then executed (for profiling).
> Now I compile using "gcc -O3 -fbranch-probabilities --param
> max-unroll-times=0 a.c".
> During this phase, I try to obtain dynamic frequencies of the statements
> within the "for"
> loop in "foo" method at RTL level. The frequencies return "0" using
> "bb->count". I
> would like this to reflect "200". How to obtain this information?
I think the problem is that foo gets inlined into main, so the offline
copy of foo is really never executed.
Honza
>
> regards,
> Raj
>
>
>
>
>
>
>
> Jan Hubicka <[EMAIL PROTECTED]>
> 07/18/2005 10:29 AM
>
> To
> Rajkishore Barik/India/[EMAIL PROTECTED]
> cc
> gcc@gcc.gnu.org
> Subject
> Re: -fprofile-arcs
>
>
>
>
>
>
> > Hi,
> >
> > I am trying to profile the frequency of each basic block of
> > SPEC 2000 benchmarks by compiling them using -fprofile-arcs and opt -O3.
> > After running the benchmark, when I try to read "bb->count" while
> > compiling
> > using "-fbranch-probabilities and -O3", I get "0" values for basic
> blocks
> > which were known to execute for sure. Any clue as to where I am missing?
> > Is "bb->count" is the right way to get the dynamic frequency in the
> second
> > pass?
>
> It is. You would need to provide more information for me to figure out
> what is going wrong. Of course the bb->count is initialized only after
> profile is read in that at current mainline is pretty late in
> compilation queue (after bp RTL pass), but this is going to change
> hopefully at monday.
>
> Honza
> >
> > regards,
> > Raj
>
Building mips cross compiler on mingw
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/ -isystem c:/devkitPro/devkitPSP_4.0.1/psp/include -isystem c:/devkitPro/devkitPSP_4.0.1/psp/sys-include -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -G 0 -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I -I../../../gcc-4.0.1-new/gcc -I../../../gcc-4.0.1-new/gcc/ -I../../../gcc-4.0.1-new/gcc/../include -I../../../gcc-4.0.1-new/gcc/../libcpp/include -DL_muldi3 -c ../../../gcc-4.0.1-new/gcc/libgcc2.c -o libgcc/./_muldi3.o C:/DOCUME~1/DAVEMN~1.000/LOCALS~1/Temp/ccAF.s: Assembler messages: C:/DOCUME~1/DAVEMN~1.000/LOCALS~1/Temp/ccAF.s:19: Warning: expected `$' C:/DOCUME~1/DAVEMN~1.000/LOCALS~1/Temp/ccAF.s:19: Error: junk at end of line, first unrecognized character is `n' make[2]: *** [libgcc/./_muldi3.o] Error 1 make[2]: Leaving directory `/c/projects/devkitPro/sources/psp/gcc/gcc' make[1]: *** [stmp-multilib] Error 2 make[1]: Leaving directory `/c/projects/devkitPro/sources/psp/gcc/gcc' make: *** [all-gcc] Error 2 Error building all-gcc saving temp files and adding -v gives this Reading specs from c:/projects/devkitPro/sources/psp/gcc/gcc/specs Target: psp Configured with: ../../gcc-4.0.1-new/configure --enable-languages=c,c++ --disable-multilib --with-gcc --with-gnu-ld --with-gnu-as --with-stabs --disable-shared --disable-win32-registry --disable-nls --enable-cxx-flags=-G0 --target=psp --with-newlib --prefix=c:/devkitPro/devkitPSP_4.0.1 Thread model: single gcc version 4.0.1 c:/projects/devkitPro/sources/psp/gcc/gcc/cc1.exe -E -quiet -v -I. -I -I../../../gcc-4.0.1-new/gcc -I../../../gcc-4.0.1-new/gcc/ -I../../../gcc-4.0.1-new/gcc/../include -I../../../gcc-4.0.1-new/gcc/../libcpp/include -iprefix c:\projects\devkitpro\sources\psp\gcc\gcc\../lib/gcc/psp/4.0.1/ -isystem c:/projects/devkitPro/sources/psp/gcc/gcc/include -DIN_GCC -DCROSS_COMPILE -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -DL_muldi3 -isystem c:/devkitPro/devkitPSP_4.0.1/psp/include -isystem c:/devkitPro/devkitPSP_4.0.1/psp/sys-include -isystem ./include ../../../gcc-4.0.1-new/gcc/libgcc2.c -G 0 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -fworking-directory -O2 -fpch-preprocess -o libgcc2.i ignoring nonexistent directory "c:/devkitPro/devkitPSP_4.0.1/psp/include" ignoring nonexistent directory "c:/devkitPro/devkitPSP_4.0.1/psp/sys-include" ignoring nonexistent directory "c:\projects\devkitpro\sources\psp\gcc\gcc\../lib/gcc/psp/4.0.1/include" ignoring nonexistent directory "c:\projects\devkitpro\sources\psp\gcc\gcc\../lib/gcc/psp/4.0.1/../../../../psp/sys-include" ignoring nonexistent directory "c:\projects\devkitpro\sources\psp\gcc\gcc\../lib/gcc/psp/4.0.1/../../../../psp/include" ignoring nonexistent directory "c:/devkitPro/devkitPSP_4.0.1/lib/gcc/psp/4.0.1/include" ignoring nonexistent directory "c:/devkitPro/devkitPSP_4.0.1/lib/../psp/sys-include" ignoring nonexistent directory "c:/devkitPro/devkitPSP_4.0.1/lib/../psp/include" ignoring nonexistent directory "-I../../../gcc-4.0.1-new/gcc" #include "..." search starts here: #include <...> search starts here: . ../../../gcc-4.0.1-new/gcc ../../../gcc-4.0.1-new/gcc/../include ../../../gcc-4.0.1-new/gcc/../libcpp/include c:/projects/devkitPro/sources/psp/gcc/gcc/include ./include End of search list. c:/projects/devkitPro/sources/psp/gcc/gcc/cc1.exe -fpreprocessed libgcc2.i -G 0 -quiet -dumpbase libgcc2.c -auxbase-strip libgcc/./_muldi3.o -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -version -o libgcc2.s GNU C version 4.0.1 (psp) compiled by GNU C version 3.4.2 (mingw-special). GGC heuristics: --param ggc-min-expand=56 --param ggc-min-heapsize=49086 c:/devkitPro/devkitPSP_4.0.1/psp/bin/as.exe --traditional-format -G 0 -EL -O2 -g -no-mdebug -mabi=eabi -v -o libgcc/./_muldi3.o libgcc2.s GNU assembler version 2.16.1 (psp) using BFD version 2.16.1 libgcc2.s: Assembler messages: libgcc2.s:19: Warning: expected `$' libgcc2.s:19: Error: junk at end of line, first unrecognized character is `n' I've attached the saved temp files. The same build process works fine on linux and I've compared output. The preprocessed source is identical barring paths. The assembly output differs only in the function prologue on mingw built compiler __muldi3: .frame$sp,0,(null)# vars= 7640055, regs= 0/0, args= 0, gp= 0 on linux built compiler __muldi3: .frame$sp,0,$31# vars= 0, regs= 0/0, args= 0, gp= 0 can anyone point me in the right direction? I'm not quite sure what I should be looking for. Dave # 1 "../../../gcc-4.0
Problems on Fedora Core 4
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 doCommand(X* thisclass, const char* funcname)
{
// See Stroustrup III, p 420
commandTags* tags = mustags;
if (quickfindtag.empty()) {
// fill quickfindtag map with all the entries in mustags array
while (tags->name != NULL) {
quickfindtag.insert(std::pair(tags->name,
tags->func));
++tags;
}
}
// find tag in quickfindtag map
std::map::const_iterator functionIterator =
quickfindtag.find(funcname);
if (functionIterator != quickfindtag.end()) {
thisfunc func = functionIterator->second;
(thisclass->*func)(); // run function
return 1;
}
return 0; // function not found
}
};
I have just installed Fedora Core 4 and am trying to compile it with gcc
4.0.0 (Redhat 4.0.0-8). However I get the error message:
FmDisplay.h: In member function 'mapTags::doCommand(X*, const char*)'
FmDisplay.h:61: error: expected `;' before 'functionIterator'
FmDisplay.h:62: error: 'functionIterator' was not declared in this scope
I do not know why this is happening. I installed gcc 2.95.3 and got
exactly the same error message so it is possibly to do with the Fedora
installation rather than gcc.
The same code compiles ok on Solaris 5.6/7 with egcs-2.91.66 and on
Redhat 8.0 with gcc 2.95.3.
Thanks in advance.
Mike
--
___
Michael Gatford
Senior Technical Consultant
___
APR Smartlogik Limited.
Rustat House - Clifton Road - Cambridge - CB1 7EJ
phone +44 (0)1223 27 1025
fax +44 (0)1223 27 1010
map: http://www.aprsmartlogik.com/contact/CambridgeMap.pdf
mailto:[EMAIL PROTECTED]
http://www.aprsmartlogik.com/
***
This e-mail may contain proprietary and confidential
information and is intended for the recipient(s) only.
If an addressing or transmission error has misdirected this
e-mail, please notify the systems administrator by forwarding
this e-mail to mailto:[EMAIL PROTECTED]
If you are not the intended recipient(s) disclosure, distribution,
copying or printing of this e-mail is strictly prohibited.
***
RE: Building mips cross compiler on mingw
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 different
_target_.
> Reading specs from c:/projects/devkitPro/sources/psp/gcc/gcc/specs
> Target: psp
> Configured with: ../../gcc-4.0.1-new/configure --enable-languages=c,c++
> --disable-multilib --with-gcc --with-gnu-ld --with-gnu-as --with-stabs
> --disable-shared --disable-win32-registry --disable-nls
> --enable-cxx-flags=-G0 --target=psp --with-newlib
There's no such thing in FSF gcc (unless it was sneaked in just after
RC2...):
[EMAIL PROTECTED] /gnu/testing/psp> /gnu/testing/gcc-4.0.1-20050702/configure
--enable-la
nguages=c --target=psp
creating cache ./config.cache
checking host system type... i686-pc-cygwin
checking target system type... Invalid configuration `psp': machine `psp'
not recognized
> The same build process works fine on linux and I've compared output. The
> preprocessed source is identical barring paths. The assembly output
> differs only in the function prologue
>
> on mingw built compiler
>
> __muldi3:
> .frame$sp,0,(null)# vars= 7640055, regs= 0/0, args= 0,
^^ ^^
This is very bad.This is even worse.
Stack frame generation / layout is going wrong if it thinks __muldi3 needs
seven and a bit megs of stack. However, perhaps that's not the correct
number for how much it actually does think it wants.
> can anyone point me in the right direction? I'm not quite sure what I
> should be looking for.
You're looking for gcc to be calling *printf and passing a NULL argument
to a %s format character, basically. Whatever patches you have applied must
be faulty. The bad call is in gcc/config/mips/mips.c
(mips_output_function_prologue):
if (!flag_inhibit_size_directive)
{
/* .frame FRAMEREG, FRAMESIZE, RETREG */
fprintf (file,
"\t.frame\t%s," HOST_WIDE_INT_PRINT_DEC ",%s\t\t"
"# vars= " HOST_WIDE_INT_PRINT_DEC ", regs= %d/%d"
", args= " HOST_WIDE_INT_PRINT_DEC
", gp= " HOST_WIDE_INT_PRINT_DEC "\n",
(reg_names[(frame_pointer_needed)
? HARD_FRAME_POINTER_REGNUM :
STACK_POINTER_REGNUM]),
((frame_pointer_needed && TARGET_MIPS16)
? tsize - cfun->machine->frame.args_size
: tsize),
reg_names[GP_REG_FIRST + 31],
cfun->machine->frame.var_size,
cfun->machine->frame.num_gp,
cfun->machine->frame.num_fp,
cfun->machine->frame.args_size,
cfun->machine->frame.cprestore_size);
Hmm. Perhaps we have HOST_WIDE_INT problems for mingw host here? If
cfun->machine->frame.var_size was a long long, and HOST_WIDE_INT_PRINT_DEC
for mingw is just "%d" or "%ld" rather than "%lld", that would push an extra
NULL word onto the stack that would be taken as the parameter for %s because
the "%d" wouldn't be advancing the varargs pointer past the whole of the
second format arg...
cheers,
DaveK
--
Can't think of a witty .sigline today
Re: Problems on Fedora Core 4
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 Bajo
Re: Problems on Fedora Core 4
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
RE: Building mips cross compiler on mingw
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,
> "\t.frame\t%s," HOST_WIDE_INT_PRINT_DEC ",%s\t\t"
> "# vars= " HOST_WIDE_INT_PRINT_DEC ", regs= %d/%d"
> ", args= " HOST_WIDE_INT_PRINT_DEC
> ", gp= " HOST_WIDE_INT_PRINT_DEC "\n",
> (reg_names[(frame_pointer_needed)
> ? HARD_FRAME_POINTER_REGNUM :
> STACK_POINTER_REGNUM]),
> ((frame_pointer_needed && TARGET_MIPS16)
> ? tsize - cfun->machine->frame.args_size
> : tsize),
> reg_names[GP_REG_FIRST + 31],
> cfun->machine->frame.var_size,
> cfun->machine->frame.num_gp,
> cfun->machine->frame.num_fp,
> cfun->machine->frame.args_size,
> cfun->machine->frame.cprestore_size);
>
> Hmm. Perhaps we have HOST_WIDE_INT problems for mingw host here? If
... either HOST_WIDE_INT or ...
> cfun->machine->frame.var_size was a long long, and HOST_WIDE_INT_PRINT_DEC
> for mingw is just "%d" or "%ld" rather than "%lld", that would push an
> extra NULL word onto the stack that would be taken as the parameter for
> %s because the "%d" wouldn't be advancing the varargs pointer past the
> whole of the second format arg...
Ooops, slight braino there. I meant the second argument involving
cfun->machine->frame.args_size may be pushing reg_names[GP_REG_FIRST + 31]
along. You could verify that was happening by running cc1 under gdb,
setting a breakpoint here, and checking that reg_names[GP_REG_FIRST + 31]
isn't actually NULL. You may also be able to workaround the bug with
-finhibit-size-directive.
cheers,
DaveK
--
Can't think of a witty .sigline today
Function Inlining for FORTRAN
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.
Re: Function Inlining for FORTRAN
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 it, I will give a try. Would you please give me
> some clues?
The problem is that each top level program unit (PU)[1] is compiled
separately. Each PU has it's own "external" decls for all function calls,
even if the function happens to be in the same function. Thus each PU is an
isolated self-contained tree structure, and the callgraph doesn't know the
definition and declaration are actually the same thing.
Basically what you need to do is parse the whole file, then start generating
code.
Unfortunately this isn't simple (or it would have been fixed already!).
Unlike C Fortran doesn't have file-level scope. It makes absolutely no
difference whether two procedures are in the same file, or in different
files. You get all the problems that multifile IPA in C experiences within a
single Fortran file.
The biggest problem is type consistency and aliasing. Consider the following
example:
subroutine a(p)
type t
integer :: t1
end type
type(t) :: p
p%t1 = 42
end subroutine
subroutine b
type u
integer :: u1
end type
type (u) :: q
call a(q)
print * q%u1
end subroutine
Here you have two different derived types which are actually the same derived
types. To make unit-at-a-time work (ie. inlining) you need to either
(a) Replace all occurrences of one type with the other
(b) Tell the compiler that the two types alias, and fixup the types with
explicit casts at any interfaces.
Ideally we'd do (a), but I don't think doing that is practical, and might not
even be possible. I think it would require fairly major hacking of the whole
frontend.
Which leaves (b).
Currently the high-level flow is something like:
- Parse and resolve the PU. This is basically everything before
gfc_generate_code.
- Call gfc_generate_code (or gfc_generate_module_code) to generate code for
that PU.
- Throw away the PU.
- Repeat for each function.
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 them
together somehow. It 's probably worth maintaining some sort of global symbol
table and building these associations incrementally during resolution.
- Generate global DECLs for all PU. Something similar to
gfc_create_function_decl. Probably also generate global DECLs for external
routines.
- Generate common blocks. This may simplify the existing code because we have
all definitions before we start generating DECLs.
- Generate code for each PU. This is more-or-less the same as the current code
except function calls may need explicit typecasts to accommodate type
mismatches described above.
- Tweak aliasing information so this type mismatching doesn't generate bad
code.
I believe Steven Bosscher had a go at implementing this, but never got it to
work properly.
Paul
[1] A top level Program Unit is a file-level subroutine, function, program or
module. If a PU has contained procedures these procedures and the parent
procedure constitute a single PU.
Re: Headsup - New PCH Failures on 3.4.x under Linux-2.6.12
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. :-)
Re: Function inlining for FORTRAN
Hi, I don't think Paul's example is completely correct, I've created PR22571 with some more info. Cheers, Joost
Re: Function Inlining for FORTRAN
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
> them together somehow. It 's probably worth maintaining some sort of global
> symbol table and building these associations incrementally during
> resolution.
This is what I was working on, but I never finished it. I encountered
some memory corruption issues (procedure names disappearing underneath
me) that I never found time for to investigate.
I've appended the last incarnation of my hack that I could find in my
local mail archive. This was supposed to help implement the first two
points of (b). Actually linking things together is something I never
got to do.
Gr.
Steven
Index: f95-lang.c
===
RCS file: /cvs/gcc/gcc/gcc/fortran/f95-lang.c,v
retrieving revision 1.26
diff -u -3 -p -r1.26 f95-lang.c
--- f95-lang.c 25 Nov 2004 11:13:35 - 1.26
+++ f95-lang.c 11 Dec 2004 20:34:40 -
@@ -45,6 +45,7 @@ Software Foundation, 59 Temple Place - S
#include "cgraph.h"
#include "gfortran.h"
+#include "gfc-toplev.h"
#include "trans.h"
#include "trans-types.h"
#include "trans-const.h"
@@ -262,17 +263,36 @@ gfc_be_parse_file (int set_yydebug ATTRI
int errors;
int warnings;
- gfc_create_decls ();
- gfc_parse_file ();
- gfc_generate_constructors ();
+ /* Set up the module and subprogram queues for the parser. */
+ gfc_initialize_module_and_subprogram_queues ();
- cgraph_finalize_compilation_unit ();
- cgraph_optimize ();
+ /* Parse the whole input file, queueing up things as we see them. */
+ gfc_parse_file ();
/* Tell the frontent about any errors. */
gfc_get_errors (&warnings, &errors);
errorcount += errors;
warningcount += warnings;
+
+ /* If there were no errors and we not asked to skip code generation,
+ generate code for all queued modules and subprograms. */
+ if (errors == 0 && ! gfc_option.flag_no_backend)
+{
+ gfc_create_decls ();
+ gfc_generate_code ();
+ gfc_generate_constructors ();
+
+ /* We've now generated code for everything, so we can free up
+all the parsing data structures and queues. */
+ gfc_finalize_module_and_subprogram_queues ();
+
+ /* Hand over control to the middle-end. */
+ cgraph_finalize_compilation_unit ();
+ cgraph_optimize ();
+}
+ else
+/* Just free the queues. */
+gfc_finalize_module_and_subprogram_queues ();
}
/* Initialize everything. */
Index: gfc-toplev.h
===
RCS file: gfc-toplev.h
diff -N gfc-toplev.h
--- /dev/null 1 Jan 1970 00:00:00 -
+++ gfc-toplev.h11 Dec 2004 20:34:40 -
@@ -0,0 +1,106 @@
+/* Header for toplevel translation functions.
+ Copyright (C) 2004 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it under
+the terms of the GNU General Public License as published by the Free
+Software Foundation; either version 2, or (at your option) any later
+version.
+
+GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING. If not, write to the Free
+Software Foundation, 59 Temple Place - Suite 330, Boston, MA
+02111-1307, USA. */
+
+#ifndef GFC_TOPLEV_H
+#define GFC_TOPLEV_H
+
+#include "vec.h"
+#include "gfortran.h"
+
+/* This header defines the interface between the parser and the
+ inter-subprogram name resolution and code generation phases.
+ The "driver" for the compilation process is in f95-lang.c, from where
+ we call the parser which queues up all modules and subprograms, then
+ the ip-resolve pass, and finally the code generator (trans*.[ch]).
+ The interface consists of two queues, one for modules and one for all
+ possible kinds of subprograms, including the main PROGRAM, for which
+ we produce a dummy function subprogram called __MAIN. */
+
+/* The queues are vectors of gfc_namespace pointers. Unfortunately we
+ need a new typedef for that. */
+typedef gfc_namespace * gfc_namespace_p;
+DEF_VEC_MALLOC_P(gfc_namespace_p);
+extern VEC(gfc_namespace_p) *gfc_module_queue;
+extern VEC(gfc_namespace_p) *gfc_subprogram_queue;
+
+
+/* Add module M to the queue of modules to generate code for.
+ Note that the .mod files are generated from the parser, because they
+ might be needed in other subprograms. */
+
+static inline void
+gfc_queue_module (gfc_namespace *m)
+{
+ VEC_safe_push (gfc_namespace_p, gfc_module_queue, m);
+}
+
+
+/*
Re: Function inlining for FORTRAN
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 my option (a). Ie. use the same type for all derived types that are "the same". This basically means where we create global function DECLs we also want to create global type declarations for derived types, and the type munging of function arguments becomes a no-op. Some trickey may still be needed for modules, but that's a slightly different issue. Paul
Re: Problems on Fedora Core 4
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). However I get the error message: FmDisplay.h: In member function 'mapTags::doCommand(X*, const char*)' FmDisplay.h:61: error: expected `;' before 'functionIterator' FmDisplay.h:62: error: 'functionIterator' was not declared in this scope I do not know why this is happening. I installed gcc 2.95.3 and got exactly the same error message so it is possibly to do with the Fedora installation rather than gcc. The same code compiles ok on Solaris 5.6/7 with egcs-2.91.66 and on Redhat 8.0 with gcc 2.95.3. Thanks in advance. Mike
-fprofile-generate and -fprofile-use
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 phase otherwise it would die looking for gcov functions. 2. Ran a representative work-load 3. Followed (1) except that instead of -fprofile-generate used -fprofile-use I had to drop the "-fprofile-use" on 2 files as they had corrupted profile data. I have tried this experiment with -fprofile-arc and -fbranch-probabilities as well and I get the same 20% slowdown. Thx -girish
Re: -fprofile-generate and -fprofile-use
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
Re: -fprofile-generate and -fprofile-use
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 that you should probably first > > tell what compiler > > you are using. > > > > Gr. > > Steven > > > > > >
Re: -fprofile-generate and -fprofile-use
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 this. > > > > > > My first thought is that you should probably first > > > tell what compiler > > > you are using. > > I am using gcc 3.4.3 > -girish Which platform? I've seen slower code for profile-directed optimizations on powerpc64-linux with GCC 4.0 and mainline. It's a bug, but I haven't looked into it enough to provide a small test case for a problem report. Janis
Re: -fprofile-generate and -fprofile-use
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: > > > > > 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. > > > > I am using gcc 3.4.3 > > -girish > > Which platform? I've seen slower code for > profile-directed optimizations > on powerpc64-linux with GCC 4.0 and mainline. It's > a bug, but I haven't > looked into it enough to provide a small test case > for a problem report. > > Janis >
Multilibbing threaded supports
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. Otherwise, every application may potentially have to link against the threads library, and that can cause a considerable overhead. Advice / opinions welcome. Kean
Re: Multilibbing threaded supports
> 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> version of (say) libstdc++ if your app is threaded. Otherwise, Kean> every application may potentially have to link against the Kean> threads library, and that can cause a considerable overhead. Kean> Advice / opinions welcome. The AIX configuration of GCC multilibs thread support. David
Re: Multilibbing threaded supports
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 to enable support for it. Would anyone object to renaming it from "Solaris" to "UI"? Kean
Re: -fprofile-generate and -fprofile-use
> 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 this. > > > > > > > > My first thought is that you should probably first > > > > tell what compiler > > > > you are using. > > > > I am using gcc 3.4.3 > > -girish > > Which platform? I've seen slower code for profile-directed optimizations > on powerpc64-linux with GCC 4.0 and mainline. It's a bug, but I haven't > looked into it enough to provide a small test case for a problem report. Actually I would be very interested in seeing testcases such as those. (and the Girish' slowdown too if possible). In general some slowdowns in side corners are probably unavoidable but both 3.4.3 and 4.0 seems to have pretty consistent improvements with profiling at least for SPEC and i386 I am testing pretty regularly. Such slodowns usually indicate problems like incorrectly updated profile or incorrectly readed in profile because of missmatch in CFGs in between profile and feedback run that are rather dificult to notice and hunt down... Honza > > Janis
Re: -fprofile-generate and -fprofile-use
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. What I mean is since -fprofile-generate and -fprofile-use enable a bunch of flags, would it make sense to avoid profiling and try out some of the individual flags on a trial and error basis. If so what would be the flags to start the trials with. -girish --- Jan Hubicka <[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: > > > > > > 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. > > > > > > I am using gcc 3.4.3 > > > -girish > > > > Which platform? I've seen slower code for > profile-directed optimizations > > on powerpc64-linux with GCC 4.0 and mainline. > It's a bug, but I haven't > > looked into it enough to provide a small test case > for a problem report. > > Actually I would be very interested in seeing > testcases such as those. > (and the Girish' slowdown too if possible). In > general some slowdowns > in side corners are probably unavoidable but both > 3.4.3 and 4.0 seems to > have pretty consistent improvements with profiling > at least for SPEC and > i386 I am testing pretty regularly. > Such slodowns usually indicate problems like > incorrectly updated profile > or incorrectly readed in profile because of > missmatch in CFGs in between > profile and feedback run that are rather dificult to > notice and hunt > down... > > Honza > > > > Janis >
-malign-double vs __alignof__(double)
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.
Re: PING [4.1 regression, patch] build i686-pc-mingw32
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 wrapper. > >Because it is desirable to leave the tools where they were: 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)? cgf
Re: PING [4.1 regression, patch] build i686-pc-mingw32
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 above script, I wonder why 'cp' wasn't used instead of creating > >>a shell script wrapper. > > > >Because it is desirable to leave the tools where they were: > > 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)? That's basically what it does now; the only case which uses ln || cp is for tools in the build directory, in which case they obviously are not in their install location. -- Daniel Jacobowitz CodeSourcery, LLC
Re: PING [4.1 regression, patch] build i686-pc-mingw32
> 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 tools which don't care where they are, but in the case with a system (i.e. third party) tool, we don't know, hence the script. There's also the complexity of locating a utility in $PATH, which may even change between configure and make. IMHO for MinGW, we (1) know that we're using GNU tools, and (2) realize we have an exceptional situation wrt the build system. I think this justifies an exception test in that snippet of code.
Re: PING [4.1 regression, patch] build i686-pc-mingw32
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 that, in the case with ln/cp, we *know* we're dealing >with GNU tools which don't care where they are, but in the case with a >system (i.e. third party) tool, we don't know, hence the script. Is that actually true, though? Doesn't GNU ld try to locate files relative to its invoked path? Is there a non-GNU ld out there which needs to reference things relative to its path? >There's also the complexity of locating a utility in $PATH, which may >even change between configure and make. > >IMHO for MinGW, we (1) know that we're using GNU tools, and (2) >realize we have an exceptional situation wrt the build system. I >think this justifies an exception test in that snippet of code. I hate seeing this kind of system exception in code. As much as I like MinGW, this is one of the things that bugs me about it. Adding window-isms to code can be like a creeping fungus. Danny Smith said this: >I just configure using --with-as=/path/to/original-as-for-target and I >don't run into the problem. Since we know that mingw uses GNU ld couldn't we prewire this action into configure by default and avoid the need for this kind of system-specific behavior in the makefile? cgf
should mixed buffered i/o be indeterminant?
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 the c++ code through
a c interface call. The problem I am having is that when one
redirects the output from the xplor-nih program to a file, the
buffers from the different langauges purge at different times
so that output doesn't occur sequentially as it does to a terminal.
For example, I can demonstrate this with the following code...
hello.f
--
SUBROUTINE HELLO
INTEGER CPLUS_OUTPUT
EXTERNAL CPLUS_OUTPUT
INTEGER SHELL
WRITE(6,'(A)') ' before output from c++ code'
SHELL=CPLUS_OUTPUT()
WRITE(6,'(A)') ' after output from c++ code'
RETURN
END
cplus_output.cc
#include
#define FORTRAN(x) (x ## _)
extern "C" void
FORTRAN(cplus_output)()
{
for (int i=0 ; i<1 ; i++)
cout << "Ouput from c++ of line number: " << i << "\n";
}
-
main.c
-
#include
#define FORTRAN(x) (x ## _)
void g95_runtime_stop(void);
void FORTRAN(hello)();
main()
{
FORTRAN(hello)();
g95_runtime_stop();
return 0;
}
--
If I build the above...
g95 -o hello.o -fno-second-underscore -c hello.f
g++ -o cplus_output.o -c cplus_output.cc
gcc main.c hello.o cplus_output.o ./libf95.a libf95.a
and then execute it...
./a.out > outputfile
I find that instead of having the c++ output in front and after the
fortran output, the c++ output randomly appears in the fortran output.
Andy Vaught tells me...
> If you're outputting from both the fortran and c++ side, the result is
>not determinate. It will depend on when the fortran and C libraries
>decide to flush output. That would very easily account for interleaved
>lines.
However xplor-nih has been built on at least seven different operating
systems with a number of different compilers (gnu, Intel, IBM, Portland,
SGI and Sun) and none of these have suffered this lack of synchronization
in the mixed language i/o. Can anyone clarify what the standard should
really be and if g95's i/o buffering is simply broken at the moment?
Jack
Re: PING [4.1 regression, patch] build i686-pc-mingw32
> 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 mingw uses GNU ld couldn't we prewire this action > into configure by default and avoid the need for this kind of > system-specific behavior in the makefile? 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? That gives us the functionality of symlinks even on platforms like MinGW that support neither symlinks nor shell scripts, without the nasty side effects of using cp or symlinks. Heck, it can even search $PATH for us.
Re: PING [4.1 regression, patch] build i686-pc-mingw32
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 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 tools which don't care where they are, but in the case with a > >system (i.e. third party) tool, we don't know, hence the script. > > Is that actually true, though? Doesn't GNU ld try to locate files > relative to its invoked path? Yes, that's correct. > Is there a non-GNU ld out there which needs to reference things relative > to its path? This I don't know the answer to. > >I just configure using --with-as=/path/to/original-as-for-target and I > >don't run into the problem. > > Since we know that mingw uses GNU ld couldn't we prewire this action > into configure by default and avoid the need for this kind of > system-specific behavior in the makefile? On other systems, this makes the GCC build not relocatable at install time. I don't know if that is true on mingw32 also, but I presume so. -- Daniel Jacobowitz CodeSourcery, LLC
Re: PING [4.1 regression, patch] build i686-pc-mingw32
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 > whatever path specifications it needs. 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. -- Daniel Jacobowitz CodeSourcery, LLC
Re: PING [4.1 regression, patch] build i686-pc-mingw32
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 >whatever path specifications it needs. Wouldn't that mean that 'cp' is a valid fallback even for non-GNU lds? >> Since we know that mingw uses GNU ld couldn't we prewire this action >> into configure by default and avoid the need for this kind of >> system-specific behavior in the makefile? > >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? >That gives us the functionality of symlinks even on platforms like >MinGW that support neither symlinks nor shell scripts, without the >nasty side effects of using cp or symlinks. > >Heck, it can even search $PATH for us. That sounds like a good idea to me. cgf
Re: PING [4.1 regression, patch] build i686-pc-mingw32
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 there to work around a known problem or if it is just working around a potential problem which might occur on some theoretical platform which insists that its ld must be run from a specific location. But I guess it's no more than idle curiousity. cgf
Re: PING [4.1 regression, patch] build i686-pc-mingw32
> 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 might be a problem.
Re: PING [4.1 regression, patch] build i686-pc-mingw32
> 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.
Re: PING [4.1 regression, patch] build i686-pc-mingw32
>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. Unfortunately, it seems to get this wrong is some case or another and thus these rules for "linking" the utilities into the build directory were added. Maybe it's the gcc front end that needed to be fixed, not the makefile. Ross Ridge -- l/ // Ross Ridge -- The Great HTMU [oo][oo] [EMAIL PROTECTED] -()-/()/ http://www.csclub.uwaterloo.ca/u/rridge/ db //
Re: PING [4.1 regression, patch] build i686-pc-mingw32
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
