Re: For testing: full __float128 patch

[FX]

GCC >= 4.5 is needed. I'll add a check to libquad's configure.

FX

Le 29 août 2010 à 02:56, Steve Kargl  a 
écrit :

> On Sat, Aug 28, 2010 at 05:47:28PM -0700, Steve Kargl wrote:
>> On Sun, Aug 29, 2010 at 01:24:47AM +0200, FX wrote:
>>> Before I submit it officially for review, I want this patch to get some 
>>> exposure while I clean up a few remaining dusty corners. To test the patch 
>>> on x86_64-linux, proceed as follows:
>>> 
>>>  -- Get libquad from http://quatramaran.ens.fr/~coudert/tmp/libquad.tar.bz2 
>>> , then ./configure --prefix=/foo && make && make install 
>>>  -- Build GCC with the extra configure argument: --with-quad=/foo (to be 
>>> given to the toplevel configure command, like --with-gmp, nothing fancy)
>>> 
>>> Things to test in particular:
>>> 
>>>  -- I've tested this on linux and Mac OS; although it's pretty much 
>>> OS-insensitive, does it work on things like FreeBSD and Windows?
>>>  -- check carefully I/O support; in particular, the "output formatting" 
>>> (i.e. writing out the values) involves a wrapper of my own around the gdtoa 
>>> code, which was a bit painful to write, so bugs might have crawled in there
>>> 
>>> 
>> 
>> On i386-*-freebsd,
>> 
>> ./configure --prefix=$HOME/work
>> gmake
>> ...
>> 
>> -O2 -MT libgfortran_io.lo -MD -MP -MF .deps/libgfortran_io.Tpo -c -o 
>> libgfortran_io.lo libgfortran_io.c
>> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -g -O2 -MT libgfortran_io.lo 
>> -MD -MP -MF .deps/libgfortran_io.Tpo -c libgfortran_io.c  -fPIC -DPIC -o 
>> .libs/libgfortran_io.o
>> In file included from libgfortran_io.c:1:
>> quad.h:8: error: unable to emulate 'TC'
> 
> gcc, here, is the FreeBSD system compiler.
> gcc (GCC) 4.2.1 20070719  [FreeBSD]
> 
> If I set my path to include ~/work/bin (where the 4.6.0 gcc lives)
> as the first directory to search, libquad builds fine.  So, what
> is the minimum required gcc version needs to build libquad?
> 
> -- 
> Steve

Re: Guidance needed: hi-level steps to track an object until its destruction

[Uday P. Khedker]

I am not sure that is easily feasible. I would believe it is impossible.

Within the compiler (or inside a GCC plugin, or inside a GCC extension
coded in MELT), you probably are able change/inspect C++ classes&  every
other declaration any compiler is tracking. You are also able to find
every occurrence of variables containing a pointer to such classes.




However, you are apparently willing to track a single *instance* of such
a class, and this instance is in the execution of the compiled program
[not inside the compiler]. This means that you are able to deal with all



To put it in other words: Here the issue is seeking runtime information at
compile time. An object is a run time entity. At compile time, we only see
the class. However, we also see the statements that create an object and
manipulate it. Although it is not possible to track each object distinctly,
a compile time approximation is certainly possible. And that is where creativity
in compiler research lies. The better the approximations, the better the gains.
For example, all objects that get created by a given statement can be treated
alike. There is no way of distinguishing between them at compile time, but 
perhaps
there is no need to do so because all of them are likely to be treated alike
at run time. if an object O1 and O2 are created by the same statement, asking
the question whether a method m1 is invoked for O1 does not need us to 
distinguish
between O1 and O2.

To summarize, a good approximation is indeed possible at compile time.



the aliasing&  pointer equivalence issues (a task known to be
impossible). How can the compiler surely know that pointer p in [a
particular instruction of] method YourClass::foo() is never (or
sometimes, or always) pointing to the same instance -in the running
process of the compiled program- as pointer q in method yourclass::bar()


Basile, you keep mentioning that English is not your first language and I
appreciate your politeness for reminding the reader for that (English is not
the first language for me too). It is in that light that I would like to point
out that your use of word "impossible" is a little too strong. Perhaps you mean
difficult. It is impossible if you want exact information. However, if
imprecisions can be tolerated for some gains, excellent approximations are
possible _within_ a procedure body which is what Jeff asked for, to begin with.

We have been working on this problem (pointer analysis) for a while but
are quite far from production implementation. Our ideas now seem to mature
a bit and whenever we have a conference paper, I will be happy to share it
with the gcc folks.


Or maybe you want to instrument your compiler so that for every code
emitted for method yourclass::gee() you add a first block which checks
that the this reciever is not a given pointer.

In other words&  C++ parlance, you could (this is doable, but not
trivial) hack the compiler so that at the start of every method (i.e.
member function in C++) the equivalent of the following C++ code has
been magically added

   extern "C" YourClass* hunted_yourclass_pointer;
   extern "C" void some_error_routine(void);

   if (this == hunted_yourclass_pointer)
 some_error_routine();


This is a very good way of paraphrasing the "ideal" requirement.

Regards,

Uday.

Re: Guidance needed: hi-level steps to track an object until its destruction

[J Decker]

Just out of curiosity - isn't this what C# does with objects?  would
it perhaps be something like that in how mcs (mono) builds objects and
tracks their lifespan?

On Sun, Aug 29, 2010 at 4:43 AM, Uday P. Khedker  wrote:
>
>> I am not sure that is easily feasible. I would believe it is impossible.
>>
>> Within the compiler (or inside a GCC plugin, or inside a GCC extension
>> coded in MELT), you probably are able change/inspect C++ classes&  every
>> other declaration any compiler is tracking. You are also able to find
>> every occurrence of variables containing a pointer to such classes.
>
>>
>> However, you are apparently willing to track a single *instance* of such
>> a class, and this instance is in the execution of the compiled program
>> [not inside the compiler]. This means that you are able to deal with all
>
>
> To put it in other words: Here the issue is seeking runtime information at
> compile time. An object is a run time entity. At compile time, we only see
> the class. However, we also see the statements that create an object and
> manipulate it. Although it is not possible to track each object distinctly,
> a compile time approximation is certainly possible. And that is where
> creativity
> in compiler research lies. The better the approximations, the better the
> gains.
> For example, all objects that get created by a given statement can be
> treated
> alike. There is no way of distinguishing between them at compile time, but
> perhaps
> there is no need to do so because all of them are likely to be treated alike
> at run time. if an object O1 and O2 are created by the same statement,
> asking
> the question whether a method m1 is invoked for O1 does not need us to
> distinguish
> between O1 and O2.
>
> To summarize, a good approximation is indeed possible at compile time.
>
>
>> the aliasing&  pointer equivalence issues (a task known to be
>> impossible). How can the compiler surely know that pointer p in [a
>> particular instruction of] method YourClass::foo() is never (or
>> sometimes, or always) pointing to the same instance -in the running
>> process of the compiled program- as pointer q in method yourclass::bar()
>
> Basile, you keep mentioning that English is not your first language and I
> appreciate your politeness for reminding the reader for that (English is not
> the first language for me too). It is in that light that I would like to
> point
> out that your use of word "impossible" is a little too strong. Perhaps you
> mean
> difficult. It is impossible if you want exact information. However, if
> imprecisions can be tolerated for some gains, excellent approximations are
> possible _within_ a procedure body which is what Jeff asked for, to begin
> with.
>
> We have been working on this problem (pointer analysis) for a while but
> are quite far from production implementation. Our ideas now seem to mature
> a bit and whenever we have a conference paper, I will be happy to share it
> with the gcc folks.
>
>> Or maybe you want to instrument your compiler so that for every code
>> emitted for method yourclass::gee() you add a first block which checks
>> that the this reciever is not a given pointer.
>>
>> In other words&  C++ parlance, you could (this is doable, but not
>> trivial) hack the compiler so that at the start of every method (i.e.
>> member function in C++) the equivalent of the following C++ code has
>> been magically added
>>
>>   extern "C" YourClass* hunted_yourclass_pointer;
>>   extern "C" void some_error_routine(void);
>>
>>   if (this == hunted_yourclass_pointer)
>>     some_error_routine();
>
> This is a very good way of paraphrasing the "ideal" requirement.
>
> Regards,
>
> Uday.
>

Re: Guidance needed: hi-level steps to track an object until its destruction

[Basile Starynkevitch]

On Sun, 2010-08-29 at 17:13 +0530, Uday P. Khedker wrote:
> > I am not sure that is easily feasible. I would believe it is impossible.
> >
> > Within the compiler (or inside a GCC plugin, or inside a GCC extension
> > coded in MELT), you probably are able change/inspect C++ classes&  every
> > other declaration any compiler is tracking. You are also able to find
> > every occurrence of variables containing a pointer to such classes.
> 
> >
> > However, you are apparently willing to track a single *instance* of such
> > a class, and this instance is in the execution of the compiled program
> > [not inside the compiler]. This means that you are able to deal with all
> 
> 
> To put it in other words: Here the issue is seeking runtime information at
> compile time. An object is a run time entity. At compile time, we only see
> the class. However, we also see the statements that create an object and
> manipulate it. Although it is not possible to track each object distinctly,
> a compile time approximation is certainly possible. And that is where 
> creativity
> in compiler research lies. The better the approximations, the better the 
> gains.
> For example, all objects that get created by a given statement can be treated
> alike. There is no way of distinguishing between them at compile time, but 
> perhaps
> there is no need to do so because all of them are likely to be treated alike
> at run time. if an object O1 and O2 are created by the same statement, asking
> the question whether a method m1 is invoked for O1 does not need us to 
> distinguish
> between O1 and O2.
> 
> To summarize, a good approximation is indeed possible at compile time.
> 
> 
> > the aliasing&  pointer equivalence issues (a task known to be
> > impossible). How can the compiler surely know that pointer p in [a
> > particular instruction of] method YourClass::foo() is never (or
> > sometimes, or always) pointing to the same instance -in the running
> > process of the compiled program- as pointer q in method yourclass::bar()
> 
> Basile, you keep mentioning that English is not your first language and I
> appreciate your politeness for reminding the reader for that (English is not
> the first language for me too). It is in that light that I would like to point
> out that your use of word "impossible" is a little too strong. Perhaps you 
> mean
> difficult. It is impossible if you want exact information. 

Yes, that is what I meant. Any compile-time tool produces some
abstraction.

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 mine, sont seulement les miennes} ***

Re: Guidance needed: hi-level steps to track an object until its destruction

[Uday P. Khedker]

Unfortunately I am not aware of C# implementation so can't respond to this...

Uday.

J Decker wrote, On Sunday 29 August 2010 05:32 PM:

Just out of curiosity - isn't this what C# does with objects?  would
it perhaps be something like that in how mcs (mono) builds objects and
tracks their lifespan?

On Sun, Aug 29, 2010 at 4:43 AM, Uday P. Khedker  wrote:



I am not sure that is easily feasible. I would believe it is impossible.

Within the compiler (or inside a GCC plugin, or inside a GCC extension
coded in MELT), you probably are able change/inspect C++ classes&every
other declaration any compiler is tracking. You are also able to find
every occurrence of variables containing a pointer to such classes.




However, you are apparently willing to track a single *instance* of such
a class, and this instance is in the execution of the compiled program
[not inside the compiler]. This means that you are able to deal with all



To put it in other words: Here the issue is seeking runtime information at
compile time. An object is a run time entity. At compile time, we only see
the class. However, we also see the statements that create an object and
manipulate it. Although it is not possible to track each object distinctly,
a compile time approximation is certainly possible. And that is where
creativity
in compiler research lies. The better the approximations, the better the
gains.
For example, all objects that get created by a given statement can be
treated
alike. There is no way of distinguishing between them at compile time, but
perhaps
there is no need to do so because all of them are likely to be treated alike
at run time. if an object O1 and O2 are created by the same statement,
asking
the question whether a method m1 is invoked for O1 does not need us to
distinguish
between O1 and O2.

To summarize, a good approximation is indeed possible at compile time.



the aliasing&pointer equivalence issues (a task known to be
impossible). How can the compiler surely know that pointer p in [a
particular instruction of] method YourClass::foo() is never (or
sometimes, or always) pointing to the same instance -in the running
process of the compiled program- as pointer q in method yourclass::bar()


Basile, you keep mentioning that English is not your first language and I
appreciate your politeness for reminding the reader for that (English is not
the first language for me too). It is in that light that I would like to
point
out that your use of word "impossible" is a little too strong. Perhaps you
mean
difficult. It is impossible if you want exact information. However, if
imprecisions can be tolerated for some gains, excellent approximations are
possible _within_ a procedure body which is what Jeff asked for, to begin
with.

We have been working on this problem (pointer analysis) for a while but
are quite far from production implementation. Our ideas now seem to mature
a bit and whenever we have a conference paper, I will be happy to share it
with the gcc folks.


Or maybe you want to instrument your compiler so that for every code
emitted for method yourclass::gee() you add a first block which checks
that the this reciever is not a given pointer.

In other words&C++ parlance, you could (this is doable, but not
trivial) hack the compiler so that at the start of every method (i.e.
member function in C++) the equivalent of the following C++ code has
been magically added

   extern "C" YourClass* hunted_yourclass_pointer;
   extern "C" void some_error_routine(void);

   if (this == hunted_yourclass_pointer)
 some_error_routine();


This is a very good way of paraphrasing the "ideal" requirement.

Regards,

Uday.

Re: For testing: full __float128 patch

[Steve Kargl]

On Sun, Aug 29, 2010 at 09:01:49AM +0200, FX wrote:
> GCC >= 4.5 is needed. I'll add a check to libquad's configure.
> 
> FX
> 

Further testing on i386-*-freebsd runs into undefined symbols.

libquad.so: undefined reference to `__getf2'
libquad.so: undefined reference to `__eqtf2'
libquad.so: undefined reference to `__addtf3'
libquad.so: undefined reference to `__floatsitf'
libquad.so: undefined reference to `__trunctfxf2'
libquad.so: undefined reference to `__divtf3'
libquad.so: undefined reference to `__letf2'
libquad.so: undefined reference to `__unordtf2'
libquad.so: undefined reference to `__fixtfdi'
libquad.so: undefined reference to `__fixtfsi'
libquad.so: undefined reference to `__lttf2'
libquad.so: undefined reference to `__netf2'
libquad.so: undefined reference to `__extendxftf2'
libquad.so: undefined reference to `__extenddftf2'
libquad.so: undefined reference to `__multf3'
libquad.so: undefined reference to `__gttf2'
libquad.so: undefined reference to `__subtf3'
libgfortran.so: undefined reference to `__floatunditf'
libquad.so: undefined reference to `__trunctfdf2'


AFAICT, these should come from libgcc_s.so.1, but for whatever
reason these are missing.  I have been unable to find how
to induce gcc to build the required files. 

-- 
Steve

gcc-4.3-20100829 is now available

[gccadmin]

Snapshot gcc-4.3-20100829 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20100829/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch 
revision 163629

You'll find:

 gcc-4.3-20100829.tar.bz2 Complete GCC (includes all of below)

  MD5=bd7ca621d03b53ecd7ea987d9113263e
  SHA1=17f6648504acaa175845f1bcacac00d23957d94c

 gcc-core-4.3-20100829.tar.bz2C front end and core compiler

  MD5=22d379e0c3e1a97910a087c58c7e3043
  SHA1=d28da7dd1d080a2c49f0f4eacd62ee4cc4688d50

 gcc-ada-4.3-20100829.tar.bz2 Ada front end and runtime

  MD5=1822a16ddab567e2c5413f8b52a542f8
  SHA1=65ce74f6438ff30cf635cc0fb5febd502e80544f

 gcc-fortran-4.3-20100829.tar.bz2 Fortran front end and runtime

  MD5=9afdba2feafe18b355b59ff8c21e6951
  SHA1=2094769df0ce7064d5c1198bb90dc7d4587ec4e8

 gcc-g++-4.3-20100829.tar.bz2 C++ front end and runtime

  MD5=f76d114ebb0cbcecf74f4897fbc1a77e
  SHA1=cca0aa12958dfa04598cf3b387f72997d9982958

 gcc-java-4.3-20100829.tar.bz2Java front end and runtime

  MD5=7a1b88bf0faeb7d94de6ded4deb01d69
  SHA1=f23c297a151b276526834db930b08626941b8bf4

 gcc-objc-4.3-20100829.tar.bz2Objective-C front end and runtime

  MD5=bf79bb2190f436458c2c996e32d8bc8f
  SHA1=318270d5d165a37ee9103321e6deb315d88c6495

 gcc-testsuite-4.3-20100829.tar.bz2   The GCC testsuite

  MD5=7ae2514bfd86d01452a0a25121ebd280
  SHA1=a59773b30f00723eb4c2838d1a942302fc1ff4d0

Diffs from 4.3-20100822 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.3
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: For testing: full __float128 patch

[Uros Bizjak]

Hello!

> On Sun, Aug 29, 2010 at 09:01:49AM +0200, FX wrote:
> > GCC >= 4.5 is needed. I'll add a check to libquad's configure.
> > 
> > FX
> > 
> 
> Further testing on i386-*-freebsd runs into undefined symbols.
> 
> libquad.so: undefined reference to `__getf2'
> libquad.so: undefined reference to `__eqtf2'
> libquad.so: undefined reference to `__addtf3'
> libquad.so: undefined reference to `__floatsitf'
> libquad.so: undefined reference to `__trunctfxf2'
> libquad.so: undefined reference to `__divtf3'
> libquad.so: undefined reference to `__letf2'
> libquad.so: undefined reference to `__unordtf2'
> libquad.so: undefined reference to `__fixtfdi'
> libquad.so: undefined reference to `__fixtfsi'
> libquad.so: undefined reference to `__lttf2'
> libquad.so: undefined reference to `__netf2'
> libquad.so: undefined reference to `__extendxftf2'
> libquad.so: undefined reference to `__extenddftf2'
> libquad.so: undefined reference to `__multf3'
> libquad.so: undefined reference to `__gttf2'
> libquad.so: undefined reference to `__subtf3'
> libgfortran.so: undefined reference to `__floatunditf'
> libquad.so: undefined reference to `__trunctfdf2'
> 
> 
> AFAICT, these should come from libgcc_s.so.1, but for whatever
> reason these are missing.  I have been unable to find how
> to induce gcc to build the required files. 

Try to build gcc with attached patch...

Uros.
Index: config.gcc
===
--- config.gcc  (revision 163630)
+++ config.gcc  (working copy)
@@ -3485,6 +3485,9 @@
i[34567]86-*-cygwin* | i[34567]86-*-mingw* | x86_64-*-mingw*)
tmake_file="${tmake_file} i386/t-fprules-softfp 
soft-fp/t-softfp"
;;
+   i[34567]86-*-freebsd* | x86_64-*-freebsd*)
+   tmake_file="${tmake_file} i386/t-fprules-softfp 
soft-fp/t-softfp"
+   ;;
ia64*-*-linux*)
tmake_file="${tmake_file} ia64/t-fprules-softfp 
soft-fp/t-softfp"
;;

Re: For testing: full __float128 patch

[Steve Kargl]

On Sun, Aug 29, 2010 at 10:48:46PM +0200, Uros Bizjak wrote:
> Hello!
> 
> > On Sun, Aug 29, 2010 at 09:01:49AM +0200, FX wrote:
> > > GCC >= 4.5 is needed. I'll add a check to libquad's configure.
> > > 
> > > FX
> > > 
> > 
> > Further testing on i386-*-freebsd runs into undefined symbols.
> > 
> > libquad.so: undefined reference to `__getf2'
> > libquad.so: undefined reference to `__eqtf2'
> > libquad.so: undefined reference to `__addtf3'
> > libquad.so: undefined reference to `__floatsitf'
> > libquad.so: undefined reference to `__trunctfxf2'
> > libquad.so: undefined reference to `__divtf3'
> > libquad.so: undefined reference to `__letf2'
> > libquad.so: undefined reference to `__unordtf2'
> > libquad.so: undefined reference to `__fixtfdi'
> > libquad.so: undefined reference to `__fixtfsi'
> > libquad.so: undefined reference to `__lttf2'
> > libquad.so: undefined reference to `__netf2'
> > libquad.so: undefined reference to `__extendxftf2'
> > libquad.so: undefined reference to `__extenddftf2'
> > libquad.so: undefined reference to `__multf3'
> > libquad.so: undefined reference to `__gttf2'
> > libquad.so: undefined reference to `__subtf3'
> > libgfortran.so: undefined reference to `__floatunditf'
> > libquad.so: undefined reference to `__trunctfdf2'
> > 
> > 
> > AFAICT, these should come from libgcc_s.so.1, but for whatever
> > reason these are missing.  I have been unable to find how
> > to induce gcc to build the required files. 
> 
> Try to build gcc with attached patch...
> 

Thanks for the patch.  It is clearly a step in the right
direction.  Unfortunately, my build dies with fixtfti.c,
fixunstfti.c, floattitf.c, and floatuntitf.c, which I 
assume are used with conversions involving TI and TF modes.
If I use #if 0 ... #endif to block out the code in 
those files, my build proceeds to libgomp, which dies with
only two missing symbols,

/usr/home/kargl/gcc/obj4x/./gcc/libgcc_s.so: undefined reference to `__fabstf2'
/usr/home/kargl/gcc/obj4x/./gcc/libgcc_s.so: undefined reference to 
`__copysigntf3'

I suppose this means that on FreeBSD, I need to enable TI mode
as well as TF.

-- 
Steve

Re: 2010 GCC and GNU Toolchain Developers' Summit

[NightStrike]

On Thu, Aug 12, 2010 at 4:22 PM, Toon Moene  wrote:
> Andrew J. Hutton wrote:
>
>> The annual GCC & GNU Toolchain Developers’ Summit brings together the core
>> development team of the GNU Compiler Collection with those working on the
>> other toolchain components to discuss the state of the art. We focus on
>> providing a vendor neutral environment to encourage open dialog, technology
>> demonstrations, as well as long term technical roadmap development.
>>
>> The 2010 Summit will be taking place in Ottawa, Canada from October 25th
>> to 27th and located in the SITE building at the uOttawa campus in the
>> central core of the city.
>>
>> The CFP is now available at http://www.gccsummit.org/2010/cfp.php and
>> additional information is available on the Summit website at
>> http://www.gccsummit.org.
>
> Thanks for the invitation.  I'd like to join - unfortunately, I do not have
> a good subject for a talk.
>
> Perhaps some from the gfortran effort would like to give a talk.  As far  as
> I can see I can support one person financially (trip from Europe to Ottawa
> vice versa and stay in "Les Suites").

Only a gfortran person?  Because I'd like to nominate Kai Tietz for
that, if he's willing to accept.

gcc-4.5.1 failing test: FAIL: abi_check

[Tom Browder]

I posted this earlier on gcc-help but no solutions that worked.

After a good build of gcc-4.5.1 I did 'make check' (several times
now).  I only get one failure for languages c,c++,fortran.

Portion of test results showing failure:

Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file
for target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using /disk3/extsrc/gcc-4.5.1/libstdc++-v3/testsuite/config/default.exp
as tool-and-target-specific interface file.
Running /disk3/extsrc/gcc-4.5.1/libstdc++-v3/testsuite/libstdc++-abi/abi.exp ...
FAIL: abi_check

I searched the test results at
 and found similar failures
but I haven't found any discussion on the gcc list since 2009-10.

Any ideas?

Thanks.

-Tom

Thomas M. Browder, Jr.
Niceville, Florida
USA

Re: For testing: full __float128 patch

[Uros Bizjak]

On Mon, Aug 30, 2010 at 1:47 AM, Steve Kargl
 wrote:

>> > Further testing on i386-*-freebsd runs into undefined symbols.
>> >
>> > libquad.so: undefined reference to `__getf2'
>> > libquad.so: undefined reference to `__eqtf2'
>> > libquad.so: undefined reference to `__addtf3'
>> > libquad.so: undefined reference to `__floatsitf'
>> > libquad.so: undefined reference to `__trunctfxf2'
>> > libquad.so: undefined reference to `__divtf3'
>> > libquad.so: undefined reference to `__letf2'
>> > libquad.so: undefined reference to `__unordtf2'
>> > libquad.so: undefined reference to `__fixtfdi'
>> > libquad.so: undefined reference to `__fixtfsi'
>> > libquad.so: undefined reference to `__lttf2'
>> > libquad.so: undefined reference to `__netf2'
>> > libquad.so: undefined reference to `__extendxftf2'
>> > libquad.so: undefined reference to `__extenddftf2'
>> > libquad.so: undefined reference to `__multf3'
>> > libquad.so: undefined reference to `__gttf2'
>> > libquad.so: undefined reference to `__subtf3'
>> > libgfortran.so: undefined reference to `__floatunditf'
>> > libquad.so: undefined reference to `__trunctfdf2'
>> >
>> >
>> > AFAICT, these should come from libgcc_s.so.1, but for whatever
>> > reason these are missing.  I have been unable to find how
>> > to induce gcc to build the required files.
>>
>> Try to build gcc with attached patch...
>>
>
> Thanks for the patch.  It is clearly a step in the right
> direction.  Unfortunately, my build dies with fixtfti.c,
> fixunstfti.c, floattitf.c, and floatuntitf.c, which I
> assume are used with conversions involving TI and TF modes.
> If I use #if 0 ... #endif to block out the code in
> those files, my build proceeds to libgomp, which dies with
> only two missing symbols,
>
> /usr/home/kargl/gcc/obj4x/./gcc/libgcc_s.so: undefined reference to 
> `__fabstf2'
> /usr/home/kargl/gcc/obj4x/./gcc/libgcc_s.so: undefined reference to 
> `__copysigntf3'
>
> I suppose this means that on FreeBSD, I need to enable TI mode
> as well as TF.

Oh, additional patch for libgcc is also needed. Attached patch will
enable filtering out TImode on 32bits and will also enable fallbacks
for the two missing functions, so no need for any other changes.

Can you please regression test these two patches on freebsd (32 and 64 bit)?

Uros.
Index: config.host
===
--- config.host (revision 163630)
+++ config.host (working copy)
@@ -608,7 +608,8 @@
   i[34567]86-*-linux* | x86_64-*-linux* | \
   i[34567]86-*-gnu* | \
   i[34567]86-*-solaris2* | \
-  i[34567]86-*-cygwin* | i[34567]86-*-mingw* | x86_64-*-mingw*)
+  i[34567]86-*-cygwin* | i[34567]86-*-mingw* | x86_64-*-mingw* | \
+  i[34567]86-*-freebsd* | x86_64-*-freebsd*)
if test "${host_address}" = 32; then
tmake_file="${tmake_file} t-softfp 
i386/${host_address}/t-fprules-softfp"
fi

Re: gcc-4.5.1 failing test: FAIL: abi_check

[Jonathan Wakely]

On 30 August 2010 02:59, Tom Browder wrote:
> I posted this earlier on gcc-help but no solutions that worked.
>
> After a good build of gcc-4.5.1 I did 'make check' (several times
> now).  I only get one failure for languages c,c++,fortran.
>
> Portion of test results showing failure:
>
> Running target unix
> Using /usr/share/dejagnu/baseboards/unix.exp as board description file
> for target.
> Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
> Using /disk3/extsrc/gcc-4.5.1/libstdc++-v3/testsuite/config/default.exp
> as tool-and-target-specific interface file.
> Running /disk3/extsrc/gcc-4.5.1/libstdc++-v3/testsuite/libstdc++-abi/abi.exp 
> ...
> FAIL: abi_check
>
> I searched the test results at
>  and found similar failures
> but I haven't found any discussion on the gcc list since 2009-10.
>
> Any ideas?

Look in ${TARGET}/libstdc++-v3/testsuite/libstdc++.log to see details
of the failure and try asking on the libstdc++ list.