The aliasing policies that GCC implements seem to be more strict than
what is in the C99 standard. I am wondering if this is true or whether
I am mistaken (I am not an expert on the standard, so the latter is
definitely possible).
The relevant text is:
An object shall have its stored value acc
Richard Guenther gmail.com> writes:
> On Sun, Jan 3, 2010 at 6:46 AM, Joshua Haberman
gmail.com> wrote:
> > The aliasing policies that GCC implements seem to be more strict than
> > what is in the C99 standard. I am wondering if this is true or whether
> > I am mist
Andrew Haley redhat.com> writes:
> On 01/03/2010 10:53 AM, Richard Guenther wrote:
> > GCC follows its own documentation here, not some random
> > websites and maybe not the strict reading of the standard.
>
> GCC is compatible with C99 in this regard.
I do not believe this is true. Your argumen
Patrick Horgan yahoo.com> writes:
> Since it would be hard to read this any other way, it seems then you-
> maintain that you found a bug in the standard, has it been brought up to-
> the committee? The latest draft I see still has that wording. Doesn't-
> seem to be on the radar for C1x.
I str
Richard Guenther gmail.com> writes:
> On Sun, Jan 3, 2010 at 10:55 PM, Joshua Haberman
gmail.com> wrote:
> > This is why perfect warnings about this issue are not possible; if we
> > see a downcast in isolation, we do not know if it is undoing a previous
> > upcas
By the way, here is one case I tested where I was surprised GCC was not
more aggressive:
extern void bar();
int foo(int *i) {
if(*i) bar();
return *i;
}
With GCC 4.4.1 -O3 (Ubuntu, x86-64) this reloads *i if bar is called. I
suppose you have to allow that either "i" or "*i" is acce
Andrew Haley redhat.com> writes:
> On 01/03/2010 10:14 PM, Joshua Haberman wrote:
> > Andrew Haley redhat.com> writes:
> "6.3.2.3
>
> "A pointer to an object or incomplete type may be converted to a
> pointer to a different object or incomplete type. If the
Erik Trulsson student.uu.se> writes:
> On Mon, Jan 04, 2010 at 08:17:00PM +, Joshua Haberman wrote:
> > The text you quoted does not contain any "shall not" language about
> > dereferencing, so this conclusion does not follow.
>
> It doesn't have t
Robert Dewar adacore.com> writes:
> In any case the gcc interpretation is clearly what's
> intended in my view, so if it can be argued that the
> standard is inconsistent with this interpretation (I
> am unconvinced that this burden has been met), then
> the conclusion is to add a clarification to
Andrew Haley redhat.com> writes:
> but
>
> (union u*)&i
>
> is not a legal lvalue expression because the dereference is undefined
> behaviour.
Your example does not contain a dereference.
> You may only dereference a pointer as permitted by 6.3.2.3.
6.3.2.3 does not mention dereferencing at al
Erik Trulsson student.uu.se> writes:
> On Sun, Jan 03, 2010 at 05:46:48AM +, Joshua Haberman wrote:
> > The aliasing policies that GCC implements seem to be more strict than
> > what is in the C99 standard. I am wondering if this is true or whether
> > I am mistake
Richard Guenther gmail.com> writes:
> On Wed, Jan 6, 2010 at 7:20 PM, Nick Stoughton msbit.com>
wrote:
> > The C1x timetable has us finishing the draft for an initial ballot this
> > summer (the April Florence meeting being the last chance to submit new
> > material). The best expert I know on t
Erik Trulsson student.uu.se> writes:
> > int i;
> > unsigned int *pui = (unsigned int*)&i;
> > unsigned int ui = *pui;
>
> (First I will assume that 'i' will be assigned some value, to make sure it
> does not contain a trap-representation, or the assignment to 'ui' would have
> undefined beh
I have a case where I think useless stores are being generated, but I
want to be sure before I file a bug. This is with gcc 4.4.3 on Ubuntu
10.04, x86-64.
I have been experimenting with returning structs from functions instead
of passing pointers to "out" parameters. This seems like it should be
Ian Lance Taylor google.com> writes:
> Joshua Haberman gmail.com> writes:
>
> > I have a case where I think useless stores are being generated, but I
> > want to be sure before I file a bug. This is with gcc 4.4.3 on Ubuntu
> > 10.04, x86-64.
>
> I concu
15 matches
Mail list logo
