I had some trouble with random build failures in a large LTO project
and it turned out to be random seed collisions in a highly parallel build
(thanks to Honza for suggesting that)

There were multiple problems:
- The way to generate the random seed is not very random (milliseconds time plus pid)
and prone to collisions on highly parallel builds
- It's only 32bit
- Several users take the existing ascii seed and re-CRC32 it again, which
doesn't exactly improve it.

This patch changes that to:
- Always use 64bit seeds as numbers (no re-crcing)
- Change all users to use HOST_WIDE_INT
- When the user specifies a random seed it's still crc32ed, but only in
this case.

Passes bootstrap + testsuite on x86_64-linux.

gcc/cp:

2011-09-26   Andi Kleen <ak@linux.intel.com>

	* repo.c (finish_repo): Use HOST_WIDE_INT_PRINT_HEX_PURE.

gcc/:

2011-09-26   Andi Kleen <ak@linux.intel.com>

	* hwint.h (HOST_WIDE_INT_PRINT_HEX_PURE): Add.
	* lto-streamer.c (lto_get_section_name): Remove crc32_string.
 	Handle numerical random seed.
	* lto-streamer.h (lto_file_decl_data): Change id to unsigned HOST_WIDE_INT.
	* toplev.c (random_seed): Add.
	(init_random_seed): Change for numerical random seed.
	(get_random_seed): Return as HOST_WIDE_INT.
	(set_random_seed): Crc32 existing string.
	* toplev.h (get_random_seed): Change to numercal return.
	* tree.c (get_file_function_name): Remove CRC. Handle numerical random seed.

gcc/lto/:

2011-09-26   Andi Kleen <ak@linux.intel.com>

	* lto.c (lto_resolution_read): Remove id dumping.
	(lto_section_with_id): Turn id HOST_WIDE_ID.
	(create_subid_section_table): Dito.

From-SVN: r179347