libstdc++ svn head broken
Doing a build of gcc from revision 134693 with build=host=x86_64-pc-linux and target=i686-pc-mingw32 yields the following mess of errors: [EMAIL PROTECTED]:/var/tmp/g-tw64$ make > /dev/null ctype_members.cc: In member function 'virtual char std::ctype::do_narrow(wchar_t, char) const': ctype_members.cc:210: warning: comparison is always true due to limited range of data type ctype_members.cc: In member function 'virtual const wchar_t* std::ctype::do_narrow(const wchar_t*, const wchar_t*, char, char*) const': ctype_members.cc:224: warning: comparison is always true due to limited range of data type In file included from /var/tmp/g-tw64/i686-pc-mingw32/libstdc++-v3/include/parallel/algobase.h:46, from /var/tmp/g-tw64/i686-pc-mingw32/libstdc++-v3/include/bits/stl_algobase.h:1137, from /var/tmp/g-tw64/i686-pc-mingw32/libstdc++-v3/include/list:66, from ../../../../build/gcc-svn/gcc/libstdc++-v3/src/list.cc:56, from ../../../../build/gcc-svn/gcc/libstdc++-v3/src/parallel_list.cc:30: /var/tmp/g-tw64/i686-pc-mingw32/libstdc++-v3/include/parallel/base.h:43:17: error: omp.h: No such file or directory In file included from /var/tmp/g-tw64/i686-pc-mingw32/libstdc++-v3/include/parallel/parallel.h:45, from /var/tmp/g-tw64/i686-pc-mingw32/libstdc++-v3/include/parallel/base.h:46, from /var/tmp/g-tw64/i686-pc-mingw32/libstdc++-v3/include/parallel/algobase.h:46, from /var/tmp/g-tw64/i686-pc-mingw32/libstdc++-v3/include/bits/stl_algobase.h:1137, from /var/tmp/g-tw64/i686-pc-mingw32/libstdc++-v3/include/list:66, from ../../../../build/gcc-svn/gcc/libstdc++-v3/src/list.cc:56, from ../../../../build/gcc-svn/gcc/libstdc++-v3/src/parallel_list.cc:30: /var/tmp/g-tw64/i686-pc-mingw32/libstdc++-v3/include/parallel/tags.h: In member function '__gnu_parallel::thread_index_t __gnu_parallel::parallel_tag::get_num_threads()': /var/tmp/g-tw64/i686-pc-mingw32/libstdc++-v3/include/parallel/tags.h:79: error: 'omp_get_max_threads' was not declared in this scope In file included from /var/tmp/g-tw64/i686-pc-mingw32/libstdc++-v3/include/parallel/algobase.h:46, from /var/tmp/g-tw64/i686-pc-mingw32/libstdc++-v3/include/bits/stl_algobase.h:1137, from /var/tmp/g-tw64/i686-pc-mingw32/libstdc++-v3/include/list:66, from ../../../../build/gcc-svn/gcc/libstdc++-v3/src/list.cc:56, from ../../../../build/gcc-svn/gcc/libstdc++-v3/src/parallel_list.cc:30: /var/tmp/g-tw64/i686-pc-mingw32/libstdc++-v3/include/parallel/base.h: In function 'int __gnu_parallel::get_max_threads()': /var/tmp/g-tw64/i686-pc-mingw32/libstdc++-v3/include/parallel/base.h:94: error: 'omp_get_max_threads' was not declared in this scope In file included from /var/tmp/g-tw64/i686-pc-mingw32/libstdc++-v3/include/parallel/algobase.h:49, from /var/tmp/g-tw64/i686-pc-mingw32/libstdc++-v3/include/bits/stl_algobase.h:1137, from /var/tmp/g-tw64/i686-pc-mingw32/libstdc++-v3/include/list:66, from ../../../../build/gcc-svn/gcc/libstdc++-v3/src/list.cc:56, from ../../../../build/gcc-svn/gcc/libstdc++-v3/src/parallel_list.cc:30: /var/tmp/g-tw64/i686-pc-mingw32/libstdc++-v3/include/parallel/find.h: In function 'std::pair<_T1, _T2> __gnu_parallel::find_template(RandomAccessIterator1, RandomAccessIterator1, RandomAccessIterator2, Pred, Selector, __gnu_parallel::equal_split_tag)': /var/tmp/g-tw64/i686-pc-mingw32/libstdc++-v3/include/parallel/find.h:120: error: 'omp_lock_t' was not declared in this scope /var/tmp/g-tw64/i686-pc-mingw32/libstdc++-v3/include/parallel/find.h:120: error: expected ';' before 'result_lock' /var/tmp/g-tw64/i686-pc-mingw32/libstdc++-v3/include/parallel/find.h:121: error: 'result_lock' was not declared in this scope /var/tmp/g-tw64/i686-pc-mingw32/libstdc++-v3/include/parallel/find.h:121: error: there are no arguments to 'omp_init_lock' that depend on a template parameter, so a declaration of 'omp_init_lock' must be available /var/tmp/g-tw64/i686-pc-mingw32/libstdc++-v3/include/parallel/find.h:121: note: (if you use '-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated) /var/tmp/g-tw64/i686-pc-mingw32/libstdc++-v3/include/parallel/find.h:128: error: there are no arguments to 'omp_get_num_threads' that depend on a template parameter, so a declaration of 'omp_get_num_threads' must be available /var/tmp/g-tw64/i686-pc-mingw32/libstdc++-v3/include/parallel/find.h:133: error: there are no arguments to 'omp_get_thread_num' that depend on a template parameter, so a declaration of 'omp_get_thread_num' must be available /var/tmp/g-tw64/i686-pc-mingw32/libstdc++-v3/include/parallel/find.h:147: error: there are no arguments to 'omp_set_lock' that depend on a template parameter, so a declaration of 'omp_set_lock' must be available /var/tmp/g-tw64
gcc-4.4-20080425 is now available
Snapshot gcc-4.4-20080425 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20080425/ 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/trunk revision 134680 You'll find: gcc-4.4-20080425.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20080425.tar.bz2 C front end and core compiler gcc-ada-4.4-20080425.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20080425.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20080425.tar.bz2 C++ front end and runtime gcc-java-4.4-20080425.tar.bz2 Java front end and runtime gcc-objc-4.4-20080425.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20080425.tar.bz2The GCC testsuite Diffs from 4.4-20080418 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: IRA for GCC 4.4
On Thu, 2008-04-24 at 20:23 -0400, Vladimir Makarov wrote:
> Hi, Peter. The last time I looked at the conflict builder
> (ra-conflict.c), I did not see the compressed matrix. Is it in the
> trunk? What should I look at?
Yes, the compressed bit matrix was committed as revision 129037 on
October 5th, so it's been there a while. Note that the old square
bit matrix was used not only for testing for conflicts, but also for
visiting an allocno's neighbors. The new code (and all compilers I've
worked on/with), use a {,compressed} upper triangular bit matrix for
testing for conflicts and an adjacency list for visiting neighbors.
The code that allocates and initializes the compressed bit matrix is in
global.c. If you remember how a upper triangular bit matrix works, it's
just one big bit vector, where the bit number that represents the conflict
between allocnos LOW and HIGH is given by either of these two functions:
1) bitnum = f(HIGH) + LOW
2) bitnum = f(LOW) + HIGH
where:
1) f(HIGH) = (HIGH * (HIGH - 1)) / 2
2) f(LOW) = LOW * (max_allocno - LOW) + (LOW * (LOW - 1)) / 2 - LOW - 1
As mentioned in some of the conflict graph bit matrix literature (actually,
they only mention expression #1 above), the expensive functions f(HIGH) and
f(LOW) can be precomputed and stored in an array, so to access the conflict
graph bits only takes a load and an addition. Below is an example bit matrix
with initialized array:
012 3456789 10 11
---
| -1 | 0 || 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 |
---
| 9 | 1 ||| 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 |
---
| 18 | 2 |||| 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 |
---
| 26 | 3 ||||| 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 |
---
| 33 | 4 |||||| 38 | 39 | 40 | 41 | 42 | 43 | 44 |
---
| 39 | 5 ||||||| 45 | 46 | 47 | 48 | 49 | 50 |
---
| 44 | 6 |||||||| 51 | 52 | 53 | 54 | 55 |
---
| 48 | 7 ||||||||| 56 | 57 | 58 | 59 |
---
| 51 | 8 |||||||||| 60 | 61 | 62 |
---
| 53 | 9 ||||||||||| 63 | 64 |
---
| 54 | 10 |||||||||||| 65 |
---
| NA | 11 |||||||||||||
---
As an example, if we look at the interference between allocnos 8 and 10, we
compute "array[8] + 10" = "51 + 10" = "61", which if you look above, you will
see is the correct bit number for that interference bit.
The difference between a compressed upper triangular bit matrix from a standard
upper triangular bit matrix like the one above, is we eliminate space from the
bit matrix for conflicts we _know_ can never exist. The easiest case to catch,
and the only one we catch at the moment, is that allocnos that are "local" to a
basic block B1 cannot conflict with allocnos that are local to basic block B2,
where B1 != B2. To take advantage of this fact, I updated the code in global.c
to sort the allocnos such that all "global" allocnos (allocnos that are live in
more than one basic block) are given smaller allocno numbers than the "local"
allocnos, and all allocnos for a given basic block are grouped together in a
contiguous range to allocno numbers. The sorting is accomplished by:
/* ...so we can sort them in the order we want them to receive
their allocnos. */
qsort (reg_allocno, max_allocno, sizeof (int), regno_compare);
Once we have them sorted, our conceptual view of the compressed bit matrix
will now look like:
GGGB0 B0 B0 B1 B1 B2 B2 B2 B2
012 3456789 10 11
-- -
| -1 |G 0 || 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 |
--
Re: More on GCC Back Ends
> Mike writes: Mike> Is there a short list of steps to get a very minimal machine specific Mike> back end going? Please point me to some better documents? :) http://gcc.gnu.org/wiki/GettingStarted http://www.cfdvs.iitb.ac.in/~amv/gcc-int-docs/ Most new backends start by copying an existing GCC backend for an architecture with similar characteristics. David
Re: More on GCC Back Ends
http://gcc.gnu.org/onlinedocs/gccint/Back-End.html This mentions a file "config.gcc" which I can't find in the GCC source. This page tells too little I guess. Its under the 'gcc' directory. Aaron
More on GCC Back Ends
http://gcc.gnu.org/onlinedocs/gccint/Back-End.html This mentions a file "config.gcc" which I can't find in the GCC source. This page tells too little I guess. http://gcc.gnu.org/onlinedocs/gccint/Machine-Desc.html This stuff would be useful if the GCC build process recognized that I made some .MD file, but the build process just outputs "Configuration... not supported...". Is there a short list of steps to get a very minimal machine specific back end going? Please point me to some better documents? :)
Re: US-CERT Vulnerability Note VU#162289
* Robert Dewar: > To me, the whole notion of this vulnerability node > is flawed in that respect. You can write a lengthy > and useful book on pitfalls in C that must be > avoided, but I see no reason to turn such a book > into a cert advisory, I think it's useful to point out in security advisories widespread coding mistakens which are particularly security-related. Perhaps I'm biased because I did that for incorrect integer over flow checks in C code back in 2002. My motivation back then was that advisories were published about common configuration mistakes, even though the underlying tool was working as documented--and misusing a compiler seems to fall in the same category.
Re: Fix for libstdc++/35887 broke build for single-thread targets
> apparently for all single-thread targets (like cris-elf). > > Could it be that you forgot to actually test that this works on > single-thread targets? Or how did you test that? Reverted on the branch, fixing on trunk. Sorry, you are correct. I did not test single thread targets. -benjamin
RE: US-CERT Vulnerability Note VU#162289
Daniel Jacobowitz wrote on : > On Fri, Apr 25, 2008 at 11:45:25AM -0400, Paul Koning wrote: >> Robert> To me, the whole notion of this vulnerability node is flawed >> Robert> in that respect. You can write a lengthy and useful book on >> Robert> pitfalls in C that must be avoided, but I see no reason to >> Robert> turn such a book into a cert advisory, let alone pick out a >> Robert> single arbitrary example on a particular compiler! >> >> I think that comment is absolutely correct. > > The R in CERT is "Response" (at least it used to be; I can't find an > expansion on their web site...). They're responding to a problem that > was reported to them, and alerting others to the problem. We can > argue about the details, but not about the need to respond. But the E is "Emergency". This is not an emergency and does not demand an *urgent* (and hence rushed and methodologically flawed) response; this is just one more facet of the problems inherent in the design of the C language that have been going on since /forever/. cheers, DaveK -- Can't think of a witty .sigline today
Re: US-CERT Vulnerability Note VU#162289
Daniel Jacobowitz wrote: The R in CERT is "Response" (at least it used to be; I can't find an expansion on their web site...). They're responding to a problem that was reported to them, and alerting others to the problem. We can argue about the details, but not about the need to respond. I agree. I am not happy about some of the ways in which CERT has singled out GCC in this situation. That said, warning people that applications that use a particular style of security check are broken is a perfectly reasonable thing to do, especially given that the broken security check is known to be present in real-world applications. In fact, warning people that such code worked with GCC X, but not GCC X+1, is useful; some people may not be able to audit the code, but may be able to control whether or not they upgrade to a new compiler, and this is useful data for those people. But, it should be made clear that switching from GCC to icc (or whatever) is not a solution, since many of those compilers also do the optimization. (Never mind the risks that making a major change to your build environment entails...) -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: US-CERT Vulnerability Note VU#162289
On Fri, Apr 25, 2008 at 11:45:25AM -0400, Paul Koning wrote: > Robert> To me, the whole notion of this vulnerability node is flawed > Robert> in that respect. You can write a lengthy and useful book on > Robert> pitfalls in C that must be avoided, but I see no reason to > Robert> turn such a book into a cert advisory, let alone pick out a > Robert> single arbitrary example on a particular compiler! > > I think that comment is absolutely correct. The R in CERT is "Response" (at least it used to be; I can't find an expansion on their web site...). They're responding to a problem that was reported to them, and alerting others to the problem. We can argue about the details, but not about the need to respond. -- Daniel Jacobowitz CodeSourcery
Re: Security vulernarability or security feature?
On 4/24/08, Robert C. Seacord <[EMAIL PROTECTED]> wrote: > If you are referring to VU#694123, this refers to an optimization that > removes checks pointer arithmetic wrapping. The optimization doesn't > actually eliminate the wrapping behavior; this still occurs. It does, > however, eliminate certain kinds of checks (that depend upon undefined > behavior). How can you hold the compiler responsible for code that depends on undefined behavior? The behavior is undefined, therefore you CANNOT depend on it. If you buy a hammer that says on it "for use in hammering nails," and you use it to hammer in a screw, and it fails miserably (as hammering screws is undefined behavior), is it the hammer manufacturer's fault for not telling you about every single possible scenario in which a hammer cannot be used?
Re: US-CERT Vulnerability Note VU#162289
> "Robert" == Robert Dewar <[EMAIL PROTECTED]> writes: Robert> Another general point is that conceptually this is not an Robert> optimization issue at all. Robert> The programmer writes code that is undefined according to the Robert> standard. ... Robert> To me, the whole notion of this vulnerability node is flawed Robert> in that respect. You can write a lengthy and useful book on Robert> pitfalls in C that must be avoided, but I see no reason to Robert> turn such a book into a cert advisory, let alone pick out a Robert> single arbitrary example on a particular compiler! I think that comment is absolutely correct. I would add one point: "undefined" (or the equivalent) is a term that appears in many language standards, not just in the C standard. For example, Algol 68 very precisely defined "undefined" (with essentially the meaning we have discussed). Given Robert's comment it seems to me that the right approach is to withdraw the proposed vulnerability note entirely. paul
RE: US-CERT Vulnerability Note VU#162289
Robert Dewar wrote on : > One thing to realize in this discussion is that it is not > possible in general to warn when a programmer is depending > on undefined behavior, since by definition you cannot in > general guess what misunderstandings the programmer has > about C, and hence what behavior is expected. > > There are some cases where you can guess well enough that > you can provide warnings that won't have an excessive > number of annoying false positivesm, and warnings in > such cases are appropriate. > > But some contributions to this thread have seemed to > come near to a position of requiring warnings whenever > the compiler does something that might violate expectations > of a programmer writing undefined C code, and as a general > principle this is fundamentally impossible. And some have been pleas for the compiler to DWIM. Which, while it would be nice, is not just impossible, but conceptually flawed to the point of meaninglessness because it begs the question. This is because whatever the compiler assumes you /actually/ meant when it's trying to DWYM would have to be based on a set of rules/heuristics/inferences that would be just as liable as the current optimisation vs. undefined behaviour rules to misunderstandings that end up introducing security violations - but with the added disadvantage of not being in accord with a well-defined standard of behaviour, but being some ad-hoc and unpredictable set of transformations that you can't even know to avoid. In short, any attempt by the compiler to DWIM would just move the same class of problem around, but make it harder to detect; a lose-lose situation for everyone. At least with a clear standard, it's possible to make guarantees about when and whether a program is correct or not. cheers, DaveK -- Can't think of a witty .sigline today
Re: US-CERT Vulnerability Note VU#162289
Robert Dewar wrote: Paul Koning wrote: That said, it certainly is helpful if the compiler can detect some undefined actions and warn about them. But that doesn't create a duty to warn about all of them. If it were reasonable to require a compiler to generate a warning for a particular case, the standard would have made it an error. The whole point in allowing undefined behavior is that in certain cases, it is too onerous for a compiler to be required to detect the undefined behavior, so it is not required to do so. I recall something in the Ada LRM that a conforming Ada program did not depend on undefined or implementation dependent behavior. The example I remember being used to explain it to me was a program depending upon the precise order of tasks executing. That can obviously vary based upon interrupts, CPU speed, time slice quantum and a number of tasking implementation decisions. When you talk undefined, the program is questionable at best. I like the Ada LRM because it tries to be very clean about this in a way that a programmer can understand and try to do the right thing. -- Joel Sherrill, Ph.D. Director of Research & Development [EMAIL PROTECTED]On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: US-CERT Vulnerability Note VU#162289
Paul Koning wrote: That said, it certainly is helpful if the compiler can detect some undefined actions and warn about them. But that doesn't create a duty to warn about all of them. If it were reasonable to require a compiler to generate a warning for a particular case, the standard would have made it an error. The whole point in allowing undefined behavior is that in certain cases, it is too onerous for a compiler to be required to detect the undefined behavior, so it is not required to do so.
Re: US-CERT Vulnerability Note VU#162289
Another general point is that conceptually this is not an optimization issue at all. The programmer writes code that is undefined according to the standard. Whatever expectation the programmer has for this code is based on either a fundamental misunderstanding of the semantics of C, or there is a simple bug. When you write such code, the compiler may do anything, whether or not optimization is turned on. It's not a security risk that the compiler fails to provide some kind of behavior that the standard does not defined\. The security risk is in writing undefined code, such code has a (potentially serious) bug. Sure, this is indeed a case where switching from one compiler to another, one architecture to another, one version of a particular commpiler to another, one set of compilation switches to another etc can change the behavior. It's even possible for such code to behave differently on the same day with none of these conditions changed, depending e.g. on what was run before or is running at the same time. If you write in a language which is not 100% safe in this regard, you do have to worry about safety considerations caused by undefined code, and depend on proofs, code reviews, tools etc to ensure that your code is free of such defects. That's worrisome, but any bugs in supposedly secure/safe code are worrisome, and there is no real reason to single out the particular class of bugs corresponding to use of undefined semantics in C. To me, the whole notion of this vulnerability node is flawed in that respect. You can write a lengthy and useful book on pitfalls in C that must be avoided, but I see no reason to turn such a book into a cert advisory, let alone pick out a single arbitrary example on a particular compiler!
Re: US-CERT Vulnerability Note VU#162289
One thing to realize in this discussion is that it is not possible in general to warn when a programmer is depending on undefined behavior, since by definition you cannot in general guess what misunderstandings the programmer has about C, and hence what behavior is expected. There are some cases where you can guess well enough that you can provide warnings that won't have an excessive number of annoying false positivesm, and warnings in such cases are appropriate. But some contributions to this thread have seemed to come near to a position of requiring warnings whenever the compiler does something that might violate expectations of a programmer writing undefined C code, and as a general principle this is fundamentally impossible.
Fix for libstdc++/35887 broke build for single-thread targets
apparently for all single-thread targets (like cris-elf). Could it be that you forgot to actually test that this works on single-thread targets? Or how did you test that? Build worked with trunk 134647 and was broken with 134655 (still broken with 134662 in the same way), yours being the only suspect commit. For 4.3, it worked with 134632 and was broken with 134650. (I don't see why you put stuff like this on a release branch.) For trunk 134655: /bin/sh ../libtool --tag CXX --mode=compile /tmp/x/./gcc/xgcc -shared-libgcc -B/tmp/x/./gcc -nostdinc++ -L/tmp/x/cris-elf/libstdc++-v3/src -L/tmp/x/cris-elf/libstdc++-v3/src/.libs -nostdinc -B/tmp/x/cris-elf/newlib/ -isystem /tmp/x/cris-elf/newlib/targ-include -isystem /tmp/y/newlib/libc/include -B/tmp/x/cris-elf/libgloss/cris -L/tmp/x/cris-elf/libgloss/libnosys -L/tmp/y/libgloss/cris -B/tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/bin/ -B/tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/lib/ -isystem /tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/include -isystem /tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/sys-include -I/tmp/x/cris-elf/libstdc++-v3/include/cris-elf -I/tmp/x/cris-elf/libstdc++-v3/include -I/tmp/y/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -fopenmp -D_GLIBCXX_PARALLEL -I/tmp/x/cris-elf/libstdc++-v3/../libgomp -c /tmp/y/libstdc++-v3/src/parallel_l! ist.cc libtool: compile: /tmp/x/./gcc/xgcc -shared-libgcc -B/tmp/x/./gcc -nostdinc++ -L/tmp/x/cris-elf/libstdc++-v3/src -L/tmp/x/cris-elf/libstdc++-v3/src/.libs -nostdinc -B/tmp/x/cris-elf/newlib/ -isystem /tmp/x/cris-elf/newlib/targ-include -isystem /tmp/y/newlib/libc/include -B/tmp/x/cris-elf/libgloss/cris -L/tmp/x/cris-elf/libgloss/libnosys -L/tmp/y/libgloss/cris -B/tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/bin/ -B/tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/lib/ -isystem /tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/include -isystem /tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/sys-include -I/tmp/x/cris-elf/libstdc++-v3/include/cris-elf -I/tmp/x/cris-elf/libstdc++-v3/include -I/tmp/y/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -fopenmp -D_GLIBCXX_PARALLEL -I/tmp/x/cris-elf/libstdc++-v3/../libgomp -c /tmp/y/libstdc++-v3/src/parallel_list.cc -o parallel_list.o xgcc: unrecognized option '-pthread' In file included from /tmp/x/cris-elf/libstdc++-v3/include/parallel/algobase.h:46, from /tmp/x/cris-elf/libstdc++-v3/include/bits/stl_algobase.h:1137, from /tmp/x/cris-elf/libstdc++-v3/include/list:66, from /tmp/y/libstdc++-v3/src/list.cc:56, from /tmp/y/libstdc++-v3/src/parallel_list.cc:30: /tmp/x/cris-elf/libstdc++-v3/include/parallel/base.h:43:17: error: omp.h: No such file or directory In file included from /tmp/x/cris-elf/libstdc++-v3/include/parallel/parallel.h:45, from /tmp/x/cris-elf/libstdc++-v3/include/parallel/base.h:46, from /tmp/x/cris-elf/libstdc++-v3/include/parallel/algobase.h:46, from /tmp/x/cris-elf/libstdc++-v3/include/bits/stl_algobase.h:1137, from /tmp/x/cris-elf/libstdc++-v3/include/list:66, from /tmp/y/libstdc++-v3/src/list.cc:56, from /tmp/y/libstdc++-v3/src/parallel_list.cc:30: /tmp/x/cris-elf/libstdc++-v3/include/parallel/tags.h: In member function '__gnu_parallel::thread_index_t __gnu_parallel::parallel_tag::get_num_threads()': /tmp/x/cris-elf/libstdc++-v3/include/parallel/tags.h:79: error: 'omp_get_max_threads' was not declared in this scope In file included from /tmp/x/cris-elf/libstdc++-v3/include/parallel/algobase.h:46, from /tmp/x/cris-elf/libstdc++-v3/include/bits/stl_algobase.h:1137, from /tmp/x/cris-elf/libstdc++-v3/include/list:66, from /tmp/y/libstdc++-v3/src/list.cc:56, from /tmp/y/libstdc++-v3/src/parallel_list.cc:30: /tmp/x/cris-elf/libstdc++-v3/include/parallel/base.h: In function 'int __gnu_parallel::get_max_threads()': /tmp/x/cris-elf/libstdc++-v3/include/parallel/base.h:94: error: 'omp_get_max_threads' was not declared in this scope In file included from /tmp/x/cris-elf/libstdc++-v3/include/parallel/find.h:46, from /tmp/x/cris-elf/libstdc++-v3/include/parallel/algobase.h:49, from /tmp/x/cris-elf/libstdc++-v3/include/bits/stl_algobase.h:1137, from /tmp/x/cris-elf/libstdc++-v3/include/list:66, from /tmp/y/libstdc++-v3/src/list.cc:56, from /tmp/y/libstdc++-v3/src/parallel_list.cc:30: /tmp/x/cris-elf/libstdc++-v3/include/parallel/compatibility.h: In function 'void __gnu_parallel::yield()': /tmp/x/cris-elf/libstdc++-v3/include/parallel/compatibility.h:351: error: 'sched_yield' wa
RE: US-CERT Vulnerability Note VU#162289
Mark Syddall wrote: ^ Should read "Dave Korn." Apologies all recipients, we had mailserver trouble at this end and somehow some of the resends got the admin's From: line on them by mistake. > Robert C. Seacord wrote on : > >> I am getting tired with the personal/organizational attacks. >> If you expect a response, please keep your comments professional. > > Will you address the methodological flaws in your study, or do you > consider them to be "personal/organizational attacks"? cheers, DaveK -- Can't think of a witty .sigline today
ARCtangent-A4 support
We (ARC) intend to contribute our improvements to the ARC gcc/binutils support once our Copyright assignment is in place. We are currently considering removing the ARCtangent-A4 support from our sources, as we don't need it anymore. The only reason to keep the code would be to facilitate merges with the FSF code base. I expect we would do regular testing for ARC600 and ARC700 support, since we are interested in this support for our current and future products. ARCtangent-A5 is similar enough to ARC600 that it shouldn't require much testing / maintenance effort to keep it around. However, the ARCtangent-A4 has a number of architectural differences and uses a different instruction encoding. Since we don't use ARCtangent-A4 support, we would not test it. So, is there anybody still interested in ARCtangent-A4 support to the point that they are willing to do regular tests once the port is maintained? If there is no volunteer for testing, I suppose we can assume that ARCtangent-A4 support will be dropped from the FSF sources for lack of testing.
RE: US-CERT Vulnerability Note VU#162289
Robert C. Seacord wrote on : > I am getting tired with the personal/organizational attacks. > If you expect a response, please keep your comments professional. Will you address the methodological flaws in your study, or do you consider them to be "personal/organizational attacks"? cheers, DaveK -- Can't think of a witty .sigline today
Re: Un-deprecating CRX: Request to review and commit
Hello All, I have committed the patch to 4.3 branch and mainline. Thanks a lot for considering the removal of deprecation. Many thanks to all who reviewed the patch. Regards, Pompa Richard Guenther wrote: On Mon, Apr 21, 2008 at 10:40 AM, Pompapathi V Gadad <[EMAIL PROTECTED]> wrote: Hello All, Steering Committee, I have submitted a patch to undeprecate CRX port in 4.3 branch. The port itself has not changed. I have also submitted the tests results. So far I have not recevied any comments for GCC community. Can someone please review the patch and suggest if this is OK for 4.3 branch? If this OK for 4.3 branch, I request to commit the patch as well. I would really wish to see the port undeprecated in 4.3.1 release. Reply is highly appreciated. Patch: http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00306.html This is ok for the 4.3 branch and mainline. In the MAINTAINERS file Paul Woegerer is listed as maintainer for crx, is this still accurate? Testresults: http://gcc.gnu.org/ml/gcc-testresults/2008-04/msg01588.html http://gcc.gnu.org/ml/gcc-testresults/2008-03/msg00360.html We expect that you do some housekeeping of this backend as the latest change to it is from the end of 2005. Richard.
