Re: PATCH RFA: Build stages 2 and 3 with C++
On Wed, 20 Jul 2011 14:41:16 -0700
Ian Lance Taylor wrote:
> Mike Stump writes:
>
> >> Presumably the fix will be to use -frandom-seed.
> >
> > But, the random seem was to ensure that things that should not collide,
> > don't. If you use 0, then things that should not collide, eventually will
> > and your world with then end. In the present code base, it is perfectly
> > safe to do this. If the codebase is ever extended to use C++ features,
> > then, that code can break.
>
> I wasn't suggesting using -frandom-seed=0.
I have a similar issue in the MELT branch, and I am passing to -frandom-seed
the md5sum
of relevant source files. With such a trick, the seed is reproducible from one
build to
the next one (of the exact same source tree), and does provide much more
randomness than
just using 0 all the time.
Cheers.
--
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} ***
TARGET_FLAGS_REGNUM breaks gcc
Hi,
After the discussion we had on the previous thread 'splitting add
instructions', I added support for TARGET_FLAGS_RENUM to my port along
with *_flags rules similar to how it is done in rx backend (gcc 4.6.1).
Then I decided to create a very simple C program:
unsigned long foo(unsigned int a, unsigned int b)
{
if(a < b)
return a << b;
else
return a >> b;
}
When I compile it (with my backend) it I either gets into an infinite
loop or segfaults in kill_value_one_regno (unsigned int regno, struct
value_data *vd), regcprop.c, called from cprop_hardreg pass.
The infinite cycle, or segfault, is in the cycle (regcprop.c:138):
for (i = vd->e[regno].oldest_regno;
vd->e[i].next_regno != regno;
i = vd->e[i].next_regno)
continue;
That i goes into the loop 0, 7, -1, 0... where regno passed into the
function is 14, my FIRST_PSEUDO_REGISTER, and CC_REGNUM is 13.
When it segfaults the loop goes 0, 7, 15127832392 (some obscene number).
Then I decided to turn on checking. So I configured gcc with
--enable-checking=all and with this I get:
internal compiler error: in df_live_verify_transfer_functions, at
df-problems.c:1816
I followed to see what happened to rx. So I compiled the rx backend and
used the same example, also with checking enabled and I get the same
assertion. So I assume this is GCC issue and reported it. Bug 49801
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49801).
In the meantime I am trying to pinpoint the exact problem. If someone
has any idea and know of a workaround, can you please let me know?
Cheers,
--
PMatos
Re: PATCH RFA: Build stages 2 and 3 with C++
On Wed, Jul 20, 2011 at 4:25 PM, Ian Lance Taylor wrote: > Presumably the fix will be to use -frandom-seed. Does this patch fix > the problem? (The only real change is to fragment.am, the other changes > are all generated by automake). This patch gets the build past the compiler and runtime, although the build time now is much longer on AIX. Thanks, David
C99 Status - inttypes.h
Hi, I checked the "library functions in " item in c99status (marked as "Library Issue") [http://gcc.gnu.org/c99status.html], and it seems that glibc implements everything the standard demands. Am I missing something or is this outdated? If so, where can I find more information about it? Thank you, Diogo Sousa signature.asc Description: OpenPGP digital signature
Re: C99 Status - inttypes.h
On Thu, 21 Jul 2011, Diogo Sousa wrote: > Hi, > > I checked the "library functions in " item in c99status > (marked as "Library Issue") [http://gcc.gnu.org/c99status.html], and it > seems that glibc implements everything the standard demands. > > Am I missing something or is this outdated? If so, where can I find more > information about it? "Library Issue" simply means it's not GCC's resposibility; it says nothing about the state in any particular library that may be used with GCC. -- Joseph S. Myers jos...@codesourcery.com
Re: PATCH RFA: Build stages 2 and 3 with C++
Basile Starynkevitch writes: > I have a similar issue in the MELT branch, and I am passing to -frandom-seed > the md5sum > of relevant source files. With such a trick, the seed is reproducible from > one build to > the next one (of the exact same source tree), and does provide much more > randomness than > just using 0 all the time. In practice I think it is fine to just pass the source file name to -frandom-seed. That's what the patch I sent out does. The source file name should be unique within a given program. Ian
Re: C99 Status - inttypes.h
On Thu, 21 Jul 2011 15:24:00 +0100
Diogo Sousa wrote:
> I checked the "library functions in " item in c99status
> (marked as "Library Issue") [http://gcc.gnu.org/c99status.html], and it
> seems that glibc implements everything the standard demands.
> Am I missing something or is this outdated? If so, where can I find more
> information about it?
This brings another question. Can a GCC pass use intptr_t (the standard int of
the same
size as a void* pointer)? This is quite useful, for instance when one wants to
compute an
hash, or a unique sorted rank (to be used inside B-trees) from the address of a
gimple
or a tree.
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: PATCH RFA: Build stages 2 and 3 with C++
On Thu, Jul 21, 2011 at 08:51:46AM -0700, Ian Lance Taylor wrote: > Basile Starynkevitch writes: > > > I have a similar issue in the MELT branch, and I am passing to > > -frandom-seed the md5sum > > of relevant source files. With such a trick, the seed is reproducible from > > one build to > > the next one (of the exact same source tree), and does provide much more > > randomness than > > just using 0 all the time. > > In practice I think it is fine to just pass the source file name to > -frandom-seed. That's what the patch I sent out does. The source file > name should be unique within a given program. Isn't the filename already encoded in what get_file_function_name returns? It is __, so IMHO -frandom-seed=$@ brings almost no advantages at all over -frandom-seed=0. Except perhaps for the characters from the filename that are wiped into _ by clean_symbol_name. Jakub
Re: C99 Status - inttypes.h
On Thu, Jul 21, 2011 at 07:30:16AM -0700, Joseph S. Myers wrote: > On Thu, 21 Jul 2011, Diogo Sousa wrote: > > > Hi, > > > > I checked the "library functions in " item in c99status > > (marked as "Library Issue") [http://gcc.gnu.org/c99status.html], and it > > seems that glibc implements everything the standard demands. > > > > Am I missing something or is this outdated? If so, where can I find more > > information about it? > > "Library Issue" simply means it's not GCC's resposibility; it says nothing > about the state in any particular library that may be used with GCC. But readers will focus on the word "Issue" here and think that there is something missing. Perhaps there should be a footnote explaining that glibc/eglibc has the needed support, but that other libraries might not.
Re: PATCH RFA: Build stages 2 and 3 with C++
Jakub Jelinek writes: > On Thu, Jul 21, 2011 at 08:51:46AM -0700, Ian Lance Taylor wrote: >> Basile Starynkevitch writes: >> >> > I have a similar issue in the MELT branch, and I am passing to >> > -frandom-seed the md5sum >> > of relevant source files. With such a trick, the seed is reproducible from >> > one build to >> > the next one (of the exact same source tree), and does provide much more >> > randomness than >> > just using 0 all the time. >> >> In practice I think it is fine to just pass the source file name to >> -frandom-seed. That's what the patch I sent out does. The source file >> name should be unique within a given program. > > Isn't the filename already encoded in what get_file_function_name returns? > It is __, so IMHO > -frandom-seed=$@ brings almost no advantages at all over -frandom-seed=0. > Except perhaps for the characters from the filename that are > wiped into _ by clean_symbol_name. That's a fair point, but I guess I still think using the file name with -frandom-seed is going to be more future-proof against other users of random numbers. Ian
trunk merged into MELT branch, and improved build
Hello
For information I merged trunk 176576 into MELT branch rev 176583
and the build machinery has been improved.
MELT now requires every MELT module to have its generated .c files available.
Cheers.
--
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: PATCH RFA: Build stages 2 and 3 with C++
On Thu, 21 Jul 2011 11:13:00 -0700
Ian Lance Taylor wrote:
> Jakub Jelinek writes:
>
> > On Thu, Jul 21, 2011 at 08:51:46AM -0700, Ian Lance Taylor wrote:
> >> Basile Starynkevitch writes:
> >>
> >> > I have a similar issue in the MELT branch, and I am passing to
> >> > -frandom-seed the md5sum
> >> > of relevant source files. With such a trick, the seed is reproducible
> >> > from one build to
> >> > the next one (of the exact same source tree), and does provide much more
> >> > randomness than
> >> > just using 0 all the time.
> >>
> >> In practice I think it is fine to just pass the source file name to
> >> -frandom-seed. That's what the patch I sent out does. The source file
> >> name should be unique within a given program.
> >
> > Isn't the filename already encoded in what get_file_function_name returns?
> > It is __, so IMHO
> > -frandom-seed=$@ brings almost no advantages at all over -frandom-seed=0.
> > Except perhaps for the characters from the filename that are
> > wiped into _ by clean_symbol_name.
>
> That's a fair point, but I guess I still think using the file name with
> -frandom-seed is going to be more future-proof against other users of
> random numbers.
Using the md5sum of the file is probably not bad neither. I would understand
that you
find it being perhaps too complex for your need, but it is much more random
than just the
file name (because the md5sum changes with the file content).
Cheers.
--
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} ***
Please apply toplevel patches to both gcc and src
I'd like to remind people that when they commit a toplevel build system patch to GCC they should commit it to the src repository as well, or ask a build system maintainer to do so if they don't have write access to src. It looks like at least the following recent patches have not been committed to src. 2011-07-20 David Edelsohn * Makefile.tpl (POSTSTAGE1_CONFIGURE_FLAGS): Add libsupc++ to link directories. * Makefile.in: Rebuild. 2011-07-20 Ian Lance Taylor PR bootstrap/49787 * configure.ac: Move --enable-bootstrap handling earlier in file. If --enable-bootstrap and either --enable-build-with-cxx or --enable-build-poststage1-with-cxx, enable C++ automatically. * configure: Rebuild. 2011-07-19 Ian Lance Taylor * configure.ac: Add --enable-build-poststage1-with-cxx. If set, make C++ a boot_language. Set and substitute POSTSTAGE1_CONFIGURE_FLAGS. * Makefile.tpl (POSTSTAGE1_CONFIGURE_FLAGS): New variable. (STAGE[+id+]_CONFIGURE_FLAGS): Add $(POSTSTAGE1_CONFIGURE_FLAGS). * configure, Makefile.in: Rebuild. 2011-07-16 Jason Merrill * Makefile.def (language=c++): Add check-c++0x and check-target-libmudflap-c++. * Makefile.tpl (check-target-libmudflap-c++): New. * Makefile.in: Regenerate. 2011-07-16 Matthias Klose * Makefile.tpl (EXTRA_CONFIGARGS_LIBJAVA): Define. * Makefile.def (target_modules/libjava): Pass $(EXTRA_CONFIGARGS_LIBJAVA). * configure.ac: Pass --disable-static in EXTRA_CONFIGARGS_LIBJAVA, if not configured with --enable-static-libjava. * Makefile.in: Regenerate. * configure: Likewise. 2011-07-15 Jason Merrill * Makefile.in (check-c++): Move check-gcc-c++0x after check-target-libstdc++-v3. 2011-07-13 Jason Merrill * Makefile.in (check-gcc-c++0x): New. (check-c++): Depend on it. 2011-06-22 Hans-Peter Nilsson PR regression/47836 PR bootstrap/23656 PR other/47733 PR bootstrap/49247 PR c/48825 * configure.ac (target_libraries): Remove target-libiberty. Remove case-statement setting skipdirs=target-libiberty for multiple targets. Remove checking target_configdirs and removing target-libiberty but keeping target-libgcc if otherwise empty. * Makefile.def (target_modules): Don't add libiberty. (dependencies): Remove all traces of target-libiberty. * configure, Makefile.in: Regenerate. -- Joseph S. Myers jos...@codesourcery.com
Re: PATCH RFA: Build stages 2 and 3 with C++
Basile Starynkevitch writes: > Using the md5sum of the file is probably not bad neither. I would understand > that you > find it being perhaps too complex for your need, but it is much more random > than just the > file name (because the md5sum changes with the file content). Granted, but I am concerned about the affect on bootstrap time. Ian
Re: C99 Status - inttypes.h
Basile Starynkevitch writes: > This brings another question. Can a GCC pass use intptr_t (the standard int > of the same > size as a void* pointer)? This is quite useful, for instance when one wants > to compute an > hash, or a unique sorted rank (to be used inside B-trees) from the address of > a gimple > or a tree. Yes. There are a number of uses of intptr_t already in the gcc source code. We can get away with this because the configure script uses AC_TYPE_INTPTR_T (via GCC_STDINT_TYPES). Ian
gcc-4.5-20110721 is now available
Snapshot gcc-4.5-20110721 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20110721/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_5-branch revision 176594 You'll find: gcc-4.5-20110721.tar.bz2 Complete GCC MD5=7cbda425f9a00b77c2161a006c5b7901 SHA1=e7a260d25d24000214ad15b72c8f3739d2fe9c69 Diffs from 4.5-20110714 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 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: C99 Status - inttypes.h
On 07/21/2011 06:44 PM, Joe Buck wrote: > On Thu, Jul 21, 2011 at 07:30:16AM -0700, Joseph S. Myers wrote: >> On Thu, 21 Jul 2011, Diogo Sousa wrote: >> >>> Hi, >>> >>> I checked the "library functions in " item in c99status >>> (marked as "Library Issue") [http://gcc.gnu.org/c99status.html], and it >>> seems that glibc implements everything the standard demands. >>> >>> Am I missing something or is this outdated? If so, where can I find more >>> information about it? >> >> "Library Issue" simply means it's not GCC's resposibility; it says nothing >> about the state in any particular library that may be used with GCC. > > But readers will focus on the word "Issue" here and think that there is > something missing. Perhaps there should be a footnote explaining that > glibc/eglibc has the needed support, but that other libraries might not. > I agree. It should say something as "Library Dependent", and report glibc status. signature.asc Description: OpenPGP digital signature
