Re: complex arithmetic in gcc (and various standards)
On Monday 02 October 2006 19:39, Gabriel Dos Reis wrote: > "Joseph S. Myers" <[EMAIL PROTECTED]> writes: > | On Mon, 2 Oct 2006, Jan van Dijk wrote: > | > On Monday 02 October 2006 12:57, Joseph S. Myers wrote: > | > > On Mon, 2 Oct 2006, Jan van Dijk wrote: [...] > | > Triggered by 1*(Inf,0) = (Inf,NaN), I looked inside the compiler for > | > the first > | > | (Inf,NaN) is a valid complex infinity just as (Inf,0) is; see G.3. > > I think his concern is about the evaluation of 1 * (Inf, 0). 1*(Inf,0) gives (Inf,NaN) with the recent gcc version (with -O0 or arguments unknown at compile time). I now understand that this is correct: according to the standard a complex number is Inf if one of the components is Inf (even if the other is NaN). It is also *unfortunate*: std::abs(1*(Inf,0)) -> nan, where Inf would be expected by the user; 1/std::abs(1*(Inf,0)) ->nan, where 0 would be expected. The result is that (for example) in the evaluation of small-argument expansions of special functions special-case-handling is required to avoid the generation of NaNs for 'too-low' |z|, where Inf or 0 is expected. Note that the analogous expressions for (IEE 754) floating point numbers work as expected when overflow/underflow happens. The bottom line is that the concept of infinity/nan is of limited practical value for complex numbers. Doing multiplications in terms of polar representations would solve all such problems for complex numbers, BTW. Anyway, this behaviour is standard-conformant, if we assume that C++ is supposed to mimmick C in the behaviour of complex numbers (where is that written, BTW?) People doing scientific computing in C(++) shall have to live with this, I am afraid. More serious is the fact that the compiler translates 1*(Inf,Inf) into (NaN,NaN). This is plain wrong, but, as Joseph mentioned, the solution requires the implementation of mixed-mode MULT_EXPRESSIONS, since apparently 1*(Inf,Inf) == (Inf,Inf) != (1,0)*(Inf,Inf)==(NaN,NaN). Is the latter project suitable for a motivated newby? I am willing to spend some time and effort into this issue, but will definitely need guidance from time to time. With kind regards, Jan van Dijk. -- If I haven't seen further, it is by standing in the footprints of giants Dr. Jan van Dijk Eindhoven University of Technology Department of Applied Physics Group Elementary Processes in Gas Discharges Room Na-2.09 P.O. Box 513 5600 MB Eindhoven The Netherlands tel. +31 40 247 57 65
Re: complex arithmetic in gcc (and various standards)
On Tue, 3 Oct 2006, Jan van Dijk wrote: > More serious is the fact that the compiler translates 1*(Inf,Inf) into > (NaN,NaN). This is plain wrong, but, as Joseph mentioned, the solution > requires the implementation of mixed-mode MULT_EXPRESSIONS, since apparently > > 1*(Inf,Inf) == (Inf,Inf) != (1,0)*(Inf,Inf)==(NaN,NaN). In C99 mode, the libgcc function should be called to ensure that you don't get (NaN,NaN), as per the Annex G algorithm. > Is the latter project suitable for a motivated newby? I am willing to spend > some time and effort into this issue, but will definitely need guidance from > time to time. Instead of trying mixed-type expressions, call save_expr on both real and complex operands, multiply the real and imaginary parts separately and then form a COMPLEX_EXPR of the results. Likewise for addition, subtraction and complex/real division (real/complex division can continue to be handled like complex/complex). You'll need to change how build_binary_op uses c_common_type since in these cases you'll no longer want to convert both operands to that type - the complex operand should be converted to it, but the real operand to the corresponding real type. -- Joseph S. Myers [EMAIL PROTECTED]
Re: complex arithmetic in gcc (and various standards)
On Tuesday 03 October 2006 11:08, Joseph S. Myers wrote: > On Tue, 3 Oct 2006, Jan van Dijk wrote: > > More serious is the fact that the compiler translates 1*(Inf,Inf) into > > (NaN,NaN). This is plain wrong, but, as Joseph mentioned, the solution > > requires the implementation of mixed-mode MULT_EXPRESSIONS, since > > apparently > > > > 1*(Inf,Inf) == (Inf,Inf) != (1,0)*(Inf,Inf)==(NaN,NaN). > > In C99 mode, the libgcc function should be called to ensure that you don't > get (NaN,NaN), as per the Annex G algorithm. I just noticed that g++ was fixed wrt this issue somewhere between 4.1.0 and HEAD.In the tree dump with -O0 with 4.1.0, I noticed an expanded form of the multiplication, without handling of the (NaN,NaN) case. With HEAD __muldc3 is called and the result is correct, indeed. > > Is the latter project suitable for a motivated newby? I am willing to > > spend some time and effort into this issue, but will definitely need > > guidance from time to time. > > Instead of trying mixed-type expressions, call save_expr on both real and > complex operands, multiply the real and imaginary parts separately and > then form a COMPLEX_EXPR of the results. Likewise for addition, > subtraction and complex/real division (real/complex division can continue > to be handled like complex/complex). You'll need to change how > build_binary_op uses c_common_type since in these cases you'll no longer > want to convert both operands to that type - the complex operand should be > converted to it, but the real operand to the corresponding real type. That is a lot for me to digest, but gives me nice starting point for studying gcc. Thank you. Regards, Jan van Dijk.
Internationalization of Ada.Directories (MinGW)
Hello. In Japanese version Windows, package Ada.Directories often raises Name_Error with DBCS-filename. I was shocked that Get_Next_Entry reported error when reading dir. I looked for the reason and found gcc/ada/mingw32.h. #define GNAT_UNICODE_SUPPORT was commented out. If GNAT_UNICODE_SUPPORT was defined, GNAT runtime use W-version API and "String" type has UTF-8. I consented. But, GNAT_UNICODE_SUPPORT was NOT defined(it's default), adaint.c, GNAT.Directory_Operations use C runtime. C runtime takes filenames as DBCS, not UTF-8. But, Ada.Directories.Validity(Mingw32-ver) always thinks filenames as UTF-8. It's reason of Name_Error. I want to correct this problem, but I do not understand the policy. If Ada.Directories must take filenames as UTF-8, it's necessary to insert the character-code conversion. If Ada.Directories can take filenames according to the locale, The condition of a-dirval-mingw.adb should be made loose. And, if all String should always be UTF-8, the correction is needed Ada.Text_IO(System.File_IO), etc packages used C runtime directly like fopen, regardless of GNAT_UNICODE_SUPPORT. Thanks. YT
Re: complex arithmetic in gcc (and various standards)
On Monday 02 October 2006 20:53, Gabriel Dos Reis wrote:
[...]
>
> | the result of the "same" multiplication considered as complex *
> | complex (vs complex * real) has a different sign for the zero
> | imaginary component.
>
> Thanks for the example. I'm not sure this was anticipated by the C++
> specification. I suspect I have to raise this on LWG.
>
Note that this problem also makes the two common complex initialisation
strategies behave differently: in the second case below the sign of the
imaginary part of z has disappeared:
#include
#include
int main() {
double complex z;
double x=1.0;
double y=-0.0;
__real__ z = x;
__imag__ z = y;
printf("%e %e\n", creal(z), cimag(z));
z = x + y*I;
printf("%e %e\n", creal(z), cimag(z));
return 0;
}
[EMAIL PROTECTED]:../bessel $ gcc t16.c -O0 && ./a.out
1.00e+00 -0.00e+00
1.00e+00 0.00e+00
Another effect is that: when z==(1,-0.0), we get: creal(z) + cimag(z)*I = (1,
+0.0). Since 0==-0, formally this is not in conflict with footnote 166 on
page 179 of ISO/IEC 9899:TC2, but well ... the standard is not too friendly
for users of complex functions with branch cuts.
Regards,
Jan.
Stepping down as SH maintainer
I have decided to accept employment at ARC International, so effective 11th December 2006, I will step down as an active SH maitainer. I might still do some GCC patch reviews if time allows, but I expect to submit only patches to the SH port - if any - as part of multi-platform patches with the intention to improve ARC support. Depending on the progress of the Copyright Assignment paperwork till the 11th December, I will adjust my MAINTAINERS files entrys to Write After Approval or waiting for paperwork. I hope my new position will allow me to make a more constructive contribution to GCC than I did in the last year. In my remaining time at ST, I will try to tie up some loose ends in the SH port and the infrastructure it relies on, or where these ends are too frayed to be tied up in the remaining time with the available resources, at least point out where they are, and any ideas I have how to fix them.
gcj internals documentation
Hi, I'm having difficulty finding any documentation for the gcj internals, apart from the source, Chapter 12 of the gcj manual, a couple of Linux Journal articles, and some papers from 1997. Is there anything else that describes the workings of the gcj front-end and run-time libraries. I'm particularly interested is descriptions of how the synchronization works. Thanks Paul -- Paul Biggar [EMAIL PROTECTED]
Re: C++ Frontend and combining files
On Oct 2, 2006, at 9:24 PM, Brendon Costa wrote: * Modify the ASM spec used for compiling .s files into .o files so that it will somehow rename the /tmp/foo1.s.edc files to /tmp/gah1.o.edc files where /tmp/gah1.o is the name of the output .o file that comes from the assembler. * Write a wrapper for ld, that looks for .edc files for each .o file given and merges them before calling the real ld. This would also look for .edc files associated with any libraries being statically linked with and merge those as well. Hum, on second thought, why not just encode the information you want into the .o file. Just put it into a special section, in whatever format you like, the linker will combine them, no additional files, .a files work, ld -r foo.o bar.o -o new.o works and so on. You can then fish the information back out from the .o files or the executable as you want.
Re: Darwin as primary platform
David Edelsohn <[EMAIL PROTECTED]> writes: > Bugzilla currently shows 64 open bugs with a darwin listed as the > target; another 5 Altivec bugs. I am concerned about the effect on > releases from increasing the priority of many of those bugs to P1 if > Darwin is a primary platform. Which of these bugs do you think would be P1s? > Also, there also are a few Bugzilla bugs assigned to Apple > developers that have not seen any progress and some features > contributed by Apple don't appear to receive a lot of support. Could you be more specific? I am not aware of any problems. Possibly these bugzilla bugs should be unassigned.
Re: unwind-dw2-fde-darwin.c changes
[EMAIL PROTECTED] (Jack Howarth) writes:
> Geoff,
> Can you explain why we don't have...
>
> Index: unwind-dw2-fde-darwin.c
> ===
> --- unwind-dw2-fde-darwin.c (revision 117350)
> +++ unwind-dw2-fde-darwin.c (working copy)
> @@ -61,7 +61,7 @@ struct mach_header;
> struct mach_header_64;
> extern char *getsectdatafromheader (struct mach_header*, const char*,
> const char *, unsigned long *);
> -extern char *getsectdatafromheader_64 (struct mach_header*, const char*,
> +extern char *getsectdatafromheader_64 (struct mach_header_64*, const char*,
> const char *, unsigned long *);
>
> /* This is referenced from KEYMGR_GCC3_DW2_OBJ_LIST. */
> @@ -157,8 +157,12 @@ examine_objects (void *pc, struct dwarf_
>
> /* For ppc only check whether or not we have __DATA eh frames. */
> #ifdef __ppc__
> +#if __LP64__
> + fde = getsectdatafromheader ((struct mach_header_64 *)image->mh,
> "__DATA", "__eh_frame", &sz);
> +#else
> fde = getsectdatafromheader (image->mh, "__DATA", "__eh_frame", &sz);
> #endif
> +#endif
>
> if (fde == NULL)
> {
>
> Thanks in advance for any clarifications.
__ppc__ and __LP64__ should not be defined together. On Darwin,
__ppc__ means 32-bit powerpc.
Re: Darwin as primary platform
> > David Edelsohn <[EMAIL PROTECTED]> writes: > > > Bugzilla currently shows 64 open bugs with a darwin listed as the > > target; another 5 Altivec bugs. I am concerned about the effect on > > releases from increasing the priority of many of those bugs to P1 if > > Darwin is a primary platform. > > Which of these bugs do you think would be P1s? PR 25127 is an example already which was marked as a P1. It was only found recently by me that this is a regression and only because I decided to look at it after another report came in. On the other hand there are three ABI problems with the FSF GCC compared to Apple's GCC. PR 18742, 23067, and 25630. -- Pinski
Re: C++ Frontend and combining files
Mike Stump wrote: > Hum, on second thought, why not just encode the information you want > into the .o file. Just put it into a special section, in whatever > format you like, the linker will combine them, no additional files, .a > files work, ld -r foo.o bar.o -o new.o works and so on. You can then > fish the information back out from the .o files or the executable as you > want. > That sounds like a great idea! I guess I need to start researching how to embed data into .o files... Is looking at debug data generated by the C++ front-end a good place to start? I assume this can be done by adding certain directives to the assembler source file (.s), since the assembler generates the .o files. Anyhow, I will continue to look further into this and may get back with more questions :-) later. Thanks for the idea. Thanks, Brendon.
Re: C++ Frontend and combining files
Brendon Costa wrote: > Mike Stump wrote: >> Hum, on second thought, why not just encode the information you want >> into the .o file. Just put it into a special section, in whatever >> format you like, the linker will combine them, no additional files, .a >> files work, ld -r foo.o bar.o -o new.o works and so on. You can then >> fish the information back out from the .o files or the executable as you >> want. >> > > That sounds like a great idea! I guess I need to start researching how > to embed data into .o files... Is looking at debug data generated by > the C++ front-end a good place to start? > > I assume this can be done by adding certain directives to the > assembler source file (.s), since the assembler generates the .o files. > > Anyhow, I will continue to look further into this and may get back > with more questions :-) later. Thanks for the idea. > > > Thanks, > Brendon. > Alright after briefly looking into some info on the binutils and GNU as I have a few thoughts. I think I could insert my data into the .s file into a particular section. I am not sure if I should create my own named section used for meta-data (Only available using COFF from what I understand using the as .section directive) or maybe I could insert it into the .data section with a particular identifier. I don't understand this completely though. If I place it into the .data section then would it then be possible to have conflicts with code symbols? I am also not yet sure how I would extract this data from the objects (Using libbfd somehow I will have to look further into it). What would be the best directive to use to insert binary data into the section? I was thinking at first of using the .ascii directive as my file is just a plain text file. However in the future I would like to convert the file into a binary format and could not find a directive that would allow me to insert binary data simply. I would also need to figure out how to modify the front end to insert this data into the .s file. I have not looked into that yet so it may be as simple as inserting a node into the tree, but I don't know the details yet. -- Option 2 -- The other option I could think of is to generate a .edc file from the front end as normal along with the .s file, then run the assembler to produce the .o file from the .s file, and then get the driver to run some "embedding compiler" program that uses libbfd to embed the .edc file into the .o file before it is passed onto the linker. This could be a more "generic" approach that could be used elsewhere for embedding meta-data into object files using gcc, thought I am not sure of the details yet. This "embedding compiler" would simply place meta-data into object files using libbfd and would be driven by the gcc driver. I have never used libbfd before, and from what I understand it would still have the same problems of needing to decide which section to place the meta-data into. Where would be the best section to place this sort of data? Also does using ar/ld on resulting .o files filter out any sections they don't know about? Or do they always just include sections into the resulting archive/executable even if the sections are non-standard containing meta-data that they don't understand? Sorry for the emails, I just find it helpful discussing these issues with others. It has produced great results so far in the idea of embedding the meta-data into the .o files and I am fairly new to compiler development and so don't understand this stuff completely. Thanks, Brendon.
Re: C++ Frontend and combining files
On Oct 3, 2006, at 5:43 PM, Brendon Costa wrote:
I think I could insert my data into the .s file into a particular
section. I am not sure if I should create my own named section
I'd recommend .comment probably. If you want to productize it, add
your own, and put it into your linker script.
If I place it into the .data section then would it then be possible to
have conflicts with code symbols?
Only if you add a symbol that can have conflicts with code symbols,
see the language spec for which symbols you can and cannot use. __foo
$bar is safe for example to use. printf generally isn't.
I am also not yet sure how I would extract this data from the
objects (Using libbfd somehow I will have to look further into it).
man objcopy, man objdump
objdump --section=.comment --full-contents a.out
for example.
What would be the best directive to use to insert binary data into the
section?
If you have a word
.word 0
see the assembler manual for other possibilities.
.string "Hello world\n\0"
might also work, if you have strings. Also, you can ask the compiler
how to output data by using the -S flag.
Also does using ar/ld on resulting .o files filter out any sections
they don't know about?
as no. ld -r, no. Final link, probably. --print-map for example
might tell you some of the information you might need. Look at the
default linker script. I can use use emacs /usr/bin/ld to view mine
for example. :-)
You can google("ld options dump liinker script") and find out that ld
--verbose is an easier way to figure out the default linker script for
GNU ld.
Or do they always just include sections into the resulting archive/
executable even if the sections are non-standard containing meta-
data that they don't understand?
.comment is standard on my platform.
recombination?
So let's say that I have an instruction that the combiner finds. For instance: "mac": (set (match_operand:SI 0 "register_operand" "=r") (plus:SI (mult:SI (match_operand:SI 1 "register_operand" "r") (match_operand:SI 2 "register_operand" "r")) (match_operand:SI 3 "register_operand" "0"))) Combine picks this up, no problem. Let's say I also have the instruction "mac_s16": (set (match_operand:SI 0 "register_operand" "=r") (ashiftrt:SI (plus:SI (mult:SI (match_operand:SI 1 "register_operand" "r") (match_operand:SI 2 "register_operand" "r")) (match_operand:SI 3 "register_operand" "0")) (const_int 16))) Combine seems to not pick this up. I think it is the combination of: * Combine doesn't pick tuples of three to attempt to combine, so it would never pick mult, plus, and ashift to try together. * Combine doesn't put an instruction back to try and combine again, so once I get "mac" combine doesn't try again to find "mac_s16". Is my understanding correct? Is there anything that can be done? Would it be safe to run combine again after running it the first time? Or does something happen that makes this problematic? -- Why are ``tolerant'' people so intolerant of intolerant people?
testsuite exp programming issue
I am trying to adjust the current gcc/gcc/testsuite/lib/objc.exp
to allow it to build against the gnu-objc runtime library in the
case of -m64 compiles on Darwin8. Unfortunately, I've hit a brick
wall in terms of catching the instance of '-m64' being passed to
the compiler flags. Normally I do this with...
make -k check RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'"
so it comes in on the variations in runtest. The patch should
look like...
--- /Users/howarth/gcc/gcc/testsuite/lib/objc.exp 2006-08-13
14:20:19.0 -0400
+++ objc.exp2006-10-03 22:29:54.0 -0400
@@ -130,7 +130,14 @@
global shlib_ext
set ld_library_path ".:${objc_libgcc_s_path}"
+if { [istarget "powerpc-apple-darwin8"] && \
+[regexp ".*-m64.*" "$(options)"] } {
+ lappend options "cflags=-fgnu-runtime"
+ lappend options "libs=-lobjc-gnu"
+ } else {
lappend options "libs=-lobjc"
+}
+
set shlib_ext [get_shlib_extension]
verbose "shared lib extension: $shlib_ext"
however this doesn't manage to detect when '-m64'
is being used in the compile flags. Does anyone have
any hints on how to change...
+[regexp ".*-m64.*" "$(options)"] } {
to properly catch the instances when -m64 is being used
in the compilations? Thanks in advance for any help.
Jack
Re: C++ Frontend and combining files
Thanks for all the help. I have tried a few things now and decided to try and create a new section called .edoc I tried using .comment on my machine, however there is already data in .comment on my machine and it will make parsing the data from the section to find my data a little more difficult as it becomes intermixed. At least for the moment I don't think it necessary to play with linker scripts. I tried a few things on my machine: * linking single .o file to create exe * linking multiple .o files to create exe * creating .a file from multiple .o files and linking that to create exe where each .o file had a defined .edoc section with some data in it and in all cases the resulting exe has a .edoc section with the data from each .o file .edoc section appended to each other. This works well for my purposes (Though I guess I( should try on a few different platforms as I really would like to support at least NetBSD, Linux and Win32 using MinGW. The last is most likely a problem platform but ill see how I go). However when I tried using the .comment section, I ended up with my data intermixed within a number of other comments that I did not insert. I would need to find some way of separating my data from the other inserted data which starts to get more complex. By using my own section I don't think I need to define any symbols or sync headers for my data or anything like that. Thanks again for the help. I now have somethings I can try. Brendon.
Re: testsuite exp programming issue
>
> I am trying to adjust the current gcc/gcc/testsuite/lib/objc.exp
> to allow it to build against the gnu-objc runtime library in the
> case of -m64 compiles on Darwin8. Unfortunately, I've hit a brick
> wall in terms of catching the instance of '-m64' being passed to
> the compiler flags. Normally I do this with...
>
> make -k check RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'"
>
> so it comes in on the variations in runtest. The patch should
> look like...
I would suggest instead to disable the testcases instead of just
testing the GNU runtime, it is useless really because some testcases
are compile time only which test the Next runtime explictly and will
fail if you test them using the GNU runtime.
-- Pinski
Re: testsuite exp programming issue
Andrew, I'll double check but I don't think the testcases which use -fnext-runtime were failing when I had these changes hardwired in for -m64. The reason is that the -fgnu-runtime appears on the cflags and gets overridden when a specific testcase appends -fnext-runtime because that appears last. I'll double check and post the results of a run with these flags hardcoded. Jack
Re: testsuite exp programming issue
Andrew,
I think I have this puzzled out now. The correct patch is...
Index: lib/obj-c++.exp
===
--- lib/obj-c++.exp (revision 117423)
+++ lib/obj-c++.exp (working copy)
@@ -282,8 +282,16 @@ proc obj-c++_target_compile { source des
global ALWAYS_OBJCXXFLAGS
global OBJCXX_UNDER_TEST
global shlib_ext
+global compiler_flags
+if { [istarget "powerpc-apple-darwin8"] && \
+[string match "*-m64 *" $compiler_flags] } {
+ lappend options "libs=-fgnu-runtime"
+ lappend options "libs=-lobjc-gnu"
+} else {
lappend options "libs=-lobjc"
+}
+
set shlib_ext [get_shlib_extension]
verbose "shared lib extension: $shlib_ext"
Index: lib/objc.exp
===
--- lib/objc.exp(revision 117423)
+++ lib/objc.exp(working copy)
@@ -128,9 +128,18 @@ proc objc_target_compile { source dest t
global ld_library_path
global objc_libgcc_s_path
global shlib_ext
+global compiler_flags
set ld_library_path ".:${objc_libgcc_s_path}"
+
+if { [istarget "powerpc-apple-darwin8"] && \
+[string match "*-m64 *" $compiler_flags] } {
+ lappend options "libs=-fgnu-runtime"
+ lappend options "libs=-lobjc-gnu"
+} else {
lappend options "libs=-lobjc"
+}
+
set shlib_ext [get_shlib_extension]
verbose "shared lib extension: $shlib_ext"
Note that the placement of -fgnu-runtime on the libs
flags is by design. Otherwise for those tests that
null out the compiler flags, the -fgnu-runtime flag
is lost. With these patches, I get the following on
my G5...
# make -k check-objc RUNTESTFLAGS="--target_board=unix'{-m64}'"
test -d testsuite || mkdir testsuite
test -d testsuite/objc || mkdir testsuite/objc
(rootme=`${PWDCMD-pwd}`; export rootme; \
srcdir=`cd ../../gcc-4.2-20060930/gcc; ${PWDCMD-pwd}` ; export srcdir ; \
cd testsuite/objc; \
rm -f tmp-site.exp; \
sed '/set tmpdir/ s|testsuite|testsuite/objc|' \
< ../../site.exp > tmp-site.exp; \
/bin/sh ${srcdir}/../move-if-change tmp-site.exp site.exp; \
EXPECT=`if [ -f ${rootme}/../expect/expect ] ; then echo
${rootme}/../expect/expect ; else echo expect ; fi` ; export EXPECT ; \
if [ -f ${rootme}/../expect/expect ] ; then \
TCL_LIBRARY=`cd .. ; cd ${srcdir}/../tcl/library ; ${PWDCMD-pwd}` ; \
export TCL_LIBRARY ; fi ; \
`if [ -f ${srcdir}/../dejagnu/runtest ] ; then echo
${srcdir}/../dejagnu/runtest ; else echo runtest; fi` --tool objc
--target_board=unix'{-m64}')
WARNING: Couldn't find the global config file.
Test Run By root on Tue Oct 3 23:31:10 2006
Native configuration is powerpc-apple-darwin8
=== objc tests ===
Schedule of variations:
unix/-m64
Running target unix/-m64
Using /sw/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /sw/share/dejagnu/config/unix.exp as generic interface file for target.
Using
/sw/src/fink.build/gcc4-4.1.-20060930/gcc-4.2-20060930/gcc/testsuite/config/default.exp
as tool-and-target-specific interface file.
Running
/sw/src/fink.build/gcc4-4.1.-20060930/gcc-4.2-20060930/gcc/testsuite/objc/compile/compile.exp
...
Running
/sw/src/fink.build/gcc4-4.1.-20060930/gcc-4.2-20060930/gcc/testsuite/objc/execute/exceptions/exceptions.exp
...
Running
/sw/src/fink.build/gcc4-4.1.-20060930/gcc-4.2-20060930/gcc/testsuite/objc/execute/execute.exp
...
Running
/sw/src/fink.build/gcc4-4.1.-20060930/gcc-4.2-20060930/gcc/testsuite/objc.dg/dg.exp
...
FAIL: objc.dg/bitfield-2.m execution test
FAIL: objc.dg/const-str-10.m scan-assembler
.long\t__NSConstantStringClassReference\n\t.long\t.*\n\t.long\t5\n\t.data
FAIL: objc.dg/const-str-11.m scan-assembler
.long\t__XStrClassReference\n\t.long\t.*\n\t.long\t5\n\t.data
FAIL: objc.dg/const-str-3.m (test for excess errors)
WARNING: objc.dg/const-str-3.m compilation failed to produce executable
FAIL: objc.dg/const-str-9.m scan-assembler
.long\t__NSConstantStringClassReference\n\t.long\t.*\n\t.long\t5\n\t.data
FAIL: objc.dg/encode-1.m execution test
FAIL: objc.dg/encode-5.m (test for excess errors)
FAIL: objc.dg/encode-8.m execution test
FAIL: objc.dg/headers.m (test for excess errors)
FAIL: objc.dg/isa-field-1.m (test for excess errors)
FAIL: objc.dg/lookup-1.m (test for excess errors)
FAIL: objc.dg/next-runtime-1.m scan-assembler L_OBJC_MODULES:\n[ \t]*.long\t6\n
FAIL: objc.dg/no-extra-load.m (test for excess errors)
ERROR: objc.dg/no-extra-load.m: error executing dg-final: couldn't open
"no-extra-load.s": no such file or directory
FAIL: objc.dg/stret-2.m scan-assembler objc_msgSend_stret
FAIL: objc.dg/stret-2.m scan-assembler objc_msgSendSuper_stret
FAIL: objc.dg/stret-2.m scan-assembler-not objc_msgSend[^_S]
FAIL: objc.dg/stret-2.m scan-assembler-not objc_msgSendSuper[^_]
FAIL: objc.dg/symtab-1.m scan-assembler
L_OBJC_SYMBOLS.*:\n\t.long\t0\n\t.long\t0\n\t.short\t2\n\t.short\t0\n\t.l
Re: recombination?
"Erich Plondke" <[EMAIL PROTECTED]> writes: > * Combine doesn't pick tuples of three to attempt to combine, so it > would never > pick mult, plus, and ashift to try together. Actually, combine does try to put pairs and triplets of instructions together. It won't do four instructions at once, though. > * Combine doesn't put an instruction back to try and combine again, > so once I get "mac" > combine doesn't try again to find "mac_s16". No, actually, it will do this. It is possible to build up combinations through a sequence of insn patterns. I don't know why it didn't combine for you. You will have look at the RTL debugging dump to figure it out. A common problem is that combine will normally only combine two or three SETs if the destination register of the earlier one dies in the later one. (Technically it will try to putting together a PARALLEL of the combined instruction and the initial SET, but this rarely matches.) Another occasional problem is that combine will only do a combination if the resulting instruction is cheaper, so you have to make sure that your costs are right. Ian
Re: testsuite exp programming issue
On Wed, 2006-10-04 at 00:30 -0400, Jack Howarth wrote: > FAIL: objc.dg-struct-layout-encoding-1/t001_main.m execution test If these (being objc.dg-struct-layout-encoding-1/*) are all failing, then something is wrong. I bet natural alignment is not set correctly for 64bit. But these were added so we know that we are getting the wrong sizeof/alignof inside the library. The correct fix is to help me work on the libobjc_noheaders branch which will fix these the correct way. Oh, they are not going to be fixed for 4.2 so it is better just to xfail them. Thanks, Andrew Pinski
