Wrong warning? ISO C restricts enumerator values to range of ‘int’

[Felipe Contreras]

Hi,

This is what ISO C says:

Each enumerated type shall be compatible with char, a signed integer
type, or an unsigned integer type. The choice of type is
implementation-defined,110) but shall be capable of representing the
values of all the members of the enumeration.

110) An implementation may delay the choice of which integer type
until all enumeration constants have been seen.


The interesting part here is "shall be capable of representing the
values of all the members of the enumeration", sometimes only an
"unsigned int" can do that.

So, shouldn't gcc allow this without warnings then?

typedef enum OMX_ERRORTYPE
{
  OMX_ErrorNone = 0,
  OMX_ErrorInsufficientResources = 0x80001000
} OMX_ERRORTYPE;

Best regards.

-- 
Felipe Contreras

Re: Wrong warning? ISO C restricts enumerator values to range of ‘int’

[Felipe Contreras]

On Feb 6, 2008 1:18 PM, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote:
> On 06/02/2008, Felipe Contreras <[EMAIL PROTECTED]> wrote:
> >
> > So, shouldn't gcc allow this without warnings then?
> >
> > typedef enum OMX_ERRORTYPE
> > {
> >   OMX_ErrorNone = 0,
> >   OMX_ErrorInsufficientResources = 0x80001000
> > } OMX_ERRORTYPE;
> >
>
> And what warning do you get and with which version of GCC you get it?
>
> [EMAIL PROTECTED]:~$ cat felipe.c
> typedef enum OMX_ERRORTYPE
> {
>  OMX_ErrorNone = 0,
>  OMX_ErrorInsufficientResources = 0x80001000
> } OMX_ERRORTYPE;
> [EMAIL PROTECTED]:~$ ~/personal/gcc/objdir/gcc/cc1 -Wall -Wextra
> -Wconversion ~/felipe.c
> [EMAIL PROTECTED]:~$ ~/personal/gcc/objdir/gcc/cc1 --version
> GNU C (GCC) version 4.3.0 20080122 (experimental) (x86_64-unknown-linux-gnu)
> compiled by GNU C version 4.3.0 20080122 (experimental), GMP
> version 4.2.2, MPFR version 2.3.0.
> GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

0x80001000u and 0x80001000UL didn't work:

gcc test.c -o test -pedantic
test.c:7: warning: ISO C restricts enumerator values to range of 'int'

This is with:
gcc (GCC) 4.1.2 20070925 (Red Hat 4.1.2-33)

-- 
Felipe Contreras

Re: Wrong warning? ISO C restricts enumerator values to range of ‘int’

[Manuel López-Ibáñez]

On 06/02/2008, Dave Korn <[EMAIL PROTECTED]> wrote:
> On 06 February 2008 11:05, Felipe Contreras wrote:
>
> > So, shouldn't gcc allow this without warnings then?
> >
> > typedef enum OMX_ERRORTYPE
> > {
> >   OMX_ErrorNone = 0,
> >   OMX_ErrorInsufficientResources = 0x80001000
> > } OMX_ERRORTYPE;
> >

OK. I see, you used "-pedantic" and the warning is:
felipe.c:5: warning: ISO C restricts enumerator values to range of 'int'

which is generated by c-decl.c (build_enumerator):

  if (pedantic && !int_fits_type_p (value, integer_type_node))
{
  pedwarn ("ISO C restricts enumerator values to range of %");
  /* XXX This causes -pedantic to change the meaning of the program.
 Remove?  -zw 2004-03-15  */
  value = convert (integer_type_node, value);
}

Cheers,

Manuel.

Re: Wrong warning? ISO C restricts enumerator values to range of ‘int’

[Manuel López-Ibáñez]

On 06/02/2008, Felipe Contreras <[EMAIL PROTECTED]> wrote:
>
> So, shouldn't gcc allow this without warnings then?
>
> typedef enum OMX_ERRORTYPE
> {
>   OMX_ErrorNone = 0,
>   OMX_ErrorInsufficientResources = 0x80001000
> } OMX_ERRORTYPE;
>

And what warning do you get and with which version of GCC you get it?

[EMAIL PROTECTED]:~$ cat felipe.c
typedef enum OMX_ERRORTYPE
{
 OMX_ErrorNone = 0,
 OMX_ErrorInsufficientResources = 0x80001000
} OMX_ERRORTYPE;
[EMAIL PROTECTED]:~$ ~/personal/gcc/objdir/gcc/cc1 -Wall -Wextra
-Wconversion ~/felipe.c
[EMAIL PROTECTED]:~$ ~/personal/gcc/objdir/gcc/cc1 --version
GNU C (GCC) version 4.3.0 20080122 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.3.0 20080122 (experimental), GMP
version 4.2.2, MPFR version 2.3.0.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096


Cheers,

Manuel.

RE: Wrong warning? ISO C restricts enumerator values to range of ‘int’

[Dave Korn]

On 06 February 2008 11:05, Felipe Contreras wrote:

> So, shouldn't gcc allow this without warnings then?
> 
> typedef enum OMX_ERRORTYPE
> {
>   OMX_ErrorNone = 0,
>   OMX_ErrorInsufficientResources = 0x80001000
> } OMX_ERRORTYPE;
> 
> Best regards.

  Does this work any better?

 typedef enum OMX_ERRORTYPE
 {
   OMX_ErrorNone = 0,
   OMX_ErrorInsufficientResources = 0x80001000u
 } OMX_ERRORTYPE;


cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: Wrong warning? ISO C restricts enumerator values to range of ‘int’

[Manuel López-Ibáñez]

On 06/02/2008, Felipe Contreras <[EMAIL PROTECTED]> wrote:
> On Feb 6, 2008 1:18 PM, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote:
> > On 06/02/2008, Felipe Contreras <[EMAIL PROTECTED]> wrote:
> > >
> > > So, shouldn't gcc allow this without warnings then?
> > >
> > > typedef enum OMX_ERRORTYPE
> > > {
> > >   OMX_ErrorNone = 0,
> > >   OMX_ErrorInsufficientResources = 0x80001000
> > > } OMX_ERRORTYPE;
> > >
> >

It seems that this is a correct warning.

"Even though the underlying type of an enum is unspecified, the type
of enumeration constants is explicitly defined as int (6.4.4.3/2 in
the C99 Standard)."

from:  http://gcc.gnu.org/ml/gcc-patches/2000-07/msg00993.html

Nonetheless, the comment from Zack is right, so shouldn't we make the
conversion independently of the warning ?


Cheers,

Manuel.

output of "cc1 --version"

[Vincent Lefevre]

I have here:

vin:~> /usr/lib/gcc/x86_64-linux-gnu/4.3/cc1 --version
GNU C (Debian 4.3-20080202-1) version 4.3.0 20080202 (experimental) [trunk 
revision 132072] (x86_64-linux-gnu)
compiled by GNU C version 4.3.0 20080202 (experimental) [trunk revision 
132072], GMP version 4.2.2, MPFR version 2.3.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072

Shouldn't it give more information about the GMP and MPFR versions,
such as the library versions used at runtime?

FYI, I use the following code (or similar) in my programs:

#include 
#include 
#include 

int main (void)
{
  printf ("GMP .  Library: %-12s  Header: %d.%d.%d\n",
  gmp_version, __GNU_MP_VERSION, __GNU_MP_VERSION_MINOR,
  __GNU_MP_VERSION_PATCHLEVEL);
  printf ("MPFR   Library: %-12s  Header: %s (based on %d.%d.%d)\n",
  mpfr_get_version (), MPFR_VERSION_STRING, MPFR_VERSION_MAJOR,
  MPFR_VERSION_MINOR, MPFR_VERSION_PATCHLEVEL);
#if MPFR_VERSION >= MPFR_VERSION_NUM(2,3,0)
  printf ("MPFR patches: %s\n", mpfr_get_patches ());
#endif
  return 0;
}

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: Wrong warning? ISO C restricts enumerator values to range of ‘int’

[Andreas Schwab]

"Felipe Contreras" <[EMAIL PROTECTED]> writes:

> This is what ISO C says:
>
> Each enumerated type shall be compatible with char, a signed integer
> type, or an unsigned integer type. The choice of type is
> implementation-defined,110) but shall be capable of representing the
> values of all the members of the enumeration.

The standard also says:

  The expression that defines the value of an enumeration constant shall
  be an integer constant expression that has a value representable as an
  int.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: output of "cc1 --version"

[Manuel López-Ibáñez]

On 06/02/2008, Vincent Lefevre <[EMAIL PROTECTED]> wrote:
> I have here:
>
> Shouldn't it give more information about the GMP and MPFR versions,
> such as the library versions used at runtime?

Those are the library versions used at runtime, aren't they?

> FYI, I use the following code (or similar) in my programs:

See gcc/toplev.c (print_version) for the relevant code in GCC. (It
gives a warning when there is a mismatch between runtime and header
versions, otherwise it just prints the latter).

Cheers,

Manuel.

Re: Wrong warning? ISO C restricts enumerator values to range of ‘int’

[Felipe Contreras]

On Feb 6, 2008 2:47 PM, Andreas Schwab <[EMAIL PROTECTED]> wrote:
> "Felipe Contreras" <[EMAIL PROTECTED]> writes:
>
> > This is what ISO C says:
> >
> > Each enumerated type shall be compatible with char, a signed integer
> > type, or an unsigned integer type. The choice of type is
> > implementation-defined,110) but shall be capable of representing the
> > values of all the members of the enumeration.
>
> The standard also says:
>
>   The expression that defines the value of an enumeration constant shall
>   be an integer constant expression that has a value representable as an
>   int.

Ahh, I see. So even if the type of the enum is specified by the
compiler as "unsigned int"; the value assigned to it can only be an
"int".

-- 
Felipe Contreras

Re: [RFC] Change (flatten) representation of memory references

[Richard Guenther]

On Mon, 4 Feb 2008, Richard Guenther wrote:

> Following the old discussions at
> 
>   http://gcc.gnu.org/ml/gcc/2007-04/msg00096.html


With starting to prototype the proposed MEM_REF scheme I noticed
a few things that I'd like to add.  First let me summarize the
idea again.  The idea is to unify all memory reference trees into
two, MEM_REF and INDIRECT_MEM_REF with the following main goals:

 - get rid of the recursiveness of the current scheme (a.b[i].c.d.e[j].f)
   to simplify and speed up the operand scanner and the to be implemented
   tree level alias oracle

 - make TBAA easier and less fragile by annotating memory accesses with
   the alias set involved.  This allows for example the vectorizer to
   use the original alias sets, even when now vector types are used.
   (The idea is that the alias sets are encoded in the source program;
we would extract them early and annotate the memory references as
part of the lowering process)

So we will have

  MEM_REF < base, byte offset, alias set nr. >
  INDIRECT_MEM_REF < base_ptr, byte offset, alias set nr. >

where those two differ only in that the base object of MEM_REF need not
be addressable (the *base_ptr object in INDIRECT_MEM_REF obviously is,
as we have an address pointing to it).

Note also the symmetry to

  POINTER_PLUS < base, offset >

which allows (modulo type system issues) to directly combine address
computations with MEM_REFs and to simply transform

  ADDR_EXPR < INDIRECT_MEM_REF < base, offset, ... > >
-> POINTER_PLUS < base, offset >

  ADDR_EXPR < MEM_REF < base, offset, ... > >
-> POINTER_PLUS < ADDR_EXPR < base >, offset >

Given that at the moment we allow invariant addresses to pass the
is_gimple_min_invariant test and that we allow &a.b as
is_gimple_formal_tmp_rhs, IMHO invariant POINTER_PLUS exprs like
&a + CST should be allowed as is_gimple_min_invariant as well, as
should non-invariant &a + o be allowed as is_gimple_formal_tmp_rhs.
So,

  foo (&a.c)

could become

  foo (&a + 4)

without an extra temporary, as well as

  tmp = &a[i];

which would become

  tmp = &a + i;


During prototyping I noticed a few things.  One is that we use
several reference trees on registers, like IMAGPART_EXPR, REALPART_EXPR
and BIT_FIELD_REF -- we need to avoid lowering references to such
registers to MEM_REF.

Another thing is bit-field accesses, like for example in

  struct { int pad : 3; int bit : 1; } x;
  x.bit = 1;
  tmp = x.bit;

which cannot be encoded with MEM_REF directly as that doesn't allow
specifying the offset in bit granularity (and IMHO it doesn't make
sense to do so).  I am playing with lowering the above to

  wtmp = MEM_REF(int) < x, 0, ... >;
  BIT_FIELD_REF < wtmp, 3, 1 > = 1;
  MEM_REF(int) < x, 0, ... > = wtmp;
  wtmp = MEM_REF(int) < x, 0, ... >;
  tmp = BIT_FIELD_REF < wtmp, 3, 1 >;

using the bitfield mode to access the whole bitfield and extract/set
the parts using BIT_FIELD_REF.  IMHO this is better than lowering to
shift and mask operations.  Note that one goal is to do complete lowering,
not keeping some operations unlowered (which would of course be also
possible here).  I'm not sure what to do about bit-aligned TImode fields
for example, or other things that appearantly can be done with Ada
(which allows bit-packing).

Another thing is (late) diagnostics, which will now print MEM_REF
expressions if they previously printed COMPONTENT_REFs or ARRAY_REFs,
but if necessary those can be re-generated.

One more thing is that with the TBAA alias set involved encoded in the
memory reference we in principle no longer need to be careful about type
correctness of pointers, but should be able to propagate them at will,
reducing the number of conversions required (all those conversions of
pointers are value preserving anyway, the current limitations are somewhat
artificial).  All what matters is the access type and the alias set
involved, which for example lets us encode VIEW_CONVERT_EXPR < type, base >
as

  MEM_REF(type) < base, 0, 0 >

simply using alias set zero for the read (the type of the MEM_REF also
specifies the access size).  A related thing is alignment of an access,
which is in principle encoded in the information we have about the
base object.  Not so in the case of INDIRECT_MEM_REF, if we start being
ignorant about its base_ptr type.  So I reserved the option to encode
alignment information alongside the alias set number in the MEM_REF
itself (like we do on RTL).  This also eases extraction of alignment
information in case the offset is non-constant, but the alignment is
nevertheless known (you can of course _not_ simply use the access type
to extract alignment information).


All of the above ignored all the fancy IDX idea with retaining
(multi-dimensional) array access information - I have not yet come
to the point prototyping that.

To shortly summarize this idea:  introduce a multiply-add expression
that we will not commutate, thus can keep extra semantics of the
positional arguments:  IDX < 

Fwd: _Unwind_Resume on the stack

[Pavan R]

Can I get some help on this.


-- Forwarded message --
From: Pavan R <[EMAIL PROTECTED]>
Date: Jan 29, 2008 5:27 PM
Subject: Fwd: _Unwind_Resume on the stack
To: gcc@gcc.gnu.org


No, We have compiled our application on RHEL 3 with libgcc-3.2.3-34.



On Jan 29, 2008 3:44 PM, Andrew Haley <[EMAIL PROTECTED]> wrote:
>
> Pavan R wrote:
> > Hi,
> >
> >  We find our application dumps core on Suse 10 SP1 that has
> > libgcc-4.1.2_20070115-0.11 shipped,  with the top of the stack as :
> >
> > Program terminated with signal 11, Segmentation fault.
> > #0 0xf7aca09c in memcpy () from /lib/libc.so.6
> > (gdb) bt
> > #0 0xf7aca09c in memcpy () from /lib/libc.so.6
> > #1 0x08050a84 in uw_install_context_1 ()
> > #2 0x08050efc in _Unwind_Resume ()
> >
> > The findings are that, by having /lib/libgcc_s.so.1 replaced with the
> > version : libgcc42-4.2.1_20070724-17 we
> > got around with the issue.
> >
> > Can anyone plz point us to any related bugs fixed in the mentioned
> > libgcc version related to _Unwind_Resume.
>
> Did you compile your application on the same machine on which it was
> run?
>
> Andrew.
>

Re: output of "cc1 --version"

[Vincent Lefevre]

On 2008-02-06 13:57:06 +0100, Manuel López-Ibáñez wrote:
> See gcc/toplev.c (print_version) for the relevant code in GCC. (It
> gives a warning when there is a mismatch between runtime and header
> versions, otherwise it just prints the latter).

OK, I didn't see that there could be a warning. In fact, the cc1
binary that comes from the Debian package uses the MPFR library
I've compiled (due to my LD_LIBRARY_PATH, though I set it for
another purpose), but it happens to be the same version (however,
perhaps not with the same configure options).

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

RE: Wrong warning? ISO C restricts enumerator values to range of ‘int’

[Dave Korn]

On 06 February 2008 13:01, Felipe Contreras wrote:

> On Feb 6, 2008 2:47 PM, Andreas Schwab <[EMAIL PROTECTED]> wrote:
>> "Felipe Contreras" <[EMAIL PROTECTED]> writes:
>> 
>>> This is what ISO C says:
>>> 
>>> Each enumerated type shall be compatible with char, a signed integer
>>> type, or an unsigned integer type. The choice of type is
>>> implementation-defined,110) but shall be capable of representing the
>>> values of all the members of the enumeration.
>> 
>> The standard also says:
>> 
>>   The expression that defines the value of an enumeration constant shall
>>   be an integer constant expression that has a value representable as an
>>   int.
> 
> Ahh, I see. So even if the type of the enum is specified by the
> compiler as "unsigned int"; the value assigned to it can only be an
> "int".

  So, how about

 typedef enum OMX_ERRORTYPE
 {
   OMX_ErrorNone = 0,
   OMX_ErrorInsufficientResources = (int)0x80001000
 } OMX_ERRORTYPE;

?



cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: interesting case of DCE with dataflow.

[Kenneth Zadeck]

Ramana Radhakrishnan wrote:
> Hi ,
>
> I've been investigating an interesting case with the following
> testcase in my private port. I know this is a slightly theoretical
> case but I believe one that should be handled cleanly.
>
> I haven't yet been able to replicate this on any other port yet whilst
> I have tried ARM, MIPS and m68k.
>
> Consider this case .
>
> void foo (int n, int in[], int res[])
> {
>   int i;
>   for (i=0; i if (in[i])
>   res[i]= 0x1234;
> else
>   res[i]= 0x1234;
> }
>
> The final code generated appears something like the following.
>
> foo:
> cmpslt  $c6,$zero,$c1
> brz $c6,$link
> i2cs$c6,@MID_11(4660)
> i2c $c6,@BOT_11(4660)
> incsi   $c1,-1
> .L5:
> stw ($c3[0]),$c6
> addzi   $c2,$c2,4  -> This is a redundant add instruction.
> addzi   $c3,$c3,4
> brinzdec$c1,.L5
> brz $zero,$link
>
>   
I am completely missing your question.  i do not see any redundancy of
the insn that you say is redundant.  that insn is indexing thru in and
the next insn is indexing thru res. 

Obviously i am missing something.

> Parameters in my port are passed in registers c1, c2 and c3 and hence
> one would expect that the address increment for in[i] with the loop
> would be removed as dead code.  However none of the tree passes remove
> the redundant check as dead code and hence it is left down to the RTL
> passes to cope as best as they can.
>
> After final_cleanup
>
>
> foo (n, in, res)
> {
>   long unsigned int ivtmp.20;
>   long unsigned int ivtmp.18;
>   int i;
>
> :
>   if (n > 0)
> goto ;
>   else
> goto ;
>
> :
>   ivtmp.18 = (long unsigned int) in;
>   ivtmp.20 = (long unsigned int) res;
>   i = 0;
>
> :
>   if (MEM[index: ivtmp.18] != 0)
> goto ;
>   else
> goto ;
>
> :
>   MEM[index: ivtmp.20] = 4660;
>   goto ;
>
> :
>   MEM[index: ivtmp.20] = 4660;
>
> :
>   i = i + 1;
>   ivtmp.18 = ivtmp.18 + 4;
>   ivtmp.20 = ivtmp.20 + 4;
>   if (n > i)
> goto ;
>   else
> goto ;
>
> :
>   return;
>
> }
>
>
>
> However the check for if (in[i]) is removed by DCE during peep2 . This
> is insn 43 in the attached logs .
>
>  However insn 58 which is the step instruction for ivtmp.18 which is
> in turn assigned to the parameter "in", does not get removed by DCE .
>
> Shouldn't $c2 become dead after the basic block in which it is
> contained. ? I have tried debugging through this but could not make
> much headway yet. If anyone has any thoughts on this would be quite
> useful to hear it.
>
> I have attached 2 sets of logs - One is with just peephole2 , expand ,
> dce and final_cleanup whilst the other one has everything else
> (fulllogs.tar.bz2)
>
>
>
> cheers
> Ramana
>
>
>
>
>
>
>
>   

Re: Wrong warning? ISO C restricts enumerator values to range of ‘int’

[Vincent Lefevre]

On 2008-02-06 14:59:21 -, Dave Korn wrote:
>   So, how about
> 
>  typedef enum OMX_ERRORTYPE
>  {
>OMX_ErrorNone = 0,
>OMX_ErrorInsufficientResources = (int)0x80001000
>  } OMX_ERRORTYPE;
> 
> ?

You should get a warning in the cases where 0x80001000 isn't
representable in an int because it is an implementation-defined
behavior. Is there any reason why gcc doesn't issue one?

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: Some 4.4 project musings

[Jeff Law]

Andrew MacLeod wrote:


There are a few things that I'm considering working on for the 4.4 
release, and I figured I'd see what others thought.  Is anyone 
considering/doing similar or related work?

I'll summarize each, and then go into more details.

1 - Pass cleanup.  There have been rumblings about this, but I haven't 
seen a lot of actual progress. We currently run 100's of passes all the 
time, and we don't really know how effective or necessary many of them 
are. We also don't know whether the cleanups they run are truly doing 
much.  It would be nice to do some actual analysis and do something with 
the results.

[ ... ]


FWIW, this is an area I've always thought we could make some
improvements.  For example, we've got cases where knowing
how pass A changed the IL may allow us to skip pass B.  This
first came up in the context of skipping cse2, but it applies
in the SSA optimizers as well, possibly even more so.

Jeff

Re: interesting case of DCE with dataflow.

[Daniel Jacobowitz]

On Wed, Feb 06, 2008 at 10:59:12AM -0500, Kenneth Zadeck wrote:
> > The final code generated appears something like the following.
> >
> > foo:
> > cmpslt  $c6,$zero,$c1
> > brz $c6,$link
> > i2cs$c6,@MID_11(4660)
> > i2c $c6,@BOT_11(4660)
> > incsi   $c1,-1
> > .L5:
> > stw ($c3[0]),$c6
> > addzi   $c2,$c2,4  -> This is a redundant add instruction.
> > addzi   $c3,$c3,4
> > brinzdec$c1,.L5
> > brz $zero,$link
> >
> >   
> I am completely missing your question.  i do not see any redundancy of
> the insn that you say is redundant.  that insn is indexing thru in and
> the next insn is indexing thru res. 
> 
> Obviously i am missing something.

Except the load from in has been removed (it's redundant); so only the
indexing is left.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] Change (flatten) representation of memory references

[Eric Botcazou]

> I'm not sure what to do about bit-aligned TImode fields
> for example, or other things that appearantly can be done with Ada
> (which allows bit-packing).

I think that we can live without TImode bitfields, up to DImode would be fine.

-- 
Eric Botcazou

Is objc++ supported?

[Kaveh R. GHAZI]

Hi,

Is there any interest in getting the testsuite failures in objc++ fixed?

http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00401.html

I generally include it in my testsuite results and I can file bug reports,
etc. but I want to know if it's worthwhile or not.  The ChangeLog for it
contains mostly patches to Make-lang.in, etc.  And the same 10 or so
failures have been around forever.

Some of the failures seem to be errors in the testcases.  Perhaps others
are rooted from generic parts of the compiler, not objc++.  Still it would
be nice to clean them up.

Thanks,
--Kaveh
--
Kaveh R. Ghazi  [EMAIL PROTECTED]

Re: Wrong warning? ISO C restricts enumerator values to range of ‘int’

[Manuel López-Ibáñez]

On 06/02/2008, Vincent Lefevre <[EMAIL PROTECTED]> wrote:
> You should get a warning in the cases where 0x80001000 isn't
> representable in an int because it is an implementation-defined
> behavior. Is there any reason why gcc doesn't issue one?

Maybe I don't understand what you are asking but from reading the code
and relevant testcases, it seems that:

* Unsigned integer constants for enum values are handled just fine by
GCC as a extension to the C language. (See testsuite/gcc.dg/enum1.c).
* Being an extension, it is warned by -pedantic.

So everything is working as expected, isn't it?

Cheers,

Manuel.

Re: interesting case of DCE with dataflow.

[Kenneth Zadeck]

Daniel Jacobowitz wrote:
> On Wed, Feb 06, 2008 at 10:59:12AM -0500, Kenneth Zadeck wrote:
>   
>>> The final code generated appears something like the following.
>>>
>>> foo:
>>> cmpslt  $c6,$zero,$c1
>>> brz $c6,$link
>>> i2cs$c6,@MID_11(4660)
>>> i2c $c6,@BOT_11(4660)
>>> incsi   $c1,-1
>>> .L5:
>>> stw ($c3[0]),$c6
>>> addzi   $c2,$c2,4  -> This is a redundant add instruction.
>>> addzi   $c3,$c3,4
>>> brinzdec$c1,.L5
>>> brz $zero,$link
>>>
>>>   
>>>   
>> I am completely missing your question.  i do not see any redundancy of
>> the insn that you say is redundant.  that insn is indexing thru in and
>> the next insn is indexing thru res. 
>>
>> Obviously i am missing something.
>> 
>
> Except the load from in has been removed (it's redundant); so only the
> indexing is left.
>
>   
Sorry, you are correct.

There are two flavors of dce at the rtl level, they are called "fast"
and "ud".  The ud is an optimistic  use def algorithm that is based on
the ssa algorithm by Cyrton, Ferrrante 

By optimistic, i mean that it assumes that all code is dead unless
proven live.  However it is very expensive to maintain use-def chains
unless you have ssa form underneath them, so this pass is only run once
before combine.  (it could be argued that this is the wrong place for
that, but this would require a lot of measurement on many platforms. 
The logic here was that the most opportunities for this would be after
the loop optimizations but the cleanups would be useful for combine.)

An unused induction variable can only be removed by the optimistic
code.  The pessimistic version is much faster and is run many times at
the rtl level.  However it assumes that all insns are live unless they
can be proven dead, so an induction var never dies.

At the time that the optimistic pass is run, there is still a real use
of this register in insn 43.  So the optimistic pass cannot get rid of
insn 57.

Kenny






This can only be removed at the tree level.

Re: Wrong warning? ISO C restricts enumerator values to range of ‘int’

[Vincent Lefevre]

On 2008-02-06 18:52:16 +0100, Manuel López-Ibáñez wrote:
> Maybe I don't understand what you are asking but from reading the code
> and relevant testcases, it seems that:
> 
> * Unsigned integer constants for enum values are handled just fine by
> GCC as a extension to the C language. (See testsuite/gcc.dg/enum1.c).

The problem is the cast (suggested by Dave Korn), not the enum itself:
(int) 0x80001000

> * Being an extension, it is warned by -pedantic.
> 
> So everything is working as expected, isn't it?

Oops, I forgot that my machine was reinstalled in 64 bits a few days
ago. Now, I've the same problem (i.e. no warnings) on a 32-bit machine
(though not with the latest gcc version):

ay:~> gcc --version
cc (GCC) 4.2.3 20080114 (prerelease) (Debian 4.2.2-7)
[...]
ay:~> cat tst.c
#include 

typedef enum OMX_ERRORTYPE {
  OMX_ErrorNone = 0,
  OMX_ErrorInsufficientResources = (int) 0x80001000
} OMX_ERRORTYPE;

int main (void)
{
  printf ("%d\n", (int) OMX_ErrorInsufficientResources);
  return 0;
}
ay:~> gcc -Wall -pedantic -std=c99 tst.c -o tst
ay:~> ./tst
-2147479552

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

RE: Wrong warning? ISO C restricts enumerator values to range of 'int'

[Dave Korn]

On 06 February 2008 18:22, Vincent Lefevre wrote:

> On 2008-02-06 18:52:16 +0100, Manuel López-Ibáñez wrote:
>> Maybe I don't understand what you are asking but from reading the code
>> and relevant testcases, it seems that:
>> 
>> * Unsigned integer constants for enum values are handled just fine by
>> GCC as a extension to the C language. (See testsuite/gcc.dg/enum1.c).
> 
> The problem is the cast (suggested by Dave Korn), not the enum itself:
> (int) 0x80001000

  FTR, I was on a 64-bit host when I tested that.

cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: [RFC] Change (flatten) representation of memory references

[Richard Guenther]

On Wed, 6 Feb 2008, Eric Botcazou wrote:

> > I'm not sure what to do about bit-aligned TImode fields
> > for example, or other things that appearantly can be done with Ada
> > (which allows bit-packing).
> 
> I think that we can live without TImode bitfields, up to DImode would be fine.

I was mainly worried about us trying to for example copy a bit-packed
substructure like

struct A {
  unsigned use_1_bit : 1;
  struct B {
char large[100];
  } b;
} a, b;

where b.large[0] is at offset 1 bit of a (I believe this is possible
with Ada, right?).  If we then have the IL (no idea if we would
consider this valid, but this is before GIMPLE):

 a.b = b.b;

I have no idea how to best lower this ;)  Basically, I want to be
able to load/store an aligned unit covering the bitfield into a
register.

But I guess we'll see when it actually happens.

Richard.

Re: Wrong warning? ISO C restricts enumerator values to range of ‘int’

[Manuel López-Ibáñez]

On 06/02/2008, Vincent Lefevre <[EMAIL PROTECTED]> wrote:
> On 2008-02-06 18:52:16 +0100, Manuel López-Ibáñez wrote:
> > Maybe I don't understand what you are asking but from reading the code
> > and relevant testcases, it seems that:
> >
> > * Unsigned integer constants for enum values are handled just fine by
> > GCC as a extension to the C language. (See testsuite/gcc.dg/enum1.c).
>
> The problem is the cast (suggested by Dave Korn), not the enum itself:
> (int) 0x80001000
>

What is the problem with the cast? Do you want a warning for the
conversion that you asked for with the cast? We want about implicit
conversions with -Wconversion but if you use a cast, we understand
that you really mean to perform the conversion.

Notice that without -pedantic you don't need to do anything, the value
is kept as it is. With -pedantic, you don't need the cast either, it
is automatically converted to an int (yes, there is a conversion but
that is what the warning is telling you). If you use a cast, then you
perform the conversion yourself and there is nothing to warn about.

Cheers,

Manuel.

Re: [RFC] Change (flatten) representation of memory references

[Eric Botcazou]

> I was mainly worried about us trying to for example copy a bit-packed
> substructure like
>
> struct A {
>   unsigned use_1_bit : 1;
>   struct B {
> char large[100];
>   } b;
> } a, b;
>
> where b.large[0] is at offset 1 bit of a (I believe this is possible
> with Ada, right?).

Actually no, it's not possible.  Once something is BLKmode, it's at least 
aligned on a byte boundary.  It's only possible for integral modes.

-- 
Eric Botcazou

Re: [RFC] Change (flatten) representation of memory references

[Richard Kenner]

> I was mainly worried about us trying to for example copy a bit-packed
> substructure like
> 
> struct A {
>   unsigned use_1_bit : 1;
>   struct B {
> char large[100];
>   } b;
> } a, b;
> 
> where b.large[0] is at offset 1 bit of a (I believe this is possible
> with Ada, right?).

It is possible ONLY if the programmer explictly puts it there with a
record representation clause.

> If we then have the IL (no idea if we would
> consider this valid, but this is before GIMPLE):
> 
>  a.b = b.b;

... in which case the Ada front end will know that it must never generate
a reference to the entire field "b", but will instead generate a
loop to copy character-by-character.

> I have no idea how to best lower this ;)  

My feeling is to declare it invalid.  You can't have a BLKmode field
aligned at other than a byte boundary if you want to be able to access
the field as a whole.

Re: [RFC] Change (flatten) representation of memory references

[Richard Guenther]

On Wed, 6 Feb 2008, Richard Kenner wrote:

> > I was mainly worried about us trying to for example copy a bit-packed
> > substructure like
> > 
> > struct A {
> >   unsigned use_1_bit : 1;
> >   struct B {
> > char large[100];
> >   } b;
> > } a, b;
> > 
> > where b.large[0] is at offset 1 bit of a (I believe this is possible
> > with Ada, right?).
> 
> It is possible ONLY if the programmer explictly puts it there with a
> record representation clause.
> 
> > If we then have the IL (no idea if we would
> > consider this valid, but this is before GIMPLE):
> > 
> >  a.b = b.b;
> 
> ... in which case the Ada front end will know that it must never generate
> a reference to the entire field "b", but will instead generate a
> loop to copy character-by-character.
> 
> > I have no idea how to best lower this ;)  
> 
> My feeling is to declare it invalid.  You can't have a BLKmode field
> aligned at other than a byte boundary if you want to be able to access
> the field as a whole.

Thanks, that certainly makes my life easier and my brain hurt less ;)

(anyone for an Ada tutorial during the summit? ;)

Thanks,
Richard.

Re: Is objc++ supported?

[Mike Stump]

On Feb 6, 2008, at 9:58 AM, Kaveh R. GHAZI wrote:
Is there any interest in getting the testsuite failures in objc++  
fixed?


Yes, but, if you have other, more important things...  :-)


http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00401.html

I generally include it in my testsuite results and I can file bug  
reports,

etc. but I want to know if it's worthwhile or not.


For state changes, yes, one should file bug reports and if possible,  
identify who changed the state and help them resolve it if possible.   
For the other things, cleanup, porting and the like, no, I'd not bother.


Perhaps others are rooted from generic parts of the compiler, not  
objc++.  Still it would be nice to clean them up.


Agreed.  If you want to work on it, I'd be happy to help out, just let  
me know.

Re: Wrong warning? ISO C restricts enumerator values to range of ‘int’

[Vincent Lefevre]

On 2008-02-06 21:17:53 +0100, Manuel López-Ibáñez wrote:
> On 06/02/2008, Vincent Lefevre <[EMAIL PROTECTED]> wrote:
> > The problem is the cast (suggested by Dave Korn), not the enum itself:
> > (int) 0x80001000
> >
> 
> What is the problem with the cast? Do you want a warning for the
> conversion that you asked for with the cast? We want about implicit
> conversions with -Wconversion but if you use a cast, we understand
> that you really mean to perform the conversion.

The problem is that the conversion here is implementation-defined,
and may raise a signal on some platforms; so, this is a non-portable
construct. I think that a warning should be issued because the value
is out-of-range. This would allow to detect problems that can arise
on some platforms, e.g. with code like:

#include 
#include 

int main (void)
{
  printf ("%ld\n", (long) UINT_MAX);
  return 0;
}

On platforms where int and long have the same size (so that UINT_MAX
isn't representable in a long), a warning would be useful.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

gcc-4.2-20080206 is now available

[gccadmin]

Snapshot gcc-4.2-20080206 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20080206/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch 
revision 132160

You'll find:

gcc-4.2-20080206.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.2-20080206.tar.bz2 C front end and core compiler

gcc-ada-4.2-20080206.tar.bz2  Ada front end and runtime

gcc-fortran-4.2-20080206.tar.bz2  Fortran front end and runtime

gcc-g++-4.2-20080206.tar.bz2  C++ front end and runtime

gcc-java-4.2-20080206.tar.bz2 Java front end and runtime

gcc-objc-4.2-20080206.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.2-20080206.tar.bz2The GCC testsuite

Diffs from 4.2-20080130 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.2
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

sh-elf vs profiling

[DJ Delorie]

Is sh-elf/sim supposed to support profiling?  My latest tests show all
the profiling tests failing.  For example, the bprob executable has
the name of the gcda file in it, but doesn't attempt to write it out
(verified with strace against the simulator).

How to run C++ tests with different optimization flags?

[H.J. Lu]

We have a bunch of stack alignment run-time tests for C++. We
like to run them with difffernet optimization flags, like
-O0, -O1, -O2, ...,  similar to those under gcc.c-torture/execute.
Is there a way to do it for C++?

Thanks.


H.J.

Re: How to run C++ tests with different optimization flags?

[Andrew Pinski]

On Feb 6, 2008 2:50 PM, H.J. Lu <[EMAIL PROTECTED]> wrote:
> We have a bunch of stack alignment run-time tests for C++. We
> like to run them with difffernet optimization flags, like
> -O0, -O1, -O2, ...,  similar to those under gcc.c-torture/execute.
> Is there a way to do it for C++?

I guess you missed g++.dg/torture which is like gcc.dg/torture which
runs at different optimizations level.

-- Pinski

Re: How to stop gcc from not calling noinline functions

[Mark Mitchell]

Richard Guenther wrote:


You can apart from the other suggestions also mark the function weak
which will prevent both inlining and pure/const analysis.


How about just writing to a volatile variable from within the callee?

void f() __attribute__((noinline)) {
  volatile int i;
  i = 3;
}

void g() {
  f();
}

A valid GNU C compiler cannot eliminate the call to "f", as long as the 
call itself is reachable.


--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: may_alias attribute and type identity (PR c++/34935)

[Mark Mitchell]

Doug Gregor wrote:

PR c++/34935 illustrates a problem with the way attributes interact
with type identity. The example in question looks something like this:

  typedef int X __attribute((may_alias));

  void foo(X);
  void foo(int);



Note that this is pretty tied up with Mark Mitchell's discussion of
semantic and non-semantic attributes, here:

  http://gcc.gnu.org/ml/gcc/2006-10/msg00318.html


The may_alias attribute is a semantic attribute as it is specifically 
designed to affect code-generation.


Using the message you mention, this means that "X" is distinct from 
"int" -- which is what Richard and Jakub indicate as well, based on what 
the middle-end does.


Also, that message says:


It is invalid to do anything that would require either type_info or a mangled name for "Q", 
including using it as an argument to typeid, thowing an exception of a type involving "Q", or 
declaring a template to take a parameter of a type involving "Q".


So, that means that you can't have any C++ functions with external 
linkage involving "X".  Of course, as that message says:



We could relax some of these restrictions in future, if we add mangling support 
for attributes.


But, yes, if we need to mangle these types, we need to have a mangling 
for attributes.


--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: sh-elf vs profiling

[Kaz Kojima]

DJ Delorie <[EMAIL PROTECTED]> wrote:
> Is sh-elf/sim supposed to support profiling?  My latest tests show all
> the profiling tests failing.  For example, the bprob executable has
> the name of the gcda file in it, but doesn't attempt to write it out
> (verified with strace against the simulator).

Is your gcc configured with --with-newlib --with-headers?
I thought that those options are required to get a working
libgcov on newlib targets.

Regards,
kaz

Re: sh-elf vs profiling

[DJ Delorie]

> Is your gcc configured with --with-newlib --with-headers?

$TOP/gcc/gcc/configure --prefix=$PREFIX --target=$TARGET \
  --enable-languages=c,c++ --with-newlib --with-mpfr=/usr/local

I do a two-phase build.  I build gcc (and let it fail for libgcc) to
get xgcc/cc1, then build and install newlib, then go back and build
gcc.

But it fails even in one of our recent combined-tree builds too.

Re: sh-elf vs profiling

[Kaz Kojima]

DJ Delorie <[EMAIL PROTECTED]> wrote:
>> Is your gcc configured with --with-newlib --with-headers?
> 
> $TOP/gcc/gcc/configure --prefix=$PREFIX --target=$TARGET \
>   --enable-languages=c,c++ --with-newlib --with-mpfr=/usr/local
> 
> I do a two-phase build.  I build gcc (and let it fail for libgcc) to
> get xgcc/cc1, then build and install newlib, then go back and build
> gcc.
> 
> But it fails even in one of our recent combined-tree builds too.

Hmm... Did you try --with-headers?

I've configured my unified tree like as

../TMP/combined/configure --target=sh-elf 
--prefix=/exp/ldroot/dodes/install-combined --with-newlib --with-headers 
--disable-gdbtk --enable-languages=c

and got

Running /exp/ldroot/dodes/TMP/combined/gcc/testsuite/gcc.misc-tests/bprob.exp 
...

=== gcc Summary ===

# of expected passes56

for "make check-gcc RUNTESTFLAGS='--target_board=sh-sim bprob.exp'.

Regards,
kaz

bootstrap failure with r132166

[Matthias Klose]

I see the following failure on i386-linux and powerpc-linux

  Matthias

/scratch/packages/gcc/4.3/gcc-4.3-4.3-20080206/build/./prev-gcc/xgcc 
-B/scratch/packages/gcc/4.3/gcc-4.3-4.3-20080206/build/./prev-gcc/ 
-B/usr/i486-linux-gnu/bin/ -c   -g -O2 -fomit-frame-pointer -DIN_GCC   -W -Wall 
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition 
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
 -Wno-overlength-strings -Werror -DOBJCPLUS 
-I../../src/gcc/objc -I../../src/gcc/cp-DHAVE_CONFIG_H -I. -Iobjcp 
-I../../src/gcc -I../../src/gcc/objcp -I../../src/gcc/../include 
-I../../src/gcc/../libcpp/include  -I../../src/gcc/../libdecnumber 
-I../../src/gcc/../libdecnumber/bid -I../libdecnumber
../../src/gcc/objcp/objcp-decl.c -o objcp/objcp-decl.o
cc1: warnings being treated as errors
../../src/gcc/objcp/objcp-decl.c: In function 'objcp_comptypes':
../../src/gcc/objcp/objcp-decl.c:98: error: implicit declaration of function 
'comptypes'
make[5]: *** [objcp/objcp-decl.o] Error 1
make[5]: *** Waiting for unfinished jobs

Re: sh-elf vs profiling

[DJ Delorie]

> Hmm... Did you try --with-headers?

I'll give that a try.

Re: bootstrap failure with r132166

[David Daney]

Matthias Klose wrote:

I see the following failure on i386-linux and powerpc-linux

  Matthias

/scratch/packages/gcc/4.3/gcc-4.3-4.3-20080206/build/./prev-gcc/xgcc 
-B/scratch/packages/gcc/4.3/gcc-4.3-4.3-20080206/build/./prev-gcc/ 
-B/usr/i486-linux-gnu/bin/ -c   -g -O2 -fomit-frame-pointer -DIN_GCC   -W -Wall 
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition 
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
 -Wno-overlength-strings -Werror -DOBJCPLUS 
-I../../src/gcc/objc -I../../src/gcc/cp-DHAVE_CONFIG_H -I. -Iobjcp 
-I../../src/gcc -I../../src/gcc/objcp -I../../src/gcc/../include 
-I../../src/gcc/../libcpp/include  -I../../src/gcc/../libdecnumber 
-I../../src/gcc/../libdecnumber/bid -I../libdecnumber
../../src/gcc/objcp/objcp-decl.c -o objcp/objcp-decl.o
cc1: warnings being treated as errors
../../src/gcc/objcp/objcp-decl.c: In function 'objcp_comptypes':
../../src/gcc/objcp/objcp-decl.c:98: error: implicit declaration of function 
'comptypes'
make[5]: *** [objcp/objcp-decl.o] Error 1
make[5]: *** Waiting for unfinished jobs


See:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35115

David Daney

Re: sh-elf vs profiling

[Ben Elliston]

Hi DJ

> Is sh-elf/sim supposed to support profiling?  My latest tests show all
> the profiling tests failing.  For example, the bprob executable has
> the name of the gcda file in it, but doesn't attempt to write it out
> (verified with strace against the simulator).

I guess it probably doesn't apply in this case (if you've straced the
simulator), but please also keep in mind another gotcha:

http://gcc.gnu.org/ml/gcc/2006-12/msg00561.html

Cheers, Ben

Re: sh-elf vs profiling

[DJ Delorie]

> I guess it probably doesn't apply in this case (if you've straced the
> simulator), but please also keep in mind another gotcha:
> 
> http://gcc.gnu.org/ml/gcc/2006-12/msg00561.html

Yeah, doesn't apply.  There were no *attempts* at I/O from the
simulator.  I'm more inclined to think that the atexit() stuff got
corrupted, which lends strength to Kaz's suggestion.

Re: How to stop gcc from not calling noinline functions

[Hans-Peter Nilsson]

> Date: Wed, 06 Feb 2008 15:59:21 -0800
> From: Mark Mitchell <[EMAIL PROTECTED]>

> Richard Guenther wrote:
> 
> > You can apart from the other suggestions also mark the function weak
> > which will prevent both inlining and pure/const analysis.
> 
> How about just writing to a volatile variable from within the callee?

Can't we just please stick with the asm as agreed on (which
already *is* volatile and besides is recognizable as magical,
should the need arise), and have the documentation patch
approved by a >= middle-end maintainer?  ;)

brgds, H-P

Re: [RFC] Change (flatten) representation of memory references

[Hans-Peter Nilsson]

On Wed, 6 Feb 2008, Richard Guenther wrote:
> (anyone for an Ada tutorial during the summit? ;)

(I wish I didn't see that smiley, because)
For practical reasons, I'd agree that's a very good idea!

I mean, those (hopefully "we") who attend could presumably hear
about some subset that relates to GCC developers, instead of
going the self-teaching path or taking some generic
semi-introductory course.

brgds, H-P

Re: [RFC] Change (flatten) representation of memory references

[Richard Kenner]

> > (anyone for an Ada tutorial during the summit? ;)
> 
> (I wish I didn't see that smiley, because)
> For practical reasons, I'd agree that's a very good idea!
> 
> I mean, those (hopefully "we") who attend could presumably hear
> about some subset that relates to GCC developers, instead of
> going the self-teaching path or taking some generic
> semi-introductory course.

Which would be more interesting: a tutorial on the Ada language itself or
on the "demands" it places on GCC?  The people who would do each of those
are different: Eric and I are two of the best for the latter, but neither
of us knows the Ada language well enough to give a language tutorial and
nearly all of those who do know it that well don't know how it interacts
with the GCC middle-end.

Re: [RFC] Change (flatten) representation of memory references

[Sebastian Pop]

On Feb 6, 2008 9:02 PM, Richard Kenner <[EMAIL PROTECTED]> wrote:
> Which would be more interesting: a tutorial on the Ada language itself or
> on the "demands" it places on GCC?

I would say that both tutorials sound interesting ;-)

When I first heard a tutorial on the Ada language, I found it very
interesting.  Here are the links to this tutorial that was given at
the FOSDEM'06 by Jean-Pierre Rosen:

http://archive.fosdem.org/2006/2006/index/dev_room_ada.html
http://www.cs.kuleuven.be/~dirk/ada-belgium/events/06/060226-fosdem.html
http://www.cs.kuleuven.be/~dirk/ada-belgium/events/06/060226-fosdem-1-intro-ada.pdf

Sebastian

Internals for STL containers

[Nick Roberts]

Emacs 22.1 has a graphical interface to Gdb which allows the display of
watch expressions in the Speedbar.

Using variable objects, if I display a watch expression for an STL container
in a program compiled with gcc, e.g.,

  vector v (3);
  v[0] = 1;
  v[1] = 11;
  v[2] = 22;

in the Speedbar, I get something like this:

v std::vector >
std::_Vector_base > 
std::_Vector_base >
  public 
_M_impl std::_Vector_base >::_Vector_impl
  std::allocator   std::allocator
__gnu_cxx::new_allocator   {...}
  public 
_M_start int *  0x804c008
  *_M_start 0
_M_finishint *  0x804c014   
  *_M_finish135153  
_M_end_of_storageint *  0x804c014
  *_M_end_of_storage135153  

which is a bit meaningless to the end user.  In this case, I know where the
values are really stored:

 v._M_impl._M_start int *   0x804c008
 *v._M_impl._M_start1
 *(v._M_impl._M_start+1)11
 *(v._M_impl._M_start+2)22

(gdb) p v._M_impl._M_finish - v._M_impl._M_start
$1 = 3

and it would be better for Emacs to display some of these.

However, _M_impl, _M_start etc are gcc internals and it might be risky for
Emacs to rely on them.  Can anyone say how likely these internals are to
change?  I'm not asking for a guarantee.  It would be helpful just to know
when they last changed as an indication of how volatile this code might be.


-- 
Nick   http://www.inet.net.nz/~nickrob

Re: Patch manager dying for a week or two

[NightStrike]

On 12/5/07, Rask Ingemann Lambertsen <[EMAIL PROTECTED]> wrote:
> On Wed, Dec 05, 2007 at 04:32:00PM -0500, NightStrike wrote:
> > On 12/5/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> > > Patch manager will be dying for a week or two while i change hosting.
> > >
> > > of course, if nobody is still using it, i can just kill it permanently.
>
>   grep -F -e patchapp gcc-bugs@ says it is being used. I use it and would
> like to keep doing so. As well as tracking my patches, I find the notice
> automatically posted to the bug database a lot more convenient that having
> to do so manually.
>
> > What is the patch manager?
>
> http://gcc.gnu.org/wiki/GCC_Patch_Tracking

This site seems to indicate that the patch manager is still offline.
Is that the case?

gcc using wrong as

[Antoine Kaufmann]

Hello

I'm working on a gcc port to a hobby operating system. I got it working 
partially (cc1 works and I think I'm not far from get the gcc frontend 
working).

Now i wanted to rename my target from i386-elf-lost to i386-pc-lost because I 
was told that this would be more canonical. (I don't wanted to rename it to 
i386-lost-elf because I was told that this would enable some newlib features, 
and we aren't using newlib).

I wanted to recompile gcc for the new target. First I made the changes in 
binutils and recompiled them without any problem. Recompiling gcc worked too 
after some small changes. But when I tried to compile a simple Hello World, 
gcc failed with some assembler error messages about illegal operad size with 
some push instructions. As i guessed they seem to come from the host 64bit 
as. I compared the error messages by trying to assemble the code manually.

This seems very strange to me, because there were no problems with the old 
target name. configure locates as correctly (as far as I can judge this):
checking for as... no
checking for i386-pc-lost-as... i386-pc-lost-as

Any ideas why this doesn't work anymore?

I attached the relevant parts of the diff to the original gcc-source (I left 
out some changes in libiberty which are only useful for the native compiler).

Thanks

Toni Kaufmann
diff -ruN ../gcc-4.2.2/config.sub ./config.sub
--- ../gcc-4.2.2/config.sub	2006-10-16 05:27:17.0 +0200
+++ ./config.sub	2008-02-04 12:51:15.0 +0100
@@ -121,8 +121,8 @@
 maybe_os=`echo $1 | sed 's/^\(.*\)-\([^-]*-[^-]*\)$/\2/'`
 case $maybe_os in
   nto-qnx* | linux-gnu* | linux-dietlibc | linux-newlib* | linux-uclibc* | \
-  uclinux-uclibc* | uclinux-gnu* | kfreebsd*-gnu* | knetbsd*-gnu* | netbsd*-gnu* | \
-  storm-chaos* | os2-emx* | rtmk-nova*)
+  lost* | uclinux-uclibc* | uclinux-gnu* | kfreebsd*-gnu* | knetbsd*-gnu* | \
+  netbsd*-gnu* | storm-chaos* | os2-emx* | rtmk-nova*)
 os=-$maybe_os
 basic_machine=`echo $1 | sed 's/^\(.*\)-\([^-]*-[^-]*\)$/\1/'`
 ;;
@@ -1249,6 +1249,9 @@
 	-linux*)
 		os=`echo $os | sed -e 's|linux|linux-gnu|'`
 		;;
+-lost*)
+os=-lost
+;;
 	-sunos5*)
 		os=`echo $os | sed -e 's|sunos5|solaris2|'`
 		;;
diff -ruN ../gcc-4.2.2/gcc/config/i386/lost.h ./gcc/config/i386/lost.h
--- ../gcc-4.2.2/gcc/config/i386/lost.h	1970-01-01 01:00:00.0 +0100
+++ ./gcc/config/i386/lost.h	2008-02-04 12:51:15.0 +0100
@@ -0,0 +1,56 @@
+/* Definitions for Intel 386 running Linux-based GNU systems with ELF format.
+   Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2001, 2002, 2004, 2005,
+   2006, 2007 Free Software Foundation, Inc.
+   Contributed by Eric Youngdale.
+   Modified for stabs-in-ELF by H.J. Lu.
+   Adapted from linux.h by Antoine Kaufmann
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later version.
+
+GCC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+.  */
+
+/* Output at beginning of assembler file.  */
+/* The .file command should always begin the output.  */
+#define TARGET_ASM_FILE_START_FILE_DIRECTIVE true
+
+#define TARGET_VERSION fprintf (stderr, " (i386 LOST/ELF)");
+
+/* The svr4 ABI for the i386 says that records and unions are returned
+   in memory.  */
+#undef DEFAULT_PCC_STRUCT_RETURN
+#define DEFAULT_PCC_STRUCT_RETURN 1
+
+#undef ASM_COMMENT_START
+#define ASM_COMMENT_START "#"
+
+#undef SIZE_TYPE
+#define SIZE_TYPE "unsigned int"
+ 
+#undef PTRDIFF_TYPE
+#define PTRDIFF_TYPE "int"
+  
+#undef WCHAR_TYPE
+#define WCHAR_TYPE "long int"
+   
+#undef WCHAR_TYPE_SIZE
+#define WCHAR_TYPE_SIZE BITS_PER_WORD
+
+#define TARGET_OS_CPP_BUILTINS()		\
+  do		\
+{		\
+	LOST_TARGET_OS_CPP_BUILTINS();		\
+}		\
+  while (0)
+
diff -ruN ../gcc-4.2.2/gcc/config/lost.h ./gcc/config/lost.h
--- ../gcc-4.2.2/gcc/config/lost.h	1970-01-01 01:00:00.0 +0100
+++ ./gcc/config/lost.h	2008-02-04 12:51:15.0 +0100
@@ -0,0 +1,57 @@
+/* Definitions for Linux-based GNU systems with ELF format
+   Copyright (C) 1995, 1996, 1997, 1998, 1999, 2000, 2003, 2004, 2005, 2006,
+   2007 Free Software Foundation, Inc.
+   Contributed by Eric Youngdale.
+   Modified for stabs-in-ELF by H.J. Lu ([EMAIL PROTECTED]).
+   Adapted from linux.h by Antoine Kaufmann
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later versi