Need someone to look at a regression

Need someone to look at a regression

[Jeffrey A Law]

gcc.dg/980626-1.c is consistently showing up as a regression when
comparing the egcs-1.1 against egcs-1.0.3a and gcc-2.8.1.

This is a test for a bogus warning.

Can someone look into why egcs-1.1 is behaving differently for this
test?  Compile with -Wimplicit-int.

gcc-2.8.1 and egcs-1.0.3 will probably not issue any warnings (which
is the correct behavior IMHO).  egcs-1.1 will issue a bogus warning.

Thanks!


int main()
{
  typedef SFtype __attribute__ ((mode (SF)));
  typedef DFtype __attribute__ ((mode (DF)));
  typedef HItype __attribute__ ((mode (HI)));
  typedef SItype __attribute__ ((mode (SI)));
  typedef DItype __attribute__ ((mode (DI)));
  typedef UHItype __attribute__ ((mode (HI)));
  typedef USItype __attribute__ ((mode (SI)));
  typedef UDItype __attribute__ ((mode (DI)));
  return 0;
}

Re: Need someone to look at a regression

[Andreas Schwab]

Jeffrey A Law <law@cygnus.com> writes:

|> gcc.dg/980626-1.c is consistently showing up as a regression when
|> comparing the egcs-1.1 against egcs-1.0.3a and gcc-2.8.1.
|> 
|> This is a test for a bogus warning.
|> 
|> Can someone look into why egcs-1.1 is behaving differently for this
|> test?  Compile with -Wimplicit-int.
|> 
|> gcc-2.8.1 and egcs-1.0.3 will probably not issue any warnings (which
|> is the correct behavior IMHO).  egcs-1.1 will issue a bogus warning.
|> 
|> Thanks!
|> 
|> 
|> int main()
|> {
|>   typedef SFtype __attribute__ ((mode (SF)));
|>   typedef DFtype __attribute__ ((mode (DF)));
|>   typedef HItype __attribute__ ((mode (HI)));
|>   typedef SItype __attribute__ ((mode (SI)));
|>   typedef DItype __attribute__ ((mode (DI)));
|>   typedef UHItype __attribute__ ((mode (HI)));
|>   typedef USItype __attribute__ ((mode (SI)));
|>   typedef UDItype __attribute__ ((mode (DI)));
|>   return 0;
|> }

I can't check it out currently, but egcs-1.1 is correct if it warns about
implicit int.  Use `typedef int SFtype __attribute__ ((mode (SF)))'
instead.

Re: Need someone to look at a regression

[Jeffrey A Law]

  In message < vyz1zqjhmgj.fsf@issan.informatik.uni-dortmund.de >you write:
  > I can't check it out currently, but egcs-1.1 is correct if it warns about
  > implicit int.  Use `typedef int SFtype __attribute__ ((mode (SF)))'
  > instead.
I think the warning is wrong.  Given:

   typedef SFtype __attribute__ ((mode (SF)));

We have an explicit type (SFmode), why in the hell would we ever
want/need typedef int ....?

eff

Re: Need someone to look at a regression

[Carlo Wood]

Hmm, I used to get a warning for this, because the
test is always true (unsigned int is always >= 0):

-------------------
#include <stdio.h>

int main(int argc, char **argv)
{
  unsigned int j = argc;

  if (j >= 0)
    printf("%u > 0\n", j);
  else
    printf("%u < 0\n", j);

  return 0;
}
-------------------

~/tmp>gcc -Wall -pedantic -O2 foo.c
~/tmp>


The following also worries me a bit:

-------------------
#include <stdio.h>

int main()
{
  unsigned int j = -1;

  if (j == -1)
    printf("%u == -1\n", j);
  else
    printf("%u != -1\n", j);

  return 0;
}
-------------------

~/tmp>gcc -Wall -pedantic foo.c
~/tmp>a.out
4294967295 == -1
~/tmp>gcc -Wall -pedantic -O6 foo.c
~/tmp>a.out
4294967295 == -1

No warnings?  I am not sure if that is a bug or a feature, but
since it is known that (unsigned int) != -1, it just seemed weird
that the optimisation chooses to make j == -1 without a warning.

-- 
 Carlo Wood  <carlo@runaway.xs4all.nl>

Re: Need someone to look at a regression

[Ulrich Drepper]

law@cygnus.com (Jeffrey A Law) writes:

>    typedef SFtype __attribute__ ((mode (SF)));
> 
> We have an explicit type (SFmode), why in the hell would we ever
> want/need typedef int ....?

Isn't it that the __attribute__ stuff is, well, an attribute and it
should be possible to drop it?  Then yu would get

	typedef SFtype;

which clearly is wrong.  You simply cannot leave out the base type.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: Need someone to look at a regression

[Jeffrey A Law]

  In message < 199808141440.QAA29307@jolan.ppro >you write:
  > Hmm, I used to get a warning for this, because the
  > test is always true (unsigned int is always >= 0):
  > 
  > -------------------
  > #include <stdio.h>
  > 
  > int main(int argc, char **argv)
  > {
  >   unsigned int j = argc;
  > 
  >   if (j >= 0)
  >     printf("%u > 0\n", j);
  >   else
  >     printf("%u < 0\n", j);
  > 
  >   return 0;
  > }
Add "-W" and you'll get the desired warning.

  > No warnings?  I am not sure if that is a bug or a feature, but
  > since it is known that (unsigned int) != -1, it just seemed weird
  > that the optimisation chooses to make j == -1 without a warning.
It is valid to compare an unsigned value against -1.

jeff

Re: Need someone to look at a regression

[Jeffrey A Law]

  In message < r2ww8bx9uq.fsf@happy.cygnus.com >you write:
  > law@cygnus.com (Jeffrey A Law) writes:
  > 
  > >    typedef SFtype __attribute__ ((mode (SF)));
  > > 
  > > We have an explicit type (SFmode), why in the hell would we ever
  > > want/need typedef int ....?
  > 
  > Isn't it that the __attribute__ stuff is, well, an attribute and it
  > should be possible to drop it?  Then yu would get
  > 
  > 	typedef SFtype;
  > 
  > which clearly is wrong.  You simply cannot leave out the base type.
I don't see that the "int" is a base type in this case.  How can you
have an integer base type for a floating point mode?

This is one of those areas where someone familiar with language design
should have been involved in specifying exactly what is supposed to
happen.

My simplistic viewpoint is 

typedef int SFtype __attribute__ ((mode (SF)));


Is bogus -- the type is actually specified by the attribute and the
"int" is neither used nor wanted.

Frankly, I don't really care about this problem all that much, we're
talking about a possible bogus warning.  The only reason this came up
at all is because libgcc2.c uses attributes like that and egcs
complained about the implicit int.  IMHO a case of warning elimination
going too far.

I'm more than willing to go with whatever group decision we come up
with on this one.  If we decide the int is needed, then the testcase
is bogus.  If the int is not needed, then the testcase is valid and
we've got a bug in the compiler (since it shouldn't have given the
warning).

jeff

Re: Need someone to look at a regression

[Carlo Wood]

| I'm more than willing to go with whatever group decision we come up
| with on this one.  If we decide the int is needed, then the testcase
| is bogus.  If the int is not needed, then the testcase is valid and
| we've got a bug in the compiler (since it shouldn't have given the
| warning).
| 
| jeff

I think there are two possibilities:

1) The use of a mode() makes this code only ever make sense when
   compiled with gcc.

Then suppression of the warning would be the best because when
the warning is not suppressed people will add 'int' and then
no warning will occur when compiling the code with another
compiler which uses:
#define __attribute__

2) It *does* make sense to compile code like this with other
   compilers (ie, using "#define __attribute__" somewhere).

In that case you want a 'backup' type to be added that will
be used when the __attribute__ is #defined away.
We need a NEW warning then however, when the overridden
type doesn't match the mode() somehow.  I am not sure if
that is possible since I don't know the mode() types :/

But, for example, I can imagine that we'd like to have
a warning when with

  typedef int XXtype __attribute__ ((mode (XX)));

sizeof(XXtype) != sizeof(int).

-- 
 Carlo Wood  <carlo@runaway.xs4all.nl>

Re: Need someone to look at a regression

[Jeffrey A Law]

  In message < 199808161324.PAA10943@jolan.ppro >you write:
  > 1) The use of a mode() makes this code only ever make sense when
  >    compiled with gcc.
The whole construct only makes sense when compiled with gcc.  It should
(IMHO) give an error instead of trying to do the right thing if you're
not compiling with gcc.

Why?  If you try to "fake it", odds are you're not going to get it
right consistently and you'll end up silently generating incorrect
code.  IMHO, it's better to get a compile time error in this case.


  > Then suppression of the warning would be the best because when
  > the warning is not suppressed people will add 'int' and then
  > no warning will occur when compiling the code with another
  > compiler which uses:
  > #define __attribute__
Right.

  > 2) It *does* make sense to compile code like this with other
  >    compilers (ie, using "#define __attribute__" somewhere).
  > 
  > In that case you want a 'backup' type to be added that will
  > be used when the __attribute__ is #defined away.
  > We need a NEW warning then however, when the overridden
  > type doesn't match the mode() somehow.  I am not sure if
  > that is possible since I don't know the mode() types :/
Many of the attributes make no sense when building with other compilers;
I think the mode attribute is one of them.

I don't see how to get the additional warning since the size  of
the C data types is implementation specific, whereas the size of
most modes is fixed.


jeff

Re: Need someone to look at a regression

[Jeffrey A Law]

  In message < Pine.LNX.3.95.980817115257.25384E-100000@plum.dwd.interkom.pl >you write:
  > 
  > Definitely "int" and "__attribute__ ((mode (SF)))" on the same typedef
  > clash.
  > 
  > However, "float" and "__attribute__ ((mode (SF)))" certainly do not.
Yes, float and SFmode clash since there is no guarantee that a float
has the same size as SFmode.

  > Now, what do I want? An integer? A pointer? Or perhaps a 4-byte
  > structure? GCC will use SImode for all of them on my machine.
Right.  Once you get past the front-end, types are not preserved.  You
just have mode and size.  And  this is precisely what the attributes
are supposed to provide.

jeff

Re: Need someone to look at a regression

[Jason Merrill]

>>>>> Jeffrey A Law <law@cygnus.com> writes:

 >   In message < r2ww8bx9uq.fsf@happy.cygnus.com >you write:
 >> law@cygnus.com (Jeffrey A Law) writes:
 >> 
 >> >    typedef SFtype __attribute__ ((mode (SF)));
 >> > 
 >> > We have an explicit type (SFmode), why in the hell would we ever
 >> > want/need typedef int ....?
 >> 
 >> Isn't it that the __attribute__ stuff is, well, an attribute and it
 >> should be possible to drop it?  Then yu would get
 >> 
 >> 	typedef SFtype;
 >> 
 >> which clearly is wrong.  You simply cannot leave out the base type.

 > I don't see that the "int" is a base type in this case.  How can you
 > have an integer base type for a floating point mode?

In C,

  typedef SFtype;

is equivalent to

  typedef int SFtype;

by the implicit int rule.  In C++ and C9X, there is no such rule, so the
above is ill-formed.

Jason

Re: Need someone to look at a regression

[Kamil Iskra]

On Sat, 15 Aug 1998, Jeffrey A Law wrote:

> My simplistic viewpoint is 
> 
> typedef int SFtype __attribute__ ((mode (SF)));
> 
> 
> Is bogus -- the type is actually specified by the attribute and the
> "int" is neither used nor wanted.

Definitely "int" and "__attribute__ ((mode (SF)))" on the same typedef
clash.

However, "float" and "__attribute__ ((mode (SF)))" certainly do not.

IMHO, saying that:

typedef SFtype __attribute__ ((mode (SF)));

gives all the type information it needs is wrong. Sure, in case of
floating type there is no much else you can do with it apart from storing 
a floating pointer number, but compare it with:

typedef SItype __attribute__ ((mode (SI)));

Now, what do I want? An integer? A pointer? Or perhaps a 4-byte
structure? GCC will use SImode for all of them on my machine.

Modes provide only a subset of information than types do. Just compare the
mode-based alias analysis vs. the type-based one.

Therefore, I think that GCC should warn when the mode has been specified,
but the type has not. Such a new type is simply incomplete.

/ Kamil Iskra    AmigaOS  Linux/i386  Linux/m68k               \
| GeekGadgets GCC maintainer   UNIX system administrator       |
| iskra@student.uci.agh.edu.pl  kiskra@ernie.icslab.agh.edu.pl |
\ kamil@dwd.interkom.pl   http://student.uci.agh.edu.pl/~iskra /

Re: Need someone to look at a regression

[Richard Earnshaw]

> >>>>> Jeffrey A Law <law@cygnus.com> writes:
> 
>  >   In message < r2ww8bx9uq.fsf@happy.cygnus.com >you write:
>  >> law@cygnus.com (Jeffrey A Law) writes:
>  >> 
>  >> >    typedef SFtype __attribute__ ((mode (SF)));
>  >> > 
>  >> > We have an explicit type (SFmode), why in the hell would we ever
>  >> > want/need typedef int ....?
>  >> 
>  >> Isn't it that the __attribute__ stuff is, well, an attribute and it
>  >> should be possible to drop it?  Then yu would get
>  >> 
>  >> 	typedef SFtype;
>  >> 
>  >> which clearly is wrong.  You simply cannot leave out the base type.
> 
>  > I don't see that the "int" is a base type in this case.  How can you
>  > have an integer base type for a floating point mode?
> 
> In C,
> 
>   typedef SFtype;
> 
> is equivalent to
> 
>   typedef int SFtype;
> 
> by the implicit int rule.  In C++ and C9X, there is no such rule, so the
> above is ill-formed.
> 

It's a pity that the code below doesn't work.

typedef struct 
{
  unsigned x, y;
} foo __attribute__((mode (DF)));

foo bar()
{
  foo x;
  x.x = 0;
  x.y = 0;
  return x;
}

test.c: In function `bar':
test.c:9: request for member `x' in something not a structure or union
test.c:10: request for member `y' in something not a structure or union

This would be an extremely useful way of breaking down a floating point 
number into its component bit-fields, without having to mess around with a 
union.  It would certainly solve a problem I have at the moment, 
especially if the struct were passed to and from calls in the same way as 
a DFmode type.

Re: Need someone to look at a regression

[Joern Rennecke]

> It's a pity that the code below doesn't work.
> 
> typedef struct 
> {
>   unsigned x, y;
> } foo __attribute__((mode (DF)));
> 
> foo bar()
> {
>   foo x;
>   x.x = 0;
>   x.y = 0;
>   return x;
> }
> 
> test.c: In function `bar':
> test.c:9: request for member `x' in something not a structure or union
> test.c:10: request for member `y' in something not a structure or union
> 
> This would be an extremely useful way of breaking down a floating point 
> number into its component bit-fields, without having to mess around with a 
> union.  It would certainly solve a problem I have at the moment, 
> especially if the struct were passed to and from calls in the same way as 
> a DFmode type.

You can use the 'transparent union' attribute for that.  The floating
point member of the union has to be the first one.

Re: Need someone to look at a regression

[Jeffrey A Law]

  In message < 199808181702.SAA14402@phal.cygnus.co.uk >you write:
  > You can use the 'transparent union' attribute for that.  The floating
  > point member of the union has to be the first one.
I would not encourage this.  

"transparent unions" are a bad gcc extension.

jeff

Re: Need someone to look at a regression

[Ken Raeburn]

Jeffrey A Law <law@cygnus.com> writes:

>   In message < Pine.LNX.3.95.980817115257.25384E-100000@plum.dwd.interkom.pl >you write:
>   > 
>   > Definitely "int" and "__attribute__ ((mode (SF)))" on the same typedef
>   > clash.
>   > 
>   > However, "float" and "__attribute__ ((mode (SF)))" certainly do not.
> Yes, float and SFmode clash since there is no guarantee that a float
> has the same size as SFmode.

I'm inclined to think of it as the type sort of describing the general
class of types to be used (FP, int, pointer, complex types), with the
mode specifying exactly how big it is.  (Though how you'd use pointers
of strange sizes, I'm not sure.)  Or, to look at it another way, the
attributes modify the type described in some ways (size, alignment,
internal padding), and produce an error if the modification is invalid
(requires different class of base type, making pointer too small).

But that's very different from the implementation.  The mode-attribute
implementation is more like a __typeof__ kind of thing, which given
some input, produces a type that you use as is.  You don't specify the
mode for *your* type; you specify a mode and signedness, and the
compiler hands you the type it has decided you will use.  IMHO such a
thing should fit in syntactically like __typeof__ does, not like an
attribute.  Maybe "typedef __type_for_mode__ (SF) foo;"...


>   > Now, what do I want? An integer? A pointer? Or perhaps a 4-byte
>   > structure? GCC will use SImode for all of them on my machine.
> Right.  Once you get past the front-end, types are not preserved.  You
> just have mode and size.  And  this is precisely what the attributes
> are supposed to provide.

The mode does not indicate signedness.  While this is not an issue for
floating point types (you can specify it, but it's ignored), it does
indicate that the mode alone is not always sufficient.

Here's a random thought: What if someone writes support for
fixed-point variables and arithmetic?  At least for machines without
special support, I'd expect the implementation to use the usual
integer modes, with some special front-end type info indicating that
some of the HLL arithmetic ops need to be expanded differently.  In
that case, I could imagine using

	typedef __fixed(1) int halfstep __attribute__((mode (DI)));

where again the type info would be required to give the correct
semantics.


I'll also note that qualifiers appear to get discarded when the mode
attribute is used.  So
	typedef const int foo __attribute__((mode(SI)));
results in "foo" type variables going into read-write storage, when
they go into read-only storage when the attribute is omitted.  And
	typedef const __complex__ unsigned long long foo
					__attribute__((mode(SF)));
is silently made equivalent to
	typedef float foo;
This too is contrary to how I'd expect such an attribute to work, if I
hadn't looked at the implementation.  (Actually, this result seems
pretty ridiculous to me.)


Also, a minor issue, type_for_mode seems completely unaware of any
complex modes.  And it has support for char* and int* having different
modes, though I don't see how that can arise.

Re: Need someone to look at a regression

[Jeffrey A Law]

  In message < tx1d89wz9wp.fsf@cygnus.com >you write:
  > Jeffrey A Law <law@cygnus.com> writes:
  > 
  > >   In message <Pine.LNX.3.95.980817115257.25384E-100000@plum.dwd.interkom.
  > pl>you write:
  > >   > 
  > >   > Definitely "int" and "__attribute__ ((mode (SF)))" on the same typede
  > f
  > >   > clash.
  > >   > 
  > >   > However, "float" and "__attribute__ ((mode (SF)))" certainly do not.
  > > Yes, float and SFmode clash since there is no guarantee that a float
  > > has the same size as SFmode.
  > 
  > I'm inclined to think of it as the type sort of describing the general
  > class of types to be used (FP, int, pointer, complex types), with the
  > mode specifying exactly how big it is.
So, after all the other issues you raised, what do you think we should
do in this specific case?

ie, do we keep the warning or is the warning bogus.  That's what I
really want opinions on right now.

jeff