Mark Mitchell | 1 Sep 2006 01:00

Re: First cut on outputing gimple for LTO using DWARF3. Discussion invited!!!!

mathieu lacage wrote:

> I have spent a considerable amount of time looking at the abbrev tables
> output by gcc are not totally random: their entries are sorted by their
> abbrev code. That is, the abbrev code of entry i+1 is higher than that
> of entry i.

That's an interesting observation.  Essentially, you've shown that by 
storing lg(n) information, you can cut the cost to find an entry in an 
abbreviation table of size n to a constant.  Since, for LTO, we 
certainly can depend on the .o file being produced by GCC, we could 
depend on this behavior, even though it's not mandated by the DWARF 
standard.

I think this is probably moot, since I believe that Kenny feels DWARF is 
not suitable for reasons other than the abbreviation table issue, but 
this is a clever technique.

Thanks,

--

-- 
Mark Mitchell
CodeSourcery
mark <at> codesourcery.com
(650) 331-3385 x713

H. J. Lu | 1 Sep 2006 01:13

SPEC CPU 2006 and gcc

Has anyone tried SPEC CPU 2006 with gcc mainline and 4.1 branch?
Currently, there is at least one regression affecting SPEC CPU 2006:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28908

I was wondering if anyone had run into problems with gcc. I need 3
patches for SPEC CPU 2006 to support gcc on Linux:

1. Add -fPIC to bzip2 for shared library. Link time issue.
2. Fix perlbench for gcc on ia64. Run time issue.
3. Initialize stack pointers in tonto. Run time issue.

H.J.

Sebastian Pop | 1 Sep 2006 13:56
Picon
Favicon

Re: MyGCC and whole program static analysis

Daniel Berlin wrote:
> >As some few people might already know, the GGCC (globalgcc) project is
> >just starting (partly funded within the ITEA framework by french,
> >spanish, swedish public money) - its kick off meeting is next week in
> >Paris.
> >
> >GGCC aims to provide a (GPL opensource) extension to GCC for program
> >wide static analysis (& optimisations) and coding rules
> >validation. But this mail is not a formal announcement of it...
> >
> >I am also extremely interested in the LTO framework, in particular
> >their persistence of GIMPLE trees. Could LTO people explain (if
> >possible) if their framework is extensible (to some new Gimple nodes)
> >and usable in some other setting (for example, storing program wide
> >static analysis partial results, perhaps in a "project" related
> >database or file).
> 
> This is one of the goals of LTO.
> 
> To steer this thread onto another topic, if you ever plan on getting
> your "globalgcc" changes back into gcc proper, I highly suggest you do
> your design and implementation discussions on gcc's mailing lists, and
> coordinate with GCC people who work in those areas.  GCC itself is
> gearing up to start doing program wide analysis and optimization, and
> I guarantee you that if you guys go off and do it on your own in
> seclusion you will
> 1. duplicate work
> 2. make it incredibly hard to get your work back into gcc.
> 
> Of course, if getting work into gcc is not a goal of globalgcc, than
(Continue reading)

Richard Guenther | 1 Sep 2006 13:08
Picon

building cross-libmudflap not possible because of libtool bug?


I'm experiencing building libmudflap cross, as libtool seems not to
pass --sysroot arguments to the compiler driver in link mode:

/bin/sh ./libtool --mode=link 
/usr/src/packages/BUILD/gcc-4.1.2-20060731/obj-i586-suse-linux/./gcc/xgcc 
-B/usr/src/packages/BUILD/gcc-4.1.2-20060731/obj-i586-suse-linux/./gcc/ 
-B/opt/cross/sh4-linux/bin/ -B/opt/cross/sh4-linux/lib/ -isystem 
/opt/cross/sh4-linux/include -isystem /opt/cross/sh4-linux/sys-include 
-Wall -ffunction-sections -fdata-sections -O2 -g -O2  
--sysroot=/opt/cross/sh4-linux   -o libmudflap.la -rpath 
/opt/cross/lib/gcc/sh4-linux/4.1.2 -version-info `grep -v '^#' 
../../../libmudflap/libtool-version` mf-runtime.lo mf-heuristics.lo 
mf-hooks1.lo mf-hooks2.lo  -ldl
/usr/src/packages/BUILD/gcc-4.1.2-20060731/obj-i586-suse-linux/./gcc/xgcc 
-B/usr/src/packages/BUILD/gcc-4.1.2-20060731/obj-i586-suse-linux/./gcc/ 
-B/opt/cross/sh4-linux/bin/ -B/opt/cross/sh4-linux/lib/ -isystem 
/opt/cross/sh4-linux/include
-isystem /opt/cross/sh4-linux/sys-include -shared  .libs/mf-runtime.o 
.libs/mf-heuristics.o .libs/mf-hooks1.o .libs/mf-hooks2.o  -ldl  
-Wl,-soname -Wl,libmudflap.so.0 -o .libs/libmudflap.so.0.0.0
/opt/cross/bin/sh4-linux-ld: crti.o: No such file: No such file or 
directory
collect2: ld returned 1 exit status
make[4]: *** [libmudflap.la] Error 1

Is there a recommended way to either fix libtool or libmudflap?

Thanks,
Richard.
(Continue reading)

Marcelo Slomp | 1 Sep 2006 14:27

gcc 4.2.0-20060826 - successful build and install - i386-pc-mingw32 (msys at a WinXP box)

Follows the build info:

config.guess:
i386-pc-mingw32

$ gcc -v
Using built-in specs.
Target: mingw32
Configured with: ../../source/gcc-4.2-20060826/configure --prefix=/mingw --host=mingw32
--target=mingw32 --program-prefix="" --with-as=/mingw/bin/as.exe --with-ld=/mingw/bin/ld.exe
--with-gcc --with-gnu-ld --with-gnu-as --enable-threads --disable-nls --enable-languages=c,c++
--disable-win32-registry --disable-shared --without-x --enable-interpreter
--enable-hash-synchronization --enable-libstdcxx-debug
Thread model: win32
gcc version 4.2.0 20060826 (experimental)

$ uname -a
MINGW32_NT-5.1 THERGOTHON 1.0.10(0.46/3/2) 2004-03-15 07:17 i686 unknown

host system: WinXP Pro SP2 i686

/me: Marcelo A B Slomp - Brazil

--

-- 
__________________________________________________
Now you can search for products and services
http://search.mail.com

Powered by Outblaze

(Continue reading)

Daniel Jacobowitz | 1 Sep 2006 14:31

Re: First cut on outputing gimple for LTO using DWARF3. Discussion invited!!!!

On Thu, Aug 31, 2006 at 04:00:25PM -0700, Mark Mitchell wrote:
> I think this is probably moot, since I believe that Kenny feels DWARF is 
> not suitable for reasons other than the abbreviation table issue, but 
> this is a clever technique.

... for GIMPLE; when I discussed with him, I got the impression he was
still open to using it for other things, like types.  I may have been
mistaken.

--

-- 
Daniel Jacobowitz
CodeSourcery

Rohit Arul Raj | 1 Sep 2006 15:31
Picon

Modifying the LABEL for functions emitted by the GCC Compiler

Hello Everyone,

I am trying to link the object file emitted by a Cross Compiler IDE
with the GCC Coldfire Linker and its libraries.
The Problem that i faced was:

The  gcc-coldfire compiler spits out the labels as it is in the
assembly file (main, printf etc), where  as the IDE compiler spits out
the labels prefixed with a  '_' (_main, _printf etc).

Is there any way  i can  make gcc-coldfire compiler emit  the lables
prefixed with an underscore (' _ ').Can anyone Help me OUT of this
mess!!!

Thanks in Advance,
Rohit

Kenneth Zadeck | 1 Sep 2006 15:45

Re: First cut on outputing gimple for LTO using DWARF3. Discussion invited!!!!

Daniel Jacobowitz wrote:
> On Thu, Aug 31, 2006 at 04:00:25PM -0700, Mark Mitchell wrote:
>   
>> I think this is probably moot, since I believe that Kenny feels DWARF is 
>> not suitable for reasons other than the abbreviation table issue, but 
>> this is a clever technique.
>>     
>
> ... for GIMPLE; when I discussed with him, I got the impression he was
> still open to using it for other things, like types.  I may have been
> mistaken.
>
>   
Given that Mark, and for that matter no one else,  did not really push
back, I am pretty much committed not to use dwarf.

Kenny

Tim Prince | 1 Sep 2006 15:51
Picon
Favicon

Re: Modifying the LABEL for functions emitted by the GCC Compiler

Rohit Arul Raj wrote:

> 
> The  gcc-coldfire compiler spits out the labels as it is in the
> assembly file (main, printf etc), where  as the IDE compiler spits out
> the labels prefixed with a  '_' (_main, _printf etc).
> 
> Is there any way  i can  make gcc-coldfire compiler emit  the lables
> prefixed with an underscore (' _ ').Can anyone Help me OUT of this
> mess!!!
> 
How about reconciling the -fleading-underscore options?

Diego Novillo | 1 Sep 2006 15:51
Picon
Favicon

Re: First cut on outputing gimple for LTO using DWARF3. Discussion invited!!!!

Kenneth Zadeck wrote on 08/28/06 09:57:

> I have not done this because I do not rule the earth.  That was not
> what I was assigned to do, and I agreed that DWARF3 sounded like a
> reasonable way to go.  Now that I understand the details of DWARF3, I
> have changed my mind about the correct direction.  Now is the time to
> make that change before there is a lot of infrastructure built that
> assumes the DWARF3 encoding.
> 
FWIW.  I agree with your conclusion.  I do not know DWARF3 very well,
but it always felt a bit heavy handed to me.

At first, I was under the impression that we were going to use DWARF3 to
describe the types and symbol table, and embed our bytecode alongside.
It sounds to me like we want to either invent our own bytecode or adapt
an existing one to our needs.  Inventing our own is probably the best
long-term alternative.

A few comments on the code:

> Index: lto-tree-flags.def
> [ ... ]
> +/* This file is designed to be inlined into both the writing and the
> +   reading of the lto information.  What it does depends on the glue
> +   that put in front and at the end of this and how ADD_BASE_FLAG is
> +   defined. 
> +
> +   For those interested in extra credit, this could also be used as
> +   the checking code to see if each flag is used correctly.  10 extra
> +   credit points will be given for the intrepid programmer who does
(Continue reading)


Gmane