PATCH (volatile support)

PATCH (volatile support)

[Mike Stump]

Here's one that adds volatile use support to the compiler.  This is
necessary because ANSI C says that one must mark variables that expect
to have the right values across setjmp/longjmp must be marked as
volatile, as I recall.

tree.h almost seemed like the exact wrong place for this code, but
nothing struct me as the right place for it.  Maybe someone with a
better sense of the big picture can recommend a better place for it.

There are only two other places I know of that have this same exact
problem.  In the C lexer and in the C++ lexer.  I wanted to think
about the performace impact on those two before changing them.


1998-05-01  Mike Stump  <mrs@kankakee.wrs.com>

	* tree.h: Add support for using volatile in the compiler.
	* tree.c (build_real_from_int_cst): Use volatile to protect
	values across setmp/longjmp.
	* fold-const.c (const_binop): Likewise.
	(fold_convert): Likewise.

Doing diffs in tree.h.~1~:
*** tree.h.~1~	Fri Apr 17 16:15:43 1998
--- tree.h	Fri May  1 17:58:52 1998
*************** extern void dwarf2out_begin_prologue	PRO
*** 2221,2223 ****
--- 2221,2227 ----
     code for a function definition.  */
  
  extern void dwarf2out_end_epilogue	PROTO((void));
+ 
+ #ifndef __STDC__
+ #define volatile
+ #endif
--------------
Doing diffs in fold-const.c.~1~:
*** fold-const.c.~1~	Mon Apr 27 13:17:46 1998
--- fold-const.c	Fri May  1 17:40:23 1998
*************** int_const_binop (code, arg1, arg2, notru
*** 1255,1261 ****
  static tree
  const_binop (code, arg1, arg2, notrunc)
       enum tree_code code;
!      register tree arg1, arg2;
       int notrunc;
  {
    STRIP_NOPS (arg1); STRIP_NOPS (arg2);
--- 1255,1261 ----
  static tree
  const_binop (code, arg1, arg2, notrunc)
       enum tree_code code;
!      volatile tree arg1, arg2;
       int notrunc;
  {
    STRIP_NOPS (arg1); STRIP_NOPS (arg2);
*************** const_binop (code, arg1, arg2, notrunc)
*** 1268,1274 ****
      {
        REAL_VALUE_TYPE d1;
        REAL_VALUE_TYPE d2;
!       int overflow = 0;
        REAL_VALUE_TYPE value;
        tree t;
  
--- 1268,1274 ----
      {
        REAL_VALUE_TYPE d1;
        REAL_VALUE_TYPE d2;
!       volatile int overflow = 0;
        REAL_VALUE_TYPE value;
        tree t;
  
*************** fold_convert (t, arg1)
*** 1497,1503 ****
       register tree arg1;
  {
    register tree type = TREE_TYPE (t);
!   int overflow = 0;
  
    if (POINTER_TYPE_P (type) || INTEGRAL_TYPE_P (type))
      {
--- 1497,1503 ----
       register tree arg1;
  {
    register tree type = TREE_TYPE (t);
!   volatile int overflow = 0;
  
    if (POINTER_TYPE_P (type) || INTEGRAL_TYPE_P (type))
      {
--------------
Doing diffs in tree.c.~1~:
*** tree.c.~1~	Thu Apr 16 12:00:10 1998
--- tree.c	Fri May  1 17:29:35 1998
*************** build_real_from_int_cst (type, i)
*** 1458,1464 ****
       tree i;
  {
    tree v;
!   int overflow = TREE_OVERFLOW (i);
    REAL_VALUE_TYPE d;
    jmp_buf float_error;
  
--- 1458,1464 ----
       tree i;
  {
    tree v;
!   volatile int overflow = TREE_OVERFLOW (i);
    REAL_VALUE_TYPE d;
    jmp_buf float_error;
  
--------------

Re: PATCH (volatile support)

[Andreas Schwab]

Mike Stump <mrs@wrs.com> writes:

|> tree.h almost seemed like the exact wrong place for this code, but
|> nothing struct me as the right place for it.  Maybe someone with a
|> better sense of the big picture can recommend a better place for it.

What about system.h?

-- 
Andreas Schwab                                      "And now for something
schwab@issan.informatik.uni-dortmund.de              completely different"
schwab@gnu.org

Re: PATCH (volatile support)

[John Carr]

> *** tree.h.~1~	Fri Apr 17 16:15:43 1998
> --- tree.h	Fri May  1 17:58:52 1998
> *************** extern void dwarf2out_begin_prologue	PRO
> *** 2221,2223 ****
> --- 2221,2227 ----
>      code for a function definition.  */
>   
>   extern void dwarf2out_end_epilogue	PROTO((void));
> + 
> + #ifndef __STDC__
> + #define volatile
> + #endif
> --------------

This is not correct.  Some MIPS compilers permit and require volatile
even when they do not define __STDC__.

	#if !defined __STDC__ && !defined volatile

would be a better test (xm files can force use of volatile).

I think this definition belongs in system.h.

Re: PATCH (volatile support)

[Richard Henderson]

On Tue, May 05, 1998 at 07:13:57AM -0400, John Carr wrote:
> This is not correct.  Some MIPS compilers permit and require volatile
> even when they do not define __STDC__.
> 
> 	#if !defined __STDC__ && !defined volatile
> 
> would be a better test (xm files can force use of volatile).

Autoconf has a test (not currently being used by gcc, but we ought)
to determine if `const' is available.  We should use the same sort
of test to determine if `volatile' is available.


r~

Re: PATCH (volatile support)

[John Carr]

> > 	#if !defined __STDC__ && !defined volatile

> That won't work, except when volatile is defined to something else that
> the compiler accepts to be synonymous to volatile.

I was assuming "#define volatile volatile".  But now I realize that
won't work with some pre-ANSI compilers, probably including the MIPS
compilers that need volatile.

(In ANSI C "#define foo foo" gives well defined results; some old
preprocessors could go into an infinite loop.)

Re: PATCH (volatile support)

[Joern Rennecke]

> This is not correct.  Some MIPS compilers permit and require volatile
> even when they do not define __STDC__.
> 
> 	#if !defined __STDC__ && !defined volatile
> 
> would be a better test (xm files can force use of volatile).
> 
> I think this definition belongs in system.h.

That won't work, except when volatile is defined to something else that
the compiler accepts to be synonymous to volatile.

I think you need to have some extra macro, e.g. HAVE_VOLATILE,
and have this set/unset appropriately by autoconf
> 

Re: PATCH (volatile support)

[Jeffrey A Law]

  In message < 19980505110009.39202@dot.cygnus.com >you write:
  > Autoconf has a test (not currently being used by gcc, but we ought)
  > to determine if `const' is available.  We should use the same sort
  > of test to determine if `volatile' is available.
Yup.  Our motto should be "if it's a host/build feature it should
be an autoconf check if at all possible".

My recommendation would be to put the test in gcc's aclocal.m4 --
nobody knows when there'll actually be another autoconf release.

Once we've got an autoconf test, I don't see a reason why the
patch can't be installed.

jeff

Re: PATCH (volatile support)

[Jeffrey A Law]

  In message < 199805081604.MAA28272@caip.rutgers.edu >you write:
  > 	Ah, okay.  Then please feel free to make use of the
  > autoconfiscation starting point I wrote in my previous email,
  > http://www.cygnus.com/ml/egcs/1998-May/0204.html
I did just that :-0

Mike -- you should be able to try and use "volatile" now.  Let me
know if it works.

jeff

Re: PATCH (volatile support)

[Kaveh R. Ghazi]

 > From: Jeffrey A Law <law@hurl.cygnus.com>
 > 
 >   In message < 199805061640.MAA11398@caip.rutgers.edu >you write:
 >   > 	I don't see why we need an autoconf check here.  Isn't
 >   > volatile generally only helpful for curing problems when the optimizer
 >   > is turned on?  We don't optimize in stage1.  So merely checking
 >   > __STDC__ (plus a check against another macro to override like jfc
 >   > requested) should be enough to activate volatile in stage2 or later.
 >   > 
 >   > 	If there is some reason we need autoconf which I don't see,
 >   > you could use the following untested snippets as a starting point.
 > 
 > You shouldn't depend on not optimizing stage1...  
 > 
 > In fact, I've had the, err, pleasure of finding several bugs in gcc
 > exposed by building the first stage optimized with a vendor supplied
 > compiler.
 > jeff

	Ah, okay.  Then please feel free to make use of the
autoconfiscation starting point I wrote in my previous email,
http://www.cygnus.com/ml/egcs/1998-May/0204.html

		--Kaveh
--
Kaveh R. Ghazi			Project Manager / Custom Development
ghazi@caip.rutgers.edu		Icon CMT Corp.

Re: PATCH (volatile support)

[Jeffrey A Law]

  In message < 199805061640.MAA11398@caip.rutgers.edu >you write:
  > 	I don't see why we need an autoconf check here.  Isn't
  > volatile generally only helpful for curing problems when the optimizer
  > is turned on?  We don't optimize in stage1.  So merely checking
  > __STDC__ (plus a check against another macro to override like jfc
  > requested) should be enough to activate volatile in stage2 or later.
  > 
  > 	If there is some reason we need autoconf which I don't see,
  > you could use the following untested snippets as a starting point.
You shouldn't depend on not optimizing stage1...  

In fact, I've had the, err, pleasure of finding several bugs in gcc
exposed by building the first stage optimized with a vendor supplied
compiler.

jeff

Re: PATCH (volatile support)

[Kaveh R. Ghazi]

 > From: Jeffrey A Law <law@cygnus.com>
 > 
 >   In message < 19980505110009.39202@dot.cygnus.com >you write:
 >   > Autoconf has a test (not currently being used by gcc, but we ought)
 >   > to determine if `const' is available.  We should use the same sort
 >   > of test to determine if `volatile' is available.
 > Yup.  Our motto should be "if it's a host/build feature it should
 > be an autoconf check if at all possible".
 > 
 > My recommendation would be to put the test in gcc's aclocal.m4 --
 > nobody knows when there'll actually be another autoconf release.
 > 
 > Once we've got an autoconf test, I don't see a reason why the
 > patch can't be installed.
 > jeff

	I don't see why we need an autoconf check here.  Isn't
volatile generally only helpful for curing problems when the optimizer
is turned on?  We don't optimize in stage1.  So merely checking
__STDC__ (plus a check against another macro to override like jfc
requested) should be enough to activate volatile in stage2 or later.

	If there is some reason we need autoconf which I don't see,
you could use the following untested snippets as a starting point.

		--Kaveh



In aclocal.m4 add:

dnl See whether the stage1 host compiler accepts the volatile keyword.
AC_DEFUN(GCC_C_VOLATILE,
[AC_CACHE_CHECK([for volatile], gcc_cv_c_volatile,
[AC_TRY_COMPILE(, [volatile int foo;],
	gcc_cv_c_volatile=yes, gcc_cv_c_volatile=no)])
if test $gcc_cv_c_volatile = yes ; then
  AC_DEFINE(HAVE_VOLATILE)
fi
])



In configure.in add:

GCC_C_VOLATILE



In system.h, (now that we're using an autoconf test...) add:

/* HAVE_VOLATILE only refers to the stage1 compiler.  We also check
   __STDC__ and assume gcc sets it and has volatile in stage >=2. */
#if !defined(HAVE_VOLATILE) && !defined(__STDC__) && !defined(volatile)
#define volatile
#endif
--
Kaveh R. Ghazi			Project Manager / Custom Development
ghazi@caip.rutgers.edu		Icon CMT Corp.

Re: PATCH (volatile support)

[John Carr]

> Here's a revised patch.  Would be nice have it autoconfed.  But I
> guess I prefer to get volatile into a autoconf distribution first,
> then use it when it shows up.

The volatile feature test should check for HAVE_VOLATILE or __STDC__.
That allows xm files to force use of volatile by defining HAVE_VOLATILE.

Re: PATCH (volatile support)

[Mike Stump]

Here's a revised patch.  Would be nice have it autoconfed.  But I
guess I prefer to get volatile into a autoconf distribution first,
then use it when it shows up.

1998-05-05  Mike Stump  <mrs@wrs.com>

	* gansidecl.h: Add support for using volatile in the compiler.
	* tree.c (build_real_from_int_cst): Use volatile to protect
	values across setmp/longjmp.
	* fold-const.c (const_binop): Likewise.
	(fold_convert): Likewise.

Doing diffs in gansidecl.h.~1~:
*** gansidecl.h.~1~	Fri Apr 10 14:03:53 1998
--- gansidecl.h	Tue May  5 11:12:26 1998
*************** Boston, MA 02111-1307, USA.  */
*** 92,97 ****
--- 92,101 ----
  
  #endif /* ! __STDC__ */
  
+ #if !defined (__STDC__) && ! defined (volatile)
+ #define volatile
+ #endif
+ 
  /* We don't have autoconf for libgcc2.c since it's a target, so don't
     define these functions, which aren't used there anyway.  */
  #ifndef IN_LIBGCC2
--------------
Doing diffs in fold-const.c.~1~:
*** fold-const.c.~1~	Mon Apr 27 13:17:46 1998
--- fold-const.c	Tue May  5 11:08:13 1998
*************** int_const_binop (code, arg1, arg2, notru
*** 1255,1261 ****
  static tree
  const_binop (code, arg1, arg2, notrunc)
       enum tree_code code;
!      register tree arg1, arg2;
       int notrunc;
  {
    STRIP_NOPS (arg1); STRIP_NOPS (arg2);
--- 1255,1261 ----
  static tree
  const_binop (code, arg1, arg2, notrunc)
       enum tree_code code;
!      volatile tree arg1, arg2;
       int notrunc;
  {
    STRIP_NOPS (arg1); STRIP_NOPS (arg2);
*************** const_binop (code, arg1, arg2, notrunc)
*** 1268,1274 ****
      {
        REAL_VALUE_TYPE d1;
        REAL_VALUE_TYPE d2;
!       int overflow = 0;
        REAL_VALUE_TYPE value;
        tree t;
  
--- 1268,1274 ----
      {
        REAL_VALUE_TYPE d1;
        REAL_VALUE_TYPE d2;
!       volatile int overflow = 0;
        REAL_VALUE_TYPE value;
        tree t;
  
*************** fold_convert (t, arg1)
*** 1497,1503 ****
       register tree arg1;
  {
    register tree type = TREE_TYPE (t);
!   int overflow = 0;
  
    if (POINTER_TYPE_P (type) || INTEGRAL_TYPE_P (type))
      {
--- 1497,1503 ----
       register tree arg1;
  {
    register tree type = TREE_TYPE (t);
!   volatile int overflow = 0;
  
    if (POINTER_TYPE_P (type) || INTEGRAL_TYPE_P (type))
      {
--------------
Doing diffs in tree.c.~1~:
*** tree.c.~1~	Tue May  5 11:05:02 1998
--- tree.c	Tue May  5 11:08:14 1998
*************** build_real_from_int_cst (type, i)
*** 1458,1464 ****
       tree i;
  {
    tree v;
!   int overflow = TREE_OVERFLOW (i);
    REAL_VALUE_TYPE d;
    jmp_buf float_error;
  
--- 1458,1464 ----
       tree i;
  {
    tree v;
!   volatile int overflow = TREE_OVERFLOW (i);
    REAL_VALUE_TYPE d;
    jmp_buf float_error;
  
--------------

Re: PATCH (volatile support)

[Kaveh R. Ghazi]

 > From: Andreas Schwab <schwab@issan.informatik.uni-dortmund.de>
 > 
 > Mike Stump <mrs@wrs.com> writes:
 > 
 > |> tree.h almost seemed like the exact wrong place for this code, but
 > |> nothing struct me as the right place for it.  Maybe someone with a
 > |> better sense of the big picture can recommend a better place for it.
 > 
 > What about system.h?
 > -- 
 > Andreas Schwab                                      "And now for something



	I've been trying pretty hard to seperate tests on autoconf
macros into system.h while putting tests on compiler macros into
gansidecl.h.  This allows us to include gansidecl.h in target files
which haven't got autoconf macros set.

	So if you're going to base your check on __STDC__ or __GNUC__,
etc, please consider putting your test into gansidecl.h, not system.h

		Thanks,
		--Kaveh

PS: Note, tree.h includes gansidecl.h, so your converage will be the
same as your existing patch. 

--
Kaveh R. Ghazi			Project Manager / Custom Development
ghazi@caip.rutgers.edu		Icon CMT Corp.