return void from void function is allowed.

2006-10-31 Thread Igor Bukanov

GCC 4.1.2 and 4.0.3 incorrectly accepts the following program:

void f();

void g()
{
   return f();
}

No warning are issued on my Ubuntu Pentium-M box. Is it a known bug?

Regards, Igor


return void from void function is allowed.

2006-10-31 Thread Igor Bukanov

-- Forwarded message --
From: Igor Bukanov <[EMAIL PROTECTED]>
Date: Oct 31, 2006 9:48 PM
Subject: Re: return void from void function is allowed.
To: Mike Stump <[EMAIL PROTECTED]>


On 10/31/06, Mike Stump <[EMAIL PROTECTED]> wrote:


This is valid in C++.


My copy of 1997 C++ public draft contains:

6.6.3  The return statement
...
2 A return statement without an expression can be used only in functions
 that  do not return a value, that is, a function with the return value
 type   void,   a   constructor   (_class.ctor_),   or   a   destructor
 (_class.dtor_).   A  return  statement  with an expression can be used
 only in functions returning a value; the value of  the  expression  is
 returned  to  the caller of the function.  If required, the expression
 is implicitly converted to the return type of the function in which it
 appears.   A return statement can involve the construction and copy of
 a temporary object (_class.temporary_).  Flowing  off  the  end  of  a
 function  is  equivalent  to  a  return with no value; this results in
 undefined behavior in a value-returning function.

My reading of that is C++ does not allow return void-expression from
void function. Was it changed later?


And final thought, wrong mailing list...   gcc-help would have been

better.

I thought bugs in GCC can be discussed here. Sorry if it is a wrong assumption.

Regards, Igor


Option to print word size, alignment on the target platform

2006-01-25 Thread Igor Bukanov
Is there any option to ask GCC to print various size and alignment
info on the target platform?  This would be very nice during cross
compilation when one can not run the executables to autoconfigure for
such parameters.

Currently I consider for that a hack like copiling the following source:

#include 
union aligned_fields {
double d;
void (*f)();
...
};

struct align_test {
union aligned_fields u1;
char c;
};

const char DATA_POINTER_SIZE[sizeof(void *)];
const char FUNCTION_POINTER_SIZE[sizeof(void (*)())];
const char UNIVERSAL_ALIGN[offsetof(struct align_test, c)];
const char SHORT_SIZE[sizeof(short)];

and then running "nm --print-size" from binutils for the target on it to get:
0004 0004 C DATA_POINTER_SIZE
0004 0004 C FUNCTION_POINTER_SIZE
0002 0002 C SHORT_SIZE
0008 0008 C UNIVERSAL_ALIGN

But I doubt that this is reliable. So perhaps there is something like
gcc -print-target-info ?


Re: Option to print word size, alignment on the target platform

2006-01-25 Thread Igor Bukanov
On 1/25/06, Paul Brook <[EMAIL PROTECTED]> wrote:
> Autoconf already has tests for things like this. Something along the lines of:
>
> const char D_P_S_4[sizeof(void *) == 4 : -1 : 1];
> const char D_P_S_8[sizeof(void *) == 8 : -1 : 1];
>
> Then see which compiles, or grep the error messages.

Right, but are there any way to learn about endianess of the paltform
or the direction of stack growth just from knowing that program
compiles or not? GCC nows about this and it would be nice if there is
a way to expose these.

Regards, Igor


Re: Option to print word size, alignment on the target platform

2006-01-25 Thread Igor Bukanov
On 1/25/06, Robert Dewar <[EMAIL PROTECTED]> wrote:
> A convenient way to get the endianness is to use
> the System.Bit_Order attribute in Ada.

But this requires to run the program on the target which is not
possible with a cross-compiler. Or is there a trick to declare
something in Ada that would force the program to miscompile depending
on the target endianness?

Regards, Igor


GCC 4.1: too strict aliasing?

2006-05-15 Thread Igor Bukanov

Consider the following code that starting with GCC 4.1.0 generates
'dereferencing type-punned pointer will break strict-aliasing rules'
warning:


~> cat test.c
struct inner {
   struct inner *next;
};

struct outer {
   struct inner base;
   int value;
};

/* List of outer elements where all outer.base.next point to struct outer */
struct outer_list {
   struct outer *head;
};

struct outer *search_list(struct outer_list *list, int value)
{
   struct outer *elem, **pelem;

   pelem = &list->head;
   while ((elem = *pelem)) {
   if (elem->base.value == value) {
   /* Hit, move atom's element to the front of the list. */
   *pelem = (struct outer*)elem->base.next;
   elem->base.next = &list->head->base;
   list->head = elem;
   return elem;
   }

   /*** LINE GENERATING WARNING */
   pelem = (struct outer **)&elem->base.next;
   }
   return 0;
}

~> gcc -c -Wall -O2 test.c
test.c: In function 'search_list':
test.c:29: warning: dereferencing type-punned pointer will break
strict-aliasing rules

But why the warning is generated? Doesn't it guaranteed that
offsetof(struct outer, base) == 0 and one can always safely cast
struct inner* to struct outer* if struct inner is a part struct outer
so struct* outer can alias struct* inner?