Re: BUG: erroneous read access to volatile mem ref

[Ralf Gütlein <ralf dot guetlein at aranea dot de>]

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.

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!
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?

> 
> > 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