Re: Segfault on OpenMP program
On Wed, Apr 18, 2007 at 07:38:40PM +0200, Kenneth Hoste wrote: > Is this only advised with parallel programs, or is it a general rule? > In my research, I statically link all my benchmarks because that I > measure stuff about them using instrumentation on a bunch of computer > (which might have various OSs, OS versions, libc versions, ...). > Because we want to analyze the same dynamic executed code over and > over again (no matter on which machine the analysis is donne), I use > static linking. General rule. Statically linked programs are actually far more dependent on the environment they are compiled in rather than less dependent, please read e.g. http://people.redhat.com/drepper/no_static_linking.html > - How can I easily dynamically link against libc, but statically link > with everything else? Currently, making everything statically linked > is easy: in the various makefiles I set CC="gcc -static". Is there a > similar 'trick' to link libc dynamically but everything else > statically? (I'm using GCC 4.1.2 if it matters) The libraries which you want to link statically into the application just mention between -Wl,-Bstatic ... -Wl,-Bdynamic on the command line. So say gcc -o foo . -Wl,-Bstatic -lfoo -lbar -lbaz -Wl,-Bdynamic -ldl -lpthread will link libfoo, libbar and libbaz into the application and libdl, libpthread, libc dynamically. Jakub
Re: HTML of -fdump-tree-XXXX proposal.
J.C. Pizarro wrote: In the attachment there is a quick&dirty alpha patch that i don't known why the gcc compiler says "gcc: unrecognized option '-html'". ??? I don't known where to modify the gcc code to add an option. The XHTML format to fputs is a little bad. There are examples to test too. The idea is to filter the output stream. I think it makes a lot more sense to implement this as a standalone filter for the output stream, which takes the files that contain the current dump-tree output and converts it to HTML. You don't lose any functionality by doing that, and there's no compelling reason for adding the extra complexity to the tree-dumpers themselves if we don't need to. Certainly it can be a useful idea to have more ways of viewing the dump files than just reading the plaintext in a text editor, but it seems more sensible to me to consider the plaintext-to-HTML conversion as an aspect of a standalone "viewer" system, rather than as an aspect of the compiler. - Brooks
Can I have a more detailed documentation about gcc 4.1.2 frontend?
Can I have gcc 4.1.2 frontend internal documentation? I am a graduated student and major in Computer Engineering. I need more detailed imformation about gcc 4.1.2 frontend (C frontend) for academical reason. The documantation includes information about internal tree representation especially abstract syntax tree, tree nodes information, tree operations, and more detailed information at gcc frontend.
RE: HTML of -fdump-tree-XXXX proposal.
On 19 April 2007 08:47, Brooks Moses wrote: > J.C. Pizarro wrote: >> In the attachment there is a quick&dirty alpha patch that i don't known >> why the gcc compiler says "gcc: unrecognized option '-html'". ??? >> I don't known where to modify the gcc code to add an option. >> >> The XHTML format to fputs is a little bad. >> >> There are examples to test too. >> >> The idea is to filter the output stream. > > I think it makes a lot more sense to implement this as a standalone > filter for the output stream, which takes the files that contain the > current dump-tree output and converts it to HTML. You don't lose any > functionality by doing that, and there's no compelling reason for adding > the extra complexity to the tree-dumpers themselves if we don't need to. > > Certainly it can be a useful idea to have more ways of viewing the dump > files than just reading the plaintext in a text editor, but it seems > more sensible to me to consider the plaintext-to-HTML conversion as an > aspect of a standalone "viewer" system, rather than as an aspect of the > compiler. I agree. It would fit nicely as a script in the contrib/ directory. cheers, DaveK -- Can't think of a witty .sigline today
RE: Can I have a more detailed documentation about gcc 4.1.2 frontend?
On 19 April 2007 09:13, ??? wrote: > Can I have gcc 4.1.2 frontend internal documentation? I am a graduated > student and major in Computer Engineering. I need more detailed > imformation about gcc 4.1.2 frontend (C frontend) for academical reason. > The documantation includes information about internal tree > representation especially abstract syntax tree, tree nodes information, > tree operations, and more detailed information at gcc frontend. If you have the compiler installed, you already have the documentation. Run "info gccint". Otherwise, it's online at http://gcc.gnu.org/onlinedocs/ although that refers to current mainline rather than 4.1.2 specifically. See also http://gcc.gnu.org/readings.html which has some links to other docs about the frontends. cheers, DaveK -- Can't think of a witty .sigline today
The Linux binutils 2.17.50.0.15 is released
This is the beta release of binutils 2.17.50.0.15 for Linux, which is
based on binutils 2007 0418 in CVS on sourceware.org plus various
changes. It is purely for Linux.
All relevant patches in patches have been applied to the source tree.
You can take a look at patches/README to see what have been applied and
in what order they have been applied.
Starting from the 2.17.50.0.4 release, the default output section LMA
(load memory address) has changed for allocatable sections from being
equal to VMA (virtual memory address), to keeping the difference between
LMA and VMA the same as the previous output section in the same region.
For
.data.init_task : { *(.data.init_task) }
LMA of .data.init_task section is equal to its VMA with the old linker.
With the new linker, it depends on the previous output section. You
can use
.data.init_task : AT (ADDR(.data.init_task)) { *(.data.init_task) }
to ensure that LMA of .data.init_task section is always equal to its
VMA. The linker script in the older 2.6 x86-64 kernel depends on the
old behavior. You can add AT (ADDR(section)) to force LMA of
.data.init_task section equal to its VMA. It will work with both old
and new linkers. The x86-64 kernel linker script in kernel 2.6.13 and
above is OK.
The new x86_64 assembler no longer accepts
monitor %eax,%ecx,%edx
You should use
monitor %rax,%ecx,%edx
or
monitor
which works with both old and new x86_64 assemblers. They should
generate the same opcode.
The new i386/x86_64 assemblers no longer accept instructions for moving
between a segment register and a 32bit memory location, i.e.,
movl (%eax),%ds
movl %ds,(%eax)
To generate instructions for moving between a segment register and a
16bit memory location without the 16bit operand size prefix, 0x66,
mov (%eax),%ds
mov %ds,(%eax)
should be used. It will work with both new and old assemblers. The
assembler starting from 2.16.90.0.1 will also support
movw (%eax),%ds
movw %ds,(%eax)
without the 0x66 prefix. Patches for 2.4 and 2.6 Linux kernels are
available at
http://www.kernel.org/pub/linux/devel/binutils/linux-2.4-seg-4.patch
http://www.kernel.org/pub/linux/devel/binutils/linux-2.6-seg-5.patch
The ia64 assembler is now defaulted to tune for Itanium 2 processors.
To build a kernel for Itanium 1 processors, you will need to add
ifeq ($(CONFIG_ITANIUM),y)
CFLAGS += -Wa,-mtune=itanium1
AFLAGS += -Wa,-mtune=itanium1
endif
to arch/ia64/Makefile in your kernel source tree.
Please report any bugs related to binutils 2.17.50.0.15 to [EMAIL PROTECTED]
and
http://www.sourceware.org/bugzilla/
Changes from binutils 2.17.50.0.14:
1. Update from binutils 2007 0418.
2. Support Intel SSE4 instructions.
3. Fix linker --fatal-warnings for --warn-shared-textrel. PR 4304.
4. Improve linker error message to identify linker script error
location. PR 4090.
5. Fix objcopy to allow removing all sections. PR 4348.
6. Don't print addresses of 32-bit targets as 64-bit values on 64bit
host. PR 4292.
7. Improve checking for corrupted input files. PR 4110.
8. Improve alpha linker performance.
9. Add a new linker option, -l:foo.
10. Fix a PPC linker bug. PR 4267.
11. Misc vxworks bug fixes.
12. Misc SH bug fixes.
13. Misc SPU bug fixes.
14. Misc ARM bug fixes.
15. Misc MIPS bug fixes.
16. Misc xtensa bug fixes.
Changes from binutils 2.17.50.0.13:
1. Update from binutils 2007 0322.
2. Fix >16byte nop padding regression in x86 assembler.
3. Fix x86-64 disassembler for xchg. PR 4218.
4. Optimize opcode for x86-64 xchg.
5. Allow register operand with x86 nop.
6. Properly handle holes between sections for PE-COFF. PR 4210.
7. Print more PE-COFF info for objdump -p.
8. Report missing matching LO16 relocation for HI16 relocation in mips
linker.
9. Use PC-relative relocation for Win64.
10. Fix strip for Solaris. PR 3535.
11. Fix a C++ demangler crash.
12. Some m32c update.
13. Fix misc ARM bugs.
Changes from binutils 2.17.50.0.12:
1. Update from binutils 2007 0315.
2. Add EFI/x86-64 support.
3. Fix ELF linker for relocation against STN_UNDEF. PR 3958.
4. Fix ELF linker for SHT_NOBITS section whose VMA > page size. PR 4144.
5. Make assembler and disassembler consistent for "test %eax,%ebx". PR
4027.
6. Fix i386 32bit address wraparound. PR 3966.
7. Allow Linux/i386 linker to read FreeBSD/i386 object files.
8. Fix ELF linker crash upon use of .gnu.warning. sections. PR
3953.
9. Fix ELF linker to issue an error on bad section in segment. PR 4007.
10. Support enabling both x86_64-mingw32 and i386-mingw32. PR 3945.
11. Fix assembler to stabilize .gcc_except_table relaxation. PR 4029.
12. Fix a MIPS linker crash. PR 3852.
13. Fix readelf for h8300-elf. PR 3800.
14. Fix strip for Solaris. PR 3535.
15. Misc xtensa bug fixes.
16. Misc PPC bug fixes.
17. Misc SPU bug fixes.
18. Add support for Toshiba MeP.
Changes from binutils 2.17.50.0.11:
1. Update from binutils 2007 0128.
2. Remove duplicate code in x86 ass
Re: HTML of -fdump-tree-XXXX proposal.
2007/4/19, Brooks Moses <[EMAIL PROTECTED]> wrote: I think it makes a lot more sense to implement this as a standalone filter for the output stream, which takes the files that contain the current dump-tree output and converts it to HTML. You don't lose any functionality by doing that, and there's no compelling reason for adding the extra complexity to the tree-dumpers themselves if we don't need to. Certainly it can be a useful idea to have more ways of viewing the dump files than just reading the plaintext in a text editor, but it seems more sensible to me to consider the plaintext-to-HTML conversion as an aspect of a standalone "viewer" system, rather than as an aspect of the compiler. - Brooks I'm agree. A script that does the plaintext-to-HTML conversion is far better than modifying the complex GCC compiler i'd made fatally it. :)
why no $pc offset in debug CFA?
In dwarf2out.c : dwarf2out_frame_init we have this code: #ifdef DWARF2_UNWIND_INFO if (DWARF2_UNWIND_INFO) initial_return_save (INCOMING_RETURN_ADDR_RTX); #endif However, gdb really needs that slot to unwind stack frames when debugging, on targets that don't use dwarf2 unwinding (i.e. cygwin with -gdwarf-2, and some embedded targets that still use sjlj). Why don't we unconditionally emit this?
Re: why no $pc offset in debug CFA?
> In dwarf2out.c : dwarf2out_frame_init we have this code: > > #ifdef DWARF2_UNWIND_INFO > if (DWARF2_UNWIND_INFO) > initial_return_save (INCOMING_RETURN_ADDR_RTX); > #endif > > However, gdb really needs that slot to unwind stack frames when > debugging, on targets that don't use dwarf2 unwinding (i.e. cygwin > with -gdwarf-2, and some embedded targets that still use sjlj). Why > don't we unconditionally emit this? We ran into this problem recently too. I think that the correct predicate is #ifdef DWARF2_UNWIND_INFO if (DWARF2_UNWIND_INFO || DWARF2_FRAME_INFO) initial_return_save (INCOMING_RETURN_ADDR_RTX); #endif -- Eric Botcazou
Re: why no $pc offset in debug CFA?
On Thu, Apr 19, 2007 at 03:30:03PM -0400, DJ Delorie wrote: > Why don't we unconditionally emit this? No idea. r~
Problem building gcc on Cygwin
I'm having problems building gcc (c,c++, and FORTRAN compilers chosen) under Cygwin. I downloaded gcc-4.1.2.tar.gz. I gunzipped it to a directory, and untarred that. I created a subdirectory obj and changed to that directory. (All this from within Cygwin.) I ran ../gcc/configure -enable-languages=c,c++,fortran. This ran successfully. I then attempted to build the compilers using: make CFLAGS='-O' LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2 -fno-implicit-templates' bootstrap Here's most of the output - it fails trying to build libiberty.a. Note that there is no directory ../build-i686-pc-cygwin/ in my system. I suppose configure has made a mistake somewhere in expecting to find such a directory. I'd appreciate any suggestions or ideas on who to ask!! --- make[1]: Entering directory `/cygdrive/c/gcc-4.1.2/obj' TARGET_CPU_DEFAULT="" \ HEADERS="auto-host.h ansidecl.h config/i386/xm-cygwin.h" DEFINES="" \ /bin/sh ../gcc/mkconfig.sh config.h TARGET_CPU_DEFAULT="" \ HEADERS="options.h config/i386/i386.h config/i386/unix.h config/i386/bsd .h config/i386/gas.h config/dbxcoff.h config/i386/cygming.h config/i386/cygwin.h defaults.h" DEFINES="" \ /bin/sh ../gcc/mkconfig.sh tm.h gawk -f ../gcc/opt-gather.awk ../gcc/fortran/lang.opt ../gcc/c.opt ../gcc/common .opt ../gcc/config/i386/i386.opt ../gcc/config/i386/cygming.opt > tmp-optionlist /bin/sh ../gcc/../move-if-change tmp-optionlist optionlist echo timestamp > s-options gawk -f ../gcc/opt-functions.awk -f ../gcc/opth-gen.awk \ < optionlist > tmp-options.h /bin/sh ../gcc/../move-if-change tmp-options.h options.h echo timestamp > s-options-h TARGET_CPU_DEFAULT="" \ HEADERS="auto-host.h ansidecl.h config/i386/xm-cygwin.h" DEFINES="" \ /bin/sh ../gcc/mkconfig.sh bconfig.h gcc -c -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC -W -Wall -Wwr ite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmi ssing-format-attribute-DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../gcc -I../gcc/build -I../gcc/../include -I../gcc/../libcpp/include -o build/genmo des.o ../gcc/genmodes.c gcc -c -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC -W -Wall -Wwr ite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmi ssing-format-attribute-DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../gcc -I../gcc/build -I../gcc/../include -I../gcc/../libcpp/include -o build/error s.o ../gcc/errors.c make[1]: *** No rule to make target `../build-i686-pc-cygwin/libiberty/libiberty .a', needed by `build/genmodes.exe'. Stop. make[1]: Leaving directory `/cygdrive/c/gcc-4.1.2/obj' make: *** [stage1_build] Error 2
Re: Problem building gcc on Cygwin
Tom Dickens wrote: > make CFLAGS='-O' LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2 > -fno-implicit-templates' bootstrap I don't know if 4.1.2 includes the toplevel bootstrap changes or not (it's kind of old), but I don't think you should be doing "make bootstrap". The new method is to either configure with --enable-bootstrap (default for native) or --disable-bootstrap and then just "make". Specifically, configuring with --disable-bootstrap and then trying to do "make bootstrap" will fail. So just use "make". Is there a page on gcc.gnu.org somewhere that tells you to use the above command? If so it should be changed. Brian
GCC mini-summit
We held a GCC mini-summit at Google on Wednesday, April 18. About 40 people came. This is my very brief summary of what we talked about. Corrections and additions very welcome. The goal of the mini-summit was just to let gcc developers meet face to face and talk. There was no goal of actually making any decisions, and, indeed, no decisions were made. If you comment on some particular item here, I'd like to suggest that you change the Subject line so that conversations can be tracked more easily. I didn't do a good job of recording who said what. And indeed most of this is from memory. I apologize for any mistakes or slights. They are entirely unintentional. 1) Introductions. 2) A phone call with Uday Khedker and other gcc developers in India from IIT Bombay in Mumbai. David Edelsohn arranged for this to happen. The call had to be from another room, and I didn't participate, so I don't have any details. 3) A discussion of gcc 4.2 and the gcc release process in general. Nobody objected to shipping gcc 4.2 today, even though it does not meet the goal of fewer than 100 regressions from an earlier release. People did comment that we should fix all the P1 bugs before shipping. We count regressions from any old release. That means that we have open bugs which were regressions in 3.x, but we are still counting them as release-blocking regressions. There were a few suggestions about how to avoid this: a) only count regressions from the last two releases. b) discount old regressions over time, perhaps by lowering their priority. c) add voting to bugzilla for which old regressions should count as release-blocking. Somebody suggested using the number of e-mail addresses CC'ed on the bug as votes. d) some people commented that this was a good thing, since it encourages us to fix old regressions, and that we should not avoid it at all. Somebody observed that our focus on regressions can cause us to ignore important wrong-code bugs which should be fixed even if they are not actually regressions--perhaps they are bugs in new features which were not present in earlier versions. 4) A discussion of dataflow. Ken Zadeck described the current state of dataflow branch. It seems stable, and just about within the compilation time guidelines set by the SC. He will do more testing and retesting this weekend, and hopes to commit it to mainline quite soon, maybe as early as next week if the testing goes well. 5) A discussion of tuples, the IR, and LTO. Diego Novillo described the tuples proposal, which is an incremental change to the IR. Ken Zadeck described the current state of his LTO work. He described LTO as having three parts: writing out types, which is being done in DWARF; serializing trees; eliminating langhooks. Discussion about writing out types in DWARF, since apparently several new DWARF attributes had to be invented to capture everything that gcc cares about. Michael Eager pointed out that if the new attributes would be of use for the debugger, he and the DWARF standardization committee would like to hear about them. Discussion of LTO and IMA; Geoff Keating said that if LTO works better than IMA, IMA should be removed. There was some concern that LTO would be slower than IMA, since in some ways it has to do more work, since the trees have to be written out and read in; however, in other ways it does less work. Discussion of a middle-end type system. Daniel Berlin said that it wasn't clear that we really needed a type system. He proposed that the middle-end use structural equivalence for the type system, and that front-ends annotate types which appear the same but are not. Interestingly, the types_compatible_p langhook is only used for C and C++ at present. People talked about the consequences for debugging information, with no clear outcome. Frontends would have to annotate types with their alias set in order for TBAA to work properly. 6) Lunch at the main Google cafeteria. 7) Daniel Berlin described the most recent draft of GPLv3. His conclusion is that, unlike earlier drafts, it is not substantially different from GPLv2. There was a fair amount of discussion. In particular there was some concern about the libgcc exception license, and whether that could ever go away. The general feeling was that that was unlikely. 8) A discussion of register allocation. This didn't go too far as none of the people working on register allocation were there. Diego Novillo briefly described Vlad Makarov's work and mentioned Andrew MacLeod's work. David Edelsohn mentioned Peter Bergner's work. There was some discussion of eliminating reload as the first step, and of taking pieces out of reload as the first incremental step. 9) A discussion of maintainership and code review. We discussed the
