Re: GCC 4.1.0 RC1

[Rainer Emrich]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jim Wilson schrieb:
> Rainer Emrich wrote:
>> /SCRATCH/gcc-build/Linux/ia64-unknown-linux-gnu/install/bin/ld:
>> unrecognized
>> option '-Wl,-rpath'
> 
> This looks like PR 21206.  See my explanation at the end.  I see this on
> some of our FreeBSD machines, but I've never seen it on an IA-64 linux
> machine.
Yes, it's exactly the same issue.
My system doesn't have libiconv, so it's installed in a non default location.
I specify the location through --with-libiconv-prefix. That causes the wrong
linker flags.

Rainer

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFD/B1S3s6elE6CYeURAtz0AJ4jjtG0tuKuBBexyPkfWOFDOoJSegCeOVWe
Whtme/60cFHL19y5K+f06QE=
=sCEw
-END PGP SIGNATURE-

Re: Possible accept wrong code in C++?

[Tarjei Knapstad]

On 2/22/06, Ed Smith-Rowland <[EMAIL PROTECTED]> wrote:
> All,
>
> I have a template class:
>
> template < class Datum, unsigned long Dim >
> class DataGrid
> {
> ...
> public:
> ...
> std::ostream &  write( std::ostream & output ) const;
> ...
> };
>
> I have a non-member operator overload:
>
> On GCC-3.4 Cygwin I needed:
>
> template < class Datum, unsigned long Dim >
> inline std::ostream &  operator<<( std::ostream & output, const
> DataGrid & data_grid )
> {
> return  data_grid.write( output );
> }
>
> On GCC-4.0 MacOSX I was able to get by with this:
>
> inline std::ostream &  operator<<( std::ostream & output, const DataGrid
> & data_grid )
> {
> return  data_grid.write( output );
> }
>
> I actually think that 3.4 is right!!!
> Am I wrong?
>

No, gcc version 4.0.2 20051125 (Red Hat 4.0.2-8) does not recognize
DataGrid as a type in the operator<< function definition as expected.

To be honest I have no idea why/how your OSX 4.0 compiler comprehends this...?

--
Tarjei

Re: Ada subtypes and base types (was: Bootstrap failure on trunk: x86_64-linux-gnu)

[Richard Guenther]

On 2/21/06, Richard Kenner <[EMAIL PROTECTED]> wrote:
>  But if the values in there do not reflect the reality of what values
>  are valid for the type, then I don't see how they can be generally
>  useful -- that's my point.  We have two fields that are inaccurate,
>  apparently on purpose, and as a result they are basically unusable.
>
> No, they *do* reflect the "reality of what values are valid for the type".
> The only glitch, which is not what we're talking about here, is that you have
> to have a way to implement the language-defined test to see if the value is
> valid or not.  However, the need to implement that relative-uncommon test
> should't drive the basic methodology used to represent types.

As you mention in another post an invalid value can only occour (as in, being
not undefined behavior) with an unchecked conversion.  The Ada frontend
has to make sure then that for

  BaseType i;
  SubType x = (SubType)i;
// now the value stored in x may exceed its range
  if (Valid (x))
   ...

that for the Valid (x) test, a VIEW_CONVERT_EXPR is used to do the comparison(s)
in the BaseType again.  And using the VIEW_CONVERT_EXPR to tell the compiler
it cannot look through the cast and infer range information from the type of x.

Richard.

Re: Ada subtypes and base types (was: Bootstrap failure on trunk: x86_64-linux-gnu)

[Richard Guenther]

On 2/21/06, Jeffrey A Law <[EMAIL PROTECTED]> wrote:
> On Mon, 2006-02-20 at 22:00 +0100, Richard Guenther wrote:
> > On 2/20/06, Jeffrey A Law <[EMAIL PROTECTED]> wrote:
> > > On Sun, 2006-02-19 at 20:43 +0100, Laurent GUERBY wrote:
> > > > On Sun, 2006-02-19 at 14:23 -0500, Richard Kenner wrote:
> > > > > "Second, for a given integer type (such as
> > > > > natural___XDLU_0_2147483647), the type for the nodes in 
> > > > > TYPE_MIN_VALUE
> > > > > and TYPE_MAX_VALUE really should be a natural___XDLU_0_2147483647.
> > > > > ie, the type of an integer constant should be the same as the 
> > > > > type of
> > > > > its min/max values."
> > > > >
> > > > > No, the type of the bounds of a subtype should be the *base type*.  
> > > > > That's
> > > > > how the tree has always looked, as far back as  I can remember.
> > > >
> > > > This is because intermediate computations can produce results
> > > > outside the subtype range but within the base type range (RM 3.5(6)),
> > > > right?
> > > >
> > > >  type T1 is range 0 .. 127;
> > > >  -- Compiler will choose some type for T'Base, likely to be -128..127
> > > >  -- but could be Integer (implementation dependant)
> > > >  subtype T is T1 range 0 .. 100;
> > > >  R : T := 100+X-X;
> > > >  -- guaranteed work as long 100+X<=T'Base'Last and 100-X>=T'Base'First

Is the final "conversion" a checked conversion or an unchecked conversion?  I.e.
are we supposed to check for overflow using 'Valid on the final result?  Or will
the value be truncated or a runtime error raised?

Richard.

conditional expression evaluation at compile time in gcc 4.01

[Inder]

Hi All

I am trying to compile 'test.cc' (code attached) with the gcc 4.0.1
it gives me the following error:

test.cc:19: error: array bound is not an integer constant

so it is not able to evaluate the conditional expression in gcc 4.0.1,
while this is being compile by gcc 3.4 without any errors.

Is this a bug in gcc 4.0.1

Any help will be appreciated.

Thanks
Inder.




--- test.cc
---
#include 

typedef struct
{
 int length;
 int a;
 int b;
}CYANBUFFER;

typedef struct
{
 int a;
 int length;
}tNPMessage;



#define my_offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER)
int hello[my_offsetof(CYANBUFFER, length)==my_offsetof(tNPMessage,
length)?10:1];

int main()
{
 return 0;
}

--- test.cc
---

Re: type layout bug, or not?

[Richard Guenther]

On 2/21/06, Andrew Pinski <[EMAIL PROTECTED]> wrote:
>
> On Feb 21, 2006, at 4:44 PM, Chris Lattner wrote:
> >
> > Is this the intended layout of this structure?  What does it mean when
> > a field runs off the end of the structure?  In this case, should I
> > just ignore the type size and assume that the 8 bytes are dynamically
> > there?
>
> I wonder if this is the same problem as recorded as PR 22488.  To me it
> does sound
> like the same issue.

Which should remind the C++ folks that they promised to fix this for 4.2 :P

Richard.

Re: Bootstrap failure on trunk: x86_64-linux-gnu

[Richard Guenther]

On 2/21/06, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Jeffrey A Law wrote:
>
> > My feeling?  Absolutely, TYPE_MIN_VALUE and TYPE_MAX_VALUE should
> > represent the set of values that an object of the type may hold.
> > Any other definition effectively renders those values useless.
>
> I agree -- with the obvious caveat that it need not be the case that the
> object actually have that value if the program has invoked undefined
> behavior.  So, if you have an 5-bit type, stored in a byte, and you
> manage to get 255 in that byte, and you read the value, you might see
> 255 at runtime -- but only because your program was busted anyhow.

Right.  And if Ada wants to test for this condition using 'Valid, it should do
the range comparison in the base type and use a VIEW_CONVERT_EXPR
to get to the object of the base type from the 5-bit-type to avoid VRP
optimizing
away the comparison.

Richard.

Re: conditional expression evaluation at compile time in gcc 4.01

[Richard Guenther]

On 2/22/06, Inder <[EMAIL PROTECTED]> wrote:
> Hi All
>
> I am trying to compile 'test.cc' (code attached) with the gcc 4.0.1
> it gives me the following error:
>
> test.cc:19: error: array bound is not an integer constant

Interestingly we end up with the C++ parser producing

  &0B->lengthD.1993 == (intD.2 *) (intD.2) &0B->lengthD.1986 ? 10 : 1

as non-constant expression (note the casts have been stripped on the
LHS of the comparison, not the RHS).  You should file a bugzilla for this
(or search for an existing one for this).

Richard.

Re: conditional expression evaluation at compile time in gcc 4.01

[Andrew Haley]

Inder writes:
 > Hi All
 > 
 > I am trying to compile 'test.cc' (code attached) with the gcc 4.0.1
 > it gives me the following error:
 > 
 > test.cc:19: error: array bound is not an integer constant
 > 
 > so it is not able to evaluate the conditional expression in gcc 4.0.1,
 > while this is being compile by gcc 3.4 without any errors.
 > 
 > Is this a bug in gcc 4.0.1
 > 
 > Any help will be appreciated.

my_offsetof isn't legal C++.  In addition:

5.19 Constant expressions 

In several places, C ++ requires expressions that evaluate to an
integral or enumeration constant: as array bounds (8.3.4, 5.3.4), ...

constant-expression:
conditional-expression

An integral constant-expression can involve only literals (2.13),
enumerators, const variables or static data members of integral or
enumeration types initialized with constant expressions (8.5),
non-type template parameters of integral or enumeration types, and
sizeof expressions.  Floating literals (2.13.3) can appear only if
they are cast to integral or enumeration types.  Only type conversions
to integral or enumeration types can be used.  In particular, except
in sizeof expressions, functions, class objects, pointers, or
references shall not be used, and assignment, increment, decrement,
function-call, or comma operators shall not be used.

Why don't you just use offsetof ?

Andrew.

Re: Ada subtypes and base types (was: Bootstrap failure on trunk: x86_64-linux-gnu)

[Laurent GUERBY]

On Wed, 2006-02-22 at 10:54 +0100, Richard Guenther wrote:
> > > > >  type T1 is range 0 .. 127;
> > > > >  -- Compiler will choose some type for T'Base, likely to be -128..127
> > > > >  -- but could be Integer (implementation dependant)
> > > > >  subtype T is T1 range 0 .. 100;
> > > > >  R : T := 100+X-X;
> > > > >  -- guaranteed work as long 100+X<=T'Base'Last and 100-X>=T'Base'First
> 
> Is the final "conversion" a checked conversion or an unchecked conversion?  
> I.e.
> are we supposed to check for overflow using 'Valid on the final result?  Or 
> will
> the value be truncated or a runtime error raised?

In the full language we are supposed to check the range on the
assignement and raise the predefined exception "CONSTRAINT_ERROR" if it
fails (whatever the way in the generated code). However GNAT by default
does not generate this kind of check, you need to add -gnato to the
compile flags.

Laurent

Re: Ada subtypes and base types

[Robert Dewar]

Richard Guenther wrote:

On 2/21/06, Richard Kenner <[EMAIL PROTECTED]> wrote:

 But if the values in there do not reflect the reality of what values
 are valid for the type, then I don't see how they can be generally
 useful -- that's my point.  We have two fields that are inaccurate,
 apparently on purpose, and as a result they are basically unusable.

No, they *do* reflect the "reality of what values are valid for the type".
The only glitch, which is not what we're talking about here, is that you have
to have a way to implement the language-defined test to see if the value is
valid or not.  However, the need to implement that relative-uncommon test
should't drive the basic methodology used to represent types.


As you mention in another post an invalid value can only occour (as in, being
not undefined behavior) with an unchecked conversion.


The use of the term invalid is confusing in connection
with Ada. Ada has two concepts of out of range values

  Invalid values. Caused most notably by uninitialized
  variables. Use of such values is generally not
  erroneous, but rather a bounded error with a small
  subset of reasonable outcomes (program termination,
  exception, or just use the value, but such use cannot
  cause erroneous behavior).

  Abnormal values, Caused e.g. by two tasks messing with
  a variable at the same time. Any use of an abnormal
  variable is erroneous.

The result of a bogus unchecked_conversion is impl defined.
For GNAT, in the case of discrete types, we say that such a
result is invalid rather than abnormal.

'Valid does not have to work for abnormal values, it must
work correctly for invalid values (in practice it will work
as expected for abnormal values).

  The Ada frontend

has to make sure then that for

  BaseType i;
  SubType x = (SubType)i;
// now the value stored in x may exceed its range
  if (Valid (x))
   ...

that for the Valid (x) test, a VIEW_CONVERT_EXPR is used to do the comparison(s)
in the BaseType again.  And using the VIEW_CONVERT_EXPR to tell the compiler
it cannot look through the cast and infer range information from the type of x.


Sounds exactly right to me.


Richard.

successful build of mingw hosted arm-elf GCC 4.1.0 RC1

[Dave Murphy]

output of config.guess

$ gcc-4.1.0-20060219/config.guess
i686-pc-mingw32

$ arm-elf-gcc -v
Using built-in specs.
Target: arm-elf
Configured with: ../../gcc-4.1.0-20060219/configure 
--enable-languages=c,c++ --with-cpu=arm7tdmi --enable-interwork 
--enable-multilib --with-gcc --with-gnu-ld --with-gnu-as --with-stabs 
--disable-shared --disable-threads --disable-win32-registry 
--disable-nls --disable-debug --disable-libmudflap --disable-libssp 
--target=arm-elf --with-newlib --prefix=e:/devkitPro/devkitARM -v

Thread model: single
gcc version 4.1.0 20060219 (prerelease) (devkitARM release 18)

built with binutils 2.16.1 and newlib 1.14.0

The resulting toolchain is building working binaries although slightly 
larger than the previous 2.16.1, 4.0.2, 1.13.0 combination I was using.

Re: Dead link http://gcc.gnu.org/install/build.html on http://gcc.gnu.org/install/

[Joseph S. Myers]

On Wed, 22 Feb 2006, Paolo Bonzini wrote:

> There's a requirement to not use footnotes in install.texi, apparently.  Also,
> I did not know about install.texi2html so I added a note on it.
> 
> Ok to install?

OK.

>  @c 1999, 2000, 2001, 2002, 2003, 2004, 2005 Free Software Foundation, Inc.

Remember of course when committing to update both copyright notices.

-- 
Joseph S. Myers   http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTED] (personal mail)
[EMAIL PROTECTED] (CodeSourcery mail)
[EMAIL PROTECTED] (Bugzilla assignments and CCs)

Re: Possible accept wrong code in C++?

[Ed Smith-Rowland]

Smith-Rowland, Edward M (Contractor) wrote:


All,

 


I have a template class:

 


template < class Datum, unsigned long Dim >

class DataGrid

{

...

public:

...

std::ostream &  write( std::ostream & output ) const;

...

};

 


I have a non-member operator overload:

 


On GCC-4.0 MacOSX I was able to get by with this:

 

inline std::ostream &  operator<<( std::ostream & output, const 
DataGrid & data_grid )


{

return  data_grid.write( output );

}

On GCC-3.4 Cygwin I needed:

 


template < class Datum, unsigned long Dim >

inline std::ostream &  operator<<( std::ostream & output, const 
DataGrid & data_grid )


{

return  data_grid.write( output );

}

 


I actually think that 3.4 is right!!!

Am I wrong?

 


I'll try mainline and 4.1 when I get back home.

 


Ed Smith-Rowland



It turns out I was using some old 4.1 snapshot rather than 4.0 when this 
strange code passed.


The operator overload without template stuff fails (correctly) for the 
latest 4.1 snap, 4.0.2, etc.


Nothing to see here, move along.

Ed

compile/install gcc

[Florian Radulescu]

Please I would need some instructions on how to compile and install gcc for 
Intel XScale.
Thank you,
Florian

Re: conditional expression evaluation at compile time in gcc 4.01

[Gabriel Dos Reis]

"Richard Guenther" <[EMAIL PROTECTED]> writes:

[...]

| You should file a bugzilla for this (or search for an existing one
| for this). 

why do you want him to fill a PR about that when his program isn't valid?

-- Gaby

Re: PATCH: [4.1/4.2 Regression]: Miscompiled FORTRAN program

[Richard Guenther]

On 2/17/06, H. J. Lu <[EMAIL PROTECTED]> wrote:
> On Thu, Feb 16, 2006 at 03:46:57PM -0800, James E Wilson wrote:
> > On Thu, 2006-02-16 at 14:46, H. J. Lu wrote:
> > > I took the liberty to fix the format issue on behalf of Denis. Is this
> > > OK for mainline?
> >
> > Yes, this looks good to me.
>
> I checked it in. Here is the testcase.

Would you please check that  in also?

Thanks,
Richard.

Re: [cp-patches] Re: .cvsignore in libjava/classpath

[Tom Tromey]

> "Volker" == Volker Reichelt <[EMAIL PROTECTED]> writes:

Volker> I didn't want to delete it myself, since I suspected something
Volker> like this.  Would somebody of the libjava maintainers take
Volker> care of this?

There didn't seem to be any reason to delete the .cvsignore files from
the classpath directory.  So we left them in on the theory that it is
a bit better to remain as close to upstream as possible.

Tom

Re: Bootstrap failure on trunk: x86_64-linux-gnu

[Jeffrey A Law]

On Wed, 2006-02-22 at 11:51 +0100, Richard Guenther wrote:
> On 2/21/06, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> > Jeffrey A Law wrote:
> >
> > > My feeling?  Absolutely, TYPE_MIN_VALUE and TYPE_MAX_VALUE should
> > > represent the set of values that an object of the type may hold.
> > > Any other definition effectively renders those values useless.
> >
> > I agree -- with the obvious caveat that it need not be the case that the
> > object actually have that value if the program has invoked undefined
> > behavior.  So, if you have an 5-bit type, stored in a byte, and you
> > manage to get 255 in that byte, and you read the value, you might see
> > 255 at runtime -- but only because your program was busted anyhow.
> 
> Right.  And if Ada wants to test for this condition using 'Valid, it should do
> the range comparison in the base type and use a VIEW_CONVERT_EXPR
> to get to the object of the base type from the 5-bit-type to avoid VRP
> optimizing away the comparison.
Agreed wholeheartedly.


Jeff

Re: Ada subtypes and base types

[Jeffrey A Law]

On Tue, 2006-02-21 at 18:20 -0500, Robert Dewar wrote:
> Laurent GUERBY wrote:
> 
> > You keep saying "brain damage", but please if you see a better design
> > (other than "forget about user range types" :), let us all know!
> 
> Actually I think everyone agrees on what is appropriate here. it is
> a matter of working out a clear view. I don't think there are any
> real disagreements, just some communication and documentation issues.
> (as well as making sure we don't lose conversions we need!)
Actually, I don't think we have an agreement on whether or not
TYPE_MIN_VALUE/TYPE_MAX_VALUE should cover the entire range of
values that can be assigned to a particular object.

Most of the other stuff discussed so far is background material to
that ultimate issue IMHO.

Jeff

Re: Dead link http://gcc.gnu.org/install/build.html on http://gcc.gnu.org/install/

[Gerald Pfeifer]

Hi Paolo,

thanks for the patch.  I just saw Joseph's okay, but I believe there
is one minor detail left.

On Wed, 22 Feb 2006, Paolo Bonzini wrote:
> +GNU Make 3.79 and above, which is necessary to build GCC, support
> +building in parallel.

Specifically, in the sentence above we have "which is" (singular)
versus "support" (plural) which confused me a bit when first reading
the change.

Joseph as a native speaker will be in a much better position to advise
whether to use singular or plural here, but I believe the two uses should
be in sync.

Gerald

Re: Bootstrap failure on trunk: x86_64-linux-gnu

[Jeffrey A Law]

On Tue, 2006-02-21 at 14:56 -0800, Mark Mitchell wrote:
> Jeffrey A Law wrote:
> 
> > My feeling?  Absolutely, TYPE_MIN_VALUE and TYPE_MAX_VALUE should
> > represent the set of values that an object of the type may hold.
> > Any other definition effectively renders those values useless.
> 
> I agree -- with the obvious caveat that it need not be the case that the
> object actually have that value if the program has invoked undefined
> behavior.  So, if you have an 5-bit type, stored in a byte, and you
> manage to get 255 in that byte, and you read the value, you might see
> 255 at runtime -- but only because your program was busted anyhow.
Right.

This does highlight one of the issues that keeps nagging at me.
For an enumeration type, presumably we have TYPE_PRECISION set to
the minimum precision necessary to hold all the values in the enum.
What are TYPE_MIN_VAL/TYPE_MAX_VAL?Does TYPE_MAX_VALUE include
values outside the enum, but which are included by the TYPE_PRECISION?

Consider

enum
{
  RED,
  GREEN,
  BLUE,
  BLACK,
  WHITE
}


for (color = RED; color <= WHITE; color++)

Now we might think that color is constrained to the values
RED .. WHITE.  However at runtime we can actually get
RED .. WHITE + 1.  Does TYPE_MAX_VALUE cover WHITE + 1?

If not, then we've got more latent bugs waiting to nail us.

It'll be simple enough to check, but if someone knows the
answer off the top of their head it would save me a few minutes
of investigative work.

jeff

Re: Dead link http://gcc.gnu.org/install/build.html on http://gcc.gnu.org/install/

[Paolo Bonzini]

Gerald Pfeifer wrote:

Hi Paolo,

thanks for the patch.  I just saw Joseph's okay, but I believe there
is one minor detail left.

On Wed, 22 Feb 2006, Paolo Bonzini wrote:
  

+GNU Make 3.79 and above, which is necessary to build GCC, support
+building in parallel.



Specifically, in the sentence above we have "which is" (singular)
versus "support" (plural) which confused me a bit when first reading
the change.

Joseph as a native speaker will be in a much better position to advise
whether to use singular or plural here, but I believe the two uses should
be in sync.
  

If rephrasing the sentence as

GNU Make supports building in parallel starting from version 3.79, which 
is anyway necessary to build GCC.


is ok, I'm pretty sure this is correct ("which" refers to "version").

Paolo

Re: Ada subtypes and base types

[Robert Dewar]

Jeffrey A Law wrote:


TYPE_MIN_VALUE/TYPE_MAX_VALUE should cover the entire range of
values that can be assigned to a particular object.


Do you mean assigned as in "with an assignment statement", or do
you mean "end up in the object by any mechanism"?


Most of the other stuff discussed so far is background material to
that ultimate issue IMHO.

Jeff

Re: Ada subtypes and base types

[Jeffrey A Law]

On Tue, 2006-02-21 at 17:22 -0500, Richard Kenner wrote:
>  Given an expression, we have to do computations in some other type than
>  the type of the expression? Now that's just silly.  
> 
> Sure, but that's not what I said.
> 
>  If the expression has some type X, then we should be doing our
>  computations in type X.  
> 
> Right.
> 
> Let me try again and take a simpler example.  If we have
> 
>   subtype T is Integer range 20..50;
> 
>   Y: T;
> 
>  ... Y + 1 ...
> 
> What the tree looks like is a PLUS_EXPR of type "Integer" (the base type of
> T), not T, whose first operand is a NOP_EXPR converting Y to Integer and
> whose second operand is the constant 1 also of type Integer, not T.
In a gimplified tree, for nodes such as PLUS_EXPR, the type
of the inputs, the type of the expression and the type of the
result are all one and the same.  Any input conversions occur
before the arithmetic statement and any output conversions 
occur after the arithmetic statement.  ie, within the statement
we are type consistent.  I think we're in agreement about that.

When I speak about doing arithmetic in a type, I'm referring to the
type of the expression & its input operands in a gimplified expression.
At that point I do not care about base types or anything like that.
All that should matter is TREE_TYPE (expr), nothing more, nothing
less.How the inputs are converted or how the output is later
converted is not a concern -- all that matters is TREE_TYPE (expr)
in a gimplified tree.

Can we agree on that?

jef

Re: Ada subtypes and base types

[Jeffrey A Law]

On Tue, 2006-02-21 at 18:11 -0500, Robert Dewar wrote:
> Richard Kenner wrote:
> 
> > Let me try again and take a simpler example.  If we have
> > 
> > subtype T is Integer range 20..50;
> > 
> > Y: T;
> > 
> >... Y + 1 ...
> > 
> > What the tree looks like is a PLUS_EXPR of type "Integer" (the base type of
> > T), not T, whose first operand is a NOP_EXPR converting Y to Integer and
> > whose second operand is the constant 1 also of type Integer, not T.
> 
> Note that this *exactly* reflects the formal Ada semantics ...
And that's not what's at issue here.  We agreed on this some time
ago.  The nop-conversions are a necessary requirement to implement
Ada semantics and those nop conversions are and need to be explicit
in the IL.

Assuming the NOP conversions are explicit statements in the IL
(as they are by the time VRP runs), then within an expression we
are type consistent.  ie, TREE_TYPE (expr) == TREE_TYPE (op0) ==
TREE_TYPE (op1) where op0 & op1 are either SSA_NAMEs or invariants.
Furthermore, the operation specified by expr is to be carried out
in TREE_TYPE (expr).

Jeff

Re: Ada subtypes and base types (was: Bootstrap failure on trunk: x86_64-linux-gnu)

[Jeffrey A Law]

On Mon, 2006-02-20 at 23:00 +0100, Richard Guenther wrote:
> On 2/20/06, Richard Kenner <[EMAIL PROTECTED]> wrote:
> >  Indeed.  Ada should in this case generate
> >
> >R = (T)( (basetype)100 + (basetype)X - (basetype)X )
> >
> >  i.e. carry out all arithmetic explicitly in the basetype and only for
> >  stores and loads use the subtype.
> >
> > That is indeed required by the language and what is normally generated.
> > It would be valuable to see exactly who generated the bogus operation.
> >
> 
> Indeed - I can very well imagine fold or ccp stripping off such type 
> conversions
> in some case, which would lead to wrong code by VRP.
Again, so can I, so it's a concern.  However, I'm pretty sure that's
not what's happening here.  If you disable the code to strip away
useless type conversions you still get the same problem.

jeff

RE: Dead link http://gcc.gnu.org/install/build.html on http://gcc.gnu.org/install/

[Dave Korn]

On 22 February 2006 16:40, Paolo Bonzini wrote:

> Gerald Pfeifer wrote:
>> Hi Paolo,
>> 
>> thanks for the patch.  I just saw Joseph's okay, but I believe there
>> is one minor detail left.
>> 
>> On Wed, 22 Feb 2006, Paolo Bonzini wrote:
>> 
>>> +GNU Make 3.79 and above, which is necessary to build GCC, support
>>> +building in parallel. 
>>> 
>> 
>> Specifically, in the sentence above we have "which is" (singular)
>> versus "support" (plural) which confused me a bit when first reading
>> the change.
>> 
>> Joseph as a native speaker will be in a much better position to advise
>> whether to use singular or plural here, but I believe the two uses should
>> be in sync. 
>> 
> If rephrasing the sentence as
> 
> GNU Make supports building in parallel starting from version 3.79, which
> is anyway necessary to build GCC.
> 
> is ok, I'm pretty sure this is correct ("which" refers to "version").
> 
> Paolo


  Yep, I think the clearest way to rephrase it would be

GNU Make 3.79 (which is the minimum version required to build GCC) and above,
support building in parallel. 

thereby removing the confusion between the requirement (singular) and the set
of versions that fulfill that requirement (plural).


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

Re: Bootstrap failure on trunk: x86_64-linux-gnu

[Mark Mitchell]

Jeffrey A Law wrote:

> This does highlight one of the issues that keeps nagging at me.
> For an enumeration type, presumably we have TYPE_PRECISION set to
> the minimum precision necessary to hold all the values in the enum.
> What are TYPE_MIN_VAL/TYPE_MAX_VAL?Does TYPE_MAX_VALUE include
> values outside the enum, but which are included by the TYPE_PRECISION?

In C++, there are no such values.  In C++, the range of the type gets
rounded up to a power of two, so for:

> Consider
> 
> enum
> {
>   RED,
>   GREEN,
>   BLUE,
>   BLACK,
>   WHITE
> }

you can happily assign "5" to this enum.  The C++ front end correctly
sets TYPE_MAX_VALUE in this case.

I'm not sure what the situation is in C.

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

Re: Ada subtypes and base types

[Jeffrey A Law]

On Tue, 2006-02-21 at 23:23 +0100, Laurent GUERBY wrote:
> On Tue, 2006-02-21 at 15:02 -0700, Jeffrey A Law wrote:
> > Given an expression, we have to do computations in some other type than
> > the type of the expression? Now that's just silly.  If the expression
> > has some type X, then we should be doing our computations in type X.
> 
> That would obviously lead to very inefficient implementation if you
> put that in a language with user range types and bound checking since it
> would force a dynamic bound check after each operation.
I'm saying nothing about where/when bounds checking occurs -- 
Ada is free to insert bounds checking wherever it is necessary
to impelment Ada semantics.


In our trees, if I have
PLUS_EXPR 

That says very simply to add X & Y in type TYPE -- anything else
is wrong.  If our Ada front-end assumes something different, then
that is braindamage in our Ada front-end.

Note carefully I'm saying absolutely nothing about ignoring
user range types, I'm saying nothing about where you insert
bounds checking.  I'm saying that within an arithmetic expression
the type of the expression specifies the type in which the
arithmetic will occur.

Jeff

Re: Bootstrap failure on trunk: x86_64-linux-gnu

[Jeffrey A Law]

On Wed, 2006-02-22 at 09:00 -0800, Mark Mitchell wrote:
> Jeffrey A Law wrote:
> 
> > This does highlight one of the issues that keeps nagging at me.
> > For an enumeration type, presumably we have TYPE_PRECISION set to
> > the minimum precision necessary to hold all the values in the enum.
> > What are TYPE_MIN_VAL/TYPE_MAX_VAL?Does TYPE_MAX_VALUE include
> > values outside the enum, but which are included by the TYPE_PRECISION?
> 
> In C++, there are no such values.  In C++, the range of the type gets
> rounded up to a power of two, so for:
Great.  That's what I expected to hear.  Hopefully the C 
front end does something similar.

Jeff

Re: Ada subtypes and base types

[Richard Kenner]

 When I speak about doing arithmetic in a type, I'm referring to the
 type of the expression & its input operands in a gimplified
 expression.  At that point I do not care about base types or anything
 like that.  All that should matter is TREE_TYPE (expr), nothing more,
 nothing less.  How the inputs are converted or how the output is later
 converted is not a concern -- all that matters is TREE_TYPE (expr) in
 a gimplified tree.

 Can we agree on that?

Yes.

The base type reference is that I'm *also* saying "If you see an arithmetic
node where TREE_TYPE is *not* a base type, there's a bug someplace that
has to be fixed". (Well, with the exception of such things as sizetypes
or subtypes that don't actually change anything.)

Is there an attribute or pragma to disable optimization for a single function?

[Ian S. Nelson]

It looks like there are attributes to help optimize some functions
further but are there any to not optimize at all?


thanks,
Ian


-- 


*Ian S. Nelson
PGP/GPG 
email preferred.
Public Key: 00D3D983

Fingerprint: 3EFD7B86B888D7E229B69E97576F1B9700D3D983 *

4.1rc1 cross Ada build issue

[Joel Sherrill]

Hi,

I think/thought this has been dealt with
but am not sure.  I started with a fresh install
directory, built and installed a native GNU/Linux
C, C++, and Ada toolset.  Then proceeded to
try to build cross Ada for *-rtems.  All targets
are failing because they are not finding newlib's
.h files in the source tree while building.

Hasn't this been fixed before?  Is there a missing
fix to merge onto the branch?

--joel

Re: Ada subtypes and base types

[Jeffrey A Law]

On Wed, 2006-02-22 at 13:25 -0500, Richard Kenner wrote:
> The base type reference is that I'm *also* saying "If you see an arithmetic
> node where TREE_TYPE is *not* a base type, there's a bug someplace that
> has to be fixed". (Well, with the exception of such things as sizetypes
> or subtypes that don't actually change anything.)
Ok.  That's actually good to know and something worth investigating.
Thanks,
Jeff

Re: compile/install gcc

[Mike Stump]

On Feb 22, 2006, at 6:46 AM, Florian Radulescu wrote:
Please I would need some instructions on how to compile and install  
gcc for Intel XScale.


You would need to use google to find the gcc documentation that  
describes this in detail.  If you do that, you should find http:// 
gcc.gnu.org/install/


Also, if you google around, you can find additional resources like  
http://www.mega-tokyo.com/osfaq2/index.php/GCC%20Cross-Compiler which  
I had never seen before, but seems to be the type of thing that might  
just be what you're looking for.


gcc-help is the right mailing list for questions.

Re: Is there an attribute or pragma to disable optimization for a single function?

[Mike Stump]

On Feb 22, 2006, at 10:24 AM, Ian S. Nelson wrote:

It looks like there are attributes to help optimize some functions
further but are there any to not optimize at all?


In general, no; however, Dale did up a patch to control this sort of  
thing from #pragma if you want to dust it off and adapt it for your  
needs (and submit it).

Re: Is there an attribute or pragma to disable optimization for a single function?

[Devang Patel]

On 2/22/06, Mike Stump <[EMAIL PROTECTED]> wrote:
> On Feb 22, 2006, at 10:24 AM, Ian S. Nelson wrote:
> > It looks like there are attributes to help optimize some functions
> > further but are there any to not optimize at all?
>
> In general, no; however, Dale did up a patch to control this sort of
> thing from #pragma if you want to dust it off and adapt it for your
> needs (and submit it).

Just to avoid confusion...

GCC distributed and maintained by FSF volunteers (aka official GCC)
does not have this support. However, this support is available in a
development branch used and maintained by Apple. As expected and just
like any other vender branch, this development branch is tested and
maintained for Apple platforms.

If you're a compiler developer OR ready to spend time to add this
feature in GCC yourself then take a look at this implementation and
make it suitable for official GCC.

However, if you're a software developer, looking for a feature in GCC
tools you use, then I suggest that you atleast file a bugzilla request
(gcc.gnu.org/bugzilla) for this feature. If enough people are
interested then one of the regular gcc developer may be motivated to
make this feature available in official GCC.

-
Devang

Re: Is there an attribute or pragma to disable optimization for a single function?

[Andrew Pinski]

> 
> On 2/22/06, Mike Stump <[EMAIL PROTECTED]> wrote:
> > On Feb 22, 2006, at 10:24 AM, Ian S. Nelson wrote:
> > > It looks like there are attributes to help optimize some functions
> > > further but are there any to not optimize at all?
> >
> > In general, no; however, Dale did up a patch to control this sort of
> > thing from #pragma if you want to dust it off and adapt it for your
> > needs (and submit it).
> 
> Just to avoid confusion...
> 
> GCC distributed and maintained by FSF volunteers (aka official GCC)
> does not have this support. However, this support is available in a
> development branch used and maintained by Apple. As expected and just
> like any other vender branch, this development branch is tested and
> maintained for Apple platforms.
> 
> If you're a compiler developer OR ready to spend time to add this
> feature in GCC yourself then take a look at this implementation and
> make it suitable for official GCC.

Just a note from the person who keeps tabs on a lot of stuff.  There
is already a project which is written or started to write to do this.
See http://gcc.gnu.org/wiki/Function%20Level%20Control%20of%20Optimizations.

Thanks,
Andrew Pinski

Re: Is there an attribute or pragma to disable optimization for a single function?

[Devang Patel]

On 2/22/06, Andrew Pinski <[EMAIL PROTECTED]> wrote:
>
> Just a note from the person who keeps tabs on a lot of stuff.  There
> is already a project which is written or started to write to do this.
> See http://gcc.gnu.org/wiki/Function%20Level%20Control%20of%20Optimizations.

I did not know about this page. Thanks!

-
Devang

ANNOUNCE: GCC track at Gelato ICE conference

[Mark K. Smith]

Dear GCC Community,

I wanted to let the GCC list know that the Gelato Federation is
holding a conference April 24-26 in San Jose. It is called Gelato ICE
(Itanium Conference & Expo). http://www.gelato.org/meeting 

The technical program is very robust (over 50 technical presentations)
covering a variety of Itanium-related topics: compilers, architecture,
reliability, security, java, virtualization, kernel, memory
management, and high-performance libraries to name a few. 

Of particular interest to this group are the compiler
presentations/sessions. Currently there are ten presentations
scheduled for the GCC track:

* LLVM - Chris Lattner 
* LTO - Mark Mitchell 
* Aliasing update - Dan Berlin
* Parallel programming with GCC - Diego Novillo
* ORC back end for GCC - Shin-Ming Liu 
* Superblock work - Bob Kidd 
* Russian Academy of Science scheduler improvement update - Andrey
Belevantsev and Arutyun Avetisyan
* Intel micro-architecture talk - Cameron McNairy
* Spec2006 - Gerolf Hoflehner (provided Spec2006 has been release at
conference time)
* GCC IP issues - Dan Berlin

We also have a round table scheduled with the Intel icc compiler team
and a talk on icc changes related to Montecito. Montecito is the next
generation of Itanium  due out in a few months.

Everyone is welcome to attend. Check http://www.gelato.org/meeting for
more details.

Mark

Re: Upated memory hog patch for make

[Gerald Pfeifer]

On Mon, 20 Feb 2006, H. J. Lu wrote:
> 3.81rc1 works much better than 3.80. But my patch for 3.80 no longer
> applies cleanly. Paul is aware of the libjava build problem and is
> working on it.

That's good news, thanks!  I'll give 3.81 RC1 a try, and hope we'll
have a release soon...

Gerald

question about pic and relocation

[Eric Fisher]

Hi,
Given such a source file,
/*fun.c*/
int b=2;
void fun(void)
{
  int a=b;
}

Then compile it,
$ mips-elf-gcc -shared -fpic fun.c -o fun.so -save-temps

We can see this below from fun.s,
lw  $2,%gp_rel(b)($28)

I think symble 'b' should be of GOT relocation.
But it isn't.

$ mips-elf-readelf -r fun.so

readelf: Error: Unable to read in 264144 bytes of dynamic segment

Relocation section '.rel.dyn' at offset 0x580 contains 2 entries:
 Offset InfoTypeSym.Value  Sym. Name
   R_MIPS_NONE
600207a0  0003 R_MIPS_REL32

I have no idea about the error and the symble 'b' of pic codes.
Yet, when use this below
$ mips-elf-as fun.s -call_shared -o fun.so

$ mips-elf-readelf -r fun.so

Relocation section '.rel.text' at offset 0x3bc contains 1 entries:
 Offset InfoTypeSym.Value  Sym. Name
000c  0907 R_MIPS_GPREL16   b

Relocation section '.rel.pdr' at offset 0x3c4 contains 1 entries:
 Offset InfoTypeSym.Value  Sym. Name
  0a02 R_MIPS_32    fun

What's the reason? Seems mips gcc doesn't create GOT relacation.

Thanks.

Re: question about pic and relocation

[Daniel Jacobowitz]

On Thu, Feb 23, 2006 at 01:33:05PM +0800, Eric Fisher wrote:
> $ mips-elf-gcc -shared -fpic fun.c -o fun.so -save-temps
> 
> We can see this below from fun.s,
> lw  $2,%gp_rel(b)($28)
> 
> I think symble 'b' should be of GOT relocation.
> But it isn't.
> 
> $ mips-elf-readelf -r fun.so

There are no GOT relocations in shared libraries.  They're resolved by
the linker.

> I have no idea about the error and the symble 'b' of pic codes.
> Yet, when use this below
> $ mips-elf-as fun.s -call_shared -o fun.so
> 
> $ mips-elf-readelf -r fun.so

That's not a shared object, no matter what you call it.  You have to
assemble and then link; please let GCC do the linking, it knows how
to invoke the linker properly for each platform.

-- 
Daniel Jacobowitz
CodeSourcery

Re: question about pic and relocation

[Eric Fisher]

But flag '-shared' and '-fpic' are used to create shared object,
aren't they? When I use objdump to see the codes, I find that the
program address doesn't start from 0. Such as,
5ffe065c :
5ffe065c:   3c02lui v0,0x0
5ffe0660:   27bdffe8addiu   sp,sp,-24
5ffe0664:   3c046002lui a0,0x6002
5ffe0668:   3c056002lui a1,0x6002
5ffe066c:   2442addiu   v0,v0,0
5ffe0670:   afbf0010sw  ra,16(sp)
5ffe0674:   248407a4addiu   a0,a0,1956
5ffe0678:   1043beqzv0,5ffe0688 
5ffe067c:   24a508d8addiu   a1,a1,2264
5ffe0680:   0c00jal 5000 <_init-0xffe0590>
5ffe0684:   nop
5ffe0688:   3c046002lui a0,0x6002
5ffe068c:   8c8208a0lw  v0,2208(a0)
5ffe0690:   nop
5ffe0694:   1047beqzv0,5ffe06b4 

Why? And the symble 'b' is of absolute type(*A*)?

2006/2/23, Daniel Jacobowitz <[EMAIL PROTECTED]>:
> On Thu, Feb 23, 2006 at 01:33:05PM +0800, Eric Fisher wrote:
> > $ mips-elf-gcc -shared -fpic fun.c -o fun.so -save-temps
> >
> > We can see this below from fun.s,
> > lw  $2,%gp_rel(b)($28)
> >
> > I think symble 'b' should be of GOT relocation.
> > But it isn't.
> >
> > $ mips-elf-readelf -r fun.so
>
> There are no GOT relocations in shared libraries.  They're resolved by
> the linker.
>
> > I have no idea about the error and the symble 'b' of pic codes.
> > Yet, when use this below
> > $ mips-elf-as fun.s -call_shared -o fun.so
> >
> > $ mips-elf-readelf -r fun.so
>
> That's not a shared object, no matter what you call it.  You have to
> assemble and then link; please let GCC do the linking, it knows how
> to invoke the linker properly for each platform.
>
> --
> Daniel Jacobowitz
> CodeSourcery
>

Re: Ada subtypes and base types (was: Bootstrap failure on trunk: x86_64-linux-gnu)

[Duncan Sands]

Hi Laurent,

On Wednesday 22 February 2006 12:34, Laurent GUERBY wrote:
> On Wed, 2006-02-22 at 10:54 +0100, Richard Guenther wrote:
> > > > > >  type T1 is range 0 .. 127;
> > > > > >  -- Compiler will choose some type for T'Base, likely to be 
> > > > > > -128..127
> > > > > >  -- but could be Integer (implementation dependant)
> > > > > >  subtype T is T1 range 0 .. 100;
> > > > > >  R : T := 100+X-X;
> > > > > >  -- guaranteed work as long 100+X<=T'Base'Last and 
> > > > > > 100-X>=T'Base'First
> > 
> > Is the final "conversion" a checked conversion or an unchecked conversion?  
> > I.e.
> > are we supposed to check for overflow using 'Valid on the final result?  Or 
> > will
> > the value be truncated or a runtime error raised?
> 
> In the full language we are supposed to check the range on the
> assignement and raise the predefined exception "CONSTRAINT_ERROR" if it
> fails (whatever the way in the generated code). However GNAT by default
> does not generate this kind of check, you need to add -gnato to the
> compile flags.

my understanding is that -gnato causes the compiler to insert checks that the
"100+X-X" computation does not overflow the base type.  The compiler always
inserts a check that the result is in the range of the target type T before
performing the assignment, regardless of whether -gnato is set or not.

Best wishes,

Duncan.