Re: building gcc4-4.3.0-20070518 failed on OSX 10.3.9
> In toplevel, svn up -r 124763 Makefile.tpl Makefile.def Makefile.in I used the files from trunk revision 124627 and the build went fine. I'll try to find some time to fill a PR Dominique
Re: 4.3 release plan
I got the second one too. Italians must be good at acronyms. :-) IMBGAA! ...BTTOWWTD!!! PBTMAICFOTL (Probably better than me as I cannot figure out the latter). On the other hand, it may mean that we can skip stage2 altogether, since we had stage2 during stage1 for 4.3... I'm definitely for short release cycles, so I'd generally second this. But in the wiki I see several stage1 projects still waiting to be merged, as Steven Bosscher said Would these have to go in now or later in 4.4? I would propose waiting for these to be merged, and then moving directly to bug-fixing stage3. We've effectively been in stage2 for 4 months. Paolo
Google Summer of Code 2007 Projects
Hi, I have added to the wiki the list of Google's SoC projects for this year. http://gcc.gnu.org/wiki/SummerOfCode From my experience of last year, I would recommend to create a wiki page for your project to dump anything that could be remotely useful and to allow people to add comments. You can see my page from last year here http://gcc.gnu.org/wiki/Wcoercion. If you decide to create such a page (or if you decide to keep such a page somewhere else), please link it from the table at http://gcc.gnu.org/wiki/SummerOfCode . I think I speak on behalf of the GCC community when I say to all new SoC participants: Welcome aboard and happy coding! Manuel. P.S. It would be nice to know that you are actually there ;-)
Re: general_operand() not accepting CONCAT?
On Fri, Apr 27, 2007 at 08:24:11AM -0700, Richard Henderson wrote:
> On Fri, Apr 27, 2007 at 04:00:13PM +0200, Rask Ingemann Lambertsen wrote:
> >I don't see how emit_move_complex_push() can ever generate a push
> > instruction. Here's a backtrace:
>
> emit_move_insn (gen_rtx_MEM (submode, XEXP (x, 0)),
> read_complex_part (y, imag_first));
> return emit_move_insn (gen_rtx_MEM (submode, XEXP (x, 0)),
> read_complex_part (y, !imag_first));
>
> Note that we're replacing (pre_dec:CSI sp) with two
> instances of (pre_dec:SI sp).
It's not working the way it is supposed to. Here is an example
(testitcs() from gcc.dg/compat/scalar-return-4_x.c) where
emit_move_complex_push() is called with CHImode:
(gdb) bt
#0 add_insn (insn=0xb7f75a50) at ../../../cvssrc/gcc/gcc/emit-rtl.c:3404
#1 0x08177709 in emit_insn (x=0xb7f88180) at
../../../cvssrc/gcc/gcc/emit-rtl.c:4353
#2 0x08532de4 in gen_movhi (operand0=0xb7f88174, operand1=0xb7ee1210) at
../../../cvssrc/gcc/gcc/config/ia16/ia16.md:203
#3 0x081b7bb9 in emit_move_insn_1 (x=0xb7f88174, y=0xb7ee1210) at
../../../cvssrc/gcc/gcc/expr.c:3260
#4 0x081b7e95 in emit_move_insn (x=0xb7f88174, y=0xb7ee1210) at
../../../cvssrc/gcc/gcc/expr.c:3351
#5 0x081bdc58 in emit_move_complex_push (mode=CHImode, x=0xb7f88168,
y=0xb7f8815c) at ../../../cvssrc/gcc/gcc/expr.c:3025
#6 0x081b7d75 in emit_move_insn_1 (x=0xb7f88168, y=0xb7f8815c) at
../../../cvssrc/gcc/gcc/expr.c:3061
#7 0x081b7e95 in emit_move_insn (x=0xb7f88168, y=0xb7f8815c) at
../../../cvssrc/gcc/gcc/expr.c:3351
#8 0x081bb478 in emit_single_push_insn (mode=CHImode, x=0xb7f8815c,
type=0xb7f82000) at ../../../cvssrc/gcc/gcc/expr.c:3582
#9 0x081c03ff in emit_push_insn (x=0xb7f8815c, mode=CHImode, type=0xb7f82000,
size=0x0, align=16, partial=0, reg=0x0, extra=0, args_addr=0x0,
args_so_far=0xb7ee1220, reg_parm_stack_space=0, alignment_pad=0xb7ee1210)
at ../../../cvssrc/gcc/gcc/expr.c:3852
#10 0x081143c7 in store_one_arg (arg=0xbf9f4c00, argblock=0x0, flags=0,
variable_size=0, reg_parm_stack_space=0) at ../../../cvssrc/gcc/gcc/calls.c:4239
#11 0x0811904f in expand_call (exp=0xb7f8523c, target=0x0, ignore=1) at
../../../cvssrc/gcc/gcc/calls.c:2652
#12 0x081a71ff in expand_expr_real_1 (exp=0xb7f8523c, target=0x0,
tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at
../../../cvssrc/gcc/gcc/expr.c:7789
#13 0x081b689b in expand_expr_real (exp=0xb7f8523c, target=0xb7ee1210,
tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0)
at ../../../cvssrc/gcc/gcc/expr.c:6789
#14 0x08355a2c in expand_expr_stmt (exp=0xb7f8523c) at
../../../cvssrc/gcc/gcc/expr.h:504
[snip]
(gdb) frame 5
#5 0x081bdc58 in emit_move_complex_push (mode=CHImode, x=0xb7f88168,
y=0xb7f8815c) at ../../../cvssrc/gcc/gcc/expr.c:3025
3025 emit_move_insn (gen_rtx_MEM (submode, XEXP (x, 0)),
(gdb) call debug_rtx(x)
(mem/s:CHI (pre_dec:HI (reg/f:HI 12 sp)) [0 S4 A16])
(gdb) call debug_rtx(y)
(mem/s:CHI (symbol_ref/f:HI ("*.LC0") [flags 0x2] ) [0
S4 A16])
(gdb) frame 4
#4 0x081b7e95 in emit_move_insn (x=0xb7f88174, y=0xb7ee1210) at
../../../cvssrc/gcc/gcc/expr.c:3351
3351 last_insn = emit_move_insn_1 (x, y);
(gdb) call debug_rtx(x)
(mem:HI (pre_dec:HI (reg/f:HI 12 sp)) [0 S2 A8])
(gdb) call debug_rtx(y)
(const_int 0 [0x0])
(gdb) frame 2
#2 0x08532de4 in gen_movhi (operand0=0xb7f88174, operand1=0xb7ee1210) at
../../../cvssrc/gcc/gcc/config/ia16/ia16.md:203
203 (match_operand:EQ16 1 "general_operand" "rm,Ri"))]
(gdb) call debug_rtx(operand0)
(mem:HI (pre_dec:HI (reg/f:HI 12 sp)) [0 S2 A8])
(gdb) call debug_rtx(operand1)
(const_int 0 [0x0])
The push operand is passed to the movhi expander. From the GCC Internals
manual, section "Standard Names":
`pushm1'
Output a push instruction. Operand 0 is value to push. Used only
when PUSH_ROUNDING is defined. For historical reason, this pattern
may be missing and in such case an mov expander is used instead,
with a MEM expression forming the push operation. The mov expander
method is deprecated.
If you agree that it is a bug to pass the push operand to the movhi
expander (instead of passing it to the pushhi expander), then I'll submit a
patch for it.
--
Rask Ingemann Lambertsen
gcc behind the scenes
Hello,, When I do "gcc foo.c", behind the scenes I suppose there are many actions, like calling 'cpp', 'gcc', 'as' and finally, 'ld'. Is there a way to know what is going on exactly behind the scenes of gcc ? Like which other tools are called and with which command line arguments ? Thank You sunzir
RE: gcc behind the scenes
On 20 May 2007 17:40, Sunzir Deepur wrote: > Hello,, > > When I do "gcc foo.c", behind the scenes I suppose there > are many actions, like calling 'cpp', 'gcc', 'as' and finally, 'ld'. > > Is there a way to know what is going on exactly behind the > scenes of gcc ? > Like which other tools are called and with which command line > arguments ? This is a question about how to use gcc, not about the coding and development of gcc itself, so should have gone to the gcc-help list; please post there next time. (The answer you're looking for is documented in the manual and in the output of 'gcc --help'. Look for the '-v' flag). cheers, DaveK -- Can't think of a witty .sigline today
Re: gcc behind the scenes
all, sorry for the misplaced (and trivial) question, won't happen again. thank you for the nice attitude though ! sunzir.
Re: building gcc4-4.3.0-20070518 failed on OSX 10.3.9
Dominique Dhumieres wrote: In toplevel, svn up -r 124763 Makefile.tpl Makefile.def Makefile.in I used the files from trunk revision 124627 and the build went fine. I'll try to find some time to fill a PR I can confirm your hunting. Reverting the mentioned patch brings bootstrap back on ppc-darwin. Thanks, Andreas
Re: building gcc4-4.3.0-20070518 failed on OSX 10.3.9
> Thanks, You're welcome! This is PR32009. Cheers Dominique
Re: 4.3 release plan
Paolo Bonzini wrote: >> ...BTTOWWTD!!! > > PBTMAICFOTL (Probably better than me as I cannot figure out the latter). Never mind, it was meant to be impossible to decode: "But The Third One Was Way Too Difficult" :-) >> Would these have to go in now or later in 4.4? > > I would propose waiting for these to be merged, and then moving directly > to bug-fixing stage3. We've effectively been in stage2 for 4 months. I see, but what about all the pending stage 2 projects then? These are most probably not yet ready to go in, and merging too much stuff at the same time isn't a wise thing anyway. (the next proposal is likely to cause some dissent) What about moving 4.3 to stage 3 *now* and moving everything else in 4.4 instead? Hopefully, it will be a matter of just a few months. From http://gcc.gnu.org/gcc-4.3/changes.html, it looks like it would already be quite a juicy release. (ducks) -- // Bernardo Innocenti \X/ http://www.codewiz.org/
Re: 4.3 release plan
Bernardo Innocenti wrote: (the next proposal is likely to cause some dissent) What about moving 4.3 to stage 3 *now* and moving everything else in 4.4 instead? Hopefully, it will be a matter of just a few months. From http://gcc.gnu.org/gcc-4.3/changes.html, it looks like it would already be quite a juicy release. Why? I mean, I suppose there could be advantages to doing this, but you haven't mentioned even one. - Brooks
Re: 4.3 release plan
On Sun, May 20, 2007 at 10:39:43PM -0700, Brooks Moses wrote: > Bernardo Innocenti wrote: > >(the next proposal is likely to cause some dissent) > >What about moving 4.3 to stage 3 *now* and moving everything > >else in 4.4 instead? Hopefully, it will be a matter of just > >a few months. From http://gcc.gnu.org/gcc-4.3/changes.html, > >it looks like it would already be quite a juicy release. > Why? > I mean, I suppose there could be advantages to doing this, but you > haven't mentioned even one. I think a few people (me!) are waiting for GCJ to have official support for Java 5 syntax and class libraries. Not that I would like to rush you - or skip any valuable merges - but if the code that is in right now is in a near ready state, waiting up to a year before releasing seems unfortunate. :-( Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __ . . _ ._ . . .__. . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/|_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/
Re: Is "FTZ/DAZ for SSE via fast math" available for x86 arch other than Linux?
Hi "Zuxy Meng" <[EMAIL PROTECTED]> дÈëÏûÏ¢ÐÂÎÅ:[EMAIL PROTECTED] > Hi, > > 2007/3/11, Danny Smith <[EMAIL PROTECTED]>: >> >> >> > -Original Message- >> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >> > Behalf Of Zuxy Meng >> > Sent: Wednesday, 7 March 2007 12:36 a.m. >> >> > >> > I've uploaded a proposed patch for this bug >> > (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13151&action=diff). >> > Putting >> > crtfastmath.o in the endfile section of specs causes undefined >> reference to >> > memset, so I moved it to the startfile section. Anyone to review this? >> Quite >> > trivial anyway. >> >> Hello Zuxy, >> >> crtfasmath.o is an endfile for a reason. _set_fast_math is run from the >> .ctors section. It needs to be run before other constructors that might >> use fastmath, so is made an end ctor (ctors are run from right to left). >> >> The reference to memset does not occur on trunk with optimization. It >> can be avoided with 4.2.0 by adding -minline-all-stringops to rule for >> (T)crtfastmath.o > > Maybe such optimization isn't turned on for mingw. I updated the patch > to force this by using -minline-all-stringops. > > http://gcc.gnu.org/bugzilla/attachment.cgi?id=13189 Any developer to have a look at this? -- Zuxy
