Re: GCC stack backtraces
On 08/29/2012 09:22 AM, Ian Lance Taylor wrote:
It uses the GCC unwind interface to collect a stack trace, and parses
DWARF debug info to get file/line/function information. (Of course it's
silly to write yet another DWARF reader, but I didn't find an existing
reader that seemed wholly suitable.) The code currently only works for
ELF/DWARF, but it's designed to support other object file and debug
formats should anybody care to write them. Since its use in GCC would
be purely for GCC developers, it's not essential that it be fully
portable.
Sorry for not actually testing the patch, but does it handle inline
functions? ("addr2line -i" can print multiple source locations for a
single stack frame.)
Support for /usr/lib/debug would be desirable, too.
--
Florian Weimer / Red Hat Product Security Team
Re: GCC stack backtraces
On 08/29/2012 08:40 PM, Toon Moene wrote: On 08/29/2012 06:21 PM, Ian Lance Taylor wrote: The DWARF reader calls malloc and is therefore not async-signal safe. It also is a problem if the crash in the program is due to overwriting the malloc heap administration (which easily occurs in Fortran if you overwrite bounds of allocatable arrays that can't be caught by bounds-check due to the wrong bounds being used inside a subroutine). I have had Fortran program tracebacks (as described by Janne) hanging due to this, which is hard to work around (euphemism). I've seen hanging processes because a custom SIGSEGV crash handler called malloc (indirectly from functions). If we could provide a more robust crash handler, I'm sure that would improve matters in the long term. The default std::unexpected handler for C++ could use this functionality as well, and so could Ada (but I'm not sure if you can get a callback when an unhandled exception is raised *before* the stack is unwound). -- Florian Weimer / Red Hat Product Security Team
Issues with Installing GCC-3.0.4 on SCO
Hi, I am having issues trying to install GCC (3.0.4) on SCO 5.0.7 i386. I downloaded gcc-3.0.4.tar.gz from "http://ftp.gnu.org/gnu/gcc/gcc-3.0.4/";, I then tried untarring the file, by: `gzip -dc gcc-3.0.4.tar.gz | tar xAvf - > file-list 2>&1` And that showed me a bunch of files, but no VOLS so I can use "scoadmin software" to install them. So I went into the "gcc-3.0.4" folder, and ran `./configure` and that generated some text: "Configuring for a i686-pc-sco3.2v5.0.7 host. *** This configuration is not supported in the following subdirectories: target-libffi target-boehm-gc target-zlib target-libjava (Any other directories should still work fine.) Created "Makefile" in /u/test/installgnu/gcc-3.0.4 using "mh-frag" ./configure: cc: not found *** The command 'cc -o conftest -g conftest.c' failed. *** You must set the environment variable CC to a working compiler." But is not much help when it fails. I can just go back to using an older version, "2.95.2pl", but that is missing lots of files which I need. Regards, Kevin Ross e. kevin.r...@afd.co.uk t. 01624 811711 f. 01624 817695 w. www.afd.co.uk
cxx-conversion a good idea?
Hi. The cxx-conversion idea does not come without its cons. The most important for us is that there will not be a plain gcc-core package that is smaller, builds faster a plain C compiler with a smaller binary and is able to bootstrap future versions of a plain C compiler made of the latest vesion of gcc. The con is recursive. The pros are two as far as i can see: 1) The C++ frontend will be put to the test in the bootstrap proccess. This one indeed has some value. 2) The gcc codebase can become cleaner and/or faster. This one is arguable and it would take some real numbers to prove the extra bootstrap time is worth it. Please note that i'm speaking as someone who is developing software that is strictly C (and many projects are like that, including python, perl, ffmpeg, linux-kernel, etc, etc) and i'm interested to get the latest gcc-core snapshot occassionaly to test both gcc and my software. And the explosion of the tarball size and bootstrap time lately is very discouraging. Given the fact that especially in the embedded world it's possible to have a perfectly working system based exclusively on C and a dynamic language, i think there should be a choice to be able to avoid the dependency of the C++ component in the compiler for those who want that. The ability to have this choice is a feature of gcc... Thanks, Nik
Re: cxx-conversion a good idea?
On 08/30/2012 01:43 PM, Nikos Fotoulis wrote: > The cxx-conversion idea does not come without its cons. The most > important for us is that there will not be a plain gcc-core package > that is smaller, builds faster a plain C compiler with a smaller > binary and is able to bootstrap future versions of a plain C > compiler made of the latest vesion of gcc. The con is recursive. > > The pros are two as far as i can see: > > 1) The C++ frontend will be put to the test in the bootstrap > proccess. This one indeed has some value. > > 2) The gcc codebase can become cleaner and/or faster. This one is > arguable and it would take some real numbers to prove the extra > bootstrap time is worth it. > > Please note that i'm speaking as someone who is developing software > that is strictly C (and many projects are like that, including > python, perl, ffmpeg, linux-kernel, etc, etc) and i'm interested to > get the latest gcc-core snapshot occassionaly to test both gcc and > my software. And the explosion of the tarball size and bootstrap > time lately is very discouraging. But, as a C developer, why do you care if GCC is written in C++? What difference will that make to you? Bear in mind that we have had the discussion about C++ conversion for a long time, and we have considered the pros and the cons, and we have made a decision. Andrew.
Re: cxx-conversion a good idea?
On 30 August 2012 13:43, Nikos Fotoulis wrote: > Hi. > > The cxx-conversion idea does not come without its > cons. The most important for us is that there will > not be a plain gcc-core package that is smaller, The GCC project doesn't make gcc-core tarballs any more anyway. Third-party packagers are still free to provide a separate package that doesn't include g++ and the C++ standard library headers, the language the code is written in doesn't greatly affect how the end result is packaged.
error when building trunk rev. 190799
Hello, I'm not sure about such errors should be reported, but I will try. Host compiler: gcc-4.7.1-MinGW-x86_64 x86_64-w64-mingw32-g++ -c -O2 -pipe -fomit-frame-pointer -momit-leaf-frame-pointer -DIN_GCC -fno-exceptions -fno-rtti -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -Igcc-trunk/gcc -Igcc-trunk/gcc/. -Igcc-trunk/gcc/../include -Igcc-trunk/gcc/../libcpp/include -I/mingw-gcc-trunk-libs-x64/include -I/mingw-gcc-trunk-libs-x64/include -I/mingw-gcc-trunk-libs-x64/include -Igcc-trunk/gcc/../libdecnumber -Igcc-trunk/gcc/../libdecnumber/bid -I../libdecnumber gcc-trunk/gcc/ggc-common.c -o ggc-common.o gcc-trunk/gcc/ggc-common.c: In function 'int gt_pch_note_object(void*, void*, gt_note_pointers, gt_types_enum)': gcc-trunk/gcc/ggc-common.c:326:49: error: cast from 'void*' to 'long int' loses precision [-fpermissive] gcc-trunk/gcc/ggc-common.c: In function 'void gt_pch_note_reorder(void*, void*, gt_handle_reorder)': gcc-trunk/gcc/ggc-common.c:359:44: error: cast from 'void*' to 'long int' loses precision [-fpermissive] gcc-trunk/gcc/ggc-common.c: In function 'hashval_t saving_htab_hash(const void*)': gcc-trunk/gcc/ggc-common.c:370:10: error: cast from 'void*' to 'long int' loses precision [-fpermissive] gcc-trunk/gcc/ggc-common.c: In function 'void relocate_ptrs(void*, void*)': gcc-trunk/gcc/ggc-common.c:443:45: error: cast from 'void*' to 'long int' loses precision [-fpermissive] gcc-trunk/gcc/ggc-common.c: In function 'void write_pch_globals(const ggc_root_tab* const*, traversal_state*)': gcc-trunk/gcc/ggc-common.c:472:42: error: cast from 'void*' to 'long int' loses precision [-fpermissive] make[2]: *** [ggc-common.o] Error 1 -- Regards, niXman ___ Dual-target(32 & 64 bit) MinGW compilers for 32 and 64 bit Windows: http://sourceforge.net/projects/mingwbuilds/
Re: Thoughts on Gengtype and Single Inheritance
On 08/27/2012 11:58 AM, Lawrence Crowl wrote: >> > I wonder if the second discriminator support is easily generalizable >> > to enabling any derived class being a root class on it own with its >> > own subtree? If I understand correctly, the GTY syntax would be the >> > same. > If I understand correctly, you are suggesting multiple inheritance > via enums. I think it is possible, but I think the tag syntax > would need to be changed to more directly associate the tag with > the variable. I understood Laurynas to be suggesting not multiple inheritance, but composition? r~
Re: Thoughts on Gengtype and Single Inheritance
On Thu, Aug 30, 2012 at 11:57 AM, Richard Henderson wrote: > On 08/27/2012 11:58 AM, Lawrence Crowl wrote: >>> > I wonder if the second discriminator support is easily generalizable >>> > to enabling any derived class being a root class on it own with its >>> > own subtree? If I understand correctly, the GTY syntax would be the >>> > same. >> If I understand correctly, you are suggesting multiple inheritance >> via enums. I think it is possible, but I think the tag syntax >> would need to be changed to more directly associate the tag with >> the variable. > > I understood Laurynas to be suggesting not multiple inheritance, > but composition? The coding convention recommends avoiding multiple inheritance, but it did not ban it altogether. I would be unfortunate that gengtype takes the step of banning it -- by effectively not supporting it. -- Gaby
Re: Thoughts on Gengtype and Single Inheritance
On 8/30/12, Richard Henderson wrote: > On 08/27/2012 11:58 AM, Lawrence Crowl wrote: >>> I wonder if the second discriminator support is easily generalizable >>> to enabling any derived class being a root class on it own with its >>> own subtree? If I understand correctly, the GTY syntax would be the >>> same. >> >> If I understand correctly, you are suggesting multiple inheritance >> via enums. I think it is possible, but I think the tag syntax >> would need to be changed to more directly associate the tag with >> the variable. > > I understood Laurynas to be suggesting not multiple inheritance, > but composition? But composition would not provide the additional space necessary for derivation, so there could be no tree under it. Perhaps an example would help. -- Lawrence Crowl
Re: Thoughts on Gengtype and Single Inheritance
On 8/30/12, Gabriel Dos Reis wrote: > On Aug 30, 2012 Richard Henderson wrote: > > On 08/27/2012 11:58 AM, Lawrence Crowl wrote: > > > > > I wonder if the second discriminator support is easily > > > > > generalizable to enabling any derived class being a root > > > > > class on it own with its own subtree? If I understand > > > > > correctly, the GTY syntax would be the same. > > > > > > If I understand correctly, you are suggesting multiple > > > inheritance via enums. I think it is possible, but I think > > > the tag syntax would need to be changed to more directly > > > associate the tag with the variable. > > > > I understood Laurynas to be suggesting not multiple inheritance, > > but composition? > > The coding convention recommends avoiding multiple inheritance, but > it did not ban it altogether. I would be unfortunate that gengtype > takes the step of banning it -- by effectively not supporting it. The present implementation need is for single inheritance. It would be reasonable to plan for eventual support of multiple inheritance. Do you have a suggestion for syntax to that end? -- Lawrence Crowl
Re: GCC stack backtraces
On Thu, Aug 30, 2012 at 1:04 AM, Florian Weimer wrote:
> On 08/29/2012 09:22 AM, Ian Lance Taylor wrote:
>
>> It uses the GCC unwind interface to collect a stack trace, and parses
>> DWARF debug info to get file/line/function information. (Of course it's
>> silly to write yet another DWARF reader, but I didn't find an existing
>> reader that seemed wholly suitable.) The code currently only works for
>> ELF/DWARF, but it's designed to support other object file and debug
>> formats should anybody care to write them. Since its use in GCC would
>> be purely for GCC developers, it's not essential that it be fully
>> portable.
>
>
> Sorry for not actually testing the patch, but does it handle inline
> functions? ("addr2line -i" can print multiple source locations for a single
> stack frame.)
Yes.
> Support for /usr/lib/debug would be desirable, too.
That is not there. I haven't looked into what this requires.
Ian
[RFC] gcc 4.8 vs glibc alias macros
Dunno if alpha is going to be the only glibc port to encounter this, if it
should be considered a gcc bug, or what.
Without this patch, using mainline gcc, I get
./../include/libc-symbols.h:485:26: error: ‘__EI___isnanf’ aliased to external
symbol ‘__GI___isnanf’
extern __typeof (name) __EI_##name \
^
./../include/libc-symbols.h:489:29: note: in expansion of macro '__hidden_ver1'
# define hidden_def(name) __hidden_ver1(__GI_##name, name, name);
^
../ports/sysdeps/alpha/fpu/s_isnan.c:48:1: note: in expansion of macro
'hidden_def'
hidden_def (__isnanf)
^
We get this because I chained aliases from __isnan to __isnanf to __GI___isnanf.
The patch works around this by defining both __isnanf and __GI___isnanf in
terms of the original __isnan.
This isn't 100% correct since the __GI___isnanf symbol gets defined in the
object file with visibility default, but it doesn't matter in practice because
the users of the symbol still see the hidden_proto and so when the symbols are
merged in the linker and link map applied, it acquires hidden visibility.
I'm looking for opinions as to whether (1) this is a gcc bug and (2) whether
the patch should be applied to glibc regardless.
r~
>From 9b0aca04145daf0d22d607e88d6fa2df8c49f11b Mon Sep 17 00:00:00 2001
From: Richard Henderson
Date: Thu, 30 Aug 2012 12:02:50 -0700
Subject: [PATCH] alpha: Work around gcc 4.8 aliasing difference/bug
---
ports/ChangeLog.alpha | 5 +
ports/sysdeps/alpha/fpu/s_isnan.c | 12 +---
2 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/ports/ChangeLog.alpha b/ports/ChangeLog.alpha
index 19edf6f..9589dd3 100644
--- a/ports/ChangeLog.alpha
+++ b/ports/ChangeLog.alpha
@@ -1,3 +1,8 @@
+2012-08-30 Richard Henderson
+
+ * sysdeps/alpha/fpu/s_isnan.c: Define all aliases in terms of
+ the original __isnan symbol.
+
2012-08-27 Mike Frysinger
[BZ #5400]
diff --git a/ports/sysdeps/alpha/fpu/s_isnan.c b/ports/sysdeps/alpha/fpu/s_isnan.c
index b18c7bb..1f239ac 100644
--- a/ports/sysdeps/alpha/fpu/s_isnan.c
+++ b/ports/sysdeps/alpha/fpu/s_isnan.c
@@ -28,11 +28,6 @@
#undef isnanf
#undef __GI___isnanf
-/* The hidden_proto in include/math.h was obscured by the macro hackery. */
-__typeof (__isnan) __isnanf;
-hidden_proto (__isnanf)
-
-
int
__isnan (double x)
{
@@ -45,8 +40,11 @@ weak_alias (__isnan, isnan)
/* It turns out that the 'double' version will also always work for
single-precision. */
strong_alias (__isnan, __isnanf)
-hidden_def (__isnanf)
-weak_alias (__isnanf, isnanf)
+weak_alias (__isnan, isnanf)
+
+/* ??? GCC 4.8 fails to look through chains of aliases with asm names
+ attached. Work around this for now. */
+hidden_ver (__isnan, __isnanf)
#ifdef NO_LONG_DOUBLE
strong_alias (__isnan, __isnanl)
--
1.7.11.4
Re: GCC stack backtraces
On 8/29/12, Gabriel Dos Reis wrote: > On Aug 29, 2012 Ian Lance Taylor wrote: > > Does this seem like something we could usefully add to GCC? > > Emphatically, yes!. Seconded! > Does anybody see any big problems with it? > > Can it would be a great addition to libstdc++ as a GNU extension, > stached in the namespace. > > I do also do like the fact that you're planning a BSD licence; > that means I can make use of it in my own projects. > > > The library is not quite ready to commit, but it's quite close. > > It just needs a bit more testing in uncommon build environments, > > i.e., anything other than x86_64 GNU/Linux, to make sure that > > it at least builds and does not crash even when it can't get > > a backtrace. > > Kudos for doing this. I am sure Diego would love it (when he > is back.) Diego already loves it! -- Lawrence Crowl
ANN: gcc-python-plugin 0.10
gcc-python-plugin is a plugin for GCC 4.6 onwards which embeds the CPython interpreter within GCC, allowing you to write new compiler warnings for C/C++ in Python, generate code visualizations, etc. It comes with "cpychecker": a tool for static analysis tool of CPython extensions. Tarball releases are available at: https://fedorahosted.org/releases/g/c/gcc-python-plugin/ Prebuilt-documentation can be seen at: http://readthedocs.org/docs/gcc-python-plugin/en/latest/index.html Project homepage: https://fedorahosted.org/gcc-python-plugin/ What's new in v0.10: * support for the to-be-released Python 3.3 (tested against latest release candidate) * better support for analysis of C++ code: the API provides support for walking the namespace tree, and the cpychecker code now supports methods, references, "this", destructors, etc * lots of bug fixes: the cpychecker code has been hardened by running it on all of the Python C extension code in Fedora 17, and in the process many internal bugs have been found and fixed - along with hundreds of bugs in the code being tested: http://fedoraproject.org/wiki/Features/StaticAnalysisOfPythonRefcounts * similarly, Daniele Varrazzo used the checker extensively on psycopg, the popular Python interface to PostgreSQL, and using it was able to find and fix numerous subtle errors: http://initd.org/psycopg/articles/2012/03/29/psycopg-245-released/ * an experimental new HTML visualization for error reports: http://fedorapeople.org/~dmalcolm/gcc-python-plugin/2012-03-19/example/example.html Thanks to Buck Golemon, Daniele Varrazzo, David Narvaez, Eevee, Jason Mueller, Kevin Pyle, Matt Rice and Tom Tromey for their contributions to this release. Enjoy! Dave
Merging Cilk Plus into GCC Trunk
Hello Everyone, The Cilk-Plus branch is feature-complete. Programs using Cilk Plus constructs get great performance on vector and multicore hardware. Programs that don't use the new language features (enabled by a -fcilkplus flag) see no change. For details please see http://cilkplus.org. It's time to promote the branch into mainline. Cilk Plus branch is stable and there is no unexpected failures with respect to the trunk in regression testsuites. Most of the changes are in the front and middle-end. Since it involves many changes, I plan to break it up into individual patches (listed below), each of which adds a new, complete capability. Later patches sometimes use the functionality added by the previous one. For example, Elemental functions for C++ will depend on some of the common routines used in C patch: 1. Elemental functions for C. 2. Regression tests for elemental functions for C. 3. Elemental functions for C++. 4. Regression tests for elemental functions for C++. 5. SIMD annotations for C. 6. Regression tests for SIMD annotations for C. 7. SIMD annotations for C++. 8. Regression tests for SIMD annotations for C++. 9. Array notations for C. 10. Regression tests for Array notations for C. 11. Array Notations for C++. 12. Regression tests for Array Notations for C++. 13. The Cilk Runtime library -- It is a separate directory without any changes to compiler source. 14. Cilk Keywords (_Cilk_spawn and _Cilk_sync) for C. 15. Regression tests _Cilk_spawn and _Cilk_sync for C. 16. Cilk Keywords (_Cilk_spawn and _Cilk_sync) for C++. 17. Regression tests _Cilk_spawn and _Cilk_sync for C++. 18. Cilk Keywords (_Cilk_for) for C. 19. _Cilk_for Regression tests for C. 20. Cilk Keywords (_Cilk_for) for C++. 21. _Cilk_for Regression tests for C++. 22. Documentation about Cilk Plus into GCC documents. If there is a more effective way to merge our changes to the trunk, I am open to suggestions. Thanking You, Yours Sincerely, Balaji V. Iyer.
[libstdc++] Mis-configure _GLIBCXX_LONG_DOUBLE_COMPAT?
I've seen this today both for alpha and s390 cross from x86_64: > libtool: compile: /home/rth/work/gcc/bld-s390/./gcc/xgcc -shared-libgcc > -B/home/rth/work/gcc/bld-s390/./gcc -nostdinc++ > -L/home/rth/work/gcc/bld-s390/s390x-linux/libstdc++-v3/src > -L/home/rth/work/gcc/bld-s390/s390x-linux/libstdc++-v3/src/.libs > -B/home/rth/work/gcc/run-cross/s390x-linux/bin/ > -B/home/rth/work/gcc/run-cross/s390x-linux/lib/ -isystem > /home/rth/work/gcc/run-cross/s390x-linux/include -isystem > /home/rth/work/gcc/run-cross/s390x-linux/sys-include > -I/home/rth/work/gcc/git-master/libstdc++-v3/../libgcc > -I/home/rth/work/gcc/bld-s390/s390x-linux/libstdc++-v3/include/s390x-linux > -I/home/rth/work/gcc/bld-s390/s390x-linux/libstdc++-v3/include > -I/home/rth/work/gcc/git-master/libstdc++-v3/libsupc++ > -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi > -fdiagnostics-show-location=once -ffunction-sections -fdata-sections > -frandom-seed=locale-inst.lo -g -O2 -D_GNU_SOURCE -c > ../../../../../git-master/libstdc++-v3/src/c++98/locale-inst.cc -fPIC -DPIC > -o loca! le-inst.o > ../../../../../git-master/libstdc++-v3/src/c++98/locale-inst.cc:362:8: error: > ‘void > _ZNKSt9money_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE9_M_insertILb1EEES3_S3_RSt8ios_basecRKSs()’ > aliased to undefined symbol > ‘_ZNKSt17__gnu_cxx_ldbl1289money_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE9_M_insertILb1EEES4_S4_RSt8ios_basecRKSs’ > > _ZNKSt9money_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE9_M_insertILb1EEES3_S3_RSt8ios_basecRKSs); > ^ > ../../../../../git-master/libstdc++-v3/src/c++98/locale-inst.cc:329:19: note: > in definition of macro '_GLIBCXX_LDBL_COMPAT' >extern "C" void ldbl (void) __attribute__ ((alias (#dbl), weak)) >^ > ../../../../../git-master/libstdc++-v3/src/c++98/locale-inst.cc:360:8: error: > ‘void > _ZNKSt9money_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE9_M_insertILb0EEES3_S3_RSt8ios_basecRKSs()’ > aliased to undefined symbol > ‘_ZNKSt17__gnu_cxx_ldbl1289money_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE9_M_insertILb0EEES4_S4_RSt8ios_basecRKSs’ > > _ZNKSt9money_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE9_M_insertILb0EEES3_S3_RSt8ios_basecRKSs); > ^ > ../../../../../git-master/libstdc++-v3/src/c++98/locale-inst.cc:329:19: note: > in definition of macro '_GLIBCXX_LDBL_COMPAT' >extern "C" void ldbl (void) __attribute__ ((alias (#dbl), weak)) >^ where, given that I've configured --with-long-double-128, appears to have mis-identified the correct setting of _GLIBCXX_LONG_DOUBLE_COMPAT. Is anyone else seeing this? Is this a problem for cross-compile only? Certainly editing config.h after the fact lets the build complete... r~
