Re: gcc breakage
Since I got advised both for and against adding a ChangeLog entry, I'm inclined to leave things as they are for now unless somebody beats me to it. -- Thanks, Laurynas
Re: Someone broke darwin?
Mike Stump <[EMAIL PROTECTED]> writes: > /Volumes/mrs3/net/gcc-darwin/powerpc-apple-darwin8.5.0/libstdc++-v3/ > include/ext/pb_ds/detail/binary_heap_/binary_heap_.hpp:235: internal > compiler error: Bus error > Please submit a full bug report, > with preprocessed source if appropriate. > See http://gcc.gnu.org/bugs.html> for instructions. > make[4]: *** [powerpc-apple-darwin8.5.0/bits/extc++.h.gch/O2g.gch] Error 1 This is PR28217. 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."
Re: Switch statement optimization
Joern RENNECKE schrieb: In http://gcc.gnu.org/ml/gcc/2006-07/msg00156.html, your wrote: We could use a cheap hash and base start compare / branch trees in every hash bin. Say we have a 16 k range, 200 nodes, and want to keep the hash bin/node ratio between 2 and 4. Let i be the switch argument. Then we can calculate a 9 bit hash as (i ^ (x << n)) & 0x3fff, where n is a value between 5 and 9. We can pick the one which produces the flattest average search trees. Note that we no longer need to check that i is in range, as for ordinary switch dispatch tables. What I suggest is to implement a cost-estimation based decision. This should include an architecture dependent modelling that could deliver an exact cost (in terms of size) for size-optimization and as well a good approximation for speed. For example in my case of 1500 labels inside the 16K range I would perfer a branch table instead of a binary compare tree. The size of the table is 16K * 4/8 bytes and this is really ok for a huge program. The frequently used entries are likely to be in the cache, so I expect the whole thing to perform well. However if I would optimize it for my case that may not help in general? So all modifications should be verified with a common standard benchmark like SPEC. Is there someone on the list who wants to support me with these tests or may deliver models for common architectures? Christian
Re: Questions regarding __register_frame_info
jacob navia writes: > Hi > > I have now everything in place for dynamically register the > debug frame information that my JIT (Just in time compiler) > generates. > > I generate a CIE (Common information block), followed by > a series of FDE (Frame Description Entries) describing > each stack frame. The binary code is the same as gcc uses, > the contents of my stuff are identical to the contents of > the .eh_frame information. > > There are several of those functions defined in unwind-dw2-fde.c: > > __register_frame_info > __register_frame_info_bases > __register_frame_info_table_bases > > If I use the > __register_frame_info > stuff, nothing happens and the program aborts. > Using __register_frame_jnfo_table_bases seems to > work better since it crashes a little bit further with a > hard crash. What happens in gdb? Does the lookup access your unwinder data? What is it doing when it crashes? > From the code of register_frame_info (in file unwind-dw2-fde.c) > that function just inserts the new data into a linked list, but it > does not do anything more. That is why probably it will never > work. > > Could someone here explain me or tell me what to do exactly to register > the frame information? > > This will be useful for all people that write JITs, for instance the > Java people, > and many others. > > Thanks in advance for your help, and thanks for the help this group > has provided me already Sure, we're all interested, but we don't have your code. Have you traced through the throwing of an exception? Andrew.
New bootstrap failure on i386-unknown-freebsd5.4
Is it possible the new bootstrap failure (log below) I started seeing within the last 24 hours is related to the following patch? 2006-07-10 Benjamin Kosnik <[EMAIL PROTECTED]> PR libstdc++/15448 * include/Makefile.am: Clean up pch rules. * include/Makefile.in: Regenerate. Gerald if [ ! -d "./i386-unknown-freebsd5.4/bits/extc++.h.gch" ]; then \ mkdir -p ./i386-unknown-freebsd5.4/bits/extc++.h.gch; \ fi; \ /files/pfeifer/OBJ-0711-1004/./gcc/xgcc -shared-libgcc -B/files/pfeifer/OBJ-0711-1004/./gcc -nostdinc++ -L/files/pfeifer/OBJ-0711-1004/i386-unknown-freebsd5.4/libstdc++-v3/src -L/files/pfeifer/OBJ-0711-1004/i386-unknown-freebsd5.4/libstdc++-v3/src/.libs -B/sw/gcc-current/i386-unknown-freebsd5.4/bin/ -B/sw/gcc-current/i386-unknown-freebsd5.4/lib/ -isystem /sw/gcc-current/i386-unknown-freebsd5.4/include -isystem /sw/gcc-current/i386-unknown-freebsd5.4/sys-include -Winvalid-pch -Wno-deprecated -x c++-header -g -O2 -I/files/pfeifer/OBJ-0711-1004/i386-unknown-freebsd5.4/libstdc++-v3/include/i386-unknown-freebsd5.4 -I/files/pfeifer/OBJ-0711-1004/i386-unknown-freebsd5.4/libstdc++-v3/include -I/sw/test/gcc/trunk/libstdc++-v3/libsupc++ -O2 -g /sw/test/gcc/trunk/libstdc++-v3/include/precompiled/extc++.h -o i386-unknown-freebsd5.4/bits/extc++.h.gch/O2g.gch /files/pfeifer/OBJ-0711-1004/i386-unknown-freebsd5.4/libstdc++-v3/include/ext/codecvt_specializations.h:57: error: 'iconv_t' does not name a type /files/pfeifer/OBJ-0711-1004/i386-unknown-freebsd5.4/libstdc++-v3/include/ext/codecvt_specializations.h:67: error: 'descriptor_type' does not name a type /files/pfeifer/OBJ-0711-1004/i386-unknown-freebsd5.4/libstdc++-v3/include/ext/codecvt_specializations.h:70: error: 'descriptor_type' does not name a type /files/pfeifer/OBJ-0711-1004/i386-unknown-freebsd5.4/libstdc++-v3/include/ext/codecvt_specializations.h:147: error: ISO C++ forbids declaration of 'descriptor_type' with no type /files/pfeifer/OBJ-0711-1004/i386-unknown-freebsd5.4/libstdc++-v3/include/ext/codecvt_specializations.h:147: error: expected ';' before '&' token /files/pfeifer/OBJ-0711-1004/i386-unknown-freebsd5.4/libstdc++-v3/include/ext/codecvt_specializations.h:151: error: expected `;' before 'const' /files/pfeifer/OBJ-0711-1004/i386-unknown-freebsd5.4/libstdc++-v3/include/ext/codecvt_specializations.h:151: error: ISO C++ forbids declaration of 'descriptor_type' with no type /files/pfeifer/OBJ-0711-1004/i386-unknown-freebsd5.4/libstdc++-v3/include/ext/codecvt_specializations.h:151: error: expected ';' before '&' token /files/pfeifer/OBJ-0711-1004/i386-unknown-freebsd5.4/libstdc++-v3/include/ext/codecvt_specializations.h:155: error: expected `;' before 'protected' /files/pfeifer/OBJ-0711-1004/i386-unknown-freebsd5.4/libstdc++-v3/include/ext/codecvt_specializations.h: In constructor '__gnu_cxx::encoding_state::encoding_state()': /files/pfeifer/OBJ-0711-1004/i386-unknown-freebsd5.4/libstdc++-v3/include/ext/codecvt_specializations.h:86: error: class '__gnu_cxx::encoding_state' does not have any field named '_M_in_desc' /files/pfeifer/OBJ-0711-1004/i386-unknown-freebsd5.4/libstdc++-v3/include/ext/codecvt_specializations.h:86: error: class '__gnu_cxx::encoding_state' does not have any field named '_M_out_desc' /files/pfeifer/OBJ-0711-1004/i386-unknown-freebsd5.4/libstdc++-v3/include/ext/codecvt_specializations.h: In constructor '__gnu_cxx::encoding_state::encoding_state(const char*, const char*, int, int, int)': /files/pfeifer/OBJ-0711-1004/i386-unknown-freebsd5.4/libstdc++-v3/include/ext/codecvt_specializations.h:92: error: class '__gnu_cxx::encoding_state' does not have any field named '_M_in_desc' /files/pfeifer/OBJ-0711-1004/i386-unknown-freebsd5.4/libstdc++-v3/include/ext/codecvt_specializations.h:92: error: class '__gnu_cxx::encoding_state' does not have any field named '_M_out_desc' /files/pfeifer/OBJ-0711-1004/i386-unknown-freebsd5.4/libstdc++-v3/include/ext/codecvt_specializations.h: In copy constructor '__gnu_cxx::encoding_state::encoding_state(const __gnu_cxx::encoding_state&)': /files/pfeifer/OBJ-0711-1004/i386-unknown-freebsd5.4/libstdc++-v3/include/ext/codecvt_specializations.h:104: error: class '__gnu_cxx::encoding_state' does not have any field named '_M_in_desc' /files/pfeifer/OBJ-0711-1004/i386-unknown-freebsd5.4/libstdc++-v3/include/ext/codecvt_specializations.h:104: error: class '__gnu_cxx::encoding_state' does not have any field named '_M_out_desc' /files/pfeifer/OBJ-0711-1004/i386-unknown-freebsd5.4/libstdc++-v3/include/ext/codecvt_specializations.h: In member function 'bool __gnu_cxx::encoding_state::good() const': /files/pfeifer/OBJ-0711-1004/i386-unknown-freebsd5.4/libstdc++-v3/include/ext/codecvt_specializations.h:121: error: 'descriptor_type' does not name a type /files/pfeifer/OBJ-0711-1004/i386-unknown-freebsd5.4/libstdc++-v3/include/ext/codecvt_specializations.h:122: error: '_M_in_desc' was not declared in this scope /files/pfeifer/OBJ-0711-1004/i386-unknow
Re: New bootstrap failure on i386-unknown-freebsd5.4
On Jul 11, 2006, at 8:51 PM, Gerald Pfeifer wrote: Is it possible the new bootstrap failure (log below) I started seeing within the last 24 hours is related to the following patch? This is not that new, in fact the only reason why Ben's patch exposes it is because it was make was not stopping after the ICE or error. See PR 28290 (the errors) and PR 28217 (the ICE). Both were reported before the actual bootstrap issue. -- Pinski
Re: Someone broke darwin?
> Andreas Schwab writes: Andreas> Mike Stump <[EMAIL PROTECTED]> writes: >> /Volumes/mrs3/net/gcc-darwin/powerpc-apple-darwin8.5.0/libstdc++-v3/ >> include/ext/pb_ds/detail/binary_heap_/binary_heap_.hpp:235: internal >> compiler error: Bus error >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See http://gcc.gnu.org/bugs.html> for instructions. >> make[4]: *** [powerpc-apple-darwin8.5.0/bits/extc++.h.gch/O2g.gch] Error 1 Andreas> This is PR28217. This now causes a bootstrap failure on AIX as well: /tmp/20060710/powerpc-ibm-aix5.2.0.0/libstdc++-v3/include/ext/pb_ds/detail/binary_heap_/binary_heap_.hpp: At global scope: /tmp/20060710/powerpc-ibm-aix5.2.0.0/libstdc++-v3/include/ext/pb_ds/detail/binary_heap_/binary_heap_.hpp:235: internal compiler error: tree check: expected integer_cst, have scope_ref in tree_int_cst_sgn, at tree.c:4517 I successfully bootstrapped yesterday and have been very few patches recently. David
Re: Someone broke darwin?
> I successfully bootstrapped yesterday and have been very few > patches recently. I ran into a similar problem on SPARC/Solaris on Sunday morning (revision 115296). The same tree bootstrapped fine on AMD64/Linux. -- Eric Botcazou
Re: Different invariants about the contents of static links
Ian Lance Taylor wrote: "Rodney M. Bates" <[EMAIL PROTECTED]> writes: The following example C code and disassembly is compiled by gcc 3.4.3, for i686. It uses two different invariants for what the value of a static link is. Everywhere inside P, static link values are consistently the same as base pointer (%ebp) register values for the same activation record. A static link value is generated at 4c: in P, and used at 22: in PInner2 and c: in PInner1. Everywhere inside similar function Q, static link values consistently point 8 bytes higher than where the base register points. A value is generated at d9: in Q and used at 7a: in Qinner2 and 64: in QInner1. From the examples I have looked at, it looks like it is correct translation, and, expect for seeming strangeness, is not a problem for execution. However, I am working on an extended gdb-derived debugger that works, in part, with code produced by a gcc-derived code generator for Modula-3. So far, I can't find out, in the debugger, which invariant is in use. I have the debugger correctly both generating and using static links when evaluating user-typed expressions, using the first invariant. I could easily change it to use the second invariant, but obviously, that would fix some cases and break others. Is there a compelling reason for this difference? If not, I would like to make it all use invariant one. Also, does anybody know where in gcc this difference is happening? I poked around in the source for a couple of hours, but didn't see anything obvious. The static link pointer points to a part of the stack frame which includes the information required for the nested functions. The amount of information required changes depending on the code. Therefore, the static link pointer will not be a constant offset from the frame pointer. I don't believe that it is possible to change this while still handling calls between doubly nested functions, but maybe I just haven't thought about it hard enough. I don't understand this. A pointer to anywhere in an activation record (or even outside it, if outside by a fixed offset) allows access to exactly the same set of things as any other, including the value the base register holds when the activation record is current. That set is everything in the AR, using different but still fixed displacements, and nothing more, since everything else is not necessarily at a fixed displacement from the AR. Signed displacements are already required anyway when using the normal base pointer, so it must not be to keep them all the same sign. Anyway, the observed shift in where SLs point is the wrong way to get all displacements to the same sign. As for multiple levels of nested functions, that always requires one static link for every level in the nesting, each to a different AR. Either consistent or varying SL target locations generalizes to multiple levels with equal ease. I am curious about the local pointer to nonlocally-accessed variables/parameters. In my examples, this always is located in the same AR as the field it points to, thus is unnecessary, since its target field could be accessed directly, using the right displacement. Does it ever point across different ARs? I wonder if this mechanism interacts with the invariant about where the SL points, but I can't imagine how it would. BTW, this is using stabs. I know that is not very complete, but it would be a lot more work than I want to do to change it. Stabs doesn't represent the static link pointer at all, so that is your problem. You should switch to DWARF. If that is impossible as you suggest, then I think your most profitable approach would be to enhance stabs somehow. Ian -- Rodney M. Bates
[boehms-gc] Some work on ggc-boehm
Hi,
This patch does three things:
1) Fix broken --with-gc=page. Now it is possible to build GCC with
these two collectors from exactly same sources.
2) Boehms's GC makes GCC print collector warnings time from time about
very large blocks being allocated. These warnings are meaningless, so
they are suppressed normally, but allowed with -v. It fixes some of
the spurious testsuite "regressions", I don't know how many yet, as
testsuite takes more than 24 hours here on Cygwin, 1.8GHz Turion. I
can run it much faster inside in VMWare on Linux on the same machine.
Is there any way to speed it up on Cygwin?
3) Adjusted decision when to collect to match more closely other
collectors. More specifically, only used bytes in the heap instead of
overall heap size are considered.
Commited to the boehms-gc branch, thanks in advance for any comments,
--
Laurynas
Index: gcc/ggc-boehm.c
===
--- gcc/ggc-boehm.c (revision 114910)
+++ gcc/ggc-boehm.c (working copy)
@@ -4,16 +4,22 @@
#include "params.h"
#include "timevar.h"
#include "ggc.h"
+#include "symtab.h"
-#define GC_DEBUG
+/* #define GC_DEBUG */
#include
+extern struct ht *ident_hash;
+
static size_t get_used_heap_size(void);
static void register_gty_roots(void);
+static void gc_warning_filter(char * msg, GC_word arg);
static size_t last_allocated = 0;
static ggc_stringpool_roots stringpool_roots;
+static GC_warn_proc default_warn_proc;
+
void
init_ggc (void)
{
@@ -23,6 +29,8 @@
stringpool_roots.start = NULL;
stringpool_roots.one_after_finish = NULL;
+
+ default_warn_proc = GC_set_warn_proc(gc_warning_filter);
}
void *
@@ -50,7 +58,7 @@
float min_expand = allocated_last_gc * PARAM_VALUE (GGC_MIN_EXPAND) / 100;
- if (GC_get_heap_size() < allocated_last_gc + min_expand
+ if (get_used_heap_size() < allocated_last_gc + min_expand
&& !ggc_force_collect)
return;
@@ -73,7 +81,7 @@
if (!quiet_flag)
fprintf (stderr, "%luk}", (unsigned long) get_used_heap_size() / 1024);
- last_allocated = GC_get_heap_size();
+ last_allocated = get_used_heap_size();
timevar_pop (TV_GC);
}
@@ -171,7 +179,11 @@
fprintf (stderr,
"Total heap size: %lu\n", (unsigned long)GC_get_heap_size());
fprintf (stderr,
- "Free bytes in the heap: %lu\n", (unsigned long)GC_get_free_bytes());
+ "Free bytes in the heap: %lu\n",
+ (unsigned long)GC_get_free_bytes());
+ fprintf (stderr,
+ "Used bytes in the heap: %lu\n",
+ (unsigned long)get_used_heap_size());
}
int
@@ -205,3 +217,38 @@
/* TODO: it might be required to process gt_ggc_cache_rtab here */
}
+
+/* Register the stringpool entries as GGC roots. In contrast to all other
+ roots, that are static, stringpool may increase and move around in memory.
+ So it's handled specially. */
+ggc_stringpool_roots
+ggc_register_stringpool_roots (void)
+{
+ ggc_stringpool_roots result;
+ result.start = ident_hash->entries;
+ result.one_after_finish = ident_hash->entries + ident_hash->nslots;
+
+ GC_add_roots (result.start, result.one_after_finish);
+
+ return result;
+}
+
+void
+ggc_unregister_stringpool_roots (ggc_stringpool_roots roots)
+{
+ GC_remove_roots (roots.start, roots.one_after_finish);
+}
+
+int
+ggc_stringpool_moved_p (ggc_stringpool_roots roots)
+{
+ return (roots.start != ident_hash->entries)
+|| (roots.one_after_finish != ident_hash->entries + ident_hash->nslots);
+}
+
+void
+gc_warning_filter(char * msg, GC_word arg)
+{
+ if (!quiet_flag)
+(*default_warn_proc)(msg, arg);
+}
Index: gcc/stringpool.c
===
--- gcc/stringpool.c(revision 114910)
+++ gcc/stringpool.c(working copy)
@@ -37,8 +37,6 @@
#include "symtab.h"
#include "cpplib.h"
-#include
-
/* The stringpool contains 2^ORDER entries. */
#define ORDER 14
@@ -74,8 +72,6 @@
ident_hash->alloc_node = alloc_node;
ident_hash->alloc_subobject = stringpool_ggc_alloc;
gcc_obstack_init (&string_stack);
-
- ggc_register_stringpool_roots();
}
/* Allocate a hash node. */
@@ -182,34 +178,6 @@
ht_forall (ident_hash, mark_ident, NULL);
}
-/* Register the stringpool entries as GGC roots. In contrast to all other
- roots, that are static, stringpool may increase and move around in memory.
- So it's handled specially. */
-ggc_stringpool_roots
-ggc_register_stringpool_roots (void)
-{
- ggc_stringpool_roots result;
- result.start = ident_hash->entries;
- result.one_after_finish = ident_hash->entries + ident_hash->nslots;
-
- GC_add_roots (result.start, result.one_after_finish);
-
- return result;
-}
-
-void
-ggc_unregister_stringpool_roots (ggc_stringpool_roots roots)
-{
- GC_remove_roots (roots.start, roots.one_after_finish);
-}
-
-int
-ggc_stringpool_moved_p (ggc_stringpool_roots roots)
-{
- return (roots.start != ident_hash->entries)
-|| (roots.one_after_finish != ident_hash->entries + ident_hash->nslots);
-}
-
/* Strings a
Re: How to deal with 1.#IND?
Up! -- View this message in context: http://www.nabble.com/How-to-deal-with-1.-IND--tf1862819.html#a5271851 Sent from the gcc - Dev forum at Nabble.com.
RE: How to deal with 1.#IND?
On 11 July 2006 16:36, truelies wrote: > Up! Off! . What part of "Please note this is NOT, I repeat NOT, a GCC users list - this is a GCC developers list. For user general questions, post to GCC - Help." don't you get? cheers, DaveK -- Can't think of a witty .sigline today
Re: Different invariants about the contents of static links
"Rodney M. Bates" <[EMAIL PROTECTED]> writes:
> I don't understand this. A pointer to anywhere in an activation record
> (or even outside it, if outside by a fixed offset) allows access to
> exactly the same set of things as any other, including the value the base
> register holds when the activation record is current. That set is everything
> in the AR, using different but still fixed displacements, and nothing more,
> since everything else is not necessarily at a fixed displacement from the
> AR.
OK, let me reset.
It seemed to me that you were suggesting that the static link pointer
should always be a constant offset from the frame pointer.
gcc doesn't work that way, though. Here is a simple counter-example.
int
foo (int x, int y)
{
int
s1 ()
{
if (--y == 0)
return 0;
return x + s1 ();
}
return s1 ();
}
If you compile this code, you will see that the static link pointer is
passed down unchanged through the recursive calls. The frame pointer
is, of course, different for each call. You can't compute the static
link pointer from the frame pointer. It's completely independent.
If this is not a counter-example for what you want, then I think we
need a clearer explanation of what you want.
Ian
Re: New bootstrap failure on i386-unknown-freebsd5.4
> See PR 28290 (the errors) and PR 28217 (the ICE). Both were reported > before the actual > bootstrap issue. Paolo's patch for 28290 is now in. I don't know what to do about the ICE: it looks like Mike has a patch. Temporary workaround is to configure with --disable-libstdcxx-pch. -benjamin
Re: GCC dejagnu testsuite: how to check for non-zero exit code?
On Thu, Jul 06, 2006 at 10:48:50PM +0200, FX Coudert wrote:
> I'd like to include cases in the gfortran testsuite to check that we
> correctly issue a run-time error, and exit with non-zero code.
>
> I have the following example:
>
> $ cat runtime_error.f90
> ! { dg-do run }
> ! { dg-options "-fbounds-check" }
> integer :: x(5), y(5)
> x = y((/0,2,3,4,6/))
> end
> $ gfortran runtime_error.f90 -fbounds-check
> $ ./a.out ; echo $?
> Fortran runtime error: Array reference out of bounds for array 'y',
> lower bound of dimension 1 exceeded (in file 'runtime_error.f90', at line 4)
> 2
>
>
> I'd like to be able to check that this code indeed issue the error
> message on stderr and indicate to dejagnu that non-zero exit codes does
> not mean that the test FAILed). How can I do that?
I've got a patch that adds a new test directive, dg-shouldfail, to
expect the executable to exit with a nonzero exit status. I was
waiting for input from the Fortran developers who requested that
facility, and will check it in later this week. There are other
test directives that let you look for runtime messages in the test
output.
Janis
[lto] libelf header
Hi, My first attempt to compile the lto branch met with resistance: /home/gdr/redhat/lto.gcc/gcc/lto/lto-elf.c:27:20: error: libelf.h: No such file or directory libelf (0.8.5-35) is installed on my system in the standard include directory (/usr/include) as libelf/libelf.h. lto/lto-elf.c:27 currently says #include "libelf.h" Should that read #include ? -- Gaby -- Gabriel Dos Reis [EMAIL PROTECTED]
Re: [lto] libelf header
On Tue, Jul 11, 2006 at 11:13:11PM +0200, Gabriel Dos Reis wrote: > lto/lto-elf.c:27 currently says > >#include "libelf.h" > > > Should that read > >#include No, because on other systems it is directly in /usr/include: rpm -qf /usr/include/libelf.h elfutils-libelf-devel-0.119-1.2.1 and there is no /usr/include/libelf/ directory. Guess GCC configure should make sure the needed -I path_to_libelf_h is added if it is not already in the system search path. Jakub
Re: [lto] libelf header
Gabriel Dos Reis wrote: > Hi, > > My first attempt to compile the lto branch met with resistance: > > /home/gdr/redhat/lto.gcc/gcc/lto/lto-elf.c:27:20: error: libelf.h: No such > file or directory > > > libelf (0.8.5-35) This libelf is too old, see michael matz's message. You are going to have to grab 0.8.8 from the libelf homepage to compile this ATM. >is installed on my system in the standard include > directory (/usr/include) as libelf/libelf.h. > > lto/lto-elf.c:27 currently says > >#include "libelf.h" > > > Should that read > >#include > So, the thing is that other libelfs are directly installing their header in /usr/include/libelf.h (this include elfutils-libelf, solaris libelf, etc). Thus, this probably need to be autoconf'd. --Dan
Re: [lto] libelf header
Jakub Jelinek <[EMAIL PROTECTED]> writes: | > Should that read | > | >#include | | No, because on other systems it is directly in /usr/include: | rpm -qf /usr/include/libelf.h | elfutils-libelf-devel-0.119-1.2.1 | and there is no /usr/include/libelf/ directory. | Guess GCC configure should make sure the needed -I path_to_libelf_h | is added if it is not already in the system search path. | | Jakub Daniel Berlin <[EMAIL PROTECTED]> writes: | Gabriel Dos Reis wrote: | > Hi, | > | > My first attempt to compile the lto branch met with resistance: | > | > /home/gdr/redhat/lto.gcc/gcc/lto/lto-elf.c:27:20: error: libelf.h: No such file or directory | > | > | > libelf (0.8.5-35) | | This libelf is too old, see michael matz's message. | You are going to have to grab 0.8.8 from the libelf homepage to compile | this ATM. | | | >is installed on my system in the standard include | > directory (/usr/include) as libelf/libelf.h. | > | > lto/lto-elf.c:27 currently says | > | >#include "libelf.h" | > | > | > Should that read | > | >#include | > | | So, the thing is that other libelfs are directly installing their header | in /usr/include/libelf.h | | (this include elfutils-libelf, solaris libelf, etc). | | Thus, this probably need to be autoconf'd. Thanks to both of you. I'll see whether Autoconf would like to talk with me. -- Gaby
Re: gcc visibility used by moz
Benjamin Smedberg wrote:
Jason, I'm sorry to email you directly, as I don't know which email list
I should be discussing on. I've built gcc trunk after your visibility
patch landed, and there are some serious issues with compiling Mozilla now:
Take the following code:
class __attribute__ ((visibility ("hidden"))) HiddenBaseClass
{
public:
virtual SomeMethod();
};
__attribute__ ((visibility ("default"))) HiddenBaseClass*
CreateAClass();
This declaration warns "CreateAClass() declared with greater visibility
than its type. And when CreateAClass is instantiated, it is hidden
visibility.
This seriously breaks XPCOM, which uses this model throughout our code
(default-visibility accessors for interface types, which are declared
with hidden visibility). Why should this model be prevented?
>
A similar issue is present for hidden-visibility classes with
default-visibility member functions:
class __attribute__ ((visibility ("hidden"))) HiddenClass
{
__attribute__ ((visibility ("default"))) void SomeMethod();
};
I see that you explicitly wrote your patch to disallow this kind of
declaration, but I can't figure out why: it works, and we were using it.
This is a less serious issue in that we only use this pattern in a few
places and we can replace the exported method with a non-class method
fairly easily, but I can't take that change on the mozilla 1.8 or 1.8.0
branch. So, unless these patterns can be made to work, it seems that
FF1.5 and 2 are going to both be thoroughly broken when compiled against
gcc trunk->4.2
It seems that you have a different mental model of type visibility. The
way I was thinking about it, if a type has hidden visibility, we can't
refer to it from outside its object. Thus, it doesn't make sense for
members or objects with that type to have greater visibility because
even if people can call the accessor they can't do anything with the
return value.
However, I'm not attached to this in defiance of practical concerns.
What is your model of type visibility?
Jason
Re: [boehms-gc] Some work on ggc-boehm
On Jul 11, 2006, at 7:18 AM, Laurynas Biveinis wrote: I don't know how many yet, as testsuite takes more than 24 hours here on Cygwin, 1.8GHz Turion. I can run it much faster inside in VMWare on Linux on the same machine. Is there any way to speed it up on Cygwin? Sure, install Linux. :-) Sorry, couldn't resist.
Re: [lto] libelf header
Daniel Berlin <[EMAIL PROTECTED]> writes: [...] | > libelf (0.8.5-35) | | This libelf is too old, see michael matz's message. Which one is it? -- Gaby
Re: gcc visibility used by moz
Jason Merrill wrote: It seems that you have a different mental model of type visibility. The way I was thinking about it, if a type has hidden visibility, we can't refer to it from outside its object. Thus, it doesn't make sense for members or objects with that type to have greater visibility because even if people can call the accessor they can't do anything with the return value. > However, I'm not attached to this in defiance of practical concerns. What is your model of type visibility? This isn't "type" visibility. Shared objects don't export "types" they export "symbols". The types are defined in headers and are thus known to exist - no visibility attributes will or should change that. If the programmer had intended that the type should appear to not exist. it wouldn't be defined in a header #include-able by client code. The compiler should assume that the type exists and can be used if it is defined and shouldn't change attributes on other parts of the program. In the examples above, client code that knows (via headers) that the classes exist should be able to get pointers to instances via exported functions, access any visible or virtual members, and pass the pointers back into visible functions of the shared object - or even dereference the pointers to pass by reference. -- Tristan Wibberley These opinions are my own, and do not reflect those of my employer.
Need help
Hi :
I am getting the following compilation error:
/tmp/ccIUvX3i.o(.gnu.linkonce.d._ZTV4ListIiE+0x8): undefined reference to
`List::Find(int const&)'
the declaration is:
virtual int Find (const Etype &X);
and the definition is:
template
int
List::Find (const Etype &X){
Node *P;
for (P=List_Head; P!=NULL; P = P->Next)
if (P->Element == X)
{
Current_Positioon = P;
return 1;
}
return 0;
}
Any suggestions!!!
Thanks
Abid
This mail sent through www.mywaterloo.ca
Re: [boehms-gc] Some work on ggc-boehm
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Stump wrote: > On Jul 11, 2006, at 7:18 AM, Laurynas Biveinis wrote: >> I don't know how many yet, as testsuite takes more than 24 hours >> here on Cygwin, 1.8GHz Turion. I can run it much faster inside in >> VMWare on Linux on the same machine. >> Is there any way to speed it up on Cygwin? > > Sure, install Linux. :-) Sorry, couldn't resist. You might be joking but for GCC hacking I've personally found Linux to be *far faster* and more reliable than Cygwin or MSYS on the same machine. Even when building a native toolchain for Windows (MinGW), I prefer building a crossed-native compiler via Linux rather than a native compiler on Windows. Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA. Web: http://rmathew.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEtFZqYb1hx2wRS48RAsP6AJ9xfNq95CuIENmCVDfIO5GOgo1ltACgqsVd UAkchCKhUOj+xyYhBKDFC70= =mNRE -END PGP SIGNATURE-
Re: Splay Tree
On Sun, 9 Jul 2006, Roger Sayle wrote:
Interesting. Richard Guenther's post for the above change, which was
based upon a previous proposal by Brian Makin, suggested that this
patch reduced the compile-time of his tramp3d benchmark by 1%.
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00294.html
I realized that 3 orders of magnitude of diference wasn't a very realistic
benchmark. So I reviewed it. I found that I forgot some profiling code
that was biasing the result of the revision 106584, and that the pice
of splay tree usage used to perform the benchmark wasn't so representative
of the whole bootstrap. So the previous benchmark wasn't accurate at all.
That said, I rebuild a benchmark this time with full traces of splay tree
usage during tramp3d (380mb) compilation and gcc bootstraping(1gb).
And I did the benchmarking again. This time with the original code, with
the revision 106584 code and with the proposed by Brian Makin (with a
few changes). Thus I have been able to reproduce the speed improvement
with the Richard Guenther's patch.
I also noticed that the code sent by Brian Makin is slightly better than
Revision 106584 and that not pushes down the root node more than 2 levels,
which can prevent that some rare cases perform bad.
bootstrap
Original
real 61.630s
user 61.010s
sys 0.620s
Revision 106584
real 59.660s
user 59.000s
sys 0.660s
New
real 58.910s
user 58.240s
sys 0.670s
tramp3d
Original
real 26.680s
user 26.350s
sys 0.340s
Revision 106584
real 26.010s
user 25.660s
sys 0.340s
New
real 25.700s
user 25.340s
sys 0.360s
ian--- splay-tree.c2006-07-11 15:36:50.0 +0200
+++ splay-tree.nrn.c2006-07-11 15:46:54.0 +0200
@@ -38,10 +38,6 @@ Boston, MA 02110-1301, USA. */
#include "splay-tree.h"
static void splay_tree_delete_helper (splay_tree, splay_tree_node);
-static inline void rotate_left (splay_tree_node *,
- splay_tree_node, splay_tree_node);
-static inline void rotate_right (splay_tree_node *,
- splay_tree_node, splay_tree_node);
static void splay_tree_splay (splay_tree, splay_tree_key);
static int splay_tree_foreach_helper (splay_tree, splay_tree_node,
splay_tree_foreach_fn, void*);
@@ -106,95 +102,103 @@ splay_tree_delete_helper (splay_tree sp,
#undef VDEL
}
-/* Rotate the edge joining the left child N with its parent P. PP is the
- grandparents pointer to P. */
+/* Splay SP around KEY.
+ This works alot like spliting a BST except if you traverse
+ left left or right right you first rotate the root before splitting
+ then move down a node. */
-static inline void
-rotate_left (splay_tree_node *pp, splay_tree_node p, splay_tree_node n)
+static void
+splay_tree_splay (splay_tree sp, splay_tree_key key)
{
- splay_tree_node tmp;
- tmp = n->right;
- n->right = p;
- p->left = tmp;
- *pp = n;
-}
+ if (sp->root == 0)
+return;
-/* Rotate the edge joining the right child N with its parent P. PP is the
- grandparents pointer to P. */
+ /* temp_tree.left is all the nodes less than key while
+ temp_tree.right is all the nodes greater than key */
+ struct splay_tree_node_s temp_tree;
+
+ /* these are the points we will add new nodes to the respective trees */
+ splay_tree_node left_ptr;
+ splay_tree_node right_ptr;
-static inline void
-rotate_right (splay_tree_node *pp, splay_tree_node p, splay_tree_node n)
-{
- splay_tree_node tmp;
- tmp = n->left;
- n->left = p;
- p->right = tmp;
- *pp = n;
-}
+ /* current node we are splitting the tree at */
+ splay_tree_node current_node;
-/* Bottom up splay of key. */
+ splay_tree_node tmp_node;
+ int comparison;
-static void
-splay_tree_splay (splay_tree sp, splay_tree_key key)
-{
- if (sp->root == 0)
+ temp_tree.left = temp_tree.right = 0;
+ left_ptr = right_ptr = &temp_tree;
+
+ current_node = sp->root;
+ comparison = (*sp->comp) (key, current_node->key);
+
+ /* no splaying need */
+ if (comparison == 0)
return;
- do {
-int cmp1, cmp2;
-splay_tree_node n, c;
-
-n = sp->root;
-cmp1 = (*sp->comp) (key, n->key);
-
-/* Found. */
-if (cmp1 == 0)
- return;
-
-/* Left or right? If no child, then we're done. */
-if (cmp1 < 0)
- c = n->left;
-else
- c = n->right;
-if (!c)
- return;
-
-/* Next one left or right? If found or no child, we're done
- after one rotation. */
-cmp2 = (*sp->comp) (key, c->key);
-if (cmp2 == 0
-|| (cmp2 < 0 && !c->left)
-|| (cmp2 > 0 && !c->right))
- {
- if (cmp1 < 0)
- rotate_left (&sp->root, n, c);
- else
- rotate_right (&sp->root, n, c);
-return;
- }
-
-/* Now we have the four cases of double-rotation. */
-if (cmp1 < 0 && cmp2 < 0)
- {
- rotate_left (&n->left, c, c->left);
- rotate_left (&sp->root, n, n->left);
- }
-else if (cmp1 > 0 && cm
Re: gcc visibility used by moz
On Wed, Jul 12, 2006 at 02:04:37AM +0100, Tristan Wibberley wrote:
> If the programmer had intended that the type should appear to not exist.
> it wouldn't be defined in a header #include-able by client code. The
GCC doesn't know if the header is includable by client code; I assume
that's the use Jason intended for marking classes hidden ("it belongs
to this shared object and no one else can see it").
> In the examples above, client code that knows (via headers) that the
> classes exist should be able to get pointers to instances via exported
> functions, access any visible or virtual members, and pass the pointers
> back into visible functions of the shared object - or even dereference
> the pointers to pass by reference.
So... what does it restrict, then? Is it just defaulting methods to
hidden, as a strange form of access control?
--
Daniel Jacobowitz
CodeSourcery
Re: Need help
[EMAIL PROTECTED] writes: > I am getting the following compilation error: > > /tmp/ccIUvX3i.o(.gnu.linkonce.d._ZTV4ListIiE+0x8): undefined reference to > `List::Find(int const&)' Wrong mailing list. This sort of question should go to [EMAIL PROTECTED] Thanks. I don't know the answer to your question without a complete test case. However, you should be able to figure it out yourself by reading the friendly manual: http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Template-Instantiation.html Ian
Re: gcc 4.2 more strict check for "function called through a non-compatible type"
Andrew Haley wrote: > Yuri Pudgorodsky writes: > > > > > We can say something like: > > > > > > "In GNU C, you may cast a function pointer of one type to a function > > > pointer of another type. If you use a function pointer to call a > > > function, and the dynamic type of the function pointed to by the > > > function pointer is not the same as indicated by the static type of the > > > function pointer, then the results of the call are unspecified. In > > > general, if the types are not too different > > s/not too different/compatible/ > > "not too different" has no meaning, whereas "compatible" is defined in > Section 6.2.7. But, at least in C++, the official meaning of compatible is not the meaning we want. For example, "int *" and "long *" are not compatible -- but, in this context, we want to say that this will work. > We need to do this because we use type-based alias analysis in gcc. Yes, I remember adding that feature. :-) :-) > If we permit incompatible > types to be casted in function calls, we make a hole in alias > analysis. Yes, users who lie will lose. The only thing we're trying to do here is behave a bit more gracefully. Introducing a call to __builtin_trap is pretty brutal; instead, we want to say "we can't promise this is going to work, but if you want to try, go ahead..." -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Ben Elliston appointed DFP maintainer
The SC has appointed Ben Elliston as maintainer of the Decimal Floating-Point components of the compiler, including relevant portions of the front ends, libraries, etc. Ben, please update MAINTAINERS to reflect your expanded role. Thanks! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
