genattrtab segfault on RH 7.3 (powerpc cross)
Hello all, I'm building a powerpc cross of gcc-4.2.2 on RH 7.2 host and ran into this: -> gdb build/genattrtab.orig core.20423 GNU gdb Red Hat Linux (5.2-2) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... warning: core file may not match specified executable file. Core was generated by `build/genattrtab ../../gcc/config/rs6000/rs6000.md insn-conditions.md'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/i686/libc.so.6...done. Loaded symbols for /lib/i686/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 #0 attr_rtx_1 (code=AND, p=0xbfffe3d4) at ../../gcc/genattrtab.c:409 409 if (h->hashcode == hashcode Breakpoint 1 at 0x8054d45: file ../../gcc/errors.c, line 132. Breakpoint 2 at 0x8054cac: file ../../gcc/errors.c, line 96. Breakpoint 3 at 0x4202bbea Breakpoint 4 at 0x4202a758 (gdb) p h $1 = (struct attr_hash *) 0x9036 (gdb) p *h Cannot access memory at address 0x9036 (gdb) l 404 return rt_val; 405 } 406 407 hashcode = ((HOST_WIDE_INT) code + RTL_HASH (arg0) + RTL_HASH (arg1)); 408 for (h = attr_hash_table[hashcode % RTL_HASH_SIZE]; h; h = h->next) 409 if (h->hashcode == hashcode 410 && GET_CODE (h->u.rtl) == code 411 && XEXP (h->u.rtl, 0) == arg0 412 && XEXP (h->u.rtl, 1) == arg1) 413 return h->u.rtl; (gdb) Host compiler details: -> gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs gcc version 2.96 2731 (Red Hat Linux 7.3 2.96-113) The bug is very hardly reproducable; on FC6 I was unable to reproduce after running test loop overnight. Has anyone seen this before? I see that by design it is impossible for h->next to point to outside of valid entry. Currently, I'm running a loop with genattrtab linked with dmalloc. May be this will shed some light... Thanks for any help. Regards, Sergei
Re: How should _Decimal64 and _Decimal128 be aligned on stack?
> DFP is beyond i386 psABI. Gcc aligns _Decimal32 to 4 byte, _Decimal64 to 8 > bytes > and _Decimal128 to 16bytes. The question is what is the best alignment for > them > when passing to a functions. The original work I did for the x86-64 backend placed them at that alignment because that is the required alignment for loading those values into SSE registers. Right? Ben
Re: How should _Decimal64 and _Decimal128 be aligned on stack?
On Sun, Mar 23, 2008 at 11:41:00PM +1100, Ben Elliston wrote: > > DFP is beyond i386 psABI. Gcc aligns _Decimal32 to 4 byte, _Decimal64 to 8 > > bytes > > and _Decimal128 to 16bytes. The question is what is the best alignment for > > them > > when passing to a functions. > > The original work I did for the x86-64 backend placed them at that > alignment because that is the required alignment for loading those > values into SSE registers. Right? That is a good question. For x86, _Decimal128 is passed on stack and aligned at 4 byte. For x86-64, _Decimal128 is passed in SSE registers. An implementation of _Decimal128 in 32bit may want to use SSE registers. H.J.
Re: [PATCH] linux/fs.h - Convert debug functions declared inline __attribute__((format (printf,x,y) to statement expression macros
On Friday 29 February 2008 02:09, Joe Perches wrote: > But the function place_entity doesn't use it directly or indirectly. > If the lines above are removed, the generated code for place_entity changes. I see it all the time. Whenever I add/remove/change something to a header, some functions grow a tiny bit, some shrink a bit. gcc 4.2.1. Report is here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29950 -- vda
http://gcc.gnu.org/onlinedocs/libstdc++/ needs a bit of help
Working on the link consistency of the http://gcc.gnu.org, I ran into a couple of links on the libstdc++ side that are in need of a bit love. It would be great could one of you libstdc++ guys look into those. http://gcc.gnu.org/onlinedocs/libstdc++/ext/parallel_mode.html * http://gcc.gnu.org/onlinedocs/libgomp --> trailing slash missing http://gcc.gnu.org/onlinedocs/libstdc++/parallel_mode.html * http://gcc.gnu.org/onlinedocs/libgomp --> trailing slash missing http://gcc.gnu.org/onlinedocs/libstdc++/faq.html * http://developer.kde.org/~sewardj/ --> now at http://valgrind.org/ http://gcc.gnu.org/onlinedocs/libstdc++/api.html * http://fsf.org/ -> http://www.fsf.org/ http://gcc.gnu.org/onlinedocs/libstdc++/faq.html * http://gcc.gnu.org/onlinedocs/17_intro/contribute.html * http://gcc.gnu.org/onlinedocs/18_support/howto.html * http://gcc.gnu.org/onlinedocs/19_diagnostics/howto.html * http://gcc.gnu.org/onlinedocs/21_strings/howto.html * http://gcc.gnu.org/onlinedocs/23_containers/howto.html * http://gcc.gnu.org/onlinedocs/debug.html * http://gcc.gnu.org/onlinedocs/ext/howto.html Thanks, Gerald
Re: ARM/Thumb function attribute
On Sat, Mar 22, 2008 at 8:24 PM, Paul Brook <[EMAIL PROTECTED]> wrote: > This list is for development of gcc, not gcc users. In future gcc-help, or > some other arm specific list is the correct place to ask such questions. I guess it wasn't clear that I'm requesting a new attribute. I want to force a call to be Thumb, or to be ARM. > The low bit of a function pointer value indicates thumbness. The caller > doesn't know or care whether it is calling an Arm or Thumb function. > > However note that > > > int __cdecl thread_create(...) > > This isn't a function pointer, it's an actual function declaration. Expect > this to break because (a) it's probably out of range of a branch instruction, > and (b) your linker defined symbol won't have the correct type. There is an existing attribute that I can use to deal with range. (longcall if I remember right) I will use this as required. I must do this anyway, since even my own code will reside in two separate chunks. My linker-defined symbol probably won't have much of a type at all. I'm asking for a way to make gcc ignore the type, and just call the symbol. Another way to solve the problem would be to have some way to make gcc emit the symbol, perhaps by an attribute that declares the address. So one of these would do: __attribute__((at(0x2718))) __attribute__((thumb)) (ideally both, so that I don't need to mess with the bits of Thumb code addresses)
Re: ARM/Thumb function attribute
On Sunday 23 March 2008, Albert Cahalan wrote: > On Sat, Mar 22, 2008 at 8:24 PM, Paul Brook <[EMAIL PROTECTED]> wrote: > > This list is for development of gcc, not gcc users. In future gcc-help, > > or some other arm specific list is the correct place to ask such > > questions. > > I guess it wasn't clear that I'm requesting a new attribute. > I want to force a call to be Thumb, or to be ARM. I think that's a bad idea. You should instead arrange for proper symbols to be created. Paul
Re: ARM/Thumb function attribute
On Sun, Mar 23, 2008 at 01:19:35PM -0400, Albert Cahalan wrote: > Another way to solve the problem would be to have > some way to make gcc emit the symbol, perhaps by > an attribute that declares the address. Just make it a longcall symbol. Either define it to be at 0x2718|1 in the linker script or create an assembly file that defines it as an absolute symbol with the low bit set, and it will act as Thumb. -- Daniel Jacobowitz CodeSourcery
Re: How to understand gcc source code?
On Sat, 2008-03-22 at 16:59 +0800, =?GB2312?B?wbqI0g==?= wrote: > But still, I cannot manage the source code of gcc. > I don't know how to start reading it. You can try: http://www.cfdvs.iitb.ac.in/~amv/gcc-int-docs/#gccdocs > Last night I want to read the code of symbol table used in gcc, I searched in > google, I greped in the source code. At last, I still have no idea > where those code is. AFAIK, GCC does not use conventional symbol table. Information about the "properties" of a symbol are in nodes of the AST. HTH, All the best. - amv -- +-+ | Abhijat M. Vichare | Email: [EMAIL PROTECTED] | |--|[EMAIL PROTECTED] | | CFDVS, IIT Powai,| WWW: http://cfdvs.iitb.ac.in/~amv | | Mumbai 400076, INDIA.|--| | | The truest perception of ignorance is at | |--| the summit of knowledge. | | Phone(Off):(22) 2576 8701| Keep climbing ... | +-+
[wwwdocs] Re: GCC 4.2.4 Status Report (2008-03-15)
On Sat, 15 Mar 2008, Joseph S. Myers wrote: > GCC 4.2.4 is due around 2008-04-02, so 4.2.4-rc1 should be built by > one of the release managers around 2008-03-26. And here is the set of web page updates I made based on this. develop.html: Add tentative date for GCC 4.2.4, use ISO dates for the GCC 4.2 series and adjust format to what we now have for GCC 4.3. index.html: Update GCC 4.2 status. Gerald Index: develop.html === RCS file: /cvs/gcc/wwwdocs/htdocs/develop.html,v retrieving revision 1.90 diff -u -3 -p -w -r1.90 develop.html --- develop.html22 Mar 2008 22:43:58 - 1.90 +++ develop.html23 Mar 2008 18:52:01 - @@ -373,18 +373,22 @@ stages of development, branch points, an | | +-- GCC 4.2 branch created --+ - |(Oct 20 2006)\ + | \ v v - GCC 4.3 Stage 1 (ends Jan 20 2007) GCC 4.2.0 release (May 13 2007) + GCC 4.3 Stage 1 (starts 2006-10-20) GCC 4.2.0 release (2007-05-13) |\ v v - GCC 4.3 Stage 2 (ends Sep 12 2007) GCC 4.2.1 release (Jul 18 2007) + GCC 4.3 Stage 2 (starts 2007-01-20) GCC 4.2.1 release (2007-07-18) | \ v v - GCC 4.3 Stage 3 GCC 4.2.2 release (Oct 7 2007) + GCC 4.3 Stage 3 (starts 2007-09-12) GCC 4.2.2 release (2007-10-07) + |\ + | v + | GCC 4.2.3 release (2008-02-01) |\ | v - | GCC 4.2.3 release (Feb 1 2008) + | GCC 4.2.4 release (2008-04-02) + | | +-- GCC 4.3 branch created --+ | \ ? TODO Index: index.html === RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v retrieving revision 1.654 diff -u -3 -p -r1.654 index.html --- index.html 22 Mar 2008 21:14:03 - 1.654 +++ index.html 23 Mar 2008 19:05:34 - @@ -120,7 +120,7 @@ annual report for 2008 GCC 4.2.3 Status: - http://gcc.gnu.org/ml/gcc/2008-02/msg00015.html";>2008-02-02 + http://gcc.gnu.org/ml/gcc/2008-03/msg00706.html";>2008-03-15 (regression fixes and docs only).
Re: http://gcc.gnu.org/onlinedocs/libstdc++/ needs a bit of help
Hi Gerald, Working on the link consistency of the http://gcc.gnu.org, I ran into a couple of links on the libstdc++ side that are in need of a bit love. It would be great could one of you libstdc++ guys look into those. Should be all fixed with the below, applied mainline and 4_3-branch. Thanks for the heads up! Paolo. /// 2008-03-23 Paolo Carlini <[EMAIL PROTECTED]> * doc/xml/faq.xml: Fix various links. * doc/xml/api.xml: Likewise. * doc/xml/manual/parallel_mode.xml: Likewise. * doc/html/faq.html: Regenerate. * doc/html/api.html: Likewise. * doc/html/manual/bk01pt12ch31s03.html: Likewise. Index: doc/xml/faq.xml === --- doc/xml/faq.xml (revision 133462) +++ doc/xml/faq.xml (working copy) @@ -130,8 +130,8 @@ -Here is a page devoted to -this topic. Subscribing to the mailing list (see above, or +Here is a page devoted to +this topic. Subscribing to the mailing list (see above, or the homepage) is a very good idea if you have something to contribute, or if you have spare time and want to help. Contributions don't have to be in the form of source code; @@ -400,7 +400,7 @@ If the only functions from libstdc++.a which you need are language support functions (those listed in - clause 18 of the + clause 18 of the standard, e.g., new and delete), then try linking against libsupc++.a, which is a subset of @@ -785,13 +785,13 @@ reason is that the state flags are not cleared on a successful call to open(). The standard unfortunately did not specify behavior in this case, and to everybody's great sorrow, -the proposed LWG resolution in - DR #22 is to leave the flags unchanged. You must insert a call +the proposed LWG resolution in + DR #22 is to leave the flags unchanged. You must insert a call to fs.clear() between the calls to close() and open(), and then everything will work like we all expect it to work. Update: for GCC 4.0 we implemented the resolution -of DR #409 and open() now calls -clear() on success! +of DR #409 and open() +now calls clear() on success! @@ -895,7 +895,7 @@ More information, including how to optionally enable/disable the checks, is available -here. +here. @@ -940,13 +940,13 @@ A few people have reported that the standard containers appear to leak memory when tested with memory checkers such as -http://developer.kde.org/~sewardj/";>valgrind. +http://valgrind.org/";>valgrind. The library's default allocators keep free memory in a pool for later reuse, rather than returning it to the OS. Although this memory is always reachable by the library and is never lost, memory debugging tools can report it as a leak. If you want to test the library for memory leaks please read -Tips for memory leak hunting +Tips for memory leak hunting first. @@ -961,7 +961,7 @@ See -the Containers +the Containers chapter. @@ -981,7 +981,7 @@ patches that covers the procedure, but for libstdc++ you should also send the patch to our mailing list in addition to the GCC patches mailing list. The libstdc++ -contributors' page +contributors' page also talks about how to submit patches. @@ -1237,8 +1237,8 @@ The copy will take O(n) time and the swap is constant time. -See Shrink-to-fit -strings for a similar solution for strings. +See Shrink-to-fit +strings for a similar solution for strings. Index: doc/xml/api.xml === --- doc/xml/api.xml (revision 133462) +++ doc/xml/api.xml (working copy) @@ -15,7 +15,7 @@ 2008 - http://fsf.org";>FSF + http://www.fsf.org/";>FSF Index: doc/xml/manual/parallel_mode.xml === --- doc/xml/manual/parallel_mode.xml(revision 133462) +++ doc/xml/manual/parallel_mode.xml(working copy) @@ -116,7 +116,7 @@ To use the libstdc++ parallel mode, compile your application with the compiler flag -D_GLIBCXX_PARALLEL -fopenmp. This - will link in libgomp, the GNU OpenMP http://gcc.gnu.org/onlinedocs/libgomp";>implementation, + will link in libgomp, the GNU OpenMP http://gcc.gnu.org/onlinedocs/libgomp/";>implementation, whose presence is mandatory. In addition, hardware capable of atomic operations is mandatory. Actually activating these atomic operations may require explicit compiler flags on some targets
Problems with builtin setjmp receiver getting eliminated - Help
I have real problems trying to get to the root of bug in
builtin_setjmp implementation and seek anyones wisdom on what I have
found and a way forward.
Sometimes it's not always clear which part is wrong - when presented
with mismatches.
I will post a bug report when I have got a little closer.
The problem I was looking at is the frame pointer being wrong on the AVR
target. (Stack and PC are ok)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21078 - but ANY
setjmp/longjump has the problem.
I traced this down to the handling of the frame pointer: by the receiver
- (which is the code the longjmp will jump back to)
Setjmp: - save pointer
Buf[0] = Virtual_stack_var
Longjmp: get pointer
Hard_Frame_pointer=buf[0]
Receiver: put back in frame pointer
Virtual_stack_var = Hard_Frame_pointer
The uniqueness on AVR is that Frame_pointer (and stack pointer) are 1
byte different from the first stack element. So the Virtual_stack_var is
1 different from the frame_pointer
i.e.
#define STACK_GROWS_DOWNWARD
#define STARTING_FRAME_OFFSET 1
#define STACK_POINTER_OFFSET 1
That's ok as this is recognized by instantiate_virtual_regs, which
makes the replacements later. In this case
Buf[0] = Frame_pointer+1
..
..
Frame_pointer = Virtual_stack_var - 1
However, what is happening is that an earlier pass noted in RTL dump
file "sibling" eliminates the receiver code block. So the frane point
is not reset correctly, and ends up being 1 out (which is bad). Other
targets may survive if they don't have offset between stack and pointers.
So where do I look to find out why this is happening? Does the RTL have
something missing or is the other pass not checking?
The RTL that gets eliminated is:
;; Start of basic block () -> 5
(code_label/s 13 12 14 5 4 "" [2 uses])
(note 14 13 15 5 [bb 5] NOTE_INSN_BASIC_BLOCK)
(insn 15 14 16 5 built-in-setjmp.c:17 (use (reg/f:HI 28 r28)) -1 (nil))
(insn 16 15 17 5 built-in-setjmp.c:17 (clobber (reg:HI 2 r2)) -1 (nil))
(insn 17 16 18 5 built-in-setjmp.c:17 (set (reg/f:HI 37 virtual-stack-vars)
(reg/f:HI 28 r28)) -1 (nil))
(insn 18 17 19 5 built-in-setjmp.c:17 (clobber (reg/f:HI 28 r28)) -1 (nil))
(insn 19 18 20 5 built-in-setjmp.c:17 (asm_input/v ("") 0) -1 (nil))
;; End of basic block 5 -> ( 6)
The second PROBLEM I noted is that gcc creates RTL for TWO receivers for
a setjmp. One is naturally from "expand_builtin_setjmp_receiver" but
there is then another one just after created by
"expand_nl_goto_receiver" in stmt.c- whats all this about?
Despite having two, both get optimised out!
Andy
Re: Problems with builtin setjmp receiver getting eliminated - Help
I have realised that part of the problem is that the receiver block has
no incoming edges so cfgcleanup removes it as unreachable block - right?
So any target that need a non trivial receiver for builtin_setjmp will
not work? That would mean any that have an offset between stack and
pointers?
I guess the same problem exists for non-local goto?
I am not convinced it could be this wrong. So please comment and suggest
solution - I'm sure I can write target handler but it seems so wrong to
leave this as issue open.
Andy
Andrew Hutchinson wrote:
I have real problems trying to get to the root of bug in
builtin_setjmp implementation and seek anyones wisdom on what I have
found and a way forward.
Sometimes it's not always clear which part is wrong - when presented
with mismatches.
I will post a bug report when I have got a little closer.
The problem I was looking at is the frame pointer being wrong on the
AVR target. (Stack and PC are ok)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21078 - but ANY
setjmp/longjump has the problem.
I traced this down to the handling of the frame pointer: by the
receiver - (which is the code the longjmp will jump back to)
Setjmp: - save pointer
Buf[0] = Virtual_stack_var
Longjmp: get pointer
Hard_Frame_pointer=buf[0]
Receiver: put back in frame pointer
Virtual_stack_var = Hard_Frame_pointer
The uniqueness on AVR is that Frame_pointer (and stack pointer) are 1
byte different from the first stack element. So the Virtual_stack_var
is 1 different from the frame_pointer
i.e.
#define STACK_GROWS_DOWNWARD
#define STARTING_FRAME_OFFSET 1
#define STACK_POINTER_OFFSET 1
That's ok as this is recognized by instantiate_virtual_regs, which
makes the replacements later. In this case
Buf[0] = Frame_pointer+1
..
..
Frame_pointer = Virtual_stack_var - 1
However, what is happening is that an earlier pass noted in RTL dump
file "sibling" eliminates the receiver code block. So the frane
point is not reset correctly, and ends up being 1 out (which is bad).
Other targets may survive if they don't have offset between stack and
pointers.
So where do I look to find out why this is happening? Does the RTL
have something missing or is the other pass not checking?
The RTL that gets eliminated is:
;; Start of basic block () -> 5
(code_label/s 13 12 14 5 4 "" [2 uses])
(note 14 13 15 5 [bb 5] NOTE_INSN_BASIC_BLOCK)
(insn 15 14 16 5 built-in-setjmp.c:17 (use (reg/f:HI 28 r28)) -1 (nil))
(insn 16 15 17 5 built-in-setjmp.c:17 (clobber (reg:HI 2 r2)) -1 (nil))
(insn 17 16 18 5 built-in-setjmp.c:17 (set (reg/f:HI 37
virtual-stack-vars)
(reg/f:HI 28 r28)) -1 (nil))
(insn 18 17 19 5 built-in-setjmp.c:17 (clobber (reg/f:HI 28 r28)) -1
(nil))
(insn 19 18 20 5 built-in-setjmp.c:17 (asm_input/v ("") 0) -1 (nil))
;; End of basic block 5 -> ( 6)
The second PROBLEM I noted is that gcc creates RTL for TWO receivers
for a setjmp. One is naturally from "expand_builtin_setjmp_receiver"
but there is then another one just after created by
"expand_nl_goto_receiver" in stmt.c- whats all this about?
Despite having two, both get optimised out!
Andy
Re: Problems with builtin setjmp receiver getting eliminated - Help
Andrew Hutchinson wrote: > I have realised that part of the problem is that the receiver block > has no incoming edges so cfgcleanup removes it as unreachable block - > right? > > So any target that need a non trivial receiver for builtin_setjmp will > not work? That would mean any that have an offset between stack and > pointers? > > I guess the same problem exists for non-local goto? > > I am not convinced it could be this wrong. So please comment and > suggest solution - I'm sure I can write target handler but it seems so > wrong to leave this as issue open. > MIPS uses an unspec_volatile in the nonloca_goto_receiver That keeps it from being removed. David Daney
