Jakub Jelinek wrote:
+ #ifndef WORDS_BIGENDIAN
+ /* On a little-endian machine, if the data is 4-byte aligned we can hash
+ by word for better speed. This gives nondeterministic results on
+ big-endian machines. */
WORDS_BIGENDIAN is not being defined in the headers that are included
On 5/17/05, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Richard Guenther wrote:
>
> >>Personally I think this change comes under the "obvious" rule, given
> >>Mark's change yesterday to not link against libiberty.
> >
> > Done.
>
> Yes, this is an obvious patch; thank you. I did not notice this p
Richard Guenther wrote:
Personally I think this change comes under the "obvious" rule, given
Mark's change yesterday to not link against libiberty.
Done.
Yes, this is an obvious patch; thank you. I did not notice this problem
because my machine does have a libiberty.h installed. Would you plea
On 17 May 2005 10:05:58 -0400, Ian Lance Taylor wrote:
> Richard Guenther <[EMAIL PROTECTED]> writes:
>
> > It works after removing the libiberty includes from generate-random.c
> > and generate-random_r.c
>
> Personally I think this change comes under the "obvious" rule, given
> Mark's change y
Richard Guenther <[EMAIL PROTECTED]> writes:
> It works after removing the libiberty includes from generate-random.c
> and generate-random_r.c
Personally I think this change comes under the "obvious" rule, given
Mark's change yesterday to not link against libiberty.
Ian
On 17 May 2005 08:59:07 -0400, Ian Lance Taylor wrote:
> Richard Guenther <[EMAIL PROTECTED]> writes:
>
> > /net/alwazn/home/rguenth/src/gcc/cvs/gcc-4.1/gcc/testsuite/gcc.dg/compat/generate-random.c:55:23:
> > libiberty.h: No such file or directory^M
> > /net/alwazn/home/rguenth/src/gcc/cvs/gcc-4
Andreas Schwab <[EMAIL PROTECTED]> writes:
> Ian Lance Taylor writes:
>
> > Richard Guenther <[EMAIL PROTECTED]> writes:
> >
> >> Note how
> >> 1. it uses $(CC) for building, not the built compiler
> >
> > That is correct, as this program is run on the build system to
> > generate test cases.
Ian Lance Taylor writes:
> Richard Guenther <[EMAIL PROTECTED]> writes:
>
>> Note how
>> 1. it uses $(CC) for building, not the built compiler
>
> That is correct, as this program is run on the build system to
> generate test cases.
Shouldn't it use CC_FOR_BUILD then?
Andreas.
--
Andreas Sc
Richard Guenther <[EMAIL PROTECTED]> writes:
> /net/alwazn/home/rguenth/src/gcc/cvs/gcc-4.1/gcc/testsuite/gcc.dg/compat/generate-random.c:55:23:
> libiberty.h: No such file or directory^M
> /net/alwazn/home/rguenth/src/gcc/cvs/gcc-4.1/gcc/testsuite/gcc.dg/compat/generate-random_r.c:56:23:
> libibe
On 5/17/05, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Ian Lance Taylor wrote:
>
> >>1. Remove the use of config.h and HAVE_*_H.
> >>
> >>2. Modify the generator not to depend on libiberty headers, including
> >>hashtab.h, by substituting a simple dictonary object.
> >>
> >>3. Adjust struct-layout
On Mon, May 16, 2005 at 05:26:36PM -0700, Mark Mitchell wrote:
> 2005-05-16 Mark Mitchell <[EMAIL PROTECTED]>
>
> * gcc.dg/compat/generate-random.c (config.h): Do not include.
> (limits.h): Include unconditionally.
> (stdlib.h): Likewise.
> * gcc.dg/compat/generate-random
DJ Delorie wrote:
(There's still a POSIX-ism in the generator, in that it tries to
write to "/dev/null". On Windows systems, I bet this will often
work, but create a real file with that name. It would be better,
and avoid portability problems, to guard the calls to fwrite, etc.,
with "if (file)"
> (There's still a POSIX-ism in the generator, in that it tries to
> write to "/dev/null". On Windows systems, I bet this will often
> work, but create a real file with that name. It would be better,
> and avoid portability problems, to guard the calls to fwrite, etc.,
> with "if (file)" rather
Ian Lance Taylor wrote:
1. Remove the use of config.h and HAVE_*_H.
2. Modify the generator not to depend on libiberty headers, including
hashtab.h, by substituting a simple dictonary object.
3. Adjust struct-layout-1.exp accordingly.
This is what I would recommend anyhow.
Done with the attached
> It's presumably a matter of adding the right libiberty configure option
> from the top-level by default. Would you care to take a try? It sounds
> like Ian would probably approve it, or maybe one of our build
> maintainers would.
I'll try, but I don't guarantee anything. IIRC I tried before f
Eric Botcazou wrote:
Personally, I think we should default to not installing libiberty.a,
though we should install libiberty.so if we build it.
And fix PR other/16513 in the process.
It's presumably a matter of adding the right libiberty configure option
from the top-level by default. Would you
> Personally, I think we should default to not installing libiberty.a,
> though we should install libiberty.so if we build it.
And fix PR other/16513 in the process.
--
Eric Botcazou
Ian Lance Taylor wrote:
I expect this dates back to the time when libiberty was mainly just a
replacement for missing system functions, and there were no particular
header files associated with it. Plus, if you configure with
--enable-shared, you will get a shared libiberty which probably needs
to
Mark Mitchell <[EMAIL PROTECTED]> writes:
> Anyhow, why do we install libiberty.a, but not the libiberty include
> files?
I expect this dates back to the time when libiberty was mainly just a
replacement for missing system functions, and there were no particular
header files associated with it.
19 matches
Mail list logo
