Re: libtool for shared objects?
On Mar 11, 2008, Basile STARYNKEVITCH <[EMAIL PROTECTED]> wrote: >> * Basile STARYNKEVITCH wrote on Tue, Mar 11, 2008 at 09:18:54PM CET: >>> I would like to use this tool to compile some (generated) >>> warm(basilys.c file into a warm-basilys.la in the most portable >>> way (on Linux/ELF systems I would just use gcc -fPIC -shared >>> warm-basilys.c -o warm-basilys.so and use the warm-basilys.so >>> shared library to dlopen). > I need all this in the gcc/ subdir, since I want cc1 (the same process) to > 1. generate a C file > 2. compile it to some dynamically loadable stuff (*.so on Linux/Elf, > perhaps *.la with libtool) > 3. lt_dlopenext it Erhm... You can't even count on having functional dynamic libraries, let alone dlopen. libtool will try to minimize the impact of these absences with the -dlopen flag, that will link the wanted library into the main executable, such that libltdl will pretend to dlopen and look up symbols. Given lack of dlopen, it's not possible to accommodate dlopening emulation of libraries created after the executable, which is what you're after. libtool and libltdl won't help you in these cases. You probably don't care about them, though. I'm not sure when the library you have in mind is supposed to be built. If it's to be built as part of the GCC build process, then there's no reason I can think of to depend on dlopen in the first place. Simply linking it into GCC should be nearly the same, unless you depend on dynamic symbol lookup, which could be easily emulated. But if the library is to be build as part of the *use* of GCC, then things get much trickier. libtool is not designed for this kind of use, although you could in theory build and install a libtool that will work along with the compiler, but there are many caveats. I don't think I'd recommend going down this path, but if this is your case, I can elaborate further. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: libtool for shared objects?
Alexandre Oliva wrote:
On Mar 11, 2008, Basile STARYNKEVITCH <[EMAIL PROTECTED]> wrote:
* Basile STARYNKEVITCH wrote on Tue, Mar 11, 2008 at 09:18:54PM CET:
I would like to use this tool to compile some (generated)
warm-basilys.c file into a warm-basilys.la in the most portable
way (on Linux/ELF systems I would just use gcc -fPIC -shared
warm-basilys.c -o warm-basilys.so and use the warm-basilys.so
shared library to dlopen).
I need all this in the gcc/ subdir, since I want cc1 (the same process) to
1. generate a C file
2. compile it to some dynamically loadable stuff (*.so on Linux/Elf,
perhaps *.la with libtool)
3. lt_dlopenext it
Erhm... You can't even count on having functional dynamic libraries,
let alone dlopen. libtool will try to minimize the impact of these
absences with the -dlopen flag, that will link the wanted library into
the main executable, such that libltdl will pretend to dlopen and look
up symbols.
I'm explicitly testing the availability of libtldl at configure time. If
the build system don't have it, toplevel configure should fail (and I
know how to do that) Actually, the MELT feature can only work on the
systems which really provides a real dynamic linking mechanism (and
*not* only the dlpreopen hack to avoid it thru static prelinking
emulation!), i.e. having one of
* dlopen (Solaris, Linux and various BSD flavors)
* shl_load (HP-UX)
* LoadLibrary (Win16 and Win32)
* load_add_on (BeOS)
http://www.delorie.com/gnu/docs/libtool/libtool_45.html
I call dynamic stuff the thing (usually a file) that these functions
load dynamically. On ELF (Linux,Solaris,...) or BSD systems it probably
is a *.so shared object (& position independent) file every linux user
is familiar with. On HPUX it probably would be some *.sl file. On Win*
probably some *.dll and/or *.lib and I don't know how it is called on BeOS
And of course I do depend on the functionality (provided by e.g. dlopen
on Solaris & Linux, by shl_load on HPUX, ... all them wrapped in
lt_dlopenext ) of dynamically loading a stuff at cc1 run time. (in other
words, I *am* making a plugin mechanism). On the few (build or host)
systems which still are lacking of this functionality, all the MELT
stuff is (or has to) be disabled at configure time and that is ok for me
(as it is for every plugin hacker in GCC).
Given lack of dlopen, it's not possible to accommodate dlopening
emulation of libraries created after the executable, which is what
you're after. libtool and libltdl won't help you in these cases. You
probably don't care about them, though.
Yes, because I am supposing a *working* lt_dlopenext able to really load
dynamic stuff
I'm not sure when the library you have in mind is supposed to be
built. If it's to be built as part of the GCC build process, then
there's no reason I can think of to depend on dlopen in the first
place. Simply linking it into GCC should be nearly the same, unless
you depend on dynamic symbol lookup, which could be easily emulated.
But if the library is to be build as part of the *use* of GCC, then
things get much trickier. libtool is not designed for this kind of
use, although you could in theory build and install a libtool that
will work along with the compiler, but there are many caveats. I
don't think I'd recommend going down this path, but if this is your
case, I can elaborate further.
Actually, I just want to generate (during the build process in gcc/
subdir in build directory) a script (basilys-gcc) invoked by cc1 with
two arguments :
the full path of some C file to generate
the stripped path (without .so or .sl or .la) of the generated
dynamic stuff
On Linux systems basilys-gcc would just be
#! /bin/sh
gcc -I...appropriatedir... -fPIC -shared -O -g $1 -o $2.so
and I do know what is the ...appropriatedir...
I was thinking that it would be a bit more portable to have it instead
#! /bin/sh
libtool cc -I...appropriatedir... -O -g $1 -o $2.lo
but there might be some thing I misunderstood.
And yes, my cc1 doing lt_dlopenext is linked with a -rdynamic flag.
Comments are welcome.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: RTL definition
Hello all, Maybe I can add a few comments here. This is the way I see the RTL within GCC. Details are at: http://www.cfdvs.iitb.ac.in/~amv/gcc-int-docs/ and in particular, I'd like to point to http://www.cfdvs.iitb.ac.in/~amv/gcc-int-docs/html/gcc-conceptual-structure.html. (BTW, community feedback requested for the above documents.) On Tue, 2008-03-11 at 06:55 -0700, Ian Lance Taylor wrote: > "Fran Baena" <[EMAIL PROTECTED]> writes: > > >> By the way, RTL is not really machine-independent. The data > >> structures are machine independent. But the contents are not. You > >> can not, even in principle, take the RTL generated for one processor > >> and compile it on another processor. > > > > I thought that RTL represented something close to the target machine, > > but not machine-dependent. I firstly thought that the output of the > > middle-end was an RTL machine-independent representation, to which is > > applied a few low-optimization machine-independent passes, and after > > that is translated to a RTL machine-dependent to be applied other > > optimization passes. > > RTL is created using named patterns in the MD file, so even the > creation process is machine-dependent. This is most obvious in the > use of unspec, but it is true in general. Adding to the above, I think it's best to see the RTL constructs as a specification language. The semantics of the target instructions are expressed in this language. RTL expresses machine dependent issues in a machine independent manner. This process of capturing machine issues occurs when the machine descriptions are written. Machine descriptions mainly contain the semantics of each target instruction (the "define_insn" construct) and information (pattern names) to be used to associate them to Gimple objects. During a compilation of a program these target specific descriptions are used directly by the Gimple->RTL translation phase, and hence the output is a RTL representation that has captured target semantics. The Gimple->RTL translation does not emit a machine independent RTL representation. Quite the opposite. > > I read the rtl.def and rtl.h files, are very interesting, and i better > > understand the whole process. But reading the output files by debuggin > > options (-fdump-rtl-all) i have seen instructions like this: > > > > (insn 8 6 10 1 (set (mem/c/i:SI (plus:DI (reg/f:DI 54 virtual-stack-vars) > > (const_int -8 [0xfff8])) [0 a+0 S4 A64]) > > (const_int 1 [0x1])) -1 (nil) > > (nil)) > > > > Among the multiple questions that appears i have a particular one, > > what does "8 6 10 1" represents? Is it the "print format" defined in > > rtl.def? > > 8 is in the INSN uid. 6 is the previous INSN uid. 10 is the next > insn UID. 1 is the number of the basic block holding the insn. In > general RTL is printed according to the format in rtl.def. There are > a couple of exceptions; one of those exceptions is that field 4 of an > insn, INSN_LOCATOR, is only printed if it is present. See line 391 of > print-rtl.c. It helps to see the above RTL as the written representation of internal linear-linked-list-of-RTL-objects. The "(set (mem...))" is an _instance_ of the specification in the .md file. It describes the semantics of an instruction available on the target. The entire linked list may be thought of as a machine independent representation of machine specific instructions, i.e. the ASM syntax has been stripped off. The RTL dump given above describes this chaining structure: the position of the current instruction, the (RTL representation) of the previous and next instructions etc. (as described in the reply above). General remarks: I prefer to view the objects in rtl.def as three disjoint subsets: one set of objects appear exclusively in machine descriptions, another set of objects appear exclusively in dumps during a compilation run, and the third set of objects appear in both. The first set of objects are constructs like define_insn, match_operand etc. The second set of objects are constructs like insn, jump_insn etc. and the third set of objects are constructs like set, plus etc. Objects from the first and the third set are used to write machine descriptions. Objects from the second and the third set are used to dump the RTL representation of a compilation run. It, thus, seems best to think of the RTL (as the gcc community usually refers to) as two different languages. One language, that we call the MD-RTL is used to capture target instruction semantics while developing a machine description .md file, and is made up of constructs from the first and the third sets from rtl.def. The other, that we call the IR-RTL is used to _express_ a given compilation in a target specific manner without the target (asm) syntax, and is made up of constructs from the second and the third sets from rtl.def. The written form of both these is lisp like. The MD-RTL has only a written representation, while the IR-RTL
[PATCH] Fix bug on soft emulation of float point in gcc/longlong.c
There are 2 bugs existing in __udiv_qrnnd_c:
1. remainder could not be counted correctly
__r1 and __r0 are not adding enough, so I use do..while to replace former if
2. the case of overflow of __m are not considered
so I add a couple of lines to handle it
I found the bugs from Linux kernel,
for PowerPC math-emu use __udiv_qrnnd_c to emulate float div.
I sent the patch to the maintainers of kernel, but they replied to me that
this code came from gcc and should better keep coincident.
So I think I should send patch to here.
I don't know how to trigger __udiv_qrnnd_c in gcc.
but if the argument of __udiv_qrnnd_c are like
0x07f8 0x07f8 0x00210fff 0xc000 0x07f8,
the bug will be reproduced.
Also, you can try the program below, I have test it on Linux kernel math-emu
but haven't test on gcc.
---
#include
union fu {
unsigned int u;
float f;
};
union fu fdiv(union fu a, union fu b, union fu expected)
{
union fu z;
z.f = a.f / b.f;
printf("fdiv %08x / %08x = %08x expected %08x %s\n",
a.u, b.u, z.u, expected.u,
(z.u == expected.u) ? "(PASS)" : "(FAIL)");
printf(" %e / %e = %e\n", a.f, b.f, z.f);
}
int main()
{
union fu fa,fb,fe;
fa.u = 0xc0843fff;
fb.u = 0x80ff;
fe.u = 0x7f044000;
fdiv(fa,fb,fe);
}
---
Signed-off-by: Liu Yu <[EMAIL PROTECTED]>
---
gcc/longlong.h | 18 --
1 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/gcc/longlong.h b/gcc/longlong.h
index 6c24564..256399b 100644
--- a/gcc/longlong.h
+++ b/gcc/longlong.h
@@ -1368,12 +1368,15 @@ UDItype __umulsidi3 (USItype, USItype);
__q1 = (n1) / __d1;
\
__m = (UWtype) __q1 * __d0;
\
__r1 = __r1 * __ll_B | __ll_highpart (n0); \
+if (__d0 && __q1 > __m / __d0) \
+ do {\
+ __q1--, __r1 += (d);\
+ } while (__r1 >= (d)); \
if (__r1 < __m)\
{
\
- __q1--, __r1 += (d);\
- if (__r1 >= (d)) /* i.e. we didn't get carry when adding to __r1 */\
- if (__r1 < __m) \
+ do {\
__q1--, __r1 += (d);\
+ } while (__r1 >= (d) && __r1 < __m);\
}
\
__r1 -= __m; \
\
@@ -1381,12 +1384,15 @@ UDItype __umulsidi3 (USItype, USItype);
__q0 = __r1 / __d1;
\
__m = (UWtype) __q0 * __d0;
\
__r0 = __r0 * __ll_B | __ll_lowpart (n0); \
+if (__d0 && __q0 > __m / __d0) \
+ do {\
+ __q0--, __r0 += (d);\
+ } while (__r0 >= (d)); \
if (__r0 < __m)\
{
\
- __q0--, __r0 += (d);\
- if (__r0 >= (d))\
- if (__r0 < __m) \
+ do {\
__q0--, __r0 += (d);\
+ } while (__r0 >= (d) && __r0 < __m);\
}
\
__r0 -= __m; \
\
--
1.5.2
Re: New picoChip port and maintainers
Thanks to the GCC SC for accepting the picochip port. Regards Hari David Edelsohn wrote: I am pleased to announce that the GCC Steering Committee has accepted the picoChip port for inclusion in GCC and appointed Hariharan Sandanagobalane and Daniel Towner as port maintainers. The initial patch needs approval from a GCC GWP maintainer before it may be committed. Please join me in congratulating Hari and Daniel on their new role. Please update your listing in the MAINTAINERS file. Happy hacking! David
Re: libtool for shared objects?
Basile STARYNKEVITCH <[EMAIL PROTECTED]> writes: > Actually, I just want to generate (during the build process in gcc/ subdir > in build directory) a script (basilys-gcc) invoked by cc1 with two > arguments : >the full path of some C file to generate >the stripped path (without .so or .sl or .la) of the generated dynamic > stuff What does this script do? Why can't you generate it in a separate toplevel directory? 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: API for callgraph and IPA passes for whole program optimization
> On 3/9/08 7:26 AM, Jan Hubicka wrote:
>
> >compensate testsuite and documentation for the removal of RTL dump
> >letters so I would rather do that just once. Does this seem OK?
>
> Yup, thanks for doing this.
>
>
> >The patch include the read/write methods that will be just placeholders
> >on mainline. Naturally I can remove them for time being at least as
> >long as we think the RTL_PASS/TREE_PASS macros are good idea.
>
> Nitpick on the name, can you s/TREE/GIMPLE/?
Sure. Though gimplifier itself might end up being GIMPLE_PASS but it is
not big deal I guess.
>
>
> >quite easilly see that those are stepping back from plan not making
> >passmanager poluted by ugly macros, but on the other hand since the PM
> >is now doing RTL/IPA/tree passes it needs at least a little of
> >flexibility to be able update API of one without affecting others.
>
> How about doing the simple hierarchy as you outlined in your last
> message? Both gimple and rtl passes would inherit everything from base,
> and ipa would have the additional hooks for summary generation and whatnot.
OK, I something like this?
Index: tree-pass.h
===
--- tree-pass.h (revision 133036)
+++ tree-pass.h (working copy)
@@ -88,9 +88,19 @@ extern const char *dump_file_name;
/* Return the dump_file_info for the given phase. */
extern struct dump_file_info *get_dump_file_info (enum tree_dump_index);
+/* Forward declare so we don't need to bring in cgraph and varpool include. */
+struct cgraph_node;
+struct varpool_node;
+
/* Describe one pass. */
-struct tree_opt_pass
+struct opt_pass
{
+ enum pass_type {
+ GIMPLE_PASS,
+ RTL_PASS,
+ SIMPLE_IPA_PASS,
+ IPA_PASS
+ } pass_type;
/* Terse name of the pass used as a fragment of the dump file name. */
const char *name;
@@ -124,11 +134,51 @@ struct tree_opt_pass
/* Flags indicating common sets things to do before and after. */
unsigned int todo_flags_start;
unsigned int todo_flags_finish;
+};
+
+struct gimple_pass
+{
+ struct opt_pass;
+};
+
+struct rtl_pass
+{
+ struct opt_pass;
+};
- /* Letter for RTL dumps. */
- char letter;
+struct simple_ipa_pass
+{
+ struct opt_pass;
};
+struct ipa_pass
+{
+ struct opt_pass;
+
+ /* IPA passes can analyze function body and variable initializers using this
+ hook and produce summary. */
+ void (*function_generate_summary) (struct cgraph_node *);
+ void (*variable_generate_summary) (struct varpool_node *);
+
+ /* These hooks will be used to serialize IPA summaries on disk. For a moment
+ they are just placeholders. */
+ void (*function_write_summary) (struct cgraph_node *);
+ void (*variable_write_summary) (struct varpool_node *);
+ void (*function_read_summary) (struct cgraph_node *);
+ void (*variable_read_summary) (struct varpool_node *);
+
+ /* Results of interprocedural propagation of an IPA pass is applied to
+ function body via this hook. */
+ void (*function_transform) (struct cgraph_node *);
+ void (*variable_transform) (struct varpool_node *);
+};
+
/* Define a tree dump switch. */
struct dump_file_info
{
@@ -138,7 +188,6 @@ struct dump_file_info
int flags;/* user flags */
int state;/* state of play */
int num; /* dump file number */
- int letter; /* enabling letter for RTL dumps */
};
/* Pass properties. */
>
>
> Diego.
-B vs Multilib
Hi, Currently, -B doesn't add the multilib search paths when processing startfile_prefixes. For example, -B $prefix/lib/ doesn't find startfiles in $prefix/lib/../lib64 Most other calls to add_prefix() in gcc.c that refer to startfile_prefixes do actually process the multilibs. Is there any good reason why -B needs to be different? Maybe there are assumptions in the GCC build itself that would break if this were to change. As you can probably tell, I haven't yet tried a build with this changed but was just wondering if anyone knew the rationale for the current -B behaviour WRT startfiles and/or whether it's just an oversight. Thanks Greg
Re: Fwd: Porting gcc to a new architecture
> "Schmave" == Schmave <[EMAIL PROTECTED]> writes: > i was wondering what steps i need to take to port gcc to a new > architecture Did you find something unclear in the GCC documentation? Do you have a specific question? Sam -- Samuel Tardieu -- [EMAIL PROTECTED] -- http://www.rfc1149.net/
Re: libtool for shared objects?
Andreas Schwab wrote:
Basile STARYNKEVITCH <[EMAIL PROTECTED]> writes:
Actually, I just want to generate (during the build process in gcc/ subdir
in build directory) a script (basilys-gcc) invoked by cc1 with two
arguments :
the full path of some C file to generate
the stripped path (without .so or .sl or .la) of the generated dynamic
stuff
What does this script do?
It just compile a (generated) C file, eg foo.c into a dynamically
loadable shared object foo.so (at least on Linux)
On linux it would be probably
#! /bin/sh
# $1 is foo.c $2 is foo or foo.so
gcc -fPIC -shared -I...someincludedir $1 -o `basename $2`.so
And the ...someincludedir above is exactly the value of
$(melt_private_include_dir) in my gcc/Makefile.in i.e;
$(libexecsubdir)/melt-private-include/ see the
http://gcc.gnu.org/ml/gcc/2008-02/msg00673.html thread
Since this script is internal to GCC MELT branch, I would believe it
might be installed as perhaps $(libexecsubdir)/melt-gcc-build but I am
open to other suggestions (in particular, I still don't understand the
relation between the -B argument to gcc and $(libexecsubdir)).
Why can't you generate it in a separate toplevel directory?
I am not sure to understand what exactly you mean. Do you suggest to
generate this script in the toplevel (top of gcc source directory)
Makefile.tpl or do you suggest it to be generated in a yet another new
subdirectory of the topdir. My (perhaps wrong) intuition was that since
it is intimately related to cc1 it should be built in gcc/Makefile.in
(which is building cc1).
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: libtool for shared objects?
Basile STARYNKEVITCH <[EMAIL PROTECTED]> writes: >> Why can't you generate it in a separate toplevel directory? > > > I am not sure to understand what exactly you mean. Do you suggest to > generate this script in the toplevel (top of gcc source directory) > Makefile.tpl or do you suggest it to be generated in a yet another new > subdirectory of the topdir. The latter, or at least not necessarily inside the gcc subdir. > My (perhaps wrong) intuition was that since it is intimately related > to cc1 it should be built in gcc/Makefile.in (which is building cc1). Like libcpp is intimately related to cc1, yet built in its own toplevel directory. Or libgcc is intimately related to cc1, although only at link time. But it looks like the functionality provided by your script is either similar to libcpp or similar to libgcc, and should be handled like those. 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."
update_path in gcc/prefix.h?
Hello all,
What is the exact intent of the update_path in gcc/prefix.[hc]?
I would guess it is related to the -B option to gcc driver executable.
But I'm not sure how exactly. I don't exactly understand what it means
to pass "GCC" (or "BINUTILS") as the key (2nd) argument to update_path.
in the MELT branch http://gcc.gnu.org/wiki/MiddleEndLispTranslator
I would like to reference from within the cc1 executable some
directories like e.g. $(libexecsubdir)/melt-private-include/ in
gcc/Makefile.in parlance.
I got the vague impression that a call to
update_path("melt-private-include/', "GCC") would return it, but I am
really not sure.
For motivations on why I'm asking, see the wiki page, the MELT branch
itself, and previous related threads like
http://gcc.gnu.org/ml/gcc/2008-03/msg00524.html
http://gcc.gnu.org/ml/gcc/2008-03/msg00549.html
http://gcc.gnu.org/ml/gcc/2008-03/msg00151.html
http://gcc.gnu.org/ml/gcc/2008-02/msg00679.html
http://gcc.gnu.org/ml/gcc/2008-02/msg00632.html
More generally, any advices and how and where should I read files inside
some middle-end code are welcome. I'm pretty sure other peoples got into
similar issues, but I don't know where and how
Regards
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: API for callgraph and IPA passes for whole program optimization
On Wed, Mar 12, 2008 at 04:19, Jan Hubicka <[EMAIL PROTECTED]> wrote: > Sure. Thanks. Phasing out the 'tree' name is going to be a long process. > Though gimplifier itself might end up being GIMPLE_PASS but it is > not big deal I guess. Both the gimplifier and the rtl expander will always have one foot on each side of the fence. Is cfgexpand a gimple pass or an rtl pass? For consistency, we probably want to consider it an rtl pass. But I don't think the distinction too important. > + /* These hooks will be used to serialize IPA summaries on disk. For a > moment > + they are just placeholders. */ s/a moment/the moment/ Yup, looks good. Thanks. Diego.
gcc 4.3.0 i386 default question
Hi, Did the default i386 CPU model that gcc generates code for change between 4.2.x and 4.3.0? I didn't see anything in the release notes that jumps out at me about this. Using i386-rtems4.9 as the target, I was running code compiled by gcc 4.3.0 on a vanilla i386 and was getting illegal instruction exceptions. I looked at the assembly and noticed instructions which were not on the i386. Obviosuly, when I added -mtune=i386 and the issue went away. This probably impacts no one on a GNU/Linux computer since very few of those are base i386's anymore. Just venerable embedded systems. :) -- Joel Sherrill, Ph.D. Director of Research & Development [EMAIL PROTECTED]On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: gcc 4.3.0 i386 default question
On Wed, Mar 12, 2008 at 4:23 PM, Joel Sherrill <[EMAIL PROTECTED]> wrote: > Hi, > > Did the default i386 CPU model that gcc generates > code for change between 4.2.x and 4.3.0? I didn't > see anything in the release notes that jumps out at > me about this. > > Using i386-rtems4.9 as the target, I was running > code compiled by gcc 4.3.0 on a vanilla i386 and > was getting illegal instruction exceptions. I looked > at the assembly and noticed instructions which were > not on the i386. Obviosuly, when I added -mtune=i386 > and the issue went away. > > This probably impacts no one on a GNU/Linux computer > since very few of those are base i386's anymore. Just > venerable embedded systems. :) -mtune doesn't change the instruction set, -march/-mcpu does. So this is probably a bug in the instruction predicates. What is the illegal instruction gcc emits? Richard.
Re: gcc 4.3.0 i386 default question
> Hi, > > Did the default i386 CPU model that gcc generates > code for change between 4.2.x and 4.3.0? I didn't > see anything in the release notes that jumps out at > me about this. There wasnt any intend to change the codebase. However the default tunning now has changed to "generic" model. Perhaps some non-i386 instructions got in as a mistake. Can you be more specific about what instructions you found? Honza > > Using i386-rtems4.9 as the target, I was running > code compiled by gcc 4.3.0 on a vanilla i386 and > was getting illegal instruction exceptions. I looked > at the assembly and noticed instructions which were > not on the i386. Obviosuly, when I added -mtune=i386 > and the issue went away. > > This probably impacts no one on a GNU/Linux computer > since very few of those are base i386's anymore. Just > venerable embedded systems. :) > > > -- > Joel Sherrill, Ph.D. Director of Research & Development > [EMAIL PROTECTED]On-Line Applications Research > Ask me about RTEMS: a free RTOS Huntsville AL 35805 > Support Available (256) 722-9985 >
Official GCC git repository
Hello, many people seem to be finding our git mirror of the GCC repo useful: http://git.infradead.org/toolchain/gcc.git git://git.infradead.org/toolchain/gcc.git Therefore, I'd like to advertise it on the GCC web site as an alternative to the Subversion repository. If nobody is opposed, I'll send a patch for wwwdocs. Developers use it for read-only access, and could even commit patches to the master repository with git svn, without the need for a separate svn checkout. At this time, the repository is being synch'd every quarter hour (actually 03,18,33,48 * * * *), and carries all branches (although only a few are displayed). If people think it would be useful, we could install a commit hook on gcc.gnu.org to mirror each commit immediately. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/
Re: update_path in gcc/prefix.h?
On Wed, Mar 12, 2008 at 04:06:52PM +0100, Basile STARYNKEVITCH wrote: > Hello all, > > > What is the exact intent of the update_path in gcc/prefix.[hc]? Very complicated and underdocumented; I avoid it for that reason. Can't you use an existing directory variable, like gcc_libexec_prefix? -- Daniel Jacobowitz CodeSourcery
RFC: adding knowledge of the int_fastN_t types to the compiler
Hi all, The Fortran 2003 standard requires that Fortran compilers be able to know, at compile-time, what size the various int_fastN_t types have on the target (for N = 8, 16, 32 and 64). I've discussed that issue before on this list, and was told it's a known issue, tracked as PR 448. For 4.3, we ignored the issue; for 4.4, I'd like to move forward and propose some way to go. Here's the idea I've been following: it's not excellent, but I don't think there are many alternatives available! I propose we implement target macros INT_FAST8_TYPE_SIZE (and so on for 16, 32 and 64): they would be defined to -1 in defaults.h (meaning that int_fastN_t types are not available), and independent targets can redefine them. Front-ends and the middle-end can then use it if they feel like it. Attached is a patch implementing this idea, including target definitions for linux, darwin, mingw, AIX, IRIX, OpenBSD, Solaris 2.10. Comments on that first draft are welcome. I know it's a hard issue and most possible fixes are more hacks than fixes, but the starting point is that we really need it to work, and a system that covers 99% of cases is better than nothing. Thanks, FX -- François-Xavier Coudert http://www.homepages.ucl.ac.uk/~uccafco/ intfast-1.diff Description: Binary data
Re: gcc 4.3.0 i386 default question
Richard Guenther wrote: On Wed, Mar 12, 2008 at 4:23 PM, Joel Sherrill <[EMAIL PROTECTED]> wrote: Hi, Did the default i386 CPU model that gcc generates code for change between 4.2.x and 4.3.0? I didn't see anything in the release notes that jumps out at me about this. Using i386-rtems4.9 as the target, I was running code compiled by gcc 4.3.0 on a vanilla i386 and was getting illegal instruction exceptions. I looked at the assembly and noticed instructions which were not on the i386. Obviosuly, when I added -mtune=i386 and the issue went away. This probably impacts no one on a GNU/Linux computer since very few of those are base i386's anymore. Just venerable embedded systems. :) -mtune doesn't change the instruction set, -march/-mcpu does. So this is probably a bug in the instruction predicates. What is the illegal instruction gcc emits? I saw a series of instructions with something like mm0 as a register. I can't duplicate it now but also realized that a background automated run of tests may have been replacing the boot image behind my back. The danger of multitasking. I am sorry to have raised this. I think this points out what is happening in the failures I see when running the gcc testsuite though: http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00944.html Lots of tests with "vect" or "sse" in the name fail when run on the same vanilla i386 target. For example, gcc.dg/vect/costmodel/i386/costmodel-vect-31.c fails with a similar illegal instruction exception. Looking at that particular case, I see that it is compiled with -msse2 and fails with an illegal instruction exception when it tries this one: 10022a: f2 0f 10 c0 movsd %xmm0,%xmm0 Is there any way to skip these tests for particular HW features that are not present? There are similar failures on the PowerPC target I use for reporting because it doesn't have Altivec. Thanks. Sorry for the bogus question. Richard. -- Joel Sherrill, Ph.D. Director of Research & Development [EMAIL PROTECTED]On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: gcc 4.3.0 i386 default question
On Wed, Mar 12, 2008 at 9:09 AM, Joel Sherrill <[EMAIL PROTECTED]> wrote: > > 10022a: f2 0f 10 c0 movsd %xmm0,%xmm0 > > Is there any way to skip these tests for particular HW features > that are not present? There are similar failures on the PowerPC > target I use for reporting because it doesn't have Altivec. > > Thanks. Sorry for the bogus question. These testcases are trying to check at runtime you have SSE2 or VMX support but it looks like you don't have signal support so they are failing. -- Pinski
Re: update_path in gcc/prefix.h?
Daniel Jacobowitz wrote:
On Wed, Mar 12, 2008 at 04:06:52PM +0100, Basile STARYNKEVITCH wrote:
Hello all,
What is the exact intent of the update_path in gcc/prefix.[hc]?
Very complicated and underdocumented; I avoid it for that reason.
Can't you use an existing directory variable, like gcc_libexec_prefix?
Thanks for the suggestion. I'll probably try.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: gcc 4.3.0 i386 default question
On Wed, Mar 12, 2008 at 09:13:07AM -0700, Andrew Pinski wrote: > On Wed, Mar 12, 2008 at 9:09 AM, Joel Sherrill > <[EMAIL PROTECTED]> wrote: > > > > > 10022a: f2 0f 10 c0 movsd %xmm0,%xmm0 > > > > Is there any way to skip these tests for particular HW features > > that are not present? There are similar failures on the PowerPC > > target I use for reporting because it doesn't have Altivec. > > > > Thanks. Sorry for the bogus question. > > These testcases are trying to check at runtime you have SSE2 or VMX support > but > it looks like you don't have signal support so they are failing. > Why not to use cpuid () to check them? H.J.
Re: gcc 4.3.0 i386 default question
H.J. Lu wrote: On Wed, Mar 12, 2008 at 09:13:07AM -0700, Andrew Pinski wrote: On Wed, Mar 12, 2008 at 9:09 AM, Joel Sherrill <[EMAIL PROTECTED]> wrote: 10022a: f2 0f 10 c0 movsd %xmm0,%xmm0 Is there any way to skip these tests for particular HW features that are not present? There are similar failures on the PowerPC target I use for reporting because it doesn't have Altivec. Thanks. Sorry for the bogus question. These testcases are trying to check at runtime you have SSE2 or VMX support but it looks like you don't have signal support so they are failing. We have POSIX signals but since this is embedded, we expect people to compile their code properly to run on the target hardware. So an illegal instruction isn't mapped to POSIX sigill but to a fatal OS exception. Why not to use cpuid () to check them? I don't even see a GNU/Linux man page for this one. Is it standard? Could it portably be used to avoid Altivec also? Since we are talking 100s of tests, it seems like it would be easiest to avoid them in the scripts. I just don't know how to do that. --joel
Re: Official GCC git repository
> "Bernardo" == Bernardo Innocenti <[EMAIL PROTECTED]> writes: Bernardo> If people think it would be useful, we could install a commit Bernardo> hook on gcc.gnu.org to mirror each commit immediately. It would be great! Sam -- Samuel Tardieu -- [EMAIL PROTECTED] -- http://www.rfc1149.net/
Re: gcc 4.3.0 i386 default question
> Since we are talking 100s of tests, it seems like it would be > easiest to avoid them in the scripts. I just don't know how > to do that. You might want to look at how the ARM NEON vector unit is handled (check_effective_target_arm_neon_ok and check_effective_target_arm_neon_hw). Paul
Re: gcc 4.3.0 i386 default question
Paul Brook wrote: Since we are talking 100s of tests, it seems like it would be easiest to avoid them in the scripts. I just don't know how to do that. You might want to look at how the ARM NEON vector unit is handled (check_effective_target_arm_neon_ok and check_effective_target_arm_neon_hw). If I understand this correctly, it is checking that the target HW actually supports the Neon extension. Is this right? Where does this get invoked? I think I am on the edge of understanding a solution path. It sounds like I need to add similar ones for MMX, SSE, Altivec, and any other odd multilib CPU option that the test suite hits and a particular target CPU does not support. Right? --joel
Re: gcc 4.3.0 i386 default question
> Joel Sherrill writes: Joel> If I understand this correctly, it is checking that the Joel> target HW actually supports the Neon extension. Joel> Is this right? Joel> Where does this get invoked? Joel> I think I am on the edge of understanding a solution Joel> path. It sounds like I need to add similar ones Joel> for MMX, SSE, Altivec, and any other odd multilib Joel> CPU option that the test suite hits and a particular Joel> target CPU does not support. Right? These already exist for Altivec, but for some reason your testing harness is not reporting back failure correctly to disable the tests for PowerPC. See .../gcc/testsuite/lib/target-supports.exp check_effective_target_powerpc_altivec check_effective_target_powerpc_altivec_ok check_vmx_hw_available i?86 does not seem to have as many checks. David
Re: libtool for shared objects?
On Mar 12, 2008, Basile STARYNKEVITCH <[EMAIL PROTECTED]> wrote: > Actually, I just want to generate (during the build process in gcc/ > subdir in build directory) a script (basilys-gcc) invoked by cc1 with > two arguments : >the full path of some C file to generate >the stripped path (without .so or .sl or .la) of the generated > dynamic stuff > I was thinking that it would be a bit more portable to have it instead > #! /bin/sh > libtool cc -I...appropriatedir... -O -g $1 -o $2.lo I see. Yes, you could do that. Ideally, you'd be using your own copy of the libtool script, configured to use the newly-built-and-already-installed toolchain under your control. Simply using /usr/bin/libtool a pre-installed libltdl, with whatever compiler happens to be in /usr/bin/gcc, are error-prone, although they work most of the time. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: RFC: adding knowledge of the int_fastN_t types to the compiler
FX Coudert <[EMAIL PROTECTED]> writes:
> The Fortran 2003 standard requires that Fortran compilers be able to
> know, at compile-time, what size the various int_fastN_t types have
> on the target (for N = 8, 16, 32 and 64). I've discussed that issue
> before on this list, and was told it's a known issue, tracked as PR
> 448. For 4.3, we ignored the issue; for 4.4, I'd like to move forward
> and propose some way to go. Here's the idea I've been following: it's
> not excellent, but I don't think there are many alternatives
> available!
>
> I propose we implement target macros INT_FAST8_TYPE_SIZE (and so on
> for 16, 32 and 64): they would be defined to -1 in defaults.h
> (meaning that int_fastN_t types are not available), and independent
> targets can redefine them. Front-ends and the middle-end can then use
> it if they feel like it. Attached is a patch implementing this idea,
> including target definitions for linux, darwin, mingw, AIX, IRIX,
> OpenBSD, Solaris 2.10.
>
> Comments on that first draft are welcome. I know it's a hard issue
> and most possible fixes are more hacks than fixes, but the starting
> point is that we really need it to work, and a system that covers 99%
> of cases is better than nothing.
I don't disagree with that, but I would also like to see something
that will not require changing every target for basic default
behaviour.
I'd like to suggest that in the absence of other information from the
tm.h file, for N in {8,16,32,64}, where N <= UNITS_PER_WORD *
BITS_PER_UNIT, we map int_fastN_t to int_fastM_t, where M ==
UNITS_PER_WORD * BITS_PER_UNIT.
Note that UNITS_PER_WORD need not be a constant, so this is slightly
harder to implement than your proposal.
Ian
Re: gcc 4.3.0 i386 default question
David Edelsohn wrote: Joel Sherrill writes: Joel> If I understand this correctly, it is checking that the Joel> target HW actually supports the Neon extension. Joel> Is this right? Joel> Where does this get invoked? Joel> I think I am on the edge of understanding a solution Joel> path. It sounds like I need to add similar ones Joel> for MMX, SSE, Altivec, and any other odd multilib Joel> CPU option that the test suite hits and a particular Joel> target CPU does not support. Right? These already exist for Altivec, but for some reason your testing harness is not reporting back failure correctly to disable the tests for PowerPC. See .../gcc/testsuite/lib/target-supports.exp check_effective_target_powerpc_altivec check_effective_target_powerpc_altivec_ok check_vmx_hw_available Those all look like checks to see if the compiler itself supports Altivec -- not a run-time check on the hardware like the Neon check_effective_target_arm_neon_hw appears to be. The RTEMS targets have a lot of multilibs so it is very likely that the compiler itself supports options not available on the hardware platform running the tests. i?86 does not seem to have as many checks. I think that is the crux of the issues. There are cases where there need to be run-time checks for target hw supporting a particular feature. So after some successful grep'ing... is this what is required. + Add run-time hw tests for MMX, SSE, and Altivec to target-supports.exp + Augment gcc.dg/vect/vect.exp to check a few more cases. Is that the general plan? David --joel
Re: RFC: adding knowledge of the int_fastN_t types to the compiler
On Wed, 12 Mar 2008, FX Coudert wrote: > I propose we implement target macros INT_FAST8_TYPE_SIZE (and so on for 16, 32 > and 64): they would be defined to -1 in defaults.h (meaning that int_fastN_t > types are not available), and independent targets can redefine them. > Front-ends and the middle-end can then use it if they feel like it. Attached > is a patch implementing this idea, including target definitions for linux, > darwin, mingw, AIX, IRIX, OpenBSD, Solaris 2.10. TARGET_64BIT is not a constant but depends on command-line options and will not be defined at all for some GNU/Linux targets, so your Linux definition is incorrect. I suggest runtime-variable values depending on a target-independent macro such as LONG_TYPE_SIZE. Also remember the various GNU/Linux targets that do not use config/linux.h (alpha, rs6000, sparc). Note that the size is not enough for implementing , you need the actual type as well to get C++ mangling right. So I suggest using type-name strings as is done for the other standard typedefs, rather than having these macros different from all the others, even if at first you do not define all the information needed for all the other types and so do not implement itself. -- Joseph S. Myers [EMAIL PROTECTED]
Re: gcc 4.3.0 i386 default question
On Wednesday 12 March 2008, Joel Sherrill wrote: > Paul Brook wrote: > >> Since we are talking 100s of tests, it seems like it would be > >> easiest to avoid them in the scripts. I just don't know how > >> to do that. > > > > You might want to look at how the ARM NEON vector unit is handled > > (check_effective_target_arm_neon_ok and > > check_effective_target_arm_neon_hw). > > If I understand this correctly, it is checking that the > target HW actually supports the Neon extension. > Is this right? Yes. If the test application succeeds we know we can run NEON code. If it explodes we can't. > Where does this get invoked? I don't know offhand. grep is your friend :-) > I think I am on the edge of understanding a solution > path. It sounds like I need to add similar ones > for MMX, SSE, Altivec, and any other odd multilib > CPU option that the test suite hits and a particular > target CPU does not support. Right? Right. There are three possibilities: 1) The current multilib/test flags are fundmentally incompatible with the extension. In principle there's no reason why you can't have i386+SSE, so this probably doesn't apply in your case. 2) Your target nominally supports the extension, however the particular hardware used for testing does not. In this case we want to run all the compile tests, but skip the execution tests. Currently there are two ways of doing this: 2a) Put a runtime check in every single execute test. If the extension is not present then skip the actual test and pretend we succeeded. This is what x86 currently does. However in many cases this is not feasible. e.g. in a bare metal environment where the only way to test for a feature is to try it and see if your program dies. 3b) Have dejagnu do an execute test. If this fails, then skip all the other execute tests. 3) Your target hardware supports the extension. Everything just works. Paul
Re: gcc 4.3.0 i386 default question
> Joel Sherrill writes: Joel> Those all look like checks to see if the compiler itself Joel> supports Altivec -- not a run-time check on the hardware Joel> like the Neon check_effective_target_arm_neon_hw appears Joel> to be. Look at check_vmx_hw_available again. David
Re: RFC: adding knowledge of the int_fastN_t types to the compiler
On Wed, 12 Mar 2008, Ian Lance Taylor wrote:
> I don't disagree with that, but I would also like to see something
> that will not require changing every target for basic default
> behaviour.
>
> I'd like to suggest that in the absence of other information from the
> tm.h file, for N in {8,16,32,64}, where N <= UNITS_PER_WORD *
> BITS_PER_UNIT, we map int_fastN_t to int_fastM_t, where M ==
> UNITS_PER_WORD * BITS_PER_UNIT.
Given the ABI implications and the varying rules used to determine these
types on different targets, I think it would be best not to install
from GCC or define any associated internal macros for C code if
we don't have appropriate definitions of the types for the particular
target in question. We can, however, provide defaults of our choice for
targets that don't have the relevant types at all and won't be updated to
have them (unmaintained OSes, or targets with OS version numbers for old
OS versions - in the latter case, types from a newer OS version would be
an appropriate choice); it's just targets that might have them but haven't
had the relevant information recorded in GCC that I think should not have
the types defined by default in GCC. (How this relates to Fortran is up
to the Fortran maintainers.)
--
Joseph S. Myers
[EMAIL PROTECTED]
New wiki page for openmp and parallelization
I've created a new wiki page to track things we'd like to add/fix/remove to the OpenMP implementation and related things like the auto parallelizer (http://gcc.gnu.org/wiki/openmp) I've linked the page to the Google SoC projects wiki page. If you have anything that you'd been wanting to work on, feel free to add it to the list. Thanks. Diego.
Re: gcc 4.3.0 i386 default question
David Edelsohn wrote: Joel Sherrill writes: Joel> Those all look like checks to see if the compiler itself Joel> supports Altivec -- not a run-time check on the hardware Joel> like the Neon check_effective_target_arm_neon_hw appears Joel> to be. Look at check_vmx_hw_available again. Whoops. That one does indeed check it. And the RTEMS target has an ugly exception. The next set of failures below that point are not altivec related. I see a block of failures like this: FAIL: gcc.misc-tests/bprob-1.c execution: file bprob-1.gcda does not exist, -fprofile-arcs And this: FAIL: gcc.target/powerpc/405-mullhw-1.c scan-assembler mullhw Are those things which would be expected to fail on a vanilla 603e target without networking or disk? Is this another category of tests to avoid somehow? -joel David -- Joel Sherrill, Ph.D. Director of Research & Development [EMAIL PROTECTED]On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: gcc 4.3.0 i386 default question
> Joel Sherrill writes: Joel> FAIL: gcc.target/powerpc/405-mullhw-1.c scan-assembler mullhw Joel> Are those things which would be expected to fail on a vanilla Joel> 603e target without networking or disk? Joel> Is this another category of tests to avoid somehow? 405-mullhw-1.c is invoked with -mcpu=405 and directly scans the assembly language output -- does not try to create an object file or run an executable. If that fails, you should check if the RTEMS configuration somehow is inhibiting generation of the mullhwX instruction and TARGET_MULHW flag. David
Re: gcc 4.3.0 i386 default question
> David Edelsohn wrote: > >>Joel Sherrill writes: > >> > > > >Joel> Those all look like checks to see if the compiler itself > >Joel> supports Altivec -- not a run-time check on the hardware > >Joel> like the Neon check_effective_target_arm_neon_hw appears > >Joel> to be. > > > >Look at check_vmx_hw_available again. > > > Whoops. That one does indeed check it. And the RTEMS > target has an ugly exception. The next set of failures below > that point are not altivec related. I see a block of failures > like this: > > FAIL: gcc.misc-tests/bprob-1.c execution: file bprob-1.gcda does not > exist, -fprofile-arcs > > And this: > > FAIL: gcc.target/powerpc/405-mullhw-1.c scan-assembler mullhw > > Are those things which would be expected to fail on a vanilla > 603e target without networking or disk? branch probability test expect the testcase to output a profile during execution, so unless you have gcov runtime support I guess it is expected. I dunno about mullhw. Honza > > Is this another category of tests to avoid somehow? > > -joel > >David > > > > > > > -- > Joel Sherrill, Ph.D. Director of Research & Development > [EMAIL PROTECTED]On-Line Applications Research > Ask me about RTEMS: a free RTOS Huntsville AL 35805 > Support Available (256) 722-9985 >
Re: gcc 4.3.0 i386 default question
On Wed, 12 Mar 2008, David Edelsohn wrote: > > Joel Sherrill writes: > > Joel> FAIL: gcc.target/powerpc/405-mullhw-1.c scan-assembler mullhw > > Joel> Are those things which would be expected to fail on a vanilla > Joel> 603e target without networking or disk? > > Joel> Is this another category of tests to avoid somehow? > > 405-mullhw-1.c is invoked with -mcpu=405 and directly scans the > assembly language output -- does not try to create an object file or run > an executable. If that fails, you should check if the RTEMS configuration > somehow is inhibiting generation of the mullhwX instruction and > TARGET_MULHW flag. Also, if you use a multilib option in testing, that option goes on the command line *after* the options specified in dg-options. The tests may need to use dg-skip-if to skip them if any CPU option other than the one in the test is explicitly specified (so it would be tested if no explicit -mcpu option is used, or if -mcpu=405 is the multilib option being tested). -- Joseph S. Myers [EMAIL PROTECTED]
Re: gcc 4.3.0 i386 default question
David Edelsohn wrote: Joel Sherrill writes: Joel> Those all look like checks to see if the compiler itself Joel> supports Altivec -- not a run-time check on the hardware Joel> like the Neon check_effective_target_arm_neon_hw appears Joel> to be. Look at check_vmx_hw_available again. Thanks again. I have a patch to test for sse2 that I am posting to gcc-patches. Running just the vect test, I now get this on the target which seems much better. :) === gcc Summary === # of expected passes889 # of expected failures73 # of unsupported tests6 David --joel
Re: gcc 4.3.0 i386 default question
Joseph S. Myers wrote:
On Wed, 12 Mar 2008, David Edelsohn wrote:
Joel Sherrill writes:
Joel> FAIL: gcc.target/powerpc/405-mullhw-1.c scan-assembler mullhw
Joel> Are those things which would be expected to fail on a vanilla
Joel> 603e target without networking or disk?
Joel> Is this another category of tests to avoid somehow?
405-mullhw-1.c is invoked with -mcpu=405 and directly scans the
assembly language output -- does not try to create an object file or run
an executable. If that fails, you should check if the RTEMS configuration
somehow is inhibiting generation of the mullhwX instruction and
TARGET_MULHW flag.
Also, if you use a multilib option in testing, that option goes on the
command line *after* the options specified in dg-options. The tests may
need to use dg-skip-if to skip them if any CPU option other than the one
in the test is explicitly specified (so it would be tested if no explicit
-mcpu option is used, or if -mcpu=405 is the multilib option being
tested).
Since we are running on target hardware, we almost always
use explicit CPU options. In this case, it is -mcpu=603e
so that would break this. We have:
set_board_info cflags "-B${RTEMS_BSP_PATH}/lib/ -specs bsp_specs -qrtems
-mcpu=603e"
If I read you correctly, then none of these tests can pass on
this target.
If you have a patch, I will happily try it. Otherwise, you will have to
teach me to fish. :-D
--joel
--
Joseph S. Myers
[EMAIL PROTECTED]
--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED]On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
Re: gcc 4.3.0 i386 default question
Jan Hubicka wrote: David Edelsohn wrote: Joel Sherrill writes: Joel> Those all look like checks to see if the compiler itself Joel> supports Altivec -- not a run-time check on the hardware Joel> like the Neon check_effective_target_arm_neon_hw appears Joel> to be. Look at check_vmx_hw_available again. Whoops. That one does indeed check it. And the RTEMS target has an ugly exception. The next set of failures below that point are not altivec related. I see a block of failures like this: FAIL: gcc.misc-tests/bprob-1.c execution: file bprob-1.gcda does not exist, -fprofile-arcs And this: FAIL: gcc.target/powerpc/405-mullhw-1.c scan-assembler mullhw Are those things which would be expected to fail on a vanilla 603e target without networking or disk? branch probability test expect the testcase to output a profile during execution, so unless you have gcov runtime support I guess it is expected. I dunno about mullhw. There are only two as best I can tell so this isn't the worst thing contaminating the results. But if there is a way to mark that gcov is not available I would be happy to pursue implementing it or (better) testing it. --joel
Re: Possible GCC 4.3 driver regression caused by your patch
Greg Schafer wrote: The issue is now filed as http://gcc.gnu.org/PR35532 It would be appreciated if the responsible Codesourcery folks could address this regression. I will definitely look into this. (I was on vacation last week and I've been sick this week, so I haven't had a chance yet, but I will try to figure out what's going on soon.) Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
gcc-4.2-20080312 is now available
Snapshot gcc-4.2-20080312 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20080312/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.2 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch revision 133151 You'll find: gcc-4.2-20080312.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20080312.tar.bz2 C front end and core compiler gcc-ada-4.2-20080312.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20080312.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20080312.tar.bz2 C++ front end and runtime gcc-java-4.2-20080312.tar.bz2 Java front end and runtime gcc-objc-4.2-20080312.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20080312.tar.bz2The GCC testsuite Diffs from 4.2-20080305 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.2 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: [RFC] GCC caret diagnostics
On 07/03/2008, Tom Tromey <[EMAIL PROTECTED]> wrote: > > "Manuel" == Manuel López-Ibáñez <[EMAIL PROTECTED]> writes: > Manuel> The third approach would be to store an offset and when > Manuel> generating diagnostics, reopen the file, fseek to the offset > Manuel> and print that line. > > I tend to favor this, provided that the performance is not too awful. > But maybe this is painful due to iconv translation? How should a file be properly opened within GCC? I find the code in libcpp/files.c pretty confusing and also I am not interested in parsing the file, so some of the conversions it makes are probably superflous (or perhaps even impossible when calling from expand_location). > How about -fshow-caret instead of -fdiagnostics-show-caret? > (By analogy with -fshow-column.) Well, we have -fdiagnostics-show-option and -fdiagnostics-show-location. So 2 versus 1. ;-) That said, I would also prefer -fshow-option and -fshow-location. > With this implementation I think cpp will not emit caret diagnostics. > It ought to as well, IMO -- consistency is important here, I think. > Maybe now it is time to switch cpp to use gcc's diagnostic > machinery... I think all the prerequisites to this have been met, > though I am not sure. cpp has the buffer and current position available when it emits diagnostics with column information, so printing the caret is certainly possible without much hassle. I agree that switching cpp to use gcc's diagnostics will avoid code duplication and ensure consistency, yet that is an orthogonal issue, it shouldn't be a prerequisite for caret diagnostics. Cheers, Manuel.
Re: [RFC] GCC caret diagnostics
On 08/03/2008, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > > Another approach would be to only use the carets for parse errors, > which is where they are the most helpful. For a middle-end error like > "assuming signed overflow does not occur when simplifying > multiplication" a caret pointer might be more misleading than > otherwise, as one thing we know for sure is that it would not point at > a multiplication operator. > I don't get this. So, what is it pointing to? Cheers, Manuel.
Re: [RFC] GCC caret diagnostics
On 08/03/2008, Chris Lattner <[EMAIL PROTECTED]> wrote: > > clang points into the original input buffer that was lexed from. This > requires keeping the original files mapped into the address space of > the compiler. However, clang only produces diagnostics from the front- > end, not from the middle-end. So no warnings for uninitialized variables? Cheers, Manuel.
Re: [RFC] GCC caret diagnostics
On 08/03/2008, Jan Hubicka <[EMAIL PROTECTED]> wrote: > Adding support for releasing large buffers from memory and either > seeking or not displaying carrets if it turns out to be important on the > top of the in-memory implementation seems straighforward: the line > location would be anyway something like file ID+offset in the file and > it does not matter much if the underlying mechanism is memory > buffer/mmap area or seek&read. That is a good point. The underlying mechanism can be fine tuned later. What would be the main problems to get caret diagnostics in trunk? The most common issue is probably bad locations but I don't see that as a major problem. On the contrary, the only reliable way to fix this is to enable caret diagnostics, otherwise people hardly bother with the exact location. Switching CPP to use diagnostics.c would also be desirable but not essential either. I will submit an update enabling caret diagnostics in CPP. > Implementing something like file compression seem bit expensive approach > for me. Lexing+parsing is slow enough. Agreed. Cheers, Manuel.
Re: [RFC] GCC caret diagnostics
On 08/03/2008, Tom Tromey <[EMAIL PROTECTED]> wrote: > > Perhaps I was mistaken to state an implementation preference this > early, anyway. It would be fine by me to have an implementation that > works in any reasonable way. If the "don't free" approach proves too > costly, with sane API design we will know we can always rip it out and > go with "reopen and seek". > Well, like Jan said, there is no much API design going on here because we just need to pass an extra "offset" every time we put a new line in the line_map and retrieve a pointer to a string from a source location. I think all potential implementations will work with such API. Cheers, Manuel.
Re: [RFC] GCC caret diagnostics
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes: > On 08/03/2008, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: >> >> Another approach would be to only use the carets for parse errors, >> which is where they are the most helpful. For a middle-end error like >> "assuming signed overflow does not occur when simplifying >> multiplication" a caret pointer might be more misleading than >> otherwise, as one thing we know for sure is that it would not point at >> a multiplication operator. >> > > I don't get this. So, what is it pointing to? I don't know for sure. I would guess that it would point to the start of the statement in which the overflow is found. The warning is going to use the location from some statement being simplified, not from the operator. Ian
Re: [RFC] GCC caret diagnostics
On 13/03/2008, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > "Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes: > > > > On 08/03/2008, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > >> > >> Another approach would be to only use the carets for parse errors, > >> which is where they are the most helpful. For a middle-end error like > >> "assuming signed overflow does not occur when simplifying > >> multiplication" a caret pointer might be more misleading than > >> otherwise, as one thing we know for sure is that it would not point at > >> a multiplication operator. > >> > > > > I don't get this. So, what is it pointing to? > > > I don't know for sure. I would guess that it would point to the start > of the statement in which the overflow is found. The warning is going > to use the location from some statement being simplified, not from the > operator. > Why? Isn't the operator available at that point? Cheers, Manuel.
Re: [RFC] GCC caret diagnostics
On Mar 12, 2008, at 5:07 PM, Manuel López-Ibáñez wrote: On 08/03/2008, Chris Lattner <[EMAIL PROTECTED]> wrote: clang points into the original input buffer that was lexed from. This requires keeping the original files mapped into the address space of the compiler. However, clang only produces diagnostics from the front- end, not from the middle-end. So no warnings for uninitialized variables? The clang front-end generates these warnings. This means that the set of warnings produced by the compiler doesn't change as the optimizer evolves, are generally less mystifying to the user, and have perfect location info as a side effect. People who use -Werror tend to prefer when they don't get new random warnings due to a compiler upgrade. This approach is similar to what Java compilers do and frontends like EDG do (afaik). The Clang project is also growing a static analysis engine which is very adept at solving path sensitive versions of these problems, which is useful for finding deeper bugs. -Chris
Re: [RFC] GCC caret diagnostics
On 13/03/2008, Chris Lattner <[EMAIL PROTECTED]> wrote:
>
> On Mar 12, 2008, at 5:07 PM, Manuel López-Ibáñez wrote:
>
> > On 08/03/2008, Chris Lattner <[EMAIL PROTECTED]> wrote:
> >>
> >> clang points into the original input buffer that was lexed from.
> >> This
> >> requires keeping the original files mapped into the address space of
> >> the compiler. However, clang only produces diagnostics from the
> >> front-
> >> end, not from the middle-end.
> >
> > So no warnings for uninitialized variables?
>
>
> The clang front-end generates these warnings. This means that the set
> of warnings produced by the compiler doesn't change as the optimizer
> evolves, are generally less mystifying to the user, and have perfect
> location info as a side effect. People who use -Werror tend to prefer
> when they don't get new random warnings due to a compiler upgrade.
> This approach is similar to what Java compilers do and frontends like
> EDG do (afaik).
But then you don't have constant propagation and other optimisations
that remove fail positives, do you? Well, we have discussed already
doing all uninitialized warnings before optimisation but users do
complain about false positives.
For example:
void
func2 (int cond)
{
int x;
int flag = 0;
if(cond)
{
x = 1;
flag = 1;
}
foo();
if(flag)
use(x);
}
> The Clang project is also growing a static analysis engine which is
> very adept at solving path sensitive versions of these problems, which
> is useful for finding deeper bugs.
>
I guess that must take considerably more time and resources and be
redundant with some of the work of the optimisers. I guess we cannot
use such approach in GCC.
Cheers,
Manuel.
[PATCH] Fix bug on soft emulation of float point in gcc/longlong.c
There are 2 bugs existing in __udiv_qrnnd_c:
1. remainder could not be counted correctly
__r1 and __r0 are not adding enough, so I use do..while to replace
former if
2. the case of overflow of __m are not considered
so I add a couple of lines to handle it
I found the bugs from Linux kernel,
for PowerPC math-emu use __udiv_qrnnd_c to emulate float div.
I sent the patch to the maintainers of kernel, but they replied to me
that
this code came from gcc and should better keep coincident.
So I think I should send patch to here.
I don't know how to trigger __udiv_qrnnd_c in gcc.
but if the argument of __udiv_qrnnd_c are like
0x07f8 0x07f8 0x00210fff 0xc000 0x07f8,
the bug will be reproduced.
Also, you can try the program below, I have test it on Linux kernel
math-emu but haven't test on gcc.
---
#include
union fu {
unsigned int u;
float f;
};
union fu fdiv(union fu a, union fu b, union fu expected)
{
union fu z;
z.f = a.f / b.f;
printf("fdiv %08x / %08x = %08x expected %08x %s\n",
a.u, b.u, z.u, expected.u,
(z.u == expected.u) ? "(PASS)" : "(FAIL)");
printf(" %e / %e = %e\n", a.f, b.f, z.f);
}
int main()
{
union fu fa,fb,fe;
fa.u = 0xc0843fff;
fb.u = 0x80ff;
fe.u = 0x7f044000;
fdiv(fa,fb,fe);
}
--
---
gcc/longlong.h | 18 --
1 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/gcc/longlong.h b/gcc/longlong.h
index 6c24564..256399b 100644
--- a/gcc/longlong.h
+++ b/gcc/longlong.h
@@ -1368,12 +1368,15 @@ UDItype __umulsidi3 (USItype, USItype);
__q1 = (n1) / __d1;
\
__m = (UWtype) __q1 * __d0;
\
__r1 = __r1 * __ll_B | __ll_highpart (n0);
\
+if (__d0 && __q1 > __m / __d0)
\
+ do {
\
+ __q1--, __r1 += (d);
\
+ } while (__r1 >= (d));
\
if (__r1 < __m)
\
{
\
- __q1--, __r1 += (d);
\
- if (__r1 >= (d)) /* i.e. we didn't get carry when adding to __r1
*/\
- if (__r1 < __m)
\
+ do {
\
__q1--, __r1 += (d);
\
+ } while (__r1 >= (d) && __r1 < __m);
\
}
\
__r1 -= __m;
\
\
@@ -1381,12 +1384,15 @@ UDItype __umulsidi3 (USItype, USItype);
__q0 = __r1 / __d1;
\
__m = (UWtype) __q0 * __d0;
\
__r0 = __r0 * __ll_B | __ll_lowpart (n0);
\
+if (__d0 && __q0 > __m / __d0)
\
+ do {
\
+ __q0--, __r0 += (d);
\
+ } while (__r0 >= (d));
\
if (__r0 < __m)
\
{
\
- __q0--, __r0 += (d);
\
- if (__r0 >= (d))
\
- if (__r0 < __m)
\
+ do {
\
__q0--, __r0 += (d);
\
+ } while (__r0 >= (d) && __r0 < __m);
\
}
\
__r0 -= __m;
\
\
--
Re: [RFC] GCC caret diagnostics
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes: >> >> Another approach would be to only use the carets for parse errors, >> >> which is where they are the most helpful. For a middle-end error like >> >> "assuming signed overflow does not occur when simplifying >> >> multiplication" a caret pointer might be more misleading than >> >> otherwise, as one thing we know for sure is that it would not point at >> >> a multiplication operator. >> >> >> > >> > I don't get this. So, what is it pointing to? >> >> >> I don't know for sure. I would guess that it would point to the start >> of the statement in which the overflow is found. The warning is going >> to use the location from some statement being simplified, not from the >> operator. >> > > Why? Isn't the operator available at that point? The location information, if present, is technically available, but it would require some surgery to actually get it. The warning is queued up in fold_binary, which does not have access to the location and is often called in cases where there is no obvious location--because it is optimizing some other expression. The warning is not issued at that point. It is only issued later, when we know whether the folding caused some actual simplification in the statement. At that point we also don't know the specific location. As we move to tuples, we will have even less location information at this point. We will almost certainly not have the location of any operators. This is in general a good thing, as we won't be paying the memory space to carry them through the whole middle-end. Ian
Re: [RFC] GCC caret diagnostics
On Mar 12, 2008, at 9:49 PM, Manuel López-Ibáñez wrote: The clang front-end generates these warnings. This means that the set of warnings produced by the compiler doesn't change as the optimizer evolves, are generally less mystifying to the user, and have perfect location info as a side effect. People who use -Werror tend to prefer when they don't get new random warnings due to a compiler upgrade. This approach is similar to what Java compilers do and frontends like EDG do (afaik). But then you don't have constant propagation and other optimisations that remove fail positives, do you? Well, we have discussed already doing all uninitialized warnings before optimisation but users do complain about false positives. There is no right answer, and this topic has been the subject of much debate on the GCC list in the past. I really don't care to debate the merits of one approach vs the other with you, I just answered your question about what clang does. Amusingly, GCC 4.0 emitted a false positive about this example despite using the techniques you discuss, and no GCC emits any of these warnings at -O0 (which is a very common mode used when doing a majority of development for some people). The Clang project is also growing a static analysis engine which is very adept at solving path sensitive versions of these problems, which is useful for finding deeper bugs. I guess that must take considerably more time and resources and be redundant with some of the work of the optimisers. I guess we cannot use such approach in GCC. I have no opinion about the approach that you take in GCC. In practice, we have been able to do this analysis very quickly and get good results, and will continue to refine them as clang continues to mature. I personally think that it is a major problem that GCC doesn't produce these diagnostics unless optimizations are enabled, and I continue to think that having diagnostics change depending on what optimization level is enabled is bad. -Chris
Re: [PATCH] Fix bug on soft emulation of float point in gcc/longlong.c
Liu Yu <[EMAIL PROTECTED]> writes: > There are 2 bugs existing in __udiv_qrnnd_c: > > 1. remainder could not be counted correctly > __r1 and __r0 are not adding enough, so I use do..while to replace former if > > 2. the case of overflow of __m are not considered > so I add a couple of lines to handle it > > I found the bugs from Linux kernel, > for PowerPC math-emu use __udiv_qrnnd_c to emulate float div. Is the kernel code testing UDIV_NEEDS_NORMALIZATION and implementing the normalization required before calling __udiv_qrnnd_c? > I don't know how to trigger __udiv_qrnnd_c in gcc. gcc will use __udiv_qrnnd_c in -lgcc for division and modulos of 64-bit values on processors which can't do that directly and for which there is no alternate implementation in longlong.h. > but if the argument of __udiv_qrnnd_c are like > 0x07f8 0x07f8 0x00210fff 0xc000 0x07f8, > the bug will be reproduced. Those arguments to __udiv_qrnnd_c are not valid. For correct operation, the most significant bit of the last argument is required to be 1. UDIV_NEEDS_NORMALIZATION signals this fact. In gcc the required normalization is implemented before calling __udiv_qrnnd_c, in __udivmoddi4 in libgcc2.c. This normalization approach is taken, rather than introducing while loops as you suggest, because the while loops can run for quite a long time on small numbers. Ian
RE: [PATCH] Fix bug on soft emulation of float point in gcc/longlong.c
Hi Ian, Thanks a lot for your detailed explanation. > -Original Message- > From: Ian Lance Taylor [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 13, 2008 1:45 PM > To: Liu Yu > Cc: gcc@gcc.gnu.org > Subject: Re: [PATCH] Fix bug on soft emulation of float point > in gcc/longlong.c > > Liu Yu <[EMAIL PROTECTED]> writes: > > > There are 2 bugs existing in __udiv_qrnnd_c: > > > > 1. remainder could not be counted correctly > > __r1 and __r0 are not adding enough, so I use do..while to replace > > former if > > > > 2. the case of overflow of __m are not considered so I add > a couple of > > lines to handle it > > > > I found the bugs from Linux kernel, > > for PowerPC math-emu use __udiv_qrnnd_c to emulate float div. > > Is the kernel code testing UDIV_NEEDS_NORMALIZATION and > implementing the normalization required before calling __udiv_qrnnd_c? > > > > I don't know how to trigger __udiv_qrnnd_c in gcc. > > gcc will use __udiv_qrnnd_c in -lgcc for division and modulos > of 64-bit values on processors which can't do that directly > and for which there is no alternate implementation in longlong.h. > > > > but if the argument of __udiv_qrnnd_c are like > > 0x07f8 0x07f8 0x00210fff 0xc000 0x07f8, the > bug will > > be reproduced. > > Those arguments to __udiv_qrnnd_c are not valid. For correct > operation, the most significant bit of the last argument is > required to be 1. UDIV_NEEDS_NORMALIZATION signals this > fact. In gcc the required normalization is implemented > before calling __udiv_qrnnd_c, in __udivmoddi4 in libgcc2.c. > > This normalization approach is taken, rather than introducing > while loops as you suggest, because the while loops can run > for quite a long time on small numbers. > > Ian >
Re: [RFC] GCC caret diagnostics
On 13/03/2008, Chris Lattner <[EMAIL PROTECTED]> wrote: > > There is no right answer, and this topic has been the subject of much > debate on the GCC list in the past. I really don't care to debate the > merits of one approach vs the other with you, I just answered your > question about what clang does. Of course. I didn't want to get into a debate. I was just trying to figure out how clang addressed the problem of false positives (or alternatively the problem of users complaining about them). Thanks for taking the time to elaborate. > Amusingly, GCC 4.0 emitted a false positive about this example despite > using the techniques you discuss, and no GCC emits any of these > warnings at -O0 (which is a very common mode used when doing a > majority of development for some people). Oh, we certainly do worse than that. See PR 179. I hope you didn't interpret my comments as criticism of LLVM. Certainly all approaches have its drawbacks and the one in GCC have a lot of drawbacks plus deficiencies. > I have no opinion about the approach that you take in GCC. In > practice, we have been able to do this analysis very quickly and get > good results, and will continue to refine them as clang continues to > mature. Hum, that is very interesting because doing these warnings in the middle-end causes so many false positives/negatives anyway that perhaps a limited static analysis in the front-end achieves better results. And the only argument then would be the overhead of the static analysis. If that is not an issue either, then it seems a very attractive approach indeed. Do you use the static analysis for other things (other warnings, early optimizations/folding)? There are many other warnings that would be noticeably enhanced by some dataflow in the front-end. > I personally think that it is a major problem that GCC doesn't produce > these diagnostics unless optimizations are enabled, and I continue to > think that having diagnostics change depending on what optimization > level is enabled is bad. I think everybody agrees on both. Yet the alternatives to these issues right now in GCC are building SSA at -O0 and moving the warnings earlier in the pipeline, respectively. The former results in slower/bigger -O0 compiler. Both would generate much more false positives, and there have been a few patches proposing moving them even later to avoid some false positives. I guess the static analysis in the front-end was discarded because of compile-time concerns, but if you don't see that (and clang seems to be much faster than GCC), then it may be worth reconsidering it. Cheers, Manuel.
