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.
This test doesn't support testing an installed compiler.
The root of the problem is that the test generator is written as a C
program, which is expected to be run on the host system. As a result,
we need to compile on the host system, which is why we need HOSTCC and
HOSTCFLAGS in struct-layout-1.e
20 matches
Mail list logo
