Re: get_ref_base_and_extent() semantics
On Fri, Dec 12, 2008 at 12:29 AM, Martin Jambor wrote: > Hi, > > today I have encountered an unpleasant problem with the function > get_ref_base_and_extent() when it claimed a known and constant offset > for the expression insn_4(D)->u.fld[arg.82_3].rt_rtvec. (arg being a > default_def parameter of the function, insn is an rtx). Moreover, it > also returned constant size and max_size, all three equal to 64 > (bits). > > This is certainly wrong (I believe the function got confused by > unions) but after looking at the function and what it did in debugger, > I grew unsure what the expected behavior is. The two alternatives I > consider possibly correct are returned offset equal to -1 or, > alternatively, offset equal to the offset of the array (+ offset of > rt_rtvec which is zero) and max_size equal either to the size of the > array or -1 if it is unknown. > > At the moment, the function never returns offset equal to -1, the > comment above it does not even mention such possibility and, from the > limited research I did, its callers do not expect and check for it. > However, at the same time, the special handling of non-constants in > array indices after the label "done" does not trigger in this > particular case (here I suspect the unions come to play because it is > the last part of the conjunction that evaluates to false). > > Which (or what else) is the correct semantics of the function? Both > make sense to me (I would prefer the former but I suspect other users > rely on the latter). What would be the correct fix, when a union > field is itself a record ending with a variable-length array? How > much would I pessimize things if I just returned -1 max_size if both a > non-constant index and a union was encountered? > > Or did I miss something else? The function is supposed to return -1 for max_size in case the access accesses a variable array index of an array of unknown size. insn_4(D)->u.fld[arg.82_3].rt_rtvec accesses struct rtvec_def -- in which case the access _does_ have known size (an int plus one rtx pointer). But maybe I am missing context here? Richard. > Thanks a lot in advance, > > Martin >
Re: get_ref_base_and_extent() semantics
> On Fri, Dec 12, 2008 at 12:29 AM, Martin Jambor wrote: > > Hi, > > > > today I have encountered an unpleasant problem with the function > > get_ref_base_and_extent() when it claimed a known and constant offset > > for the expression insn_4(D)->u.fld[arg.82_3].rt_rtvec. (arg being a > > default_def parameter of the function, insn is an rtx). Moreover, it > > also returned constant size and max_size, all three equal to 64 > > (bits). > > > > This is certainly wrong (I believe the function got confused by > > unions) but after looking at the function and what it did in debugger, > > I grew unsure what the expected behavior is. The two alternatives I > > consider possibly correct are returned offset equal to -1 or, > > alternatively, offset equal to the offset of the array (+ offset of > > rt_rtvec which is zero) and max_size equal either to the size of the > > array or -1 if it is unknown. > > > > At the moment, the function never returns offset equal to -1, the > > comment above it does not even mention such possibility and, from the > > limited research I did, its callers do not expect and check for it. > > However, at the same time, the special handling of non-constants in > > array indices after the label "done" does not trigger in this > > particular case (here I suspect the unions come to play because it is > > the last part of the conjunction that evaluates to false). > > > > Which (or what else) is the correct semantics of the function? Both > > make sense to me (I would prefer the former but I suspect other users > > rely on the latter). What would be the correct fix, when a union > > field is itself a record ending with a variable-length array? How > > much would I pessimize things if I just returned -1 max_size if both a > > non-constant index and a union was encountered? > > > > Or did I miss something else? > > The function is supposed to return -1 for max_size in case the access > accesses a variable array index of an array of unknown size. > > insn_4(D)->u.fld[arg.82_3].rt_rtvec accesses struct rtvec_def -- in which > case the access _does_ have known size (an int plus one rtx pointer). > But maybe I am missing context here? Hmm, isn't this the usual problem with arrays running past the end of sturcture? I guess we need to special case these for needs of SRA as you can't easilly know size of the array even if it is explicitely written in the program. We similarly special case those in VRP, right? Jan > > Richard. > > > Thanks a lot in advance, > > > > Martin > >
Re: get_ref_base_and_extent() semantics
On Fri, Dec 12, 2008 at 11:59 AM, Jan Hubicka wrote: >> On Fri, Dec 12, 2008 at 12:29 AM, Martin Jambor wrote: >> > Hi, >> > >> > today I have encountered an unpleasant problem with the function >> > get_ref_base_and_extent() when it claimed a known and constant offset >> > for the expression insn_4(D)->u.fld[arg.82_3].rt_rtvec. (arg being a >> > default_def parameter of the function, insn is an rtx). Moreover, it >> > also returned constant size and max_size, all three equal to 64 >> > (bits). >> > >> > This is certainly wrong (I believe the function got confused by >> > unions) but after looking at the function and what it did in debugger, >> > I grew unsure what the expected behavior is. The two alternatives I >> > consider possibly correct are returned offset equal to -1 or, >> > alternatively, offset equal to the offset of the array (+ offset of >> > rt_rtvec which is zero) and max_size equal either to the size of the >> > array or -1 if it is unknown. >> > >> > At the moment, the function never returns offset equal to -1, the >> > comment above it does not even mention such possibility and, from the >> > limited research I did, its callers do not expect and check for it. >> > However, at the same time, the special handling of non-constants in >> > array indices after the label "done" does not trigger in this >> > particular case (here I suspect the unions come to play because it is >> > the last part of the conjunction that evaluates to false). >> > >> > Which (or what else) is the correct semantics of the function? Both >> > make sense to me (I would prefer the former but I suspect other users >> > rely on the latter). What would be the correct fix, when a union >> > field is itself a record ending with a variable-length array? How >> > much would I pessimize things if I just returned -1 max_size if both a >> > non-constant index and a union was encountered? >> > >> > Or did I miss something else? >> >> The function is supposed to return -1 for max_size in case the access >> accesses a variable array index of an array of unknown size. >> >> insn_4(D)->u.fld[arg.82_3].rt_rtvec accesses struct rtvec_def -- in which >> case the access _does_ have known size (an int plus one rtx pointer). >> But maybe I am missing context here? > > Hmm, isn't this the usual problem with arrays running past the end of > sturcture? No, get_ref_base_and_extent handles those fine (it is supposed to set max_size to -1 in this case). > I guess we need to special case these for needs of SRA as you can't > easilly know size of the array even if it is explicitely written in the > program. Of course, just bail out if max_size is -1. The problem Martin is seeing is that it isn't -1 for some reason. Martin, are you asking get_ref_base_and_extent for only a part of an access? Richard.
Re: get_ref_base_and_extent() semantics
Hi,
On Fri, Dec 12, 2008 at 12:26:38PM +0100, Richard Guenther wrote:
> On Fri, Dec 12, 2008 at 11:59 AM, Jan Hubicka wrote:
> >> On Fri, Dec 12, 2008 at 12:29 AM, Martin Jambor wrote:
> >> > Hi,
> >> >
> >> > today I have encountered an unpleasant problem with the function
> >> > get_ref_base_and_extent() when it claimed a known and constant offset
> >> > for the expression insn_4(D)->u.fld[arg.82_3].rt_rtvec. (arg being a
> >> > default_def parameter of the function, insn is an rtx). Moreover, it
> >> > also returned constant size and max_size, all three equal to 64
> >> > (bits).
> >> >
> >> > This is certainly wrong (I believe the function got confused by
> >> > unions) but after looking at the function and what it did in debugger,
> >> > I grew unsure what the expected behavior is. The two alternatives I
> >> > consider possibly correct are returned offset equal to -1 or,
> >> > alternatively, offset equal to the offset of the array (+ offset of
> >> > rt_rtvec which is zero) and max_size equal either to the size of the
> >> > array or -1 if it is unknown.
> >> >
> >> > At the moment, the function never returns offset equal to -1, the
> >> > comment above it does not even mention such possibility and, from the
> >> > limited research I did, its callers do not expect and check for it.
> >> > However, at the same time, the special handling of non-constants in
> >> > array indices after the label "done" does not trigger in this
> >> > particular case (here I suspect the unions come to play because it is
> >> > the last part of the conjunction that evaluates to false).
> >> >
> >> > Which (or what else) is the correct semantics of the function? Both
> >> > make sense to me (I would prefer the former but I suspect other users
> >> > rely on the latter). What would be the correct fix, when a union
> >> > field is itself a record ending with a variable-length array? How
> >> > much would I pessimize things if I just returned -1 max_size if both a
> >> > non-constant index and a union was encountered?
> >> >
> >> > Or did I miss something else?
> >>
> >> The function is supposed to return -1 for max_size in case the access
> >> accesses a variable array index of an array of unknown size.
> >>
> >> insn_4(D)->u.fld[arg.82_3].rt_rtvec accesses struct rtvec_def -- in which
> >> case the access _does_ have known size (an int plus one rtx pointer).
> >> But maybe I am missing context here?
> >
> > Hmm, isn't this the usual problem with arrays running past the end of
> > sturcture?
>
> No, get_ref_base_and_extent handles those fine (it is supposed to set
> max_size to -1 in this case).
>
> > I guess we need to special case these for needs of SRA as you can't
> > easilly know size of the array even if it is explicitely written in the
> > program.
>
> Of course, just bail out if max_size is -1. The problem Martin is seeing
> is that it isn't -1 for some reason. Martin, are you asking
> get_ref_base_and_extent
> for only a part of an access?
I don't know what you mean by a partial access, the gimple statement
this expression comes from is:
D.10261_5 = insn_4(D)->u.fld[arg.82_3].rt_rtvec;
I simply grabbed the rhs and fed it to get_ref_base_and_extent().
I agree the function should return -1 max_size in the case of a
variable indexing into an array that might have unknown size. The
problem is how the function identifies such arrays. The idea is
simple, these are arrays at the end of the whole aggregate and thus
the hitherto calculated offset + max_size give exactly that, the size
of the whole aggregate.
However, this does not work if we have unions within the structure. A
simple example would be:
struct a
{
union
{
struct
{
int a;
int var_array[1];
} x;
struct
{
int a,b,c,d,e,f,g,h,i,j;
} y;
} z;
} a;
In this particular case, the ofset of var_array + its max_size (the
size of its element, as the function computes it, this is something I
also do not really understand) is not equal to the size of the whole
structure, because the other union component is way larger. Therefore
the final part of the following conjunction evaluates to false:
if (seen_variable_array_ref
&& maxsize != -1
&& host_integerp (TYPE_SIZE (TREE_TYPE (exp)), 1)
&& bit_offset + maxsize
== (signed)TREE_INT_CST_LOW (TYPE_SIZE (TREE_TYPE (exp
maxsize = -1;
Note that exp TREE_TYPE (exp) is now the type of the all-encompassing
most-ouward aggregate. And thus maxsize is not set to -1.
I believe a simple solution would be to ahve a nother flag to be set
when processing component_ref with a union as its zeroth argument and
always return maxsize of -1 if both seen_variable_array_ref and this
flag is set. It is not optimal because the union field might be a
structure with an array in it but not a
Re: [PATCH, DARWIN] fix emutls exports in libgcc_s10.{4,5}.dylib
Iain,
In a perfect world, the real solution to this would be for
Apple to create a new libgcc_s.10.6.dylib which contained the
missing symbols for the newer FSF gcc releases. However since
Apple won't touch GPLv3, this is impossible since it would
require their adopting the libgcc from gcc 4.3 or 4.4 for
Snow Leopard.
Jack
On Thu, Dec 11, 2008 at 05:29:16PM +, IainS wrote:
>
> On 11 Dec 2008, at 13:51, Jack Howarth wrote:
>
>> On Thu, Dec 11, 2008 at 12:38:11PM +, IainS wrote:
>> ...
>>>
>>> I have a hunch that this is, at least partially, the origin of
>>> sporadic
>>> failures in crayptr2 (which has been one of the very few tests using
>>> tls
>>> so far - because all the rest have been UNSUPPORTED by the fails in
>>> dg
>>> target supports).
>> ...
>>
>> No. The random failures in crayptr2 are due to multiple threads
>> reading
>> an offset value of 0 and is fixed by the proposed patch...
>>
>> http://gcc.gnu.org/bugzilla/attachment.cgi?id=16879
>
> actually, the deeper one digs ...
>
> it seems that libgomp is not being built with tls emulation.
>
> (for exactly the same reasons - the configure test fails with the
> unresolved __emutls... symbol)
>
> from libgomp/config.h
> /* Define to 1 if the target assembler supports thread-local storage. */
> /* #undef HAVE_CC_TLS */
>
>
>
> /* Define to 1 if the target supports thread-local storage. */
> /* #undef HAVE_TLS */
>
> and libgomp/config.log
>
> tchCS/gcc-440-install/powerpc-apple-darwin8.11.0/sys-include -o conftest
> -g -O2 -pthread conftest.c >&5
> /usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/ld: Undefined symbols:
> ___emutls_get_address
> collect2: ld returned 1 exit status
> configure:17892: $? = 1
> configure: program exited with status 1
> configure: failed program was:
> | __thread int a; int b; int main() { return a = b; }
> configure:18104: result: no
>
>
>
>
> So, I guess, the libgomp tests should not be built with TLS emulation ;
> and any test requiring TLS should be hidden behind a
> { dg-require-effective-target tls_runtime }
>
> which was a proposal anyway ( http://gcc.gnu.org/ml/fortran/2008-12/
> msg00155.html).
>
>
>
> at least this will be consistent until such time as a general solution to
> making the emulation available is agreed.
>
> (and that means addressing the general issues I raised earlier).
>
> Iain
libjava and raw_cxx
Why is the libjava directory configured with raw_cxx?
Makefile.def:151:target_modules = { module= libjava; raw_cxx=true; };
The problem with this is that it keeps the libtool test for dynamic
linker characteristics from working properly, due to the undefined
reference to __gxx_personality_v0 which is defined in libstdc++.
configure:15385: checking dynamic linker characteristics
configure:15776: /usr/local/gcc/gcc-20081202/Build/./gcc/xgcc -shared-libgcc
-B/usr/local/gcc/gcc-20081202/Build/./gcc -nostdinc++
-L/usr/local/gcc/gcc-20081202/Build/powerpc64-suse-linux/libstdc++-v3/src
-L/usr/local/gcc/gcc-20081202/Build/powerpc64-suse-linux/libstdc++-v3/src/.libs
-B/usr/powerpc64-suse-linux/bin/ -B/usr/powerpc64-suse-linux/lib/ -isystem
/usr/powerpc64-suse-linux/include -isystem
/usr/powerpc64-suse-linux/sys-include -o conftest -O2 -g -D_GNU_SOURCE
-Wl,-rpath -Wl,/foo conftest.cpp >&5
/tmp/ccqVzuDO.o:(.eh_frame+0x12): undefined reference to `__gxx_personality_v0'
collect2: ld returned 1 exit status
configure:15782: $? = 1
configure: failed program was:
| /* confdefs.h. */
|
| #define PACKAGE_NAME "libjava"
| #define PACKAGE_TARNAME "libjava"
| #define PACKAGE_VERSION "version-unused"
| #define PACKAGE_STRING "libjava version-unused"
| #define PACKAGE_BUGREPORT ""
| #ifdef __cplusplus
| extern "C" void exit (int) throw ();
| #endif
| #define PACKAGE "libjava"
| #define VERSION "version-unused"
| #define LTDL_SHLIBPATH_VAR "LD_LIBRARY_PATH"
| #define AWT_TOOLKIT ""
| #define LIBGCJ_PREFIX "/usr"
| #define USE_LTDL 1
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_DLFCN_H 1
| #define LT_OBJDIR ".libs/"
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
Andreas.
--
Andreas Schwab, SuSE Labs, sch...@suse.de
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: libjava and raw_cxx
Andreas Schwab wrote:
> Why is the libjava directory configured with raw_cxx?
>
> Makefile.def:151:target_modules = { module= libjava; raw_cxx=true; };
>
> The problem with this is that it keeps the libtool test for dynamic
> linker characteristics from working properly, due to the undefined
> reference to __gxx_personality_v0 which is defined in libstdc++.
We don't want libstdc++ linked in libgcj.
If the libtool test wants libstdc++, then it's up to the libtool test
to include libstdc++. Nobody else wants it.
Andrew.
Re: libjava and raw_cxx
Andrew Haley writes:
> Andreas Schwab wrote:
>> Why is the libjava directory configured with raw_cxx?
>>
>> Makefile.def:151:target_modules = { module= libjava; raw_cxx=true; };
>>
>> The problem with this is that it keeps the libtool test for dynamic
>> linker characteristics from working properly, due to the undefined
>> reference to __gxx_personality_v0 which is defined in libstdc++.
>
> We don't want libstdc++ linked in libgcj.
>
> If the libtool test wants libstdc++, then it's up to the libtool test
> to include libstdc++. Nobody else wants it.
It's not libtool that wants it, but gcc, by generating the reference to
__gxx_personality_v0.
Andreas.
--
Andreas Schwab, SuSE Labs, sch...@suse.de
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: libjava and raw_cxx
Andreas Schwab wrote:
> Andrew Haley writes:
>
>> Andreas Schwab wrote:
>>> Why is the libjava directory configured with raw_cxx?
>>>
>>> Makefile.def:151:target_modules = { module= libjava; raw_cxx=true; };
>>>
>>> The problem with this is that it keeps the libtool test for dynamic
>>> linker characteristics from working properly, due to the undefined
>>> reference to __gxx_personality_v0 which is defined in libstdc++.
>> We don't want libstdc++ linked in libgcj.
>>
>> If the libtool test wants libstdc++, then it's up to the libtool test
>> to include libstdc++. Nobody else wants it.
>
> It's not libtool that wants it, but gcc, by generating the reference to
> __gxx_personality_v0.
Well, yes. I don't quite see your point.
The libtool test is broken, and should be fixed.
Andrew.
Re: libjava and raw_cxx
Andrew Haley writes:
> Andreas Schwab wrote:
>> Andrew Haley writes:
>>
>>> Andreas Schwab wrote:
Why is the libjava directory configured with raw_cxx?
Makefile.def:151:target_modules = { module= libjava; raw_cxx=true; };
The problem with this is that it keeps the libtool test for dynamic
linker characteristics from working properly, due to the undefined
reference to __gxx_personality_v0 which is defined in libstdc++.
>>> We don't want libstdc++ linked in libgcj.
>>>
>>> If the libtool test wants libstdc++, then it's up to the libtool test
>>> to include libstdc++. Nobody else wants it.
>>
>> It's not libtool that wants it, but gcc, by generating the reference to
>> __gxx_personality_v0.
>
> Well, yes. I don't quite see your point.
It's a generic link test, independent of the language that the compiler
accepts. It just assumes that the compiler works.
Andreas.
--
Andreas Schwab, SuSE Labs, sch...@suse.de
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: get_ref_base_and_extent() semantics
On Fri, Dec 12, 2008 at 03:05:32PM +0100, Martin Jambor wrote: > In this particular case, the ofset of var_array + its max_size (the > size of its element, as the function computes it, this is something I > also do not really understand) No, it's not the element size, it's the size of the whole array, I got this mixed up. The actual calculation is: tree asize = TYPE_SIZE (TREE_TYPE (TREE_OPERAND (exp, 0))); /* We need to adjust maxsize to the whole array bitsize. But we can subtract any constant offset seen so far, because that would get us outside of the array otherwise. */ if (maxsize != -1 && asize && host_integerp (asize, 1)) maxsize = TREE_INT_CST_LOW (asize) - bit_offset; else maxsize = -1; It therefore definitely takes the size of the whole array, I still don't quite understand why bit_offset is subtracted though since it contains the offset of the array itself, not anything within the array... at least if I understand the code correctly. (Meanwhile, I'm preparing a patch to be conservative if both variable indices and unions were seen.) Thanks, Martin
Re: libjava and raw_cxx
Andreas Schwab wrote:
> Andrew Haley writes:
>
>> Andreas Schwab wrote:
>>> Andrew Haley writes:
>>>
Andreas Schwab wrote:
> Why is the libjava directory configured with raw_cxx?
>
> Makefile.def:151:target_modules = { module= libjava; raw_cxx=true; };
>
> The problem with this is that it keeps the libtool test for dynamic
> linker characteristics from working properly, due to the undefined
> reference to __gxx_personality_v0 which is defined in libstdc++.
We don't want libstdc++ linked in libgcj.
If the libtool test wants libstdc++, then it's up to the libtool test
to include libstdc++. Nobody else wants it.
>>> It's not libtool that wants it, but gcc, by generating the reference to
>>> __gxx_personality_v0.
>> Well, yes. I don't quite see your point.
>
> It's a generic link test, independent of the language that the compiler
> accepts. It just assumes that the compiler works.
Sure, but a generic link test shouldn't require a directory to be
configured in any special way. That's the core problem here, not
the fact that libgcj is configured with raw_cxx.
Andrew.
Re: libjava and raw_cxx
Andrew Haley writes: > Sure, but a generic link test shouldn't require a directory to be > configured in any special way. I don't see where that requirement is special. After all, RAW_CXX is definitely not a full C++ compiler (for a good reason, of course). Andreas. -- Andreas Schwab, SuSE Labs, sch...@suse.de 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: libjava and raw_cxx
Andreas Schwab wrote: > Andrew Haley writes: > >> Sure, but a generic link test shouldn't require a directory to be >> configured in any special way. > > I don't see where that requirement is special. After all, RAW_CXX is > definitely not a full C++ compiler (for a good reason, of course). Can the path to libstdc++ be added to the test? Does the test even need to be C++? Andrew.
Re: libjava and raw_cxx
Andrew Haley writes: > Does the test even need to be C++? Probably not, that's just a side effect of being generic and run for every configured compiler. It's purpose is to test the linker, although the outcome may be influenced by flags passed implicitly by the frontend. Andreas. -- Andreas Schwab, SuSE Labs, sch...@suse.de 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: libjava and raw_cxx
Andreas Schwab wrote:
> Why is the libjava directory configured with raw_cxx?
>
> Makefile.def:151:target_modules = { module= libjava; raw_cxx=true; };
>
> The problem with this is that it keeps the libtool test for dynamic
> linker characteristics from working properly, due to the undefined
> reference to __gxx_personality_v0 which is defined in libstdc++.
If we weren't using libtool, it would be better to eliminate this and
instead special case the linker in libjava's Makefile.
But using libtool, it is basically a catch-22 (you need C++ in
configure, but then C++ goes in the libtool script, and then you cannot
eliminate it from the makefile).
If it bothers you (does it cause a PR?), I think it's easiest to define
a cache variable somewhere so that the test is forced to pass. Anyway
you know you do not need to build C++ executables (only Java) in libjava.
Paolo
Re: libjava and raw_cxx
Paolo Bonzini writes: > If it bothers you (does it cause a PR?), It causes a program to fail to run during build. ./gcj-dbtool -n classmap.db || touch classmap.db /usr/local/gcc/gcc-20081202/Build/powerpc64-suse-linux/libjava/.libs/gcj-dbtool: error while loading shared libraries: libgcj.so.10: cannot open shared object file: No such file or directory > I think it's easiest to define a cache variable somewhere so that the > test is forced to pass. There is no cache variable associated with this test. > Anyway you know you do not need to build C++ executables (only Java) > in libjava. See above. Andreas. -- Andreas Schwab, SuSE Labs, sch...@suse.de 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."
MPFR-2.4.0 Release Candidate
- Forwarded message from Philippe Theveny -
From: Philippe Theveny
User-Agent: Thunderbird 2.0.0.18 (X11/20081119)
To: MPFR mailing list
Subject: [MPFR] MPFR-2.4.0 Release Candidate
The release of MPFR 2.4.0 ("andouillette sauce moutarde") is imminent.
Please help to make this release as good as possible by downloading and
testing this release candidate:
http://www.mpfr.org/mpfr-2.4.0/mpfr-2.4.0-rc1.tar.lzma
http://www.mpfr.org/mpfr-2.4.0/mpfr-2.4.0-rc1.tar.bz2
http://www.mpfr.org/mpfr-2.4.0/mpfr-2.4.0-rc1.tar.gz
http://www.mpfr.org/mpfr-2.4.0/mpfr-2.4.0-rc1.zip
The MD5's:
d0632e2f43081f8c1c438471abce3f4b mpfr-2.4.0-rc1.tar.lzma
5d69b25a675b3b336c9cf34a9d9ce305 mpfr-2.4.0-rc1.tar.bz2
a0bf1b858fcb48f0d24ffb61642eed87 mpfr-2.4.0-rc1.tar.gz
cb4fbad90dcd183ef47e11f97c2f0110 mpfr-2.4.0-rc1.zip
The signatures:
http://www.mpfr.org/mpfr-2.4.0/mpfr-2.4.0-rc1.tar.lzma.asc
http://www.mpfr.org/mpfr-2.4.0/mpfr-2.4.0-rc1.tar.bz2.asc
http://www.mpfr.org/mpfr-2.4.0/mpfr-2.4.0-rc1.tar.gz.asc
http://www.mpfr.org/mpfr-2.4.0/mpfr-2.4.0-rc1.zip.asc
Changes from version 2.3.2 to version 2.4.0:
- MPFR is now a GNU package.
- Changes in the behavior of mpfr_strtofr and in its documentation
concerning particular cases where the code and the documentation
did not match; this change is also present in MPFR 2.3.1.
- Behavior of mpfr_check_range changed: if the value is an inexact
infinity, the overflow flag is set (in case it was lost); this
change is also present in MPFR 2.3.2.
- Function mpfr_init_gmp_rand (only defined when building MPFR without
the --with-gmp-build configure option) is no longer defined at all.
This function was private and not documented, and was used only in
the MPFR test suite. User code that calls it is regarded as broken
and may fail as a consequence. Running the old test suite against
MPFR 2.4.0 may also fail.
- New functions:
* between a MPFR number and a double: mpfr_add_d, mpfr_sub_d,
mpfr_d_sub, mpfr_mul_d, mpfr_div_d, mpfr_d_div,
* formatted input/output:
mpfr_printf, mpfr_fprintf, mpfr_vprintf, mpfr_vfprintf,
mpfr_sprintf, mpfr_snprintf, mpfr_vsprintf, mpfr_vsnprintf,
mpfr_asprintf, mpfr_vasprintf.
* mpfr_sinh_cosh, mpfr_li2, mpfr_modf, mpfr_fmod, mpfr_rec_sqrt.
- Configure test for TLS support.
- Get default $CC and $CFLAGS from gmp.h (__GMP_CC / __GMP_CFLAGS,
which are available as of GMP 4.2.3).
- Documented the fact that mpfr_random and mpfr_random2 will be
suppressed in the next release, and that the specification of
mpfr_eq may change in the next release (for compatibility with
the mpf layer of GMP).
- Bug fixes.
Please send success and failure reports with "./config.guess" output to
.
If no problems are found, MPFR 2.4.0 ("andouillette sauce moutarde") should be
released around 2009-01-12.
- End forwarded message -
--
Vincent Lefèvre - Web:
Re: libjava and raw_cxx
* Andreas Schwab wrote on Fri, Dec 12, 2008 at 06:43:45PM CET: > Paolo Bonzini writes: > > > I think it's easiest to define a cache variable somewhere so that the > > test is forced to pass. > > There is no cache variable associated with this test. That's an independent bug which needs to be fixed in Libtool anyway. Thanks for the report. I will fix it upstream. I haven't understood the original bug yet, in the sense that I don't quite understand the requirements that GCC has for Libtool's macros. Obviously, in this case link tests are not explicitly forbidden, but implicitly. How can Libtool know when they are supposed to work and when not? What can we assume to work? If I see correctly, then this particular test tries to find out whether -rpath sets DT_RUNPATH in addition to DT_RPATH. Unfortunately, some distributions patch binutils to add that, but at the same time made no other change to ld which would make this behavior apparent to the outside world. So I don't see how to avoid a test here, and hard-coding "yes" for gentoo and "no" for most other distros sounds pretty ugly. Thanks, Ralf
Re: libjava and raw_cxx
Ralf Wildenhues writes: > So I don't see how to avoid a test here, and hard-coding "yes" for > gentoo and "no" for most other distros sounds pretty ugly. And not very accurate either. Andreas. -- Andreas Schwab, SuSE Labs, sch...@suse.de 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: libjava and raw_cxx
Andreas Schwab wrote: > Ralf Wildenhues writes: > >> So I don't see how to avoid a test here, and hard-coding "yes" for >> gentoo and "no" for most other distros sounds pretty ugly. > > And not very accurate either. What is done to solve the same problem in libstdc++? Andrew.
Re: libjava and raw_cxx
Andrew Haley writes: > What is done to solve the same problem in libstdc++? It has basically the same problem, but it is even more special anyway (and doesn't need to link a c++ program). Andreas. -- Andreas Schwab, SuSE Labs, sch...@suse.de 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: libjava and raw_cxx
Andreas Schwab wrote: > Paolo Bonzini writes: > >> If it bothers you (does it cause a PR?), > > It causes a program to fail to run during build. > > ./gcj-dbtool -n classmap.db || touch classmap.db > /usr/local/gcc/gcc-20081202/Build/powerpc64-suse-linux/libjava/.libs/gcj-dbtool: > error while loading shared libraries: libgcj.so.10: cannot open shared > object file: No such file or directory > >> Anyway you know you do not need to build C++ executables (only Java) >> in libjava. > > See above. But that's not a C++ program, it's a Java program. Paolo
Re: [PATCH, DARWIN] fix emutls exports in libgcc_s10.{4,5}.dylib
On Dec 10, 2008, at 3:24 PM, IainS wrote: if one did -lgcc_s.10.x -lgcc_s.1 would that break it? ... should it not pick up only the unresolved symbols from s.1 I think this is the best long term solution. Things that can be found from the system are, those that aren't, come from the newly build libgcc_s.
Re: [PATCH, DARWIN] fix emutls exports in libgcc_s10.{4,5}.dylib
On Fri, Dec 12, 2008 at 12:01:07PM -0800, Mike Stump wrote: > On Dec 10, 2008, at 3:24 PM, IainS wrote: >> if one did -lgcc_s.10.x -lgcc_s.1 would that break it? >> ... should it not pick up only the unresolved symbols from s.1 > > I think this is the best long term solution. Things that can be found > from the system are, those that aren't, come from the newly build > libgcc_s. Mike, It really would be nice if this behavior could be automated such that the default build (which currently links everything against the FSF gcc libgcc) is allowed to access all of the symbols in libgcc_s.1 rather than just the versioned copy. Considering one is using a locally built version of libgcc from a particular version of FSF gcc, I think this attempt to force uniformity on that libgcc is rather pointless. Jack
Re: libjava and raw_cxx
Paolo Bonzini writes: > Andreas Schwab wrote: >> Paolo Bonzini writes: >> >>> If it bothers you (does it cause a PR?), >> >> It causes a program to fail to run during build. >> >> ./gcj-dbtool -n classmap.db || touch classmap.db >> /usr/local/gcc/gcc-20081202/Build/powerpc64-suse-linux/libjava/.libs/gcj-dbtool: >> error while loading shared libraries: libgcj.so.10: cannot open shared >> object file: No such file or directory >> >>> Anyway you know you do not need to build C++ executables (only Java) >>> in libjava. >> >> See above. > > But that's not a C++ program, it's a Java program. Yes, this is true. But even though the test that sets shlibpath_overrides_runpath is run for every compiler, only one result is then used for all link commands, and that happens to be the result of the C++ test. Andreas. -- Andreas Schwab, SuSE Labs, sch...@suse.de 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: libjava and raw_cxx
If it bothers you (does it cause a PR?), >>> It causes a program to fail to run during build. >>> >>> ./gcj-dbtool -n classmap.db || touch classmap.db >>> /usr/local/gcc/gcc-20081202/Build/powerpc64-suse-linux/libjava/.libs/gcj-dbtool: >>> error while loading shared libraries: libgcj.so.10: cannot open shared >>> object file: No such file or directory >>> Anyway you know you do not need to build C++ executables (only Java) in libjava. >>> See above. >> But that's not a C++ program, it's a Java program. > > Yes, this is true. But even though the test that sets > shlibpath_overrides_runpath is run for every compiler, only one result > is then used for all link commands, and that happens to be the result of > the C++ test. That's the bug then I'd say... Ralf what do you think? Paolo
gcc-4.4-20081212 is now available
Snapshot gcc-4.4-20081212 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20081212/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 142725 You'll find: gcc-4.4-20081212.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20081212.tar.bz2 C front end and core compiler gcc-ada-4.4-20081212.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20081212.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20081212.tar.bz2 C++ front end and runtime gcc-java-4.4-20081212.tar.bz2 Java front end and runtime gcc-objc-4.4-20081212.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20081212.tar.bz2The GCC testsuite Diffs from 4.4-20081205 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 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.
bootstrap failure on i686-apple-darwin9
Between r142699 and r142726, we seemed to have broken the bootstrap on i686-apple-darwin9. I now see a failure when linking the -m64 version of libgfortran... libtool: compile: /sw/src/fink.build/gcc44-4.3.999-20081212/darwin_objdir/./gcc/gfortran -B/sw/src/fink.build/gcc44-4.3.999-20081212/darwin_objdir/./gcc/ -B/sw/lib/gcc4.4/i686-apple-darwin9/bin/ -B/sw/lib/gcc4.4/i686-apple-darwin9/lib/ -isystem /sw/lib/gcc4.4/i686-apple-darwin9/include -isystem /sw/lib/gcc4.4/i686-apple-darwin9/sys-include -m64 -DHAVE_CONFIG_H -I. -I../../../../gcc-4.4-20081212/libgfortran -I. -iquote../../../../gcc-4.4-20081212/libgfortran/io -I../../../../gcc-4.4-20081212/libgfortran/../gcc -I../../../../gcc-4.4-20081212/libgfortran/../gcc/config -I../../.././gcc -D_GNU_SOURCE -I . -Wall -Werror -fimplicit-none -fno-repack-arrays -fno-underscoring -fallow-leading-underscore -g -O2 -m64 -c ../../../../gcc-4.4-20081212/libgfortran/intrinsics/f2c_specifics.F90 -o f2c_specifics.o >/dev/null 2>&1 /bin/sh ./libtool --tag=CC --mode=link /sw/src/fink.build/gcc44-4.3.999-20081212/darwin_objdir/./gcc/xgcc -B/sw/src/fink.build/gcc44-4.3.999-20081212/darwin_objdir/./gcc/ -B/sw/lib/gcc4.4/i686-apple-darwin9/bin/ -B/sw/lib/gcc4.4/i686-apple-darwin9/lib/ -isystem /sw/lib/gcc4.4/i686-apple-darwin9/include -isystem /sw/lib/gcc4.4/i686-apple-darwin9/sys-include -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -fcx-fortran-rules -g -O2-m64 -m64 -o libgfortran.la -rpath /sw/lib/gcc4.4/lib/x86_64 -version-info `grep -v '^#' ../../../../gcc-4.4-20081212/libgfortran/libtool-version` '-m64' -lm -Wl,-single_module backtrace.lo compile_options.lo convert_char.lo environ.lo error.lo fpu.lo main.lo memory.lo pause.lo stop.lo string.lo select.lo all_l1.lo all_l2.lo all_l4.lo all_l8.lo all_l16.lo any_l1.lo any_l2.lo any_l4.lo any_l8.lo any_l16.lo count_1_l.lo count_2_l.lo count_4_l.lo count_8_l.lo count_16_l.lo maxloc0_4_i1.lo maxloc0_8_i1.lo maxloc0_16_i1.lo maxloc0_4_i2.lo maxloc0_8_i2.lo maxloc0_16_i2.lo maxloc0_4_i4.lo maxloc0_8_i4.lo maxloc0_16_i4.lo maxloc0_4_i8.lo maxloc0_8_i8.lo maxloc0_16_i8.lo maxloc0_4_i16.lo maxloc0_8_i16.lo maxloc0_16_i16.lo maxloc0_4_r4.lo maxloc0_8_r4.lo maxloc0_16_r4.lo maxloc0_4_r8.lo maxloc0_8_r8.lo maxloc0_16_r8.lo maxloc0_4_r10.lo maxloc0_8_r10.lo maxloc0_16_r10.lo maxloc0_4_r16.lo maxloc0_8_r16.lo maxloc0_16_r16.lo maxloc1_4_i1.lo maxloc1_8_i1.lo maxloc1_16_i1.lo maxloc1_4_i2.lo maxloc1_8_i2.lo maxloc1_16_i2.lo maxloc1_4_i4.lo maxloc1_8_i4.lo maxloc1_16_i4.lo maxloc1_4_i8.lo maxloc1_8_i8.lo maxloc1_16_i8.lo maxloc1_4_i16.lo maxloc1_8_i16.lo maxloc1_16_i16.lo maxloc1_4_r4.lo maxloc1_8_r4.lo maxloc1_16_r4.lo maxloc1_4_r8.lo maxloc1_8_r8.lo maxloc1_16_r8.lo maxloc1_4_r10.lo maxloc1_8_r10.lo maxloc1_16_r10.lo maxloc1_4_r16.lo maxloc1_8_r16.lo maxloc1_16_r16.lo maxval_i1.lo maxval_i2.lo maxval_i4.lo maxval_i8.lo maxval_i16.lo maxval_r4.lo maxval_r8.lo maxval_r10.lo maxval_r16.lo minloc0_4_i1.lo minloc0_8_i1.lo minloc0_16_i1.lo minloc0_4_i2.lo minloc0_8_i2.lo minloc0_16_i2.lo minloc0_4_i4.lo minloc0_8_i4.lo minloc0_16_i4.lo minloc0_4_i8.lo minloc0_8_i8.lo minloc0_16_i8.lo minloc0_4_i16.lo minloc0_8_i16.lo minloc0_16_i16.lo minloc0_4_r4.lo minloc0_8_r4.lo minloc0_16_r4.lo minloc0_4_r8.lo minloc0_8_r8.lo minloc0_16_r8.lo minloc0_4_r10.lo minloc0_8_r10.lo minloc0_16_r10.lo minloc0_4_r16.lo minloc0_8_r16.lo minloc0_16_r16.lo minloc1_4_i1.lo minloc1_8_i1.lo minloc1_16_i1.lo minloc1_4_i2.lo minloc1_8_i2.lo minloc1_16_i2.lo minloc1_4_i4.lo minloc1_8_i4.lo minloc1_16_i4.lo minloc1_4_i8.lo minloc1_8_i8.lo minloc1_16_i8.lo minloc1_4_i16.lo minloc1_8_i16.lo minloc1_16_i16.lo minloc1_4_r4.lo minloc1_8_r4.lo minloc1_16_r4.lo minloc1_4_r8.lo minloc1_8_r8.lo minloc1_16_r8.lo minloc1_4_r10.lo minloc1_8_r10.lo minloc1_16_r10.lo minloc1_4_r16.lo minloc1_8_r16.lo minloc1_16_r16.lo minval_i1.lo minval_i2.lo minval_i4.lo minval_i8.lo minval_i16.lo minval_r4.lo minval_r8.lo minval_r10.lo minval_r16.lo product_i1.lo product_i2.lo product_i4.lo product_i8.lo product_i16.lo product_r4.lo product_r8.lo product_r10.lo product_r16.lo product_c4.lo product_c8.lo product_c10.lo product_c16.lo sum_i1.lo sum_i2.lo sum_i4.lo sum_i8.lo sum_i16.lo sum_r4.lo sum_r8.lo sum_r10.lo sum_r16.lo sum_c4.lo sum_c8.lo sum_c10.lo sum_c16.lo matmul_i1.lo matmul_i2.lo matmul_i4.lo matmul_i8.lo matmul_i16.lo matmul_r4.lo matmul_r8.lo matmul_r10.lo matmul_r16.lo matmul_c4.lo matmul_c8.lo matmul_c10.lo matmul_c16.lo matmul_l4.lo matmul_l8.lo matmul_l16.lo transpose_i4.lo transpose_i8.lo transpose_i16.lo transpose_r4.lo transpose_r8.lo transpose_r10.lo transpose_r16.lo transpose_c4.lo transpose_c8.lo transpose_c10.lo transpose_c16.lo shape_i4.lo shape_i8.lo shape_i16.lo eoshift1_4.lo eoshift1_8.lo eoshift1_16.lo eoshift3_4.lo eoshift3_8.lo eoshift3_16.lo cshift1_4.lo cshift1_8.lo cshift1_16.lo reshape_i4.lo
libstdc++ build error for powerpc-elf or powerpc-eabi
Building top-of-tree g++ fails in libstdc++ compiling ctype.cc: In file included from .../gcc/libstdc++-v3/src/ctype.cc:59: .../build/lin/bld_gcc/build/powerpc-eabi/libstdc++-v3/include/powerpc-eabi/bits/ctype_noninline.h: In static member function ‘static const char* std::ctype::classic_table()’: .../build/powerpc-eabi/libstdc++-v3/include/powerpc-eabi/bits/ctype_noninline.h:43: error: ‘_ctype_’ was not declared in this scope -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
�dv
Szia Pár napja kérdezted hogy nem e tudok egy jó letöltős oldalt. Ãs én most találtam egyet. Tele van jobbnál jobb filmekkel, és olcsó! 1 db sms elküldése után 500 kb/sec-el töltöttem napokig a legújabb premier filmeket és meséket! Küldj most SMS-t,és 5 nap helyet,25-öt adunk,ez jelenlegi akciónk! http://href.hu/x/7k7e http://href.hu/x/7k7e __ E-mail cÃmed a Country jóvoltából került bele hÃrlevél rendszerünkbe. Ha nem szeretnél több ilyet kapni. Ãrj a clu...@1000.hu email cÃmre! A küldő FiktÃv, kitalált személy, de az e-mail cÃmen elérsz bennünket.
re: bootstrap failure on i686-apple-darwin9
I have narrowed the failure down a bit. Revision 142713 bootstraps okay on i686-apple-darwin9 but revision 142715 fails at the same place in the linkage of the -m64 version of libgfortran. I will back up to revision 142714 next to confirm that the problem was introduced with... r142715 | spop | 2008-12-12 12:24:23 -0500 (Fri, 12 Dec 2008) | 6 lines 2008-12-12 Sebastian Pop * configure.ac (ppllibs): Add by default the lib flags. * configure: Regenerate.
re: bootstrap failure on i686-apple-darwin9
Well, I am baffled. Revision 142714 fails as well so that revision 142715 can't be at fault for the bootstrap failure of -m64 libgfortran on i686-apple-darwin9. The strange part is that I don't see anything in the remaining revision 142714 which could possibly be interacting with the build of libgfortran. I guess I try to manually patch out r142714 from current gcc trunk to verify that the bootstrap failures disappear. Jack
re: bootstrap failure on i686-apple-darwin9
Manually executing make in gcc44-4.3.999-20081212/darwin_objdir after a failed build of gcc trunk on i686-apple-darwin9 produces... make[5]: Nothing to be done for `all'. make "AR_FLAGS=rc" "CC_FOR_BUILD=gcc" "CC_FOR_TARGET=/sw/src/fink.build/gcc44-4.3.999-20081212/darwin_objdir/./gcc/xgcc -B/sw/src/fink.build/gcc44-4.3.999-20081212/darwin_objdir/./gcc/ -B/sw/lib/gcc4.4/i686-apple-darwin9/bin/ -B/sw/lib/gcc4.4/i686-apple-darwin9/lib/ -isystem /sw/lib/gcc4.4/i686-apple-darwin9/include -isystem /sw/lib/gcc4.4/i686-apple-darwin9/sys-include" "CFLAGS=-g -O2 " "CXXFLAGS=-g -O2 " "CFLAGS_FOR_BUILD=-g -O2" "CFLAGS_FOR_TARGET=-g -O2" "INSTALL=/usr/bin/install -c" "INSTALL_DATA=/usr/bin/install -c -m 644" "INSTALL_PROGRAM=/usr/bin/install -c" "INSTALL_SCRIPT=/usr/bin/install -c" "LDFLAGS=" "LIBCFLAGS=-g -O2 " "LIBCFLAGS_FOR_TARGET=-g -O2" "MAKE=make" "MAKEINFO=makeinfo --split-size=500 --split-size=500 " "PICFLAG=" "PICFLAG_FOR_TARGET=" "SHELL=/bin/sh" "RUNTESTFLAGS=" "exec_prefix=/sw/lib/gcc4.4" "infodir=/sw/share/info" "libdir=/sw/lib/gcc4.4/lib" "includedir=/sw/lib/gcc4.4/include" "prefix=/sw/lib/gcc4.4" "tooldir=/sw/lib/gcc4.4/i686-apple-darwin9" "gxx_include_dir=/sw/lib/gcc4.4/include/c++/4.4.0" "AR=ar" "AS=/sw/src/fink.build/gcc44-4.3.999-20081212/darwin_objdir/./gcc/as" "LD=/sw/src/fink.build/gcc44-4.3.999-20081212/darwin_objdir/./gcc/collect-ld" "RANLIB=ranlib -c" "NM=/sw/src/fink.build/gcc44-4.3.999-20081212/darwin_objdir/./gcc/nm" "NM_FOR_BUILD=" "NM_FOR_TARGET=nm" "DESTDIR=" "WERROR=" all-recursive Making all in include make[4]: Nothing to be done for `all'. Making all in libsupc++ make[4]: Nothing to be done for `all'. Making all in libmath make[4]: Nothing to be done for `all'. Making all in doc make[4]: Nothing to be done for `all'. Making all in src /bin/sh ../libtool --tag CXX --mode=compile /sw/src/fink.build/gcc44-4.3.999-20081212/darwin_objdir/./gcc/xgcc -shared-libgcc -B/sw/src/fink.build/gcc44-4.3.999-20081212/darwin_objdir/./gcc -nostdinc++ -L/sw/src/fink.build/gcc44-4.3.999-20081212/darwin_objdir/i686-apple-darwin9/libstdc++-v3/src -L/sw/src/fink.build/gcc44-4.3.999-20081212/darwin_objdir/i686-apple-darwin9/libstdc++-v3/src/.libs -B/sw/lib/gcc4.4/i686-apple-darwin9/bin/ -B/sw/lib/gcc4.4/i686-apple-darwin9/lib/ -isystem /sw/lib/gcc4.4/i686-apple-darwin9/include -isystem /sw/lib/gcc4.4/i686-apple-darwin9/sys-include -I/sw/src/fink.build/gcc44-4.3.999-20081212/darwin_objdir/i686-apple-darwin9/libstdc++-v3/include/i686-apple-darwin9 -I/sw/src/fink.build/gcc44-4.3.999-20081212/darwin_objdir/i686-apple-darwin9/libstdc++-v3/include -I/sw/src/fink.build/gcc44-4.3.999-20081212/gcc-4.4-20081212/libstdc++-v3/libsupc++ -I/sw/include -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -fvisibility-inlines-hidden -ffunction-sections -fdata-sections -g -O2-x c++ -std=gnu++0x -c ../../../../gcc-4.4-20081212/libstdc++-v3/src/atomic.cc libtool: compile: /sw/src/fink.build/gcc44-4.3.999-20081212/darwin_objdir/./gcc/xgcc -shared-libgcc -B/sw/src/fink.build/gcc44-4.3.999-20081212/darwin_objdir/./gcc -nostdinc++ -L/sw/src/fink.build/gcc44-4.3.999-20081212/darwin_objdir/i686-apple-darwin9/libstdc++-v3/src -L/sw/src/fink.build/gcc44-4.3.999-20081212/darwin_objdir/i686-apple-darwin9/libstdc++-v3/src/.libs -B/sw/lib/gcc4.4/i686-apple-darwin9/bin/ -B/sw/lib/gcc4.4/i686-apple-darwin9/lib/ -isystem /sw/lib/gcc4.4/i686-apple-darwin9/include -isystem /sw/lib/gcc4.4/i686-apple-darwin9/sys-include -I/sw/src/fink.build/gcc44-4.3.999-20081212/darwin_objdir/i686-apple-darwin9/libstdc++-v3/include/i686-apple-darwin9 -I/sw/src/fink.build/gcc44-4.3.999-20081212/darwin_objdir/i686-apple-darwin9/libstdc++-v3/include -I/sw/src/fink.build/gcc44-4.3.999-20081212/gcc-4.4-20081212/libstdc++-v3/libsupc++ -I/sw/include -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -fvisibility-inlines-hidden -ffunction-sections -fdata-sections -g -O2 -x c++ -std=gnu++0x -c ../../../../gcc-4.4-20081212/libstdc++-v3/src/atomic.cc -fno-common -DPIC -o .libs/atomic.o In file included from /usr/include/wchar.h:114, from /sw/src/fink.build/gcc44-4.3.999-20081212/darwin_objdir/i686-apple-darwin9/libstdc++-v3/include/cwchar:52, from /sw/src/fink.build/gcc44-4.3.999-20081212/darwin_objdir/i686-apple-darwin9/libstdc++-v3/include/bits/postypes.h:47, from /sw/src/fink.build/gcc44-4.3.999-20081212/darwin_objdir/i686-apple-darwin9/libstdc++-v3/include
Will GCC 4.3 or 4.4 work on the AlphaServer anytime soon?
Hi - to all of the incredible programmers who make GCC work on so many computer chip architectures... I have one question: Will GCC 4.3.X or 4.4.X be ported and operational on the AlphaServer 4XXX Systems running Debian Linux or any other Linux anytime soon? Thanks for your time to answer my inquiry and of course for making GCC work. Regards, Robert Garron
Re: MPFR-2.4.0 Release Candidate
On Fri, 12 Dec 2008, Vincent Lefevre wrote:
> The release of MPFR 2.4.0 ("andouillette sauce moutarde") is imminent.
> Please help to make this release as good as possible by downloading and
> testing this release candidate:
>
> Changes from version 2.3.2 to version 2.4.0:
> [...]
> - Bug fixes.
Vincent,
Are there any MPFR bugs fixed in 2.4.0 that can be exposed through the
limited way GCC uses MPFR?
Thanks,
--Kaveh
--
Kaveh R. Ghazi gh...@caip.rutgers.edu
Re: libjava and raw_cxx
* Paolo Bonzini wrote on Fri, Dec 12, 2008 at 10:14:15PM CET: > > > > Yes, this is true. But even though the test that sets > > shlibpath_overrides_runpath is run for every compiler, only one result > > is then used for all link commands, and that happens to be the result of > > the C++ test. > > That's the bug then I'd say... Ralf what do you think? Yes, my intention was to use one cache variable for the test, as opposed to one per compiler, which should fix this to take the result of the first compiler (C if not disabled). Strictly speaking, that is not precise enough: the user could be using different linkers for different compilers. I don't think we need to support such a setup on GNU/Linux, though. Cheers, Ralf
Re: bootstrap failure on i686-apple-darwin9
>Manually executing make in gcc44-4.3.999-20081212/darwin_objdir > after a failed build of gcc trunk on i686-apple-darwin9 produces... This appears to be an include ordering issue. Revision 142738 works around this to fix the bootstrap issue (although the problem still exists and is readily apparent in the test results.) http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00791.html -benjamin
