Moving statements from one BB to other BB.
Hi, I have transferred all the statements of one BB( header of one loop) to another BB. After that I have updated SSA information too. But I get this error- definition in block 6 does not dominate use in block 3 for SSA_NAME: i_25 in statement: # VUSE a_18 D.1189_10 = a[i_25]; loop.c:8: internal compiler error: verify_ssa failed Can any one please tell me what is the problem? Thanks, Sandeep.
Problem compiling apache 2.0.63, libiconv.so: wrong ELF class: ELFCLASS32
Hello I'm having problem when making apache 2.0.63. Im using the configure command like this: CC=gcc CFLAGS= -O2 -mcpu=v9 -m64 CPPFLAGS= -m64 -I/usr/sfw/include LDFLAGS=-m64 \ ./configure --prefix=/usr/apache2 --enable-mods-shared=most --with-mpm=prefork And the problem I got looks like this: /usr/tmp/httpd-2.0.63/srclib/apr/libtool --silent --mode=link gcc-O2 -mcpu=v9 -m64 -m64 -I/usr/sfw/include -DSOLARIS2=10 -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -DAP_HAVE_DESIGNATED_INITIALIZER -m64 -I/usr/sfw/include -I/usr/tmp/httpd-2.0.63/srclib/apr/include -I/usr/tmp/httpd-2.0.63/srclib/apr-util/include -I/usr/tmp/httpd-2.0.63/srclib/apr-util/xml/expat/lib -I. -I/usr/tmp/httpd-2.0.63/os/unix -I/usr/tmp/httpd-2.0.63/server/mpm/prefork -I/usr/tmp/httpd-2.0.63/modules/http -I/usr/tmp/httpd-2.0.63/modules/filters -I/usr/tmp/httpd-2.0.63/modules/proxy -I/usr/tmp/httpd-2.0.63/include -I/usr/tmp/httpd-2.0.63/modules/generators -I/usr/tmp/httpd-2.0.63/modules/dav/main -export-dynamic -L/usr/tmp/httpd-2.0.63/srclib/apr-util/xml/expat/lib -m64 -o htpasswd htpasswd.lo/usr/tmp/httpd-2.0.63/srclib/pcre/libpcre.la /usr/tmp/httpd-2.0.63/srclib/apr-util/libaprutil-0.la /usr/tmp/httpd-2.0.63/srclib/apr-util/xml/expat/lib/libexpat.la -liconv /usr/tmp/httpd-2.0.63/srclib/apr/libapr-0.la -lsendfile -lrt -lm -lsocket -lnsl -lresolv -lpthread ld: fatal: file /usr/local/lib/libiconv.so: wrong ELF class: ELFCLASS32 ld: fatal: File processing errors. No output written to .libs/htpasswd collect2: ld returned 1 exit status make[2]: *** [htpasswd] Error 1 make[2]: Leaving directory `/usr/tmp/httpd-2.0.63/support' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/tmp/httpd-2.0.63/support' make: *** [all-recursive] Error 1 Any ideas why the gcc compiler not finds the 64-bit variant of libiconv.so?? file /usr/local/lib.64/libiconv.so /usr/local/lib.64/libiconv.so: ELF 64-bit MSB dynamic lib SPARCV9 Version 1, dynamically linked, not stripped Best regards Håkan Persson
A query regarding the implementation of pragmas
Hello all, For a function call will i be able to implement long call/short call for the same function at different locations? Say fun1 calls bar and fun2 calls bar. I want short-call to be generated for bar in fun1 and long-call to be generated in fun2. Is to possible to implement this in the back-end using pragmas? Regards, Shafi.
Re: Moving statements from one BB to other BB.
On Mon, Apr 14, 2008 at 12:54 PM, Sandeep Maram [EMAIL PROTECTED] wrote: Hi, I have transferred all the statements of one BB( header of one loop) to another BB. After that I have updated SSA information too. But I get this error- definition in block 6 does not dominate use in block 3 for SSA_NAME: i_25 in statement: This is the problem. # VUSE a_18 D.1189_10 = a[i_25]; loop.c:8: internal compiler error: verify_ssa failed Can any one please tell me what is the problem? Thanks, Sandeep.
Re: omp workshare (PR35423) beginner questions
Hi!
On Wed, Apr 09, 2008 at 11:29:24PM -0500, Vasilis Liaskovitis wrote:
I am a beginner interested in learning gcc internals and contributing
to the community.
Thanks for showing interest in this area!
I have started implementing PR35423 - omp workshare in the fortran
front-end. I have some questions - any guidance and suggestions are
welcome:
- For scalar assignments, wrapping them in OMP_SINGLE clause.
Yes, though if there is a couple of adjacent scalar assignments which don't
involve function calls and won't take too long to execute, you want
to put them all into one OMP_SINGLE. If the assignments make take long
because of function calls and there are several such ones adjacent,
you can use OMP_WORKSHARE.
Furthermore, for all statements, not just the scalar ones, you want to
do dependency analysis between all the statements within !$omp workshare,
and make OMP_SINGLE, OMP_FOR or OMP_SECTIONS and add OMP_CLAUSE_NOWAIT
to them where no barrier is needed.
- Array/subarray assignments: For assignments handled by the
scalarizer, I now create an OMP_FOR loop instead of a LOOP_EXPR for
the outermost scalarized loop. This achieves worksharing at the
outermost loop level.
Yes, though on gomp-3_0-branch you actually could use collapsed OMP_FOR
loop too. Just bear in mind that for best performance at least with
static OMP_FOR scheduling ideally the same memory (part of array in this
case) is accessed by the same thread, as then it is in that CPU's caches.
Of course that's not always possible, but if it can be done, gfortran
should try that.
Some array assignments are handled by functions (e.g.
gfc_build_memcpy_call generates calls to memcpy). For these, I believe
we need to divide the arrays into chunks and have each thread call the
builtin function on its own chunk. E.g. If we have the following call
in a parallel workshare construct:
memcpy(dst, src, len)
I generate this pseudocode:
{
numthreads = omp_get_numthreads();
chunksize = len / numthreads;
chunksize = chunksize + ( len != chunksize*numthreads)
}
#omp for
for (i = 0; i numthreads; i++) {
mysrc = src + i*chunksize;
mydst = dst + i*chunksize;
mylen = min(chunksize, len - (i*chunksize));
memcpy(mydst, mysrc, mylen);
}
If you have a suggestion to implement this in a simpler way, let me know.
Yeah, this possible. Note though what I said above about cache locality.
And, if the memcpy size is known to be small doing it in OMP_SINGLE might
have advantages too.
The above code executes parallel in every thread. Alternatively, the
first block above can be wrapped in omp_single, but the numthreads
chunksize variables should then be
declared shared instead of private. All the variables above
are private by default, since they are declared in a parallel
construct.
omp_get_num_threads is very cheap, and even with a division and
multiplication it most probably still be cheaper than OMP_SINGLE,
especially because it could not be NOWAIT.
How can I set the scoping for a specific variable in a given
omp for construct? Is the following correct to make a variable shared:
tmp = build_omp_clause(OMP_CLAUSE_SHARED);
OMP_CLAUSE_DECL(tmp) = variable;
omp_clauses = gfc_tran_add_clause(tmp, );
That, or just by letting the gimplifier set that up - if you don't
add OMP_CLAUSE_DEFAULT, by default loop iterators will be private,
the rest shared.
- I still need to do worksharing for array reduction operators (e.g.
SUM,ALL, MAXLOC etc). For these, I think a combination of OMP_FOR/OMP_SINGLE
or
OMP_REDUCTION is needed. I will also try to work on WHERE and
FORALL statements.
I guess OMP_CLAUSE_REDUCTION for sum, max etc. will be best. But testing
several variants on a bunch of testcases and benchmarking what is fastest
under what conditions is certainly the way to go in many cases.
Either you code it up in gfortran and try, or transform your original
!$omp workshare benchmarks into !$omp single, !$omp sections, !$omp for etc.
by hand and testing that is certainly possible too.
BTW, whenever you create OMP_FOR to handle part or whole !$omp workshare,
you should also choose the best scheduling kind. You could just use
schedule(auto) and let the middle-end choose the best scheduling when
that support is actually added, but often the gfortran frontend might
know even better.
I am also interested in gomp3 implementation and performance issues.
If there are not-worked-on issues suitable for newbies, please share
or update http://gcc.gnu.org/wiki/openmp. Can someone elaborate on the
Fine tune the auto scheduling feature for parallel loops issue?
ATM the largest unfinished part of OpenMP 3.0 support is the tasking
support in libgomp using {[sg]et,make,swap}context family of functions,
but it is quite high on my todo list and I'd like to work on it soon.
As OpenMP 3.0 allows unsigned iterators for #pragma omp for, that is
something that should be fixed too
Re: US-CERT Vulnerability Note VU#162289
(as an aside, as most target implementations treat pointers as unsigned
values, its not clear that presuming signed integer overflow semantics are
a reasonable choice for pointer comparison optimization)
The point is not of presuming signed integer overflow semantics (I was
corrected on this by Ian Taylor). It is of presuming that pointers never
move before the beginning of their object. If you have an array of 20
elements, pointers a[0] to a[20] are valid (accessing a[20] is not valid),
but the compiler can assume that the program does not refer to a[-2].
Paolo
Yes (and in which case if the compiler is smart enough to recognize
this it should generate an error, not emit arbitrary [or absents] of
code); but the example in question was:
void f(char *buf) {
unsigned int len = 0xFF00u; /* or similar */
if (buf+len buf) puts(true);
}
In which case buf is merely a pointer which may point to any char, not a
char within a particular array, implying buf+len is also just a pointer,
ultimately being compared against buf;
If all such pointers are presumed to be restricted to pointing to the
element they were originally assigned, then all composite pointer arithmetic
such as buf+len would be invalid. All this being said, I understand that in
general this is an anomalous case, however on small embedded machines with
small memory spaces or when writing drivers or memory allocators, such
pointer arithmetic may be perfectly legitimate it would seem.
Re: US-CERT Vulnerability Note VU#162289
On Mon, Apr 14, 2008 at 1:55 PM, Paul Schlie [EMAIL PROTECTED] wrote:
(as an aside, as most target implementations treat pointers as unsigned
values, its not clear that presuming signed integer overflow semantics are
a reasonable choice for pointer comparison optimization)
The point is not of presuming signed integer overflow semantics (I was
corrected on this by Ian Taylor). It is of presuming that pointers never
move before the beginning of their object. If you have an array of 20
elements, pointers a[0] to a[20] are valid (accessing a[20] is not
valid),
but the compiler can assume that the program does not refer to a[-2].
Paolo
Yes (and in which case if the compiler is smart enough to recognize
this it should generate an error, not emit arbitrary [or absents] of
code); but the example in question was:
void f(char *buf) {
unsigned int len = 0xFF00u; /* or similar */
if (buf+len buf) puts(true);
}
In which case buf is merely a pointer which may point to any char, not a
char within a particular array, implying buf+len is also just a pointer,
ultimately being compared against buf;
If all such pointers are presumed to be restricted to pointing to the
element they were originally assigned, then all composite pointer arithmetic
such as buf+len would be invalid. All this being said, I understand that in
general this is an anomalous case, however on small embedded machines with
small memory spaces or when writing drivers or memory allocators, such
pointer arithmetic may be perfectly legitimate it would seem.
In absence of any declared object (like with this testcase where we just
have an incoming pointer to some unknown object) the compiler can
still assume that any valid object ends at the end of the address space.
Thus, an object either declared or allocated via malloc never wraps
around to address zero. Thus, ptr + int never overflows.
Richard.
Re: US-CERT Vulnerability Note VU#162289
Paul Schlie wrote:
(as an aside, as most target implementations treat pointers as unsigned
values, its not clear that presuming signed integer overflow semantics are
a reasonable choice for pointer comparison optimization)
The point is not of presuming signed integer overflow semantics (I was
corrected on this by Ian Taylor). It is of presuming that pointers never
move before the beginning of their object. If you have an array of 20
elements, pointers a[0] to a[20] are valid (accessing a[20] is not valid),
but the compiler can assume that the program does not refer to a[-2].
Paolo
Yes (and in which case if the compiler is smart enough to recognize
this it should generate an error, not emit arbitrary [or absents] of
code); but the example in question was:
void f(char *buf) {
unsigned int len = 0xFF00u; /* or similar */
if (buf+len buf) puts(true);
}
In which case buf is merely a pointer which may point to any char, not a
char within a particular array, implying buf+len is also just a pointer,
ultimately being compared against buf;
nope, that may be in your mind what C means, but it's not what the
C language says. A pointer can only point within the allocated
object. Given that constraint, it is obvious that the condition can
never be true. Of course if the compiler elides the test on this
basis, it is nice if it warns you (certainly there is no basis
for an error message in the above code).
If all such pointers are presumed to be restricted to pointing to the
element they were originally assigned, then all composite pointer arithmetic
such as buf+len would be invalid.
no, that's just wrong, the computation buf+len is valild if the
resulting pointer is within the original object, a condition that
cannot be caught statically, and with typical implementations
cannot be caught dynamically in all cases either.
You might want to think of an implementation of C where pointers are
a pair, a base pointer and an offset, and pointer arithmetic only
works on the offset. This is a valid implementation, and is in some
sense the formal semantic model of C. It is used in some debugging
versions of C that always check this condition at run time.
It was also used in effect on the 286, where pointers at the
hardware level are segment+offset, and it is valid in C on the
286 to do arithmetic only on the offset part of the address,
and there were indeed C compilers that worked this way.
Alex Stepanov told me once that he preferred Ada to C, because Ada
has proper pointer arithmetic (via the type Integer_Address) which
is defined to work in Ada in the manner that Paul mistakenly expects
for C. Integer_Address would be a bit of a pain to implement on
a 286 :-)
Of course in C in practice, pointers are just machine addresses,
and more general pointer arithmetic does work, but any program
taking advantage of this is not written in the C language.
All this being said, I understand that in
general this is an anomalous case, however on small embedded machines with
small memory spaces or when writing drivers or memory allocators, such
pointer arithmetic may be perfectly legitimate it would seem.
Re: US-CERT Vulnerability Note VU#162289
Richard Guenther wrote: In absence of any declared object (like with this testcase where we just have an incoming pointer to some unknown object) the compiler can still assume that any valid object ends at the end of the address space. Thus, an object either declared or allocated via malloc never wraps around to address zero. Thus, ptr + int never overflows. Indeed, An interesting case is the special allowance to point just past the end of an array if the pointer is not deferenced, this allows the C idiom for (x = arr; x arr[10]; x++) ... where arr has bounds 0..9, the limit pointer is used only for testing, and this test must be valid. This means that you can't have an array allocated up to the extreme end of the address space if this would not work properly. I remember this issue arising on the 286, where the maximum size of an array was one element less than 64K bytes on one compiler to avoid this anomoly.
Re: US-CERT Vulnerability Note VU#162289
Robert Dewar [EMAIL PROTECTED] writes: Alex Stepanov told me once that he preferred Ada to C, because Ada has proper pointer arithmetic (via the type Integer_Address) which is defined to work in Ada in the manner that Paul mistakenly expects for C. Integer_Address would be a bit of a pain to implement on a 286 :-) In C it is called uintptr_t. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
[PATCH][RFC] middle-end array expressions (II)
This is the final proposal for the introduction of arrays as first class citizens of the middle-end. The goal is still to retain the high-level information that the GFortran frontend has for array assignments up to the high-level loop optimization passses and to not lower Fortran array assignments in the frontend. After several tries I settled on the following scheme (explained in detail in a paper for the GCC Summit this year). Whole-array loads and stores to gimple array registers (that will be put in SSA form) are done via a new variable length tree code that contains array extents and strides as operands (thus it properly lowers VLA objects to gimple). (VLA_VIEW_EXPR) Expressions operating on gimple array registers are doing so by means of operating on scalar placeholders, indexed array registers, that are just scalar results of a new indexing operation (VLA_IDX_EXPR). Results of these expressions are put back into array registers by doing a reverse transformation (VLA_RIDX_EXPR). To represent reductions VLA_DELTA_EXPR implements contraction of dimensions by iterating and summing over all values of certain indices. Usually examples are more useful than words (and I didn't want to repeat the whole paper here), so the following GIMPLE would compute the matrix product of two n x n matrices A and B (pointed to by a and b) and stores it into C. float A[n][n] = VLA(_VIEW_EXPR) n, 1, n, n (*a); float B[n][n] = VLA n, 1, n, n (*b); float Aik = VLA_IDX(_EXPR) i, k (A); float Bkj = VLA_IDX k, j (B); float tmp = Aik * Bkj; float Cij = VLA_DELTA(_EXPR) n, k (tmp); float C[n][n] = VLA_RIDX(_EXPR) i, j (Cij); VLA n, 1, n, n (*c) = C; More usual Fortran expressions like A(2:n-1) = B(1:n-2) + B(3:n) would look like float Btmp[n] = VLA n, 1 (B); float B1 = VLA_IDX i (Btmp); float B2 = VLA_IDX i+2 (Btmp); float tmp = B1 + B2; float Atmp = VLA_RIDX i (tmp); VLA n-2, 1 (A) = Atmp; The patch below doesn't touch the Fortran frontend but implements a (hacky) interface to C and C++ using builtins with covariant return types (see the testsuite entries to get an idea how they work). It also implements a lowering pass that turns the array expressions back to loops. It doesn't work at -O0 (because we're not in SSA form there) and I expect the lowering to be done by GRAPHITE in the end, not by a separate lowering pass. Now, I'm open to questions and I'll send the paper to anyone that wants it (but I gues I'm not supposed to put it somewhere public before the summit?). Please re-direct followups to gcc/gcc-patches according to subject. Thanks, Richard. middle-end-arrays-SSA.gz Description: GNU Zip compressed data
Re: Request copyright assignment form
Hi Bob, On Sat, 12 Apr 2008, Bob Walters wrote: Can you send me any reference to the current copyright assignment form, so that I can get this taken care of. I found something online at http://gcc.gnu.org/ml/gcc/2002-09/msg00678.html, but have no idea if that is current, so wanted to check with you first. please find below a form I just obtained from the FSF servers to start the process of assigning past (= existing) and future changes. If you fill this out and email it to [EMAIL PROTECTED] (putting your full name as the subject of that message), this will get the process going. I recommend to not just specify libstdc++ but GCC as well. Thanks for joining the team, and happy hacking! :-) Gerald snip [What is the name of the program or package you're contributing to?] [Did you copy any files or text written by someone else in these changes? Even if that material is free software, we need to know about it.] [Do you have an employer who might have a basis to claim to own your changes? Do you attend a school which might make such a claim?] [For the copyright registration, what country are you a citizen of?] [What year were you born?] [Please write your email address here.] [Please write your snail address here.] [Which files have you changed so far, and which new files have you written so far?]
Re: Where is scheduling going wrong? - GCC-4.1.2
On Sun, 2008-04-13 at 17:05 +0530, Mohamed Shafi wrote: Well i tracked down the cause to the md file. In the md file i had a define_expand for the jump pattern. Inside the pattern i was checking whether the value of the offset for the jump is out of range and if its out of range then force the offset into a register and emit indirect_jump. Though this didnt work, every time an unconditional jump was being emitted a barrier was also being emitted. It looks like in define_expand for jump we should consider all the case and emit DONE for all the cases, if you are considering any case, otherwise a barrier will be generated for cases not covered in DONE. Am i right? Sorry, I don't understand what the problem is. We always emit a barrier after an unconditional branch. Whether or not you call DONE inside the jump pattern is irrelevant. Also, whether you emit a PC-relative branch or an indirect branch is irrelevant. The following link is the reply from Ian for a query of mine regarding scheduling. http://gcc.gnu.org/ml/gcc/2008-04/msg00245.html After reading this, i feel that gcc should have looked for barrier insn while scheduling and should have given an ICE if it found one. True, barrier got into the instruction stream because of my mistake, but then thats what ICEs are for. Then again i might be wrong about this. We do have consistency checks for many problems with the RTL, but it isn't possible to catch all of them all of the time. P.S. I am still searching for a solution to choose between jump and indirect_jump pattern when the offset is out of range. http://gcc.gnu.org/ml/gcc/2008-04/msg00290.html May be you can help with that This is what the shorten_branches optimization pass is for. Define a length attribute that says how long a branch is for each offset to the target label. Then when emitting assembly language code, you can choose the correct instruction to emit based on the instruction length computed by the shorten branches pass. If you need to allocate a register, that gets a bit tricky, but there are various solutions. See the sh, mips16 (mips) and thumb (arm) ports for ideas. Jim
Re: US-CERT Vulnerability Note VU#162289
Robert C. Seacord wrote: i agree that the optimization is allowed by C99. i think this is a quality of implementation issue, and that it would be preferable for gcc to emphasize security over performance, as might be expected. On Sun, Apr 13, 2008 at 11:51:00PM +0200, Florian Weimer wrote: I don't think this is reasonable. If you use GCC and its C frontend, you want performance, not security. Furthermore, there are a number of competitors to GCC. These competitors do not advertise better security than GCC. Instead they claim better performance (though such claims should be taken with a grain of salt). To achieve high performance, it is necessary to take advantage of all of the opportunities for optimization that the C language standard permits. For CERT to simulataneously argue that GCC should be crippled (to emphasize security over performance) but that nothing negative should be said about competing compilers is the height of irresponsibility. Any suggestion that users should avoid new versions of GCC will drive users to competing compilers that optimize at least as aggressively.
Re: US-CERT Vulnerability Note VU#162289
* Robert Dewar: Florian Weimer wrote: * Robert C. Seacord: i agree that the optimization is allowed by C99. i think this is a quality of implementation issue, and that it would be preferable for gcc to emphasize security over performance, as might be expected. I don't think this is reasonable. If you use GCC and its C frontend, you want performance, not security. I find this a *VERY* dubious claim, in my experience VERY few users are at the boundary where small factors in performance are critical, but MANY users are definitely concerned with security. Existing safe C implementations take a performance hit which is a factor between 5 and 11 in terms of execution time. There is some new research that seems to get away with a factor less than 2, but it's pretty recent and I'm not sure if it's been reproduced independently. If GCC users are actually willing to take that hit for some gain in security (significant gains for a lot of legacy code, of course), then most of the recent work on GCC has been wasted. I don't think this is the case. Keep in mind it's not the comparison that's the real problem here, it's the subsequent buffer overflow. And plugging that hole in full generality is either difficult to do, or involves a significant run-time performance overhead (or both). To me, dubious optimizations like this at the very least should be optional and able to be turned off. Why is this optimization dubious? We would need to look at real-world code to tell, and so far, we haven't heard anything about the context in which the issue was originally encountered.
Re: A Query regarding jump pattern
Mohamed Shafi [EMAIL PROTECTED] writes: I have read in the internals that indirect_jump and jump pattern are necessary in any back-end for the compiler to be build and work successfully. For any back-end there will be some limitation as to how big the offset used in the jump instructions can be. If the offset is too big then the indirect_jump pattern has to utilized. Now my question is how will i be able to specify the limit of the offset so the gcc generates indirect_jump pattern instead of the jump pattern? I hope i am clear. From the perspective of insn names, it's not quite accurate to say that jump turns into indirect_jump. It would be more correct to say that when there is a limit to the offset for jump, it needs to use a register. The way to handle this is to set the length attribute correctly for each insn, and to change code generation based on the length. See, e.g., the mips.md jump insn for an example. Ian
Re: Problem compiling apache 2.0.63, libiconv.so: wrong ELF class: ELFCLASS32
Persson Håkan [EMAIL PROTECTED] writes: I'm having problem when making apache 2.0.63. Wrong mailing list. gcc@gcc.gnu.org is about developing gcc. [EMAIL PROTECTED] is about using gcc. I don't know the answer to your question. It looks specific to your distribution. Ian
Re: A query regarding the implementation of pragmas
Mohamed Shafi wrote: For a function call will i be able to implement long call/short call for the same function at different locations? Say fun1 calls bar and fun2 calls bar. I want short-call to be generated for bar in fun1 and long-call to be generated in fun2. Is to possible to implement this in the back-end using pragmas? A simple grep command shows that both arm and rs6000 already both support long call pragmas. Jim
Re: Mapping back to original variables after SSA optimizations
On 4/10/08 8:16 AM, Fran Baena wrote: Hi all, i have a doubt about unSSA: is it allways possible to map back the versioned variables to the original variable? If it could be possible, is there an algorithm that describe this translation back? It is not always possible. If there are overlapping live ranges for two names of the same symbol, two different symbols need to be created. That's the reason why we do not allow overlapping live-ranges on memory variables. Memory variables are not put in standard SSA form. We build FUD (factored use-def) chains for those. See Wolfe's book High performance compilers for parallel computing for details. I have read the paper Efficiently computing static single assignment form and the control dependence graph (cytron91) and no way to translate back from SSA is explained, it only points out that after SSA optimizations dead code elminitation and allocation by colloring are recommended to be performed. The out-of-SSA pass was modeled after the algorithm in Robert Morgan's book Building an Optimizing Compiler. Diego.
Re: US-CERT Vulnerability Note VU#162289
Florian Weimer [EMAIL PROTECTED] writes: To me, dubious optimizations like this at the very least should be optional and able to be turned off. Why is this optimization dubious? We would need to look at real-world code to tell, and so far, we haven't heard anything about the context in which the issue was originally encountered. The basis of the optimization in question is http://gcc.gnu.org/PR27039 . A theoretical argument for why somebody might write problematic code is http://www.fefe.de/openldap-mail.txt . I don't know where, or even if, such code is actually found in the wild. Ian
Re: US-CERT Vulnerability Note VU#162289
Ian Lance Taylor wrote: A theoretical argument for why somebody might write problematic code is http://www.fefe.de/openldap-mail.txt . I don't know where, or even if, such code is actually found in the wild. Ian Fair enough question. The other question of course is how much this optimization saves.
Re: US-CERT Vulnerability Note VU#162289
On Mon, Apr 14, 2008 at 04:27:40PM -0400, Robert Dewar wrote: Ian Lance Taylor wrote: A theoretical argument for why somebody might write problematic code is http://www.fefe.de/openldap-mail.txt . I don't know where, or even if, such code is actually found in the wild. Ian Fair enough question. The other question of course is how much this optimization saves. The big savings are in loops, where the compiler can determine that it doesn't have to consider the possibility of aliasing and can therefore use values in registers instead of reloading from memory.
Re: US-CERT Vulnerability Note VU#162289
Florian Weimer wrote: Existing safe C implementations take a performance hit which is a factor between 5 and 11 in terms of execution time. There is some new research that seems to get away with a factor less than 2, but it's pretty recent and I'm not sure if it's been reproduced independently. If GCC users are actually willing to take that hit for some gain in security (significant gains for a lot of legacy code, of course), then most of the recent work on GCC has been wasted. I don't think this is the case.\ This is wholly excessive rhetoric, it's using a common invalid device in argument, sometimes called extenso ad absurdum. It goes like this You advocate A But then to be consistent you should also advocate B,C,D,E I will now argue against the combination A,B,C,D,E :-) :-) These implementations that are 5-11 times slower are doing all sorts of things that a) I am not advocating in this discussion b) I would not advocate in any case Are you really saying that this particular optimization is costly to eliminate? If so I just don't believe that allegation without data. Keep in mind it's not the comparison that's the real problem here, it's the subsequent buffer overflow. And plugging that hole in full generality is either difficult to do, or involves a significant run-time performance overhead (or both). And there you go! I do NOT advocate plugging that hole in full generality, so go try this argument on someone who does (I don't think there are any such people around here!) To me, dubious optimizations like this at the very least should be optional and able to be turned off. Why is this optimization dubious? We would need to look at real-world code to tell, and so far, we haven't heard anything about the context in which the issue was originally encountered. An optimziation is dubious to me if a) it produces surprising changes in behavior (note the importance of the word surprising here) b) it does not provide significant performance gains (note the importance of the word significant here). I find this optimization qualifies as meeting both criteria a) and b), so that's why I consider it dubious.
Re: US-CERT Vulnerability Note VU#162289
Joe Buck wrote: On Mon, Apr 14, 2008 at 04:27:40PM -0400, Robert Dewar wrote: Ian Lance Taylor wrote: A theoretical argument for why somebody might write problematic code is http://www.fefe.de/openldap-mail.txt . I don't know where, or even if, such code is actually found in the wild. Ian Fair enough question. The other question of course is how much this optimization saves. The big savings are in loops, where the compiler can determine that it doesn't have to consider the possibility of aliasing and can therefore use values in registers instead of reloading from memory. Savings? yes Big? (from this particular optimization) dubious without data.
RE: US-CERT Vulnerability Note VU#162289
Robert Dewar wrote: An optimziation is dubious to me if a) it produces surprising changes in behavior (note the importance of the word surprising here) b) it does not provide significant performance gains (note the importance of the word significant here). I find this optimization qualifies as meeting both criteria a) and b), so that's why I consider it dubious. I don't think this is a particularly fruitful argument to be having at this stage. It's already been acknowledged that the source code is wrong to assume that the compiler knows about wrapping of pointers. The real issue at this stage is how to warn users who may be using GCC and implicitly relying on its old behavior, without unintentionally pushing people in the wrong direction. Since this optimization is performed by many other compilers, the ship has already sailed on this one, so to speak. [In fact, after GCC does something to warn users about this, it'll be much safer than those other compilers.] I agree that on the face of it, it seems like you wouldn't want to optimize away tests like this when you can know that pointer arithmetic really does look the same as unsigned arithmetic (for a particular architecture, etc.). However, sometimes an optimization may enable thirty more, so I for one am not going to argue against it. Especially not when many other compilers do it also. -Jerry P.S. I'm having some déjà vu, recalling discussions back in the GCC 2.7 days about whether it was really OK to change the behavior for signed arithmetic to support devices with saturation. We've come a long way since then.
Re: Problem with reloading in a new backend...
Le vendredi 11 avril 2008 à 11:14 -0700, Jim Wilson a écrit :
Stelian Pop wrote:
#define PREFERRED_RELOAD_CLASS(X, CLASS)\
((CONSTANT_P(X)) ? EIGHT_REGS : \
(MEM_P(X)) ? EVEN_REGS : CLASS)
#define PREFERRED_OUTPUT_RELOAD_CLASS(X, CLASS) \
((CONSTANT_P(X)) ? EIGHT_REGS : \
(MEM_P(X)) ? EVEN_REGS : CLASS)
I think most of your trouble is here. Suppose we are trying to reload a
constant into an even-reg. We call PREFERRED_RELOAD_CLASS, which says
to use eight_regs instead, and you get a fatal_insn error because you
didn't get the even-reg that the instruction needed.
[...]
I've tried the suggestion above and it did indeed help. However, I had a
few additional issues:
- the stack pointer and the frame pointer MUST be placed into an
even-reg, or else reload will generate (mem (plus (reg) (const))) insn
(when eliminating the pointers).
- I had to add a PLUS case in PREFERRED_RELOAD_CLASS() or else reload
kept generating incorrect insn (putting constants into EVEN_REGS for
example). I'm not sure this is correct or if it hides something else...
#define STACK_POINTER_REGNUM 30
#define FRAME_POINTER_REGNUM 28
#define PREFERRED_RELOAD_CLASS(X, CLASS) ardac_preferred_reload_class(X, CLASS)
#define PREFERRED_OUTPUT_RELOAD_CLASS(X, CLASS) ardac_preferred_reload_class(X,
CLASS)
enum reg_class
ardac_preferred_reload_class(rtx x, enum reg_class class)
{
if (CONSTANT_P(x)) {
switch (class) {
case NO_REGS:
case STACK_REGS:
return NO_REGS;
case EVEN_REGS:
case EIGHTEVEN_REGS:
return EIGHTEVEN_REGS;
case EIGHT_REGS:
case GENERAL_REGS:
return EIGHT_REGS;
default:
gcc_unreachable ();
}
}
else if (MEM_P(x)) {
switch (class) {
case NO_REGS:
case STACK_REGS:
return NO_REGS;
case EIGHT_REGS:
case EIGHTEVEN_REGS:
return EIGHTEVEN_REGS;
case EVEN_REGS:
case GENERAL_REGS:
return EVEN_REGS;
default:
gcc_unreachable ();
}
}
else {
if (GET_CODE (x) == PLUS
GET_CODE (XEXP (x, 0)) == REG
GET_CODE (XEXP (x, 1)) == CONST_INT) {
return EIGHTEVEN_REGS;
}
return class;
}
}
Now it compiler 100+ files from libgcc without error so I guess the
register assignment problem is solved. It now fails later:
/home/tiniou/LTD/LTD/aRDAC/wip/src/gcc-4.3.0/libgcc/../gcc/unwind-dw2-fde.c: In
function ‘frame_heapsort’:
/home/tiniou/LTD/LTD/aRDAC/wip/src/gcc-4.3.0/libgcc/../gcc/unwind-dw2-fde.c:521:
internal compiler error: in expand_call, at calls.c:3149
I haven't investigated why yet, but this is probably not related to the above.
Thanks,
--
Stelian Pop [EMAIL PROTECTED]
Re: US-CERT Vulnerability Note VU#162289
[EMAIL PROTECTED] wrote: It's already been acknowledged that the source code is wrong to assume that the compiler knows about wrapping of pointers. The real issue at this stage is how to warn users who may be using GCC and implicitly relying on its old behavior, without unintentionally pushing people in the wrong direction. Since this optimization is performed by many other compilers, the ship has already sailed on this one, so to speak. that's a strong argument I agree [In fact, after GCC does something to warn users about this, it'll be much safer than those other compilers.] For sure you want a warning, the compiler should never be removing explicit tests in the users code without generating a warning I would think. I agree that on the face of it, it seems like you wouldn't want to optimize away tests like this when you can know that pointer arithmetic really does look the same as unsigned arithmetic (for a particular architecture, etc.). However, sometimes an optimization may enable thirty more, so I for one am not going to argue against it. Especially not when many other compilers do it also. Not sure I agree with that, but I can certainly live with a warning. -Jerry P.S. I'm having some déjà vu, recalling discussions back in the GCC 2.7 days about whether it was really OK to change the behavior for signed arithmetic to support devices with saturation. We've come a long way since then. :-)
gcc-4.1-20080414 is now available
Snapshot gcc-4.1-20080414 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20080414/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch revision 134294 You'll find: gcc-4.1-20080414.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20080414.tar.bz2 C front end and core compiler gcc-ada-4.1-20080414.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20080414.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20080414.tar.bz2 C++ front end and runtime gcc-java-4.1-20080414.tar.bz2 Java front end and runtime gcc-objc-4.1-20080414.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20080414.tar.bz2The GCC testsuite Diffs from 4.1-20080407 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 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: US-CERT Vulnerability Note VU#162289
On Mon, Apr 14, 2008 at 06:42:30PM -0400, Robert Dewar wrote: [In fact, after GCC does something to warn users about this, it'll be much safer than those other compilers.] For sure you want a warning, the compiler should never be removing explicit tests in the users code without generating a warning I would think. I vaguely recall a paper from Dawson Engler's group (the people who did the Stanford Checker and Coverity) about warnings for dead code removal. They are often bugs if seen in straight-line code, but macros as well as inlining of functions will produce many warnings of this kind. They focused their work on addressing what the user could be expected to know, the idea being to issue warnings if the code on a single level is redundant, but suppress warnings if the redundant text came from macros or inlining.
INSTALL/configure.html mentions ${gcc_tooldir} - what's that?
Hi,
INSTALL/configure.html mentions ${gcc_tooldir}, just once. Here:
Cross-Compiler-Specific Options
The following options only apply to building cross compilers.
--with-sysroot
--with-sysroot=dir
Tells GCC to consider dir as the root of a tree that contains
a (subset of) the root filesystem of the target operating system.
Target system headers, libraries and run-time object files
will be searched in there. The specified directory is not copied
into the install tree, unlike the options --with-headers
and --with-libs that this option obsoletes. The default value,
in case --with-sysroot is not given an argument, is ${gcc_tooldir}/sys-root.
^^^
If the specified directory is a subdirectory of ${exec_prefix},
then it will be found relative to the GCC binaries if the installation
tree is moved.
Well, that's not too helpful.
Please, can somebody add an explanation to INSTALL/configure.html
what ${gcc_tooldir} is, and how to set it (I guess with configure
option or something?)
--
vda
MAX_CONSTRAINT VALUE
Hello Everyone,
I am currently working on OpenRISC port of GCC and I am trying to
add more constraints to the machine-dependent part and the default
number of constrant seem to be only 30 (and obviously I have more than
30 constraints, and thus it was failing). I tried making this a #define
value and moved this to the machine dependent part. This is advantageous
because now the backend designer has more flexibility.
Here is the patch for it (if a value is not provided, then the
default value of 30 is assumed). I tried to build this for x86 and arm
and they seem to work fine with no problems.
Here is the patch for it (I am working on GCC 4.0.2).
==
diff -Naur gcc.old/recog.c gcc.new/recog.c
--- gcc.old/recog.c 2008-04-14 19:57:58.5 -0400
+++ gcc.new/recog.c 2008-04-14 20:08:31.34375 -0400
@@ -2039,7 +2039,7 @@
= (recog_data.constraints[i][0] == '=' ? OP_OUT
: recog_data.constraints[i][0] == '+' ? OP_INOUT
: OP_IN);
-
+
gcc_assert (recog_data.n_alternatives = MAX_RECOG_ALTERNATIVES);
}
diff -Naur gcc.old/recog.h gcc.new/recog.h
--- gcc.old/recog.h 2008-04-14 19:57:58.5 -0400
+++ gcc.new/recog.h 2008-04-14 19:54:44.828125000 -0400
@@ -20,7 +20,12 @@
02111-1307, USA. */
/* Random number that should be large enough for all purposes. */
-#define MAX_RECOG_ALTERNATIVES 30
+
+#ifdef TARGET_MAX_RECOG_ALTERNATIVES
+#define MAX_RECOG_ALTERNATIVES TARGET_MAX_RECOG_ALTERNATIVES
+#else
+#define MAX_RECOG_ALTERNATIVES 30
+#endif
/* Types of operands. */
enum op_type {
diff -Naur gcc.old/target-def.h gcc.new/target-def.h
--- gcc.old/target-def.h2008-04-14 19:58:00.46875 -0400
+++ gcc.new/target-def.h2008-04-14 19:54:45.71875 -0400
@@ -187,6 +187,11 @@
#define TARGET_ASM_MARK_DECL_PRESERVED hook_void_constcharptr
#endif
+#ifndef TARGET_MAX_RECOG_ALTERNATIVES
+#define TARGET_MAX_RECOG_ALTERNATIVES 32
+#endif
+
+
#define TARGET_ASM_ALIGNED_INT_OP \
{TARGET_ASM_ALIGNED_HI_OP, \
TARGET_ASM_ALIGNED_SI_OP, \
==
Thanks,
Balaji V. Iyer.
--
Balaji V. Iyer
PhD Student,
Center for Efficient, Scalable and Reliable Computing,
Department of Electrical and Computer Engineering,
North Carolina State University.
Re: RFC: named address space support
Hi Mark I'm not terribly familiar with this proposal. Ben, to answer your original question, I don't think that lack of nested address spaces is a fatal flaw, as long as the implementation otherwise meets the spec, and as long as the implementation doesn't somehow make it harder to add that. However, I'd like to know how final this proposal is, and how likely it is to make the WG14 WP. According to: http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=30822 .. the embedded C proposal as of 2008-01-18 is at stage 90.92. This suggests that it's very close to being incorporated into the standard. Have I understood that correctly? As always, I'm concerned about putting things into GCC and then finding out that we have to change them in ways that are not backwards compatible. And, I'd like to know what our C maintainers make of the proposal overall; if they see language issues, then we might want to resolve those with WG14. Sure. Any comments from Joseph or Richard? Cheers, Ben
Re: US-CERT Vulnerability Note VU#162289
Robert Dewar [EMAIL PROTECTED] Richard Guenther wrote: In absence of any declared object (like with this testcase where we just have an incoming pointer to some unknown object) the compiler can still assume that any valid object ends at the end of the address space. Thus, an object either declared or allocated via malloc never wraps around to address zero. Thus, ptr + int never overflows. Indeed, An interesting case is the special allowance to point just past the end of an array if the pointer is not deferenced, this allows the C idiom for (x = arr; x arr[10]; x++) ... where arr has bounds 0..9, the limit pointer is used only for testing, and this test must be valid. This means that you can't have an array allocated up to the extreme end of the address space if this would not work properly. I remember this issue arising on the 286, where the maximum size of an array was one element less than 64K bytes on one compiler to avoid this anomoly. Further, although admittedly contrived, if a pointer to a second element of an array is passed, to which an (unsigned) -1 is added, which in effect generates an unsigned wrapping overflow and ends up pointing to the first element of the same array; whereby such a sum will be both less than the pointer passed and be known to reference the first element of the same array. (So thereby if for some reason someone wants to pass not a pointer to the first element of an array, but rather the Nth element and subsequently access the Nth-X element, it is conceivable that one may want to verify that the resulting pointer will always be less than the pointer passed, and seemingly be legitimate.)
Re: MAX_CONSTRAINT VALUE
Hi there Balaji, Here is the patch for it (if a value is not provided, then the default value of 30 is assumed). I tried to build this for x86 and arm and they seem to work fine with no problems. Thanks for the patch. You should send your patch to gcc-patches, though, not the main GCC list. Cheers, Ben
Re: Problem with reloading in a new backend...
On Tue, 2008-04-15 at 00:06 +0200, Stelian Pop wrote: - I had to add a PLUS case in PREFERRED_RELOAD_CLASS() or else reload kept generating incorrect insn (putting constants into EVEN_REGS for example). I'm not sure this is correct or if it hides something else... It does sound odd, but I can't really say it is wrong, as you have an odd set of requirements here. At least it is working which is good. Jim
Re: US-CERT Vulnerability Note VU#162289
Joe Buck wrote: On Mon, Apr 14, 2008 at 06:42:30PM -0400, Robert Dewar wrote: [In fact, after GCC does something to warn users about this, it'll be much safer than those other compilers.] For sure you want a warning, the compiler should never be removing explicit tests in the users code without generating a warning I would think. I vaguely recall a paper from Dawson Engler's group (the people who did the Stanford Checker and Coverity) about warnings for dead code removal. They are often bugs if seen in straight-line code, but macros as well as inlining of functions will produce many warnings of this kind. They focused their work on addressing what the user could be expected to know, the idea being to issue warnings if the code on a single level is redundant, but suppress warnings if the redundant text came from macros or inlining. Right, we have heuristics in the Ada front end along these lines. For instance, you generally want to be warned if a test is always true or always false, but if the test is if XYZ then where XYZ is a boolean constant, then probably this is conditional compilation type activity that is legitimate.
IA-64 ICE on integer divide due to trap_if and cfgrtl
This testcase extracted from libgcc2.c
int
sub (int i)
{
if (i == 0)
return 1 / i;
return i + 2;
}
compiled with -minline-int-divide-min-latency for IA-64 generates an
ICE.
tmp2.c:8: error: flow control insn inside a basic block
(insn 18 17 19 3 tmp2.c:5 (trap_if (const_int 1 [0x1])
(const_int 1 [0x1])) 352 {*trap} (nil))
tmp2.c:8: internal compiler error: in rtl_verify_flow_info_1, at
cfgrtl.c:1920
The problem is that IA-64 ABI specifies that integer divides trap, so we
must emit a conditional trap instruction. cse simplifies the compare.
combine substitutes the compare into the conditional trap changing it to
an unconditional trap. The next pass then fails a consistency check in
cfgrtl.
It seems odd that cfgrtl allows a conditional trap inside a basic block,
but not an unconditional trap. The way things are now, it means we need
to fix up the basic blocks after running combine or any other pass that
might be able to simplify a conditional trap into an unconditional trap.
I can work around this in the IA64 port. For instance I could use
different patterns for conditional and unconditional traps so that one
can't be converted to the other. Or I could try to hide the conditional
trap inside some pattern that doesn't get expanded until after reload.
None of these solutions seems quite right.
But changing the basic block tree during/after combine doesn't seem
quite right either.
The other solution would be to fix cfgbuild to treat all trap
instructions are control flow insns, instead of just the unconditional
ones. I'm not sure why it was written this way though, so I don't know
if this will cause other problems. I see that sibling and noreturn
calls are handled the same way as trap instructions, implying that they
are broken too.
I'm looking for suggestions here as what I should do to fix this.
Jim
[ARM] Lack of __aeabi_fsqrt / __aeabi_dsqrt (sqrtsf2 / sqrtdf2) functions
Hello all, I've been working on MaverickCrunch support in gcc, and could never get a completely working glibc (with-fp), since there is no soft-float sqrt libcall function. This is a big problem for MaverickCrunch as there are no hard div or sqrt opcodes. It seems that this is the only other thing that is missing to let glibc be compiled with-fp for soft float arm, too. Is it possible to add these functions to ieee754-sf.S and ieee754-df.S ??? There is of course a c implementation in glibc/soft-fp but I don't know of any arm assembly implementation... I know that ARM IHI 0043A doesn't specific this as part of the EABI, but perhaps it needs to be added? Thanks
Re: [ARM] Lack of __aeabi_fsqrt / __aeabi_dsqrt (sqrtsf2 / sqrtdf2) functions
On Tue, Apr 15, 2008 at 12:33:38PM +1000, Hasjim Williams wrote: Hello all, I've been working on MaverickCrunch support in gcc, and could never get a completely working glibc (with-fp), since there is no soft-float sqrt libcall function. This is a big problem for MaverickCrunch as there are no hard div or sqrt opcodes. It seems that this is the only other thing that is missing to let glibc be compiled with-fp for soft float arm, too. Is it possible to add these functions to ieee754-sf.S and ieee754-df.S ??? There is of course a c implementation in glibc/soft-fp but I don't know of any arm assembly implementation... I know that ARM IHI 0043A doesn't specific this as part of the EABI, but perhaps it needs to be added? Can you be more specific about the actual problem? I don't see why there needs to be an __aeabi_sqrt; sqrt is a function in libm. -- Daniel Jacobowitz CodeSourcery
Re: Official GCC git repository
On Wed, Mar 26, 2008 at 02:38:53PM -0400, Daniel Berlin wrote:
On Wed, Mar 26, 2008 at 12:30 PM, Frank Ch. Eigler [EMAIL PROTECTED] wrote:
Hi -
On Fri, Mar 14, 2008 at 10:41:42AM -0400, Frank Ch. Eigler wrote:
[...]
OK, /git/gcc.git appears ready for you to populate maintain. Access
as {http,git,ssh}://gcc.gnu.org/gcc.git should all work.
Just a reminder - an empty git repository has been ready for you for some
time.
Guys, if you want, i can populate it with my git-svn clone, which has
a svn root id of ssh://gcc.gnu.org//svn/gcc (IE the proper root if you
wanted to be able to dcommit), and has all branches (but no tags).
Any progress?
--
Regards, Kirill A. Shutemov
+ Belarus, Minsk
+ ALT Linux Team, http://www.altlinux.com/
signature.asc
Description: Digital signature
Re: [ARM] Lack of __aeabi_fsqrt / __aeabi_dsqrt (sqrtsf2 / sqrtdf2) functions
On Mon, 14 Apr 2008 22:41:36 -0400, Daniel Jacobowitz [EMAIL PROTECTED] said: On Tue, Apr 15, 2008 at 12:33:38PM +1000, Hasjim Williams wrote: Hello all, I've been working on MaverickCrunch support in gcc, and could never get a completely working glibc (with-fp), since there is no soft-float sqrt libcall function. This is a big problem for MaverickCrunch as there are no hard div or sqrt opcodes. Can you be more specific about the actual problem? I don't see why there needs to be an __aeabi_sqrt; sqrt is a function in libm. Both FPA and VFP coprocessors implement sqrt opcodes: arm.md: (define_expand sqrtsf2 [(set (match_operand:SF 0 s_register_operand ) (sqrt:SF (match_operand:SF 1 s_register_operand )))] TARGET_32BIT TARGET_HARD_FLOAT (TARGET_FPA || TARGET_VFP) ) fpa.md: (define_insn *sqrtsf2_fpa [(set (match_operand:SF 0 s_register_operand =f) (sqrt:SF (match_operand:SF 1 s_register_operand f)))] TARGET_32BIT TARGET_HARD_FLOAT TARGET_FPA sqt%?s\\t%0, %1 [(set_attr type float_em) (set_attr predicable yes)] ) vfp.md: (define_insn *sqrtsf2_vfp [(set (match_operand:SF0 s_register_operand =t) (sqrt:SF (match_operand:SF 1 s_register_operand t)))] TARGET_32BIT TARGET_HARD_FLOAT TARGET_VFP fsqrts%?\\t%0, %1 [(set_attr predicable yes) (set_attr type fdivs)] ) Now, when you build glibc configured --with-fp, you won't use the generic glibc/soft-fp functions, only those in gcc, i.e. the above. Only if you configure glibc --without-fp will it not use the above opcodes, but the soft-fp sqrt etc.
Re: [ARM] Lack of __aeabi_fsqrt / __aeabi_dsqrt (sqrtsf2 / sqrtdf2) functions
On Tue, Apr 15, 2008 at 12:58:40PM +1000, Hasjim Williams wrote: Both FPA and VFP coprocessors implement sqrt opcodes: So? Glibc does not rely on that. I've been building soft-float versions of glibc for non-Crunch targets for scarily close to a decade now, so this is clearly not the problem :-) Please say what actual error you've encountered. -- Daniel Jacobowitz CodeSourcery
Re: [ARM] Lack of __aeabi_fsqrt / __aeabi_dsqrt (sqrtsf2 / sqrtdf2) functions
On Mon, 14 Apr 2008 23:09:00 -0400, Daniel Jacobowitz [EMAIL PROTECTED] said: On Tue, Apr 15, 2008 at 12:58:40PM +1000, Hasjim Williams wrote: Both FPA and VFP coprocessors implement sqrt opcodes: So? Glibc does not rely on that. I've been building soft-float versions of glibc for non-Crunch targets for scarily close to a decade now, so this is clearly not the problem :-) Please say what actual error you've encountered. Of course you can build glibc and have it work correctly, as you are configuring glibc --without-fp. Try building glibc --with-fp and seeing whether it works. Suffice to say, it will compile, but when you try to run it, and your program tries to do the libcall to the sqrt function it will segfault, because there is no libcall sqrt defined. As far as I can tell, sqrt and div are the only major opcodes that are needed (for ieee754 glibc --with-fp) that aren't implemented in MaverickCrunch.
Can't build correctly working crosscompiler with 4.3.0. 4.2.1 worked like charm
Ok, I give up. I killed many hours trying to build a cross-compiling x86_64-linux-uclibc-gcc, version 4.3.0. After many WTF? moments I decided to go back and try to build a cross-compiler which I already have, just older version: I decided to build i486 one, not x86_64. Because I already have i486-linux-uclibc-gcc version 4.2.1 and it works. I unpacked and built i486-linux-uclibc-gcc version 4.3.0 with absolutely the same configure and make command lines, and it does not work. Specifically, it seems to mess up paths: i486-linux-uclibc-gcc: error trying to exec 'cc1': execvp: No such file or directory stracing gcc invocation reveals typical ..bin/../lib/something/../../../../../something-else/.. stuff, but this time, it definitely fails to pick up cc1. (See below for strace comparison between 4.2.1 and 4.3.0) Yeah, yeah, I saw it with x86_64-linux-uclibc-gcc too and was able to overcome it with even more hacks and options in configure, but it won't stop there! It will use wrong as and/or ld; then it will also try to link wrong crtX.o files which do not exist! So I won't try to fix that now - instead, let's concentrate on how in hell? it was working before! Well, hrm last sanity check: I remove i486-linux-uclibc-gcc version 4.2.1, unpack fresh 4.2.1, build it with the very same configure and make options and IT WORKS! So, something definitely is changed incompatibly between 4.2.1 and 4.3.0 Help... STATIC=/usr/app/gcc-4.3.0-i486-linux-uclibc configure invocation: ../gcc-4.3.0/configure \ --prefix=$STATIC\ --exec-prefix=$STATIC \ --bindir=/usr/bin \ --sbindir=/usr/sbin \ --libexecdir=$STATIC/libexec\ --datadir=$STATIC/share \ --sysconfdir=/etc \ --sharedstatedir=$STATIC/var/com\ --localstatedir=$STATIC/var \ --libdir=/usr/lib \ --includedir=/usr/include \ --infodir=/usr/info \ --mandir=/usr/man \ \ --with-slibdir=$STATIC/lib \ --disable-shared\ --with-local-prefix=/usr/local \ --with-gxx-include-dir=$STATIC/include/g++-v3 \ --enable-languages=c,c++ \ --disable-nls \ \ --build=i386-pc-linux-gnu \ --host=i386-pc-linux-gnu\ --target=i486-linux-uclibc \ \ --disable-__cxa_atexit \ --enable-target-optspace\ --with-gnu-ld \ --disable-threads \ --disable-multilib \ --without-headers \ make invocation: make all-gcc make install invocation: make \ prefix=$STATIC \ exec-prefix=$STATIC \ bindir=$STATIC/bin \ sbindir=$STATIC/sbin\ libexecdir=$STATIC/libexec \ datadir=$STATIC/share \ sysconfdir=$STATIC/var/etc \ sharedstatedir=$STATIC/var/com \ localstatedir=$STATIC/var \ libdir=$STATIC/lib \ includedir=$STATIC/include \ infodir=$STATIC/info\ mandir=$STATIC/man \ \ install-gcc gcc 4.3.0 fails to find cc1: 30816 stat64(/.share/usr/app/gcc-4.3.0-i486-linux-uclibc/bin/../app/gcc-4.3.0-i486-linux-uclibc/libexec/gcc/i486-linux-uclibc/4.3.0/cc1, 0xffde613c) = -1 ENOENT (No such file or directory) 30816 stat64(/.share/usr/app/gcc-4.3.0-i486-linux-uclibc/bin/../app/gcc-4.3.0-i486-linux-uclibc/libexec/gcc/cc1, 0xffde613c) = -1 ENOENT (No such file or directory) 30816 stat64(/.share/usr/app/gcc-4.3.0-i486-linux-uclibc/bin/../lib/gcc/i486-linux-uclibc/4.3.0/../../../../../i486-linux-uclibc/bin/i486-linux-uclibc/4.3.0/cc1, 0xffde613c) = -1 ENOENT (No such file or directory) 30816 stat64(/.share/usr/app/gcc-4.3.0-i486-linux-uclibc/bin/../lib/gcc/i486-linux-uclibc/4.3.0/../../../../../i486-linux-uclibc/bin/cc1, 0xffde613c) = -1 ENOENT (No such file or directory) 30816 vfork() = 30817 30817 execve(/root/bin/cc1, [cc1, -quiet, -Iinclude, -Ilibbb, -I/.1/usr/srcdevel/bbox/fix/busy..., -iprefix, /.share/usr/app/gcc-4.3.0-i486-l..., -D_GNU_SOURCE, -DNDEBUG, -D_LARGEFILE_SOURCE, -D_LARGEFILE64_SOURCE, -D_FILE_OFFSET_BITS=64, -DBB_VER=KBUILD_STR(1.11.0.svn), -DBB_BT=AUTOCONF_TIMESTAMP, -DKBUILD_STR(s)=#s, -DKBUILD_BASENAME=KBUILD_STR(app..., ...], [/* 35 vars */]) = -1 ENOENT (No such file or directory) 30817 execve(/bin/cc1, [cc1, -quiet, -Iinclude, -Ilibbb, -I/.1/usr/srcdevel/bbox/fix/busy..., -iprefix, /.share/usr/app/gcc-4.3.0-i486-l..., -D_GNU_SOURCE, -DNDEBUG, -D_LARGEFILE_SOURCE, -D_LARGEFILE64_SOURCE, -D_FILE_OFFSET_BITS=64,
Re: US-CERT Vulnerability Note VU#162289
Robert Dewar [EMAIL PROTECTED] writes: An optimziation is dubious to me if a) it produces surprising changes in behavior (note the importance of the word surprising here) b) it does not provide significant performance gains (note the importance of the word significant here). I find this optimization qualifies as meeting both criteria a) and b), so that's why I consider it dubious. To this particular optimization does not meet criteria a). I never write code that constructs a pointer which does not point to any object, because I know that is invalid. I think it is rather weird that anybody would write code like this. If I want to check whether an index is out of bounds, I compare the index and the length of the buffer. I don't use a pointer comparison to check for an out of bounds index. I don't know about criteria b), I haven't measured. It's easy to come up with test cases where it gives a performance gain--many loops with a pointer induction variable will benefit--but I don't know how significant they are. Ian
Re: IA-64 ICE on integer divide due to trap_if and cfgrtl
Jim Wilson [EMAIL PROTECTED] writes: It seems odd that cfgrtl allows a conditional trap inside a basic block, but not an unconditional trap. The way things are now, it means we need to fix up the basic blocks after running combine or any other pass that might be able to simplify a conditional trap into an unconditional trap. I can work around this in the IA64 port. For instance I could use different patterns for conditional and unconditional traps so that one can't be converted to the other. Or I could try to hide the conditional trap inside some pattern that doesn't get expanded until after reload. None of these solutions seems quite right. But changing the basic block tree during/after combine doesn't seem quite right either. The other solution would be to fix cfgbuild to treat all trap instructions are control flow insns, instead of just the unconditional ones. I'm not sure why it was written this way though, so I don't know if this will cause other problems. I see that sibling and noreturn calls are handled the same way as trap instructions, implying that they are broken too. I think the current cfgbuild behaviour is just to avoid putting a barrier in the middle of a basic block. A conditional trap instruction is not necessarily a control flow instruction for the compiler--it's similar to a function call which may or may not return. An unconditional trap is similar to a function call which is known to not return. I guess the difference is that combine can't turn a function call which may or may not return into a function call which will not return. Since traps are uncommon, and since you can't do a lot of optimization around them anyhow, it's probably OK to make them always return true from control_flow_insn_p. At least it's worth trying to see if anything breaks. Ian
Re: Moving statements from one BB to other BB.
To clarify what Richard means, your assertion that you have updated SSA information is false. If you had updated the SSA information, the error would not occur :). How exactly are you updating the ssa information? The general way to update SSA for this case would be: For each statement you have moved: Call update_stmt (t); Then call update_ssa (TODO_update_ssa) (or instead use rewrite_into_loop_closed_ssa if this is a loop pass). If you do not call update_stmt in this case, update_ssa won't actually do anything. Diego, the bsi iterators do not update the statements for you though it is not clear if this is a bug or not. The bsi iterators call update_modified_stmts, which says: /* Mark statement T as modified, and update it. */ static inline void update_modified_stmts (tree t) However, this only calls update_stmt_if_modified (IE it does not mark the statement as modified and update it, as it claims to). Sandeep, it should also suffice to call mark_stmt_modified *before* moving the statements (since the above routine should then update them). On Mon, Apr 14, 2008 at 7:10 AM, Richard Guenther [EMAIL PROTECTED] wrote: On Mon, Apr 14, 2008 at 12:54 PM, Sandeep Maram [EMAIL PROTECTED] wrote: Hi, I have transferred all the statements of one BB( header of one loop) to another BB. After that I have updated SSA information too. But I get this error- definition in block 6 does not dominate use in block 3 for SSA_NAME: i_25 in statement: This is the problem. # VUSE a_18 D.1189_10 = a[i_25]; loop.c:8: internal compiler error: verify_ssa failed Can any one please tell me what is the problem? Thanks, Sandeep.
Re: Official GCC git repository
I put my version of the gcc conversion (which has all branches but no
tags) at git://gcc.gnu.org/git/gcc.git and set a script up to update
it appropriately.
Note that i will not announce this anywhere until someone steps
forward to actually maintain it because i do not know GIT. Neither of
the people who volunteered have done it even after repeated prodding
:(
(I don't mean to shame them, i am simply pointing out that it appears
we need new volunteers)
On Mon, Apr 14, 2008 at 10:49 PM, Kirill A. Shutemov
[EMAIL PROTECTED] wrote:
On Wed, Mar 26, 2008 at 02:38:53PM -0400, Daniel Berlin wrote:
On Wed, Mar 26, 2008 at 12:30 PM, Frank Ch. Eigler [EMAIL PROTECTED]
wrote:
Hi -
On Fri, Mar 14, 2008 at 10:41:42AM -0400, Frank Ch. Eigler wrote:
[...]
OK, /git/gcc.git appears ready for you to populate maintain. Access
as {http,git,ssh}://gcc.gnu.org/gcc.git should all work.
Just a reminder - an empty git repository has been ready for you for
some time.
Guys, if you want, i can populate it with my git-svn clone, which has
a svn root id of ssh://gcc.gnu.org//svn/gcc (IE the proper root if you
wanted to be able to dcommit), and has all branches (but no tags).
Any progress?
--
Regards, Kirill A. Shutemov
+ Belarus, Minsk
+ ALT Linux Team, http://www.altlinux.com/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkgEF60ACgkQbWYnhzC5v6oJ0gCfcCHQqB3TXubihzAvauZHttaJ
f+cAn1zgCkx8MggOjoKDYNW2pqNiGTtc
=l6Vg
-END PGP SIGNATURE-
Re: Moving statements from one BB to other BB.
On Tue, Apr 15, 2008 at 10:34 AM, Daniel Berlin [EMAIL PROTECTED] wrote: To clarify what Richard means, your assertion that you have updated SSA information is false. If you had updated the SSA information, the error would not occur :). How exactly are you updating the ssa information? I am calling update_ssa (TODO_update_ssa), after all the statements are transferred. The general way to update SSA for this case would be: For each statement you have moved: Call update_stmt (t); Then call update_ssa (TODO_update_ssa) (or instead use rewrite_into_loop_closed_ssa if this is a loop pass). If you do not call update_stmt in this case, update_ssa won't actually do anything. Diego, the bsi iterators do not update the statements for you though it is not clear if this is a bug or not. The bsi iterators call update_modified_stmts, which says: /* Mark statement T as modified, and update it. */ static inline void update_modified_stmts (tree t) However, this only calls update_stmt_if_modified (IE it does not mark the statement as modified and update it, as it claims to). Sandeep, it should also suffice to call mark_stmt_modified *before* moving the statements (since the above routine should then update them). Thanks. I will use update_stmt, update_ssa now. Best Regards, Sandeep. On Mon, Apr 14, 2008 at 7:10 AM, Richard Guenther [EMAIL PROTECTED] wrote: On Mon, Apr 14, 2008 at 12:54 PM, Sandeep Maram [EMAIL PROTECTED] wrote: Hi, I have transferred all the statements of one BB( header of one loop) to another BB. After that I have updated SSA information too. But I get this error- definition in block 6 does not dominate use in block 3 for SSA_NAME: i_25 in statement: This is the problem. # VUSE a_18 D.1189_10 = a[i_25]; loop.c:8: internal compiler error: verify_ssa failed Can any one please tell me what is the problem? Thanks, Sandeep.
Re: A query regarding the implementation of pragmas
On Mon, Apr 14, 2008 at 11:44 PM, Jim Wilson [EMAIL PROTECTED] wrote: Mohamed Shafi wrote: For a function call will i be able to implement long call/short call for the same function at different locations? Say fun1 calls bar and fun2 calls bar. I want short-call to be generated for bar in fun1 and long-call to be generated in fun2. Is to possible to implement this in the back-end using pragmas? A simple grep command shows that both arm and rs6000 already both support long call pragmas. I did see those but i coudn't determine whether it is possible to change the attribute of the same function at different points of compilation. Regards, Shafi
[Bug c++/35929] Argument type of non-member operator-*
--- Comment #2 from gcc at magfr dot user dot lysator dot liu dot se 2008-04-14 06:34 --- I think I was wrong. -- gcc at magfr dot user dot lysator dot liu dot se changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35929
[Bug target/35907] [4.3/4.4 Regression] 64-bit power6 glibc miscompilation
--- Comment #12 from amodra at bigpond dot net dot au 2008-04-14 07:19 --- Created an attachment (id=15476) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15476action=view) proposed patch I think we want something like the attached patch (as yet untested). Besides the epilogue bug exposed by alloca, there is another bug with vrsave. If all non-volatile gp and fp regs are saved/restored by a function, then vrsave will be stored at frame-288-4 for 64-bit. After sp is adjusted, this location may be trashed by an interrupt routine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35907
[Bug target/35907] [4.3/4.4 Regression] 64-bit power6 glibc miscompilation
--- Comment #13 from jakub at gcc dot gnu dot org 2008-04-14 07:30 --- Couldn't it use hard_frame_pointer_rtx if frame_pointer_needed, to avoid the load from 0(1) ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35907
[Bug fortran/35930] New: -pedantic: Check for -std=f95/f2003/f2008
I understood -pedantic such that it gives warnings if a construct does not match the Fortran standard. Currently, it seems to be partially used such but also used to warn for non-Fortran-95 (!) constructs. I think one should go through the pedantic sections in the source and check whether they still make sense (e.g. give an error for valid F2003, cf. e.g. PR35882); maybe we should also some more checks? (At least I often forget to think of the -pedantic option.) Additionally, one should change (a) to Fortran 95 into to the Fortran standard and (b) Valid Fortran 95 programs into Programs which are valid according to the Fortran standard -- or something like that. In the manual wie have: -pedantic Issue warnings for uses of extensions to Fortran 95. [...] Valid Fortran 95 programs should compile properly with or without this option. However, without this option, certain GNU extensions and traditional Fortran features are supported as well. With this option, many of them are rejected. This should be used in conjunction with -std=f95, -std=f2003, or -std=f2008. -- Summary: -pedantic: Check for -std=f95/f2003/f2008 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35930
[Bug target/35926] Pushing / Poping ebx without using it.
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-04-14 09:18 --- This is setting up the frame pointer which is needed for unwinding/debugging on some targets. You can use -fomit-frame-pointer to avoid this. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35926
[Bug ada/35050] [4.1/4.2/4.3/4.4 regression] renames entities not in symbol table
--- Comment #4 from sam at gcc dot gnu dot org 2008-04-14 09:39 --- Subject: Bug 35050 Author: sam Date: Mon Apr 14 09:38:34 2008 New Revision: 134256 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134256 Log: gcc/ada/ PR ada/35050 * xref_lib.adb (Parse_Identifier_Info): Correctly parse and ignore the renaming information. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/xref_lib.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35050
[Bug ada/20822] makeinfo cannot process gnat_ugn_unw.texi
--- Comment #7 from sam at gcc dot gnu dot org 2008-04-14 09:48 --- Thanks Rolf, patch applied in SVN. -- sam at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20822
[Bug ada/35050] [4.1/4.2/4.3/4.4 regression] renames entities not in symbol table
--- Comment #5 from sam at gcc dot gnu dot org 2008-04-14 09:42 --- Bug fixed in SVN version. -- sam at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.1.3 |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35050
[Bug ada/20822] makeinfo cannot process gnat_ugn_unw.texi
--- Comment #6 from sam at gcc dot gnu dot org 2008-04-14 09:40 --- Subject: Bug 20822 Author: sam Date: Mon Apr 14 09:39:39 2008 New Revision: 134257 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134257 Log: 2008-04-14 Rolf Ebert [EMAIL PROTECTED] gcc/ada/ PR ada/20822 * xgnatugn.adb (Put_Line): New procedure, ensuring Unix line endings even on non-Unix platforms. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/xgnatugn.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20822
[Bug middle-end/35509] [4.3/4.4 Regression] builtin isinf() mismatch to compile-time substitution
--- Comment #7 from dmixm at marine dot febras dot ru 2008-04-14 10:55 --- Possible the (isgreater(fabs(x), DBL_MAX) ? (signbit(x) ? -1 : 1) : 0) will be fast with common finite numbers? Question: in case of AVR target, is it possible to call extern isinf() function regardless of language dialect? Inline code is very undesirable with small memory. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35509
[Bug target/35907] [4.3/4.4 Regression] 64-bit power6 glibc miscompilation
--- Comment #14 from amodra at bigpond dot net dot au 2008-04-14 10:25 --- Yes, I think you could use hard_frame_pointer_rtx in rs6000_emit_epilogue if frame_pointer_needed, anywhere up to the point where gprs are restored. Probably done best as a separate patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35907
[Bug middle-end/35509] [4.3/4.4 Regression] builtin isinf() mismatch to compile-time substitution
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-04-14 11:06 --- I propose that we do the following: - add a warning to the C/C++ frontends that isinf (x) CMP isinf (y) is only well-defined for !isinf (x) !isinf (y). this doesn't result in a runtime penalty and informs people about the possible problem in their code (it is non-portable). A different workaround would be to canonicalize the return value of isinf to bool. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35509
[Bug target/35926] Pushing / Poping ebx without using it.
--- Comment #3 from ubizjak at gmail dot com 2008-04-14 11:12 --- (In reply to comment #2) This is setting up the frame pointer which is needed for unwinding/debugging on some targets. You can use -fomit-frame-pointer to avoid this. No, -fomit-frame-pointer uses %ebp. %ebx is marked as used due to long long value in %ecx/%ebx. For some reason, %ebx is still marked as live when function prologue and epilogue are constructed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35926
[Bug middle-end/35838] [4.4 Regression] FAIL: 22_locale/num_get/get/char/16.cc execution test, and 76 others
--- Comment #6 from rsandifo at gcc dot gnu dot org 2008-04-14 11:27 --- Created an attachment (id=15477) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15477action=view) Possible fix Sorry for the problems. Can you give this patch a try? I'd wrongly assumed that one of the subregs would always be paradoxical. Richard -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rsandifo at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35838
[Bug ada/15915] Illegal program not detected, RM 13.11(15)
--- Comment #3 from sam at gcc dot gnu dot org 2008-04-14 12:11 --- Subject: Bug 15915 Author: sam Date: Mon Apr 14 12:10:16 2008 New Revision: 134261 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134261 Log: gcc/ada/ PR ada/15915 * sem_util.ads, sem_util.adb (Denotes_Variable): New function. * sem_ch12.adb (Instantiate_Object): Use it. * sem_ch13.adb (Analyze_Attribute_Definition_Clause): Ensure that storage pool denotes a variable as per RM 13.11(15). gcc/testsuite/ PR ada/15915 * gnat.dg/specs/storage.ads: New. Added: trunk/gcc/testsuite/gnat.dg/specs/storage.ads Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/sem_ch12.adb trunk/gcc/ada/sem_ch13.adb trunk/gcc/ada/sem_util.adb trunk/gcc/ada/sem_util.ads trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15915
[Bug ada/16098] Illegal program not detected, RM 13.1(6)
--- Comment #2 from sam at gcc dot gnu dot org 2008-04-14 12:11 --- Subject: Bug 16098 Author: sam Date: Mon Apr 14 12:11:06 2008 New Revision: 134262 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134262 Log: gcc/ada/ PR ada/16098 * sem_prag.adb (Error_Pragma_Ref): New. (Process_Convention): Specialized message for non-local subprogram renaming. Detect the problem in homonyms as well. gcc/testsuite/ PR ada/16098 * gnat.dg/specs/renamings.ads: New. Added: trunk/gcc/testsuite/gnat.dg/specs/renamings.ads Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/sem_prag.adb trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16098
[Bug ada/15915] Illegal program not detected, RM 13.11(15)
--- Comment #4 from sam at gcc dot gnu dot org 2008-04-14 12:12 --- This is fixed in SVN. -- sam at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15915
[Bug ada/16098] Illegal program not detected, RM 13.1(6)
--- Comment #3 from sam at gcc dot gnu dot org 2008-04-14 12:12 --- Fixed in SVN. -- sam at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16098
[Bug java/35923] gcj: error trying to exec 'ecj1': execvp: No such file or directory
--- Comment #2 from david dot griffiths at gmail dot com 2008-04-14 12:25 --- Well there is no ecj1 - that's the problem I think. It didn't build it. Presumably nobody has noticed this before because they are picking up an old version of ecj1? Anyway, here's the -v output: /home/dgriff gcj -v foo.java Using built-in specs. Reading specs from /lib/libgcj.spec rename spec lib to liborig Target: i686-pc-cygwin Configured with: ./configure Thread model: single gcc version 4.3.0 (GCC) COLLECT_GCC_OPTIONS='-fsaw-java-file' '-v' '-fbootclasspath=.;C/:\PROGRA~1\IBM\SQLLIB\java\db2java.zip;C/:\PROGRA~1\IBM\SQLLIB\java\db2jcc.jar;C/:\PROGRA~1\IBM\SQLLIB\java\sqlj.zip;C/:\PROGRA~1\IBM\SQLLIB\java\db2jcc_license_cisuz.jar;C/:\PROGRA~1\IBM\SQLLIB\java\db2jcc_license_cu.jar;C/:\PROGRA~1\IBM\SQLLIB\bin;C/:\PROGRA~1\IBM\SQLLIB\java\common.jar;C/:\Program Files\Java\jre1.6.0_02\lib\ext\QTJava.zip:/usr/local/share/java/libgcj-4.3.0.jar' '-g1' '-mtune=generic' ecj1 foo.java -g1 -fbootclasspath=.;C/:\PROGRA~1\IBM\SQLLIB\java\db2java.zip;C/:\PROGRA~1\IBM\SQLLIB\java\db2jcc.jar;C/:\PROGRA~1\IBM\SQLLIB\java\sqlj.zip;C/:\PROGRA~1\IBM\SQLLIB\java\db2jcc_license_cisuz.jar;C/:\PROGRA~1\IBM\SQLLIB\java\db2jcc_license_cu.jar;C/:\PROGRA~1\IBM\SQLLIB\bin;C/:\PROGRA~1\IBM\SQLLIB\java\common.jar;C/:\Program Files\Java\jre1.6.0_02\lib\ext\QTJava.zip:/usr/local/share/java/libgcj-4.3.0.jar -g1 -fsource=1.5 -ftarget=1.5 -fzip-dependency /cygdrive/c/DOCUME~1/dgriff/LOCALS~1/Temp/ccQkBX0B.zip -fzip-target /cygdrive/c/DOCUME~1/dgriff/LOCALS~1/Temp/ccwv2KR3.jar gcj: error trying to exec 'ecj1': execvp: No such file or directory Also, the result of find: /home/dgriff/gcc-4.3.0 find . -iname ecj\* ./ecj.jar /home/dgriff/gcc-4.3.0 cd /usr /usr find . -iname ecj\* /usr cd -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35923
[Bug inline-asm/35931] New: [ARM] - Kernel (v2.6.24) memset.S bad compile using 3.4.5
My target machine is an HP Jornada 720 (sa1100 based). Found this when trying to boot from flashrom. Using gcc 3.4.5 / glibc 2.3.5 memset.S is compiled without any errors. However the kernel boots and freezes on memset.S (never returns from function). On early_printk this is just seen as freezing right after Node 0 : ... message. Using gcc 3.4.1 / glibc 2.3.2 works nicely. gcc-3.4.5: Reading specs from /opt/crosstool/gcc-3.4.5-glibc-2.3.5/arm-unknown-linux-gnu/lib/gcc/arm-unknown-linux-gnu/3.4.5/specs Configured with: /home/kristoffer/crosstool-0.43/build/arm-unknown-linux-gnu/gcc-3.4.5-glibc-2.3.5/gcc-3.4.5/configure --target=arm-unknown-linux-gnu --host=i686-host_pc-linux-gnu --prefix=/opt/crosstool/gcc-3.4.5-glibc-2.3.5/arm-unknown-linux-gnu --with-headers=/opt/crosstool/gcc-3.4.5-glibc-2.3.5/arm-unknown-linux-gnu/arm-unknown-linux-gnu/include --with-local-prefix=/opt/crosstool/gcc-3.4.5-glibc-2.3.5/arm-unknown-linux-gnu/arm-unknown-linux-gnu --disable-nls --enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit --enable-languages=c,c++ --enable-shared --enable-c99 --enable-long-long Thread model: posix gcc version 3.4.5 gcc-3.4.1: Reading specs from /usr/local/arm/3.4.1/lib/gcc/arm-linux/3.4.1/specs Configured with: /work/crosstool-0.27/build/arm-linux/gcc-3.4.1-glibc-2.3.2/gcc-3.4.1/configure --target=arm-linux --host=i686-host_pc-linux-gnu --prefix=/usr/local/arm/3.4.1 --with-headers=/usr/local/arm/3.4.1/arm-linux/include --with-local-prefix=/usr/local/arm/3.4.1/arm-linux --disable-nls --enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit --enable-languages=c,c++ --enable-shared --enable-c99 --enable-long-long Thread model: posix gcc version 3.4.1 -- Summary: [ARM] - Kernel (v2.6.24) memset.S bad compile using 3.4.5 Product: gcc Version: 3.4.5 Status: UNCONFIRMED Severity: major Priority: P3 Component: inline-asm AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kristoffer dot ericson at gmail dot com GCC host triplet: i486-slackware-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35931
[Bug inline-asm/35931] [ARM] - Kernel (v2.6.24) memset.S bad compile using 3.4.5
--- Comment #1 from kristoffer dot ericson at gmail dot com 2008-04-14 12:42 --- Created an attachment (id=15478) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15478action=view) memset.o compiled with 3.4.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35931
[Bug inline-asm/35931] [ARM] - Kernel (v2.6.24) memset.S bad compile using 3.4.5
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-04-14 12:43 --- gcc 3.4 is no longer maintained. Please try 4.2.4. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35931
[Bug ada/18680] pragma Linker_Section problems
--- Comment #4 from sam at gcc dot gnu dot org 2008-04-14 13:42 --- Subject: Bug 18680 Author: sam Date: Mon Apr 14 13:41:25 2008 New Revision: 134266 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134266 Log: gcc/ada/ PR ada/18680 * sem_prag.adb (Analyze_Pragma, Linker_Section case): Refuse to apply pragma Linker_Section on type. gcc/testsuite/ PR ada/18680 * gnat.dg/specs/linker_section.ads: New. Added: trunk/gcc/testsuite/gnat.dg/specs/linker_section.ads Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/sem_prag.adb trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18680
[Bug web/35375] A couple of typos in links on Status of Experimental C++0x Support page
--- Comment #2 from dgregor at gcc dot gnu dot org 2008-04-14 13:56 --- The links on the C++0x status web pages have been fixed. -- dgregor at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35375
[Bug c++/35929] Argument type of non-member operator-*
--- Comment #3 from bangerth at dealii dot org 2008-04-14 14:17 --- Yes. Note that it requires an argument of *class* type, not *pointer to class* type. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35929
[Bug libgomp/35912] omp parallel for wrong result
--- Comment #2 from bangerth at dealii dot org 2008-04-14 14:28 --- (In reply to comment #1) I don't think this is a bug as you did not mark the operations on s as atomic. Yes, exactly. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35912
[Bug c++/35927] befriending a whole template in another namespace fails
--- Comment #1 from bangerth at dealii dot org 2008-04-14 14:21 --- I too believe that z1.cc is valid. icc accepts it. Not a regression, the code fails back to 2.95. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-04-14 14:21:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35927
[Bug c++/35904] Poor error message
--- Comment #1 from bangerth at dealii dot org 2008-04-14 14:34 --- You are asking for too much. The problem is that in your first example the compiler knows that you want to call the grab() function and therefore can give you an informative error message. But in the second example it can't: there's a template, and the compiler tries to match your call's argument types with the template types, but it can't find a set of template types for which the call would match the signature of the function template. In other words, it doesn't know which function you want to call -- there doesn't appear to be one that would match what you want. To implement what you suggest would require the compiler to speculate what you wanted, for example by speculating that you wanted grabint. We've found over the years that letting the compiler speculate sometimes produces a better diagnostic, but most of the time leads to messages that really don't have anything to do with what the user really wanted -- and then become really confusing. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35904
[Bug fortran/35932] New: internal compiler error: CHAR with array arg and also a KIND arg
The following program generates an ICE. program FA0005 ! fails on Windows XP ! gcc version 4.4.0 20080312 (experimental) [trunk revision 133139] CHARACTER(1) CDA1(10) INTEGER IDA(10) CDA1 = CHAR ( IDA, KIND(A )) !fails CDA1 = CHAR ( IDA ) !works END C:\gfortrangfortran fa0005.f fa0005.f: In function 'fa0005': fa0005.f:1: internal compiler error: in gfc_trans_assignment_1, at fortran/trans -expr.c:4330 -- Summary: internal compiler error: CHAR with array arg and also a KIND arg Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dick dot hendrickson at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35932
can/should autoincrement get optimized away?
I finally got to the bottom of some unexpected behavior from the
amreb-linux target of the 4.1.2 compiler.
I'm hoping that someone can say if is this an optimization bug
(optimizes away too much) or a problem with this code.
extern int ReadChar( char *p);
/* grab a character from input buffer if available, or make a call to
get a chunk */
#define READCHAR(p) \
((p-bufposP = p-inbufendm1P) ? (ReadChar(p)) : \
(*(unsigned char *)(p-bufposP++)))
for(bytesread = 0; bytesread len; bytesread++)
{
int ch = READCHAR(p);
if(ch 0) break;
htP-threshP[bytesread] = ch;
/* discard every other byte. */
if( READCHAR(p) 0) break;
}
With the armeb-linux compiler at -O2, in the second invocation of
READCHAR, the compiler optimizes away the load from bufposP AND the
post-increment. Its clear that there's no point in doing the load since
its only needed to conditionally break out of the loop, and an unsigned
char can't be less-than zero. However, can't make up my mind as to
whether or not it should be allowed to optimize away the
post-increment. For the first invocation of READCHAR, the compiler
generates a conditional load byte with post-increment instruction.
This code has worked on perhaps 7 different architectures over that last
10 years, using gcc and serveral other compilers.
Thanks, JB
[Bug fortran/35932] [4.3/4.4 Regression] ICE: CHAR with array arg and also a KIND arg
--- Comment #1 from burnus at gcc dot gnu dot org 2008-04-14 16:21 --- Confirm. The following assert seemingly fails: gcc_assert (lse.ss == gfc_ss_terminator rse.ss == gfc_ss_terminator); -- burnus at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code Known to fail||4.3.0 4.4.0 Known to work||4.2.2 4.1.3 Summary|internal compiler error:|[4.3/4.4 Regression] ICE: |CHAR with array arg and also|CHAR with array arg and also |a KIND arg |a KIND arg Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35932
[Bug bootstrap/35933] New: local variable used before set in fold-const.c
I just tried to compile the GNU C compiler version 4.4 snapshot 20080411 with the Intel C compiler. The Intel compiler said gcc-4.4-20080411/gcc/fold-const.c(14101): warning #592: variable arg1 is used before its value is set The source code is tree arg1 = arg1; if ((TREE_INT_CST_LOW (arg1) 1) == 0) I agree with the compiler. Suggest code rework. -- Summary: local variable used before set in fold-const.c Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35933
[Bug ada/18680] pragma Linker_Section problems
--- Comment #5 from sam at gcc dot gnu dot org 2008-04-14 16:46 --- This is fixed in the current SVN tree. -- sam at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18680
[Bug libstdc++/35934] New: abi breakage in search (4.0.0 - 4.2.1)
From http://gcc.gnu.org/ml/libstdc++/2008-04/msg00034.html In gcc-4.0.0 search was instantiated in string-inst.cc: // Used in str::find. template const C* search(const C*, const C*, const C*, const C*, bool(*)(const C, const C)); and if a user compiled their code with -frepo, they can wind up with an external reference to this, that is bound to the shared library for libstdc++ for 4.0.0. Now, fast forward to 4.2.1. It cleverly removes the instantiation for this and the users application no longer works. I think this should reproduce on any target that uses config/abi/pre/gnu.ver. The fix seems to be to add std::search* back to libstdc++-v3/config/abi/pre/gnu.ver and template const C* search(const C*, const C*, const C*, const C*, bool(*)(const C, const C)); back to libstdc++-v3/src/string-inst.cc, to undo the abi break caused by: r101112 | bkoz | 2005-06-16 16:30:55 -0700 (Thu, 16 Jun 2005) | 61 lines 2005-06-17 Jakub Jelinek [EMAIL PROTECTED] * config/abi/ia64-linux-gnu/baseline_symbols.txt: Update. * config/abi/s390x-linux-gnu/baseline_symbols.txt: Update. * config/abi/s390-linux-gnu/baseline_symbols.txt: Update. * config/abi/x86_64-linux-gnu/baseline_symbols.txt: Update. * config/abi/x86_64-linux-gnu/32/baseline_symbols.txt: Update. * config/abi/powerpc-linux-gnu/baseline_symbols.txt: Update. * config/abi/i486-linux-gnu/baseline_symbols.txt: Update. * config/abi/i386-linux-gnu/baseline_symbols.txt: Update. * config/abi/powerpc64-linux-gnu/baseline_symbols.txt: New file. * config/abi/powerpc64-linux-gnu/32/baseline_symbols.txt: New file. 2005-06-16 Jakub Jelinek [EMAIL PROTECTED] * src/compatibility.cc: Include bits/c++config.h first. (_GLIBCXX_SYMVER_COMPATIBILITY): Define if _GLIBCXX_SYMVER and PIC are both defined. * include/bits/char_traits.h (char_traits::eq): Rename only if _GLIBCXX_SYMVER_COMPATIBILITY is defined. 2005-06-16 Jakub Jelinek [EMAIL PROTECTED] * acinclude.m4 ((GLIBCXX_ENABLE_SYMVERS): Rename _GLIBCXX_SIZE_T_IS_INT to _GLIBCXX_SIZE_T_IS_UINT. Define _GLIBCXX_PTRDIFF_T_IS_INT. * configure: Regenerate. * config.h.in: Regenerate. * src/compatibility.cc (istream:ignore(streamsize)): Use _GLIBCXX_PTRDIFF_T_IS_INT instead of _GLIBCXX_SIZE_T_IS_INT. * config/abi/compatibility.h: Rename _GLIBCXX_SIZE_T_IS_INT to _GLIBCXX_SIZE_T_IS_UINT. Use _GLIBCXX_PTRDIFF_T_IS_INT instead for symbols with streamsize arguments. 2005-06-16 Jakub Jelinek [EMAIL PROTECTED] * config/linker-map.gnu: Also export _ZNSt13basic_istreamIwSt11char_traitsIwEE6ignoreE[il][il]. 2005-06-15 Benjamin Kosnik [EMAIL PROTECTED] * configure.ac (libtool_VERSION): To 6:5:0. * configure: Regenerate. * config/linker-map.gnu: Edit. * src/istream.cc: Move istream::ignore(streamsize) specializations... * src/compatibility.cc: ...here. New. * include/bits/char_traits.h (char_traits::eq): Rename when appropriate. * acinclude.m4 (GLIBCXX_ENABLE_SYMVERS): Define _GLIBCXX_SIZE_T_IS_INT. Bump glibcxx_min_gnu_ld_version to 21590. * configure: Regenerate. * acconfig.h: Remove _GLIBCXX_ASM_SYMVER. * config.h.in: Regenerate. * src/Makefile.am (sources): Add compatibility.cc. * src/Makefile.in: Regenerate. * include/Makefile.am (host_headers_noinst): Add compatibility.h. * include/Makefile.in: Regenerate. * testsuite/testsuite_abi.h (symbol): Add data members. * testsuite/testsuite_abi.cc (check_version): Add GLIBCXX_3.4.5. Remove deprecated versions. Do a better job version checking. -- Summary: abi breakage in search (4.0.0 - 4.2.1) Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mrs at apple dot com GCC host triplet: i686-apple-darwin9 GCC target triplet: i686-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35934
[Bug libstdc++/35935] New: abi breakage in search (4.0.0 - 4.2.1)
From http://gcc.gnu.org/ml/libstdc++/2008-04/msg00034.html In gcc-4.0.0 search was instantiated in string-inst.cc: // Used in str::find. template const C* search(const C*, const C*, const C*, const C*, bool(*)(const C, const C)); and if a user compiled their code with -frepo, they can wind up with an external reference to this, that is bound to the shared library for libstdc++ for 4.0.0. Now, fast forward to 4.2.1. It cleverly removes the instantiation for this and the users application no longer works. I think this should reproduce on any target that uses config/abi/pre/gnu.ver. The fix seems to be to add std::search* back to libstdc++-v3/config/abi/pre/gnu.ver and template const C* search(const C*, const C*, const C*, const C*, bool(*)(const C, const C)); back to libstdc++-v3/src/string-inst.cc, to undo the abi break caused by: r101112 | bkoz | 2005-06-16 16:30:55 -0700 (Thu, 16 Jun 2005) | 61 lines 2005-06-17 Jakub Jelinek [EMAIL PROTECTED] * config/abi/ia64-linux-gnu/baseline_symbols.txt: Update. * config/abi/s390x-linux-gnu/baseline_symbols.txt: Update. * config/abi/s390-linux-gnu/baseline_symbols.txt: Update. * config/abi/x86_64-linux-gnu/baseline_symbols.txt: Update. * config/abi/x86_64-linux-gnu/32/baseline_symbols.txt: Update. * config/abi/powerpc-linux-gnu/baseline_symbols.txt: Update. * config/abi/i486-linux-gnu/baseline_symbols.txt: Update. * config/abi/i386-linux-gnu/baseline_symbols.txt: Update. * config/abi/powerpc64-linux-gnu/baseline_symbols.txt: New file. * config/abi/powerpc64-linux-gnu/32/baseline_symbols.txt: New file. 2005-06-16 Jakub Jelinek [EMAIL PROTECTED] * src/compatibility.cc: Include bits/c++config.h first. (_GLIBCXX_SYMVER_COMPATIBILITY): Define if _GLIBCXX_SYMVER and PIC are both defined. * include/bits/char_traits.h (char_traits::eq): Rename only if _GLIBCXX_SYMVER_COMPATIBILITY is defined. 2005-06-16 Jakub Jelinek [EMAIL PROTECTED] * acinclude.m4 ((GLIBCXX_ENABLE_SYMVERS): Rename _GLIBCXX_SIZE_T_IS_INT to _GLIBCXX_SIZE_T_IS_UINT. Define _GLIBCXX_PTRDIFF_T_IS_INT. * configure: Regenerate. * config.h.in: Regenerate. * src/compatibility.cc (istream:ignore(streamsize)): Use _GLIBCXX_PTRDIFF_T_IS_INT instead of _GLIBCXX_SIZE_T_IS_INT. * config/abi/compatibility.h: Rename _GLIBCXX_SIZE_T_IS_INT to _GLIBCXX_SIZE_T_IS_UINT. Use _GLIBCXX_PTRDIFF_T_IS_INT instead for symbols with streamsize arguments. 2005-06-16 Jakub Jelinek [EMAIL PROTECTED] * config/linker-map.gnu: Also export _ZNSt13basic_istreamIwSt11char_traitsIwEE6ignoreE[il][il]. 2005-06-15 Benjamin Kosnik [EMAIL PROTECTED] * configure.ac (libtool_VERSION): To 6:5:0. * configure: Regenerate. * config/linker-map.gnu: Edit. * src/istream.cc: Move istream::ignore(streamsize) specializations... * src/compatibility.cc: ...here. New. * include/bits/char_traits.h (char_traits::eq): Rename when appropriate. * acinclude.m4 (GLIBCXX_ENABLE_SYMVERS): Define _GLIBCXX_SIZE_T_IS_INT. Bump glibcxx_min_gnu_ld_version to 21590. * configure: Regenerate. * acconfig.h: Remove _GLIBCXX_ASM_SYMVER. * config.h.in: Regenerate. * src/Makefile.am (sources): Add compatibility.cc. * src/Makefile.in: Regenerate. * include/Makefile.am (host_headers_noinst): Add compatibility.h. * include/Makefile.in: Regenerate. * testsuite/testsuite_abi.h (symbol): Add data members. * testsuite/testsuite_abi.cc (check_version): Add GLIBCXX_3.4.5. Remove deprecated versions. Do a better job version checking. -- Summary: abi breakage in search (4.0.0 - 4.2.1) Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mrs at apple dot com GCC host triplet: i686-apple-darwin9 GCC target triplet: i686-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35935
[Bug libstdc++/35935] abi breakage in search (4.0.0 - 4.2.1)
--- Comment #1 from pcarlini at suse dot de 2008-04-14 18:02 --- *** This bug has been marked as a duplicate of 35934 *** -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35935
[Bug libstdc++/35934] abi breakage in search (4.0.0 - 4.2.1)
--- Comment #1 from pcarlini at suse dot de 2008-04-14 18:02 --- *** Bug 35935 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35934
[Bug fortran/35877] difference between result in optimized and normal executable
--- Comment #2 from jb at gcc dot gnu dot org 2008-04-14 18:09 --- Well, your test case is invalid anyway (i0 is referenced before being defined). Here's a standard conforming portable version that compiles with -Wall -pedantic -std=f2003: program short_test_inf implicit none integer, parameter :: dp = selected_real_kind (15) complex(dp) nan_inf, normal_number, cmplx_test, i0 real(dp) tth, pi, zero data tth /6.7e-01_dp/ data pi /3.1415926535897932385_dp/ data zero /0.0_dp/ normal_number = cmplx(tth, zero, dp) nan_inf = cmplx(pi/zero, zero/zero, dp) i0 = cmplx(0, 0, dp) cmplx_test = nan_inf * normal_number Cprint *,'nan_inf ',nan_inf print *,'cmplx_test (inf+iNan)*(2/3+i0) ',cmplx_test cmplx_test = nan_inf * tth Cprint *,'tth ',tth print *,'cmplx_test (inf+iNan)*(2/3)',cmplx_test end program Results with this program comparing 4.1 and 4.4 (trunk): $ ./gf41-opt cmplx_test (inf+iNan)*(2/3+i0) (NaN, NaN) cmplx_test (inf+iNan)*(2/3) ( +Infinity,NaN) $ ./gf41-nonopt cmplx_test (inf+iNan)*(2/3+i0) (NaN, NaN) cmplx_test (inf+iNan)*(2/3) (NaN,NaN) $ ./gf44-opt cmplx_test (inf+iNan)*(2/3+i0) (+Infinity, NaN) cmplx_test (inf+iNan)*(2/3) (+Infinity, NaN) $ ./gf44-nonopt cmplx_test (inf+iNan)*(2/3+i0) ( NaN, NaN) cmplx_test (inf+iNan)*(2/3) ( NaN, NaN) Basically, I'd like to close this as wontfix. IIRC once you get an FP exception, all bets are off and the result of further computation can be anything. Of course it would be nice if results were the same regardless of optimization level. For a related issue where being excessively anal about complex arithmetic resulted in a factor of 5 slowdown, see PR 29549 -- jb at gcc dot gnu dot org changed: What|Removed |Added CC||jb at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-04-14 18:09:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35877
Re: Building newlib-1.15.0 with gcc-4.3.0 for arm-elf
Mariusz Janiak wrote:
../../../../../../../../newlib-1.15.0/newlib/libc/machine/arm/setjmp.S:
Assembler messages:
../../../../../../../../newlib-1.15.0/newlib/libc/machine/arm/setjmp.S:123:
Error: SP not allowed in register list -- `stmea a1!,{v1-v7,fp,ip,sp,lr}'
../../../../../../../../newlib-1.15.0/newlib/libc/machine/arm/setjmp.S:145:
Error: SP not allowed in register list -- `ldmfd a1!,{v1-v7,fp,ip,sp,lr}'
This is an assembler error for a .S file, which means it has nothing to
do with gcc. It is either a newlib bug or a binutils bug. Probably a
newlib bug. Looks like newlib doesn't support thumb2.
By the way, we don't track bugs mailed to the gcc-bugs mailing list.
GCC bugs should be filed into bugzilla, or ask a question on the
gcc-help mailing list.
Jim
Re: can/should autoincrement get optimized away?
John Breitenbach wrote: char can't be less-than zero. However, can't make up my mind as to whether or not it should be allowed to optimize away the post-increment. It is not OK to optimize away the post-increment. This is a gcc optimization bug. Jim
[Bug libfortran/32972] performance of pack/unpack
--- Comment #24 from tkoenig at gcc dot gnu dot org 2008-04-14 18:51 --- Subject: Bug 32972 Author: tkoenig Date: Mon Apr 14 18:50:57 2008 New Revision: 134286 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134286 Log: 2008-04-14 Thomas Koenig [EMAIL PROTECTED] PR libfortran/32972 * intrinsics/spread_generic.c (spread): Use spread_i2() for GFC_DTYPE_DERIVED_2 (fix typo from previous commit). Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/spread_generic.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32972
[Bug libfortran/35863] [F2003] Implement ENCODING=UTF-8
--- Comment #1 from jb at gcc dot gnu dot org 2008-04-14 18:55 --- Confirmed. This could be a bit tricky to get right. OTOH Fortran is fortunate enough that there are real strings and not char arrays like in C, so from a user perspective it should be pretty transparent. But certainly the implementation can be tricky. Perhaps we should ask advice from e.g. python developers who already have implemented unicode support in some language with a runtime library written in C? http://www.cl.cam.ac.uk/~mgk25/unicode.html Specifically http://www.cl.cam.ac.uk/~mgk25/unicode.html#mod http://www.cl.cam.ac.uk/~mgk25/unicode.html#c -- jb at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-04-14 18:55:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35863
[Bug target/35936] New: Cannot compile libgcc.S on avr
/home/sam/tmp/gcc-avr/./gcc/xgcc -B/home/sam/tmp/gcc-avr/./gcc/ -B/home/sam/local/i386-linux/avr/bin/ -B/home/sam/local/i386-linux/avr/lib/ -isystem /home/sam/local/i386-linux/avr/include -isystem /home/sam/local/i386-linux/avr/sys-include -g -O2 -mmcu=avr31 -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -DDF=SF -Dinhibit_libc -mcall-prologues -Os -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../.././gcc -I/home/sam/Dev/gcc/libgcc -I/home/sam/Dev/gcc/libgcc/. -I/home/sam/Dev/gcc/libgcc/../gcc -I/home/sam/Dev/gcc/libgcc/../include -DHAVE_CC_TLS -o _copy_data.o -MT _copy_data.o -MD -MP -MF _copy_data.dep -DL_copy_data -xassembler-with-cpp \ -c /home/sam/Dev/gcc/libgcc/../gcc/config/avr/libgcc.S /home/sam/Dev/gcc/libgcc/../gcc/config/avr/libgcc.S: Assembler messages: /home/sam/Dev/gcc/libgcc/../gcc/config/avr/libgcc.S:736: Error: illegal opcode elpm for mcu avr3 I'm using the latest binutils from CVS. gcc knows that elmp is valid for avr31 and calls as with -mmcu=avr3, making as reject it. Looks awfully like PR #35073 with another opcode. -- Summary: Cannot compile libgcc.S on avr Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sam at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu GCC target triplet: avr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35936
[Bug fortran/35937] New: char_result_5.f90 / char_result_6.f90 fail with -fdefault-integer-8
$ gfortran -g -fdefault-integer-8 char_result_5.f90 $ gdb ./a.out GNU gdb 6.7.1-debian Copyright (C) 2007 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i486-linux-gnu... Using host libthread_db library /lib/i686/cmov/libthread_db.so.1. (gdb) r Starting program: /tmp/a.out Program received signal SIGSEGV, Segmentation fault. 0xb7f82664 in *_gfortran_string_scan (slen=9, str=0x804b480 123456789, setlen=1, set=0x0, back=-1080910905) at ../../../../gcc/trunk/libgfortran/intrinsics/string_intrinsics.c:300 300 if (str[i] == set[j]) -- Summary: char_result_5.f90 / char_result_6.f90 fail with - fdefault-integer-8 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org BugsThisDependsOn: 32770 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35937
[Bug bootstrap/35938] New: Fixincludes failure with 'make check'
With a clean svn checkout (gcc version 4.4.0 20080414 (experimental) (GCC)),
--enable-languages=c,c++
I can successfully make bootstrap and make install, and the resulting
compiler seems to work.
However, trying to 'make check' results in the output below:
~/gccbin$ make check
autogen -T ../../gcc/fixincludes/check.tpl ../../gcc/fixincludes/inclhack.def
/bin/sh ./check.sh ../../gcc/fixincludes/tests/base
Fixed: testing.h
Fixed: testing.h
Fixed: AvailabilityMacros.h
Fixed: X11/ShellP.h
Fixed: X11/Xmu.h
Fixed: Xm/BaseClassI.h
Fixed: Xm/Traversal.h
Fixed: _G_config.h
Fixed: ansi/math.h
Fixed: ansi/stdlib.h
Fixed: arch/i960/archI960.h
Fixed: architecture/ppc/math.h
Fixed: arpa/inet.h
Fixed: assert.h
Fixed: bits/huge_val.h
Fixed: bits/string2.h
Fixed: bsd/libc.h
Fixed: c_asm.h
Fixed: com_err.h
Fixed: ctrl-quotes-def-1.h
Fixed: ctype.h
Fixed: curses.h
Fixed: errno.h
Fixed: features.h
Fixed: fixinc-test-limits.h
Fixed: fs/rfs/rf_cache.h
Fixed: hsfs/hsfs_spec.h
Fixed: ia64/sys/getppdp.h
Fixed: internal/math_core.h
Fixed: internal/sgimacros.h
Fixed: internal/wchar_core.h
Fixed: inttypes.h
Fixed: io-quotes-def-1.h
Fixed: iso/math_c99.h
Fixed: locale.h
Fixed: mach-o/dyld.h
Fixed: mach-o/swap.h
Fixed: machine/cpu.h
Fixed: malloc.h
Fixed: math.h
Fixed: netdnet/dnetdb.h
Fixed: netinet/in.h
Fixed: netinet/ip.h
Fixed: obstack.h
Fixed: pixrect/memvar.h
sed: 1: /define[ \t]\+PTHREAD_MU ...: expected context address
Fixed: reg_types.h
Fixed: regex.h
Fixed: regexp.h
Fixed: rpc/auth.h
Fixed: rpc/rpc.h
Fixed: rpc/svc.h
Fixed: rpc/xdr.h
Fixed: rpcsvc/rstat.h
Fixed: rpcsvc/rusers.h
Fixed: signal.h
Fixed: sparc/asm_linkage.h
Fixed: standards.h
Fixed: stdint.h
Fixed: stdio.h
Fixed: stdio_tag.h
Fixed: stdlib.h
Fixed: string.h
Fixed: strings.h
Fixed: sundev/vuid_event.h
Fixed: sunwindow/win_lock.h
Fixed: sym.h
Fixed: sys/asm.h
Fixed: sys/cdefs.h
Fixed: sys/file.h
Fixed: sys/ioctl.h
Fixed: sys/limits.h
Fixed: sys/machine.h
Fixed: sys/mman.h
Fixed: sys/pthread.h
Fixed: sys/regset.h
Fixed: sys/signal.h
Fixed: sys/socket.h
Fixed: sys/spinlock.h
Fixed: sys/stat.h
Fixed: sys/sysmacros.h
Fixed: sys/time.h
Fixed: sys/times.h
Fixed: sys/types.h
Fixed: sys/ucontext.h
Fixed: sys/utsname.h
Fixed: sys/wait.h
Fixed: testing.h
Fixed: time.h
Fixed: tinfo.h
Fixed: types/vxTypesBase.h
Fixed: unistd.h
Fixed: wchar.h
Fixed: widec.h
Xm/Traversal.h /Users/caj/gcc/fixincludes/tests/base/Xm/Traversal.h differ:
char 296, line 15
*** Xm/Traversal.h 2008-04-14 20:09:00.0 +0100
--- /Users/caj/gcc/fixincludes/tests/base/Xm/Traversal.h2008-02-26
18:15:39.0 +
***
*** 12,18
#if defined( X11_NEW_CHECK )
struct wedge {
#ifdef __cplusplus
! Widgetold, c_new;
#else
Widget old, new; /* fixinc check FAILS ON BSD */
#endif
--- 12,18
#if defined( X11_NEW_CHECK )
struct wedge {
#ifdef __cplusplus
! Widget old, c_new;
#else
Widget old, new; /* fixinc check FAILS ON BSD */
#endif
strings.h /Users/caj/gcc/fixincludes/tests/base/strings.h differ: char 687,
line 31
*** strings.h 2008-04-14 20:09:01.0 +0100
--- /Users/caj/gcc/fixincludes/tests/base/strings.h 2008-02-26
18:15:40.0 +
***
*** 28,39
strncmp( const char *__s1, const char *__s2, size_t __n );
extern int
! strcasecmp( const char *__s1, const char *__s2),
! strncasecmp( const char *__s1, const char *__s2, size_t __n );
strncmp();
extern int
! strcasecmp(),
! strncasecmp();
#endif /* ULTRIX_STRINGS2_CHECK */
--- 28,39
strncmp( const char *__s1, const char *__s2, size_t __n );
extern int
! strcasecmp( const char *__s1, const char *__s2),
! strncasecmp( const char *__s1, const char *__s2, size_t __n );
strncmp();
extern int
! strcasecmp(),
! strncasecmp();
#endif /* ULTRIX_STRINGS2_CHECK */
sys/stat.h /Users/caj/gcc/fixincludes/tests/base/sys/stat.h differ: char 432,
line 18
*** sys/stat.h 2008-04-14 20:09:01.0 +0100
--- /Users/caj/gcc/fixincludes/tests/base/sys/stat.h2008-02-26
18:15:40.0 +
***
*** 15,21
#if defined( GLIBC_C99_INLINE_2_CHECK )
! extern int fstat64 (int __fd, struct stat64 *__buf) __THROW __nonnull ((2));
#ifdef __GNUC_GNU_INLINE__
extern
#endif
--- 15,24
#if defined( GLIBC_C99_INLINE_2_CHECK )
! #ifdef __GNUC_GNU_INLINE__
! extern
! #endif
! __inline__ int fstat64 (int __fd, struct stat64 *__buf) __THROW __nonnull
((2));
#ifdef __GNUC_GNU_INLINE__
extern
#endif
***
*** 39,45
return __stat32(__f, __p);
}
#if __cplusplus
! }
#endif /* __cplusplus */
# else /* !__STDC__ THIS FAILS ON BSD SYSTEMS */
--- 42,48
return __stat32(__f, __p);
}
#if __cplusplus
! }
#endif /* __cplusplus */
# else /* !__STDC__ THIS FAILS ON BSD SYSTEMS */
***
*** 53,59
[Bug fortran/35932] [4.3/4.4 Regression] ICE: CHAR with array arg and also a KIND arg
-- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-04-14 19:20:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35932
[Bug bootstrap/35938] Fixincludes failure with 'make check'
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-04-14 19:36 --- The last failures are white space differences and can be ignored, the BSD sed causes them. Anyways you should be using make -k check -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35938
[Bug libstdc++/35915] [4.4 Regression] atomic.cc:31:20: error: stdint.h: No such file
--- Comment #2 from bkoz at gcc dot gnu dot org 2008-04-14 19:37 --- Ah. Well, I see that this is the second time I broke stuff on stdint.h. I must fix this correctly, apparently. Mine... -- bkoz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-04-14 19:37:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35915
[Bug libstdc++/35915] [4.4 Regression] atomic.cc:31:20: error: stdint.h: No such file
--- Comment #3 from andreast at gcc dot gnu dot org 2008-04-14 19:42 --- happens on sparc-solaris2.8 as well. sparc-solaris2.10 is not affected. -- andreast at gcc dot gnu dot org changed: What|Removed |Added CC||andreast at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35915
[Bug fortran/35937] char_result_5.f90 / char_result_6.f90 fail with -fdefault-integer-8
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-04-14 19:45 --- The right way around... See the attached file in comment #7 of PR32770. Yes, I'm trying to make indiviual PRs of all failures that I see. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn|32770 | OtherBugsDependingO||32770 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35937
