gcc vs gnu-classpath
Hi. Recently (at least in 4.1.1), the classpath pieces bundled with gcc include /usr/lib/classpath/libgjsmalsa.so (JNI midi-alsa). This creates a conflict when installing gnu-classpath itself. Is it correct for gcc to install libgjsmalsa.so in /usr/lib/classpath? Would it make sense for gcc to install it instead into /usr/share/gcc-data/i686-pc-linux-gnu/4.1.1 along with the other classpath libraries included by gcc? -- Kevin F. Quinn signature.asc Description: PGP signature
problem in gcc port based on MIPS
hi, I am trying to write the backend for a processor based on mips.I am facing some problems during compilation of gcc.GAS has been ported for target processor.The store word instruction on ported assembler only supports 16 bit offsets.i.e the only supported format is stw $1,16-bit-offset($2) I modified mips backend to support stw instruction.But during the compilation of crtstuff.c it is generating an instrucion stw $2,p.2249 as this format of instruction is not supported on assembler,an error for illegal operands(p.2249) is being generated. First of all i'm not been able to understand the operand p.2249 as i'm newbie to mips assembly.According to tc-mips.c code in GAS ,it seems to be a 32 address,but still the syntax is not clear to me. Where in mips backend in gcc (mips.md,mips.h,mips.c) such type of offset(p.2249) is being generated because i need to tell the compiler that only allowed offset for stw instruction is 16-bit and generated format should be stw reg,offset(reg) thanks, kernelcoder
Re: Splay Tree
Hi Ian, On Sun, 9 Jul 2006, Ian Blanes wrote: > I've been recently looking at the splay tree implementation. I've noticed > that this revision http://gcc.gnu.org/viewcvs?view=rev&revision=106584 > does a strange splaying. It does a bottom up splaying but starting at the > root (not the same that top down). It works but performs worst. 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 appreciate that you've also benchmarked "typical" splay tree usage during a GCC boostrap. Any chance, that you could repeat your experiment but instead evaluate the behaviour of splay tree usage during a tramp3d compilation: http://www.suse.de/~rguenther/tramp3d/ Whilst your analysis demonstrates that splay_tree_splay is behaving curiously, I'm also interested in resolving the reported performance benefits of the different implementations. Thanks in advance, Roger --
Re: externs and thread local storage
* Richard Henderson: > You're kidding, right? *All* targets have to generate different > code for thread-local storage. If it didn't, it wouldn't be > thread-local, would it? The local/non-local distinction could be encoded as a flag in the load instruction, set by the linker according to the definition it sees. i386 is not very far away from that. Nowadays, the distinction is just an instruction prefix. However, you need very specialized hardware support for taking a globally valid address of a thread-local object. (For example, LEA on i386 is not good enough). This means that thread-local storage with the semantics GCC provides is not just a mapping issue.
[PATCH] (request for comments) Wcoercion in g++
The following patch replaces some of the functionality of Wconversion
in g++ by using the code developed for Wcoercion project. In
particular, it checks for coercions from real to integer.
The proposed implementation has two advantages over the existing one:
* The code is shared by both C and C++ front ends in the function
"coercion_warning" which is called through the existing function
"convert_and_check".
* The proposed implementation warns for int i = 1.1 but not for int i
= 1.0 while the previous code warns for both cases.
The patch must be applied after the ones given in
http://gcc.gnu.org/ml/gcc-patches/2006-07/msg00098.html
Bootstrapped and tested in trunk revision 115112
Comments and suggestions are very welcome.
diff -pEbaur --unidirectional-new-file --exclude='*svn*' --exclude='*~' pristine/gcc/cp/call.c wcoercion/gcc/cp/call.c
--- pristine/gcc/cp/call.c 2006-07-07 22:58:38.0 +0100
+++ wcoercion/gcc/cp/call.c 2006-07-09 19:21:13.0 +0100
@@ -4255,12 +4255,11 @@ convert_like_real (conversion *convs, tr
if (TREE_CODE (TREE_TYPE (expr)) == REAL_TYPE
&& TREE_CODE (t) == INTEGER_TYPE)
{
- if (fn)
- warning (OPT_Wconversion, "passing %qT for argument %P to %qD",
- TREE_TYPE (expr), argnum, fn);
- else
- warning (OPT_Wconversion, "converting to %qT from %qT", t, TREE_TYPE (expr));
+ convert_and_check (t, expr);
+ /* There is another call to convert_and_check below, we just
+ warn once. */
+ issue_conversion_warnings = false;
}
}
diff -pEbaur --unidirectional-new-file --exclude='*svn*' --exclude='*~' pristine/gcc/testsuite/g++.dg/warn/conv2.C wcoercion/gcc/testsuite/g++.dg/warn/conv2.C
--- pristine/gcc/testsuite/g++.dg/warn/conv2.C 2006-07-07 23:00:25.0 +0100
+++ wcoercion/gcc/testsuite/g++.dg/warn/conv2.C 2006-07-09 19:21:13.0 +0100
@@ -1,4 +1,5 @@
// PR c++/13932
-// { dg-options "-Wconversion" }
+// { dg-options "-Wcoercion" }
-int i = 1.; // { dg-warning "converting" }
+int i = 1.;
+int j = 1.1; // { dg-warning "coercion" }
diff -pEbaur --unidirectional-new-file --exclude='*svn*' --exclude='*~' pristine/gcc/testsuite/g++.old-deja/g++.warn/impint2.C wcoercion/gcc/testsuite/g++.old-deja/g++.warn/impint2.C
--- pristine/gcc/testsuite/g++.old-deja/g++.warn/impint2.C 2006-07-07 23:22:57.0 +0100
+++ wcoercion/gcc/testsuite/g++.old-deja/g++.warn/impint2.C 2006-07-09 19:21:13.0 +0100
@@ -1,8 +1,9 @@
// { dg-do assemble }
-// { dg-options "-Wconversion" }
+// { dg-options "-Wcoercion" }
// Copyright (C) 2000 Free Software Foundation, Inc.
// Contributed by Nathan Sidwell 6 Mar 2000 <[EMAIL PROTECTED]>
+// Modified by Manuel Lopez-Ibanez 7 Jul 2006 <[EMAIL PROTECTED]>
// initialization to 'int' from to 'double' We expect consistent warnings
// whenever a float is implicitly truncated to int, make sure references
diff -pEbaur --unidirectional-new-file --exclude='*svn*' --exclude='*~' pristine/gcc/testsuite/g++.old-deja/g++.warn/impint.C wcoercion/gcc/testsuite/g++.old-deja/g++.warn/impint.C
--- pristine/gcc/testsuite/g++.old-deja/g++.warn/impint.C 2006-07-07 23:25:01.0 +0100
+++ wcoercion/gcc/testsuite/g++.old-deja/g++.warn/impint.C 2006-07-09 19:21:13.0 +0100
@@ -1,7 +1,9 @@
// { dg-do assemble }
-// { dg-options "-Wconversion" }
+// { dg-options "-Wcoercion" }
+
// Copyright (C) 2000 Free Software Foundation, Inc.
// Contributed by Nathan Sidwell 24 Feb 2000 <[EMAIL PROTECTED]>
+// Modified by Manuel Lopez-Ibanez 7 Jul 2006 <[EMAIL PROTECTED]>
// derived from a bug report by Johan Kuipers <[EMAIL PROTECTED]>
// initialization to 'int' from to 'double' We expect consistent warnings
Re: problem in gcc port based on MIPS
Please do not send e-mail to both gcc and gcc-help. Please just write to one mailing list. Thanks. "kernel coder" <[EMAIL PROTECTED]> writes: > I modified mips backend to support stw instruction.But during the > compilation of crtstuff.c it is generating an instrucion > > stw $2,p.2249 > > as this format of instruction is not supported on assembler,an error > for illegal operands(p.2249) is being generated. > > First of all i'm not been able to understand the operand p.2249 as i'm > newbie to mips assembly.According to tc-mips.c code in GAS ,it seems > to be a 32 address,but still the syntax is not clear to me. p.2249 is simply the name of a symbol. > Where in mips backend in gcc (mips.md,mips.h,mips.c) such type of > offset(p.2249) is being generated because i need to tell the compiler > that only allowed offset for stw instruction is 16-bit and generated > format should be > > stw reg,offset(reg) The name p.2249 is most likely coming from the machine independent code. You can see names like this for a function static variable named "p". Note that all MIPS processors are restricted to 16 bit offsets in the sw instruction. Most MIPS assemblers support "sw $2,foo" by expanding it into multiple instructions. However, the compiler also supports expanding that into multiple instructions itself, which is generally better for scheduling purposes. So if you are modifying the existing MIPS backend, you should force TARGET_EXPLICIT_RELOCS to be true. Then the compiler will not normally a store word for a symbol. Ian
request for new a syntactic design for C/C++.
Hello ! I for the first time write to this list of dispatch. I would like to offer one expansion for C/C ++. It is quite well entered in an existing design of language. This expansion increases expressive power of language since preconditions for reduction of a role of macros and patterns are created. For some schemes in which it is necessary to carry out reductions of type to appear more logical alternative design. Now in essence. Some time back I did not like a situation with asymmetry dereferencing fields of structure. I.e. absolutely easily it is possible to receive the address of memory almost any element in structure (except for a bit field), but reversed transformation, i.e. to the address of a field to receive the beginning of all structure, is essentially more complex operation in which some assignments of types are made. Not strict typification in this case can arouse a mistake in a code. Reduction of type very frequent operation for structures at which in the beginning of structure appears other, heading structure. The first offer concerns additions of a symmetric design concerning syntax dereferencing an element. On an example dereferencing "init_ptr = *load_ptr-> field;" I shall describe reversed syntax. Current syntax C/C++: load_ptr = typeof(load_ptr)(((char *)init_ptr) - \ offsetof(typeof(init_ptr), field); The offered syntax: &load_ptr->field = init_ptr; Where `load_ptr' and `init_ptr' should be indexes. In the index `load_ptr' the address of the beginning of structure `typeof(load_ptr)` with which the field field is placed to the address of which specifies `init_ptr' will be placed. It is possible to combine with definition. The name of type is added only: struct some_struct &load_ptr->field = init_ptr; load_ptr->field = val; Definition is similar to existing syntax of definition in C++. But nevertheless syntax, and operation (I mean similarity of operation, that the symbol '&' is used to the left of a sign on giving) differs: Definition is similar to existing syntax of definition in C++. But differs both syntax, and action of operation. I mean similarity of operation, that the symbol '&' is used to the left of a sign '=' on giving. C++: struct some_struct &link = other; link.field = val; Assignment: link1 = &load_ptr->field = link2 = init_ptr; It should be interpreted from right to left: link2 = init_ptr; &load_ptr->field = init_ptr; link1 = init_ptr; If it is necessary to receive the beginning of structure on a field of other structure, enclosed in given these fields are specified through a symbol of a point: &load_ptr->substruct1.substruct2.field = init_ptr; Sense in that if simply to change places the right and left parts of operation of giving we receive operation, reversed given. At a physical level operation "init_ptr = &load_ptr-> field;" initializes a variable `init_ptr' which the beginnings of structure are defined by an increment to `load_ptr' sizes of shift of a field `field' concerning. Operation "*load_ptr-> field = init_ptr;" defines `load_ptr' by reduction `init_ptr' on size of shift of a field `field' concerning the beginning of structure. In my opinion, this opportunity will promote development of procedural programming. In some cases will make unnecessary use of dangerous assignment of type. Quite probably that the similar offer appeared earlier. If it so I ask me to excuse. Thanks.
