lock-less containers?
Hi, Sorry if this is the wrong place to ask this, but I've heard about the Summer of Code project to create lock-less containers for use with GCC. What happened to that project? Is there code to download anywhere? Best regards, dm.n9107
Procedure to submit new port (CR16 processor)
Hello, I have a new port for CR16 (National Semiconductor's 16-bit processor) for submission. While I was searching the mail archives, I found following steps are required for submitting the patches to GCC: 1. Submit the patches for reviewing and approval to gcc-patches mailing list. After approval, it is eligible for checking into the GCC SVN repository. 2. Obtain a method of committing the patches to GCC repository. One of them is to acquire write permissions to at least the port specific portions of GCC SVN repository. After approval, the port maintainer can check in the port specific files. My GCC assignment/disclaimer process with the FSF is complete. It would be greatly appreciated, if someone can provide information about the following: a) Can the write permissions to port specific files can be obtained even before submitting the files? How to get GCC SVN write permissions? b) I would also like to maintain the CRX (National Semiconductor's 32-bit processor) port. What is the procedure to request transfer in maintainership of CRX port? If there is no such thing called "transfer of maintainership", then would it be possible to co-maintain the CRX port? Thanks in advance, Pompa - Pompapathi V Gadad CR Tool Chain Team National Semiconductor Corporation
Splitting function arguments.
Hello all, I am working for a private GCC target. The target has 4 registers, each 32 bits reserved for arguments. When passing arguments depending on the type of the argument either registers or stack + registers will be used Sometimes the arguments will be split between a memory location and the register.Consider the following function call fun(int k, long long j, long long m); In the above case k and j will be passed through registers and m will be passed through register and stack, as all the other registers are used by the arguments k and j. In this case compiler is splitting the values on its own. But due to the restriction placed by load/store operation for the target, the splitting has to be modified according to the target. Is there any target hook that will help me to do it? Or can i write a pattern in the md file that can be used for this purpose. Is there any other target that does similar to this? Thanks for your time, Regards, Shafi.
sparc-rtems4.7-gcc versus fpu
Hello,
I have downloaded sparc-rtems4.7 and would like to use it for a leon2 target
with fpu. I am puzzled on how the compiler inserts fpu instructions. My summary
is:
- The compiler does insert fpu instructions, if no fpu command line option is
given or if "-mhard-quad-float" is used.
- The compiler does not insert fpu instructions, if "-mfpu" or "-mhard-float"
is used.
Why?
Peter
__
Erweitern Sie FreeMail zu einem noch leistungsstärkeren E-Mail-Postfach!
Mehr Infos unter http://produkte.web.de/club/?mc=021131
$ sparc-rtems-gcc -v
Using built-in specs.
Target: sparc-rtems4.7
Configured with: ../gcc-4.1.1/configure --prefix=/opt/rtems-4.7
--bindir=/opt/rtems-4.7/bin --includedir=/opt/rtems-4.7/include
--libdir=/opt/rtems-4.7/lib --libexecdir=/opt/rtems-4.7/lib
--mandir=/opt/rtems-4.7/man --infodir=/opt/rtems-4.7/info
--datadir=/opt/rtems-4.7/share --build=i686-suse-linux-gnu
--host=i686-suse-linux-gnu --target=sparc-rtems4.7 --with-gnu-as --with-gnu-ld
--verbose --with-newlib --with-system-zlib --disable-nls
--without-included-gettext --disable-win32-registry
--enable-version-specific-runtime-libs --enable-threads --enable-languages=c,c++
Thread model: rtems
gcc version 4.1.1 (RTEMS gcc-4.1.1/newlib-1.15.0-9.suse10.2)
$ cat float.c
float square(float x)
{
return x * x;
}
$ sparc-rtems-gcc -mcpu=cypress -c float.c
$ sparc-rtems-objdump -d float.o
float.o: file format elf32-sparc
Disassembly of section .text:
:
0: 9d e3 bf 98 save %sp, -104, %sp
4: f0 27 a0 44 st %i0, [ %fp + 0x44 ]
8: d3 07 a0 44 ld [ %fp + 0x44 ], %f9
c: d1 07 a0 44 ld [ %fp + 0x44 ], %f8
10: 91 a2 49 28 fmuls %f9, %f8, %f8
14: 81 a0 00 28 fmovs %f8, %f0
18: 81 e8 00 00 restore
1c: 81 c3 e0 08 retl
20: 01 00 00 00 nop
$ sparc-rtems-gcc -mcpu=cypress -mfpu -c float.c
$ sparc-rtems-objdump -d float.o
float.o: file format elf32-sparc
Disassembly of section .text:
:
0: 9d e3 bf 98 save %sp, -104, %sp
4: f0 27 a0 44 st %i0, [ %fp + 0x44 ]
8: d0 07 a0 44 ld [ %fp + 0x44 ], %o0
c: d2 07 a0 44 ld [ %fp + 0x44 ], %o1
10: 40 00 00 00 call 10
14: 01 00 00 00 nop
18: 82 10 00 08 mov %o0, %g1
1c: b0 10 00 01 mov %g1, %i0
20: 81 e8 00 00 restore
24: 81 c3 e0 08 retl
28: 01 00 00 00 nop
$ sparc-rtems-gcc -mcpu=cypress -mhard-float -c float.c
$ sparc-rtems-objdump -d float.o
float.o: file format elf32-sparc
Disassembly of section .text:
:
0: 9d e3 bf 98 save %sp, -104, %sp
4: f0 27 a0 44 st %i0, [ %fp + 0x44 ]
8: d0 07 a0 44 ld [ %fp + 0x44 ], %o0
c: d2 07 a0 44 ld [ %fp + 0x44 ], %o1
10: 40 00 00 00 call 10
14: 01 00 00 00 nop
18: 82 10 00 08 mov %o0, %g1
1c: b0 10 00 01 mov %g1, %i0
20: 81 e8 00 00 restore
24: 81 c3 e0 08 retl
28: 01 00 00 00 nop
$ sparc-rtems-gcc -mcpu=cypress -mhard-quad-float -c float.c
$ sparc-rtems-objdump -d float.o
float.o: file format elf32-sparc
Disassembly of section .text:
:
0: 9d e3 bf 98 save %sp, -104, %sp
4: f0 27 a0 44 st %i0, [ %fp + 0x44 ]
8: d3 07 a0 44 ld [ %fp + 0x44 ], %f9
c: d1 07 a0 44 ld [ %fp + 0x44 ], %f8
10: 91 a2 49 28 fmuls %f9, %f8, %f8
14: 81 a0 00 28 fmovs %f8, %f0
18: 81 e8 00 00 restore
1c: 81 c3 e0 08 retl
20: 01 00 00 00 nop
Re: sparc-rtems4.7-gcc versus fpu
The gcc version used by RTEMS 4.7 is 4.1.1 with no patches in this area.
I duplicated this behavior with gcc 4.2.0. gcc 3.2.3 still generated FPU
instructions in his test case.
--joel
Peter A. Krauss wrote:
Hello,
I have downloaded sparc-rtems4.7 and would like to use it for a leon2 target
with fpu. I am puzzled on how the compiler inserts fpu instructions. My summary
is:
- The compiler does insert fpu instructions, if no fpu command line option is given or if
"-mhard-quad-float" is used.
- The compiler does not insert fpu instructions, if "-mfpu" or "-mhard-float"
is used.
Why?
Peter
__
Erweitern Sie FreeMail zu einem noch leistungsstärkeren E-Mail-Postfach!
Mehr Infos unter http://produkte.web.de/club/?mc=021131
$ sparc-rtems-gcc -v
Using built-in specs.
Target: sparc-rtems4.7
Configured with: ../gcc-4.1.1/configure --prefix=/opt/rtems-4.7
--bindir=/opt/rtems-4.7/bin --includedir=/opt/rtems-4.7/include
--libdir=/opt/rtems-4.7/lib --libexecdir=/opt/rtems-4.7/lib
--mandir=/opt/rtems-4.7/man --infodir=/opt/rtems-4.7/info
--datadir=/opt/rtems-4.7/share --build=i686-suse-linux-gnu
--host=i686-suse-linux-gnu --target=sparc-rtems4.7 --with-gnu-as --with-gnu-ld
--verbose --with-newlib --with-system-zlib --disable-nls
--without-included-gettext --disable-win32-registry
--enable-version-specific-runtime-libs --enable-threads --enable-languages=c,c++
Thread model: rtems
gcc version 4.1.1 (RTEMS gcc-4.1.1/newlib-1.15.0-9.suse10.2)
$ cat float.c
float square(float x)
{
return x * x;
}
$ sparc-rtems-gcc -mcpu=cypress -c float.c
$ sparc-rtems-objdump -d float.o
float.o: file format elf32-sparc
Disassembly of section .text:
:
0: 9d e3 bf 98 save %sp, -104, %sp
4: f0 27 a0 44 st %i0, [ %fp + 0x44 ]
8: d3 07 a0 44 ld [ %fp + 0x44 ], %f9
c: d1 07 a0 44 ld [ %fp + 0x44 ], %f8
10: 91 a2 49 28 fmuls %f9, %f8, %f8
14: 81 a0 00 28 fmovs %f8, %f0
18: 81 e8 00 00 restore
1c: 81 c3 e0 08 retl
20: 01 00 00 00 nop
$ sparc-rtems-gcc -mcpu=cypress -mfpu -c float.c
$ sparc-rtems-objdump -d float.o
float.o: file format elf32-sparc
Disassembly of section .text:
:
0: 9d e3 bf 98 save %sp, -104, %sp
4: f0 27 a0 44 st %i0, [ %fp + 0x44 ]
8: d0 07 a0 44 ld [ %fp + 0x44 ], %o0
c: d2 07 a0 44 ld [ %fp + 0x44 ], %o1
10: 40 00 00 00 call 10
14: 01 00 00 00 nop
18: 82 10 00 08 mov %o0, %g1
1c: b0 10 00 01 mov %g1, %i0
20: 81 e8 00 00 restore
24: 81 c3 e0 08 retl
28: 01 00 00 00 nop
$ sparc-rtems-gcc -mcpu=cypress -mhard-float -c float.c
$ sparc-rtems-objdump -d float.o
float.o: file format elf32-sparc
Disassembly of section .text:
:
0: 9d e3 bf 98 save %sp, -104, %sp
4: f0 27 a0 44 st %i0, [ %fp + 0x44 ]
8: d0 07 a0 44 ld [ %fp + 0x44 ], %o0
c: d2 07 a0 44 ld [ %fp + 0x44 ], %o1
10: 40 00 00 00 call 10
14: 01 00 00 00 nop
18: 82 10 00 08 mov %o0, %g1
1c: b0 10 00 01 mov %g1, %i0
20: 81 e8 00 00 restore
24: 81 c3 e0 08 retl
28: 01 00 00 00 nop
$ sparc-rtems-gcc -mcpu=cypress -mhard-quad-float -c float.c
$ sparc-rtems-objdump -d float.o
float.o: file format elf32-sparc
Disassembly of section .text:
:
0: 9d e3 bf 98 save %sp, -104, %sp
4: f0 27 a0 44 st %i0, [ %fp + 0x44 ]
8: d3 07 a0 44 ld [ %fp + 0x44 ], %f9
c: d1 07 a0 44 ld [ %fp + 0x44 ], %f8
10: 91 a2 49 28 fmuls %f9, %f8, %f8
14: 81 a0 00 28 fmovs %f8, %f0
18: 81 e8 00 00 restore
1c: 81 c3 e0 08 retl
20: 01 00 00 00 nop
LOG_LINKS information after dataflow merge
LOG_LINKS are gone. Where do I find the equivalent information in a dump file now? -- Rask Ingemann Lambertsen
Re: LOG_LINKS information after dataflow merge
Rask Ingemann Lambertsen wrote: LOG_LINKS are gone. Where do I find the equivalent information in a dump file now? LOG_LINKS are now stored in a side array. Adding some dumps in create_log_links would be a good idea indeed. Paolo
Re: sparc-rtems4.7-gcc versus fpu
> I have downloaded sparc-rtems4.7 and would like to use it for a leon2 > target with fpu. I am puzzled on how the compiler inserts fpu instructions. > My summary is: > > - The compiler does insert fpu instructions, if no fpu command line option > is given or if "-mhard-quad-float" is used. > > - The compiler does not insert fpu instructions, if "-mfpu" or > "-mhard-float" is used. Stupid breakage, now fixed on all active branches in the tree: http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00879.html Thanks for reporting it. -- Eric Botcazou
Re: sparc-rtems4.7-gcc versus fpu
Eric Botcazou wrote: I have downloaded sparc-rtems4.7 and would like to use it for a leon2 target with fpu. I am puzzled on how the compiler inserts fpu instructions. My summary is: - The compiler does insert fpu instructions, if no fpu command line option is given or if "-mhard-quad-float" is used. - The compiler does not insert fpu instructions, if "-mfpu" or "-mhard-float" is used. Stupid breakage, now fixed on all active branches in the tree: http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00879.html Thanks for reporting it. Thank you for fixing it!!! Some day, I am going to have to come clean on all this beer I owe people for fixing bugs. :-D --joel
Re: Sparc bootstrap failure, dataflow related?
On Tue, 12 Jun 2007, Kenneth Zadeck wrote: > Kaveh R. GHAZI wrote: > > I'm getting a new bootstrap failure today on sparc-sun-solaris2.10 which > > I've filed under PR bootstrap/32312. GCC dies in stage1 building libgcc2, > > I see that it's getting a SEGV because the variable "df" is nil. It might > > be related to the dataflow merge. > > > > There's an attachment in the PR, would you please take a look? > > > > Thanks, > > --Kaveh > > -- > > Kaveh R. Ghazi [EMAIL PROTECTED] > > > > i am about to commit the patch to fix this. > kenny Thanks, it seems to have worked. http://gcc.gnu.org/ml/gcc-testresults/2007-06/msg00615.html -- Kaveh R. Ghazi [EMAIL PROTECTED]
Blackfin eh broken with dataflow merge
Exception handling on the Blackfin was broken by the dataflow merge.
Inspecting the differences in the generated code, it appears that when
compiling functions like _Unwind_Resume in unwind-dw2.c, the dse pass
deletes necessary instructions.
Before:
(insn 56 55 57 7 (set (reg/v:SI 56 [ offset ])
(reg:SI 0 R0)) 14 {*movsi_insn} (expr_list:REG_DEAD (reg:SI 0 R0)
(nil)))
(insn 57 56 67 7 (set (reg/v/f:SI 55 [ handler ])
(mem/s/f/c:SI (plus:SI (reg/f:SI 15 FP)
(const_int -376 [0xfe88])) [12 cur_context.ra+0 S4
A32])) 14 {*movsi_insn} (nil))
(insn 67 57 68 7 (set (reg:SI 10 P2 [ offset ])
(reg/v:SI 56 [ offset ])) 14 {*movsi_insn} (expr_list:REG_DEAD
(reg/v:SI 56 [ offset ])
(nil)))
(insn 68 67 69 7 (set (mem:SI (plus:SI (reg/f:SI 15 FP)
(const_int 4 [0x4])) [0 S4 A32])
(reg/v/f:SI 55 [ handler ])) 14 {*movsi_insn}
(expr_list:REG_DEAD (reg/v/f:SI 55 [ handler ])
(nil)))
(jump_insn 69 68 0 7 (set (pc)
(unspec_volatile [
(reg:SI 10 P2)
] 0)) 126 {eh_return_internal} (expr_list:REG_DEAD (reg:SI
10 P2)
(expr_list:REG_EQUAL (unspec_volatile [
(reg:SI 10 P2)
] 0)
(nil
After:
(insn 56 55 67 7 (set (reg/v:SI 56 [ offset ])
(reg:SI 0 R0)) 14 {*movsi_insn} (expr_list:REG_DEAD (reg:SI 0 R0)
(nil)))
(insn 67 56 69 7 (set (reg:SI 10 P2 [ offset ])
(reg/v:SI 56 [ offset ])) 14 {*movsi_insn} (expr_list:REG_DEAD
(reg/v:SI 56 [ offset ])
(nil)))
(jump_insn 69 67 0 7 (set (pc)
(unspec_volatile [
(reg:SI 10 P2)
] 0)) 126 {eh_return_internal} (expr_list:REG_DEAD (reg:SI
10 P2)
(expr_list:REG_EQUAL (unspec_volatile [
(reg:SI 10 P2)
] 0)
(nil
[FP + 4] is part of the register save area. Insn 68, which stores a
value into it, gets deleted.
There is a reference to current_function_uses_eh_return in dse.c, but
it's not clear to me what it's trying to achieve. Anyway, turning the
store into an unspec_volatile solves the problem. I've committed the
following.
Bernd
--
This footer brought to you by insane German lawmakers.
Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif
Index: ChangeLog
===
--- ChangeLog (revision 125680)
+++ ChangeLog (working copy)
@@ -1,3 +1,10 @@
+2007-06-13 Bernd Schmidt <[EMAIL PROTECTED]>
+
+ * config/bfin/bfin.h (EH_RETURN_HANDLER_RTX): Use gen_frame_mem.
+ * config/bfin/bfin.md (UNSPEC_VOLATILE_STORE_EH_HANDLER): New constant.
+ (eh_store_handler): New pattern.
+ (eh_return): Emit it instead of a plain move.
+
2007-06-13 Uros Bizjak <[EMAIL PROTECTED]>
* config/i386/i386.c (ix86_init_mmx_sse_builtins)
Index: config/bfin/bfin.h
===
--- config/bfin/bfin.h (revision 125641)
+++ config/bfin/bfin.h (working copy)
@@ -813,7 +813,7 @@ typedef struct {
#define EH_RETURN_DATA_REGNO(N)((N) < 2 ? (N) : INVALID_REGNUM)
#define EH_RETURN_STACKADJ_RTX gen_rtx_REG (Pmode, REG_P2)
#define EH_RETURN_HANDLER_RTX \
-gen_rtx_MEM (Pmode, plus_constant (frame_pointer_rtx, UNITS_PER_WORD))
+gen_frame_mem (Pmode, plus_constant (frame_pointer_rtx, UNITS_PER_WORD))
/* Addressing Modes */
Index: config/bfin/bfin.md
===
--- config/bfin/bfin.md (revision 125648)
+++ config/bfin/bfin.md (working copy)
@@ -144,7 +144,8 @@ (define_constants
[(UNSPEC_VOLATILE_EH_RETURN 0)
(UNSPEC_VOLATILE_CSYNC 1)
(UNSPEC_VOLATILE_SSYNC 2)
- (UNSPEC_VOLATILE_LOAD_FUNCDESC 3)])
+ (UNSPEC_VOLATILE_LOAD_FUNCDESC 3)
+ (UNSPEC_VOLATILE_STORE_EH_HANDLER 4)])
(define_constants
[(MACFLAG_NONE 0)
@@ -2687,12 +2688,20 @@ (define_expand "eh_return"
UNSPEC_VOLATILE_EH_RETURN)]
""
{
- emit_move_insn (EH_RETURN_HANDLER_RTX, operands[0]);
+ emit_insn (gen_eh_store_handler (EH_RETURN_HANDLER_RTX, operands[0]));
emit_jump_insn (gen_eh_return_internal ());
emit_barrier ();
DONE;
})
+(define_insn "eh_store_handler"
+ [(unspec_volatile [(match_operand:SI 1 "register_operand" "da")]
+ UNSPEC_VOLATILE_STORE_EH_HANDLER)
+ (clobber (match_operand:SI 0 "memory_operand" "=m"))]
+ ""
+ "%0 = %1%!"
+ [(set_attr "type" "mcst")])
+
(define_insn_and_split "eh_return_internal"
[(set (pc)
(unspec_volatile [(reg:SI REG_P2)] UNSPEC_VOLATILE_EH_RETURN))]
Re: Procedure to submit new port (CR16 processor)
"Pompapathi V Gadad" <[EMAIL PROTECTED]> writes: > My GCC assignment/disclaimer process with the FSF is complete. It > would be greatly appreciated, if someone can provide information about > the following: > a) Can the write permissions to port specific files can be obtained > even before submitting the files? How to get GCC SVN write permissions? The first step is to send the proposed patch to gcc-patches. Get the patch approved, which will normally involve some give-and-take with the maintainers. Then apply for write permission to the SVN repository, and commit the patch. > b) I would also like to maintain the CRX (National Semiconductor's > 32-bit processor) port. What is the procedure to request transfer in > maintainership of CRX port? If there is no such thing called "transfer > of maintainership", then would it be possible to co-maintain the CRX > port? The first step would be to talk to the current maintainer of the CRX port, Paul Woegerer, and make sure that he agrees. Usually the steering committee would like to see some track record of successful patch submission before granting maintainer status. For example, it needs to be clear that you understand the basic formatting, patch submission, and patch approval rules. So you should probably go through the exercise of submitting the CR16 port before becoming maintainer of the CRX port. This is all my personal take on things, not any sort of official statement. Ian
Re: Splitting function arguments.
"Mohamed Shafi" <[EMAIL PROTECTED]> writes: > I am working for a private GCC target. > The target has 4 registers, each 32 bits reserved for arguments. > When passing arguments depending on the type of the argument either > registers or stack + registers will be used Sometimes the arguments > will be split between a memory location and the register.Consider the > following function call > > fun(int k, long long j, long long m); > > In the above case k and j will be passed through registers and m will > be passed through register and stack, as all the other registers are > used by the arguments k and j. > In this case compiler is splitting the values on its own. But due to > the restriction placed by load/store operation for the target, the > splitting has to be modified according to the target. > > Is there any target hook that will help me to do it? > Or can i write a pattern in the md file that can be used for this > purpose. Is there any other target that does similar to this? See TARGET_ARG_PARTIAL_BYTES. Ian
Re: Blackfin eh broken with dataflow merge
Bernd Schmidt wrote: > There is a reference to current_function_uses_eh_return in dse.c, but > it's not clear to me what it's trying to achieve. Anyway, turning the > store into an unspec_volatile solves the problem. I've committed the > following. > > I will look into this. kenny
Generating a phi node
Hello, I have two ssa vars (i0 and i1 in the following example); what is the sequence to generate a new phi node corresponding to i3 - if (...) i0 = exp1 else i1 = exp2 i3 = PHI(i0 , i1); Thanks, Revital
Re: Generating a phi node
On 6/13/07, Revital1 Eres <[EMAIL PROTECTED]> wrote: Hello, I have two ssa vars (i0 and i1 in the following example); what is the sequence to generate a new phi node corresponding to i3 - if (...) i0 = exp1 else i1 = exp2 i3 = PHI(i0 , i1); From tree-vectorizer.c, /* 1.1. Generate new phi node in NEW_MERGE_BB: */ new_phi = create_phi_node (SSA_NAME_VAR (PHI_RESULT (orig_phi)), new_merge_bb); /* 1.2. NEW_MERGE_BB has two incoming edges: GUARD_EDGE and the exit-edge of LOOP. Set the two phi args in NEW_PHI for these edges: */ loop_arg = PHI_ARG_DEF_FROM_EDGE (orig_phi, EDGE_SUCC (loop->latch, 0)); guard_arg = PHI_ARG_DEF_FROM_EDGE (orig_phi, loop_preheader_edge (loop)); add_phi_arg (new_phi, loop_arg, new_exit_e); add_phi_arg (new_phi, guard_arg, guard_edge);
Re: Some regressions from the dataflow merge
Richard Guenther wrote: > On Tue, 12 Jun 2007, Richard Guenther wrote: > > >> On ia64 SPEC2000 I see fma3d and applu now miscompare. >> > > On x86_64 186.wupwise ICEs with -O2 -ffast-math and FDO: > > /gcc/spec/sb-haydn-fdo-64/x86_64/install-200706120559/bin/gfortran -c -o > zscal.o-fprofile-use -O2 -ffast-math zscal.f > Error from fdo_make_pass2 'specmake -j2 FDO=PASS2 build 2> > fdo_make_pass2.err | tee fdo_make_pass2.out': > zgemm.f: In function 'zgemm': > zgemm.f:413: internal compiler error: in remove_insn, at emit-rtl.c:3597 > Please submit a full bug report, > with preprocessed source if appropriate. > See http://gcc.gnu.org/bugs.html> for instructions. > > Likewise for 176.gcc: > > combine.c: In function 'simplify_comparison': > combine.c:9697: internal compiler error: in remove_insn, at > emit-rtl.c:3597 > Please submit a full bug report, > with preprocessed source if appropriate. > See http://gcc.gnu.org/bugs.html> for instructions. > specmake: *** [combine.o] Error 1 > > Richard. > Richard, did these two regression go away? We committed a change to gcse that should have fixed this bug. kenny
Backtrace() called inside a signal handler traps while tracking an invalid function call.
Hello,
Backtrace API is trapping when it is called inside a signal handler
to trace back an invalid function call.
Backtrace API is called from a signal handler. When the SEGFAULT signal
that is captured by the signal handler is due to the invokation of an
invalid function call, then backtrace is generating SEGFAULT. In i586
this segfault again gets captured by the signal handler, reaches
backtrace, backtrace again generates segfault and infinite loop results.
In x86_64 architecture, when backtrace generates segfault, the program
stops.
Following code is an excerpt from gcc-3.3.3/gcc/unwind-dw2.c:
In x86_64 arch, fde is returned null for the invalid singal handler
stack frame...
--
fde = _Unwind_Find_FDE (context->ra - 1, &context->bases);
if (fde == NULL)
{
/* Couldn't find frame unwind info for this function. Try a
target-specific fallback mechanism. This will necessarily
not provide a personality routine or LSDA. */
#ifdef MD_FALLBACK_FRAME_STATE_FOR
MD_FALLBACK_FRAME_STATE_FOR (context, fs, success);
return _URC_END_OF_STACK;
--
MD_FALLBACK_FRAME_STATE_FOR macro is called which inturn checks the pc
to see whether the backtrace is called from a signal hander
--
#ifdef __x86_64__
#define MD_FALLBACK_FRAME_STATE_FOR(CONTEXT, FS, SUCCESS) \
do { \
unsigned char *pc_ = (CONTEXT)->ra; \
struct sigcontext *sc_; \
long new_cfa_; \
\
/* movq __NR_rt_sigreturn, %rax ; syscall */ \
if (*(unsigned char *)(pc_+0) == 0x48 \
&& *(unsigned long *)(pc_+1) == 0x050f000fc0c7) \
{ \
struct ucontext *uc_ = (CONTEXT)->cfa; \
--
SEGFAULT is generated while accessing the content of pc, as pc value is
invalid (oxfe) for the invalid function call.
Is this scenario, of calling backtrace() on a stack containing invalid
function pointer, a supported one? If yes, is there a way we can avoid
accessing pc in this case and get onto unwind further stack frames ?
Btw, gdb is able to successfully unwind the full stack for this same
scenario.
Attaching source files for recreating the problem: main.c and foo.c
Thanks, Supriya
IBM Linux Technology Centre
#include
#include
#include
void foo( void ) ;
void catch_segv(int signum)
{
int i, cnt ;
void *syms[100] ;
char buf[80] ;
cnt = backtrace( syms, 100 ) ;
for ( i = 0 ; i < cnt ; i++ )
{
snprintf( buf, sizeof(buf), "%d\t%lx\n", i, (unsigned long)syms[i] ) ;
puts( buf ) ;
}
}
int main( void )
{
int rc ;
struct sigaction newact; /* Action */
struct sigaction oldact; /* Old action */
newact.sa_handler = catch_segv;
sigemptyset (&newact.sa_mask);
newact.sa_flags = 0;
rc = sigaction (SIGSEGV, &newact, &oldact);
rc = sigaction (SIGBUS, &newact, &oldact);
printf( "rc = %d, calling foo\n", rc ) ;
foo() ;
return 0 ;
}
#include
void (*fp)(void) = (void *)0xff ;
void foo( void )
{
char buf[16] ;
int cnt;
buf[0] = '\n' ;
buf[1] = '\0' ;
printf( "Calling invalid function pointer.%s", buf ) ;
fp() ;
}
Re: Backtrace() called inside a signal handler traps while tracking an invalid function call.
On Thu, Jun 14, 2007 at 02:24:19AM +0530, supriya kannery wrote: > Is this scenario, of calling backtrace() on a stack containing invalid > function > pointer, a supported one? In my opinion, no. Attach a debugger instead. -- Daniel Jacobowitz CodeSourcery
Re: Some regressions from the dataflow merge
On 6/13/07, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: Richard Guenther wrote: > On Tue, 12 Jun 2007, Richard Guenther wrote: > > >> On ia64 SPEC2000 I see fma3d and applu now miscompare. >> > > On x86_64 186.wupwise ICEs with -O2 -ffast-math and FDO: > > /gcc/spec/sb-haydn-fdo-64/x86_64/install-200706120559/bin/gfortran -c -o > zscal.o-fprofile-use -O2 -ffast-math zscal.f > Error from fdo_make_pass2 'specmake -j2 FDO=PASS2 build 2> > fdo_make_pass2.err | tee fdo_make_pass2.out': > zgemm.f: In function 'zgemm': > zgemm.f:413: internal compiler error: in remove_insn, at emit-rtl.c:3597 > Please submit a full bug report, > with preprocessed source if appropriate. > See http://gcc.gnu.org/bugs.html> for instructions. > > Likewise for 176.gcc: > > combine.c: In function 'simplify_comparison': > combine.c:9697: internal compiler error: in remove_insn, at > emit-rtl.c:3597 > Please submit a full bug report, > with preprocessed source if appropriate. > See http://gcc.gnu.org/bugs.html> for instructions. > specmake: *** [combine.o] Error 1 > > Richard. > Richard, did these two regression go away? We committed a change to gcse that should have fixed this bug. Sorry, we have to wait another day - the placement new patch caused conflicts on svn update on the tree (DAMN IDENTICAL LOCAL FILES CONFLICTS - svn sucks). I'll keep you posted if they still fail after the gcse patch. Richard.
gcc-4.2-20070613 is now available
Snapshot gcc-4.2-20070613 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20070613/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.2 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch revision 125685 You'll find: gcc-4.2-20070613.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20070613.tar.bz2 C front end and core compiler gcc-ada-4.2-20070613.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20070613.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20070613.tar.bz2 C++ front end and runtime gcc-java-4.2-20070613.tar.bz2 Java front end and runtime gcc-objc-4.2-20070613.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20070613.tar.bz2The GCC testsuite Diffs from 4.2-20070606 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.2 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Merge PTR_PLUS branch?
Andrew -- Now that dataflow has gone in, you have the ball. When you feel that PTR_PLUS is in suitable shape to go in, and the patches have been reviewed, please merge and commit. I know that there have been some reviews of the patches along the way, and the concept has been appropriately approved, so I don't mean for you to get bogged down in the review process. But, I would like a maintainer to approve the commit. I will help review if necessary. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Merge PTR_PLUS branch?
On 6/13/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: Andrew -- Now that dataflow has gone in, you have the ball. When you feel that PTR_PLUS is in suitable shape to go in, and the patches have been reviewed, please merge and commit. Thanks for the confirmation. I know that there have been some reviews of the patches along the way, and the concept has been appropriately approved, so I don't mean for you to get bogged down in the review process. But, I would like a maintainer to approve the commit. I will help review if necessary. I am testing the changes which were requested earlier today. I could not tell if Diego's was an official approval or not. I have approval currently officially only for the Fortran parts. If you could review the C++ front-end changes, that would be nice. The only difference in the C++ front-end between the patch which I sent out and my next version is the use of fold_build1 instead of build1 for the negative expressions. Thanks, Andrew Pinski
Re: Procedure to submit new port (CR16 processor)
Hello Ian, Thanks for the valuable information. My GCC assignment/disclaimer process with the FSF is complete. It would be greatly appreciated, if someone can provide information about the following: a) Can the write permissions to port specific files can be obtained even before submitting the files? How to get GCC SVN write permissions? The first step is to send the proposed patch to gcc-patches. Get the patch approved, which will normally involve some give-and-take with the maintainers. Then apply for write permission to the SVN repository, and commit the patch. OK. Let me submit the patch for CR16 first and go through the approval process. b) I would also like to maintain the CRX (National Semiconductor's 32-bit processor) port. What is the procedure to request transfer in maintainership of CRX port? If there is no such thing called "transfer of maintainership", then would it be possible to co-maintain the CRX port? The first step would be to talk to the current maintainer of the CRX port, Paul Woegerer, and make sure that he agrees. Usually the steering committee would like to see some track record of successful patch submission before granting maintainer status. For example, it needs to be clear that you understand the basic formatting, patch submission, and patch approval rules. So you should probably go through the exercise of submitting the CR16 port before becoming maintainer of the CRX port. The email id of Paul Woegerer is not valid as he is not with National anymore. Therefore, there is no way to contact Paul on this matter. Our team in National has started handling tool chains related to CRX and CR16 cores. May be, I should go ahead with submitting the CR16 port first. Thanks a lot, -Pompa - Pompapathi V Gadad CR Tool Chain Team National Semiconductor Corporation
Re: Merge PTR_PLUS branch?
On 6/13/07 11:33 PM, Andrew Pinski wrote: > I am testing the changes which were requested earlier today. I could > not tell if Diego's was an official approval or not. I have approval > currently officially only for the Fortran parts. It was, with the changes I suggested, for the non-FE parts. Sorry for not making that clear.
Re: Splitting function arguments.
On 13 Jun 2007 10:47:33 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: "Mohamed Shafi" <[EMAIL PROTECTED]> writes: > I am working for a private GCC target. > The target has 4 registers, each 32 bits reserved for arguments. > When passing arguments depending on the type of the argument either > registers or stack + registers will be used Sometimes the arguments > will be split between a memory location and the register.Consider the > following function call > > fun(int k, long long j, long long m); > > In the above case k and j will be passed through registers and m will > be passed through register and stack, as all the other registers are > used by the arguments k and j. > In this case compiler is splitting the values on its own. But due to > the restriction placed by load/store operation for the target, the > splitting has to be modified according to the target. > > Is there any target hook that will help me to do it? > Or can i write a pattern in the md file that can be used for this > purpose. Is there any other target that does similar to this? See TARGET_ARG_PARTIAL_BYTES. I looked into this hook before but this hook only helps me to choose the number of bytes at the beginning of an argument that must be put in registers. But what i want is to shift the 64 bit value 16 times to left before its split. So in essence i need to control which all bytes should go into the register and which all in the memory and the above target hook, IIUC only decides about how many. So is there any way to do this? Regards, Shafi.
