BUG: erroneous read access to volatile mem ref

[Graham Stott]

Ralf Gütlein wrote:
> 
> Wow! That's been a fast response!
> Does that mean this is a known bug?
> Is there a regarding thread earlier in this list?
> 
> Is anybody already working on a fix?
> 
> As long as there is no fix available, I'm stuck with
> my december-snapshot and can't gain by the new improvements
> made to the h8300 port.
> 
Well there is a work around for both the C++ and C testcases
cast to void the result of the assignments to volatile variables.

For your C++ example

	inline void Watchdog()
	{
  	  (void)(TCW = 0);
	}

For my C example 

	#define  WD()   \
	({              \
	  (void)(TCW = 0);\
	  1;            \
	 })

> Regarding your reply:
> 
> > No the bug is in both because it's an interaction between GCC's
> > statement expression extension ({...}) and volatile variables.
> >
> > Here's a C testcase
> > -----------------------------------------------------
> > extern volatile unsigned char TCW;
> >
> > #define  WD()   \
> > ({              \
> >   TCW = 0;      \
> >   1;            \
> > })
> >
> > int test(void)
> > {
> >    return WD();
> > }
> > ------------------------------------------------------
> >
> 
> Indeed... and, wow!, my oldest compiler (early 98) shows the same
> behaviour!
Well it's likely it goes back to the beginning of time when statement
expressions were first implemented cira. late 1980's? 

> But even if this issue is that old, I keep calling it a BUG.
> At least in the "inline" case noone would expect that kind
> of side effect.
> 
> But why doesn't this problem show up with cc1.exe and my
> "inline" test case?
>
Because the C compiler does the inlining at the RTL level
whereas the C++ compiler does it at the tree level.
 
> >
> > > A quick investigation on earlier versions turned out that
> > > this issue has been present in egcs-20000103 snapshot already,
> > > but not in versions before december 99. As I read somewhere,
> > > a new inliner has been introduced around december; maybe this
> > > new module is to blame?
> > >
> > No the new inliner isn't to blame it just exposes the problem in
> > the backend.
> 
> I still would sue the inliner for that! Your test case uses an
> extension to ANSI, and it's everybody's own fault to use an
> extension and then expect a certain behavior. (Note that the
> online docs really advise you against using statement expressions)
> But I've been using plain C++ (inline) without any extension, so
> I would not expect a read access to an lvalue.
> 
> Ralf

Graham