Re: sed: command garbled

Re: sed: command garbled

[Phil Edwards]

> >> > breaks a build when libstdc++-v3 is enabled:
> >> 
> >> Yup, I've already posted another patch that addresses this problem.
>
> > Which patch was it, so I can push for inclusion
>
> It's already checked in.  Update your tree to the current HEAD and you
> should get it.

I already had the current HEAD, and just now updated it to be sure.
The problem is fixed with the configuration defaults, but passing
--enable-libstdcxx-v3 breaks it again.

And I can't seem to come up with a minimal change to configure.in that
lets it work.  The amount of nested quoting required is just too much.
(It's around line 54 currently, setting libstdcxx_flags.)  There's probably
a clean solution, but one that requires more rewriting, and I don't know
what that section of the script is supposed to do.


Phil
P.S.- Should that top-level configure.in really have /bin/bash as its
      #! invocation line?  I'm all for a Bourne shell that doesn't suck,
      but is that safe?

Re: sed: command garbled

[Alexandre Oliva]

On Aug  3, 2000, Phil Edwards <pedwards@disaster.jaj.com> wrote:

> I already had the current HEAD, and just now updated it to be sure.
> The problem is fixed with the configuration defaults, but passing
> --enable-libstdcxx-v3 breaks it again.

What do you get for CXX_FOR_TARGET in the top-level Makefile?

> P.S.- Should that top-level configure.in really have /bin/bash as its
>       #! invocation line?  I'm all for a Bourne shell that doesn't suck,
>       but is that safe?

It just doesn't matter at all.  configure.in is always run with
${CONFIG_SHELL-/bin/sh}.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: sed: command garbled

[Alexandre Oliva]

On Aug  3, 2000, Phil Edwards <pedwards@disaster.jaj.com> wrote:

> I already had the current HEAD, and just now updated it to be sure.
> The problem is fixed with the configuration defaults, but passing
> --enable-libstdcxx-v3 breaks it again.

Let me guess: are you running Solaris?  Solaris' /bin/sh behaves
differently regarding nested backticks and quotes.  That must be the
problem.  Oh, well, back to the drawing board... :-(

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: sed: command garbled

[Alexandre Oliva]

On Aug  3, 2000, Phil Edwards <pedwards@disaster.jaj.com> wrote:

>> What do you get for CXX_FOR_TARGET in the top-level Makefile?

> This is going to be horribly linewrapped...

Thanks.  It's right (for some value of right that doesn't match
Solaris' /bin/sh's expectations :-)

> If CONFIG_SHELL is set to bash v2, it works.  With sh and ksh (the
> POSIX sh on Solaris), it fails.

I should have known better.  I had forgot CXX_FOR_TARGET was evaluated
within double-quotes.  The following patch carefully avoids using
double quotes without losing in safety.  (for those who didn't know, a
shell variable after `case' isn't broken into works)

I'm checking this in as an obvious (at least to me) bug fix.  Tested
on i686-pc-linux-gnu and sparc-sun-solaris2.6.

Re: sed: command garbled

[Phil Edwards]

Combining your messages...

> What do you get for CXX_FOR_TARGET in the top-level Makefile?

This is going to be horribly linewrapped...

CXX_FOR_TARGET = $$r/gcc/g++ -nostdinc++ `test "x$$dir" != xlibstdc++-v3 &&
  test -f $$r/$(TARGET_SUBDIR)/libstdc++-v3/mkcheck &&
  $(SHELL) $$r/$(TARGET_SUBDIR)/libstdc++-v3/mkcheck 2
  $$r/$(TARGET_SUBDIR)/libstdc++-v3 $$s/libstdc++-v3 | sed -e "s/-I/-isystem /g"`
  -L$$r/$(TARGET_SUBDIR)/libstd++-v3/src
  -L$$r/$(TARGET_SUBDIR)/libstd++-v3/src/.libs $(FLAGS_FOR_TARGET)



> > P.S.- Should that top-level configure.in really have /bin/bash as its
> >       #! invocation line?  I'm all for a Bourne shell that doesn't suck,
> >       but is that safe?
>
> It just doesn't matter at all.  configure.in is always run with
> ${CONFIG_SHELL-/bin/sh}.

Ah.  Maybe it should be #!/bin/ignored or something.


> Let me guess: are you running Solaris?  Solaris' /bin/sh behaves
> differently regarding nested backticks and quotes.  That must be the
> problem.  Oh, well, back to the drawing board... :-(

Uck.  Solaris' /bin/sh is non-POSIX-compliant, and due to demands from very
well-paying customers, it's apparently not going to change.  (According to
Sun employees on Usenet.)

If CONFIG_SHELL is set to bash v2, it works.  With sh and ksh (the POSIX
sh on Solaris), it fails.


Phil

Re: sed: command garbled

[Alexandre Oliva]

On Aug  3, 2000, Phil Edwards <pedwards@disaster.jaj.com> wrote:

>> > breaks a build when libstdc++-v3 is enabled:
>> 
>> Yup, I've already posted another patch that addresses this problem.

> Which patch was it, so I can push for inclusion

It's already checked in.  Update your tree to the current HEAD and you
should get it.

If you really want the patch, please search the recent gcc-patches
archives.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: sed: command garbled

[Mike Stump]

> Date: Mon, 31 Jul 2000 13:46:24 -0400
> From: Phil Edwards <pedwards@disaster.jaj.com>
> To: gcc-bugs@gcc.gnu.org
> Cc: aoliva@redhat.com

> (What is "Cygnus configure" and why is it used in the top-level
> instead of autoconf?  Or would I be happier not knowing?  :-)

Bwa ha ha ha  :-)  The later...
>From David.Billinghurst@riotinto.com Mon Jul 31 22:30:00 2000
From: "Billinghurst, David (CRTS)" <David.Billinghurst@riotinto.com>
To: "'Rainer Orth'" <ro@TechFak.Uni-Bielefeld.DE>
Cc: "'gcc-bugs@gcc.gnu.org'" <gcc-bugs@gcc.gnu.org>, "'ghazi@caip.rutgers.edu'" <ghazi@caip.rutgers.edu>
Subject: RE: Results for 2.96 20000725 (experimental) testsuite on mips-sgi-irix6.2
Date: Mon, 31 Jul 2000 22:30:00 -0000
Message-id: <A9E96A79C068D211A6A90000C07BDF0D88F1B7@crtsmail.crts.techaust.riotinto.com.au>
X-SW-Source: 2000-07/msg00791.html
Content-length: 1192

OK.  This works for me if I do it in the gcc directory, but not when I do it
top-level directory.   Looks like RUNTESTFLAGS gets mangled when passed down
by the top Makefile.  

Now I see that

   make RUNTESTFLAGS='--target_board \"unix{,-mabi=64}\"' check

works from the top level. 


> -----Original Message-----
> From:	Rainer Orth [SMTP:ro@TechFak.Uni-Bielefeld.DE]
> Sent:	Saturday, 29 July 2000 0:45
> To:	Billinghurst, David (CRTS)
> Subject:	RE: Results for 2.96 20000725 (experimental) testsuite on
> mips-sg 	i-irix6.2
> 
> Hi David,
> 
> > What flags did you add to "make check" to run  the testsuite with and
> > without -mabi-64.  I have been trying all sorts of things on irix6.5 but
> > just can't get it to work.
> 
> 	make RUNTESTFLAGS='--target_board "unix{,-mabi=64}"' check
> 
> worked for me.  I've added _RLD_ARGS='-log /dev/fd/2' to the environment
> to
> work around SGIs stupid idea to write runtime linker errors to /dev/tty,
> so
> they didn't show up in the logs.
> 
> 	Rainer
> 
> --------------------------------------------------------------------------
> ---
> Rainer Orth, Faculty of Technology, Bielefeld University
> 
> Email: ro@TechFak.Uni-Bielefeld.DE
>From martin.kahlert@infineon.com Tue Aug 01 00:31:00 2000
From: Martin Kahlert <martin.kahlert@infineon.com>
To: gcc-bugs@gcc.gnu.org
Subject: Wrong warnings in g77
Date: Tue, 01 Aug 2000 00:31:00 -0000
Message-id: <200008010731.JAA29916@keksy.muc.infineon.com>
X-SW-Source: 2000-08/msg00000.html
Content-length: 657

Hi!
The snapshots of g77 seem to warn a lot about unused variables
in my prog. These variables aren't unused at all, since they are inside
named common blocks. In the following example, bar2 isn't unused,
because it could be used in other subroutines.
I would prefer, that g77 omits the warning about BAR, too, because
the common block 'name' is included in more than one subroutine and
every subroutine uses other parts of it.

      SUBROUTINE FOO
      COMMON /NAME/ BAR, BAR2
      INTEGER*4 BAR, BAR2

      BAR2 = 1
      RETURN
      END

Bye,
Martin.

PS: I see a near 30% performance boost in some parts of my prog.
    Thanks for that super work!
>From C.vanReeuwijk@its.tudelft.nl Tue Aug 01 01:48:00 2000
From: "C. van Reeuwijk" <C.vanReeuwijk@its.tudelft.nl>
To: gcc-bugs@gcc.gnu.org
Subject: Re: New Cpp not right for non-C files
Date: Tue, 01 Aug 2000 01:48:00 -0000
Message-id: <20000801104833.B9297@falcon.pds.twi.tudelft.nl>
References: <200007270322.NAA25921@kobold.cit.gu.edu.au> <20000726204919.O26565@wolery.cumb.org>
X-SW-Source: 2000-08/msg00001.html
Content-length: 751

> We suggest you use a real general-purpose macro preprocessor, such as
> M4, instead.

<shudder>

Although in theory M4 is capable of doing any substitution job, it, err,
takes some getting used to. There are other preprocessors out there that
are easier to use. One of them is a program that I have written, called
Tm. See < http://www.pds.twi.tudelft.nl/~reeuwijk/software/Tm/index.html >.
Don't be fooled by the emphasis on code generation for data-structure
manipulation, there is a very capable preprocessor in there. The original
poster may even prefer it over cpp.

Tm is a mature program (10 years of active duty), and is available under
the GPL.

-- 
Kees van Reeuwijk, Delft University of Technology
http://www.pds.twi.tudelft.nl/~reeuwijk
>From masklin@debian.org Tue Aug 01 04:36:00 2000
From: Chris Leishman <masklin@debian.org>
To: bug-gcc@gnu.org
Subject: Parser failure with optimiser output code when using templates.
Date: Tue, 01 Aug 2000 04:36:00 -0000
Message-id: <20000801213628.A30843@freeonline.com.au>
X-SW-Source: 2000-08/msg00002.html
Content-length: 1650

/*

gcc version:    gcc version 2.95.2 20000220 (Debian GNU/Linux)
OS:             Debian GNU/Linux (woody)
kernel:         2.2.16 (SMP)

compiled with:  g++ -Wall gcc-bug.cc


The following code will build fine if NO_TEMPLATE is defined.  If, however,
templates are used then the following errors occur:

gcc-bug.cc: In method `void Tester<int>::test()':
gcc-bug.cc:43:   instantiated from here
gcc-bug.cc:32: `volatile' undeclared (first use this function)
gcc-bug.cc:32: (Each undeclared identifier is reported only once
gcc-bug.cc:32: for each function it appears in.)
gcc-bug.cc:32: warning:  qualifier ignored on asm


The code using asm was produced by gcc as an optimisation, which I striped out
from the preprocessed source to use in this example.

*/

//#define NO_TEMPLATE


#ifndef NO_TEMPLATE
template <class T>
#endif
class Tester
{
public:
	void test();
};


#ifndef NO_TEMPLATE
template <class T> void
Tester<T> :: test()
#else
void
Tester :: test()
#endif
{
	int port = 1;
	int port2;

	port2 = (__extension__   ({ register unsigned short int __v; if (__builtin_constant_p (  port  ))    __v = ((((   port   ) >> 8) & 0xff) | (((   port   ) & 0xff) << 8)) ;   else    __asm__ __volatile__ ("rorw $8, %w0"    : "=r" (__v)    : "0" ((unsigned short int) (  port  )) : "cc");    __v; }))  ;
}


int main()
{
#ifndef NO_TEMPLATE
	Tester<int> x;
#else
	Tester x;
#endif
	x.test();
	return 0;
}
-- 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.2 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjmGtjwACgkQlBjBIrTiQhm7oACghw2/Bc1M+/kbi6vE/C8YLc1t
1ZEAn0ZfzhtO6LsQzSM5CnxaFJBkZDrf
=e3BU
-----END PGP SIGNATURE-----
>From espie@quatramaran.ens.fr Tue Aug 01 06:19:00 2000
From: Marc Espie <espie@quatramaran.ens.fr>
To: Alexandre Oliva <aoliva@redhat.com>, Zack Weinberg <zack@wolery.cumb.org>, gcc-bugs@gcc.gnu.org
Subject: gcc 2000-07-31 bootstrap problem
Date: Tue, 01 Aug 2000 06:19:00 -0000
Message-id: <20000801151907.A3849@quatramaran.ens.fr>
X-SW-Source: 2000-08/msg00003.html
Content-length: 3452

I think either Alexandre or Zack may know what's going on and how to fix it,
since Zack is playing with cpp, and Alexandre is playing with configure 
machinery.

2000-07-31 fails bootstrapping at the end of stage 3, in the library build 
stage.

Here's the issue (recompiled with -v)
rootme=`pwd`/ ; export rootme;  CC="/var/www/work/lang/egcs/snapshot/build-i386/gcc/xgcc -B/var/www/work/lang/egcs/snapshot/build-i386/gcc/ -B/usr/local/i386-unknown-openbsd2.7/bin/ -B/usr/local/i386-unknown-openbsd2.7/lib/ -isystem /usr/local/i386-unknown-openbsd2.7/include -I. -I/usr/ports/lang/egcs/snapshot/work/egcs-20000731/libio"; export CC;  CXX="c++ -v -B/var/www/work/lang/egcs/snapshot/build-i386/gcc/ -B/usr/local/i386-unknown-openbsd2.7/bin/ -B/usr/local/i386-unknown-openbsd2.7/lib/ -isystem /usr/local/i386-unknown-openbsd2.7/include -I. -I/usr/ports/lang/egcs/snapshot/work/egcs-20000731/libio -nostdinc++ -nostdinc++ -O2 -g"; export CXX;  CONFIG_NM="nm"; export CONFIG_NM;  /bin/sh /usr/ports/lang/egcs/snapshot/work/egcs-20000731/libio/gen-params LIB_VERSION=2.8.0  >tmp-params.h
Reading specs from /var/www/work/lang/egcs/snapshot/build-i386/gcc/specs
gcc driver version 2.95.2 19991024 (release) executing gcc version 2.96
 /var/www/work/lang/egcs/snapshot/build-i386/gcc/cpp -lang-c++ -nostdinc++ -nostdinc++ -v -I. -I/usr/ports/lang/egcs/snapshot/work/egcs-20000731/libio -isystem /usr/local/i386-unknown-openbsd2.7/lib/include -isystem /usr/local/i386-unknown-openbsd2.7/bin/include -isystem /var/www/work/lang/egcs/snapshot/build-i386/gcc/include -D__GNUC__=2 -D__GNUG__=2 -D__GNUC_MINOR__=96 -D__cplusplus -D__unix__ -D__OpenBSD__ -D__unix__ -D__OpenBSD__ -Asystem(unix) -Asystem(bsd) -Asystem(OpenBSD) -D__EXCEPTIONS -D__OPTIMIZE__ -g -isystem /usr/local/i386-unknown-openbsd2.7/include dummy.C /tmp/ccV11500.ii
Reading specs from /usr/local/lib/gcc-lib/i386-unknown-openbsd2.7/2.96/specs
gcc version 2.96 20000731 (experimental)
 cpp0 -lang-c++ -nostdinc++ -nostdinc++ -v -Asystem(unix) -Asystem(bsd) -Asystem(OpenBSD) -I. -I/usr/ports/lang/egcs/snapshot/work/egcs-20000731/libio -iprefix /var/www/work/lang/egcs/snapshot/build-i386/gcc/../lib/gcc-lib/i386-unknown-openbsd2.7/2.96/ -D__unix__ -D__OpenBSD__ -D__unix__ -D__OpenBSD__ -Asystem(unix) -Asystem(bsd) -Asystem(OpenBSD) -g -D__GNUC__=2 -D__GNUG__=2 -D__GNUC_MINOR__=96 -D__cplusplus -D__unix__ -D__OpenBSD__ -D__unix__ -D__OpenBSD__ -D__EXCEPTIONS -D__OPTIMIZE__ -isystem /usr/local/i386-unknown-openbsd2.7/lib/include -isystem /usr/local/i386-unknown-openbsd2.7/bin/include -isystem /var/www/work/lang/egcs/snapshot/build-i386/gcc/include -isystem /usr/local/i386-unknown-openbsd2.7/include dummy.C -o /tmp/ccV11500.ii
cpp: installation problem, cannot exec `cpp0': No such file or directory
gen-params: could not compile dummy.C with c++ -v -B/var/www/work/lang/egcs/snapshot/build-i386/gcc/ -B/usr/local/i386-unknown-openbsd2.7/bin/ -B/usr/local/i386-unknown-openbsd2.7/lib/ -isystem /usr/local/i386-unknown-openbsd2.7/include -I. -I/usr/ports/lang/egcs/snapshot/work/egcs-20000731/libio -nostdinc++ -nostdinc++ -O2 -g

Somehow, gen-params does not get any path for cpp0, even though it is present
in /var/www/work/lang/egcs/snapshot/build-i386/gcc

This suspiciously looks like cpp may now need to understand -B...

Note that installing cpp0 first allows bootstrap to continue, so this is
a failure mode that will not show on machines having gcc already installed
somewhere...
>From aoliva@redhat.com Tue Aug 01 06:29:00 2000
From: Alexandre Oliva <aoliva@redhat.com>
To: Marc Espie <espie@quatramaran.ens.fr>
Cc: Zack Weinberg <zack@wolery.cumb.org>, gcc-bugs@gcc.gnu.org
Subject: Re: gcc 2000-07-31 bootstrap problem
Date: Tue, 01 Aug 2000 06:29:00 -0000
Message-id: <orlmyh156n.fsf@guarana.lsd.ic.unicamp.br>
References: <20000801151907.A3849@quatramaran.ens.fr>
X-SW-Source: 2000-08/msg00004.html
Content-length: 811

On Aug  1, 2000, Marc Espie <espie@quatramaran.ens.fr> wrote:

> CXX="c++ -v -B/var/www/work/lang/egcs/snapshot/build-i386/gcc/ ...
       ^^^
This is wrong.  Any idea why you've got CXX set to c++ instead of
CXX_FOR_TARGET?  Is CXX_FOR_TARGET set in your environment?

The problem is that this old c++ runs cpp instead of cpp0, so it finds
the cpp driver, not the actual preprocessor, now cpp0.  It doesn't
pass the appropriate flags to the cpp driver, since it doesn't expect
it to be a driver, so cpp can't find cpp0.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me