Re: Pointers in comparison expressions

[Vincent Lefevre]

On 2005-07-12 23:42:23 +0200, Erik Trulsson wrote:
> Pointer subtraction is only well defined if both pointers point to
> elements in the same array (or one past the end of the array).

I don't know what you mean by "well defined", but even in this case,
the behavior can be undefined. So, replacing a < b by a - b < 0 is not
guaranteed to work with every implementation, just like with integers.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: Where does the C standard describe overflow of signed integers?

[Georg Bauhaus]

Dave Korn wrote:


You can have both, correctness and uninitialised local
variables. For an impression of the difference in performance,
and for a way to ensure correctness, I tried this
(switch register/volatile in the declaration lines in comp
and r to see the effects).
   



 I didn't get that far.  Before the first call to comp the program has
already accessed uninitialised memory:
 


[...]


 for (size_t c=0; c < hi + 2; ++c) {
   if (a[c]) {
   



 Uninitialised variable access.  Boom.  *NOT* correct.
 



Right, but not so much Boom because `a` is full of don't care
shorts. Rather because if x, y, and z are register variables
they might never be assigned; if a[c] happens to always yield 0,
then the function r adds uninitialised local variables in
  return x + y + z;
GCC tells us, anyway.

And then there is + 2 in the loop condition which
might move c off the end of a before a[c]. Another bug,
unrelated to uninitiliased variables.

If you remove the if (a[c]) entirely here and also the + 2
(left over when quickly scribbling a program),
then x, y, and z will be computed. I think the assert
statement has a lot more to say about correctness
than when the register variables get some (which?) initial
values that are not used ever.


 In what sense of the word 'correct' do you claim this example is correct?
 



The example was intended to demonstrate two things:

1) initialising variables doesn't necessarily make programs any
 more correct.
 Initialisation might be redundant, distracting, and inviting
 asymmetric expressions, see below.  A good initial value
 for some algorithm might depend on other values, hence it is
 known only after a conditional. Pseudo code:

 f(a, b):
x <- some initial value
 # expr doesn't show init really depends on cond(a, b)
...
if cond(a, b):
   x <- a different initial value  # asymmetry here
   compute(x, ...)
else:
   compute(x, ...)

2) if putting local variables in registers becomes impossible
 there will be a significant cost. I wanted to get an impression
 of the cost. That's the reason for writing volatile in the
 declaration lines. Just for demo.)


-- Georg

Re: Where does the C standard describe overflow of signed integers?

[Georg Bauhaus]

Paul Schlie wrote:


From: Georg Bauhaus <[EMAIL PROTECTED]>
   


Paul Schlie wrote:
 


From: Robert Dewar <[EMAIL PROTECTED]>
   


this would mean you could not put local variables in
registers. the effect on code quality woul be awful!
   


Why would anyone care about the performance of an access to an
un-initialized variable? 
 


You can have both, correctness and uninitialised local
variables. For an impression of the difference in performance,
   




- which predominantly illustrates the effect of volatile semantics?
 


I was looking for a way to stop GCC from using registers,
as I wanted to see one of the above mentioned effects
on code quality. Hence volatile.


-- Georg

implementing rvalue references to g++

[russell.yanofsky]

Hi,

I just wanted to let anyone who might interested know that there's an attempt 
underway to add support for rvalue references to G++. I've got a preliminary 
patch at http://russ.hn.org/rref/ which adds partial support for them, and I'm 
hoping to turn it into a complete implementation over the next few weeks.

Rvalue references are described and proposed for inclusion in a future C++ 
standard in a paper [1] by Peter Dimov, Howard Hinnant, and Dave Abrahams. They 
work pretty much the same way as normal C++ references, the main difference 
being that they are allowed to bind to temporary objects that hold the results 
of rvalue expressions. Example:

  struct S{};
  S foo();

  // invalid in C++, normal non-const references can't bind to rvalues
  S & lvalue_ref = foo(); 

  // rvalue references are declared with && and can bind to rvalues
  S && rvalue_ref = foo();

The situations that require rvalue references are complicated, and amply 
described in [1] and [2]. But the basic idea is that when you have a modifiable 
reference to an temporary, you can work with it directly instead of having to 
create unnecessary copies of it. Generic code can use them to work well with 
objects that may be expensive to copy (like strings, containers) or impossible 
to copy (like auto_ptrs).

The changes that need to be made to the compiler to support rvalue references 
are straightforward and are laid out in [1] and [3]. The compiler needs to be 
able to understand the && syntax for rvalue reference declarations, and to 
follow some new rules for && types when doing things like resolving function 
overloads and performing template type deduction.

Rvalue references are backwards compatible, and do not in affect the 
compilation or behavior of existing C++ code. They have already been 
implemented in Metrowerks Codewarrior, and according to Howard Hinnant [4], 
they will be included in an upcoming release of that compiler (along with 
standard library extensions that take advantage of them for performance and 
usability gains).

- Russ

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1377.htm
[2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1690.html
[3] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1770.html
[4] 
http://groups-beta.google.com/group/comp.std.c++/browse_thread/thread/64bf775bdf069dad

Re: Where does the C standard describe overflow of signed integers?

[Paul Schlie]

> From: Georg Bauhaus <[EMAIL PROTECTED]>
> 2) if putting local variables in registers becomes impossible
>   there will be a significant cost. I wanted to get an impression
>   of the cost. That's the reason for writing volatile in the
>   declaration lines. Just for demo.)

I believe that was just a miss-statement, as I don't believe there's any
relationship between the two.

implementing rvalue references in g++

[russell.yanofsky]

[sorry for the duplicate post, the first one somehow didn't have line breaks]

Hi,

I just wanted to let anyone who might interested know that there's an
attempt underway to add support for rvalue references to G++. I've got a
preliminary patch at http://russ.hn.org/rref/ which adds partial support for
them, and I'm hoping to turn it into a complete implementation over the next
few weeks.

Rvalue references are described and proposed for inclusion in a future C++
standard in a paper [1] by Peter Dimov, Howard Hinnant, and Dave Abrahams.
They work pretty much the same way as normal C++ references, the main
difference being that they are allowed to bind to temporary objects that
hold the results of rvalue expressions. Example:

  struct S{};
  S foo();

  // invalid in C++, normal non-const references can't bind to rvalues
  S & lvalue_ref = foo();

  // rvalue references are declared with && and can bind to rvalues
  S && rvalue_ref = foo();

The situations that require rvalue references are complicated, and amply
described in [1] and [2]. But the basic idea is that when you have a
modifiable reference to an temporary, you can work with it directly instead
of having to create unnecessary copies of it. Generic code can use them to
work well with objects that may be expensive to copy (like strings,
containers) or impossible to copy (like auto_ptrs).

The changes that need to be made to the compiler to support rvalue
references are straightforward and are laid out in [1] and [3]. The compiler
needs to be able to understand the && syntax for rvalue reference
declarations, and to follow some new rules for && types when doing things
like resolving function overloads and performing template type deduction.

Rvalue references are backwards compatible, and do not in affect the
compilation or behavior of existing C++ code. They have already been
implemented in Metrowerks Codewarrior, and according to Howard Hinnant [4],
they will be included in an upcoming release of that compiler (along with
standard library extensions that take advantage of them for performance and
usability gains).

- Russ

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1377.htm
[2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1690.html
[3] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1770.html
[4] http://groups-beta.google.com/group/comp.std.c++/msg/58549f7f2e14d4ac

Re: implementing rvalue references to g++

[Paolo Carlini]

Hi Russell,

>Hi,
>
>I just wanted to let anyone who might interested know that there's an attempt 
>underway to add support for rvalue references to G++. I've got a preliminary 
>patch at http://russ.hn.org/rref/ which adds partial support for them, and I'm 
>hoping to turn it into a complete implementation over the next few weeks.
>  
>
Besides repeating again that personally I consider this effort very,
very welcome, just wanted to restate (*) that probably you should take
as baseline current *mainline*, not 4.0.0, because, of course, any
possible patch will go in mainline only. Also obvious, in case you are
actually willing to contribute the code to FSF (otherwise why discussing
it on the GCC development mailing list? ;) please start ASAP the
copyright assignment paperwork: it takes time!

Thanks,
Paolo.

(*) See comp.std.c++

Re: Big Classpath Merge warning

[Andreas Jaeger]

I know have a problem building gcc mainline with a parallel build on 
Linux/x86-64:

/usr/include/java/net/URL.h:25: error: global qualification of class name is 
inva
lid before ':' token
/usr/include/java/security/ProtectionDomain.h:24: error: global qualification of
class name is invalid before ':' token
make[5]: *** [gij.lo] Error 1

Are there some missing dependendencies?  Running a normal make in
libjava seems to work.

Btw. I now see a lot of these:

mkdir gnu/java/rmi/ > /dev/null 2>&1
make[3]: [gnu/java/rmi/server.lo] Error 1 (ignored)

This is rather unfortunate, it makes it difficult to grep for errors.
Can't we use something like?
  @test -z gnu/java/rmi || mkdir gnu/java/rmi 

Andreas
-- 
 Andreas Jaeger, [EMAIL PROTECTED], http://www.suse.de/~aj
  SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


pgpPqMRNVg5q6.pgp
Description: PGP signature

Re: Big Classpath Merge warning

[Andreas Schwab]

Andreas Jaeger <[EMAIL PROTECTED]> writes:

> Btw. I now see a lot of these:
>
> mkdir gnu/java/rmi/ > /dev/null 2>&1
> make[3]: [gnu/java/rmi/server.lo] Error 1 (ignored)
>
> This is rather unfortunate, it makes it difficult to grep for errors.
> Can't we use something like?
>   @test -z gnu/java/rmi || mkdir gnu/java/rmi 

It should use $(mkinstalldirs).

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: volatile semantics

[D. Hugh Redelmeier]

Sorry for the very late response.  It is actually triggered by the
bugzilla entry
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278

The motivating example, abstracted from a misbehaving part of X, is:
void test (char *addr) {
*((volatile char *) addr);
}
In this case, the fetch ("access") is required for the hardware to
behave.

| From: Dale Johannesen 
| Date: Tue, 3 May 2005 10:04:36 -0700
| 
| On May 3, 2005, at 7:41 AM, Nathan Sidwell wrote:
| > Mike Stump wrote:
| > > int avail;
| > > int main() {
| > >   while (*(volatile int *)&avail == 0)
| > > continue;
| > >   return 0;
| > > }
| > > Ok, so, the question is, should gcc produce code that infinitely  loops,
| > > or should it be obligated to actually fetch from memory?   Hint, 3.3
| > > fetched.
| > 
| > I beleive the compiler is so licensed. [5.1.2.3/2] talks about accessing
| > a volatile object.  If the compiled can determine the actual object
| > being accessed through a series of pointer and volatile cast conversions,
| > then I see nothing in the std saying it must behave as-if the object
| > were volatile when it is not.

That turns out not to be the case.  See the chain of reasoning later
in this message.

| This is correct; the standard consistently talks about the type of the object,
| not the type of the lvalue, when describing volatile.
|
| However, as a QOI issue, I believe the compiler should treat the reference as
| volatile if either the object or the lvalue is volatile.  That is obviously
| the
| user's intent.

It appears to me that standards conformance requires the access to be
performed.  So GCC4 has a bug.  One that is subtle, so the damage it
is doing may not be evident.  The worst kind.

When I asked Henry Spencer to look at this, he gave a convincing
argument from chapter and verse of C99.  I will quote it here.  I
added the identical text to the bugzilla entry (comment #43), so there
is no need to read the rest of this message if you read that comment.

 start of Henry's comment

There is little room for compiler writers to maneuver here, unless they
have announced their intentions in advance in their documentation. 
Reading C99 carefully:

6.5.3.2:  applying `*' to a pointer of type `T *' which points to an
object yields an lvalue of type `T' designating that object.  So the
lvalue in the assignment has a volatile-qualified type. 

6.3.2.1:  when an object is said to have a particular type, the type is
specified by the lvalue used to designate the object.  So the lvalue
having a volatile-qualified type *means* that the object it designates has
a volatile-qualified type; "has type X" and "is designated by an lvalue of
type X" are synonymous (!).

6.7.3:  any expression referring to an object of volatile-qualified
type must be evaluated strictly by the rules of the abstract machine,
although precisely what constitutes an "access" to the object is
implementation-defined.  (Note, "implementation-defined" behavior is
required to be well-defined and *documented*.)  So if the reference in
question is an "access", it must occur where the abstract machine says
it should.

5.1.2.3:  the abstract machine evaluates all expressions as specified by
semantics and all side effects must occur, side effects including
"accessing a volatile object"; implementations are allowed to skip part
of expression evaluation only if they can deduce that no needed side
effects (notably "accessing a volatile object") are therefore skipped. 
So if the reference is an "access", it must occur, period.

I see no useful wiggle room in the difference between "access" and
"accessing", or the difference between "volatile object" and "object of
volatile-qualified type".  These appear to me to be minor accidents of
inconsistent terminology, not useful to a sane implementer.

6.7.3 says that to refer to an object "defined with" volatile-qualified
type "through use of an lvalue" with non-volatile-qualified type yields
undefined behavior.  However, the reference here uses a volatile-qualified
lvalue, so this is not relevant.  A pointer value is not an lvalue; there
is no lvalue present until the `*' operator is applied. 

Surprising though it might seem, I see no express or implied permission to
distinguish based on whether the object in question was *defined* with a
volatile-qualified type.  There are places in the standard where how an
object is defined is significant, e.g. the rules for `const' and the part
of 6.7.3 noted in the previous paragraph, but none of them is part of the
chain of reasoning above.

The only loophole is the definition of "access".  If GCC wishes to claim
standard conformance, GCC is required to document its definition.  I'm not
aware of any mention of this in the GCC documentation, although I haven't
dug hard for it. 

I see no room for a reasonable definition of "access" which retains some
useful meaning for `volatile' and doesn't cover the reference in question. 
(I agree that y

Re: volatile semantics

[Daniel Berlin]

On Sat, 2005-07-16 at 12:50 -0400, D. Hugh Redelmeier wrote:
> Sorry for the very late response.  It is actually triggered by the
> bugzilla entry
>   http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
> 
> The motivating example, abstracted from a misbehaving part of X, is:
>   void test (char *addr) {
>   *((volatile char *) addr);
>   }
> In this case, the fetch ("access") is required for the hardware to
> behave.
> 
...

> 6.5.3.2:  applying `*' to a pointer of type `T *' which points to an
> object yields an lvalue of type `T' designating that object.  So the
> lvalue in the assignment has a volatile-qualified type. 
> 
> 6.3.2.1:  when an object is said to have a particular type, the type is
> specified by the lvalue used to designate the object.  So the lvalue
> having a volatile-qualified type *means* that the object it designates has
> a volatile-qualified type; "has type X" and "is designated by an lvalue of

How does this reasoning not apply to *((char *)a) = 5 where a was
originally of a const qualified type?
Or do you think you can only *add* qualifiers, and not remove them?

Because if you allow casting away, then you can't ever trust const to be
true either, just like we apparently can't trust the user saying "this
is not volatile" (which they are doing by not declaring the original
object volatile).

There is no point in type qualifiers if they can be simply changed at
will.  Do not lie about your objects, and you will not be screwed over.

Re: volatile semantics

[Nathan Sidwell]

Daniel Berlin wrote:

> How does this reasoning not apply to *((char *)a) = 5 where a was
> originally of a const qualified type?
> Or do you think you can only *add* qualifiers, and not remove them?
> 
> Because if you allow casting away, then you can't ever trust const to be
> true either, just like we apparently can't trust the user saying "this
> is not volatile" (which they are doing by not declaring the original
> object volatile).

I don't understand your point. given
void Foo (char const * a) { *(char *)a = 5; }
the compiler generates code to store 5 through the pointer 'a'.  It doesn't turn
this into a call to 'abort', because it thinks you're writing to const storage.

So, here it appears the compiler does believe the (char *) cast.  Why should it
not believe a (char volatile *) cast -- unless it can determine the static type
of the object pointed to?

nathan

-- 
Nathan Sidwell::   http://www.codesourcery.com   :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk

Re: volatile semantics

[Daniel Berlin]

object volatile).


I don't understand your point. given
void Foo (char const * a) { *(char *)a = 5; }
the compiler generates code to store 5 through the pointer 'a'.  It doesn't turn
this into a call to 'abort', because it thinks you're writing to const storage.


Is this *always* the cast, or just in the example above?



So, here it appears the compiler does believe the (char *) cast.


I imagine this is due to some workaround in an optimizer for some bug it 
exposed elswhere.



 Why should it
not believe a (char volatile *) cast -- unless it can determine the static type
of the object pointed to?


It appears he was saying that *even if it could determine the static 
type*, the volatile qualifier on the cast *made the object not that type 
anymore*. And i'm not sure why such a thing would apply only to volatile, 
if true.



--Dan

Re: volatile semantics

[Andrew Haley]

D. Hugh Redelmeier writes:
 >  start of Henry Spencer's comment
 > 
 > There is little room for compiler writers to maneuver here, unless they
 > have announced their intentions in advance in their documentation. 
 > Reading C99 carefully:
 > 
 > ...
 > 
 > 6.3.2.1:  when an object is said to have a particular type, the type is
 > specified by the lvalue used to designate the object.  So the lvalue
 > having a volatile-qualified type *means* that the object it designates has
 > a volatile-qualified type; "has type X" and "is designated by an lvalue of
 > type X" are synonymous (!).

In other words, we're asked to agree that the type of an object
changes depending on how it is accessed.

For the benefit of readers, only the first sentence of this para is
the language of the standard; the rest isn't.  

That an object referred to through a volatile pointer must
"temporarily" be treated as though it were declared volatile is the
crux of this argument.  I don't believe that such a conclusion must
necessarily be drawn from this language.  That may well be what the
authors meant, but I don't think that it's certainly so.

Andrew.

Re: Big Classpath Merge warning

[Andreas Schwab]

Andreas Jaeger <[EMAIL PROTECTED]> writes:

> I know have a problem building gcc mainline with a parallel build on 
> Linux/x86-64:
>
> /usr/include/java/net/URL.h:25: error: global qualification of class name is 
> inva
> lid before ':' token
> /usr/include/java/security/ProtectionDomain.h:24: error: global qualification 
> of
> class name is invalid before ':' token
> make[5]: *** [gij.lo] Error 1
>
> Are there some missing dependendencies?

It's missing target directories, fixed by this patch.  Bootstrapped on
ia64-suse-linux and checked in as obvious.

Andreas.

2005-07-16  Andreas Schwab  <[EMAIL PROTECTED]>

* scripts/makemake.tcl (emit_package_rule): Emit command to create
target directory.
* Makefile.am (%.lo): Don't create it here.
* sources.am, Makefile.in: Regenerated.

--- gcc/libjava/Makefile.am.~1.494.~2005-07-16 18:19:40.0 +0200
+++ gcc/libjava/Makefile.am 2005-07-16 18:33:15.0 +0200
@@ -345,7 +345,6 @@ lib-gnu-awt-xlib.la: $(lib_gnu_awt_xlib_
 ## Compiling a list of java sources to a single .o.
 
 %.lo: %.list
-   -mkdir $(dir $@) > /dev/null 2>&1
$(LTGCJCOMPILE) -c -o $@ -MT $@ -MD -MP -MF $(basename $@).deps @$<
 
 ## 
--- gcc/libjava/scripts/makemake.tcl.~1.1.~ 2005-07-16 03:27:13.0 
+0200
+++ gcc/libjava/scripts/makemake.tcl2005-07-16 18:32:35.0 +0200
@@ -239,6 +239,7 @@ proc emit_package_rule {package} {
 
   # A rule to make the phony file we are going to compile.
   puts "$lname: \$($varname)"
+  puts "[EMAIL PROTECTED](mkinstalldirs) \$(dir \$@)"
   puts "[EMAIL PROTECTED] file in \$($varname); do \\"
   puts "\t  if test -f \$(srcdir)/\$\$file; then \\"
   puts "\techo \$(srcdir)/\$\$file; \\"

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: volatile semantics

[Daniel Berlin]

> In other words, we're asked to agree that the type of an object
> changes depending on how it is accessed.
> For the benefit of readers, only the first sentence of this para is
> the language of the standard; the rest isn't.  
> 
> That an object referred to through a volatile pointer must
> "temporarily" be treated as though it were declared volatile is the
> crux of this argument. 

Again, you could say the same about const, restrict, or any other
qualifier then, making them more or less useless as qualifiers.

gcc-4.1-20050716 is now available

[gccadmin]

Snapshot gcc-4.1-20050716 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20050716/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.1 CVS branch
with the following options:  -D2005-07-16 17:43 UTC

You'll find:

gcc-4.1-20050716.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.1-20050716.tar.bz2 C front end and core compiler

gcc-ada-4.1-20050716.tar.bz2  Ada front end and runtime

gcc-fortran-4.1-20050716.tar.bz2  Fortran front end and runtime

gcc-g++-4.1-20050716.tar.bz2  C++ front end and runtime

gcc-java-4.1-20050716.tar.bz2 Java front end and runtime

gcc-objc-4.1-20050716.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.1-20050716.tar.bz2The GCC testsuite

Diffs from 4.1-20050709 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.1
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: volatile semantics

[Nathan Sidwell]

Daniel Berlin wrote:
>>> object volatile).
>>
>>
>> I don't understand your point. given
>> void Foo (char const * a) { *(char *)a = 5; }
>> the compiler generates code to store 5 through the pointer 'a'.  It
>> doesn't turn
>> this into a call to 'abort', because it thinks you're writing to const
>> storage.
> 
> 
> Is this *always* the cast, or just in the example above?

I thought we were discussing the case where there is no static information about
what the pointer actually points to. I.e. the case of an incoming pointer
parameter of a function that is not being inlined (or equivalent).


> It appears he was saying that *even if it could determine the static
> type*, the volatile qualifier on the cast *made the object not that type
> anymore*. And i'm not sure why such a thing would apply only to
> volatile, if true.

I could not determine whether that was the case of Hugh Redelmeier's argument --
the example is an incomping pointer parameter.

I agree with you, Daniel, that if the static object can be determined, then its
type qualifiers win.

nathan
-- 
Nathan Sidwell::   http://www.codesourcery.com   :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk

Re: volatile semantics

[Dale Johannesen]

On Jul 16, 2005, at 10:34 AM, Andrew Haley wrote:

6.3.2.1:  when an object is said to have a particular type, the type 
is

specified by the lvalue used to designate the object.


I don't have a standard here, but I will point out that IF this 
sentence is

interpreted to mean


 the type of an object
changes depending on how it is accessed.


this also makes nonsense of gcc's implementation of type-based aliasing
rules.

  *((int *)&x) = 3

would then be valid whatever the type of x.

Re: volatile semantics

[D. Hugh Redelmeier]

[I'm just a tourist here.  I don't subscribe to the gcc list.  I don't
hack on gcc itself.  I'm just posting because this bug hits me and
didn't seem to be analyzed correctly.  I have participated in the C
standardization process for perhaps 20 years.  Now that I look at the
GCC list archives, I see a more of misunderstanding of the standard
than I'd like.]

| From: Daniel Berlin <[EMAIL PROTECTED]>

[quoting Henry's comment]

| > 6.5.3.2:  applying `*' to a pointer of type `T *' which points to an
| > object yields an lvalue of type `T' designating that object.  So the
| > lvalue in the assignment has a volatile-qualified type. 
| > 
| > 6.3.2.1:  when an object is said to have a particular type, the type is
| > specified by the lvalue used to designate the object.  So the lvalue
| > having a volatile-qualified type *means* that the object it designates has
| > a volatile-qualified type; "has type X" and "is designated by an lvalue of
| 
| How does this reasoning not apply to *((char *)a) = 5 where a was
| originally of a const qualified type?

Did you read Henry's comment in full?  It specifically addresses
"const".

Surprising though it might seem, I see no express or implied permission to
distinguish based on whether the object in question was *defined* with a
volatile-qualified type.  There are places in the standard where how an
object is defined is significant, e.g. the rules for `const' and the part
of 6.7.3 noted in the previous paragraph, but none of them is part of the
chain of reasoning above.

| Or do you think you can only *add* qualifiers, and not remove them?

No, that was not said.

| Because if you allow casting away, then you can't ever trust const to be
| true either, just like we apparently can't trust the user saying "this
| is not volatile" (which they are doing by not declaring the original
| object volatile).

No, that is not correct reasoning.

"const" says: this lvalue will only be used for reading.  It does not
say that the underlying object will not be changed.  More is implied
if the object in question is *defined* with a const attribute.  For
example:
const int foo = 0xF00;

| There is no point in type qualifiers if they can be simply changed at
| will.

This has an element of truth to it.  But they do have points:

- const means that a program cannot accidentally change something
  through a const-qualified thingee (lvalue, pointer, whatever)

- volatile tells the compiler "hands off" when such an lvalue is used.

- let's not talk about "restrict"

|  Do not lie about your objects, and you will not be screwed over.

Funny that you should be paraphrasing one of Henry's famous aphorisms
"If you lie to the compiler, it will get its revenge.".  Yes, this is
the same Henry Spencer.

cxx-reflection branch

[Maurizio Monge]

Hello,
sorry for bothering you, but i wasn't able to find on the web
the informations i was looking for about the cxx reflection branch
and i wasn't albe to contact the mantainer (and i don't have enough 
knowlegde of gcc to deduce it from sources).

In particular i would like to know what is the current status of the
branch, as i was planning to try add to gcc some extension to 
allow things like:

template 
serialize(const T& t)
{
/* code that accesses T members with some extension */
}

is anything like this supported (or planned) in the branch?
Thanks.

Best regards
Maurizio Monge

Re: volatile semantics

[Daniel Berlin]

On Sat, 2005-07-16 at 19:35 +0100, Nathan Sidwell wrote:
> Daniel Berlin wrote:
> >>> object volatile).
> >>
> >>
> >> I don't understand your point. given
> >> void Foo (char const * a) { *(char *)a = 5; }
> >> the compiler generates code to store 5 through the pointer 'a'.  It
> >> doesn't turn
> >> this into a call to 'abort', because it thinks you're writing to const
> >> storage.
> > 
> > 
> > Is this *always* the cast, or just in the example above?
> 
> I thought we were discussing the case where there is no static information 
> about
> what the pointer actually points to. I.e. the case of an incoming pointer
> parameter of a function that is not being inlined (or equivalent).

If so, i  have no problem, but then you end up with people claiming we
shouldn't know info we actually do, etc.

> 
> 
> > It appears he was saying that *even if it could determine the static
> > type*, the volatile qualifier on the cast *made the object not that type
> > anymore*. And i'm not sure why such a thing would apply only to
> > volatile, if true.
> 
> I could not determine whether that was the case of Hugh Redelmeier's argument 
> --
> the example is an incomping pointer parameter.

> 
> I agree with you, Daniel, that if the static object can be determined, then 
> its
> type qualifiers win.
> 
> nathan

Re: volatile semantics

[Gabriel Dos Reis]

Daniel Berlin <[EMAIL PROTECTED]> writes:

| On Sat, 2005-07-16 at 12:50 -0400, D. Hugh Redelmeier wrote:
| > Sorry for the very late response.  It is actually triggered by the
| > bugzilla entry
| > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
| > 
| > The motivating example, abstracted from a misbehaving part of X, is:
| > void test (char *addr) {
| > *((volatile char *) addr);
| > }
| > In this case, the fetch ("access") is required for the hardware to
| > behave.
| > 
| ...
| 
| > 6.5.3.2:  applying `*' to a pointer of type `T *' which points to an
| > object yields an lvalue of type `T' designating that object.  So the
| > lvalue in the assignment has a volatile-qualified type. 
| > 
| > 6.3.2.1:  when an object is said to have a particular type, the type is
| > specified by the lvalue used to designate the object.  So the lvalue
| > having a volatile-qualified type *means* that the object it designates has
| > a volatile-qualified type; "has type X" and "is designated by an lvalue of
| 
| How does this reasoning not apply to *((char *)a) = 5 where a was
| originally of a const qualified type?
| Or do you think you can only *add* qualifiers, and not remove them?

If by analysis, you can determine that the argument bound to "a"
actually is the address of a const object (not just a plain pointer
that happens to accidently acquire a const), then it effectively is
invoking an undefined behaviour.  Otherwise, GCC has to accept the
cast-away and store 5.  In general, we just store "5", and let user has
its machine blow if the location is actually read only.



Interestingly, C++ uses a slightly different language and formulation
of its object model and type system.  I'm under the impression that in
previous discussions, there were a mixture of both both (C and C++)
models. 


   The constructs in a C++ program create, destroy, refer to,
   access, and manipulate objects. An object is a region of
   storage. [Note: A function is not an object, regardless of whether
   or not it occupies storage in the way that objects do. ] An object
   is created by a definition (3.1), by a new-expression (5.3.4) or by
   the implementation (12.2) when needed. The properties of an object are
   determined when the object is created.  An object can have a name
   (clause 3). An object has a storage duration (3.7) which influences
   its lifetime (3.8). An object has a type (3.9). The term object
   type refers to the type with which the object is created.  Some
   objects are polymorphic (10.3); the implementation generates
   information associated with each such object that makes it possible
   to determine that objects type during program execution. For other
   objects, the interpretation of the values found therein is
   determined by the type of the expressions (clause 5) used to access them.


Here, C++ says that the type of an object is acquired when the object
is created, NOT the type of the lvalue expression used to access it.

Someone allued to the type-based alias analysis, again C++ uses a
slightly different formulation talking about the "dynamic type", which
is well-defined, i.e. the type with which the object was created.
Thus GCC is well-founded there.

| Because if you allow casting away, then you can't ever trust const to be
| true either, just like we apparently can't trust the user saying "this
| is not volatile" (which they are doing by not declaring the original
| object volatile).

Indeed.  We must however make sure we distinguish between the meaning
of  const as in "const T* p" and that of const in "const T".

| There is no point in type qualifiers if they can be simply changed at
| will.  Do not lie about your objects, and you will not be screwed over.

only if the language you're implementing the compiler for says so, no
matter what nifty transformation you could have done.

-- Gaby

Re: volatile semantics

[Gabriel Dos Reis]

Daniel Berlin <[EMAIL PROTECTED]> writes:

| >> object volatile).
| >
| > I don't understand your point. given
| > void Foo (char const * a) { *(char *)a = 5; }
| > the compiler generates code to store 5 through the pointer 'a'.  It doesn't 
turn
| > this into a call to 'abort', because it thinks you're writing to const 
storage.
| 
| Is this *always* the cast, or just in the example above?
| 
| >
| > So, here it appears the compiler does believe the (char *) cast.
| 
| I imagine this is due to some workaround in an optimizer for some bug
| it exposed elswhere.

I do not understand your sentence; could you clarify?

Given the above definition of Foo(), the following shall pass
assertion

int main()
{
   int char a = 30;
   Foo(&a);
   assert(a == 5); 
}


| >  Why should it
| > not believe a (char volatile *) cast -- unless it can determine the static 
type
| > of the object pointed to?
| 
| It appears he was saying that *even if it could determine the static
| type*, the volatile qualifier on the cast *made the object not that
| type anymore*.


I think care needs to be exercise here about terminology, because it
appears that everybody has its own dialect that ultimately leads to
lot of confusion.  Let me give my answer based on the terminology 
in the C++ standard that I'll reprroduce below.

If you can determine that the *dynamic type* of an object is const,
and yet users writes to it, then you're well-founded to do whatever
you like.  Whoever, just using the static type without further
information that relates it to the dynamic type is insufficient.

Similarly, if you can determine that the dynamic type of an object is
volatile, yet uses access it through non volatile then you can
whatever you like with the program.

Notice that "dynamic type" talks about type of objects, whereas static
type talks about type of expression.
   

   1.3.3 dynamic type 
   the type of the most derived object (1.8) to which the lvalue
   denoted by an lvalue expression refers. [Example: if a pointer
   (8.3.1) p whose static type is pointer to class B is pointing to an
   object of class D, derived from B (clause 10), the dynamic type of
   the expression *p is D. References (8.3.2) are treated similarly. ] 
   The dynamic type of an rvalue expression is its static type.

   1.3.11 static type
   the type of an expression (3.9), which type results from analysis
   of the program without considering execution semantics. The static
   type of an expression depends only on the form of the program in
   which the expression appears, and does not change while the program
   is executing. 

Re: volatile semantics

[Daniel Berlin]

> | There is no point in type qualifiers if they can be simply changed at
> | will.  Do not lie about your objects, and you will not be screwed over.
> 
> only if the language you're implementing the compiler for says so, no
> matter what nifty transformation you could have done.
> 

Except that nobody seems to agree that is what the language actually
says.

BTW, telling us what C++ says is not really interesting, and only adds
to confusion, since we are talking solely about C here

> -- Gaby

Re: volatile semantics

[Gabriel Dos Reis]

"D. Hugh Redelmeier" <[EMAIL PROTECTED]> writes:

[...]

| - let's not talk about "restrict"

Oh, it was getting fun :-)

-- Gaby

Re: volatile semantics

[Gabriel Dos Reis]

Dale Johannesen <[EMAIL PROTECTED]> writes:

| >  the type of an object
| > changes depending on how it is accessed.
| 
| this also makes nonsense of gcc's implementation of type-based aliasing
| rules.
| 
|*((int *)&x) = 3

No.  That one is specifically covered by the C and C++  standards
(although they use different terminologies).  C uses the notion of
*effective type* to formulate the rule.


   [#6] The effective type of an object for an  access  to  its
   stored value is the declared type of the object, if any.72)
   If a value is stored into an object having no declared  type
   through  an  lvalue  having  a  type that is not a character
   type, then the type of the lvalue becomes the effective type
   of  the  object  for that access and for subsequent accesses
   that do not modify the stored value.  If a value  is  copied
   into  an  object  having  no  declared  type using memcpy or
   memmove, or is copied as an array of  character  type,  then
   the  effective  type  of the modified object for that access
   and for subsequent accesses that do not modify the value  is
   the  effective  type  of  the object from which the value is
   copied, if it has one.  For all other accesses to an  object
   having no declared type, the effective type of the object is
   simply the type of the lvalue used for the access.


-- Gaby

Re: cxx-reflection branch

[Gabriel Dos Reis]

Maurizio Monge <[EMAIL PROTECTED]> writes:

| Hello,
| sorry for bothering you, but i wasn't able to find on the web
| the informations i was looking for about the cxx reflection branch
| and i wasn't albe to contact the mantainer (and i don't have enough 
| knowlegde of gcc to deduce it from sources).
| 
| In particular i would like to know what is the current status of the
| branch, as i was planning to try add to gcc some extension to 
| allow things like:
| 
| template 
| serialize(const T& t)
| {
| /* code that accesses T members with some extension */
| }
| 
| is anything like this supported (or planned) in the branch?

No, I have no such plan.  (And the branch has seen no much development
recently) 

-- Gaby

Re: volatile semantics

[Gabriel Dos Reis]

Daniel Berlin <[EMAIL PROTECTED]> writes:

| > | There is no point in type qualifiers if they can be simply changed at
| > | will.  Do not lie about your objects, and you will not be screwed over.
| > 
| > only if the language you're implementing the compiler for says so, no
| > matter what nifty transformation you could have done.
| > 
| 
| Except that nobody seems to agree that is what the language actually
| says.

The way I see it is that people who designed and wrote the standard
offer their view and interpretation of of they wrote and some people
are determined to offer a different interpretation so that they can
claim they are well-founded to apply  their transformations.

| BTW, telling us what C++ says is not really interesting, and only adds
| to confusion, since we are talking solely about C here

No.  The issue pops up in both languages and they share the same
transformation machinery, even if the bug was originally reported only
for C.  I would hate to have to go through this again with you, so I
rather make sure that you understand.  No confusion added.

-- Gaby

Re: volatile semantics

[Gabriel Dos Reis]

Daniel Berlin <[EMAIL PROTECTED]> writes:

| On Sat, 2005-07-16 at 19:35 +0100, Nathan Sidwell wrote:
| > Daniel Berlin wrote:
| > >>> object volatile).
| > >>
| > >>
| > >> I don't understand your point. given
| > >> void Foo (char const * a) { *(char *)a = 5; }
| > >> the compiler generates code to store 5 through the pointer 'a'.  It
| > >> doesn't turn
| > >> this into a call to 'abort', because it thinks you're writing to const
| > >> storage.
| > > 
| > > 
| > > Is this *always* the cast, or just in the example above?
| > 
| > I thought we were discussing the case where there is no static information 
about
| > what the pointer actually points to. I.e. the case of an incoming pointer
| > parameter of a function that is not being inlined (or equivalent).
| 
| If so, i  have no problem, but then you end up with people claiming we
| shouldn't know info we actually do, etc.

I find that fuzzy formulation of the issue rather quite disturbing.
Nobody is claiming you should not know what you know.  What people
claim is under which circumstances you can apply transformations based
on the information you know, i.e. when those transformations are valid.

You don't make people happier by transmutating their programs into
faster executable with (what they think) wrong semantics where there is no
way you can clearly and unambiguously justify those transformations.

-- Gaby

Re: volatile semantics

[Daniel Berlin]

On Sat, 2005-07-16 at 23:23 +0200, Gabriel Dos Reis wrote:
> Daniel Berlin <[EMAIL PROTECTED]> writes:
> 
> | > | There is no point in type qualifiers if they can be simply changed at
> | > | will.  Do not lie about your objects, and you will not be screwed over.
> | > 
> | > only if the language you're implementing the compiler for says so, no
> | > matter what nifty transformation you could have done.
> | > 
> | 
> | Except that nobody seems to agree that is what the language actually
> | says.
> 
> The way I see it is that people who designed and wrote the standard
> offer their view and interpretation of of they wrote and some people
> are determined to offer a different interpretation so that they can
> claim they are well-founded to apply  their transformations.

I'm sorry, i have a hard time believing the view of what amounts so far
to 2 people is that of the standard committee.
After all, if the standard is really that unclear, someone could file a
DR and we could get an official answer.

We both know that standards committees are not made up of 1 or 2 people,
and saying "people who designed and wrote the standard offer their view
and interpretation of of they wrote " is not useful when they do not
actually speak for the committee.

--Dan

Re: volatile semantics

[Daniel Berlin]

On Sat, 2005-07-16 at 23:23 +0200, Gabriel Dos Reis wrote:
> Daniel Berlin <[EMAIL PROTECTED]> writes:
> 
> | > | There is no point in type qualifiers if they can be simply changed at
> | > | will.  Do not lie about your objects, and you will not be screwed over.
> | > 
> | > only if the language you're implementing the compiler for says so, no
> | > matter what nifty transformation you could have done.
> | > 
> | 
> | Except that nobody seems to agree that is what the language actually
> | says.
> 
> The way I see it is that people who designed and wrote the standard
> offer their view and interpretation of of they wrote and some people
> are determined to offer a different interpretation so that they can
> claim they are well-founded to apply  their transformations.

It's nice of you to characterize it in such divisive and confrontational
terms. 

You make it sound like  the standard is crystal clear on this issue, and
everyone who disagrees with your viewpoint are just slimeballs trying to
get around the clear wording of the standard.

And if you don't mean to sound like that, you sure need to be more
careful, because it sure sounds like that to me.

Re: volatile semantics

[Daniel Berlin]

On Sat, 2005-07-16 at 23:28 +0200, Gabriel Dos Reis wrote:
> Daniel Berlin <[EMAIL PROTECTED]> writes:
> 
> | On Sat, 2005-07-16 at 19:35 +0100, Nathan Sidwell wrote:
> | > Daniel Berlin wrote:
> | > >>> object volatile).
> | > >>
> You don't make people happier by transmutating their programs into
> faster executable with (what they think) wrong semantics where there is no
> way you can clearly and unambiguously justify those transformations.

Again, you try and posit it your view as clear and unambiguous when it
simply isn't.
It's not even close to that.

Personally, I actually give less of a crap about volatile and optimizing
volatile than i do const, restrict, etc.  As long as you guys aren't
going to start claiming this type of "Oh well, now my object is
volatile, and now it's not, and now it is again, and now it's not.  Look
at me, i'm dancing!" for other things, it's fine by me.

Also, if we are going to play the "well, volatile is just different
game", and you want no optimization whatsoever when someone says
"volatile", then fine.  I really have no problem with that.  I'll also
simply point all the bug reports we get about "volatile not being
optimized well" (sadly, we have them, take a gander :( ) to you or
whoever wants to explain what semantic you think is correct.

Re: volatile semantics

[Gabriel Dos Reis]

Daniel Berlin <[EMAIL PROTECTED]> writes:

| On Sat, 2005-07-16 at 23:28 +0200, Gabriel Dos Reis wrote:
| > Daniel Berlin <[EMAIL PROTECTED]> writes:
| > 
| > | On Sat, 2005-07-16 at 19:35 +0100, Nathan Sidwell wrote:
| > | > Daniel Berlin wrote:
| > | > >>> object volatile).
| > | > >>
| > You don't make people happier by transmutating their programs into
| > faster executable with (what they think) wrong semantics where there is no
| > way you can clearly and unambiguously justify those transformations.
| 
| Again, you try and posit it your view as clear and unambiguous when it
| simply isn't.
| It's not even close to that.
| 
| Personally, I actually give less of a crap about volatile and optimizing
| volatile than i do const, restrict, etc.  As long as you guys aren't
| going to start claiming this type of "Oh well, now my object is
| volatile, and now it's not, and now it is again, and now it's not.  Look
| at me, i'm dancing!" for other things, it's fine by me.

I generally don't care about volatile -- I don't believe it is a very
useful progroamming language device given its current definition.  I
care only when its implementation hurts users.

| Also, if we are going to play the "well, volatile is just different
| game", and you want no optimization whatsoever when someone says
| "volatile", then fine.

It is not me inventing that.  

|  I really have no problem with that.  I'll also
| simply point all the bug reports we get about "volatile not being
| optimized well" (sadly, we have them, take a gander :( ) to you or
| whoever wants to explain what semantic you think is correct.

Please give me references, it always is good thing.

-- Gaby

Re: volatile semantics

[Gabriel Dos Reis]

Daniel Berlin <[EMAIL PROTECTED]> writes:

[...]

| You make it sound like  the standard is crystal clear on this issue, and
| everyone who disagrees with your viewpoint are just slimeballs trying to
| get around the clear wording of the standard.

I think you're profondly mistaken in your understanding of what I wrote.

-- Gaby

Re: volatile semantics

[Daniel Berlin]

On Sun, 2005-07-17 at 00:05 +0200, Gabriel Dos Reis wrote:
> Daniel Berlin <[EMAIL PROTECTED]> writes:
> 
> [...]
> 
> | You make it sound like  the standard is crystal clear on this issue, and
> | everyone who disagrees with your viewpoint are just slimeballs trying to
> | get around the clear wording of the standard.
> 
> I think you're profondly mistaken in your understanding of what I wrote.

I read it another few times, and still looks the same to me.

"The way I see it is that people who designed and wrote the standard
offer their view and interpretation of of they wrote and some people
are determined to offer a different interpretation so that they can
claim they are well-founded to apply  their transformations."


IE there are those whose opinion is right because "they wrote the
standard" (even though they don't actually speak for the standards
committee as individuals), and everyone else is just trying to get
around what they say.

Re: volatile semantics

[Gabriel Dos Reis]

Daniel Berlin <[EMAIL PROTECTED]> writes:

| We both know that standards committees are not made up of 1 or 2 people,
| and saying "people who designed and wrote the standard offer their view
| and interpretation of of they wrote " is not useful when they do not
| actually speak for the committee.

Clearly, the communication channel to read you has a serious problem.

-- Gaby

Re: volatile semantics

[Gabriel Dos Reis]

Daniel Berlin <[EMAIL PROTECTED]> writes:

| On Sun, 2005-07-17 at 00:05 +0200, Gabriel Dos Reis wrote:
| > Daniel Berlin <[EMAIL PROTECTED]> writes:
| > 
| > [...]
| > 
| > | You make it sound like  the standard is crystal clear on this issue, and
| > | everyone who disagrees with your viewpoint are just slimeballs trying to
| > | get around the clear wording of the standard.
| > 
| > I think you're profondly mistaken in your understanding of what I wrote.
| 
| I read it another few times, and still looks the same to me.
| 
| "The way I see it is that people who designed and wrote the standard
| offer their view and interpretation of of they wrote and some people
| are determined to offer a different interpretation so that they can
| claim they are well-founded to apply  their transformations."
| 
| 
| IE there are those whose opinion is right because "they wrote the

see, here is where you added the transmutation.

-- Gaby

Re: volatile semantics

[D. Hugh Redelmeier]

| From: Gabriel Dos Reis <[EMAIL PROTECTED]>

| The way I see it is that people who designed and wrote the standard
| offer their view and interpretation of of they wrote and some people
| are determined to offer a different interpretation so that they can
| claim they are well-founded to apply  their transformations.

I don't know exactly what you are referring to here.  That's OK, I
think.

The standard should stand alone.  It should be able to be interpreted
without "insider knowledge".

The standard is quite complicated and intricate.  It helps to already
know it when trying to read it.  (On the other hand, that same
phenomenon makes it hard for the authors to see its ambiguities.)

Generations have worked on improving the standards.  Not all of the
changes were made by people who understood what went before.

Having said all that, I think that the standard gives no authority to
do the optimization that GCC4 is doing to the code sample I gave.  I
included Henry's carefully justified-by-scripture argument.  If anyone
disagrees, PLEASE give a careful argument why, siting the Standard.

If you wish to answer other questions about the standard, I recommend
that the first step would be to read the standard.  Arguing by opinion
isn't getting us too far.

PS: thanks for not just ignoring my report.

Re: volatile semantics

[Gabriel Dos Reis]

"D. Hugh Redelmeier" <[EMAIL PROTECTED]> writes:

| | From: Gabriel Dos Reis <[EMAIL PROTECTED]>
| 
| | The way I see it is that people who designed and wrote the standard
| | offer their view and interpretation of of they wrote and some people
| | are determined to offer a different interpretation so that they can
| | claim they are well-founded to apply  their transformations.
| 
| I don't know exactly what you are referring to here.  That's OK, I
| think.

yes :-)

| The standard should stand alone.  It should be able to be interpreted
| without "insider knowledge".

fully agreed.

| The standard is quite complicated and intricate.  It helps to already
| know it when trying to read it.  (On the other hand, that same
| phenomenon makes it hard for the authors to see its ambiguities.)

again agreed.

| Generations have worked on improving the standards.  Not all of the
| changes were made by people who understood what went before.

no displute there.

| Having said all that, I think that the standard gives no authority to
| do the optimization that GCC4 is doing to the code sample I gave.  I
| included Henry's carefully justified-by-scripture argument.  If anyone
| disagrees, PLEASE give a careful argument why, siting the Standard.
| 
| If you wish to answer other questions about the standard, I recommend
| that the first step would be to read the standard.  Arguing by opinion
| isn't getting us too far.

Again agreed.

| PS: thanks for not just ignoring my report.

well, feedbacks are always welcome and it would not help us if we did
"just ignore" them.  After many exchanges via private mails and
looking at the various reports related to this issue, it has become
clear to me that the interpretations offered to justify why GCC is
behaving the way it does seem to go beyond what can be inferred.

-- Gaby

Re: 4.1 news item

[Daniel Berlin]

On Sun, 2005-07-10 at 00:16 +0200, Gerald Pfeifer wrote:
> On Fri, 8 Jul 2005, Daniel Berlin wrote:
> > Here's a patch.
> 
> Thanks.
> 
> There are a couple of commas between items missing (usually when
> there is a line break)
fixed.

>  and some of the lines are too long (as with
> GCC sources we generally prefer lines no longer than ~77 characters).

Fixed.

> 
> Is the new stack checking infrastructure really a port of IBM Pro
> Police, or a reimplementation by RTH and Jakub?

Reimplementation, but that was the item listed in the wiki.
I'll change both.

How about now?

> 
> Gerald
Index: index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.507
diff -u -p -r1.507 index.html
--- index.html	8 Jul 2005 06:50:42 -	1.507
+++ index.html	17 Jul 2005 01:33:55 -
@@ -84,6 +84,25 @@ mission statement.
 
 
 
+July 8, 2005
+
+GCC 4.1 stage 2 has been closed.  The following projects were contributed
+during stage 1 and stage 2: 
+New C Parser, LibAda GNATTools Branch, Code Sinking, Improved phi-opt, 
+Structure Aliasing, Autovectorization Enhancements, Hot and Cold Partitioning,
+SMS Improvements, Integrated Immediate Uses, Tree Optimizer Cleanups, 
+Variable-argument Optimization, Redesigned VEC API, IPA Infrastructure, 
+Altivec Rewrite Warning Message Control, New SSA Operand Cache Implementation, 
+Safe Builtins, Reimplementation of IBM Pro Police Stack Detector, 
+New DECL hierarchy.
+
+More information about these projects can be found at 
+http://gcc.gnu.org/wiki/GCC%204.1%20Projects";>GCC 4.1 projects
+
+Thank you to all contributors, testers, and everyone else for making stage 1 and stage 2 
+of GCC 4.1 a success.
+
+
 July 7, 2005
 
 GCC 4.0.1 has been released.

Re: volatile semantics

[D. Hugh Redelmeier]

| From: Gabriel Dos Reis <[EMAIL PROTECTED]>

|  After many exchanges via private mails and
| looking at the various reports related to this issue, it has become
| clear to me that the interpretations offered to justify why GCC is
| behaving the way it does seem to go beyond what can be inferred.

OK.

Is there a consensus on this?  If not, how can a consensus be reached?

If so, how can we get a fix?

I think that is urgent.  This bug is causing X to misbehave and the
current workarounds might be harmful.  Who knows what other
manifestations might be lurking?

As I said, I'm not a GCC hacker.  Who is the likely maintainer to fix
this?  Does he or she agree that this needs to be done?  Urgently?

Re: profiledbootstrap insn-attrtab.c compile taking forever

[R Hill]

Richard Guenther wrote:

On 7/14/05, Richard Guenther <[EMAIL PROTECTED]> wrote:

As subject says - on x86_64 it takes a whopping 30 minutes to
compile said with -fprofile-generate!


It's caused by -frename-registers enabled by -funroll-loops.  Compiling
with -O2 -fno-unroll-loops -fprofile-generate compared to -O2 -fno-unroll-loops
-fprofile-generate -frename-registers takes 14 minutes instead of 31.

Please consider not enabling -frename-registers for -fprofile-generate.


I thought -frename-registers defaulted to disabled now.  On the 4.0 
branch the manual states it's not enabled by opt switches due to known 
bugs.  Is it also enabled by -funroll-loops on the branch?


--de.

Re: volatile semantics

[Gabriel Dos Reis]

"D. Hugh Redelmeier" <[EMAIL PROTECTED]> writes:

| | From: Gabriel Dos Reis <[EMAIL PROTECTED]>
| 
| |  After many exchanges via private mails and
| | looking at the various reports related to this issue, it has become
| | clear to me that the interpretations offered to justify why GCC is
| | behaving the way it does seem to go beyond what can be inferred.
| 
| OK.
| 
| Is there a consensus on this?

JSM, please chime in.

| If not, how can a consensus be reached?

try to explain those who read the standard to you their interpretation
does not match the intent and the letter?  Sorry :-)

More seriously, at this point Daniel Berlin has indicated that he gives
"less of a crap about volatile and optimizing volatile than [he does]
const, restrict, etc".  So that is, I hope, a path to a saner behaviour
from the code transformation part of the compiler.

| If so, how can we get a fix?
| 
| I think that is urgent.  This bug is causing X to misbehave and the
| current workarounds might be harmful.  Who knows what other
| manifestations might be lurking?
| 
| As I said, I'm not a GCC hacker.  Who is the likely maintainer to fix
| this?  Does he or she agree that this needs to be done?  Urgently?

Joseph S. Myers (jsm at polyomino.org.uk) and Richard Henderson (rth
at redhat.com) are the C front-end maintainers.  The following is
from the last message I received from Joseph (on access through volatile
lvalue expression): 

  # Using always the qualification of the lvalue is reasonable semantics to 
  # specify (I don't know about to implement).  It's still a matter of making 
  # a choice and documenting and implementing it.

The issue is compounded by the fact that the code transformation part
(the "optimizer") is maintained by a different set of people and it takes
coordination between both worlds to arrive to a useful semantics. 

At this point we need:
  (1) agreement from C and C++ maintainers on access through volatile
  lvalue 
  (2) agreement with the middle-end maintainers not to "optimize"
  volatile lvalue expressions
  (3) document the behaviour.

The most important for you and X is to have (2) done, i.e. Richard
Henderson, Roger Sayle, Daniel Berlin and others.

-- Gaby

Re: volatile semantics

[Daniel Berlin]

On Sat, 2005-07-16 at 21:36 -0400, D. Hugh Redelmeier wrote:
> | From: Gabriel Dos Reis <[EMAIL PROTECTED]>
> 
> |  After many exchanges via private mails and
> | looking at the various reports related to this issue, it has become
> | clear to me that the interpretations offered to justify why GCC is
> | behaving the way it does seem to go beyond what can be inferred.
> 
> OK.
> 
> Is there a consensus on this?  If not, how can a consensus be reached?
> 
I'll pass on this, since I've said my piece, and i don't care about
volatile much.  However, if you come after const or restrict I'll bite
back.
Personally, I think a DR should be filed to clarify this, instead of all
this argument and opinion. 

> If so, how can we get a fix?
Usually by asking nicely and pressuring people. 
Or waiting long enough for someone to get around to it.
Or paying someone to fix it :)

> 
> I think that is urgent. 
No offense, but everyone thinks the problems that affect them are the
most urgent.

>  This bug is causing X to misbehave and the
> current workarounds might be harmful.  Who knows what other
> manifestations might be lurking?

Whoever is testing distributions compiled with mainline :)

> 
> As I said, I'm not a GCC hacker.  Who is the likely maintainer to fix
> this?
Anyone can fix it, however, who can review the fix depends on what it
touches.

>  Does he or she agree that this needs to be done? 
> Urgently?

This is actually probably pretty unlikely.  There are few bugs most
people consider urgent, and i'd venture this is not one of them.  It
would probably be fixed by release time.

In that spirit, here is a patch against mainline that fixes your bug (a
similar patch to the same function should work on 4.0)

Someone else can go through the process of testing and getting this
reviewed, i'm currently swamped (IE i have no plans to try to submit
this to gcc-patches).

Have a nice weekend,
Dan

Index: tree-ssa-operands.c
===
RCS file: /cvs/gcc/gcc/gcc/tree-ssa-operands.c,v
retrieving revision 2.95
diff -u -p -r2.95 tree-ssa-operands.c
--- tree-ssa-operands.c	13 Jul 2005 15:34:16 -	2.95
+++ tree-ssa-operands.c	17 Jul 2005 02:26:21 -
@@ -1224,6 +1224,9 @@ get_expr_operands (tree stmt, tree *expr
   code = TREE_CODE (expr);
   class = TREE_CODE_CLASS (code);
 
+  if (TREE_THIS_VOLATILE (expr))
+s_ann->has_volatile_ops = true;
+
   switch (code)
 {
 case ADDR_EXPR:

Re: volatile semantics

[Daniel Berlin]

> At this point we need:
>   (1) agreement from C and C++ maintainers on access through volatile
>   lvalue 
>   (2) agreement with the middle-end maintainers not to "optimize"
>   volatile lvalue expressions

We already don't optimize expressions considered to have "volatile"
operands.

It's just our definition of volatile operands did not include this.
The patch i sent is probably overkill in this regard to this specific
semantic.

Anything it sees anything in a statement with volatile, it marks the
statement as volatile, which should stop things from touching it
(anything that *does* optimize something marked volatile is buggy).

I should note that this will probably annoy the people who reported :

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3506
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18617
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21580
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20222

(there's a couple others).

Then again, I'm pretty  willing at this point to laugh at people who use
volatile and complain about code quality (even if most of those end up
being caused in the backend)

--Dan

Re: volatile semantics

[Gabriel Dos Reis]

Daniel Berlin <[EMAIL PROTECTED]> writes:

| Anything it sees anything in a statement with volatile, it marks the
| statement as volatile, which should stop things from touching it
| (anything that *does* optimize something marked volatile is buggy).

great!

| I should note that this will probably annoy the people who reported :
|   
| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3506

The rationale is:

   GCC doesn't know what constitutes a reference to a volatile memory,
so it never performs operations on them directly.  It will always
pull the value into a register first.

| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18617

If the statement that anything that does optimze something marked
volatile is buggy, how can that PR be considered a bug in GCC?

| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21580

  GCC generates:

 (1) read the volatile variable into location rho;
 (2) compute rho <- rho + 1
 (3) store rho back in the variable

As far as I can see, this matches the previous statement that anything
that is marrked volatile is not optimized.  


| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20222

   Andrew Pinski has declared this to be a bug, but the audit trail
   isn't clear as to why.

| (there's a couple others).
| 
| Then again, I'm pretty  willing at this point to laugh at people who use
| volatile and complain about code quality

then you'll be in good company ;-/

-- Gaby

Re: volatile semantics

[Gabriel Dos Reis]

Daniel Berlin <[EMAIL PROTECTED]> writes:

[...]

| > I think that is urgent. 
| No offense, but everyone thinks the problems that affect them are the
| most urgent.

miscompilation of KDE was declared urgent; I hope bug affecting code
semantics for X is not just "request for enhancement".

-- Gaby

Re: volatile semantics

[Daniel Berlin]

On Sun, 2005-07-17 at 05:13 +0200, Gabriel Dos Reis wrote:
> Daniel Berlin <[EMAIL PROTECTED]> writes:
> 
> [...]
> 
> | > I think that is urgent. 
> | No offense, but everyone thinks the problems that affect them are the
> | most urgent.
> 
> miscompilation of KDE was declared urgent; I hope bug affecting code
> semantics for X is not just "request for enhancement".

Not for me to judge. That's why we have Mark.
As i said, it would probably be fixed before 4.1 whether done by me or
someone else.

Re: volatile semantics

[Michael Veksler]

Gabriel Dos Reis wrote on 17/07/2005 06:07:29:
>
> | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20222
>
>Andrew Pinski has declared this to be a bug, but the audit trail
>isn't clear as to why.
>

Maybe because gcc treats -O1 differently from -O2, -O3,
and -Os ? Also, since abs is a (built in) function, passing
  extern volatile int i1;
as a parameter to abs(int) should be generating a single
memory access - only when the parameter is created.
The implementation of abs should not matter in this case -
as the parameter has already been copied.

If abs was implemented as inline rather than built in:
  inline int abs(int a) { return a < 0 ? -a : a ; }
would it still generate 2 loads? This does not make sense,
since abs is a separate function, with `a' being declared as
a non-volatile variable.


  Michael

Re: volatile semantics

[D. Hugh Redelmeier]

| From: Gabriel Dos Reis <[EMAIL PROTECTED]>

| Daniel Berlin <[EMAIL PROTECTED]> writes:
| 
| [...]
| 
| | > I think that is urgent. 
| | No offense, but everyone thinks the problems that affect them are the
| | most urgent.
| 
| miscompilation of KDE was declared urgent; I hope bug affecting code
| semantics for X is not just "request for enhancement".

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161242#c120
[Comment 120, if your browser doesn't get to the right spot]

Here is the text, written by Olivier Baudron:

There are 100+ casts into volatile in xorg-x11 and some of them
are in libvgahw.  All of these are "miscompiled" by gcc4 -O2. The
patch in -43 (one volatile fixed in libvgahw) was enough for my
G400.  Unfortunatly, other hardware are depending upon volatile
side effects found elsewhere in libvgahw or even elsewhere in
xorg. Thus reported scenarii a,b,c,d are easily understood.

For now, we have fixed: 1 bug out of 100+ in 1 package out of
1000+.  I *really* suggest gcc4 be compatible with gcc3 in a near
future.

I have not verified these numbers, but they do make the bug seem
serious.


Just as I'm not a GCC hacker, I'm not an X hacker nor a kernel hacker.
What follows is idle speculation.

My feeling (i.e. it is not certain knowledge) is that a lot of X
driver code may represent scar tissue from battles with intransigent
hardware.  There may not be explicit specs that the code is following.
This may make migrating the code to another approach to volatile
somewhat destabilizing.

Another feeling I have is that 100+ casts to volatile are an
indication that the code should be refactored.  A long-term process
that should not be attempted in an emergency.

If GCC4 causes this much problem with X, I wonder what GCC4 will do to
the Linux kernel.  I understand that Linus generally prefers older
GCCs to newer ones.  It would be great if his preference were only
superstition.

Re: volatile semantics

[Michael Veksler]

Gabriel Dos Reis wrote on 17/07/2005 06:07:29:

> Daniel Berlin <[EMAIL PROTECTED]> writes:
>
> | Anything it sees anything in a statement with volatile, it marks the
> | statement as volatile, which should stop things from touching it
> | (anything that *does* optimize something marked volatile is buggy).
> great!
>

I can't agree with that as is. I would refine it to:
  Anything that *does* optimizes away visible reads or writes of
  something marked volatile is buggy.

> | I should note that this will probably annoy the people who reported :
> |
> | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3506
>
> The rationale is:
>
>GCC doesn't know what constitutes a reference to a volatile memory,
> so it never performs operations on them directly.  It will always
> pull the value into a register first.

This can be optimized, without violating the rule for read/write
visibility. It was over a decade since I were on a Pentium validation
team, so I may be wrong:
  inc mem - without a LCK prefix is not atomic, generating a
  read, and then write - behaving as if it were 3 instructions:
  [read mem; inc; write mem].
What I am getting at, is that gcc is *allowed* to optimize any
sequence of the form [read mem; arithmetic; write mem] to
[arithmetic mem], even for a  volatile int.


I do *not* say that this *has* to be optimized, only that it could.
If it had to, gcc would have a very difficult time with RISC
load/store architectures. No reasonable interpretation of the
standard may claim that gcc *should* generate a single "inc y".
I claim that in this case gcc *could* generate a single "inc y",
and as such it is a missed optimization (and the PR is valid).

It may be a very difficult optimization to implement, so
it can be postponed indefinitely, but it should not be marked
INVALID. It should be marked a SUSPENDED missed
optimization opportunity (for x86 and probably several
other CISCs - as long as read/write is not atomic).


   Michael

Re: volatile semantics

[Gabriel Dos Reis]

"D. Hugh Redelmeier" <[EMAIL PROTECTED]> writes:

[...]

| If GCC4 causes this much problem with X, I wonder what GCC4 will do to
| the Linux kernel.  I understand that Linus generally prefers older
| GCCs to newer ones.  It would be great if his preference were only
| superstition.

I do not follow the linux kernel on a regular basis, so I may miss
things there.  However, I regularly follow the GMP development list
and it has been advised by GMP delopers NOT to use GCC4.0.x because of
alleged miscompilation problems 

   http://www.swox.com/gmp/

 [...]

 For GMP 4.1.4, we recommend that you use GCC 3.3.x or
 older. We've had some luck with GCC 3.4.x on some systems, but we
 have yet to find a system where GCC 4.0 builds, and neither
 crashes or miscompiles the GMP sources.

I have not analysed the problems in GMP and make no claim that it has
to do with volatile or not.  Torbjörn knows more:

   http://swox.com/list-archives/gmp-discuss/2005-July/001750.html

-- Gaby

Re: volatile semantics

[Gabriel Dos Reis]

Michael Veksler <[EMAIL PROTECTED]> writes:

| Gabriel Dos Reis wrote on 17/07/2005 06:07:29:
| 
| > Daniel Berlin <[EMAIL PROTECTED]> writes:
| >
| > | Anything it sees anything in a statement with volatile, it marks the
| > | statement as volatile, which should stop things from touching it
| > | (anything that *does* optimize something marked volatile is buggy).
| > great!
| >
| 
| I can't agree with that as is. I would refine it to:
|   Anything that *does* optimizes away visible reads or writes of
|   something marked volatile is buggy.

How do you define "visible reads or writes", and how is it different
from Daniel's statement?

-- Gaby

howto multilib gcc mainline on sparc-linux?

[Christian Joensson]

I just tried, what I thought to be default enabled, to build a
multilibbed gcc mainline. However, when I run the testsuite with -m64
flag, I get warnings like this (this is from gcc testsuite)

Executing on host: /usr/local/src/trunk/objdir32/gcc/xgcc
-B/usr/local/src/trunk/objdir32/gcc/   -O0  -w -fno-show-column -c 
-m64 -o 2105-1.o
/usr/local/src/trunk/gcc/gcc/testsuite/gcc.c-torture/compile/2105-1.c
   (timeout = 600)
/usr/local/src/trunk/gcc/gcc/testsuite/gcc.c-torture/compile/2105-1.c:1:
error: -m64 is not supported by this configuration
/usr/local/src/trunk/gcc/gcc/testsuite/gcc.c-torture/compile/2105-1.c:1:
error: -mlong-double-64 not allowed with -m64
compiler exited with status 1
output is:
/usr/local/src/trunk/gcc/gcc/testsuite/gcc.c-torture/compile/2105-1.c:1:
error: -m64 is not supported by this configuration
/usr/local/src/trunk/gcc/gcc/testsuite/gcc.c-torture/compile/2105-1.c:1:
error: -mlong-double-64 not allowed with -m64

FAIL: gcc.c-torture/compile/2105-1.c  -O0  (test for excess errors)
Excess errors:
/usr/local/src/trunk/gcc/gcc/testsuite/gcc.c-torture/compile/2105-1.c:1:
error: -m64 is not supported by this configuration
/usr/local/src/trunk/gcc/gcc/testsuite/gcc.c-torture/compile/2105-1.c:1:
error: -mlong-double-64 not allowed with -m64


This is on 

Aurora SPARC Linux release 2.0 (Kashmir FC3) UltraSparc IIi (Sabre) sun4u:

(auroralinux corona + Rathann's FC3 updates)

binutils-2.15.92.0.2-5.1sparc.sparc
bison-1.875c-2.sparc
dejagnu-1.4.4-2.noarch
expect-5.42.1-1.sparc
gcc-3.4.2-6.fc3.sparc
gcc4-4.0.0-0.8sparc.sparc
glibc-2.3.5-0.fc3.1.sparcv9
glibc-2.3.5-0.fc3.1.sparc64
glibc-devel-2.3.5-0.fc3.1.sparc64
glibc-devel-2.3.5-0.fc3.1.sparc
glibc-headers-2.3.5-0.fc3.1.sparc
glibc-kernheaders-2.6-20sparc.sparc
gmp-4.1.4-3sparc.sparc
gmp-4.1.4-3sparc.sparc64
gmp-devel-4.1.4-3sparc.sparc
gmp-devel-4.1.4-3sparc.sparc64
kernel-2.6.11-1.1166sp1.sparc64
package kernel-devel is not installed
package kernel-smp is not installed
libgcc-3.4.2-6.fc3.sparc
libgcc-3.4.2-6.fc3.sparc64
libstdc++-3.4.2-6.fc3.sparc64
libstdc++-3.4.2-6.fc3.sparc
libstdc++-devel-3.4.2-6.fc3.sparc64
libstdc++-devel-3.4.2-6.fc3.sparc
make-3.80-5.sparc
nptl-devel-2.3.5-0.fc3.1.sparcv9
tcl-8.4.7-2.sparc

LAST_UPDATED: Fri Jul 15 20:35:20 UTC 2005

and the configure was done like this:

CC="gcc -m32" /usr/local/src/trunk/gcc/configure sparc-linux \
--enable-__cxa_atexit \
--enable-shared --enable-languages=c,ada,c++,f95,objc,treelang \
>& configure.log;

this is done in a "64 bit shell"

[EMAIL PROTECTED] objdir32]$ uname -a
Linux ultra10.j-son.org 2.6.11-1.1166sp1 #1 Fri Mar 4 20:41:51 EST
2005 sparc64 sparc64 sparc64 GNU/Linux
[EMAIL PROTECTED] objdir32]$

I then checked the build log file and AFAICT the libs are not built
with -m64 also as alternative... so, my question, what have I missed?

-- 
Cheers,

/ChJ