Possible Bug

Possible Bug

[Nathan Boley]

[-- Attachment #1: Type: text/plain, Size: 1748 bytes --]

Hi All,

In a much larger application, I was getting a weird segfault that an
assignment to a temporary variable fixed. I distilled the example into
the attached "test_case.c". When I run test_case.c under valgrind I
get a memory read error, and it segfaults with electric fence, but I'm
not actually able to get a true segfault. However, I am pretty sure
that the same issue was causing the segfault in my application.

From my really limited assembly knowledge, it looks that on 64 bit
machines gcc is trying to do a full 8 byte read into the register
followed by a 2 byte shift ( instead of 4 then 2 byte read ). If the
two extra bytes are out of bounds it will segfault. This explains why
I get the sporadic segfaults in my bigger application ( where I can
actually be at the page boundary ), but not in the test case.

This only occurs on 64 bit machines, and my gcc version info is:

nboley@ingvas:~/Desktop$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.4.4-14ubuntu5'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.4 --enable-shared --enable-multiarch
--enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib
--enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-objc-gc --disable-werror
--with-arch-32=i686 --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5)

Best,
Nathan Boley

[-- Attachment #2: test_case.c --]
[-- Type: text/x-csrc, Size: 1025 bytes --]

#include <stdio.h>
#include <stdlib.h>

/* Does NOT cause memory error */
typedef struct __attribute__((__packed__))
{
   unsigned short chr;
   unsigned int loc;
} GENOME_LOC_TYPE_2;

/* Causes memory error */
typedef struct __attribute__((__packed__))
{
   unsigned chr            :16;
   unsigned loc            :32;
} GENOME_LOC_TYPE;

void
print_mapped_location( GENOME_LOC_TYPE loc )
{
   printf( "%i\n", loc.loc );
}

int main( int argc, char* argv )
{
   char* data;
   data = malloc(12*sizeof(char));

   GENOME_LOC_TYPE* gen_array
       = (GENOME_LOC_TYPE*) data;
   gen_array[0].loc = 0;
   gen_array[1].loc = 1;

   /* Make sure the structure is actually 6 bytes */
   printf("Gen Loc Type Size: %zu\n", sizeof(GENOME_LOC_TYPE) );

   /* Works fine. */
   printf( "%i\n", gen_array[1].loc );

   /* Works fine */
   GENOME_LOC_TYPE loc = gen_array[1];
   print_mapped_location( loc );

   /* Causes valgrind error */
   /* Cause -lefence segfault */
   print_mapped_location( gen_array[1] );

   free( data );
}

Re: Possible Bug

[Ian Lance Taylor]

Nathan Boley <npboley@gmail.com> writes:

> In a much larger application, I was getting a weird segfault that an
> assignment to a temporary variable fixed. I distilled the example into
> the attached "test_case.c". When I run test_case.c under valgrind I
> get a memory read error, and it segfaults with electric fence, but I'm
> not actually able to get a true segfault. However, I am pretty sure
> that the same issue was causing the segfault in my application.

There is nothing wrong if gcc is reading an 8-byte value at an 8-byte
aligned address.  That can not cause a memory read error.  To a program
like valgrind it may look like a read of an uninitialized memory
location, but because the location is aligned and the values loaded from
the uninitialized memory is ignored, everything will work fine.

That said, I could not recreate the problem with your test case.  I only
see 4-byte loads.

Ian

Re: Possible Bug

[Paolo Bonzini]

On 03/27/2011 06:27 AM, Ian Lance Taylor wrote:
> Nathan Boley<npboley@gmail.com>  writes:
>
>> In a much larger application, I was getting a weird segfault that an
>> assignment to a temporary variable fixed. I distilled the example into
>> the attached "test_case.c". When I run test_case.c under valgrind I
>> get a memory read error, and it segfaults with electric fence, but I'm
>> not actually able to get a true segfault. However, I am pretty sure
>> that the same issue was causing the segfault in my application.
>
> There is nothing wrong if gcc is reading an 8-byte value at an 8-byte
> aligned address.

Note the struct is packed, so alignof = 1.

> That said, I could not recreate the problem with your test case.  I only
> see 4-byte loads.

I see it with this modified testcase:

#include <stdio.h>
#include <stdlib.h>

/* GCC uses 4-byte + 2-byte loads and stack passing */
typedef struct __attribute__((__packed__))
{
    unsigned short chr;
    unsigned int loc;
} GENOME_LOC_TYPE_1;

/* GCC uses 8-byte loads and register passing even though sizeof = 6 */
typedef struct __attribute__((__packed__))
{
    unsigned chr            :16;
    unsigned loc            :32;
} GENOME_LOC_TYPE_2;

//#define GENOME_LOC_TYPE GENOME_LOC_TYPE_1
#define GENOME_LOC_TYPE GENOME_LOC_TYPE_2

static __attribute__((__noclone__,__noinline__))
int f(GENOME_LOC_TYPE x)
{
   return x.loc;
}

GENOME_LOC_TYPE h;
GENOME_LOC_TYPE *g = &h;

int
main()
{
   printf ("%d %d\n", sizeof (GENOME_LOC_TYPE),
                      __alignof__(GENOME_LOC_TYPE));
   return f(*g);
}


Both definitions have a (sizeof = 6, alignof = 1) but GCC loads the 
second with an 8-byte load.  It's really an ugly bug if I understood it 
correctly, because I would have expected the second struct to have 
sizeof = 8.  The two final bytes are not padding, they are what's left 
of the unsigned int from which the bitfields are carved.  If that were 
the correct fix for the bug, it would be a change to the ABI.

Paolo

Re: Possible Bug

[Richard Guenther]

On Mon, Mar 28, 2011 at 12:42 PM, Paolo Bonzini <bonzini@gnu.org> wrote:
> On 03/27/2011 06:27 AM, Ian Lance Taylor wrote:
>>
>> Nathan Boley<npboley@gmail.com>  writes:
>>
>>> In a much larger application, I was getting a weird segfault that an
>>> assignment to a temporary variable fixed. I distilled the example into
>>> the attached "test_case.c". When I run test_case.c under valgrind I
>>> get a memory read error, and it segfaults with electric fence, but I'm
>>> not actually able to get a true segfault. However, I am pretty sure
>>> that the same issue was causing the segfault in my application.
>>
>> There is nothing wrong if gcc is reading an 8-byte value at an 8-byte
>> aligned address.
>
> Note the struct is packed, so alignof = 1.
>
>> That said, I could not recreate the problem with your test case.  I only
>> see 4-byte loads.
>
> I see it with this modified testcase:
>
> #include <stdio.h>
> #include <stdlib.h>
>
> /* GCC uses 4-byte + 2-byte loads and stack passing */
> typedef struct __attribute__((__packed__))
> {
>   unsigned short chr;
>   unsigned int loc;
> } GENOME_LOC_TYPE_1;
>
> /* GCC uses 8-byte loads and register passing even though sizeof = 6 */
> typedef struct __attribute__((__packed__))
> {
>   unsigned chr            :16;
>   unsigned loc            :32;
> } GENOME_LOC_TYPE_2;
>
> //#define GENOME_LOC_TYPE GENOME_LOC_TYPE_1
> #define GENOME_LOC_TYPE GENOME_LOC_TYPE_2
>
> static __attribute__((__noclone__,__noinline__))
> int f(GENOME_LOC_TYPE x)
> {
>  return x.loc;
> }
>
> GENOME_LOC_TYPE h;
> GENOME_LOC_TYPE *g = &h;
>
> int
> main()
> {
>  printf ("%d %d\n", sizeof (GENOME_LOC_TYPE),
>                     __alignof__(GENOME_LOC_TYPE));
>  return f(*g);
> }
>
>
> Both definitions have a (sizeof = 6, alignof = 1) but GCC loads the second
> with an 8-byte load.  It's really an ugly bug if I understood it correctly,
> because I would have expected the second struct to have sizeof = 8.  The two
> final bytes are not padding, they are what's left of the unsigned int from
> which the bitfields are carved.  If that were the correct fix for the bug,
> it would be a change to the ABI.

At expansion time we have the following for the call argument:

 <mem_ref 0x7ffff7ff9118
    type <record_type 0x7ffff5b295e8 GENOME_LOC_TYPE_2 packed type_0 BLK
        size <integer_cst 0x7ffff5b256b8 constant 48>
        unit size <integer_cst 0x7ffff5b25708 constant 6>
        align 8 symtab 0 alias set -1 canonical type 0x7ffff5b29540

which looks ok to me.  expand generates a MEM of BLKmode:

(mem/s:BLK (reg/f:DI 62) [0 MEM[(struct GENOME_LOC_TYPE_2 *)g.0_1]+0 S6 A8])

which is also ok.  But then calls.c calls move_block_to_reg and messes
up via operand_subword_force (mem, 0, BLKmode) which simply makes
a DImode mem out of it.

Richard.

Re: Possible Bug

[Paolo Bonzini]

On 03/28/2011 01:06 PM, Richard Guenther wrote:
>> /* GCC uses 8-byte loads and register passing even though sizeof = 6 */
>> typedef struct __attribute__((__packed__))
>> {
>>    unsigned chr            :16;
>>    unsigned loc            :32;
>> } GENOME_LOC_TYPE_2;
>>
>> //#define GENOME_LOC_TYPE GENOME_LOC_TYPE_1
>> #define GENOME_LOC_TYPE GENOME_LOC_TYPE_2
>>
>> static __attribute__((__noclone__,__noinline__))
>> int f(GENOME_LOC_TYPE x)
>> {
>>   return x.loc;
>> }
>>
>> GENOME_LOC_TYPE h;
>> GENOME_LOC_TYPE *g =&h;
>>
>> int
>> main()
>> {
>>   printf ("%d %d\n", sizeof (GENOME_LOC_TYPE),
>>                      __alignof__(GENOME_LOC_TYPE));
>>   return f(*g);
>> }
>>
>>
>> Both definitions have a (sizeof = 6, alignof = 1) but GCC loads the second
>> with an 8-byte load.  It's really an ugly bug if I understood it correctly,
>> because I would have expected the second struct to have sizeof = 8.  The two
>> final bytes are not padding, they are what's left of the unsigned int from
>> which the bitfields are carved.  If that were the correct fix for the bug,
>> it would be a change to the ABI.
>
> At expansion time we have the following for the call argument:
>
>   <mem_ref 0x7ffff7ff9118
>      type<record_type 0x7ffff5b295e8 GENOME_LOC_TYPE_2 packed type_0 BLK
>          size<integer_cst 0x7ffff5b256b8 constant 48>
>          unit size<integer_cst 0x7ffff5b25708 constant 6>
>          align 8 symtab 0 alias set -1 canonical type 0x7ffff5b29540
>
> which looks ok to me.

It already isn't, why is the alignment 8 if __alignof__ 
(GENOME_LOC_TYPE_2) is 1?

The other question is a layout question, should the packed attribute 
affect the removal of padding from the last bitfield element?  That's a 
very different kind of padding, and it affects whether the size of the 
struct should be 6 or 8?  Note this is slightly different from the 
problem in -Wpacked-bitfield-compat.

In fact, should the poster's desired layout (the same as 
GENOME_LOC_TYPE_1, I guess) be achievable at all with bitfields, even in 
combination with the packed attribute?

Paolo

Re: Possible Bug

[Richard Guenther]

On Mon, Mar 28, 2011 at 1:36 PM, Paolo Bonzini <bonzini@gnu.org> wrote:
> On 03/28/2011 01:06 PM, Richard Guenther wrote:
>>>
>>> /* GCC uses 8-byte loads and register passing even though sizeof = 6 */
>>> typedef struct __attribute__((__packed__))
>>> {
>>>   unsigned chr            :16;
>>>   unsigned loc            :32;
>>> } GENOME_LOC_TYPE_2;
>>>
>>> //#define GENOME_LOC_TYPE GENOME_LOC_TYPE_1
>>> #define GENOME_LOC_TYPE GENOME_LOC_TYPE_2
>>>
>>> static __attribute__((__noclone__,__noinline__))
>>> int f(GENOME_LOC_TYPE x)
>>> {
>>>  return x.loc;
>>> }
>>>
>>> GENOME_LOC_TYPE h;
>>> GENOME_LOC_TYPE *g =&h;
>>>
>>> int
>>> main()
>>> {
>>>  printf ("%d %d\n", sizeof (GENOME_LOC_TYPE),
>>>                     __alignof__(GENOME_LOC_TYPE));
>>>  return f(*g);
>>> }
>>>
>>>
>>> Both definitions have a (sizeof = 6, alignof = 1) but GCC loads the
>>> second
>>> with an 8-byte load.  It's really an ugly bug if I understood it
>>> correctly,
>>> because I would have expected the second struct to have sizeof = 8.  The
>>> two
>>> final bytes are not padding, they are what's left of the unsigned int
>>> from
>>> which the bitfields are carved.  If that were the correct fix for the
>>> bug,
>>> it would be a change to the ABI.
>>
>> At expansion time we have the following for the call argument:
>>
>>  <mem_ref 0x7ffff7ff9118
>>     type<record_type 0x7ffff5b295e8 GENOME_LOC_TYPE_2 packed type_0 BLK
>>         size<integer_cst 0x7ffff5b256b8 constant 48>
>>         unit size<integer_cst 0x7ffff5b25708 constant 6>
>>         align 8 symtab 0 alias set -1 canonical type 0x7ffff5b29540
>>
>> which looks ok to me.
>
> It already isn't, why is the alignment 8 if __alignof__ (GENOME_LOC_TYPE_2)
> is 1?
>
> The other question is a layout question, should the packed attribute affect
> the removal of padding from the last bitfield element?  That's a very
> different kind of padding, and it affects whether the size of the struct
> should be 6 or 8?  Note this is slightly different from the problem in
> -Wpacked-bitfield-compat.
>
> In fact, should the poster's desired layout (the same as GENOME_LOC_TYPE_1,
> I guess) be achievable at all with bitfields, even in combination with the
> packed attribute?

Btw, this looks like http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36043

Richard.

> Paolo
>

Re: Possible Bug

[Michael Matz]

Hi,

On Mon, 28 Mar 2011, Paolo Bonzini wrote:

> > At expansion time we have the following for the call argument:
> >
> >   <mem_ref 0x7ffff7ff9118
> >      type<record_type 0x7ffff5b295e8 GENOME_LOC_TYPE_2 packed type_0 BLK
> >          size<integer_cst 0x7ffff5b256b8 constant 48>
> >          unit size<integer_cst 0x7ffff5b25708 constant 6>
> >          align 8 symtab 0 alias set -1 canonical type 0x7ffff5b29540
> >
> > which looks ok to me.
> 
> It already isn't, why is the alignment 8 if __alignof__ 
> (GENOME_LOC_TYPE_2) is 1?

The aligns are printed in bits.  It really is okay, as is the MEM.

> The other question is a layout question, should the packed attribute 
> affect the removal of padding from the last bitfield element?

A hypothetical question because we can't change this behaviour after about 
15 years.  Even if we could I'd argue that the current behaviour is 
correct (because we lack another attribute that would say 'and please also 
pack arrays of this type tightly', which then would finally imply that 
final padding is also removed, and hence we'd then hit this very same bug 
with testcases using _that_ attribute instead of packed).

As some digging shows, already GCC 1.35 had effectively the same code.  
As soon as parameters are passed in registers GCC loads the parts fitting 
into registers as full words.  We could simply sorry() for these cases, as 
they never worked correctly.  Though I suppose that's quite unforgiving, 
as most of the time (struct in question not passing page border) it works 
fine.


Ciao,
Michael.

Re: Possible Bug

[Paolo Bonzini]

On 03/28/2011 02:27 PM, Michael Matz wrote:
>>>    <mem_ref 0x7ffff7ff9118
>>>       type<record_type 0x7ffff5b295e8 GENOME_LOC_TYPE_2 packed type_0 BLK
>>>           size<integer_cst 0x7ffff5b256b8 constant 48>
>>>           unit size<integer_cst 0x7ffff5b25708 constant 6>
>>>           align 8 symtab 0 alias set -1 canonical type 0x7ffff5b29540
>>>
>>> which looks ok to me.
>>
>> It already isn't, why is the alignment 8 if __alignof__
>> (GENOME_LOC_TYPE_2) is 1?
>
> The aligns are printed in bits.  It really is okay, as is the MEM.

Uff, I'm always confused by align being printed after the unit size.

> As some digging shows, already GCC 1.35 had effectively the same code.
> As soon as parameters are passed in registers GCC loads the parts fitting
> into registers as full words.  We could simply sorry() for these cases, as
> they never worked correctly.  Though I suppose that's quite unforgiving,
> as most of the time (struct in question not passing page border) it works
> fine.

We should warn, I think.

Paolo

Re: Possible Bug

[Richard Guenther]

On Mon, Mar 28, 2011 at 3:36 PM, Paolo Bonzini <bonzini@gnu.org> wrote:
> On 03/28/2011 02:27 PM, Michael Matz wrote:
>>>>
>>>>   <mem_ref 0x7ffff7ff9118
>>>>      type<record_type 0x7ffff5b295e8 GENOME_LOC_TYPE_2 packed type_0 BLK
>>>>          size<integer_cst 0x7ffff5b256b8 constant 48>
>>>>          unit size<integer_cst 0x7ffff5b25708 constant 6>
>>>>          align 8 symtab 0 alias set -1 canonical type 0x7ffff5b29540
>>>>
>>>> which looks ok to me.
>>>
>>> It already isn't, why is the alignment 8 if __alignof__
>>> (GENOME_LOC_TYPE_2) is 1?
>>
>> The aligns are printed in bits.  It really is okay, as is the MEM.
>
> Uff, I'm always confused by align being printed after the unit size.
>
>> As some digging shows, already GCC 1.35 had effectively the same code.
>> As soon as parameters are passed in registers GCC loads the parts fitting
>> into registers as full words.  We could simply sorry() for these cases, as
>> they never worked correctly.  Though I suppose that's quite unforgiving,
>> as most of the time (struct in question not passing page border) it works
>> fine.
>
> We should warn, I think.

We should fix the bug ;)

Richard.

> Paolo
>

Re: Possible Bug

[Nathan Boley]

>>> As some digging shows, already GCC 1.35 had effectively the same code.
>>> As soon as parameters are passed in registers GCC loads the parts fitting
>>> into registers as full words.  We could simply sorry() for these cases, as
>>> they never worked correctly.  Though I suppose that's quite unforgiving,
>>> as most of the time (struct in question not passing page border) it works
>>> fine.
>>
>> We should warn, I think.
>
> We should fix the bug ;)

Agreed ;-)

FWIW, this was particularly nasty because it was serious ( the
segfault lost more than a days work on a couple of occasions ) and it
was very very difficult to track down due to the fact that:

1) the read rarely crosses the page boundary. ( as others have noted )
2) seemingly trivial changes to the struct that didn't change the
alignment or the size would "fix" it
3) storing the data to an intermediate variable would "fix" it

Also, for some context, in my real application I am using packed
arrays of these ( so aligning each to the word boundary would be
pretty worthless ) and the bitfield is still 6 bytes but quite a bit
more complex ( copied below ).

Thank you all very much for the comments and the feedback. I am sorry
that my original report couldn't be more definitive.

Best,
Nathan Boley

#define CHR_BITS 15
#define LOCATION_BITS 28
#define MAX_NUM_SNPS 3
typedef struct __attribute__((__packed__))
{
    /* 1 if it covers at least 1 snp */
    unsigned covers_snp     :1;
    unsigned snp_coverage   :MAX_NUM_SNPS;

    /* read_type 0 = normal, 1 = junction */
    unsigned read_type      :1;

    /* the chr that the read came from */
    unsigned chr            :CHR_BITS;

    /*
     * Start of the sequence in the 5' direction -
     * so a read of length L that maps here covers
     * bps (loc, loc+1, ..., loc+L-1)
     */
    unsigned loc            :LOCATION_BITS;

} GENOME_LOC_TYPE;

Re: possible bug

[Fergus Henderson]

On 31-Jan-2003, Alexandre Oliva <aoliva@redhat.com> wrote:
> On Jan 30, 2003, Jan Hubicka <jh@suse.cz> wrote:
> 
> >> char *zot(void)
> >> {
> >> return ({foo(); 0; });
> >> }
> >> mnm:/home/akpm> /usr/local/gcc-3.2.1/bin/gcc -O -Wall -c t.c
> >> t.c: In function `zot':
> >> t.c:10: warning: return makes pointer from integer without a cast
> 
> >> I think the warning is bogus?

No, the warning is valid.

The function body calls foo(), evaluations the expression `0' with type
`int', and then converts the `int' to `char *' without a cast.

> > I think the value of  ({foo(); 0; }) is zero (value of last statement,
> > if I recall the definition), so it is corect.
> 
> But then, zero is a NULL pointer constant, isn't it?  At least in C++,
> a warning would have been very inappropriate.  I don't think one for C
> is.

`0' is a null pointer constant.  But `{foo(); 0;}' is not.
And it is the latter which is being converted to a pointer.

The code shown here is exactly analagous to

	char *zot(void)
	{
	  return (foo(), 0);
	}

except that it uses a GNU C statement-expression instead of a
comma-expression.  In both cases, the `0' expression does not itself occur
in a context in which that `0' expression itself is being converted to
a pointer; instead, the `0' expresion itself has type `int',
and the more complicated expression containing it, which is not
a null pointer constant, is the one that is being converted to
a pointer.  Since the more complicated expression is not itself
a null pointer constant, a diagnostic is required.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

Re: possible bug

[Alexandre Oliva]

On Jan 30, 2003, Jan Hubicka <jh@suse.cz> wrote:

>> char *zot(void)
>> {
>> return ({foo(); 0; });
>> }
>> mnm:/home/akpm> /usr/local/gcc-3.2.1/bin/gcc -O -Wall -c t.c
>> t.c: In function `zot':
>> t.c:10: warning: return makes pointer from integer without a cast

>> I think the warning is bogus?

> I think the value of  ({foo(); 0; }) is zero (value of last statement,
> if I recall the definition), so it is corect.

But then, zero is a NULL pointer constant, isn't it?  At least in C++,
a warning would have been very inappropriate.  I don't think one for C
is.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: possible bug

[Andrew Morton]

Jan Hubicka wrote:
> 
> > mnm:/home/akpm> cat t.c
> > void foo(void);
> >
> > char *bar(void)
> > {
> >         return 0;
> > }
> >
> > char *zot(void)
> > {
> >         return ({foo(); 0; });
> > }
> > mnm:/home/akpm> /usr/local/gcc-3.2.1/bin/gcc -O -Wall -c t.c
> > t.c: In function `zot':
> > t.c:10: warning: return makes pointer from integer without a cast
> >
> >
> > I think the warning is bogus?
> I think the value of  ({foo(); 0; }) is zero (value of last statement,
> if I recall the definition), so it is corect.
> 

Ah.  You are of course correct.

Re: possible bug

[Jan Hubicka]

> mnm:/home/akpm> cat t.c
> void foo(void);
> 
> char *bar(void)
> {
>         return 0;
> }
> 
> char *zot(void)
> {
>         return ({foo(); 0; });
> }
> mnm:/home/akpm> /usr/local/gcc-3.2.1/bin/gcc -O -Wall -c t.c
> t.c: In function `zot':
> t.c:10: warning: return makes pointer from integer without a cast
> 
> 
> I think the warning is bogus?
I think the value of  ({foo(); 0; }) is zero (value of last statement,
if I recall the definition), so it is corect.

Honza

possible bug

[Andrew Morton]

mnm:/home/akpm> cat t.c
void foo(void);

char *bar(void)
{
        return 0;
}

char *zot(void)
{
        return ({foo(); 0; });
}
mnm:/home/akpm> /usr/local/gcc-3.2.1/bin/gcc -O -Wall -c t.c
t.c: In function `zot':
t.c:10: warning: return makes pointer from integer without a cast


I think the warning is bogus?

Re: possible bug

[Alexandre Oliva]

On Jul 25, 1999, Manush Dodunekov <manush@litecom.se> wrote:

> The code below compiles fine with no flags, but fails to compile with a
> parse error on the line containing "iterator i;" when compiling with
> -pedantic.

That's correct.  Members of template-dependent base classes must be
explicitly qualified.  Without -pedantic, gcc accepts it as an
extension.

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
oliva@{dcc.unicamp.br,guarana.{org,com}} aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
** I may forward mail about projects to mailing lists; please use them

Re: possible bug

[Alexandre Oliva]

On Jul 27, 1999, Manush Dodunekov <manush@litecom.se> wrote:

> 	vector<T>::iterator i;
> doesn't help the compile; It only compiles when using 
> 	typename vector<T>::iterator i;

> What does the standard say on this?

`typename' is required before template-dependent qualified type
names.

> Shouldn't the first case be enough?

It'll probably work without -pedantic, but it is a gcc extension,
don't count on it.

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
oliva@{dcc.unicamp.br,guarana.{org,com}} aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
** I may forward mail about projects to mailing lists; please use them

possible bug

[Manush Dodunekov]

The code below compiles fine with no flags, but fails to compile with a
parse error on the line containing "iterator i;" when compiling with
-pedantic.

This happens with both egcs-1.1.2 (as shipped on RH6.0/i386) and latest
snapshot (19990718).

Is the code wrong in some way, or is this a bug?

-----------------------
#include <vector>

template <class T>
class X : public vector<T> {
public:
	void f() {
		iterator i;
	}
};

int main(void) 
{
	return 0;
}
---------------------------

thankful for any suggestions,
Manush

Re: possible bug

[Manush Dodunekov]

On 26 Jul 1999, Alexandre Oliva wrote:

> On Jul 25, 1999, Manush Dodunekov <manush@litecom.se> wrote:
> 
> > The code below compiles fine with no flags, but fails to compile with a
> > parse error on the line containing "iterator i;" when compiling with
> > -pedantic.
> 
> That's correct.  Members of template-dependent base classes must be
> explicitly qualified.  Without -pedantic, gcc accepts it as an
> extension.

However, using 
	vector<T>::iterator i;
doesn't help the compile; It only compiles when using 
	typename vector<T>::iterator i;
What does the standard say on this? Shouldn't the first case be enough?

regards,
Manush

Re: possible bug

[Alexandre Oliva]

On Jul 27, 1999, Manush Dodunekov <manush@litecom.se> wrote:

> 	vector<T>::iterator i;
> doesn't help the compile; It only compiles when using 
> 	typename vector<T>::iterator i;

> What does the standard say on this?

`typename' is required before template-dependent qualified type
names.

> Shouldn't the first case be enough?

It'll probably work without -pedantic, but it is a gcc extension,
don't count on it.

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
oliva@{dcc.unicamp.br,guarana.{org,com}} aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
** I may forward mail about projects to mailing lists; please use them

Re: possible bug

[Manush Dodunekov]

On 26 Jul 1999, Alexandre Oliva wrote:

> On Jul 25, 1999, Manush Dodunekov <manush@litecom.se> wrote:
> 
> > The code below compiles fine with no flags, but fails to compile with a
> > parse error on the line containing "iterator i;" when compiling with
> > -pedantic.
> 
> That's correct.  Members of template-dependent base classes must be
> explicitly qualified.  Without -pedantic, gcc accepts it as an
> extension.

However, using 
	vector<T>::iterator i;
doesn't help the compile; It only compiles when using 
	typename vector<T>::iterator i;
What does the standard say on this? Shouldn't the first case be enough?

regards,
Manush

Re: possible bug

[Alexandre Oliva]

On Jul 25, 1999, Manush Dodunekov <manush@litecom.se> wrote:

> The code below compiles fine with no flags, but fails to compile with a
> parse error on the line containing "iterator i;" when compiling with
> -pedantic.

That's correct.  Members of template-dependent base classes must be
explicitly qualified.  Without -pedantic, gcc accepts it as an
extension.

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
oliva@{dcc.unicamp.br,guarana.{org,com}} aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
** I may forward mail about projects to mailing lists; please use them

possible bug

[Manush Dodunekov]

The code below compiles fine with no flags, but fails to compile with a
parse error on the line containing "iterator i;" when compiling with
-pedantic.

This happens with both egcs-1.1.2 (as shipped on RH6.0/i386) and latest
snapshot (19990718).

Is the code wrong in some way, or is this a bug?

-----------------------
#include <vector>

template <class T>
class X : public vector<T> {
public:
	void f() {
		iterator i;
	}
};

int main(void) 
{
	return 0;
}
---------------------------

thankful for any suggestions,
Manush

Possible Bug

[Mike Sullivan]

I have tried to compile some fortran code with the binary 
snapshot of pgcc-1.0, If I use the -ggdb flag I get 

Compiling sysdepen.F ...
g77: Internal compiler error: program f771 got fatal signal 6
make: *** [objl/sysdepen.o] Error 1


	I am running Linux on a P-PRO

						Mike Suliivan