Re: A libio patch

Re: A libio patch

[H.J. Lu]

> 
> I've skimmed the patch.  (I *really* hate jumbo patches!)

Sorry. I am trying to keep it small. But they depend on each other.

> 
> Three comments:  I don't understand the point of the must_be_exact
> hack in _IO_file_seekoff.  The comment suggests it is needed for fflush,
> which according to Posix should be caseful to not make the external
> and internal file positions differ.  And fflush is implemented using
> _IO_file_sync, which calls _IO_SYSSEEK when the read position is
> not in sync.  This this is only called when
> fp->_IO_read_ptr != fp->_IO_read_end.
> 
> On the other hand, must_be_true is true if fp->_IO_read_base ==
> fp->_IO_read_end - which implies fp->_IO_read_ptr == fp->_IO_read_end,
> which implies that _IO_file_sync would not call _IO_SYSSEEK in this case.
> 
> Another issue:  In _IO_file_read and _IO_file_write the patch comments out
> code that checks for EINTR, because Posix recommends against it.
> Fine - just remove that code then, which would simplify it.
> I wrote the code to check for EINTR because I got the impression that
> was what you were supposed to do - it was not an optimization.
> If there is no need to check for EINTR, just remove the code that does.

I will leave those to Ulrich. I just copied them from libio in
glibc 2.1.

> 
> I see various places where it checks for __linux__.  This looks
> suspicious.  Wouldn't it be the same for any other OS that uses glibc
> native, such as the Hurd?

There are 2 stdio in glibc. Using glibc doesn't really mean much unless
I can tell libio is used. Ulrich, is there a way to tell that in
iostream.h? As for __linux__ is libio.h, that is a special compatibility
kludge for the Linux libc 5.


-- 
H.J. Lu (hjl@gnu.ai.mit.edu)

RTEMS Cleanup for egcs-ss-970821

[Joel Sherrill]

Sorry this is relative to the older snapshot.  I have just now gotten
enough configurations built to feel comfortable submitting this.

Minor issue:  -Dinhibit_libc is required (as with the crossgcc patch)
  to build an embedded toolset from scratch.

The build of this is minor cleanup and adding -mrtems as a subtarget switch.
Some of the target cpus did not have the SUBTARGET_SWITCHES macro, so I 
added it.  The PPC configuration I based powerpc-rtems on already had one,
so I added a definition of EXTRA_SUBTARGET_SWITCHES.

--joel

diff -r -c tmp/egcs-ss-970821/config/i386/go32-rtems.h egcs-ss-970821/config/i386/go32-rtems.h
*** tmp/egcs-ss-970821/config/i386/go32-rtems.h	Thu Aug 21 17:49:30 1997
--- egcs-ss-970821/config/i386/go32-rtems.h	Wed Aug 27 11:42:49 1997
***************
*** 30,32 ****
--- 30,39 ----
  #endif
  #define CPP_PREDEFINES "-Dunix -Di386 -DGO32 -DMSDOS -Drtems -D__rtems__ \
    -Asystem(unix) -Asystem(msdos) -Acpu(i386) -Amachine(i386) -Asystem(rtems)"
+ 
+ #undef  SUBTARGET_SWITCHES
+ #define SUBTARGET_SWITCHES \
+   { "rtems", 0 },
+ 
+ /* end of i386/go32-rtems.h */
+ 
diff -r -c tmp/egcs-ss-970821/config/i386/rtems.h egcs-ss-970821/config/i386/rtems.h
*** tmp/egcs-ss-970821/config/i386/rtems.h	Thu Aug 21 17:49:33 1997
--- egcs-ss-970821/config/i386/rtems.h	Wed Aug 27 11:42:53 1997
***************
*** 28,31 ****
  #define CPP_PREDEFINES "-Di386 -Drtems -D__rtems__ \
     -Asystem(rtems) -Acpu(i386) -Amachine(i386)"
  
! /* end of i386-rtems.h */
--- 28,35 ----
  #define CPP_PREDEFINES "-Di386 -Drtems -D__rtems__ \
     -Asystem(rtems) -Acpu(i386) -Amachine(i386)"
  
! #undef  SUBTARGET_SWITCHES
! #define SUBTARGET_SWITCHES \
!   { "rtems", 0 },
! 
! /* end of i386/rtems.h */
diff -r -c tmp/egcs-ss-970821/config/i960/i960.h egcs-ss-970821/config/i960/i960.h
*** tmp/egcs-ss-970821/config/i960/i960.h	Thu Aug 21 17:49:40 1997
--- egcs-ss-970821/config/i960/i960.h	Sat Aug 23 11:52:59 1997
***************
*** 269,274 ****
--- 269,275 ----
      {"no-old-align", -(TARGET_FLAG_OLD_ALIGN|TARGET_FLAG_STRICT_ALIGN)}, \
      {"link-relax", 0},					\
      {"no-link-relax", 0},				\
+     SUBTARGET_SWITCHES                                                  \
      { "", TARGET_DEFAULT}}
  
  /* Override conflicting target switch options.
diff -r -c tmp/egcs-ss-970821/config/i960/rtems.h egcs-ss-970821/config/i960/rtems.h
*** tmp/egcs-ss-970821/config/i960/rtems.h	Thu Aug 21 17:49:40 1997
--- egcs-ss-970821/config/i960/rtems.h	Wed Aug 27 11:43:04 1997
***************
*** 28,31 ****
  #define CPP_PREDEFINES "-Di960 -Di80960 -DI960 -DI80960 -Drtems -D__rtems__ \
     -Asystem(rtems) -Acpu(i960) -Amachine(i960)"
  
! /* end of i960-rtems.h */
--- 28,35 ----
  #define CPP_PREDEFINES "-Di960 -Di80960 -DI960 -DI80960 -Drtems -D__rtems__ \
     -Asystem(rtems) -Acpu(i960) -Amachine(i960)"
  
! #undef  SUBTARGET_SWITCHES
! #define SUBTARGET_SWITCHES \
!   { "rtems", 0 },
! 
! /* end of i960/rtems.h */
diff -r -c tmp/egcs-ss-970821/config/m68k/rtems.h egcs-ss-970821/config/m68k/rtems.h
*** tmp/egcs-ss-970821/config/m68k/rtems.h	Thu Aug 21 17:49:48 1997
--- egcs-ss-970821/config/m68k/rtems.h	Wed Aug 27 11:43:08 1997
***************
*** 27,30 ****
  #define CPP_PREDEFINES "-Dmc68000 -Drtems -D__rtems__ \
     -Asystem(rtems) -Acpu(mc68000) -Acpu(m68k) -Amachine(m68k)"
  
! /* end of m68k-rtems.h */
--- 27,34 ----
  #define CPP_PREDEFINES "-Dmc68000 -Drtems -D__rtems__ \
     -Asystem(rtems) -Acpu(mc68000) -Acpu(m68k) -Amachine(m68k)"
  
! #undef  SUBTARGET_SWITCHES
! #define SUBTARGET_SWITCHES \
!   { "rtems", 0 },
! 
! /* end of m68k/rtems.h */
diff -r -c tmp/egcs-ss-970821/config/mips/rtems64.h egcs-ss-970821/config/mips/rtems64.h
*** tmp/egcs-ss-970821/config/mips/rtems64.h	Thu Aug 21 17:49:58 1997
--- egcs-ss-970821/config/mips/rtems64.h	Wed Aug 27 11:43:21 1997
***************
*** 28,31 ****
  #define CPP_PREDEFINES "-Dmips -DMIPSEB -DR4000 -D_mips -D_MIPSEB -D_R4000 \
     -Drtems -D__rtems__ -Asystem(rtems)"
  
! /* end of rtems64.h */
--- 28,35 ----
  #define CPP_PREDEFINES "-Dmips -DMIPSEB -DR4000 -D_mips -D_MIPSEB -D_R4000 \
     -Drtems -D__rtems__ -Asystem(rtems)"
  
! #undef  SUBTARGET_SWITCHES
! #define SUBTARGET_SWITCHES \
!   { "rtems", 0 },
! 
! /* end of mips/rtems64.h */
diff -r -c tmp/egcs-ss-970821/config/pa/rtems.h egcs-ss-970821/config/pa/rtems.h
*** tmp/egcs-ss-970821/config/pa/rtems.h	Thu Aug 21 17:50:07 1997
--- egcs-ss-970821/config/pa/rtems.h	Sat Aug 23 11:53:49 1997
***************
*** 28,30 ****
--- 28,32 ----
  #undef  SUBTARGET_SWITCHES
  #define SUBTARGET_SWITCHES \
    { "rtems", 0 },
+ 
+ /* end of pa/rtems.h */
diff -r -c tmp/egcs-ss-970821/config/rs6000/rtems.h egcs-ss-970821/config/rs6000/rtems.h
*** tmp/egcs-ss-970821/config/rs6000/rtems.h	Thu Aug 21 17:50:15 1997
--- egcs-ss-970821/config/rs6000/rtems.h	Sat Aug 23 11:54:05 1997
***************
*** 28,33 ****
  #define CPP_PREDEFINES "-DPPC -Drtems -D__rtems__ \
     -Asystem(rtems) -Acpu(powerpc) -Amachine(powerpc)"
  
! /* rtems is in the SUBTARGET_SWITCHES in rs6000/sysv4.h */
  
  /* end of powerpc-rtems.h */
--- 28,37 ----
  #define CPP_PREDEFINES "-DPPC -Drtems -D__rtems__ \
     -Asystem(rtems) -Acpu(powerpc) -Amachine(powerpc)"
  
! /* extend the SUBTARGET_SWITCHES in rs6000/sysv4.h */
! 
! #undef  EXTRA_SUBTARGET_SWITCHES
! #define EXTRA_SUBTARGET_SWITCHES \
!   { "rtems", 0 },
  
  /* end of powerpc-rtems.h */
diff -r -c tmp/egcs-ss-970821/config/rs6000/sysv4.h egcs-ss-970821/config/rs6000/sysv4.h
*** tmp/egcs-ss-970821/config/rs6000/sysv4.h	Thu Aug 21 17:50:16 1997
--- egcs-ss-970821/config/rs6000/sysv4.h	Thu Aug 28 09:06:30 1997
***************
*** 95,101 ****
--- 95,105 ----
    { "emb",		 0 },						\
    { "solaris-cclib",	 0 },						\
    { "shlib",		 0 },						\
+   EXTRA_SUBTARGET_SWITCHES                                              \
    { "newlib",		 0 },
+ 
+ /* This is meant to be redefined in the host dependent files */
+ #define EXTRA_SUBTARGET_SWITCHES
  
  /* Default ABI to use */
  #define RS6000_ABI_NAME "sysv"
diff -r -c tmp/egcs-ss-970821/config/sparc/rtems.h egcs-ss-970821/config/sparc/rtems.h
*** tmp/egcs-ss-970821/config/sparc/rtems.h	Thu Aug 21 17:50:19 1997
--- egcs-ss-970821/config/sparc/rtems.h	Wed Aug 27 11:43:58 1997
***************
*** 28,31 ****
  #define CPP_PREDEFINES "-Dsparc -D__GCC_NEW_VARARGS__ -Drtems -D__rtems__ \
    -Asystem(rtems) -Acpu(sparc) -Amachine(sparc)"
  
! /* end of sparc-rtems.h */
--- 28,35 ----
  #define CPP_PREDEFINES "-Dsparc -D__GCC_NEW_VARARGS__ -Drtems -D__rtems__ \
    -Asystem(rtems) -Acpu(sparc) -Amachine(sparc)"
  
! #undef  SUBTARGET_SWITCHES
! #define SUBTARGET_SWITCHES \
!   { "rtems", 0 },
! 
! /* end of sparc/rtems.h */

Changelog for RTEMS patch

[Joel Sherrill]

Whoops I forgot the changelog entry...

--joel

Thu Aug 28 09:24:18 CDT 1997  Joel Sherrill  <joel@OARcorp.com>

        * i386/go32-rtems.h, i386/rtems.h, i960/rtems.h, 
        m68k/rtems.h, mips/rtems64.h, pa/rtems.h, rs6000/rtems.h,
        sparc/rtems.h (subtarget_switches): Added -mrtems as a switch.
        * i960/i960.h: Added SUBTARGET_SWITCHES macro.
        * rs6000/sysv4.h (extra_subtarget_switches): Added new
        macro EXTRA_SUBTARGET_SWITCHES.
        * configure.in (sh*-*-rtems*): New target.
        * sh/rtems.h: New file.
        * sh/sh.h: Added SUBTARGET_SWITCHES macro.

suggested addition to -Wparentheses: warn about ` ! x & 1 '

[Jim Meyering]

I think it would be worthwhile to add at least one more case in which
-Wparentheses gives a warning.  I just saw someone fix a bug that
such an addition would have highlighted.

I was a little surprised to see that gcc -Wparentheses doesn't
warn about this mix of `!' and `&':

  int foo (int x) { return ! x&1; }

Can anyone think of a reason not to add this functionality?

egcs-970825 cross build question

[Joel Sherrill]

I am trying to build the rtems configurations using egcs-970825.
With the old organization, I used the one-tree shell script
(ftp.cygnus.com:/pub/embedded/crossgcc) to generate a binutils,
gcc, newlib source tree to configure and build.  The new organization
seem incompatible with this.  Is there another one-tree script
I should be using?

Could someone please tell me what should be linked under a src directory
to make a one-tree build possible?

Thanks.  At this point, I don't know how to build egcs snapshots
for rtems or any other embedded target.

--joel

FreeBSD and exception name clash

[Kent Vander Velden]

Is fixincludes supposed to fix the following error:

xns|Thu7:09am} uname -a
FreeBSD pseudo.cc.iastate.edu 3.0-CURRENT FreeBSD 3.0-CURRENT #0: Fri
Aug 15 00:29:41 CDT 1997    
kent@pseudo.cc.iastate.edu:/usr/src/sys/compile/PSEUDO  i386

xns|Thu7:17am} cat test.C
#include <set>
#include <math.h>

int
main() {
  return 0;
}

xns|Thu7:18am} ~/egcs/bin/c++ -nostdinc++ -I/home/kent/egcs/include
-I/home/kent/egcs/include/g++/ -L/home/kent/egcs/lib -o test test.C
In file included from test.C:2:
/usr/include/math.h:67: redefinition of `class exception'
/home/kent/egcs/lib/gcc-lib/i386-unknown-freebsd3.0/egcs-2.90.02/include/exception:20:
previous definition here
/usr/include/math.h:73: confused by earlier errors, bailing out

  Thanks.

Re: suggested addition to -Wparentheses: warn about ` ! x & 1 '

[Michael R Cook]

>>>>> "PS" == Peter Seebach  writes:

 >> Hmm, maybe you could make an option -Wall-parentheses, which warns if
 >> any construct is ambigous if operator precedence is not taken into account.
 >> That would cover this case, and all the related ones...

 PS> Yeah, but I don't want warnings on
 PS> 	2 * 3 + 5;

Ideally, all warnings would be very specific, and would be given a
unique identifier, and we'd be able to enable and disable them
individually.  Even better would be if we could enable/disable them
on a sub-file basis; for example:

  __warning(+4701); /* Enable the "Misaligned frobnicator" warning */
  x = 2 * 3 + 5;
  __warning(-4701); /* Disable */

or

  x = __warning(+4701, 2 * 3 + 5);
    /* Evaluate the expression `e' with warning 4701 enabled. */

For macros and headers, we'd want to be able to maintain a kind of
stack for enabling and disabling warnings.  For example, if a
warning is disabled N times, it would have to be enabled N times
before it really became enabled.  Perhaps something like:
__warning(++4701) and __warning(--4701).

Warning identifiers could be assigned so that similar warnings were
consecutive, so you could maybe enable and disable sets of similar
warnings all at once:

 __warning(+3201..3299) /* gimme all of the parentheses warnings */

This functionality would subsume probably all of the existing -W
options.

Re: suggested addition to -Wparentheses: warn about ` ! x & 1 '

[Peter Seebach]

>> | > I was a little surprised to see that gcc -Wparentheses doesn't
>> | > warn about this mix of `!' and `&':
>> | >
>> | >   int foo (int x) { return ! x&1; }
>> | >
>> | > Can anyone think of a reason not to add this functionality?

>Hmm, maybe you could make an option -Wall-parentheses, which warns if
>any construct is ambigous if operator precedence is not taken into account.
>That would cover this case, and all the related ones...

Yeah, but I don't want warnings on
	2 * 3 + 5;

>> Would you give an example or two of such useful constructs?

>!x & y , where y is a variable.

That could be spelled as
	y & !x;

unambiguously.  (And, IMHO, more idiomatically, as I always try to leave
the thing masked on the left, and the mask on the right.)

>!x & (y) , where y is a macro argument that may or may not be constant...

I'd probably do that as
	(!x) & (y)

I will admit to occasionally being bitten by things like the '!x & y', just
because I do enough sh to think of '!' as working on everything in sight.

-s

Re: suggested addition to -Wparentheses: warn about ` ! x & 1 '

[Jim Meyering]

Joern Rennecke <amylaar@cygnus.co.uk> writes:
| > I was a little surprised to see that gcc -Wparentheses doesn't
| > warn about this mix of `!' and `&':
| >
| >   int foo (int x) { return ! x&1; }
| >
| > Can anyone think of a reason not to add this functionality?
|
| Yes.  It's easy to remember that the unary operators have a high
| priority.  There are some useful constructs that would be warned about,
| and adding superflous parantheses often makes the code harder to read.

But first you have to know that.
Some people don't.

Would you give an example or two of such useful constructs?

Re: suggested addition to -Wparentheses: warn about ` ! x & 1 '

[Joern Rennecke]

> I was a little surprised to see that gcc -Wparentheses doesn't
> warn about this mix of `!' and `&':
> 
>   int foo (int x) { return ! x&1; }
> 
> Can anyone think of a reason not to add this functionality?

Yes.  It's easy to remember that the unary operators have a high
priority.  There are some useful constructs that would be warned about,
and adding superflous parantheses often makes the code harder to read.