Re: Possible bug: Template name lookup & overloaded functions.
2010/1/19 Simon Hill: > Axel Quote: > "Anyways there is an already filed GCC bug about this defect report > against the standard, > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29131 ." > > That bug report is suspended. Is this due to the C++ standards issue > you referred to?: > http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_active.html#225 Yes, there's no point changing GCC until it's clear what the standard will say on the subject. > That C++ standards issue is also 10 years old, and so (I would guess) > unlikely to be fixed any time soon. It has "drafting" status which means someone is working on it. > So, regardless of which stance GCC takes regarding the standards > issue, in my view GCC should still remain consistent. Either accept > both versions (with and without the original template foo()) or reject > both versions. GCC aims for consistency to the standard. If you want to change the standard this isn't the place to do it. You can update the bug report with additional testcases if you think there is something missing from the discussion, but the bug is likely to remain suspended until the DR is resolved (which should be soon, given that the new standard could be finished this year.) Jonathan
Re: Changing the ABI
On Mon, 18 Jan 2010 13:55:16 -0500, Jean Christophe Beyler wrote: >I have a current issue on my port. Basically the stack is defined as follows : > >1) CALL_USED save area >2) Local variables >3) Caller arguments passed on the stack >4) 8 words to save arguments passed in registers, even if not passed > >Now, this was done because we have defined 8 output registers, >therefore zone (3) is not used except if we call a function with more >than 8 parameters. > >(4) is only used if we have va_arg functions that will then spill the >8 input registers on the stack and call the va_arg function. > >This is done, to my understanding for our ABI, because, in the case of >a va_arg function, we want the parameters consecutively store in >memory. That's indeed a desirable property. >However, this brings me to 2 problems : > >1) If there are no va_arg function calls, there still is 8 words >wasted on the stack per function call still active on the stack. > >2) If there is an alloca, then GCC moves the stack pointer but without >trying to get back those 8 words or even the space for (3). > > >I am currently working on not having that wasted space. I see two options: > >1) Change the ABI to go closer to what I have seen in the MIPS port : >- The zone (4) is handled by the callee >- However, I'll still have the wasted space (4) when an alloca is used no ? Actually, zone (4) should just be deleted entirely from the ABI. That is, all the ABI should specify is that non-register arguments are in the caller's frame starting exactly at the stack pointer. For non-varargs calls, there's no waste. For varargs calls, the callee can allocate its frame and save the incoming register arguments at the top of its own frame, establishing the all-arguments-are-stored-consecutively property without burdening the caller or the ABI. An alloca() in the callee should just adjust the stack pointer and ignore the register arguments save area at the top of the frame. /Mikael
Re: GCC 4.4.3 Release Candidate available from gcc.gnu.org
On Sat, 2010-01-16 at 16:23 +0100, Jakub Jelinek wrote: > > The branch is now frozen and all checkins until after the final release > of GCC 4.4.3 require explicit RM approval. I would like to backport this patch http://gcc.gnu.org/PR38697 from mainline into the 4.3 and 4.4 branches, so that some spurious Neon test failures go away. Can I also ask to backport the fix for http://gcc.gnu.org/PR40887 into the 4.3 / 4.4 branches ? Cheers Ramana
Re: Unknown CPU given in --with-tune=athlon64-sse3.
Felyza Wishbringer writes: > Trying to build trunk. Having an issue with "Unknown CPU given in > --with-tune=athlon64-sse3." > > My configure script is: > cd build;../gcc-4.5/configure --prefix=/opt/gcc-4.5 --enable-lto > --program-suffix=-4.5 --with-system-zlib --enable-__cxa_atexit > --with-tune=athlon64-sse3 > > I'm using the page found at > http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86_002d64-Options.html as > reference, which lists, "//k8-sse3, opteron-sse3, athlon64-sse3/"/ as > a valid option step between the k8 and barcelona lines. / > // > /From trunk/gcc/config.gcc:/ > /echo "Unsupported CPU used in --with-cpu=$with_cpu, > supported values:" 1>&2/ > /echo "generic atom core2 nocona x86-64 amdfam10 > barcelona k8 opteron athlon64 athlon-fx" 1>&2/ > // > No where in config.gcc am I finding mention of 'sse3'. > > /Is the lack of the sse3 models an oversight, or intended?// I haven't looked in full detail, but it looks like an oversight to me. It's rejected in config.gcc but accepted in i386.c. If config.gcc accepted it it seems likely that it would work fine. Ian
C parser modification & questions
Hello, I am working on a modification of C parser and I need some help since I am having difficulties understanding some issues (I am complete newbie on GCC). Long story short, I am trying to add a new attribute to function types (similar to "inline", for example). Let's say that this new keyword is _Something. So, my new parser should be able to parse c function declared/defined like this: _Something int Function_Name(unsigned a, int b); Of course, I need to add new keyword "_Something", but that is the easiest part. I am having difficulties understanding c-parser.c code. I tried to debug cc1 (c-parser.c file) to see where the function declarator is parsed (I used simple code which has main() and Hi_World() functions). I have several questions about debugging: 1. Which part of code parses "Hi_World" string? 2. How can I see the tree which contains "Hi_World" string (during debugging)? 3. Which part of code parses parameters of "Hi_World"? (In general, which part of code parses function parameters) 4. If Hi_World has parameters a and b, how can I see the tree nodes which contain values/names of these parameters? (As it's obvious I have problem understanding/viewing data during debugging parser). 5. In which part of code I need to add parsing of my new reserved word _Something? I would be very grateful if someone could answer any of these questions. Thank you in advance! Best regards, Nikola
Re: Non-standard test?
YuGr writes: > On Monday 18 January 2010 16:19:23 Joseph S. Myers wrote: > >> As previously discussed at length, many changes are needed in various >> parts of GCC to work well for targets where char is wider than 8 bits; >> they never worked well even when GCC used to have such ports. If adding >> such a port, many substantial code changes will be needed as well as >> substantial testsuite changes; not just patching one test. > > Ok, thanks Joseph. I guess we'll just patch our local c-torture then. I actually think it would be fine to use a dg-requires or a #ifdef in this test. dg-requires is probably better but I'm not sure offhand whether it works in the c-torture/execute directory. As Joseph says, other tests will have to be changed as well, but that isn't a reason not to fix this test. Ian
Re: C parser modification & questions
Nikola Ikonic wrote:
Hello,
I am working on a modification of C parser and I need some help since
I am having difficulties understanding some issues (I am complete
newbie on GCC). Long story short, I am trying to add a new attribute
to function types (similar to "inline", for example). Let's say that
this new keyword is _Something.
So, my new parser should be able to parse c function declared/defined like this:
_Something int Function_Name(unsigned a, int b);
I would suggest using GCC attributes for that. So you would code instead
int Function_Name(unsigned a, int b) __attribute__((YourAttribute));
See http://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html
Of course, you could provide your headerfile which would
#define _Something __attribute__((YourAttribute))
So your user code could be
int Function_Name(unsigned a, int b) _Something;
The big advantages of attributes are:
1. You don't have to hack the GCC parser.
2. People already should be familiar with the notion of attributes and their
syntax.
3. There is already a lot of support for attributes inside GCC.
BTW you don't even have to hack GCC 4.5 for your purposes. You could code a plugin for GCC 4.5 (to be released soon, and
snapshots are already available thru SVN or FTP), and your plugin (which should be GPL compatible) would accept that
extra attribute and handle it appropriately! You could even code your plugin using MELT (a high-level lisp-like language
with pattern-matching, objects, functional values, ...).
So my advice is to not touch at all the C parser, and use the existing infrastructure. BTW, attributes are also parsed
by the C++ parser!
The big issue when hacking your own variant of the GCC parser is all the work required just to follow GCC's evolution
(which is always a big lot of work, even within plugins).
Regards.
PS. For people interested, I am also begin to add an alternative infix syntax to MELT. This only for people allergical
to lot of insipid stupid parenthesis syntax.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Long paths with ../../../../ throughout
Hello gcc -o t -### test.c Any easy way to evaluate and reduce command lines? Consider this: /usr/lib/gcc/i486-linux-gnu/4.3.3/../../../../lib/crt1.o Is actually the same as: /usr/lib/crt1.o -- which is much clearer! I'm using Ubuntu 9.04. Cheers, Jon $ gcc -o t -### test.c Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.3-5ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) COLLECT_GCC_OPTIONS='-o' 't' '-mtune=generic' "/usr/lib/gcc/i486-linux-gnu/4.3.3/cc1" "-quiet" "test.c" "-D_FORTIFY_SOURCE=2" "-quiet" "-dumpbase" "test.c" "-mtune=generic" "-auxbase" "test" "-fstack-protector" "-o" "/tmp/ccoCNitV.s" COLLECT_GCC_OPTIONS='-o' 't' '-mtune=generic' "as" "-Qy" "-o" "/tmp/ccKSwMpH.o" "/tmp/ccoCNitV.s" COMPILER_PATH=/usr/lib/gcc/i486-linux-gnu/4.3.3/:/usr/lib/gcc/i486-linux-gnu/4.3.3/:/usr/lib/gcc/i486-linux-gnu/:/usr/lib/gcc/i486-linux-gnu/4.3.3/:/usr/lib/gcc/i486-linux-gnu/:/usr/lib/gcc/i486-linux-gnu/4.3.3/:/usr/lib/gcc/i486-linux-gnu/ LIBRARY_PATH=/usr/lib/gcc/i486-linux-gnu/4.3.3/:/usr/lib/gcc/i486-linux-gnu/4.3.3/:/usr/lib/gcc/i486-linux-gnu/4.3.3/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/i486-linux-gnu/4.3.3/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-o' 't' '-mtune=generic' "/usr/lib/gcc/i486-linux-gnu/4.3.3/collect2" "--eh-frame-hdr" "-m" "elf_i386" "--hash-style=both" "-dynamic-linker" "/lib/ld-linux.so.2" "-o" "t" "-z" "relro" "/usr/lib/gcc/i486-linux-gnu/4.3.3/../../../../lib/crt1.o" "/usr/lib/gcc/i486-linux-gnu/4.3.3/../../../../lib/crti.o" "/usr/lib/gcc/i486-linux-gnu/4.3.3/crtbegin.o" "-L/usr/lib/gcc/i486-linux-gnu/4.3.3" "-L/usr/lib/gcc/i486-linux-gnu/4.3.3" "-L/usr/lib/gcc/i486-linux-gnu/4.3.3/../../../../lib" "-L/lib/../lib" "-L/usr/lib/../lib" "-L/usr/lib/gcc/i486-linux-gnu/4.3.3/../../.." "/tmp/ccKSwMpH.o" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "-lc" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "/usr/lib/gcc/i486-linux-gnu/4.3.3/crtend.o" "/usr/lib/gcc/i486-linux-gnu/4.3.3/../../../../lib/crtn.o"
Re: Long paths with ../../../../ throughout
I should add, I'm not on this mailing list, so please include my email address in any replies. Cheers, Jon
Re: Long paths with ../../../../ throughout
2010/1/19 Jon Grant : > I should add, I'm not on this mailing list, so please include my email > address in any replies. Also I notice lots of duplicate parameters: Is this directory really needed twice? -L/usr/lib/gcc/i486-linux-gnu/4.3.3 -L/usr/lib/gcc/i486-linux-gnu/4.3.3 also -lgcc_s is mentioned twice, as is -gcc Finally, could collect2 output command lines when in -verbose mode? Currently I can't see what parameters it is calling "ld" with.. when ld fails. I'm not on this mailing list, so please include my email address in any replies. Cheers, Jon
Re: Long paths with ../../../../ throughout
Jon Grant writes: > Any easy way to evaluate and reduce command lines? Consider this: > > /usr/lib/gcc/i486-linux-gnu/4.3.3/../../../../lib/crt1.o > > Is actually the same as: /usr/lib/crt1.o -- which is much clearer! Using this form of path makes it easy to move an installed gcc tree to a new location and have it continue to work correctly. Since normal users never see these paths, the goal is correctness rather than clarity. > Also I notice lots of duplicate parameters: > > Is this directory really needed twice? > -L/usr/lib/gcc/i486-linux-gnu/4.3.3 -L/usr/lib/gcc/i486-linux-gnu/4.3.3 No. I would encourage you to investigate why it is happening. > also -lgcc_s is mentioned twice, as is -gcc This is because on some systems there is a circular dependency between -lgcc and -lc. Some of the functions in -lgcc require functions in -lc. If -lc was compiled with gcc, then on some systems some of the functions in -lc will require -lgcc. Fortunately the functions which -lc requires in -lgcc will never themselves require -lc. So mentioning -lgcc twice, once before -lc and once after, suffices on all systems. > Finally, could collect2 output command lines when in -verbose mode? > Currently I can't see what parameters it is calling "ld" with.. when > ld fails. To see what collect2 is doing, use -Wl,-debug. Ian
Eric Weddington appointed AVR co-maintainer
I am pleased to announce that the GCC Steering Committee has appointed Eric Weddington as AVR co-maintainer. Please join me in congratulating Eric on his new role. Eric, please update your listing in the MAINTAINERS file. Happy hacking! David
Re: Help-The possible places where insn is splitted in greg pass
2010/1/16 fanqifei :
> 2010/1/15 Ian Lance Taylor :
>> There are many places where that insn could be generated, so it's
>> pretty hard to answer your question as asked.
>>
>> I recommend setting a breakpoint on make_insn_raw if
>> cfun->emit->x_cur_insn_uid == 479. Then a backtrace will show you
>> what is creating the insn.
>>
>> Ian
>>
> That insn was generated in subst_reloads() called by reload_as_needed
> in reload1.c.
>
> In greg pass, the instruction#320 needs to be splitted. The cpu
> supports the memory address mode mem(r1*4+r2).
> (insn 320 308 309 19 a.c:381 (set (reg:SI 207 [ .wrData ])
> (mem/s:SI (plus:SI (mult:SI (reg:SI 204)
> (const_int 4 [0x4]))
> (reg/f:SI 234)) [5 .wrData+0 S4 A32])) 3
> {movsi} (expr_list:REG_DEAD (reg:SI 204)
> (nil)))
>
> In find_reloads() (called by reload_as_needed()), following reload
> information was generated.
> (insn 320 308 309 19 a.c:381 (set (reg:SI 14 a14 [orig:207
> .wrData ] [207])
> (mem/s:SI (plus:SI (mult:SI (reg:SI 9 a9 [204])
> (const_int 4 [0x4]))
> (plus:SI (reg/f:SI 16 SP)
> (const_int 96 [0x60]))) [5 .wrData+0 S4
> A32])) 3 {movsi} (expr_list:REG_DEAD (reg:SI 9 a9 [204])
> (nil)))
> Reload 0: reload_in (SI) = (plus:SI (reg/f:SI 16 SP)
> (const_int 96 [0x60]))
> GENERAL_REGS, RELOAD_FOR_INPUT_ADDRESS (opnum = 1)
> reload_in_reg: (plus:SI (reg/f:SI 16 SP)
> (const_int 96 [0x60]))
> reload_reg_rtx: (reg:SI 12 a12)
> Reload 1: reload_in (SI) = (plus:SI (mult:SI (reg:SI 9 a9 [204])
> (const_int 4 [0x4]))
> (plus:SI (reg/f:SI 16 SP)
> (const_int 96 [0x60])))
> GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 1), inc by 4
> reload_in_reg: (plus:SI (mult:SI (reg:SI 9 a9 [204])
> (const_int 4 [0x4]))
> (plus:SI (reg/f:SI 16 SP)
> (const_int 96 [0x60])))
> reload_reg_rtx: (reg:SI 12 a12)
>
> After find_reloads() called, emit_reload_insns() generated insns to
> reload operands. Then subst_reloads() substituted the reload regs
> using the replacement information.
>
> The insn list after subst_reloads():
> (insn 475 308 477 19 a.c:381 (set (reg:SI 12 a12)
> (const_int 96 [0x60])) -1 (nil))
>
> (insn 477 475 478 19 a.c:381 (set (reg:SI 12 a12)
> (reg/f:SI 16 SP)) -1 (nil))
>
> (insn 478 477 479 19 a.c:381 (set (reg:SI 12 a12)
> (plus:SI (reg:SI 12 a12)
> (const_int 96 [0x60]))) -1 (expr_list:REG_EQUIV (plus:SI
> (reg/f:SI 16 SP)
> (const_int 96 [0x60]))
> (nil)))
>
> (insn 479 478 320 19 a.c:381 (set (reg:SI 12 a12)
> (plus:SI (mult:SI (reg:SI 9 a9 [204])
> (const_int 4 [0x4]))
> (reg:SI 12 a12))) -1 (nil))
>
> (insn 320 479 481 19 a.c:381 (set (reg:SI 14 a14 [orig:207
> .wrData ] [207])
> (mem/s:SI (reg:SI 12 a12) [5 .wrData+0 S4 A32])) 3
> {movsi} (expr_list:REG_DEAD (reg:SI 9 a9 [204])
> (nil)))
>
> But insn#479 is not recognized by recog() in insn-recog.c and the
> compilation failed. (recog only recognizes RTL defined in md, right?)
> Here the backtrace is
> reload--->cleanup_subreg_operands--->extract_insn_cached--->extract_insn--->recog_memoized--->recog.
> There is no machine instruction(r3=r1*4+r2) match the pattern of
> insn#479. Though there is pattern r3=mem(r1*4+r2).
> I don’t quite understand the generation of reload information.
> What can I do next?
> Thanks!
>
> Qifei Fan
>
Actually the second reload is not needed if there is already the first reload.
If (plus:SI (reg/f:SI 16 SP) (const_int 96 [0x60]) is replaced by
(reg:SI 12 a12), then (plus:SI (mult:SI (reg:SI 9 a9 [204])
(const_int 4 [0x4])) (reg:SI 12 a12) ) is a valid memory address.
But in function find_reloads, I can’t find the related code that
deciding whether the second reload should be generated by regarding
the previous reload. The function is too complex. :-(
Qifei Fan
gcc-4.4-20100119 is now available
Snapshot gcc-4.4-20100119 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20100119/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch revision 156049 You'll find: gcc-4.4-20100119.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20100119.tar.bz2 C front end and core compiler gcc-ada-4.4-20100119.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20100119.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20100119.tar.bz2 C++ front end and runtime gcc-java-4.4-20100119.tar.bz2 Java front end and runtime gcc-objc-4.4-20100119.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20100119.tar.bz2The GCC testsuite Diffs from 4.4-20100112 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 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.
Re: Why Thumb-2 only allows very limited access to the PC?
Could anybody help to review the small patch http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00531.html thanks Guozhi On Sat, Jan 9, 2010 at 7:25 PM, Carrot Wei wrote: > OK, I filed a bug to trace it. > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42671 > > thanks > Guozhi > > On Thu, Jan 7, 2010 at 6:23 PM, Richard Earnshaw wrote: >> >> On Wed, 2010-01-06 at 18:26 +, Paul Brook wrote: >>> On Wednesday 06 January 2010, Carrot Wei wrote: >>> > So thumb2 can also use the instructions similar to thumb1, right? It >>> > potentially has better performance and smaller code size. >>> >>> Technically yes, however in ARMv7 the relevant instruction (add.n , pc) >>> is deprecated. >> >> Where'd you get that idea? >> >> Annex D of the ARM ARM says that the 16-bit instructions that add SP and >> PC together (writing either SP or PC) are deprecated, but there's >> nothing else using PC that's mentioned there other than trying to move >> PC into SP or vice-versa. All the deprecated instructions in this area >> are pretty meaningless in real life anyway. >> >> R. >> >> >
Fwd: Help - as a beginner how to get started to contribute
Hello GCC experts! I am looking for projects on GCC back end development. Ideally I would like to work on a reasonably sized project that is challenging but not too overwhelm for a beginner. I would like to start with beginner's project listed below (1, 2, 3), and would like to know how to reach the originator of the project, which is not listed in that web page. I assume the process is first to notify the owner that I am working on the specific project, get more context information, work and deliver, get reviewed and submit (after signing some legal papers) but I am not sure.. Also it'll be much appreciated if someone has any suggestions on possible projects I could start work on to bootstrap myself on GCC development. ~Michael -- Forwarded message -- From: Ian Lance Taylor Date: Tue, Jan 19, 2010 at 11:44 PM Subject: Re: Help - as a beginner how to get started to contribute To: Michael Han Cc: "Paulo J. Matos" , gcc-h...@gcc.gnu.org Michael Han writes: > Yeah... also I found the some of projects listed on gcc wiki > (http://gcc.gnu.org/wiki) has listed projects' owners, but I guess I'd > better stick to the simple project for now consider I am a beginner. > > So does anyone know how to contact the owner of the following projects > which I am currently particularly interested in, as listed on simple > gcc projects page? > 1. Make insn-recog.c use a byte-coded DFA > 2. Convert reorg.c to use the flow graph > 3. Find all the places that simplify RTL and make them use simplify-rtx.c That is a good question but I don't have a good answer. If you are interested in one of those, I recommend writing to g...@gcc.gnu.org. The unstated goal of number 1 is to speed up the generated code in insn-recog.c. That would be a nice small improvement in compilation time. Take a look at insn-recog.c and see what you come up with. Number 2 is a rather hairy problem: getting reorg.c to use things like cfglayout mode and the dataflow information, rather than its own private resource management code in resource.c. This is only mildly interesting as most popular targets do not use the code in reorg.c. I'm not sure what the status of number 3 is. I hope that there aren't too many places which are not using simplify-rtx.c anyhow. The list of open projects gets cleaned up occasionally but not very often. There are a lot of good ideas on http://gcc.gnu.org/wiki/ in the links under "Improving GCC". Ian -- If first the idea is not absurd, then there is no hope for it
