g++-2.95 rejects cast to void

g++-2.95 rejects cast to void

[Bruno Haible]

Hi,

G++ (gcc-2.95 19990602 prerelease) gives an error on the following code:

=================================================
struct foobar;

void bar (const foobar& x)
{
  static_cast<void>(x);   // ok
  (void)x;                // error message
}
=================================================

$ g++ -W -Wall -S bar.cc
bar.cc: In function `void bar(const foobar &)':
bar.cc:6: invalid use of undefined type `const struct foobar'
bar.cc:1: forward declaration of `const struct foobar'

After reading ANSI/ISO C++ section 5.4

    The conversions performed by
      --a static_cast (_expr.static.cast_),
      ...
    can be performed using the cast notation of explicit type conversion.

it seems to me that g++ ought to grok the code without error message, just
like egcs-1.1 did.

Bruno
>From ghazi@caip.rutgers.edu Wed Jun 16 15:37:00 1999
From: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>
To: dje@watson.ibm.com
Cc: egcs-bugs@egcs.cygnus.com, egcs-patches@egcs.cygnus.com
Subject: Re: Profiling suddenly broken for powerpc-aix4.1 (gcc-2.96 19990612)
Date: Wed, 16 Jun 1999 15:37:00 -0000
Message-id: <199906162237.SAA21392@caip.rutgers.edu>
X-SW-Source: 1999-06/msg00469.html
Content-length: 796

 > From: David Edelsohn <dje@watson.ibm.com>
 > 
 > 	The problem is not a missing asm_fprintf, but that asm_fprintf
 > does not perform assembler dialect selection on arguments as I had
 > assumed.  I needed to expand the code so that RS6000_CALL_GLUE was the
 > format string itself.
 > [...]
 > David
 > 
 > Index: rs6000.c
 > ===================================================================
 > RCS file: /egcs/carton/cvsfiles/egcs/gcc/config/rs6000/rs6000.c,v
 > retrieving revision 1.73
 > diff -c -p -r1.73 rs6000.c
 > *** rs6000.c	1999/06/09 16:01:47	1.73
 > --- rs6000.c	1999/06/14 21:25:49


	I retested profiling last night and it appears to be fixed.
Thanks David.

		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions
>From obrien@NUXI.com Wed Jun 16 16:22:00 1999
From: "David O'Brien" <obrien@NUXI.com>
To: Jeffrey A Law <law@cygnus.com>
Cc: egcs-bugs@egcs.cygnus.com, pfeifer@dbai.tuwien.ac.at
Subject: Re: Damn it
Date: Wed, 16 Jun 1999 16:22:00 -0000
Message-id: <19990616162231.A82914@dragon.nuxi.com>
References: <7328.929571196@upchuck.cygnus.com> <7328.929571196@upchuck.cygnus.com>
X-SW-Source: 1999-06/msg00470.html
Content-length: 608

> And you (meaning the FreeBSD team) wonder why people do not want to integrate
> your changes.  Jeez.

This morning I downloaded the 19990615 snapshot and have *ZERO* problems
boot strapping EGCS.  Would you like a typescript??  I can also point you
to the output from ``make check''.  Additionally bootstrapped and tested
were the 19990608 snapshot and the 19990608 snapshot with that patch.

Before attacking, lets try to understand the discrepancy.

 
> Can you please submit a patch to fix this.

If I can reproduce it I'll send a fix ASAP.
 
-- 
-- David    (obrien@NUXI.com  -or-  obrien@FreeBSD.org)
>From pfeifer@dbai.tuwien.ac.at Wed Jun 16 17:40:00 1999
From: Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at>
To: "David O'Brien" <obrien@nuxi.com>
Cc: Jeffrey A Law <law@cygnus.com>, egcs-bugs@egcs.cygnus.com
Subject: Re: Damn it
Date: Wed, 16 Jun 1999 17:40:00 -0000
Message-id: <Pine.GSO.4.10.9906170229380.23864-100000@alphard.dbai.tuwien.ac.at>
References: <19990616162231.A82914@dragon.nuxi.com>
X-SW-Source: 1999-06/msg00471.html
Content-length: 1310

On Wed, 16 Jun 1999, David O'Brien wrote:
> This morning I downloaded the 19990615 snapshot and have *ZERO* problems
> boot strapping EGCS.  Would you like a typescript??  I can also point you
> to the output from ``make check''.  Additionally bootstrapped and tested
> were the 19990608 snapshot and the 19990608 snapshot with that patch.
> 
> Before attacking, lets try to understand the discrepancy.

I'm most willing to provide any information you require.

Three possible sources of discrepany:

 o As I mentioned in my original report, I am running FreeBSD 3.1.
   Which version did you run your tests on?

 o I am referring to the egcs main branch. Snapshots are made against
   the 2.95 release branch.

 o My bootstrapping compiler is egcs 1.1.2 residing in /sw/egcs-1.1/bin/
   which preceeds /usr/bin/ in the path.

> If I can reproduce it I'll send a fix ASAP.

Some additional data points: I experienced the problem some hours ago
with current CVS, then I undid the patch and bootstrap succeeded.

Just now I did another successfull bootstrap, did a `cvs update -PAd` and
bootstrap failed again.

I have kept both object trees and the output of the bootstraps.
Just let me know what you'd like me to do!

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: g++-2.95 rejects cast to void

[Nathan Sidwell]

Bruno Haible wrote:

> struct foobar;
> 
> void bar (const foobar& x)
> {
>   static_cast<void>(x);   // ok
>   (void)x;                // error message
> }
> =================================================
> 
> $ g++ -W -Wall -S bar.cc
> bar.cc: In function `void bar(const foobar &)':
> bar.cc:6: invalid use of undefined type `const struct foobar'
> bar.cc:1: forward declaration of `const struct foobar'
> 
> After reading ANSI/ISO C++ section 5.4
> 
>     The conversions performed by
>       --a static_cast (_expr.static.cast_),
>       ...
>     can be performed using the cast notation of explicit type conversion.
> 
> it seems to me that g++ ought to grok the code without error message, just
> like egcs-1.1 did.
Firstly I know what's going on here as it's a patch of mine which is
responsible.
I added require_incomplete_type_in_void (typeck.c) and this fixed
g++.bugs/900428_01.C. 

5.2.9/4 says `any expression can be explicitly converted to cv void, The value
is discarded'. 3.2/2 says `an expresion is potentially evaluated unless ...'
The unless part does not mention casting to void. So the argment to static_cast
is evaluated then thrown away. In evaluating a reference, the first thing you
do is look through the reference (5/6). You can't evaluate an expression of
incomplete type.
So shouldn't `(void)x' behave the same regardless of whether `x' is plain
`foobar' or `foobar &'?

But I'm not 100% convinced, because you're allowed to have a reference
parameter to an incomplete object (5.2.2/4) and we have to accept,

foobar &fn();
...
fn();

which is also giving a reference to incomplete in a void context (and we do
accept this (see typeck.c(require_complete_type_in_void, INDIRECT_REF))).
(well, pedantically do we have to accept it?)

What about the following?

struct foobar;
extern foobar obj;
extern foobar &ref; // no initialization needed here
...
(void)obj; // not valid
(void)ref; // valid or not?

Need a language lawyer to confirm/deny ... then I can produce a patch to DTRT.

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 law@cygnus.com Thu Jun 17 02:49:00 1999
From: Jeffrey A Law <law@cygnus.com>
To: jason@cygnus.com, mark@markmitchell.com
Cc: egcs-bugs@egcs.cygnus.com
Subject: gcc-2.95: asm-extn1.C regression
Date: Thu, 17 Jun 1999 02:49:00 -0000
Message-id: <9734.929612627@upchuck.cygnus.com>
X-SW-Source: 1999-06/msg00490.html
Content-length: 2457

This looks like a bug in the C++ front-end.  Given this testcase on a sparc:



extern void traptable(void);

main()
{
  asm("wr    %0,%%tbr" : : "r" (traptable));
}

We abort in emit_move_insn because we have mis-matched modes.  The mis-matched
modes appear to be due to a bogus tree expression passed to the generic
asm code.

If I put a breakpoint in finish_asm_statement, then examine "input_operands"
I get:

 <tree_list 0x83276f0 allocated from function obstack
   
    purpose <string_cst 0x83284d4
        type <array_type 0x8334648 type <integer_type 0x8331670 char>
            allocated from permanent_obstack
            permanent BLK
            size <integer_cst 0x83346e4 constant permanent 1608>
            align 8 symtab 0 alias set -1 domain <integer_type 0x83345b0>>
        allocated from momentary_obstack
        constant "r">
    value <function_decl 0x8343d54 traptable
        type <function_type 0x8334bb4 type <void_type 0x83342bc void>
            allocated from permanent_obstack
            permanent DI
            size <integer_cst 0x8330420 constant permanent 64>
            align 64 symtab 0 alias set -1
            arg-types <tree_list 0x8334394 allocated from permanent_obstack
                unsigned permanent value <void_type 0x83342bc void>>>
        allocated from permanent_obstack
        used permanent public external decl_2 SI file foo.c line 1
       
        decl-main-variant 0x8343d54
        (mem/f:SI (symbol_ref:SI ("traptable__Fv")) 0)
        chain <var_decl 0x833c8dc __func__ type <array_type 0x8334648>
            allocated from permanent_obstack
            readonly asm_written permanent static ignored in_system_header BLK 
file <internal> line 0 size <integer_cst 0x83346e4 1608>
            align 8 initial <string_cst 0x833c940>
            (mem/s/u:BLK (symbol_ref:SI ("__func__")) 0) chain <var_decl 
0x833c80c __PRETTY_FUNCTION__>>>>
$

Of particular interest is the TREE_VALUE field, which is a raw FUNCTION_DECL.
I believe we should have had an ADDR_EXPR containing the FUNCTION_DECL.

If you run the same testcase under the C front-end, that's precisely what
happens.  We have an ADDR_EXPR (FUNCTION_DECL) and everything is happy.

Similarly if the testcase is slightly modified by putting an addressof
operator on the reference to traptable in the asm statement the C++ front-end
will correctly wrap the FUNCTION_DECL inside an ADDR_EXPR.

Can one of you take a looksie?

jeff

Re: g++-2.95 rejects cast to void

[Alexandre Oliva]

On Jun 17, 1999, Nathan Sidwell <nathan@acm.org> wrote:

>> (void)x;                // error message

>> bar.cc:6: invalid use of undefined type `const struct foobar'

> this fixed g++.bugs/900428_01.C.

To save y'all from looking it at, here's a relevant part of this
testcase:

struct s;
extern struct s es, *ps;
void pv_test () {
  es;			// ERROR - incomplete
  (i ? es : es);	// ERROR - undefined type
  es, es;		// ERROR - incomplete
  *ps;			// ERROR - undefined type
  (i ? *ps : *ps);	// ERROR - undefined type
  *ps, *ps;		// ERROR - undefined type
}

I don't think these cases should really be errors.  [expr.unary.op]/1
says: ``[Note: a pointer to an incomplete type (other than cv void )
can be derefer- enced.  The lvalue thus obtained can be used in
limited ways (to ini- tialize a reference, for example); this lvalue
must not be converted to an rvalue, see _conv.lval_.  ]''  But you
shouldn't convert an lvalue to an rvalue gratuitously.  I can't find
any wording in the Standard requiring a diagnostic for dereferencing
an incomplete type other than void and throwing the resulting lvalue
away, or even for referring to an extern variable whose type is
incomplete.

> In evaluating a reference, the first thing you do is look through
> the reference (5/6).

Nope, [expr]/6 has to do with the *type* of an expression, not with
dereferencing reference types.  You don't have to dereference it in
order to cast it to void, because, even if you defined an `operator
void' for the object's class, it shouldn't be used [class.conv.fct]/1.
So you don't need a complete type in order to cast to void.

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists

Re: g++-2.95 rejects cast to void

[Bruno Haible]

> 3.2/2 says `an expresion is potentially evaluated unless ...'
> The unless part does not mention casting to void.

In 3.2/2 the term "potentially evaluated" is only defined as an auxiliary
term in order to define the term "used". (That's what I infer from the
nicely HTMLized copy at http://www.cygnus.com/misc/wp/nov97/ .) This term,
in turn, specifies when the linker is justified in emitting error messages
about undefined member functions / conversion operators etc.

Seems to me that 5.2.9 and 5.4 contain all the lawyer language you need:

5.2.9/4:

     Any expression can be explicitly converted  to  type  cv  void.  The
     expression  value  is discarded.  ... The
     lvalue-to-rvalue  (_conv.lval_),  array-to-pointer (_conv.array_), and
     function-to-pointer (_conv.func_) standard conversions are not applied
     to the expression.

5.4/5:

     The conversions performed by
       --a static_cast (_expr.static.cast_),
       ...
     can be performed using the cast notation of explicit type conversion.

> 5.2.9/4 says `any expression can be explicitly converted to cv void,
> The value is discarded'.

Which means, side effects are executed, only the value is discarded [in
contrast to sizeof, which does not evaluate its argument expression].

> In evaluating a reference, the first thing you do is look through
> the reference (5/6). You can't evaluate an expression of incomplete type.

But 5.2.9/4 contains explicit language to skip the lvalue-to-rvalue
conversion, therefore the fact that the type is incomplete does not matter.

> So shouldn't `(void)x' behave the same regardless of whether `x' is plain
> `foobar' or `foobar &'?

Yes it should behave the same way. That's also what `static_cast<void>(x)'
does. One more test:

===============================================
struct foobar;
extern foobar y;

void bar (foobar& x)
{
  static_cast<void>(x);   // ok
  static_cast<void>(y);   // ok
  (void)x;                // error message, should be no error
  (void)y;                // error message, should be no error
  x;                      // error message, fine
  y;                      // error message, fine
}
===============================================

> What about the following?
> 
> struct foobar;
> extern foobar obj;
> extern foobar &ref; // no initialization needed here
> ...
> (void)obj; // not valid
> (void)ref; // valid or not?

Both are valid - it's the lvalue-to-rvalue conversion which is not valid
when the type is incomplete, and this lvalue-to-rvalue conversion is
explicitly turned off by 5.2.9/4.

Bruno
>From law@cygnus.com Thu Jun 17 03:24:00 1999
From: Jeffrey A Law <law@cygnus.com>
To: dje@watson.ibm.com
Cc: egcs-bugs@egcs.cygnus.com
Subject: Heads up
Date: Thu, 17 Jun 1999 03:24:00 -0000
Message-id: <9812.929614722@upchuck.cygnus.com>
X-SW-Source: 1999-06/msg00494.html
Content-length: 1184

I was looking at the 921208-2.c regression for rs6000-ibm-aix4.2 (and likely
others).  It looks closely related to a thread from last year.  I've skimmed
the discussion just to get familiar with the issues again, but I haven't
really dug deep into the problem yet.

For reference, the test is aborting due to an instruction not matching
its constraints:

j.c: In function `f':
j.c:8: internal error--insn does not satisfy its constraints:

(insn 82 79 91 (set (reg:DF 3 r3)
        (mem:DF (plus:SI (reg:SI 9 r9)
                (reg:SI 1 r1)) 0)) 440 {*movdf_hardfloat32} (nil)
    (nil))

Compile with -O2 (stripped down 921208-2.c)

f()
{
  int i;
  float a[10000];

  for (i = 0; i < 1; i++)
      g(i / 2.0);
}



Note the indexed address and that we're using movdf_hardfloat32.  This pattern
only allows offsettable memrefs to be loaded into GPRs.  reg+reg is not
offsettable and thus we lose.

I'm going to sleep on it before diving into it again, but I wanted to give you
a heads up and a chance to review the discussion from last year.

http://www.cygnus.com/ml/egcs-patches/1998-Aug/subject.html#start

Go about 3/4 the way down and look for the subject "ppc patch".

jeff

Re: g++-2.95 rejects cast to void

[Nathan Sidwell]

Bruno Haible wrote:

> Seems to me that 5.2.9 and 5.4 contain all the lawyer language you need:
> 
> 5.2.9/4:
> 
>      Any expression can be explicitly converted  to  type  cv  void.  The
>      expression  value  is discarded.  ... The
>      lvalue-to-rvalue  (_conv.lval_),  array-to-pointer (_conv.array_), and
>      function-to-pointer (_conv.func_) standard conversions are not applied
>      to the expression.
> 
> 5.4/5:
> 
>      The conversions performed by
>        --a static_cast (_expr.static.cast_),
>        ...
>      can be performed using the cast notation of explicit type conversion.

> But 5.2.9/4 contains explicit language to skip the lvalue-to-rvalue
> conversion, therefore the fact that the type is incomplete does not matter.
> 
Okay, Bruno and Alexandre have convinced me, a patch will be forthcoming. This
line of reasoning implies that g++.bugs/900428_01.C is wrong, even for volatile
objects in statement expressions (6.2/1), because lvalue->rvalue never happens.
I.e.

struct foobar;
extern volatile foobar veobj;
volatile foobar *ptr;
...
veobj; // no access
*ptr;  // no access
(void)*ptr; // no access

though we probably want to warn about such volatile accesses.

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 oliva@dcc.unicamp.br Thu Jun 17 04:21:00 1999
From: Alexandre Oliva <oliva@dcc.unicamp.br>
To: nathan@cs.bris.ac.uk
Cc: Bruno Haible <haible@ilog.fr>, egcs-bugs@egcs.cygnus.com
Subject: Re: g++-2.95 rejects cast to void
Date: Thu, 17 Jun 1999 04:21:00 -0000
Message-id: <orpv2v845a.fsf@saci.lsd.dcc.unicamp.br>
References: <199906162201.AAA03491@jaures.ilog.fr> <3768BF3D.A70C479A@acm.org> <199906171020.MAA06732@jaures.ilog.fr> <3768D64D.358C40FC@acm.org>
X-SW-Source: 1999-06/msg00496.html
Content-length: 862

On Jun 17, 1999, Nathan Sidwell <nathan@acm.org> wrote:

> a patch will be forthcoming.

Great, thanks!

> This line of reasoning implies that g++.bugs/900428_01.C is wrong,
> even for volatile objects in statement expressions (6.2/1), because
> lvalue->rvalue never happens.

Yup

> though we probably want to warn about such volatile accesses.

What's the point?  I'd agree with warning about volatile accesses of
built-in types, such as `*(int*)foo', since they'd just be optimized
away (would they?), but it doesn't make sense to access a volatile
struct as a whole, does it?

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists

Re: access to a volatile variable

[Sergei Organov]

Nathan Sidwell <nathan@acm.org> writes:

[...]

> I understand what you're talking about, and Alexandre pointed it out. In your
> case you'd be accessing via a `volatile int *' (or other _integral_ type), not
> via
> `volatile struct thing *'. Describing a device's memory layout with a struct
> and then mapping it at a particular address I understand. Dinking particular
> 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.

Because, for example, *whole* struct might be single hardware register:

struct A {
  int i : 1;
  int j : 1;
};

A volatile* pa = (A volatile*)0x1234;

int i = pa->i;
int j = pa->j;

generates _two_ accesses to the same hardware address, while

A a = *pa;  /* Access to structure as _whole_ */
int i = a.i;
int j = a.j;

generates _one_ access to the hardware address (at least with all C
compilers I ever used).

Unfortunately the latter is not valid C++ :-( Have no idea why didn't
they preserve compatibility with C in this area at least for
PODs. Don't you think it'd be fine idea to bypass this limitation in
egcs?
>From jgarzik@pobox.com Fri Jun 18 07:07:00 1999
From: Jeff Garzik <jgarzik@pobox.com>
To: egcs-bugs@egcs.cygnus.com
Subject: compiling CVS-latest egcs "locks" on DG/UX
Date: Fri, 18 Jun 1999 07:07:00 -0000
Message-id: <Pine.GSO.3.96.990618100327.5533D-100000@ext1>
X-SW-Source: 1999-06/msg00558.html
Content-length: 535

Platform: i586-dg-dguxR4.20MU04
Platform compiler: gcc version 2.7.2 (ix86 DG/ux, DG-2.7.2.9, Feb  3 1998)


I did a 'cvs up' yesterday afternoon, and attempted to compile egcs with

	./configure --prefix=/usr/local/gcc.new --enable-languages=c++
	make bootstrap

The compilation quite simply stops when stage1/xgcc compiles regclass.c!

'ps' shows that stage1/cc1 is using tons of CPU time, so my guess is
that stage1/cc1 is in some sort of infinite, or really really long loop.

Any help or suggestions are appreciated.

	Jeff

Re: access to a volatile variable

[Nathan Sidwell]

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

Sergei Organov wrote:
>
> Because, for example, *whole* struct might be single hardware register:
> 
> struct A {
>   int i : 1;
>   int j : 1;
> };
I nearly put a comment about this, but figured that using bitfields to *access*
volatile objects is so obviously insane that I needn't. (Notice I didn't say
`using bitfields to *describe* the *layout* of a device register'.) Ho hum.

> A a = *pa;  /* Access to structure as _whole_ */
> int i = a.i;
> int j = a.j;
> 
> generates _one_ access to the hardware address (at least with all C
> compilers I ever used)
Prove that the language guarantees that. [a particular compiler on a particular
system may offer such a guarantee by accident or by design, I'd even like an
example of a compiler where this is a documented feature.]

> Unfortunately the latter is not valid C++ :-( Have no idea why didn't
Why is it not valid? (What do you mean by `valid' -- that it guarantees a
single access, or that it is compilable without diagnostic?)

> they preserve compatibility with C in this area at least for
> PODs. Don't you think it'd be fine idea to bypass this limitation in
> egcs?
What limitation?

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 andihartmann@01019freenet.de Fri Jun 18 08:12:00 1999
From: Andreas Hartmann <andihartmann@01019freenet.de>
To: egcs-bugs@egcs.cygnus.com
Subject: BUG in egcs 1.1.2 under glibc 2.1.1
Date: Fri, 18 Jun 1999 08:12:00 -0000
Message-id: <376A619C.9850DA74@01019freenet.de>
X-SW-Source: 1999-06/msg00568.html
Content-length: 1378

Hallo!

I probably found a bug in compiling
egcs 2.91.66 19990314 on a i586-pc-linux-gnu.

The options I used to compile:
configure --enable-shared --enable-threads --prefix=/usr
make

The following describes the situation the bug occured:

make[1]: Entering directory `/usr/temp/egcs-1.1.2-cpp/compile/gcc'
rm -f SYSCALLS.c tmp-SYSCALLS.s
cat ../../gcc/sys-types.h ../../gcc/sys-protos.h > SYSCALLS.c
/temp/egcs-1.1.2-cpp/compile/gcc/xgcc
-B/temp/egcs-1.1.2-cpp/compile/gcc/  -DIN_GCC    -g -O2 -I./include
-I. -I../../gcc -I../../gcc/config \
  -aux-info SYSCALLS.c.X -S -o tmp-SYSCALLS.s SYSCALLS.c
xgcc: Internal compiler error: program cpp got fatal signal 11
make[1]: *** [SYSCALLS.c.X] Error 1
make[1]: Leaving directory `/usr/temp/egcs-1.1.2-cpp/compile/gcc'
make: *** [all-gcc] Error 2


I read, that signal 11 could be a result of buggy hardware. But I don´t
think so, because there is absolutely no trouble compiling with running
glibc
2.0.7. Always I compile egcs itself, running glibc 2.1.1, I got the
mentioned errormessage (at the very same position). Interesting too:
compiling egcs-1.1.1 produces at the same position with glibc2.1.1 the
same error. Strange, isn´t it?!


I would be glad, if you could tell me a workaround or a solution,
because I won´t miss glibc 2.1.1, because it´s a very fast glibc!

Thanks for your work and kind regards,
A. Hartmann

Re: g++-2.95 rejects cast to void

[Nathan Sidwell]

Alexandre Oliva wrote:
> 
> On Jun 17, 1999, Nathan Sidwell <nathan@acm.org> wrote:

> > though we probably want to warn about such volatile accesses.
> 
> What's the point?  I'd agree with warning about volatile accesses of
> built-in types, such as `*(int*)foo', since they'd just be optimized
> away (would they?), but it doesn't make sense to access a volatile
> struct as a whole, does it?
Oops yes, the incompleteness is irrelevant, it's the volatileness which is
important.

volatile int *pvi;
struct foobar;
volatile foobar *pvfb;
foobar *pfb;

int x;
x = *pvi; //access through pointer
*pfb = *pvfb; // error, dereference incomplete
*pvfb; // no error, no deref -- should warn (this construct doesn't make much
sense even if complete)
*pvi; //no access - should warn

[better check this last case does result in us not generating an access, but
that's a different potential bug report]

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

access to a volatile variable

[David Whitten]

> 
> Alexandre Oliva wrote:
> > 
> > On Jun 17, 1999, Nathan Sidwell <nathan@acm.org> wrote:
> 
> > > though we probably want to warn about such volatile accesses.
> > 
> > What's the point?  I'd agree with warning about volatile accesses of
> > built-in types, such as `*(int*)foo', since they'd just be optimized
> > away (would they?), but it doesn't make sense to access a volatile
> > struct as a whole, does it?
> Oops yes, the incompleteness is irrelevant, it's the volatileness which is
> important.
> 
> volatile int *pvi;
> struct foobar;
> volatile foobar *pvfb;
> foobar *pfb;
> 
> int x;
> x = *pvi; //access through pointer
> *pfb = *pvfb; // error, dereference incomplete
> *pvfb; // no error, no deref -- should warn (this construct doesn't make much
> sense even if complete)
> *pvi; //no access - should warn
> 
> [better check this last case does result in us not generating an access, but
> that's a different potential bug report]

If you are writing code that the volatile element is a memory mapped 
I/O channel, this construct makes sense.  Just because you don't do 
anything with the result you read from the I/O channel doesn't mean that 
strobing the address bus to access a volatile will have no affect.

David

Re: g++-2.95 rejects cast to void

[Alexandre Oliva]

On Jun 17, 1999, Nathan Sidwell <nathan@acm.org> wrote:

> a patch will be forthcoming.

Great, thanks!

> This line of reasoning implies that g++.bugs/900428_01.C is wrong,
> even for volatile objects in statement expressions (6.2/1), because
> lvalue->rvalue never happens.

Yup

> though we probably want to warn about such volatile accesses.

What's the point?  I'd agree with warning about volatile accesses of
built-in types, such as `*(int*)foo', since they'd just be optimized
away (would they?), but it doesn't make sense to access a volatile
struct as a whole, does it?

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists

Re: access to a volatile variable

[Sergei Organov]

Nathan Sidwell <nathan@acm.org> writes:

> Sergei Organov wrote:
> >
> > Because, for example, *whole* struct might be single hardware register:
> > 
> > struct A {
> >   int i : 1;
> >   int j : 1;
> > };
> I nearly put a comment about this, but figured that using bitfields to *access*
> volatile objects is so obviously insane that I needn't. (Notice I didn't say
> `using bitfields to *describe* the *layout* of a device register'.)
> Ho hum.

Maybe it is insane, but still it works fine for me.

> 
> > A a = *pa;  /* Access to structure as _whole_ */
> > int i = a.i;
> > int j = a.j;
> > 
> > generates _one_ access to the hardware address (at least with all C
> > compilers I ever used)
> Prove that the language guarantees that. [a particular compiler on a particular
> system may offer such a guarantee by accident or by design, I'd even like an
> example of a compiler where this is a documented feature.]

I can't prove (and I'm almost sure it couldn't be proved), that's why
I didn't claim it does. But once I check that it works this way with
particular compiler for particular target, I use it, because it is so
hardware dependent and it is very unlikely that this code will ever be
compiled for another target or by another compiler.

> > Unfortunately the latter is not valid C++ :-( Have no idea why didn't
> Why is it not valid? (What do you mean by `valid' -- that it guarantees a
> single access, or that it is compilable without diagnostic?)

It requires constructor

A(A volatile&);

to be defined for struct A, to compile 'A a = *pa', but doesn't
provide such constructor automatically (the same for assignment
operator). So the code shouldn't compile. It is explicitly mentioned
in C/C++ incompatibilities section of the Standard. I posted it here
as egcs bug some time ago, but one of gurus explained me that I was
wrong.

> 
> > they preserve compatibility with C in this area at least for
> > PODs. Don't you think it'd be fine idea to bypass this limitation in
> > egcs?
> What limitation?

To require to define 'A(A volatile&)' to compile (actually egcs
produces warning, not error).

> 
> nathan

Sergei.

Re: access to a volatile variable

[Nathan Sidwell]

David Whitten wrote:

> > volatile int *pvi;
> > struct foobar;
> > volatile foobar *pvfb;
> > foobar *pfb;
> >
> > int x;
> > x = *pvi; //access through pointer
> > *pfb = *pvfb; // error, dereference incomplete
> > *pvfb; // no error, no deref -- should warn (this construct doesn't make much
> > sense even if complete)

> 
> If you are writing code that the volatile element is a memory mapped
> I/O channel, this construct makes sense.  Just because you don't do
> anything with the result you read from the I/O channel doesn't mean that
> strobing the address bus to access a volatile will have no affect.
I understand what you're talking about, and Alexandre pointed it out. In your
case you'd be accessing via a `volatile int *' (or other _integral_ type), not
via
`volatile struct thing *'. Describing a device's memory layout with a struct
and then mapping it at a particular address I understand. Dinking particular
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.

Anyway, even just reading the volatile int as `*pvi;' will not cause a read of
the location pointed to. (It will in C but not in C++ [this is Mike's
objection].) If you want to strobe some location and discard the result, you
have to write

  int tmp;
  tmp = *pvi;

both
	*pvi;
and
	(void)*pvi;

won't do because the lvalue `*pvi' is not converted to an rvalue. This is a
surprise worthy of a warning (IMHO).

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

Re: access to a volatile variable

[Nathan Sidwell]

mark@codesourcery.com wrote:

> I'm not sure I like this last bullet point.  If I understand the
> debate, C++ has different semantics than C for this case.  Well, that
> may be "right" or "wrong" but it's also true.  We must implement them.
Yes the semantics are different, yes we must implement them (for conforming
programs).

>     --> A conforming program could not tell the difference anyway. <--
> 
> If this is true, which wouldn't surprise me, why the debate?  If this
> is true, then we can do the "sensible" thing, 
Alexandre disputes this, however the example he gives looks like a
non-conforming program to me.

>but why were we talking about this to start?
http://egcs.cygnus.com/ml/egcs-bugs/1999-06/msg00468.html et seq, and
http://egcs.cygnus.com/ml/egcs-patches/1999-06/msg00411.html

I'm sorry to keep burdening the list with this issue, but as the one who
submitted the require_complete_type_in_void patch, I'm responsible and I'd
really like to turn that function into a no-op for the 2.95 release -- it only
performs checks, and those checks are wrong. Of course Jeff has frozen 2.95
now, so it'll have to go via him too.

The patch I provided
( http://egcs.cygnus.com/ml/egcs-patches/1999-06/msg00411.html ) is not a
complete solution and I withdraw it for consideration on the mainline.

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

Re: access to a volatile variable

[Mike Stump]

And does everything you just said apply to C?  If not, why should C++
be different?  I am not asking what the C++ Standard says, I know what
it says.  I am asking why it says what it says.

Re: access to a volatile variable

[Mike Stump]

> Date: Wed, 23 Jun 1999 09:24:33 +0100
> From: Nathan Sidwell <nathan@acm.org>

> > If they happen to be different, I'd vote for fixing the C Standard,
> > since the C++ semantics seem quite reasonable to me.
> Nope bad idea :-)

:-) Not necessarily.  I just want to be sure that the entire community
of C and C++ users buys into one semantic.  I prefer to delay the
implications of the C++ change until the C community has a chance to
digest what C++ did (wants to do), and either say, yes, that is a good
thing, or no, it is a bad thing.

Maybe having a warning on volatile lvalues that would not be read is
enough.  Maybe the C folks don't actually use this that often, and
those that do would be willing to put in a foo = vref; to make it read.

Re: access to a volatile variable

[Nathan Sidwell]

Mike Stump wrote:

> > Sergei Organov wrote:
> > >
> > > Because, for example, *whole* struct might be single hardware register:
----------------------------*whole*-----------------single
Sorry, I'd missed this very important part of Sergei's mail, my mistake.
The discussion seemed to be going in the direction of getting rock solid
guarantees about arbitrary structs. I see that was not Sergei's intention.

> I think that is perfectly clear and correct.  *vpi; means fetch.  End
> of story.  :-( I'll see about getting this fixed in C++, though it
> will be harder than just derailing it in a working group, as I did
> last time.
I think that would be a very sensible thing to do.

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

Re: access to a volatile variable

[Mike Stump]

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

> Date: Wed, 23 Jun 1999 10:56:22 +0100
> From: Nathan Sidwell <nathan@acm.org>

> The semantics of volatile are nearly all supplied by the
> implementation.

I would claim they are not specific to an implementation, but to a
target architecture, though, yes, I agree, it would be part of the
implementation's documentation.
>From jeffdbREMOVETHIS@goodnet.com Wed Jun 23 14:15:00 1999
From: jeffdbREMOVETHIS@goodnet.com (Mikey)
To: egcs-bugs@egcs.cygnus.com
Subject: regression in fp constants
Date: Wed, 23 Jun 1999 14:15:00 -0000
Message-id: <37713efc.50385429@mail.goodnet.com>
X-SW-Source: 1999-06/msg00761.html
Content-length: 3829

This worked correctly in egcs-1.2.1

affects all x86 targets with 80387 and LONG_DOUBLE_TYPE_SIZE == 64?

related to changes in i386.md around 3/28/99?

compiling libgcc2.a

_fixunssfsi
_fixunsdfdi
    0       0 [main] D:\USR\SRC\OBJ\GCC\CC1.EXE 1333 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
/tmp\cc6Qaaaa.s: Assembler messages:
/tmp\cc6Qaaaa.s:0: Warning: end of file in string: inserted '"'
/tmp\cc6Qaaaa.s:76: Warning: .stabs: Missing comma
_fixdfdi
_fixunssfdi
    0       0 [main] D:\USR\SRC\OBJ\GCC\CC1.EXE 1347 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
/tmp\ccyRaaaa.s: Assembler messages:
/tmp\ccyRaaaa.s:0: Warning: end of file in string: inserted '"'
/tmp\ccyRaaaa.s:76: Warning: .stabs: Missing comma
_fixsfdi
_fixxfdi

adding -mno-80387 to ./specs works around this error
but is, I think, a less than optimal solution.-)

an XFmode node is being generated in expand_float()
with no type to represent it since long_double_type_node == DFmode

Reading symbols from /USR/SRC/OBJ/GCC/CC1.EXE...done.
0x4860ef in force_const_mem (mode=XFmode, x=0x29fff08)
    at /usr/src/src/gcc/varasm.c:3462
3462          align = CONSTANT_ALIGNMENT (make_tree (type_for_mode (mode, 0), x)

(gdb) bt
#0  0x4860ef in force_const_mem (mode=XFmode, x=0x29fff08)
    at /usr/src/src/gcc/varasm.c:3462
#1  0x44dc3f in emit_move_insn (x=0x29fff20, y=0x29fff08)
    at /usr/src/src/gcc/expr.c:2532
#2  0x4743e4 in copy_to_mode_reg (mode=XFmode, x=0x29fff08)
    at /usr/src/src/gcc/explow.c:670
#3  0x475a60 in expand_binop (mode=XFmode, binoptab=0x29e0450, op0=0x29ffba0,
    op1=0x29fff08, target=0x29ffba0, unsignedp=0, methods=OPTAB_LIB_WIDEN)
    at /usr/src/src/gcc/optabs.c:497
#4  0x47c4ee in expand_float (to=0x29ffb68, from=0x29d59d8, unsignedp=1)
    at /usr/src/src/gcc/optabs.c:3712
#5  0x45ae9e in expand_expr (exp=0x29d40a0, target=0x29ffb68, tmode=VOIDmode,
    modifier=EXPAND_NORMAL) at /usr/src/src/gcc/expr.c:7185
#6  0x45eddb in expand_expr (exp=0x29d40d0, target=0x29d57e8, tmode=DFmode,
    modifier=EXPAND_NORMAL) at /usr/src/src/gcc/expr.c:8159
#7  0x4503af in store_expr (exp=0x29d40d0, target=0x29d57e8, want_value=0)
    at /usr/src/src/gcc/expr.c:3638
#8  0x44ff4f in expand_assignment (to=0x29d5780, from=0x29d40d0, want_value=0,
    suggest_reg=1) at /usr/src/src/gcc/expr.c:3475
#9  0x45de1a in expand_expr (exp=0x29d40f0, target=0x0, tmode=VOIDmode,
    modifier=EXPAND_NORMAL) at /usr/src/src/gcc/expr.c:7872
#10 0x43e19c in expand_expr_stmt (exp=0x29d40f0)
    at /usr/src/src/gcc/stmt.c:1695
#11 0x627c0f in expand_stmt_with_iterators_1 (stmt=0x29d40f0, iter_list=0x0)
    at /usr/src/src/gcc/c-iterate.c:167
#12 0x627bee in iterator_expand (stmt=0x29d40f0)
    at /usr/src/src/gcc/c-iterate.c:157
#13 0x5fa207 in yyparse () at c-parse.y:1700
#14 0x40677a in compile_file (name=0x29bfd9a "/tmp\\ccrHaaaa.i")
    at /usr/src/src/gcc/toplev.c:3019
#15 0x40b535 in main (argc=12, argv=0x29d1060)
    at /usr/src/src/gcc/toplev.c:5354

(gdb) print long_double_type_node->type
$4 = {common = "\000\000\000\000\000\000\000\000\b\000\000\000\004\000\000",
  values = 0x0, size = 0x29d2a28, size_unit = 0x29d2a48, attributes = 0x0,
  uid = 27, precision = 64 '@', mode = DFmode, string_flag = 0,
  no_force_blk_flag = 0, needs_constructing_flag = 0,
  transparent_union_flag = 0, packed_flag = 0, restrict_flag = 0,
  lang_flag_0 = 0, lang_flag_1 = 0, lang_flag_2 = 0, lang_flag_3 = 0,
  lang_flag_4 = 0, lang_flag_5 = 0, lang_flag_6 = 0, align = 64,
  pointer_to = 0x0, reference_to = 0x0, symtab = {address = 14,
    pointer = 0xe "p"}, name = 0x29d8970, minval = 0x0, maxval = 0x0,
  next_variant = 0x0, main_variant = 0x29d88c8, binfo = 0x0,
  noncopied_parts = 0x0, context = 0x0, obstack = 0x635250, alias_set = -1,
  lang_specific = 0x0}

Sorry that's as far as I know how to get ;-)
>From mrs@wrs.com Wed Jun 23 14:28:00 1999
From: mrs@wrs.com (Mike Stump)
To: nathan@cs.bris.ac.uk, oliva@dcc.unicamp.br
Cc: egcs-bugs@egcs.cygnus.com, osv@Javad.RU
Subject: Re: access to a volatile variable
Date: Wed, 23 Jun 1999 14:28:00 -0000
Message-id: <199906232127.OAA25852@kankakee.wrs.com>
X-SW-Source: 1999-06/msg00762.html
Content-length: 750

> Date: Wed, 23 Jun 1999 09:24:33 +0100
> From: Nathan Sidwell <nathan@acm.org>

> > If they happen to be different, I'd vote for fixing the C Standard,
> > since the C++ semantics seem quite reasonable to me.
> Nope bad idea :-)

:-) Not necessarily.  I just want to be sure that the entire community
of C and C++ users buys into one semantic.  I prefer to delay the
implications of the C++ change until the C community has a chance to
digest what C++ did (wants to do), and either say, yes, that is a good
thing, or no, it is a bad thing.

Maybe having a warning on volatile lvalues that would not be read is
enough.  Maybe the C folks don't actually use this that often, and
those that do would be willing to put in a foo = vref; to make it read.
>From jerry@cs.ucsb.edu Wed Jun 23 15:48:00 1999
From: jerry@cs.ucsb.edu (Jerry James)
To: egcs-bugs@egcs.cygnus.com
Subject: Re: compile and install bugs on irix
Date: Wed, 23 Jun 1999 15:48:00 -0000
Message-id: <tpr674e7cu9.fsf@cs.ucsb.edu>
References: <32522.930132560@upchuck.cygnus.com> <or1zf3z0mb.fsf@saci.lsd.dcc.unicamp.br>
X-SW-Source: 1999-06/msg00763.html
Content-length: 1526

> On Jun 23, 1999, Jeffrey A Law <law@cygnus.com> wrote:
> 
> >> 7387:./makeinfo: rld: Error: unresolvable symbol in /usr/lib32/libiflPNG.so:
> 
> > So, what makes your irix system different from mine?  THe makeinfo built
> > during the build process works just fine.  I just configure & make, nothing
> > fancy.
> 
> Does your configure find libz?  Is that a link to libiflPNG?  Does
> your libiflPNG depend on libCsup?  Do you have any patched ld that
> might have fixed this bug?

It isn't a linker bug.  The problem is that libz.so (aka libiflPNG.so)
depends on symbols in libCsup.so, but is not linked to it.  So if you
link with libz, your executable depends on symbols in libCsup, but isn't
linked to it, so the dynamic linker chokes.  You can check this yourself
with:

  elfdump -L libiflPNG.so

It shows that libiflPNG.so is linked to libifl.so, libm.so, libC.so, and
libc.so.  Repeating the process shows that libifl.so is linked to the
other three, and libC.so is linked to libc.so.

Jeff is probably linking with a locally compiled libz, instead of the
IFL version.  I've had nothing but trouble with those IFL libraries,
both because of this issue and because some of them are quite out of
date.  I had a discussion with a couple of XEmacs people about this.
They told me that they had complained to SGI about the lack of a link
from libiflPNG.so to libCsup.so, and SGI basically said they weren't
going to do anything about it. :-(
-- 
Jerry James
Email: jerry@cs.ucsb.edu
WWW:   http://www.cs.ucsb.edu/~jerry/
>From jmg@trivida.com Wed Jun 23 16:31:00 1999
From: "Jeff Greif" <jmg@trivida.com>
To: <egcs-bugs@egcs.cygnus.com>
Subject: template instantiation bug
Date: Wed, 23 Jun 1999 16:31:00 -0000
Message-id: <065901bebdd0$6c60e810$a24630d1@trivida.com>
X-SW-Source: 1999-06/msg00764.html
Content-length: 446

egcs-1.1.2 on solaris (sparc) 2.6 can compile all the template class 
definitions except the last two (M and S).  It fails because it cannot cast 
a template parameter which is a pointer to a derived object into a pointer to 
the corresponding base class.
 
The preprocessor output and compiler options/version/errors are in the 
attached zip file.
 
Any suggested workarounds would be appreciated.  Thanks.
 
Jeff
TriVida Corp.
junk12.zip

Re: access to a volatile variable

[mark]

>>>>> "Nathan" == Nathan Sidwell <nathan@acm.org> writes:

    Nathan> Alexandre Oliva wrote:

    Nathan>For volatile complete T, issue a ped-warn and read the object. Thus
    Nathan> pedantic people will be told that something non-standard
    Nathan> is happening, but the `sensible' semantics happen. The
    Nathan> non-standard behaviour is the lvalue to rvalue decay.

    Nathan> does this sound right?

I'm not sure I like this last bullet point.  If I understand the
debate, C++ has different semantics than C for this case.  Well, that
may be "right" or "wrong" but it's also true.  We must implement them.
I'm all for spotting typos in the standard, but I'm not for guessing
what the committee should have done on substantive issues.

    --> A conforming program could not tell the difference anyway. <--

If this is true, which wouldn't surprise me, why the debate?  If this
is true, then we can do the "sensible" thing, but why were we talking
about this to start?

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com
>From chris@classnet.med.miami.edu Wed Jun 23 08:48:00 1999
From: Christopher C Chimelis <chris@classnet.med.miami.edu>
To: Richard Henderson <rth@cygnus.com>
Cc: egcs-bugs@egcs.cygnus.com
Subject: Re: Last Internal compiler error on Alpha Linux (glibc 2.1.1)
Date: Wed, 23 Jun 1999 08:48:00 -0000
Message-id: <Pine.LNX.3.96.990623114516.16737B-100000@beezer.med.miami.edu>
References: <19990621203831.E32470@cygnus.com>
X-SW-Source: 1999-06/msg00752.html
Content-length: 754

On Mon, 21 Jun 1999, Richard Henderson wrote:

> This does not happen with gcc 2.95, so apparently the bug
> has been fixed.

Thanks for checking on these for me.  Apparently, the fixes were
incorporated between the 19990608 and 19990616 snapshots, fyi.

Also, one thing that has plagued us on Alpha (linux) for awhile is
building emacs 20.x.  It seems to build and run fine with egcs 1.0.3, but
generating a properly functioning binary with any subsequent version of
egcs is impossible.

I wish I had more info, but unfortunately I don't.  If you could look into
this sometime in the future, I know I'd greatly appreciate it (since I'd
finally be able to rm the 1.0.3 installation that I keep around for
building new emacs versions).

Thanks a ton!

C

Re: access to a volatile variable

[Alexandre Oliva]

On Jun 23, 1999, Nathan Sidwell <nathan@acm.org> wrote:

> If you've got a volatile T object and you really don't want to read
> it, why on Earth would you write `object;'?

I might write `foo();', where foo returns `volatile bar_t&'.  Would
this cause the returned bar_t to be read?  Should `(void)foo();'?
Note, I'm *explicitly* throwing away the result of the function,
should it be used regardless of my request?

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists

Re: access to a volatile variable

[Nathan Sidwell]

Alexandre Oliva wrote:
> > 4) For volatile complete T, issue a ped-warn and read the
> > object.
> 
> If you add ``unless `-ansi' is given, in which case you shouldn't read
> the object.'', I buy that.
In this case I think that'd be a bad idea. In some cases we do change behaviour
with the -ansi switch, but I believe the change is to reject/warn some programs
with -ansi that we'd accept without -ansi. I don't think there are cases where
we generate different code (no doubt someone will immediately point out some
case of this :-). If we do generate different code we should warn on the
non-ansi case. Overall I think it would lower the quality of implementation to
do so.

> > --> A conforming program could not tell the difference anyway. <--
> 
> I don't get it.  If I know I'm talking to a particular memory-mapped
> device, and I know it will consume a character every time I read from
> it, I *would* be able to tell, wouldn't I?
You would only be able to tell in a non-conforming way. Or put it another way,
if you can tell, you can't be a conforming program. Device drivers are, of
necessity, non-conforming. We'd better give them sensible semantics.
Now, it's a good thing to tell you when you're straying outside the standard,
we even warn when you're not doing so but your code is weird (like `suggest
paren around ...' (ok, so you have to ask for that warning)). My suggestion
does warn for both volatile cases (if you ask -- maybe we should make it
unconditional), but has the same behaviour regardless of the -ansi switch.

If you've got a volatile T object and you really don't want to read it, why on
Earth would you write `object;'? To say 'Ha! I look at it yet do not see, I
laugh in the face of lvalues!' :-)

The code which Bruno had was trying to use `(void)param' to shut up an `unused
parameter' warning. param wasn't volatile, but was a reference type and thus
normally has an implicit dereference -- except for this void context. If you've
got a parameter of type `volatile T &' and you don't want to use it you'd have
to either not name the parameter, or (if/when the G++ parser is fixed) use
__attribute__ ((unused)), or live with the warning. Is this too high a price to
pay?

The semantics of volatile are nearly all supplied by the implementation. IIR,
all the standard says is that at a sequence point all accesses to/from volatile
objects will have happened and be visible to the `external environment'. The
implementation gets to define `external environment'. I believe there is no
guarantee that a compiler won't fold two volatile accesses to the same object
between the same two sequence points together* (this is my recollection from a
discussion several years ago when we were deciding what our C compiler should
guarantee about volatiles). It all comes down to `implementation defined' and
`quality of implementation'.

nathan

* for example
volatile int *ptr = somewhere
int a = *ptr + *ptr;

produced code might be

load r0,[ptr];	//look two loads
load r1,[ptr];
add r0,r0,r1;
membar;		//memory barier cos we accessed some volatiles

Now, the memory system of the cpu has licence to fold the two loads together
(modulo any page table information), because we've not told it otherwise.
Argument for this code generation-> membar is expensive, if we access several
different volatiles we'd like to share the same memory barrier.
Argument against-> surprise! you (might) only touch the device once.

-- 
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 law@cygnus.com Wed Jun 23 03:10:00 1999
From: Jeffrey A Law <law@cygnus.com>
To: Stephane Conversy <Stephane.Conversy@lri.fr>
Cc: Alexandre Oliva <oliva@dcc.unicamp.br>, egcs-bugs@egcs.cygnus.com, egcs-patches@egcs.cygnus.com
Subject: Re: compile and install bugs on irix 
Date: Wed, 23 Jun 1999 03:10:00 -0000
Message-id: <32522.930132560@upchuck.cygnus.com>
References: <3770AA81.6D4D091C@lri.fr>
X-SW-Source: 1999-06/msg00745.html
Content-length: 873

  In message < 3770AA81.6D4D091C@lri.fr >you write:
  > Jeffrey A Law wrote:
  > 
  > >
  > > What I do not understand (I did not follow the whole thread) is why other
  > > folks are not having this problem.  What is different about the particula
  > r
  > > system that's choking on libz right now?
  > >
  > > jeff
  > 
  > What happens is that libz is not needed when building makeinfo:
  > 
  > > cc -g  -o makeinfo  makeinfo.o multi.o ../lib/libtxi.a ../intl/libintl.a 
  > -lz
  > ld32: WARNING 84: /usr/lib32/libz.so is not used for resolving any symbol.
  > 
  > and when I launch makeinfo I get:
  > > ./makeinfo
  >  7387:./makeinfo: rld: Error: unresolvable symbol in /usr/lib32/libiflPNG.s
  > o:
So, what makes your irix system different from mine?  THe makeinfo built
during the build process works just fine.  I just configure & make, nothing
fancy.

jeff

Re: access to a volatile variable

[Alexandre Oliva]

On Jun 23, 1999, Nathan Sidwell <nathan@acm.org> wrote:

> Alexandre Oliva wrote:
>> If they happen to be different, I'd vote for fixing the C Standard,
>> since the C++ semantics seem quite reasonable to me.

> I've come to the conclusion that Mike's points about C++ and
> volatile are sensible and that the C++ standard is wrong, because it
> generates a `surprise'.

Dunno.  It's no surprise for me, but maybe that's just because I'm
quite used to C++speak, and I've hardly used volatile in C...  I still 
find it weird to fetch a whole object just because a pointer to it is
dereferenced, but it that's what a C programmer would expect it to do,
so be it.

> 4) For volatile complete T, issue a ped-warn and read the
> object.

If you add ``unless `-ansi' is given, in which case you shouldn't read
the object.'', I buy that.

> --> A conforming program could not tell the difference anyway. <--

I don't get it.  If I know I'm talking to a particular memory-mapped
device, and I know it will consume a character every time I read from
it, I *would* be able to tell, wouldn't I?

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists

Re: access to a volatile variable

[Nathan Sidwell]

Alexandre Oliva wrote:

> If they happen to be different, I'd vote for fixing the C Standard,
> since the C++ semantics seem quite reasonable to me.
Nope bad idea :-)

I've come to the conclusion that Mike's points about C++ and volatile are
sensible and that the C++ standard is wrong, because it generates a `surprise'.
Surprises are bad. (Actually, this looks like the computing equivalent of a
singularity -- whatever happens a surprise pops out!)

I think the best solution for egcs is
1) disable the error for 2.95, it is causing us to reject legal code.
2) For non-volatile T, behave as C++ says (i.e allow incomplete lvalues and
don't convert decay to rvalue).
3) For volatile incomplete T, issue a warning, and don't access it (this
conforms to C++, but tells the programmer that something strange is happening).
Again, we don't reject a legal (but probably misguided) program.
4) For volatile complete T, issue a ped-warn and read the object. Thus pedantic
people will be told that something non-standard is happening, but the
`sensible' semantics happen. The non-standard behaviour is the lvalue to rvalue
decay.
   --> A conforming program could not tell the difference anyway. <--

does this sound right?

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 jason@cygnus.com Wed Jun 23 01:33:00 1999
From: Jason Merrill <jason@cygnus.com>
To: Alexandre Oliva <oliva@dcc.unicamp.br>
Cc: "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de>, ees1cg@ee.surrey.ac.uk, egcs-bugs@egcs.cygnus.com, egcs-patches@egcs.cygnus.com
Subject: Re: C++ conversion rules ???
Date: Wed, 23 Jun 1999 01:33:00 -0000
Message-id: <u9ogi7mi59.fsf@yorick.cygnus.com>
References: <m10vgOP-0003JqC@ainur.ee.surrey.ac.uk> <199906201354.PAA00548@mira.isdn.cs.tu-berlin.de> <orbte75vaz.fsf@saci.lsd.dcc.unicamp.br> <u9wvwvmjwg.fsf@yorick.cygnus.com> <orvhcf1go5.fsf@saci.lsd.dcc.unicamp.br>
X-SW-Source: 1999-06/msg00734.html
Content-length: 424

>>>>> Alexandre Oliva <oliva@dcc.unicamp.br> writes:

 > I see.  It would be cool if we could guess the user expectations and
 > just print the warning when they'd be violated, but it seems to me
 > that this warning gets too many false positives, so it should not be
 > enabled by default.

I suppose we could suppress the warning if the two ops are from the same
class and the target types only differ in cv-quals.

Jason
>From oliva@dcc.unicamp.br Wed Jun 23 01:39:00 1999
From: Alexandre Oliva <oliva@dcc.unicamp.br>
To: Jason Merrill <jason@cygnus.com>
Cc: "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de>, ees1cg@ee.surrey.ac.uk, egcs-bugs@egcs.cygnus.com, egcs-patches@egcs.cygnus.com
Subject: Re: C++ conversion rules ???
Date: Wed, 23 Jun 1999 01:39:00 -0000
Message-id: <oriu8f1fd3.fsf@saci.lsd.dcc.unicamp.br>
References: <m10vgOP-0003JqC@ainur.ee.surrey.ac.uk> <199906201354.PAA00548@mira.isdn.cs.tu-berlin.de> <orbte75vaz.fsf@saci.lsd.dcc.unicamp.br> <u9wvwvmjwg.fsf@yorick.cygnus.com> <orvhcf1go5.fsf@saci.lsd.dcc.unicamp.br> <u9ogi7mi59.fsf@yorick.cygnus.com>
X-SW-Source: 1999-06/msg00735.html
Content-length: 812

On Jun 23, 1999, Jason Merrill <jason@cygnus.com> wrote:

>>>>>> Alexandre Oliva <oliva@dcc.unicamp.br> writes:
>> I see.  It would be cool if we could guess the user expectations and
>> just print the warning when they'd be violated, but it seems to me
>> that this warning gets too many false positives, so it should not be
>> enabled by default.

> I suppose we could suppress the warning if the two ops are from the same
> class and the target types only differ in cv-quals.

Sounds reasonable, but that's too much for me :-(

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists

Re: access to a volatile variable

[Alexandre Oliva]

On Jun 21, 1999, mrs@wrs.com (Mike Stump) wrote:

> And does everything you just said apply to C?

I don't have a copy of the C Standard.

> If not, why should C++ be different?

If they happen to be different, I'd vote for fixing the C Standard,
since the C++ semantics seem quite reasonable to me.

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists

Re: access to a volatile variable

[Alexandre Oliva]

On Jun 18, 1999, mrs@wrs.com (Mike Stump) wrote:

> I think that is perfectly clear and correct.  *vpi; means fetch.

I disagree.  [expr.unary.op] says:

1 The unary * operator performs indirection: [...] the result is an
  lvalue referring to the object or function to which the expression
  ^^^^^^^^^^^^^^^^
  points. [...]

But [basic.lval] says:

7 Whenever  an  lvalue appears in a context where an rvalue is expected,
  the lvalue is converted to an rvalue

So the question is whether the lvalue-to-rvalue standard conversion,
that fetches the value referred by the lvalue, is performed or not.
In the cast-to-void case, it's easy, as [expr.static.cast] says:

4 Any expression can be explicitly converted to type cv void. [...] 
  The lvalue-to-rvalue (_conv.lval_), array-to-pointer (_conv.array_),
  and function-to-pointer (_conv.func_) standard conversions are not
  applied to the expression.                                     ^^^

So `(void)*pvi;' must *not* fetch the value, whereas `+*pvi;' *must*
fetch it (assuming that unary+ expects an rvalue, which is not
explicitly stated in its definition, but can be implied from
[over.built]/10, where operator+ takes its argument by value, not by
reference)

But what about plain `*pvi;'?  The answer is in [stmt.expr]:

1 Expression statements have the form
  expression-statement:
          expressionopt ;
  The expression is evaluated and its value is discarded.   The  lvalue-
  to-rvalue  (_conv.lval_),  array-to-pointer  (_conv.array_), and func-
  tion-to-pointer (_conv.func_) standard conversions are not applied  to
  the  expression.                                       ^^^

Therefore, `*pvi;' must not fetch any value, while `(int)*pvi;' must.

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists

Re: access to a volatile variable

[Mike Stump]

> Date: Fri, 18 Jun 1999 16:08:57 +0100
> From: Nathan Sidwell <nathan@acm.org>

> Sergei Organov wrote:
> >
> > Because, for example, *whole* struct might be single hardware register:
> > 
> > struct A {
> >   int i : 1;
> >   int j : 1;
> > };

> > A a = *pa;  /* Access to structure as _whole_ */
> > int i = a.i;
> > int j = a.j;
> > 
> > generates _one_ access to the hardware address (at least with all C
> > compilers I ever used)

> Prove that the language guarantees that.

It is possible to misread the various language standards in ways that
the authors had no intention of people misreading.  The fact one can
do this isn't interesting.  Likewise, there are things the language
standard says, whose exact meaning isn't clearly expressed or
complete, but for which we believe the meaning is obvious to one
skilled in the art.

[ donning flame suit ]

I would claim that it is obvious that

volatile int i, j; i = j;

means that a single load/store is issued on machines that support it.
Yes, the standard doesn't say that, nor can it.  But, we as
implementors can make those claims.  I would be happy to claim that of
gcc/g++ for you on the majority of systems it supports.

Now, onto the differences between the above case, and a case of a
arbitrary structure whose size is the same as the above.  There aren't
any.  The structure is done in a single load/store iff the int is.
Again, I think this is a perfectly valid thing to document, if we want
to.  I think it is a perfectly fine thing to expect of gcc.
Deviations from this are bugs and should be fixed.  Yes, I have seen
some bugs with volatile in the past, and I went through and found all
similar bugs in a systematic fashion and elimiated them all.

Now, onto exactly what the standard says.  It says that only
sig_atomic_t sized objects are small/large enough to be guaranteed to
fit in a single load.  I would claim it is obvious that all structures
whose size is the same as sig_atomic_t would be done in exactly one
load/store.  Not much, but some people might find a way to make use of
this.

Further, the advantage of documenting all the portable semantics of
volatile in the gcc manual is that the next time the standard bodies
meet, they can have a guide as to what really to say.  I personally
derailed efforts to say more about volatile in the ANSI/ISO C++
committee, as the people who wanted to say something didn't know what
volatile meant.  I viewed this as extremely dangerous.  Luckily for me
(and us all), they just went away.

However, my I failed in not being in the room when they changed *vpi;
to not fetch the value.  In C, it must.  From a working paper:

7 [Note:  volatile is a hint to the implementation to  avoid  aggressive
  optimization  involving  the  object  because  the value of the object
  might be changed by means undetectable by an implementation.  See  1.8
  for  detailed  semantics.   In general, the semantics of  volatile are
  intended to be the same in C++ as they are in C.  ]

I think that is perfectly clear and correct.  *vpi; means fetch.  End
of story.  :-( I'll see about getting this fixed in C++, though it
will be harder than just derailing it in a working group, as I did
last time.
>From mrs@wrs.com Fri Jun 18 10:18:00 1999
From: mrs@wrs.com (Mike Stump)
To: egcs-bugs@egcs.cygnus.com
Cc: amylaar@cygnus.com
Subject: infinite loop in loop.c with -O2
Date: Fri, 18 Jun 1999 10:18:00 -0000
Message-id: <199906181718.KAA05472@kankakee.wrs.com>
X-SW-Source: 1999-06/msg00584.html
Content-length: 965

I too am seeing an infinite loop when bootstrapping.  This is on
x86-linux.  I was compiling regclass.o with stage1, 18hr of CPU time
later...  I was using:

File: loop.c            Status: Up-to-date
 
   Working revision:    1.165
   Repository revision: 1.165   /egcs/carton/cvsfiles/egcs/gcc/loop.c,v

stage1/xgcc -Bstage1/ -c  -DIN_GCC    -DUSE_GNULIBC_1 -O2  -DHAVE_CONFIG_H    -I. -I../../egcs/gcc -I../../egcs/gcc/config -I../../egcs/gcc/../include ../../egcs/gcc/regclass.c

was the command.  It loops while compiling init_reg_sets_1.

cvs update -r 1.162 loop.c

and a recompile of loop.c fixes it.  When I do:

cvs update -r 1.163 loop.c

it then breaks.  That was:

revision 1.163
date: 1999/06/17 09:32:59;  author: amylaar;  state: Exp;  lines: +12 -3
        * loop.c (strength_reduce): When doing biv->giv conversion, fix up
        reg_biv_class.
        (recombine_givs): Set ix field after sorting.

Hope this is enough for you to track it down.
>From nathan@acm.org Fri Jun 18 10:44:00 1999
From: Nathan Sidwell <nathan@acm.org>
To: Mike Stump <mrs@wrs.com>
Cc: nathan@compsci.bristol.ac.uk, osv@Javad.RU, egcs-bugs@egcs.cygnus.com
Subject: Re: access to a volatile variable
Date: Fri, 18 Jun 1999 10:44:00 -0000
Message-id: <376A8497.78E47367@acm.org>
References: <199906181624.JAA05363@kankakee.wrs.com>
X-SW-Source: 1999-06/msg00586.html
Content-length: 904

Mike Stump wrote:

> > Sergei Organov wrote:
> > >
> > > Because, for example, *whole* struct might be single hardware register:
----------------------------*whole*-----------------single
Sorry, I'd missed this very important part of Sergei's mail, my mistake.
The discussion seemed to be going in the direction of getting rock solid
guarantees about arbitrary structs. I see that was not Sergei's intention.

> I think that is perfectly clear and correct.  *vpi; means fetch.  End
> of story.  :-( I'll see about getting this fixed in C++, though it
> will be harder than just derailing it in a working group, as I did
> last time.
I think that would be a very sensible thing to do.

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 bill.morrow@macsch.com Fri Jun 18 10:44:00 1999
From: William Morrow <bill.morrow@macsch.com>
To: egcs-bugs@egcs.cygnus.com, bill.morrow@draco-le1.is.macsch.com
Subject: yet another user bug...
Date: Fri, 18 Jun 1999 10:44:00 -0000
Message-id: <376A853A.5BA46262@macsch.com>
X-SW-Source: 1999-06/msg00585.html
Content-length: 2031

Hi,

My name is Bill Morrow.   Please test the example below and
see if it is a problem for you in your product.  I have encountered
this problem in the redhat delivery 6.0, egcs-1.1.2 release.
I may be reached by email as: bill.morrow@macsch.com.
Additionally, my phone number is: 714-444-4182

Below is an example of the problem uncovered. It relatings to
the expansion of template functions which contain __asm__
__volatile__ blocks.  This occurs when standard macros are
applied in the user source.  The example can be modified
by commenting out the "template ..." line with // and adding
#define type int
This converts the code to an instance of the template.  The
code now compiles without errors.  It also can be squashed
by defining __volatile__ as an empty string, although I cannot
say if that is a good idea.

Please reply to acknowledge receiving is message, and if possible
add any known work-around.  Perhaps this is just a bug in the user.

-------------------- cut here --------------------
#include <iostream.h>

typedef void *Pointer;
typedef unsigned long xdr_t;
typedef unsigned short int xdr_t_short;

/*
  The code that follow is the expansion of:

  template <class type>
  inline void GET_VAL(Pointer buffer, type& value)
  {
      value = (type) ntohl( *(xdr_t*)buffer );
  }
*/

template <class type>
inline void GET_VAL(Pointer buffer, type& value)
{
   value = (type) (__extension__
     ({ register unsigned int __v;
        if (__builtin_constant_p ( *(xdr_t*)buffer ))
           __v = (((( *(xdr_t*)buffer ) & 0xff000000) >> 24) |
                  ((( *(xdr_t*)buffer ) & 0x00ff0000) >>  8) |
                  ((( *(xdr_t*)buffer ) & 0x0000ff00) <<  8) |
                  ((( *(xdr_t*)buffer ) & 0x000000ff) << 24)) ;
        else
           __asm__ __volatile__ ( bswap %0"   : "=r" (__v)    :
            "0" ((unsigned int) ( *(xdr_t*)buffer )));
     __v; }))  ;
}

int main(int ac, char **av)
{
   char bfr[128];
   int val;
   GET_VAL(&bfr[0],val);
   cout << val << "\n";
   return 0;
}