http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51297
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51297
--- Comment #11 from Nathan Sidwell nathan at gcc dot gnu.org 2011-11-26
21:44:26 UTC ---
Author: nathan
Date: Sat Nov 26 21:44:24 2011
New Revision: 181745
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181745
Log:
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51297
Nathan Sidwell nathan at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51297
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot
Uni-Bielefeld.DE 2011-11-25 10:20:28 UTC ---
The patch solves the problem for me.
Same on i386-pc-solaris2.8 (all gcc.misc-tests/gcov and g++.dg/gcov
tests) and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51297
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
Target|alpha-dec-osf5.1b,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51297
--- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-11-24
18:40:43 UTC ---
What are the values being passed to the bsearch call?
Very likely the problem indeed. qsort is known to be very picky on Solaris 8
and 9, in the sense
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51297
--- Comment #4 from Nathan Sidwell nathan at gcc dot gnu.org 2011-11-24
19:08:24 UTC ---
the names being entered into the array are unique, so there is a total ordering
-- I think that's a red herring. I think the problem is the string read from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51297
--- Comment #5 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-11-24
19:46:20 UTC ---
the names being entered into the array are unique, so there is a total
ordering
-- I think that's a red herring. I think the problem is the string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51297
--- Comment #6 from Nathan Sidwell nathan at acm dot org 2011-11-24 21:36:20
UTC ---
On 11/24/11 19:46, ebotcazou at gcc dot gnu.org wrote:
In fact the array is empty:
(gdb) p n_names
$1 = 0
(gdb) p names
$2 = (name_map_t *) 0x0
d'oh! A
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51297
--- Comment #7 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-11-24
21:54:15 UTC ---
d'oh! A fix will be right up.
Thanks. I confirm that adding if (n_names 0) in the right places works fine.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51297
--- Comment #8 from Nathan Sidwell nathan at acm dot org 2011-11-24 22:12:11
UTC ---
On 11/24/11 21:54, ebotcazou at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51297
--- Comment #7 from Eric Botcazouebotcazou at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51297
--- Comment #9 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-11-24
23:31:06 UTC ---
Hm, can you try the attached patch? It avoids passing a null pointer, which
is
not permitted. Passing zero as nmemb is permitted (7.20.5 para 1 of
12 matches
Mail list logo
