public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* indent 1.10.0 and glibc 2.1.1
@ 1999-06-18  5:05 Mike Castle
  1999-06-30 23:07 ` Jeffrey A Law
  0 siblings, 1 reply; 6+ messages in thread
From: Mike Castle @ 1999-06-18  5:05 UTC (permalink / raw)
  To: egcs-bugs

On a linux system using egcs 1.1.2 and glibc 2.1.1 I'm trying to build
GNU indent 1.10.0.

Using "./configure --prefix=/usr", it dies with:

gcc -DHAVE_CONFIG_H -I. -I. -I.     -g -O2 -c args.c
args.c: In function `set_option':
args.c:687: void value not ignored as it ought to be
make: *** [args.o] Error 1


-O1 has the same problem.  I have to not use any -O options to get it to 
compile.

mrc
-- 
       Mike Castle       Life is like a clock:  You can work constantly
  dalgoda@ix.netcom.com  and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day.  -- mrc
    We are all of us living in the shadow of Manhattan.  -- Watchmen
>From nathan@acm.org Fri Jun 18 05:29:00 1999
From: Nathan Sidwell <nathan@acm.org>
To: Martin Dorey <martin.dorey@madge.com>
Cc: egcs-bugs@egcs.cygnus.com
Subject: Re: (void)ing unreferenced parameters
Date: Fri, 18 Jun 1999 05:29:00 -0000
Message-id: <376A3AF7.CAD5D@acm.org>
References: <376A25BA.476329@madge.com>
X-SW-Source: 1999-06/msg00553.html
Content-length: 3375

Martin Dorey wrote:

> > fields of that struct to strobe something I understand. I find it hard
> to
> > understand why you'd dink the *whole* struct in one go. But I'm not
> suggesting
> > gratuitously banning it.
> 
> Scenario: you want to read several registers from a device in a loop,
> whose values all change each time you frob the device - once per loop
> iteration.  You have to use volatile, to ensure the dereference doesn't
> get hoisted out of the loop.  You can get the whole struct at once,
> because you know the device's registers won't change except when you
> frob it.  You want to get the whole struct at once, because sequential
> memory accesses are more efficient, perhaps because of memory pipelining
> or because the compiler might then be able to read several byte-wide
> registers with a word-read.
You've changed the ground rules.

I said that given
	struct dev {int reg1; int reg2};
	volatile dev *device = someptr;
I found it hard to understand what you would expect
	*device;
to do. The most you can expect it to do is read the locations and ignore the
result (You'd be wrong for C++, as the read should not happen.) Why would you
do this? The _only_ reason must be that a read had a side effect of changing
the device's state. In which case you need to be absolutely certain in which
order and with which atomicity the device's registers were accessed. There are
no guarentees in reading an entire struct in one go.

You give an example where you do
	while(whenever) {
	  dev copy = *device; // doesn't change state
	  ... do something
	  device->reg1 = somecommand; // change device's state
	}

You'd like `copy = *device' to happen in one go for efficiency. You lose.

You can say to the compiler either a) this object behaves just like memory (not
volatile qualified), b) this object does not behave just like memory
(volatile).
What you wanted to say is c) reads can be combined and reordered wrt reads, but
writes cannot be reordered or combined.

Hardware cache control and memory interfaces generally give only a and b too.
not c.

If you want it read in one go you might try
	memcpy(&copy, device, sizeof(dev));
and hope the compiler inlines it (egcs should do). or
	copy = *(dev *)device;
but I'm not sure how legal that is and how it might interfere with type based
alias analysis. If `dev' and `volatile dev' are treated as different types,
you've now given the compiler license to reorder the reads with the write and
all bets are off.

> Scenario: you want to save the whole state of the device in one go.
> Again, you need to be sure that you're going to read a consistent state.
You've changed the ground rules *again*. In the example you gave, you wanted to
get the thing on one go for *efficiency*. Now you're saying you need to get it
in one go for *consistency*. If this is the case you've now reverted to a
device where a read changes its state. This is an even worse situation and
there's no way to tell the compiler both
1) don't rearrange reads because they do something strange (volatile)
2) you have to combine (i.e. rearrange) these reads
there might be *no* way to atomically read the locations.

nathan

-- 
Dr Nathan Sidwell :: Computer Science Department :: Bristol University
        I have seen the death of PhotoShop -- it is called GIMP
nathan@acm.org  http://www.cs.bris.ac.uk/~nathan/  nathan@cs.bris.ac.uk
>From Didier.Spezia@sip.fr Fri Jun 18 06:24:00 1999
From: Didier.Spezia@sip.fr
To: egcs-bugs@egcs.cygnus.com
Subject: Problems with AIX and shared libs
Date: Fri, 18 Jun 1999 06:24:00 -0000
Message-id: <C1256794.0045F1F4.00@applications.sip.fr>
X-SW-Source: 1999-06/msg00554.html
Content-length: 4345

Hi all !

I'm trying to compile EGCS 1.1.2 on an AIX 4.1.5 platform with the
--enable-shared option enabled.

The build of the compiler works flawlessly, but when I want to
compile a simple hello world program using iostreams ( e.g.
any program linked with the stdc++ library ), the execution of
the produced binary fails with the following message :

Could not load program a.out
Could not load library .
Error was: Permission denied

The same program compiled with the -static flag works fine.

I wish to make it clear that I've applied the fix for APAR IX75823
on the AIX linker and the LIBPATH environment variable is correctly
set.

I think the build of the stdc++ shared library could be broken.

Here is the verbose output of g++ :

-----------------------------------------------------------

spezia@garfield:~/perso/test/dyn> g++ -v hello.cc
Reading specs from
/softs/egcs/lib/gcc-lib/powerpc-ibm-aix4.1.5.0/egcs-2.91.66/specs
gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)
 /softs/egcs/lib/gcc-lib/powerpc-ibm-aix4.1.5.0/egcs-2.91.66/cpp -lang-c++
-v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -D__GNUC_MINOR__=91
-D_IBMR2 -D_POWER -D_AIX -D_AIX32 -D_AIX41 -D_LONG_LONG -D_IBMR2 -D_POWER
-D_AIX -D_AIX32 -D_AIX41 -D_LONG_LONG -Asystem(unix) -Asystem(aix)
-D__EXCEPTIONS -D__CHAR_UNSIGNED__ -D_ARCH_COM hello.cc /tmp/cc51RO5e.ii
GNU CPP version egcs-2.91.66 19990314 (egcs-1.1.2 release)
#include "..." search starts here:
#include <...> search starts here:
 /softs/egcs/include/g++
 /usr/local/include
 /softs/egcs/powerpc-ibm-aix4.1.5.0/include
 /softs/egcs/lib/gcc-lib/powerpc-ibm-aix4.1.5.0/egcs-2.91.66/include
 /usr/include
End of search list.
 /softs/egcs/lib/gcc-lib/powerpc-ibm-aix4.1.5.0/egcs-2.91.66/cc1plus
/tmp/cc51RO5e.ii -quiet -dumpbase hello.cc -version -o /tmp/ccrJdZdb.s
GNU C++ version egcs-2.91.66 19990314 (egcs-1.1.2 release)
(powerpc-ibm-aix4.1.5.0) compiled by GNU C version egcs-2.91.66 19990314
(egcs-1.1.2 release).
 as -u -mcom -o /tmp/cchbl4o2.o /tmp/ccrJdZdb.s
 /softs/egcs/lib/gcc-lib/powerpc-ibm-aix4.1.5.0/egcs-2.91.66/collect2
-bpT:0x10000000 -bpD:0x20000000 -btextro -bnodelcsect /lib/crt0.o
-L/softs/egcs/lib/gcc-lib/powerpc-ibm-aix4.1.5.0/egcs-2.91.66
-L/softs/egcs/powerpc-ibm-aix4.1.5.0/lib -L/softs/egcs/lib /tmp/cchbl4o2.o
-lstdc++ -lm
/softs/egcs/lib/gcc-lib/powerpc-ibm-aix4.1.5.0/egcs-2.91.66/libgcc.a -lc
/softs/egcs/lib/gcc-lib/powerpc-ibm-aix4.1.5.0/egcs-2.91.66/libgcc.a

-----------------------------------------------------------

spezia@garfield:~/perso/test/dyn> dump -H a.out
a.out:

                        ***Loader Section***
                      Loader Header Information
VERSION#         #SYMtableENT     #RELOCent        LENidSTR
0x00000001       0x0000000a       0x0000001c       0x0000009f

#IMPfilID        OFFidSTR         LENstrTBL        OFFstrTBL
0x00000003       0x00000260       0x00000083       0x000002ff


                        ***Import File Strings***
INDEX  PATH                          BASE                MEMBER

0
/softs/egcs/lib/gcc-lib/powerpc-ibm-aix4.1.5.0/egcs-2.91.66:/softs/egcs/pow
erpc-ibm-aix4.1.5.0/lib:/softs/egcs/lib:/usr/lib:/lib

1                                    libc.a              shr.o

2                                    libstdc++.a


Ok, all is normal here.

-----------------------------------------------------------

spezia@garfield:~/perso/test/dyn> dump -H /softs/egcs/lib/libstdc++.a

2:52PM
/softs/egcs/lib/libstdc++.a:

                        ***Loader Section***
                      Loader Header Information
VERSION#         #SYMtableENT     #RELOCent        LENidSTR
0x00000001       0x000004e7       0x00000eb3       0x00000044

#IMPfilID        OFFidSTR         LENstrTBL        OFFstrTBL
0x00000003       0x0001262c       0x0000a5eb       0x00012670


                        ***Import File Strings***
INDEX  PATH                          BASE                MEMBER

0      /users/spezia/perso/egcsbuild/gcc:/usr/lib:/lib

1                                    libc.a              shr.o

2                                    .


Note that the number 2 entry in the import file strings table seems to be
wrong ;
it's probably the reason of my problem.

-----------------------------------------------------------

Does anyone succeed in using dynamic linking on such a platform ?

Best regards,
DS




^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: indent 1.10.0 and glibc 2.1.1
  1999-06-30 23:07     ` Andreas Jaeger
@ 1999-06-19  9:36       ` Mike Castle
  1999-06-30 23:07       ` Ulrich Drepper
  1 sibling, 0 replies; 6+ messages in thread
From: Mike Castle @ 1999-06-19  9:36 UTC (permalink / raw)
  To: Carlo Wood, libc-alpha, Mike Castle; +Cc: egcs-bugs, bug-glibc

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 6909 bytes --]

On Sat, Jun 19, 1999 at 08:27:58AM +0200, Andreas Jaeger wrote:
> this is a problem that's not related to egcs but to glibc and indent.
> I'm therefore changing the mail adresses again and have set a
> reply-to.
> 
> The problem is that glibc uses inline macros and functions for string
> functions (see  <bits/string.h> and <bits/string2.h>).  If you disable 
> those (compile with -D__NO_STRING_INLINES) args.c compiles.  I've been 
> able to reproduce the problem with the following small program:
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[Deleted]

Ok.  Thanks.  Now I'm convinced.  :->

> Carlo, the indent author might fix his configure test (it checks
> for memcpy) and sys.h which uses:
> /* configure defines USG if it can't find bcopy */
> 
> #ifndef USG
> #define memcpy(dest,src,len) bcopy((src),(dest),len)
> #endif
> but apparently configure neither sets USG nor checks for bcopy.

This code was in the sys.h that came from indent 1.9.1.  And the configure 
from 1994 DID check for USG.

My solution was to simply remove the USG block in sys.h.

My apologies to Jeffrey Law.  He was right.

Regards,
mrc
-- 
       Mike Castle       Life is like a clock:  You can work constantly
  dalgoda@ix.netcom.com  and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day.  -- mrc
    We are all of us living in the shadow of Manhattan.  -- Watchmen
>From Stephane.Conversy@lri.fr Sat Jun 19 09:53:00 1999
From: Stephane Conversy <Stephane.Conversy@lri.fr>
To: egcs-bugs@egcs.cygnus.com
Subject: internal error: scope_die_for bug on sgi
Date: Sat, 19 Jun 1999 09:53:00 -0000
Message-id: <376BCAEF.7EAEC5AE@lri.fr>
X-SW-Source: 1999-06/msg00616.html
Content-length: 4850

gcc version: gcc-2.95 19990615 (prerelease) (but i think it's the 19990616...)
system: sgi o2 irix-6.3
options: -O2 -funroll-loops -g
ii file location: http://www-ihm.lri.fr/~conversy/egcs/cabinet.ii.gz
result:
../src/qui/cabinet.cc: In method `Cabinet::Cabinet(UI *, int, int)':
../src/qui/cabinet.cc:117: Internal compiler error in `scope_die_for',
at dwarf2out.c:7788
Please submit a full bug report to `egcs-bugs@egcs.cygnus.com'.
See <URL: http://egcs.cygnus.com/faq.html#bugreport > for details.
 
here is the long version:
(sgi3) ~/Archives/quasimodo-0.1.6/build > g++ -v -savetemps -g -I/usr/freeware/
include -O2 -funroll-loops -W -Wimplicit    -I. -I./include
-I/u/conversy/local
/lib/Gtk--/include -I/u/conversy/local/include -I/u/conversy/local/lib/glib/inc
lude -I/u/conversy/local/lib/sigc++/include -I/u/conversy/local/include 
-c ../
src/qui/cabinet.cc -o cabinet.o
Reading specs from /usr/freeware/lib/gcc-lib/mips-sgi-irix6.3/gcc-2.95/specs
g++: unrecognized option `-savetemps'
gcc version gcc-2.95 19990615 (prerelease)
 /usr/freeware/lib/gcc-lib/mips-sgi-irix6.3/gcc-2.95/cpp -lang-c++
-v -I/usr/freeware/include -I. -I./include -I/u/conversy/local/lib/Gtk--/include
-I/u/conversy/local/include -I/u/conversy/local/lib/glib/include -I/u/conversy/local/lib/sigc++/include
-I/u/conversy/local/include -D__GNUC__=2 -D__GNUG__=2 -D__GNUC_MINOR__=95
-D__cplusplus -Dunix -Dmips -Dsgi -Dhost_mips -DMIPSEB -D_MIPSEB -DSYSTYPE_SVR4
-D_LONGLONG -D_SVR4_SOURCE -D_MODERN_C -D__DSO__ -D__unix__ -D__mips__
-D__sgi__ -D__host_mips__ -D__MIPSEB__ -D_MIPSEB -D__SYSTYPE_SVR4__ -D_LONGLONG
-D_SVR4_SOURCE -D_MODERN_C -D__DSO__ -D__unix -D__mips -D__sgi -D__host_mips
-D__MIPSEB -D__SYSTYPE_SVR4 -Asystem(unix) -Asystem(svr4) -Acpu(mips) -Amachine(sgi)
-D__EXCEPTIONS -D__CHAR_UNSIGNED__ -D__OPTIMIZE__ -g -W -Wimplicit -D__LANGUAGE_C_PLUS_PLUS
-D_LANGUAGE_C_PLUS_PLUS -D__SIZE_TYPE__=unsigned int -D__PTRDIFF_TYPE__=int
-D__EXTENSIONS__ -D_SGI_SOURCE -D_MIPS_FPSET=32 -D_MIPS_ISA=_MIPS_ISA_MIPS3
-D_ABIN32=2 -D_MIPS_SIM=_ABIN32 -D_MIPS_SZINT=32 -D_MIPS_SZLONG=32 -D_MIPS_SZPTR=32
-D_COMPILER_VERSION=601 -U__mips -D__mips=3 -D__mips64 ../src/qui/cabinet.cc
/var/tmp/ccZ5aaaa.ii
GNU CPP version gcc-2.95 19990615 (prerelease) [AL 1.1, MM 40] SGI
running IRIX 6.x
#include "..." search starts here:
#include <...> search starts here:
 /usr/freeware/include
 .
 include
 /u/conversy/local/lib/Gtk--/include
 /u/conversy/local/include
 /u/conversy/local/lib/glib/include
 /u/conversy/local/lib/sigc++/include
 /u/conversy/local/include
 /usr/freeware/lib/gcc-lib/mips-sgi-irix6.3/gcc-2.95/../../../../include/g++-2
 /usr/local/include
 /usr/freeware/lib/gcc-lib/mips-sgi-irix6.3/gcc-2.95/../../../../mips-sgi-irix6.3/include
 /usr/freeware/lib/gcc-lib/mips-sgi-irix6.3/gcc-2.95/include
 /usr/include
End of search list.
The following default directories have been omitted from the search
path:
End of omitted list.
 /usr/freeware/lib/gcc-lib/mips-sgi-irix6.3/gcc-2.95/cc1plus /var/tmp/ccZ5aaaa.ii
-quiet -dumpbase cabinet.cc -g -O2 -W -Wimplicit -version -funroll-loops
-o /var/tmp/ccO1baaa.s
GNU C++ version gcc-2.95 19990615 (prerelease) (mips-sgi-irix6.3) compiled
by GNU C version gcc-2.95 19990615 (prerelease).
In file included from /usr/freeware/lib/gcc-lib/mips-sgi-irix6.3/gcc-2.95/../../../../include/g++-2/iostream.h:31,
                
from ../src/qui/cabinet.cc:20:
/usr/freeware/lib/gcc-lib/mips-sgi-irix6.3/gcc-2.95/../../../../include/g++-2/streambuf.h:
In method `ios::~ios()':
/usr/freeware/lib/gcc-lib/mips-sgi-irix6.3/gcc-2.95/../../../../include/g++-2/streambuf.h:485:
warning: `void *' is not a pointer-to-object type
In file included from /u/conversy/local/include/sigc++/object.h:4,
                
from /u/conversy/local/include/sigc++/slot.h:27,
                
from /u/conversy/local/include/sigc++/signal_system.h:28,
                
from include/sigcpp.h:24,
                
from include/transmitter.h:26,
                
from include/error.h:23,
                
from include/qm.h:37,
                
from ../src/qui/cabinet.cc:27:
/u/conversy/local/include/sigc++/scope.h: In method `SigC::Scope::Scope(const
SigC::Scope &)':
/u/conversy/local/include/sigc++/scope.h:124: warning: base class `struct
SigC::ScopeNode' should be explicitly initialized in the copy constructor
../src/qui/cabinet.cc: In method `Cabinet::Cabinet(UI *, int, int)':
../src/qui/cabinet.cc:117: Internal compiler error in `scope_die_for',
at dwarf2out.c:7788
Please submit a full bug report to `egcs-bugs@egcs.cygnus.com'.
See <URL: http://egcs.cygnus.com/faq.html#bugreport > for details.
 
 
 
 
-- 
Stéphane Conversy
http://www-ihm.lri.fr/~conversy/
mailto:conversy@lri.fr
 


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: indent 1.10.0 and glibc 2.1.1
  1999-06-30 23:07 ` Jeffrey A Law
@ 1999-06-30 23:07   ` Mike Castle
  1999-06-30 23:07     ` Andreas Jaeger
  0 siblings, 1 reply; 6+ messages in thread
From: Mike Castle @ 1999-06-30 23:07 UTC (permalink / raw)
  To: egcs-bugs, bug-glibc

Considering the original response, I am also including bug-glibc@gnu.org.

On Fri, Jun 18, 1999 at 12:40:10PM -0600, Jeffrey A Law wrote:
> 
>   In message < 19990617001241.A15022@thune.netcom.com >you write:
>   > 
>   > On a linux system using egcs 1.1.2 and glibc 2.1.1 I'm trying to build
>   > GNU indent 1.10.0.
>   > 
>   > Using "./configure --prefix=/usr", it dies with:
>   > 
>   > gcc -DHAVE_CONFIG_H -I. -I. -I.     -g -O2 -c args.c
>   > args.c: In function `set_option':
>   > args.c:687: void value not ignored as it ought to be
>   > make: *** [args.o] Error 1
> This sounds like a bug in either the glibc header files or (more likely) the
> gnu-indent code.  It is unlikely this is a bug in egcs.


Well, considering that the include file entry is:

/* Copy SRC to DEST.  */
extern char *strcpy __P ((char *__restrict __dest,
                          __const char *__restrict __src));

and the section of code in args.c is:

        case PRO_KEY:
          {
            register char *str;
            if (*param_start == 0)
              if (!(param_start = param))
                goto arg_missing;
              else
                val = 1;
   
            str = (char *) xmalloc (strlen (param_start) + 1);
            strcpy (str, param_start);
            addkey (str, rw_decl);
          }
          break;


I fail to see where there could be a bug in either the glibc headers or
indent.  Though if someone could point out the exact problem to me, then
I would be convinced.

Moreover, replacing the xmalloc() line with a call to strdup() results in
the same message for strdup().

Modifing the string.h to get rid of __restrict does not help.

Renaming "str" to "foo" does not help (thinking of a possible conflict with
a name).

param_start is declared as: char *param_start;

As I noted in the original mail (for the benefit of glibc folks), building
without optimizations is a work around.  So, it's not like this is stopping
anything.

This is not the first time I've experienced apparently bogus messages from 
egcs 1.1.2.  (I was getting bogus "might be used uninitialized" warnings
when building the package found at:
ftp://sunsite.unc.edu/pub/Linux/system/daemons/at-2.9b.tgz when building
with -O2 or greater; I tried posting about it, but ORBS likes to bogusly
list netcom.com, so my messages only sometimes get through).

I do not see how, in this instance, either the glibc headers or the indent 
source could be causing problems.  And given past experience with suspicious 
egcs operations, I would tend to think that egcs is the culprit here.

mrc
-- 
       Mike Castle       Life is like a clock:  You can work constantly
  dalgoda@ix.netcom.com  and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day.  -- mrc
    We are all of us living in the shadow of Manhattan.  -- Watchmen


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: indent 1.10.0 and glibc 2.1.1
  1999-06-30 23:07     ` Andreas Jaeger
  1999-06-19  9:36       ` Mike Castle
@ 1999-06-30 23:07       ` Ulrich Drepper
  1 sibling, 0 replies; 6+ messages in thread
From: Ulrich Drepper @ 1999-06-30 23:07 UTC (permalink / raw)
  To: Carlo Wood; +Cc: libc-alpha, Mike Castle, egcs-bugs, bug-glibc

Andreas Jaeger <aj@arthur.rhein-neckar.de> writes:

> Now the glibc part.  Is there any chance that we can guard our inline
> string functions against such defines?  Or do we declare such programs 
> as broken?

The latter.  Memcpy is a standard function which must be available and
only the system is allowed to define macros shadowing the declaration.
If the program does it it is not ISo C compliant and everything can
happen.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: indent 1.10.0 and glibc 2.1.1
  1999-06-30 23:07   ` Mike Castle
@ 1999-06-30 23:07     ` Andreas Jaeger
  1999-06-19  9:36       ` Mike Castle
  1999-06-30 23:07       ` Ulrich Drepper
  0 siblings, 2 replies; 6+ messages in thread
From: Andreas Jaeger @ 1999-06-30 23:07 UTC (permalink / raw)
  To: Mike Castle; +Cc: egcs-bugs, bug-glibc, Carlo Wood, libc-alpha

Hi Mike,

this is a problem that's not related to egcs but to glibc and indent.
I'm therefore changing the mail adresses again and have set a
reply-to.

The problem is that glibc uses inline macros and functions for string
functions (see  <bits/string.h> and <bits/string2.h>).  If you disable 
those (compile with -D__NO_STRING_INLINES) args.c compiles.  I've been 
able to reproduce the problem with the following small program:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#include <string.h>

#define memcpy(dest,src,len) bcopy((src),(dest),len)

void
test (void)
{
  register char *str;
  char *param_start;
  strcpy (str, param_start);
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

$ /opt/egcs/bin/gcc -Wall -m486 -O2 -c t.c
t.c: In function `test':
t.c:11: void value not ignored as it ought to be

The problem here is that indent redines memcpy (which is used
internally by the inline function strcpy) to bcopy - and bcopy and
memcpy are not identical since memcpy returns a pointer:
extern void bcopy __P ((__const __ptr_t __src, __ptr_t __dest, size_t __n));
extern __ptr_t memcpy __P ((__ptr_t __restrict __dest,
                            __const __ptr_t __restrict __src, size_t __n));

Ok, now how to fix this?  The short term solution for you, Mike, is to 
use -D__STRING_INLINES to compile indent.

Carlo, the indent author might fix his configure test (it checks
for memcpy) and sys.h which uses:
/* configure defines USG if it can't find bcopy */

#ifndef USG
#define memcpy(dest,src,len) bcopy((src),(dest),len)
#endif
but apparently configure neither sets USG nor checks for bcopy.

Now the glibc part.  Is there any chance that we can guard our inline
string functions against such defines?  Or do we declare such programs 
as broken?


>>>>> Mike Castle writes:

Mike> Considering the original response, I am also including bug-glibc@gnu.org.
Mike> On Fri, Jun 18, 1999 at 12:40:10PM -0600, Jeffrey A Law wrote:
>> 
>> In message < 19990617001241.A15022@thune.netcom.com >you write:
>> > 
>> > On a linux system using egcs 1.1.2 and glibc 2.1.1 I'm trying to build
>> > GNU indent 1.10.0.
>> > 
>> > Using "./configure --prefix=/usr", it dies with:
>> > 
>> > gcc -DHAVE_CONFIG_H -I. -I. -I.     -g -O2 -c args.c
>> > args.c: In function `set_option':
>> > args.c:687: void value not ignored as it ought to be
>> > make: *** [args.o] Error 1
>> This sounds like a bug in either the glibc header files or (more likely) the
>> gnu-indent code.  It is unlikely this is a bug in egcs.


Mike> Well, considering that the include file entry is:

Mike> /* Copy SRC to DEST.  */
Mike> extern char *strcpy __P ((char *__restrict __dest,
Mike>                           __const char *__restrict __src));

Mike> and the section of code in args.c is:

Mike>         case PRO_KEY:
Mike>           {
Mike>             register char *str;
Mike>             if (*param_start == 0)
Mike>               if (!(param_start = param))
Mike>                 goto arg_missing;
Mike>               else
Mike>                 val = 1;
   
Mike>             str = (char *) xmalloc (strlen (param_start) + 1);
Mike>             strcpy (str, param_start);
Mike>             addkey (str, rw_decl);
Mike>           }
Mike>           break;


Mike> I fail to see where there could be a bug in either the glibc headers or
Mike> indent.  Though if someone could point out the exact problem to me, then
Mike> I would be convinced.
It's always good to see the preprocessed expansion of those lines.

Mike> Moreover, replacing the xmalloc() line with a call to strdup() results in
Mike> the same message for strdup().

Mike> Modifing the string.h to get rid of __restrict does not help.

Mike> Renaming "str" to "foo" does not help (thinking of a possible conflict with
Mike> a name).

Mike> param_start is declared as: char *param_start;

Mike> As I noted in the original mail (for the benefit of glibc folks), building
Mike> without optimizations is a work around.  So, it's not like this is stopping
Mike> anything.
Since the inline functions and macros are only used with optimizations.

Mike> This is not the first time I've experienced apparently bogus messages from 
Mike> egcs 1.1.2.  (I was getting bogus "might be used uninitialized" warnings
Mike> when building the package found at:
Mike> ftp://sunsite.unc.edu/pub/Linux/system/daemons/at-2.9b.tgz when building
Mike> with -O2 or greater; I tried posting about it, but ORBS likes to bogusly
Mike> list netcom.com, so my messages only sometimes get through).

Mike> I do not see how, in this instance, either the glibc headers or the indent 
Mike> source could be causing problems.  And given past experience with suspicious 
Mike> egcs operations, I would tend to think that egcs is the culprit here.

In this case egcs is working perfectly.

Andreas
-- 
 Andreas Jaeger   aj@arthur.rhein-neckar.de    jaeger@informatik.uni-kl.de
  for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: indent 1.10.0 and glibc 2.1.1
  1999-06-18  5:05 indent 1.10.0 and glibc 2.1.1 Mike Castle
@ 1999-06-30 23:07 ` Jeffrey A Law
  1999-06-30 23:07   ` Mike Castle
  0 siblings, 1 reply; 6+ messages in thread
From: Jeffrey A Law @ 1999-06-30 23:07 UTC (permalink / raw)
  To: Mike Castle; +Cc: egcs-bugs

  In message < 19990617001241.A15022@thune.netcom.com >you write:
  > 
  > On a linux system using egcs 1.1.2 and glibc 2.1.1 I'm trying to build
  > GNU indent 1.10.0.
  > 
  > Using "./configure --prefix=/usr", it dies with:
  > 
  > gcc -DHAVE_CONFIG_H -I. -I. -I.     -g -O2 -c args.c
  > args.c: In function `set_option':
  > args.c:687: void value not ignored as it ought to be
  > make: *** [args.o] Error 1
This sounds like a bug in either the glibc header files or (more likely) the
gnu-indent code.  It is unlikely this is a bug in egcs.




jeff


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~1999-06-30 23:07 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-06-18  5:05 indent 1.10.0 and glibc 2.1.1 Mike Castle
1999-06-30 23:07 ` Jeffrey A Law
1999-06-30 23:07   ` Mike Castle
1999-06-30 23:07     ` Andreas Jaeger
1999-06-19  9:36       ` Mike Castle
1999-06-30 23:07       ` Ulrich Drepper

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).