This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC Steering Committee decision on ISO C conversion
- From: "John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>
- To: ghazi at caip dot rutgers dot edu (Kaveh R. Ghazi)
- Cc: gcc at gcc dot gnu dot org
- Date: Sun, 30 Jun 2002 15:45:42 -0400 (EDT)
- Subject: Re: GCC Steering Committee decision on ISO C conversion
> > From: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
> >
> > See PR 7170. The main problem is the string concatenation used in the
> > definition of re_error_msgid. If you have thoughts on a good way to
> > fix this let me know.
>
> I know the problem, in fact gcc-3.x -Wtraditional warns about it when
> compiling regex.c. But I don't have any suggestions on how to fix it
> that are clean and/or minimally invasive.
>
> However AFAICT, we don't actually use libibety's regex.o anywhere in
> gcc so maybe you can just not compile it if configure determines that
> your stage1 compiler is lame. (?)
What about the other packages that use libiberty (eg., binutils)? If
gcc will build the C language using the native tools, then the above
could be a viable bootstrap approach.
I guess what could be done is to initialize re_error_msgid at runtime
in a manner similar to re_syntax_table if the stage1 compiler doesn't
support string concatenation.
> Regarding 7163, this doesn't occur for me either and the warning
> message doesn't say where the second half of the conflict occurred.
> You need to provide preprocessed source for me to be able to offer any
> assistance.
I will try to go through these in detail after the holiday and provide
patches.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)