What does this character mean in gcc's md file?
I've been studying DLX's md file for GCC. I have a question about the following lines in this file, ;; ;; Float compares. ;; The RTL for these is also generated in ;; gen_conditional_branch(). ;; (define_insn "" [(set (match_operand:CCFP 0 "register_operand" "=z") (match_operator:SF 1 "signed_comparison_operator" [(match_operand:SF 2 "register_operand" "f") (match_operand:SF 3 "register_operand" "f")]))] "" "%C1f\\t%2,%3" [(set_attr "type" "fp") (set_attr "mode" "SF")]) This pattern outputs float compare instruction. "%C" in the output template is defined in dlx.c to be one of eq, ne, gt, lt, le and neq. DLX's assembly code for float compare has the format of "*f op1, op2", where * is to be substituted by eq, ne, gt, I don't know the meaning of the numeric character "1" between "%C" and "f" in the output template. ___ 快来雅虎邮箱发贺卡，拜大年啦！ http://cn.mail.yahoo.com/promo/greetings/
What does this character mean in DLX's md file?
I've been studying DLX's md file for GCC. I have a question about the following lines in this file, ;; ;; Float compares. ;; The RTL for these is also generated in ;; gen_conditional_branch(). ;; (define_insn "" [(set (match_operand:CCFP 0 "register_operand" "=z") (match_operator:SF 1 "signed_comparison_operator" [(match_operand:SF 2 "register_operand" "f") (match_operand:SF 3 "register_operand" "f")]))] "" "%C1f\\t%2,%3" [(set_attr "type" "fp") (set_attr "mode" "SF")]) This pattern outputs float compare instruction. "%C" in the output template is defined in dlx.c to be one of eq, ne, gt, lt, le and neq. DLX's assembly code for float compare has the format of "*f op1, op2", where * is to be substituted by eq, ne, gt, I don't know the meaning of the numeric character "1" between "%C" and "f" in the output template. Attached is DLX's md file. ___ 雅虎1G免费邮箱百分百防垃圾信 http://cn.mail.yahoo.com/ DLX.rar Description: 2680642989-DLX.rar
Re: What does this character mean in DLX's md file?
(define_insn "" [(set (match_operand:CCFP 0 "register_operand" "=z") (match_operator:SF 1 "signed_comparison_operator" [(match_operand:SF 2 "register_operand" "f") (match_operand:SF 3 "register_operand" "f")]))] "" "%C1f\\t%2,%3" [(set_attr "type" "fp") (set_attr "mode" "SF")]) This pattern outputs float compare instruction. "%C" in the output template is defined in dlx.c to be one of eq, ne, gt, lt, le and neq. DLX's assembly code for float compare has the format of "*f op1, op2", where * is to be substituted by eq, ne, gt, I don't know the meaning of the numeric character "1" between "%C" and "f" in the output template. It means that operand 1 (the signed_comparison_operator) is passed to the dlx.c routine. Likewise for %2 and %3. Attached is DLX's md file. The whole content of the file is not relevant. Paolo
Re: What does this character mean in DLX's md file?
On Thu, 19 Jan 2006, Paolo Bonzini wrote: > > (define_insn "" ... > > "%C1f\\t%2,%3" > > I don't know the meaning of the > > numeric character "1" between "%C" and "f" in the output template. > > It means that operand 1 (the signed_comparison_operator) is passed to > the dlx.c routine. Likewise for %2 and %3. The "routine" in question being the expansion of the target macro PRINT_OPERAND. See the documentation. brgds, H-P
Thread support in GCC
I've localized the supporting module in GCC for threads (gthr.h and gthr-xxx.h). These primitives seems fairly easy to support, but there seems to be a major flaw in them. While there is an initialization macro, there is no descruction macro. This is problematic when these functions need to allocate kernel reasources, that must eventually be reclaimed. It is no problem to free these up on termination, but if they build up during execution, it would be problematic. Are these objects created at load time and kept for the duration of the run or are they sometimes allocated and reallocated? Leif Ekblad www.rdos.net/rdos
Draft: 12 Jan 06 notes from GCC improvement for Itanium conference call
ON THE CALL: Shin-ming Liu (HP), Vladimir Makarov (Red Hat), Diego Novillo (Red Hat), Mark Smith (Gelato), Bob Kidd (UIUC), Andrey Belevantsev (RAS), Arutyun Avetisyan (RAS) Dan Berlin (IBM) was not able to join the call but did email an aliasing update (see below). We spent some time up front discussing the GCC track at the upcoming Gelato ICE conference (www.gelato.org/meeting). Potential topics and speaker candidates include: 1) Parallel programming with GCC - Diego Novillo 2) Aliasing - Diego Novillo or Dan Berlin (Diego to coordinate with Dan) 3) LLVM - Chris Lattner? (Mark will approach Chris) 4) LTO - Mark Mitchell? (Shin-ming will approach Mark M.) 5) ORC back end for GCC - Shin-Ming Liu 6) Superblock work - Bob Kidd 7) GCC IP issues - Dan Berlin? (Diego will ask Dan) 8) NUDT update - Canqun Yang? (Mark will approach Canqun) 9) RAS update - Andrey Belevantsev and Arutyun Avetisyan 10) Intel micro-architecture talk - Cameron McNairy Also we discussed holding a face-to-face GCC Improvement meeting in mid August in Moscow. Expected benefits: strong participation from Europe GCC community, Intel Moscow, and RAS. Updates from call participants can be found below. NEXT MEETING: Feb 16th, 2006. Details will be emailed out prior to the call. Dan Berlin: --- Update on aliasing: Improvements to the actual points-to analyzer from the improved-aliasing-branch of gcc have been merged into mainline. This includes: 1. An initial implementation of interprocedural pointer analysis (though this is disabled by default for the moment until i finish some follow up patches). 2. Significantly better results for pointers inside structures. 3. Not punting on structures that contain arrays (we used to treat all the fields like a single variable). There is work by Richard Guenther on treating small arrays as if they were structures so we can get better information about them (without resorting to pair based querying). Work on the aliasing query system for those optimizations that want to disambiguate results for specific stores/loads better than we do now will start soon on IAB. Call clobbering changes from IAB are in the process of being merged into the mainline. This mainly consists of much better non-context sensitive intraprocedural call clobbering information, combined with better use of the interprocedural clobber information for static variables that we compute. Once the aliasing query system is done, i will revisit this and implement some context-sensitive analysis for call clobbering to get better results. I also reviewed the patch for propagating points-to sets to RTL, and sent the review to the list. Andrey Belevantsev: --- Dan Berlin has reviewed the alias propagation patch about two weeks ago. Diego mentioned that his concerns about the patch are in line with Dan's. I had a chance to read the review only recently due to the mail problems of our provider. Dan has pointed out to the implementation flaw of the patch, which is using varrays for storing points-to sets instead of bitmaps. This should be fixed to avoid memory and compilation time issues. There are some other less serious issues and the coding style issues. We are going to fix all problems pointed to by Dan and resend the patch. We've sent five parts of the speculation patch to the gcc-patches list, and Vladimir Makarov has taken them for the review. Some issues were already raised in the list, mentioning documentation issues and the effects of the patch for the other platforms. For the x86-64, the influence of the patch is pretty neutral. We're going to address the issues Vlad would probably raise in his review and then resend the patch. We're advancing in the implementation of the new scheduler. We're working on the code motion part, which fixes the scheduling DAG and the data sets after the selected insruction has been scheduled. Part of those is already implemented and under testing. Another part we're starting to work on is the selection of the best instruction for scheduling from the set of available ones. We plan to adopt the corresponding routines from the haifa scheduler. Bob Kidd: - The Superblock formation pass now duplicates the loop header to allow Superblock loops to be unrolled. On a trivial test case, this improves performance on x86_64 and PPC. I'm currently benchmarking the patch on SPEC. Vladimir Makarov: - I am working on review of ISP RAS patch for control and data specualtion support. In general the patch is ok. As for idea of gelato meeting devoted to gcc in Moscow, that is a not bad place because gcc developers from Europe could be there. But probably time (August) is not so good. Diego Novillo: -- I briefly described the OpenMP implementation and what it requires in terms of runtime support. It is now being merged into mainline to be released with GCC 4.2. The Fedora Core GCC 4.1 compiler will also include it. It should work well on Itani
Re: Parallel build failure in c-pragma.o missing gt-c-pragma.h
> I'm getting a parallel build failure on mainline like so: > > > make[3]: *** No rule to make target `gt-c-pragma.h', needed by > `c-pragma.o'. Stop. > > We have c-pragma.o depend on gt-c-pragma.h, but there's no rule to > build gt-c-pragma.h. I assume gt-c-pragma.h needs to depend on > s-gtype, but I thought that was handled by the automatically generated > ALL_GTFILES_H dependency: > > > $(ALL_GTFILES_H) : s-gtype ; @true > > Then I see below it manual listings of the gt-* files depending on > s-gtype. So what does the ALL_GTFILES_H rule do? Turns out the problem was I had /usr/ucb in my path. The rule in ALL_GTFILES_H does: tr ' ' '\n' but newlines don't work with /usr/ucb/tr. When I use /bin/tr instead, it works (I'm on solaris2.10). So a word of caution to anyone using /usr/ucb ... don't do it. --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: GCC can't stop using GNU libiconv if it's in /usr/local
> > IMHO, the fact that GCC includes /usr/local/include by default in > > it's system header search path is brain damaged, but it's probably > > way too entrenched to revisit that. :-( > > You can stop this by specifying --with-local-prefix=/not-usr-local > when configuring GCC. Aha, --with-local-prefix= plus --without-libiconv-prefix did the trick for me. Thanks, --Kaveh PS: --with-local-prefix= wasn't documented in cpp.texi, only in install.texi which is why I missed it. Thanks again. -- Kaveh R. Ghazi [EMAIL PROTECTED]
RE: GCC can't stop using GNU libiconv if it's in /usr/local
Kaveh R. Ghazi wrote: > PS: --with-local-prefix= wasn't documented in cpp.texi, only in > install.texi Why would you expect to find install instructions in the preprocessor manual, rather than the installation manual? cheers, DaveK -- Can't think of a witty .sigline today
Re: GCC can't stop using GNU libiconv if it's in /usr/local
> Why would you expect to find install instructions in the > preprocessor manual, rather than the installation manual? Because the problem was caused by the preprocessor. I was looking for a *runtime* flag to change this behavior, (hence cpp.texi). Only in hindsight (20/20) did it become clear that this was a configure (and therefore installation) option. -- Kaveh R. Ghazi [EMAIL PROTECTED]
RE: GCC can't stop using GNU libiconv if it's in /usr/local
Kaveh R. Ghazi wrote: > > Why would you expect to find install instructions in the > > preprocessor manual, rather than the installation manual? > > Because the problem was caused by the preprocessor. I was looking for > a *runtime* flag to change this behavior, (hence cpp.texi). Only in > hindsight (20/20) did it become clear that this was a configure (and > therefore installation) option. Heh, gotcha. That sentence did read awfully strangely without a bit of explanation though! cheers, DaveK -- Can't think of a witty .sigline today
Re: [HELP] GCC 4.1 branch Ada status on powerpc-darwin?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric Botcazou wrote: |>Yes the workaround is to add -fexceptions or -shared-libgcc to the |>command line when linking libgnat but I don't know if that is the correct |>fix or some hacking to config/darwin.h is needed. | | | Thanks. However, that's not sufficient because the tools fail to build too: I'm adding Geoff Keating to the CC, hoping that he'll both shout at me while explaining why this change to darwin.h is broken, and suggest a real fix. This change allows gcc to build on powerpc-apple-darwin8.4 with ada. Peter -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Darwin) iQCVAwUBQ8/HhbiDAg3OZTLPAQJpowQAnZLRilL7mE1l9LLwETXKWYFarWC+2DSl J00YAywB5cDF+J1emf3ET7S4ZFgZ1Wvl9fJVutvgnVTWkvnnBm8nI+hFSHY93dUZ 9jK7/dyzWUQol4kG55bmNJDNjxr0wSx27RHafo6ktxQF0CwXQN+nzGJo9AU6mnaf foTpzV+E64s= =NJtm -END PGP SIGNATURE- Index: gcc/config/darwin.h === --- gcc/config/darwin.h (revision 109965) +++ gcc/config/darwin.h (working copy) @@ -324,6 +324,7 @@ -lgcc; \ :%:version-compare(>< 10.3.9 10.5 mmacosx-version-min= -lgcc_s.10.4) \ %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_s.10.5) \ + %:version-compare(!> 10.3.9 mmacosx-version-min= -lgcc_eh) \ -lgcc}" /* We specify crt0.o as -lcrt0.o so that ld will search the library path. */
Re: Status of -fstack-usage?
Hello, Ioannis E. Venetis wrote: > Having followed this thread and searched a little bit more, I understand > that -fstack-usage will dump information into a file at compile time. Right. > However, I was wondering whether something similar would be possible at > run-time. > > I am working on multithreaded libraries and I know that many > multithreaded languages have compilers that calculate the required stack > size and pass this information on to the associated library. This way, > they can handle efficiently memory. However, this is a problem in > standalone libraries. If we could have something like: > > stack_size = __builtin_stack_size() > > that returns the maximum required stack size for , > multithreaded libraries could take advantage of it at run-time, in order > to allocate only the amount of required memory. Interesting idea :) > This is of course not a complete proposal for something, just asking if > something like that would be possible at all. Well, it depends :) Would __builtin_stack_size (F) retrieve information about F's stack frame only, or would it also recursively account for every other function that F may call ? Implementing the former is probably possible, though I'm not sure exactly how useful it would be. The latter would no doubt be much^a_lot harder.
Re: Status of -fstack-usage?
I sent the following to Olivier, but forgot to CC this list. Ioannis Hello, Well, it depends :) Would __builtin_stack_size (F) retrieve information about F's stack frame only, or would it also recursively account for every other function that F may call ? Implementing the former is probably possible, though I'm not sure exactly how useful it would be. I agree that the former is probably not very useful. If a function is set to run as a thread and it calls other functions, the stack required for those functions should be accounted for. Probably the second option is much more useful. I had a look here: http://gcc.gnu.org/onlinedocs/gnat_ugn_unw/Static-Stack-Usage-Analysis.html I think that the best would be __builtin_stack_size(F) to return what is described as "dynamic" and "bounded" in the above link. Maybe a return value of -1 could be used to mean that it was not possible to retrieve this information. A library could then use a default, bigger stack for that thread. Except from recursive functions, what are the other cases where the above size cannot be computed statically? Ioannis
Re: [HELP] GCC 4.1 branch Ada status on powerpc-darwin?
On 19/01/2006, at 9:08 AM, Peter O'Gorman wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric Botcazou wrote: |>Yes the workaround is to add -fexceptions or -shared-libgcc to the |>command line when linking libgnat but I don't know if that is the correct |>fix or some hacking to config/darwin.h is needed. | | | Thanks. However, that's not sufficient because the tools fail to build too: I'm adding Geoff Keating to the CC, hoping that he'll both shout at me while explaining why this change to darwin.h is broken, and suggest a real fix. If ADA is going to use exceptions, then it needs to do what G++ does, which is pass -shared-libgcc in its driver. This change allows gcc to build on powerpc-apple-darwin8.4 with ada. It's not OK because for forwards binary compatibility the shared libgcc must be used for exception handling. Peter -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Darwin) iQCVAwUBQ8/HhbiDAg3OZTLPAQJpowQAnZLRilL7mE1l9LLwETXKWYFarWC+2DSl J00YAywB5cDF+J1emf3ET7S4ZFgZ1Wvl9fJVutvgnVTWkvnnBm8nI+hFSHY93dUZ 9jK7/dyzWUQol4kG55bmNJDNjxr0wSx27RHafo6ktxQF0CwXQN+nzGJo9AU6mnaf foTpzV+E64s= =NJtm -END PGP SIGNATURE- Index: gcc/config/darwin.h === --- gcc/config/darwin.h (revision 109965) +++ gcc/config/darwin.h (working copy) @@ -324,6 +324,7 @@ -lgcc; \ :%:version-compare(>< 10.3.9 10.5 mmacosx-version-min= - lgcc_s.10.4) \ %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_s. 10.5) \ + %:version-compare(!> 10.3.9 mmacosx-version-min= - lgcc_eh) \ -lgcc}" /* We specify crt0.o as -lcrt0.o so that ld will search the library path. */ smime.p7s Description: S/MIME cryptographic signature
Re: matrix linking
On Jan 18, 2006, at 10:24 PM, [EMAIL PROTECTED] wrote:
I thought some kind of that, yet moved to matrix approach. Reason?
The clarity.
Clarity is not an in-vogue reason for compiler code generation. Size
is, speed is. Sacrificing these two for clarity in generated code
limits the end result to that of novelty item.
For instance you have many ... let me say 'revisions' of the same
function. In
your case it is obvious how to handle jump to the newly compiled
function, but
how to handle roll-back to some particular revision of this function?
If my scheme supports changing from X' to X'', then clearly it
supports changing from X'' to X'. Just google undo buffer for an
example algorithm that will do this.
How about revisioning for file and for module?
A file is just a collection of units, if you can do a unit, you can
do a file (let me ignore file scope ctors/dtors for a second).
Module, what's that?
These thought restrained me from doing any assembler hacks into the
system.
Modifying the assembler would be bad.
One more thing. My original purpose was to make possible to modify the
algorithms runtime, without recompilation. For this case we need
interpreter.
If you're intention is to write an interpreter, that this is
orthogonal to runtime rebinding. This list would be off-topic for
discussing writing a C interpreter.
you may find this topic interesting:
http://docs.georgeshagov.com/twiki/tiki-index.php?page=Matrix
+Linking+-+Proxing)
Can't manage to read it, posting links I can't read is bad style.
Synchronization and other challenges.
Mike, do you have a copyright on that phrase: "there are certain
realities when
doing this, and its important to understand the limitations and
gotchas. " ?
Yes, US law makes everything I write copyright. :-)/2
About my initial approach. I completely reviewed it :-). it looks
like this:
http://docs.georgeshagov.com/twiki/tiki-index.php?page=Matrix
+Linking+-+The+shortest+way+to+go,
it would appear it is required to make an additional pass in order
to formalize
the matrix.
This looks all wrong. See Objective C for an example of a
dynamically rebindable language, further, you can examine the code
generation, the data structures and runtime library to see how they
achieve things. It doesn't need mlmake and doesn't need 'new passes'
run by make. For example, you can see the gcc darwin port for how to
generate a stub function that does some arbitrary thing inside a
compiler.
Dear Mike, I would be really interested in some questions regarded
runtime
linker. I am going to download the sources, yet in that same time
if it be
there is any additional dos about that, I would be really
appreciate for the
link.
If you're talking about the runtime rebinder we use, don't know of
any. For a generic runtime linker, google("ld.so") will take you to
the sources for one.
libgomp & solaris
Hello, Andrew P. wanted me to report the issues I encountered with libgomp and solaris on head. In team.c solaris fails due to the fact that alloca is defined in alloca.h iso stdlib.h, config/posix/proc.c fails in a similar manner due to the fact that getloadavg is defined in sys/loadavg.h The next issue is the -pthread in the config stuff. Solaris does not like it :) -pthreads instead. If I find the time I'll come up with a proper patch. But for now just the report. Regards, Andreas [vw_andreas_main] [EMAIL PROTECTED]:/export/data/devel-test/gcc-svn/trunk/libgomp> svn diff team.c config/posix/proc.c Index: team.c === --- team.c (revision 109942) +++ team.c (working copy) @@ -31,6 +31,7 @@ #include "libgomp.h" #include #include +#include /* This array manages threads spawned from the top level, which will Index: config/posix/proc.c === --- config/posix/proc.c (revision 109942) +++ config/posix/proc.c (working copy) @@ -34,6 +34,7 @@ #include "libgomp.h" #include #include +#include /* At startup, determine the default number of threads. It would seem
Re: libgomp & solaris
On Thu, Jan 19, 2006 at 10:45:39PM +0100, Andreas Tobler wrote: > In team.c solaris fails due to the fact that alloca is defined in > alloca.h iso stdlib.h ... Er, *not* defined did you mean? This should probably be fixed with a #define to __builtin_alloca in libgomp.h or so. > config/posix/proc.c fails in a similar manner due > to the fact that getloadavg is defined in sys/loadavg.h Easy, more configury near getloadavg detection. > The next issue is the -pthread in the config stuff. Solaris does not > like it :) -pthreads instead. Sounds like a typo in the specs for the platform. r~
gcc-4.0-20060119 is now available
Snapshot gcc-4.0-20060119 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20060119/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.0 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_0-branch revision 109984 You'll find: gcc-4.0-20060119.tar.bz2 Complete GCC (includes all of below) gcc-core-4.0-20060119.tar.bz2 C front end and core compiler gcc-ada-4.0-20060119.tar.bz2 Ada front end and runtime gcc-fortran-4.0-20060119.tar.bz2 Fortran front end and runtime gcc-g++-4.0-20060119.tar.bz2 C++ front end and runtime gcc-java-4.0-20060119.tar.bz2 Java front end and runtime gcc-objc-4.0-20060119.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.0-20060119.tar.bz2The GCC testsuite Diffs from 4.0-20060112 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.0 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.
libgomp and OMP_NUM_THREADS
Hello, It appears that although the most recent svn update (Revision 109975) of gcc compiles apparently fine, simple OpenMP programs will only operate when OMP_NUM_THREADS=1. I am compiling and running gcc on a Dual CPU G5 PowerPC running OS X 10.4.4. If I compile omp_hello.c from testsuite/libgomp.c with gcc -fopenmp omp_hello.c -o omp_hello -lgomp then the program reports that 1 thread is created. If I then set OMP_NUM_THREADS=2, omp_hello hangs. If one runs recomplies this program, runs it in gdb and Ctrl-C's it when it hangs, here is the backtrace generated #0 0x900c48fc in sem_wait () #1 0x00020c24 in gomp_sem_wait (sem=0x222c4) at ../../../gomp/ libgomp/config/posix/sem.c:44 #2 0x00020d68 in gomp_barrier_wait_end (bar=0x22298, last=4294967295) at ../../../gomp/libgomp/config/posix/bar.c:92 #3 0x000202f8 in gomp_team_start (fn=0x2a08 , data=0x0, nthreads=2, work_share=0x0) at ../../../gomp/libgomp/team.c: 293 #4 0x29e0 in main (argc=1, argv=0xb714) at omp_hello.c:33 Thanks, Walter Szeliga
Re: RTL alias analysis
On Tuesday 03 January 2006 17:27, Richard Henderson wrote: > On Mon, Jan 02, 2006 at 12:45:49AM -0500, Daniel Berlin wrote: > > ... the real > > solution is to transfer the information that the stack space sharing > > knows into some simple set form, and use *that directly* in alias.c, and > > check it *first*, so that if they have the same stack slot, we say there > > is a dependence, even if the memory expressions/types/etc look > > different. > > ... And that doesn't work for the test case, because we've > carefuly thrown away any information that might have given > us any information wrt the stack slots. > > I'll have to give this some thought. Hi rth, Is your "think this over"-process still runnig? ;-) We've tried to add some more food for thought in the audit trail of PR25654, which is tracking this issue. Hope you'll add your thoughts so far, so that we can make some progress on getting a PR GCC 4.1 regression fixed... Gr. Steven
Re: libgomp and OMP_NUM_THREADS
On Thu, Jan 19, 2006 at 04:35:17PM -0700, Walter Szeliga wrote:
> Hello,
> It appears that although the most recent svn update (Revision
> 109975) of gcc compiles apparently fine, simple OpenMP programs will
> only operate when OMP_NUM_THREADS=1. I am compiling and running gcc
> on a Dual CPU G5 PowerPC running OS X 10.4.4. If I compile
> omp_hello.c from testsuite/libgomp.c with
>
> gcc -fopenmp omp_hello.c -o omp_hello -lgomp
>
> then the program reports that 1 thread is created. If I then set
> OMP_NUM_THREADS=2, omp_hello hangs. If one runs recomplies this
> program, runs it in gdb and Ctrl-C's it when it hangs, here is the
> backtrace generated
Yeah, that's a known thing, libgomp is miscompiled on PowerPC.
>
> #0 0x900c48fc in sem_wait ()
> #1 0x00020c24 in gomp_sem_wait (sem=0x222c4) at ../../../gomp/
> libgomp/config/posix/sem.c:44
> #2 0x00020d68 in gomp_barrier_wait_end (bar=0x22298,
> last=4294967295) at ../../../gomp/libgomp/config/posix/bar.c:92
> #3 0x000202f8 in gomp_team_start (fn=0x2a08 ,
> data=0x0, nthreads=2, work_share=0x0) at ../../../gomp/libgomp/team.c:
> 293
> #4 0x29e0 in main (argc=1, argv=0xb714) at omp_hello.c:33
On redhat/gcc-4_1-branch (which has also a gomp branch backport)
I'm using following patch that cures it, but I bet it won't apply cleanly
to the trunk.
2005-11-25 Jakub Jelinek <[EMAIL PROTECTED]>
* config/rs6000/rs6000.md (UNSPEC_LWSYNC, UNSPEC_ISYNC,
UNSPEC_SYNC_OP, UNSPEC_ATOMIC, UNSPEC_CMPXCHG, UNSPEC_XCHG): Rename
to...
(UNSPECV_LWSYNC, UNSPECV_ISYNC, UNSPECV_SYNC_OP, UNSPECV_ATOMIC,
UNSPECV_CMPXCHG, UNSPECV_XCHG): ... these.
* config/rs6000/sync.md: Adjust for the above changes, use
unspec_volatile instead of unspec for
UNSPECV_{SYNC_OP,ATOMIC,CMPXCHG,XCHG}.
--- gcc/config/rs6000/sync.md.jj2005-11-24 13:24:35.0 +0100
+++ gcc/config/rs6000/sync.md 2005-11-25 10:43:31.0 +0100
@@ -70,10 +70,10 @@
[(set (match_operand:GPR 0 "gpc_reg_operand" "=&r")
(match_operand:GPR 1 "memory_operand" "+Z"))
(set (match_dup 1)
- (unspec:GPR
+ (unspec_volatile:GPR
[(match_operand:GPR 2 "reg_or_short_operand" "rI")
(match_operand:GPR 3 "gpc_reg_operand" "r")]
- UNSPEC_CMPXCHG))
+ UNSPECV_CMPXCHG))
(clobber (match_scratch:GPR 4 "=&r"))
(clobber (match_scratch:CC 5 "=&x"))]
"TARGET_POWERPC"
@@ -90,9 +90,9 @@
[(set (match_operand:GPR 0 "gpc_reg_operand" "=&r")
(match_operand:GPR 1 "memory_operand" "+Z"))
(set (match_dup 1)
- (unspec:GPR
+ (unspec_volatile:GPR
[(match_operand:GPR 2 "reg_or_short_operand" "rL")]
- UNSPEC_XCHG))
+ UNSPECV_XCHG))
(clobber (match_scratch:GPR 3 "=&r"))
(clobber (match_scratch:CC 4 "=&x"))]
"TARGET_POWERPC"
@@ -107,10 +107,10 @@
(define_expand "sync_"
[(parallel [(set (match_operand:INT1 0 "memory_operand" "")
- (unspec:INT1
+ (unspec_volatile:INT1
[(FETCHOP:INT1 (match_dup 0)
(match_operand:INT1 1 "" ""))]
-UNSPEC_ATOMIC))
+UNSPECV_ATOMIC))
(clobber (scratch:INT1))
(clobber (scratch:CC))])]
"TARGET_POWERPC"
@@ -128,10 +128,10 @@
(define_insn_and_split "*sync_si_internal"
[(set (match_operand:SI 0 "memory_operand" "+Z")
- (unspec:SI
+ (unspec_volatile:SI
[(FETCHOP:SI (match_dup 0)
(match_operand:SI 1 "" ""))]
- UNSPEC_ATOMIC))
+ UNSPECV_ATOMIC))
(clobber (match_scratch:SI 2 "=&b"))
(clobber (match_scratch:CC 3 "=&x"))]
"TARGET_POWERPC"
@@ -146,10 +146,10 @@
(define_insn_and_split "*sync_di_internal"
[(set (match_operand:DI 0 "memory_operand" "+Z")
- (unspec:DI
+ (unspec_volatile:DI
[(FETCHOP:DI (match_dup 0)
(match_operand:DI 1 "" ""))]
- UNSPEC_ATOMIC))
+ UNSPECV_ATOMIC))
(clobber (match_scratch:DI 2 "=&b"))
(clobber (match_scratch:CC 3 "=&x"))]
"TARGET_POWERPC"
@@ -164,10 +164,10 @@
(define_expand "sync_nand"
[(parallel [(set (match_operand:INT1 0 "memory_operand" "")
- (unspec:INT1
+ (unspec_volatile:INT1
[(and:INT1 (not:INT1 (match_dup 0))
(match_operand:INT1 1 "gpc_reg_operand" ""))]
- UNSPEC_ATOMIC))
+ UNSPECV_ATOMIC))
(clobber (scratch:INT1))
(clobber (scratch:CC))])]
"TARGET_POWERPC"
@@ -187,10 +187,10 @@
(define_insn_and_split "*sync_nand_internal"
[(set (match_operand:GPR 0 "memory_operand" "+Z")
- (unspec:GPR
+ (unspec_volatile:GPR
[(and:GPR (not:GPR (match_dup 0))
(match_operand:GPR 1 "gpc_reg_operand" "r"))]
- UNSPEC_ATOMIC))
+ UNSPECV_ATOMIC))
(clobber (match_scratch:GPR 2 "=&r"))
(clobber (match_s
Re: matrix linking
[EMAIL PROTECTED] wrote: Dear Mike, dear Sirs. Thank you very much for the letter. The idea of runtime linking seems to be quite natural, therefore last half a year couple of time I thought myself a madman. I am glad to see your letter, it means if it be I am crazy I am not alone :-) Natural enough that it has been part of the COBOL standard since 1966 :-)
Re: RELOAD_OTHER bug?
This seems to have gotten forgotten: > Date: Wed, 14 Dec 2005 21:12:20 -0500 > From: DJ Delorie <[EMAIL PROTECTED]> > CC: gcc@gcc.gnu.org, ian@airs.com > It seems like the very next thing it does is generate and emit the > reload insns via emit_reload_insns(). > > However, I modified my logic to check to see if the other thing we're > merging with is also an address; if it's not, we stick with > RELOAD_OTHER. I fiddled with the logic to look for reloads for the > new RELOAD_FOR_OTHER_ADDRESS too, but I suspect if we find any, > something may go wrong anyway. http://gcc.gnu.org/ml/gcc/2005-12/msg00377.html
Re: libgomp and OMP_NUM_THREADS
> Jakub Jelinek writes: Jakub> * config/rs6000/rs6000.md (UNSPEC_LWSYNC, UNSPEC_ISYNC, Jakub> UNSPEC_SYNC_OP, UNSPEC_ATOMIC, UNSPEC_CMPXCHG, UNSPEC_XCHG): Rename Jakub> to... Jakub> (UNSPECV_LWSYNC, UNSPECV_ISYNC, UNSPECV_SYNC_OP, UNSPECV_ATOMIC, Jakub> UNSPECV_CMPXCHG, UNSPECV_XCHG): ... these. I thought Geoff and Richard agreed that volatile was not necessary. David
Re: -Wpointer-sign for GCC 4.1
Joe Buck wrote: > So the answer is that, after consulting with some of the affected people > (which is why you got mail, Mike) the SC told RMS that it would be > changed. If it hasn't been done yet, then it's a release blocker, > because it was a promise the SC made. Since you seem to have a handle on the outcome of the discussion, would you please create a Bugzilla entry for this, targeted at 4.1, explaining what it is the SC agreed to do? Otherwise, I'm certain to forget about this issue... Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: insv vs one-bit fields
Re-revisiting it... > Revisiting an old thread... > > On Fri, Sep 02, 2005 at 09:40:20PM -0400, DJ Delorie wrote: > > > So... why is it illegal to put a constant into a single bit field? > > > > Probably because it was more efficient to use some other pattern > > for some other target. > > That's a bad reason to put it in the MI code, since the target could > simply reject those requests itself. Does anyone remember which > target needed this? If not, can we remove that test? Nobody has said anything about this for the last two weeks. Can we remove this restriction now?
Re: What does this character mean in gcc's md file?
ZengNan <[EMAIL PROTECTED]> writes: > (define_insn "" > [(set (match_operand:CCFP 0 "register_operand" "=z") > (match_operator:SF 1 "signed_comparison_operator" > [(match_operand:SF 2 "register_operand" "f") > (match_operand:SF 3 "register_operand" "f")]))] > "" > "%C1f\\t%2,%3" > [(set_attr "type" "fp") >(set_attr "mode" "SF")]) > > This pattern outputs float compare instruction. "%C" in the output template > is defined in dlx.c to > be one of eq, ne, gt, lt, le and neq. DLX's assembly code for float compare > has the format of "*f > op1, op2", where * is to be substituted by eq, ne, gt, I don't know the > meaning of the > numeric character "1" between "%C" and "f" in the output template. It is the operand number which is used to determine what to print for %C. In this case the match_operator:SF, which is operand 1 in the pattern (the 1 appears explicitly above). Ian
Mainline bootstrap failure (revision 110017)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Mainline fails to bootstrap for me (revision 110017)
on i686-pc-linux-gnu.
Configured as:
$GCC_SRC_DIR/configure --prefix=$HOME/gcc --enable-languages=c,c++,java \
- --with-as=/home/ranmath/gnu/bin/as --with-gnu-as \
- --with-ld=/home/ranmath/gnu/bin/ld --with-gnu-ld \
- --with-arch=pentium4 --with-tune=pentium4 \
- --disable-nls --disable-checking --disable-libmudflap \
- --disable-debug --enable-threads=posix --enable-__cxa_atexit \
- --disable-static
Information from GDB (version 6.4):
--- 8< ---
(gdb) r
Starting program: /home/ranmath/src/gcc/build/gcc/cc1 -quiet -I. -I. -I/home/ran
math/src/gcc/gcc/gcc -I/home/ranmath/src/gcc/gcc/gcc/. -I/home/ranmath/src/gcc/g
cc/gcc/../include -I/home/ranmath/src/gcc/gcc/gcc/../libcpp/include -I/home/ranm
ath/src/gcc/gcc/gcc/../libdecnumber -I../libdecnumber -iprefix /home/ranmath/src
/gcc/build/gcc/../lib/gcc/i686-pc-linux-gnu/4.2.0/ -isystem ./include -DIN_GCC -
DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DL_gcov -isystem /home
/ranmath/gcc/i686-pc-linux-gnu/include -isystem /home/ranmath/gcc/i686-pc-linux-
gnu/sys-include -isystem ./include /home/ranmath/src/gcc/gcc/gcc/libgcov.c -quie
t -dumpbase libgcov.c -march=pentium4 -auxbase-strip libgcc/./_gcov.o -g -O2 -W
- -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-defin
ition -fPIC -o /tmp/ccTrGLVi.s
Program received signal SIGSEGV, Segmentation fault.
0x0812d02c in bitmap_obstack_free (map=0x8688638)
at /home/ranmath/src/gcc/gcc/gcc/bitmap.c:272
272 map->first = (void *)map->obstack->heads;
(gdb) l
267 bitmap_obstack_free (bitmap map)
268 {
269 if (map)
270 {
271 bitmap_clear (map);
272 map->first = (void *)map->obstack->heads;
273 map->obstack->heads = map;
274 }
275 }
276
(gdb) p map->obstack
$2 = (bitmap_obstack *) 0x3ff
(gdb) bt
#0 0x0812d02c in bitmap_obstack_free (map=0x8688638)
at /home/ranmath/src/gcc/gcc/gcc/bitmap.c:272
During symbol reading, incomplete CFI data; unspecified registers (e.g., eax) at
0x812d00f.
During symbol reading, incomplete CFI data; unspecified registers (e.g., ecx) at
0x812d00f.
During symbol reading, incomplete CFI data; unspecified registers (e.g., edx) at
0x812d00f.
During symbol reading, incomplete CFI data; unspecified registers (e.g., ebx) at
0x812d00f.
During symbol reading, incomplete CFI data; unspecified registers (e.g., esi) at
0x812d00f.
During symbol reading, incomplete CFI data; unspecified registers (e.g., edi) at
0x812d00f.
#1 0x0818e1ec in df_rd_free_bb_info (dflow=0x86d52f0, bb=0xb71fa280,
vbb_info=0x86884a0) at /home/ranmath/src/gcc/gcc/gcc/df-problems.c:856
During symbol reading, incomplete CFI data; unspecified registers (e.g., eax) at
0x818e16d.
During symbol reading, incomplete CFI data; unspecified registers (e.g., ecx) at
0x818e16d.
During symbol reading, incomplete CFI data; unspecified registers (e.g., edx) at
0x818e16d.
During symbol reading, incomplete CFI data; unspecified registers (e.g., ebx) at
0x818e16d.
During symbol reading, incomplete CFI data; unspecified registers (e.g., esi) at
0x818e16d.
During symbol reading, incomplete CFI data; unspecified registers (e.g., edi) at
0x818e16d.
#2 0x0818a90a in df_set_blocks (df=0x86d6de8, blocks=0x8687c90)
at /home/ranmath/src/gcc/gcc/gcc/df-core.c:373
During symbol reading, incomplete CFI data; unspecified registers (e.g., eax) at
0x818a822.
During symbol reading, incomplete CFI data; unspecified registers (e.g., ecx) at
0x818a822.
During symbol reading, incomplete CFI data; unspecified registers (e.g., edx) at
0x818a822.
During symbol reading, incomplete CFI data; unspecified registers (e.g., esi) at
0x818a822.
During symbol reading, incomplete CFI data; unspecified registers (e.g., edi) at
0x818a822.
#3 0x081c1d1c in iv_analysis_loop_init (loop=0x86d9500)
at /home/ranmath/src/gcc/gcc/gcc/loop-iv.c:267
During symbol reading, incomplete CFI data; unspecified registers (e.g., eax) at
0x81c1c33.
During symbol reading, incomplete CFI data; unspecified registers (e.g., ecx) at
0x81c1c33.
During symbol reading, incomplete CFI data; unspecified registers (e.g., edx) at
0x81c1c33.
#4 0x08357f0e in predict_loops (loops_info=0xbfffeb20,
rtlsimpleloops=1 '\001') at /home/ranmath/src/gcc/gcc/gcc/predict.c:618
#5 0x0835873d in estimate_probability (loops_info=0xbfffeb20)
at /home/ranmath/src/gcc/gcc/gcc/predict.c:842
#6 0x08364dc2 in rest_of_handle_branch_prob ()
at /home/ranmath/src/gcc/gcc/gcc/profile.c:1363
#7 0x083ef41e in execute_one_pass (pass=0x85d4d00)
at /home/ranmath/src/gcc/gcc/gcc/passes.c:849
#8 0x083ef4d9 in execute_pass_list (pass=0x85d4d00)
at /home/ranmath/src/gcc/gcc/gcc/passes.c:881
#9 0x083ef4f4 in execute_pass_list (pass=0x85d53a0)
at /home/ranmath/src/gcc/gcc/gcc/passes.c:882
#10 0x080c048f in tree_rest_o
Re: Mainline bootstrap failure (revision 110017)
On Fri, 2006-01-20 at 10:53 +0530, Ranjit Mathew wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi,
>
> Mainline fails to bootstrap for me (revision 110017)
> on i686-pc-linux-gnu.
>
> Configured as:
>
> $GCC_SRC_DIR/configure --prefix=$HOME/gcc --enable-languages=c,c++,java \
> - --with-as=/home/ranmath/gnu/bin/as --with-gnu-as \
> - --with-ld=/home/ranmath/gnu/bin/ld --with-gnu-ld \
> - --with-arch=pentium4 --with-tune=pentium4 \
> - --disable-nls --disable-checking --disable-libmudflap \
> - --disable-debug --enable-threads=posix --enable-__cxa_atexit \
> - --disable-static
>
Kenny thought it would be nice, rather than pass the actual bb info to free to
the freeing function, to instead pass some random bitmap.
The attached fixes *that*, but this just causes a crash deeper in trying to
free some chains.
However, it looks like that is either caused by a double free, or because
we never null out pointers to things after we free the memory for what they
are pointing to.
Index: df-core.c
===
--- df-core.c (revision 110017)
+++ df-core.c (working copy)
@@ -292,6 +292,7 @@ are write-only operations.
static struct df *ddf = NULL;
struct df *shared_df = NULL;
+static void * df_get_bb_info (struct dataflow *, unsigned int);
/*
Functions to create, destroy and manipulate an instance of df.
*/
@@ -370,7 +371,7 @@ df_set_blocks (struct df *df, bitmap blo
EXECUTE_IF_SET_IN_BITMAP (diff, 0, bb_index, bi)
{
basic_block bb = BASIC_BLOCK (bb_index);
- (*dflow->problem->free_bb_fun) (dflow, bb, diff);
+ (*dflow->problem->free_bb_fun) (dflow, bb, df_get_bb_info (dflow, bb_index));
}
}
}
help with the conception of floating point
I guess that the macro NGARDS is relevant to the guard digit. But I still failed to have a clear conception about what it means. Others are easy to know by IEEE 754 and "What Every Computer Scientist Should Know about Floating-Point Arithmetic". Except, define NGARDS 8L define GARDROUND 0x7f define GARDMASK 0xff define GARDMSB 0x80 what do these mean? :-) Especially when unpack a signal floating point, the fraction takes such an operation at last, that make me much confused. dst->fraction.ll = (fraction << NGARDS) | IMPLICIT_1; I just want to know what does this mean.:-) Thanks a lot. Eirc.
Re: libgomp & solaris
Hello, > Andrew P. wanted me to report the issues I encountered with libgomp and > solaris > on head. > The next issue is the -pthread in the config stuff. Solaris does not like it > :) > -pthreads instead. I have encountered the same problem, perhaps the analysis at http://gcc.gnu.org/ml/gcc/2005-11/msg00649.html can help. Uros.
