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
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
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 perform
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
> 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 jus
[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
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 impl
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
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/j
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
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 (c
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 l
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 cas
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
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: err
> 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
> "te
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
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 co
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
[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 se
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 c
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 tu
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 f
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 thin
> | 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 n
"D. Hugh Redelmeier" <[EMAIL PROTECTED]> writes:
[...]
| - let's not talk about "restrict"
Oh, it was getting fun :-)
-- Gaby
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
(alt
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 sourc
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 t
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 c
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 y
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 y
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
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
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 understa
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 wor
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.
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 a
| 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 th
"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
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
| 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.
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-gener
"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
| | beha
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
> 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.
I
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
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
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 a
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 (b
| 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
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 volatil
"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 follo
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
| > |
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
55 matches
Mail list logo
