Re: GCC 4.1 RC2

[Mark Mitchell]

Paolo Bonzini wrote:
> Mark Mitchell wrote:
>> I will spin GCC 4.1 RC2 tonight.
>>
>> The only patch I plan to apply, relative to current sources, is Paolo
>> Bonzini's Ada patch.
> 
> ... which is revision 108058.  I gather that you want to apply it yourself?

Already done.

Thanks!

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

Re: Ada subtypes and base types

[Richard Guenther]

On 2/24/06, Jeffrey A Law <[EMAIL PROTECTED]> wrote:
> On Wed, 2006-02-22 at 13:25 -0500, Richard Kenner wrote:
> >  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.)
> Just to make sure I've dotted the i's and crossed the t's, this
> is not what's happening when we hang in VRP when compiling a-textio.
>
> We convert the incoming object from natural___XDLU_0___2147483647
> into its base type, perform the addition in the base type, then
> convert back to XDLU_0_2147483647.

Which is exactly what I would expect, i.e. fine.  So VRP can assume for

 (XDLU..) ( (base) a + (base) b )

that a and b have values in the range of natural ___XDLU_0___2147483647,
the sum is in range of the base type and this result get's truncated again to
___XDLU_0___2147483647.

Which is my understanding of Ada semantics.  There is nothing in Ada semantics
as far as I understand that requires possible overflow to be preserved
until after
the cast to (XDLU..) for checking with 'Valid - if there is, Ada needs to use an
explicit unchecked conversion which again has to be implemented using a
VIEW_CONVERT_EXPR.

Any other semantics don't make sense, so the middle-end ought to use these
semantics and bugs in the middle-end and the Ada frontend uncovered by it
fixed.  Better soon than later.

Richard.

static inline function body is missing

[Nemanja Popov]

Hi all,

In my GCC 4.02 port for DLX cpu I'm expiriencing strange problem.
When compiling following example:

static inline int bar(void)
{
 return 1;
}

int main()
{
 int i = 0;

 i = bar();

 return i;
}


with the following line
dlx-elf-gcc -S foo.c

there is no bar() function body, but there is call of that function in 
main().


Code is correct (bar() function body is there) when compiling with the 
following line:


dlx-elf-gcc -S foo.c -funit-at-a-time

Is it possible to workaround this problem in my port files.

Thanks in advance,
Nemanja Popov 

Re: IVOPTS vs Ada subtypes and base types

[Sebastian Pop]

Jeffrey A Law wrote:
> 
> Note how the conversions have been lost.
> 

This is a bug in chrec_convert_aggressive.

The following patch fixes the problem in a quite drastic way,
disabling the analysis of ivs that contain casts in their induction.

Index: tree-scalar-evolution.c
===
--- tree-scalar-evolution.c (revision 111416)
+++ tree-scalar-evolution.c (working copy)
@@ -1057,8 +1057,9 @@ follow_ssa_edge_in_rhs (struct loop *loo
   /* This assignment is under the form "a_1 = (cast) rhs.  */
   res = follow_ssa_edge_in_rhs (loop, at_stmt, TREE_OPERAND (rhs, 0),
halting_phi, evolution_of_loop, limit);
-  *evolution_of_loop = chrec_convert (TREE_TYPE (rhs),
- *evolution_of_loop, at_stmt);
+  if (res == t_true)  
+   *evolution_of_loop = chrec_dont_know;
+
   break;
 
 case INTEGER_CST:



If we keep the conversions without performing the conversion, ie. the
next patch, later on we get the call to chrec_convert_aggressive that
will remove all the type casts, resulting in the endless loop.

Index: tree-scalar-evolution.c
===
--- tree-scalar-evolution.c (revision 111416)
+++ tree-scalar-evolution.c (working copy)
@@ -1057,8 +1057,9 @@ follow_ssa_edge_in_rhs (struct loop *loo
   /* This assignment is under the form "a_1 = (cast) rhs.  */
   res = follow_ssa_edge_in_rhs (loop, at_stmt, TREE_OPERAND (rhs, 0),
halting_phi, evolution_of_loop, limit);
-  *evolution_of_loop = chrec_convert (TREE_TYPE (rhs),
- *evolution_of_loop, at_stmt);
+  if (res == t_true)
+   *evolution_of_loop = build1 (NOP_EXPR, TREE_TYPE (rhs),
+*evolution_of_loop);
   break;
 
 case INTEGER_CST:

pointer member constant expression

[Perry Smith]

I have asked this question before -- maybe to the gcc-help list but  
I'm still unclear.


The problem is this:

struct foo {
int a;
int b;
int c;
};

static const int foo::*j = &foo::c; // accepted

class dog {
static const int foo::*k = &foo::c; // error
};

5.19 (constant expressions) paragraph 2, the last item in the 1998 C+ 
+ spec says " -- a pointer to member constant expression."  That  
appears to be defined as: '&' qualified-id (5.19 paragraph 6).


So is the line in error legal C++ or not?

Thanks,
Perry

Re: pointer member constant expression

[Richard Guenther]

On 2/24/06, Perry Smith <[EMAIL PROTECTED]> wrote:
> I have asked this question before -- maybe to the gcc-help list but
> I'm still unclear.
>
> The problem is this:
>
> struct foo {
>  int a;
>  int b;
>  int c;
> };
>
> static const int foo::*j = &foo::c; // accepted
>
> class dog {
>  static const int foo::*k = &foo::c;// error
> };
>
> 5.19 (constant expressions) paragraph 2, the last item in the 1998 C+
> + spec says " -- a pointer to member constant expression."  That
> appears to be defined as: '&' qualified-id (5.19 paragraph 6).
>
> So is the line in error legal C++ or not?

No.

t.C:10: error: 'foo::c' cannot appear in a constant-expression
t.C:10: error: `&' cannot appear in a constant-expression
t.C:10: error: invalid in-class initialization of static data member
of non-integral type 'const int foo::*'

use

class dog {
static const int foo::*k;
};
const int foo::*dog::k = &foo::c;

Richard.


> Thanks,
> Perry
>
>

information request about generated trees during gcc process

[Bruno GALLEGGIANTI - LLSP]

Hi,

My name is Bruno Galleggianti and I am working for the CEA, a French 
research center.
I'm looking for tools that can generate AST (Abstract Syntax Tree) from 
C files.


I have found with gcc toolchain the option -dump-tree-original. The 
generated files are very interresting for me and I think they can be 
exploited for my project.


But before starting development, I need some information about the 
generated GENERIC tree:
1) Have you an history version (based on gcc releases) about this option 
(in fact, an history of all -fdump-tree-* options)?
2) Have you a text file format of the grammar of the generated tree and 
documentations that describe precisely each fields of tree nodes?
3) Do you know any limitations with this option? The gcc internal 
documentation refers about limitations with goto instruction in GIMPLE 
tree!
4) Have you a paper or information that explain when and how during the 
compilation the GENERIC tree is generated?


Thank you for your help

Regards

Bruno Galleggianti

STUDENTS WANTED: Home Inspection training and certification prep starts Mar 4 and Mar 13: IRC Building code class starts Mar 7

[admin]

 

 **/EARLY BIRD DISCOUNTS. //HOME INSPECTION AND BUILDING CODE
CERTIFICATION COURSES/**

 ** select the course that works for you **

 A training and resource facility for home inspectors, 
 builders and home owners. 
 **contact us http://www.InspectorsUSA.com
**

 Call Stan A. Garnet @ 770-512-8228 or Carita Ferrell @ 770-552-1224
or 
email: [EMAIL PROTECTED]


 **Winter 2006 Professional courses**

 ** Inspection courses **

 INTRODUCTION TO PROFESSIONAL HOME INSPECTING AND THE NATIONAL HOME
INSPECTOR TEST PREPARATION



 Next Weekend class starts * March 4, April 1*
Next One Week Fast track class starts *March 13, April 3*

COMMERCIAL PROPERTY INSPECTOR

The next class starts *May 4*

 **BUILDING CODES **

 IRC BUILDING CODE

The next class starts *March 7, April 22*

 BUILDER CONTRACTOR "C"

The next class starts *March 20*

PRACTICAL CODE APPLICATION FOR BUILDERS AND INSPECTORS

The next class starts *March 24*

 IRC PLUMBING CODE

The next class starts *FEB 18*

IRC ELECTRICAL CODE

The next class starts *Mar 18*

IRC MECHANICAL CODE

The next class starts *Mar 7*

HOW TO PASS THE IRC CODE EXAMS

The next class starts *April 3*

 **ROOFING **

 LEARN MORE ABOUT ROOFS AND WHAT TO LOOK FOR

The next class starts *May 31*

 **STRUCTURE **

 IS THE HOME STRUCTURALLY SOUND? RED FLAGS TO LOOK FOR

The next class starts *(To be Announced)*

 **ELECTRICAL **

 HOW TO PERFORM AN ELECTRICAL INSPECTION

The next class starts *Mar 17*

 Class sizes will be limited. Register early. 

 **WEATHER WRAP AND BARRIERS**

 Weather resistive barriers and flashing installation and integration

Learn the correct application techniques and how to integrate
different materials. Wall sections are utilized for hands on
demonstrations along with pictorial imaging. 

Presented by: Ben Mauldin, Tyvek

 **quick links**

 Class Calendar


 Directions to Campus


 Professional Education


 Homeowner Classes


 We will train at your facility or ours. 

 We will custom create a presentation to fit your individual needs.
Let us know your needs. 

 Discount price if paid with Cash, Check or Money Order at time of
registration. Easy payment plans provided by We Teach House. Call for
deferred payment pricing and plan. Register early and save $$$. 

 Our training is provided by We Teach House Institute, located in
Roswell, Georgia. All of our instructors are Building Code Certified
in one or more disciplines. Have a minimum of 10 years experience in
property inspections and or have received specialized training in
their field of instruction. 

 Didn't find all your answers?
Click here..


 We Teach House
339 S. Atlanta St
Roswell, GA 30075

 770-552-1224

 Our campus is located in Historic Roswell Georgia. Click for
directions


 Inspectors Associates, Inc. d/b/a We Teach House

 Contact Stan Garnet: [EMAIL PROTECTED]
 Phone: 770-512-8228 Fax: 770-512-8078 

 Click here to be removed from the mailing list: www.iainews.com




--
If you do not wish to receive any more information on our courses or our
newsletters then please click here. 
http://iainews.com/?p=unsubscribe&uid=95404bd60ef13faa201c9a8ede8c5f17

To update your preferences please visit
http://iainews.com/?p=preferences&uid=95404bd60ef13faa201c9a8ede8c5f17



--
Powered by PHPlist, www.phplist.com --

STUDENTS WANTED: Home Inspection training and certification prep starts Mar 4 and Mar 13: IRC Building code class starts Mar 7

[admin]

 

 **/EARLY BIRD DISCOUNTS. //HOME INSPECTION AND BUILDING CODE
CERTIFICATION COURSES/**

 ** select the course that works for you **

 A training and resource facility for home inspectors, 
 builders and home owners. 
 **contact us http://www.InspectorsUSA.com
**

 Call Stan A. Garnet @ 770-512-8228 or Carita Ferrell @ 770-552-1224
or 
email: [EMAIL PROTECTED]


 **Winter 2006 Professional courses**

 ** Inspection courses **

 INTRODUCTION TO PROFESSIONAL HOME INSPECTING AND THE NATIONAL HOME
INSPECTOR TEST PREPARATION



 Next Weekend class starts * March 4, April 1*
Next One Week Fast track class starts *March 13, April 3*

COMMERCIAL PROPERTY INSPECTOR

The next class starts *May 4*

 **BUILDING CODES **

 IRC BUILDING CODE

The next class starts *March 7, April 22*

 BUILDER CONTRACTOR "C"

The next class starts *March 20*

PRACTICAL CODE APPLICATION FOR BUILDERS AND INSPECTORS

The next class starts *March 24*

 IRC PLUMBING CODE

The next class starts *FEB 18*

IRC ELECTRICAL CODE

The next class starts *Mar 18*

IRC MECHANICAL CODE

The next class starts *Mar 7*

HOW TO PASS THE IRC CODE EXAMS

The next class starts *April 3*

 **ROOFING **

 LEARN MORE ABOUT ROOFS AND WHAT TO LOOK FOR

The next class starts *May 31*

 **STRUCTURE **

 IS THE HOME STRUCTURALLY SOUND? RED FLAGS TO LOOK FOR

The next class starts *(To be Announced)*

 **ELECTRICAL **

 HOW TO PERFORM AN ELECTRICAL INSPECTION

The next class starts *Mar 17*

 Class sizes will be limited. Register early. 

 **WEATHER WRAP AND BARRIERS**

 Weather resistive barriers and flashing installation and integration

Learn the correct application techniques and how to integrate
different materials. Wall sections are utilized for hands on
demonstrations along with pictorial imaging. 

Presented by: Ben Mauldin, Tyvek

 **quick links**

 Class Calendar


 Directions to Campus


 Professional Education


 Homeowner Classes


 We will train at your facility or ours. 

 We will custom create a presentation to fit your individual needs.
Let us know your needs. 

 Discount price if paid with Cash, Check or Money Order at time of
registration. Easy payment plans provided by We Teach House. Call for
deferred payment pricing and plan. Register early and save $$$. 

 Our training is provided by We Teach House Institute, located in
Roswell, Georgia. All of our instructors are Building Code Certified
in one or more disciplines. Have a minimum of 10 years experience in
property inspections and or have received specialized training in
their field of instruction. 

 Didn't find all your answers?
Click here..


 We Teach House
339 S. Atlanta St
Roswell, GA 30075

 770-552-1224

 Our campus is located in Historic Roswell Georgia. Click for
directions


 Inspectors Associates, Inc. d/b/a We Teach House

 Contact Stan Garnet: [EMAIL PROTECTED]
 Phone: 770-512-8228 Fax: 770-512-8078 

 Click here to be removed from the mailing list: www.iainews.com




--
If you do not wish to receive any more information on our courses or our
newsletters then please click here. 
http://iainews.com/?p=unsubscribe&uid=fff061a9318a4e246ae0d8ad50fb

To update your preferences please visit
http://iainews.com/?p=preferences&uid=fff061a9318a4e246ae0d8ad50fb



--
Powered by PHPlist, www.phplist.com --

Re: Ada subtypes and base types

[Richard Kenner]

Just to make sure I've dotted the i's and crossed the t's, this is not
what's happening when we hang in VRP when compiling a-textio.

We convert the incoming object from natural___XDLU_0___2147483647
into its base type, perform the addition in the base type, then
convert back to XDLU_0_2147483647.

The above is exactly what I thought everybody agrees is and should be
happening, so I'm confused by your "this is not what's happening"
comment above.

Re: Ada subtypes and base types

[Sebastian Pop]

Richard Kenner wrote:
> Just to make sure I've dotted the i's and crossed the t's, this is not
> what's happening when we hang in VRP when compiling a-textio.
> 
> We convert the incoming object from natural___XDLU_0___2147483647
> into its base type, perform the addition in the base type, then
> convert back to XDLU_0_2147483647.
> 
> The above is exactly what I thought everybody agrees is and should be
> happening, so I'm confused by your "this is not what's happening"
> comment above.

So if I understand correctly, if we can prove that the operation does
not overflow in natural___XDLU_0___2147483647, then there is no need
of a cast to the base type and back.

chrec_convert is checking for non overflowing sequences before
removing a cast, and that is missing from the aggressive convert.
Aggressive convert has been intentionally implemented this way because
the conservative chrec_convert has caused performance regressions (see
sixtrack slowdowns from last August).

A patch like the following would solve the problem too, but will
introduce performance regressions... so I'm not sure that it is a good
solution.

Index: tree-chrec.c
===
--- tree-chrec.c(revision 111416)
+++ tree-chrec.c(working copy)
@@ -1202,6 +1202,8 @@ chrec_convert_aggressive (tree type, tre
 {
   tree inner_type, left, right, lc, rc;
 
+  return chrec_convert (type, chrec, NULL_TREE);
+
   if (automatically_generated_chrec_p (chrec)
   || TREE_CODE (chrec) != POLYNOMIAL_CHREC)
 return NULL_TREE;

Re: Ada subtypes and base types

[Jeffrey A Law]

On Fri, 2006-02-24 at 18:42 +0100, Sebastian Pop wrote:
> Richard Kenner wrote:
> > Just to make sure I've dotted the i's and crossed the t's, this is not
> > what's happening when we hang in VRP when compiling a-textio.
> > 
> > We convert the incoming object from natural___XDLU_0___2147483647
> > into its base type, perform the addition in the base type, then
> > convert back to XDLU_0_2147483647.
> > 
> > The above is exactly what I thought everybody agrees is and should be
> > happening, so I'm confused by your "this is not what's happening"
> > comment above.
> 
> So if I understand correctly, if we can prove that the operation does
> not overflow in natural___XDLU_0___2147483647, then there is no need
> of a cast to the base type and back.
And that's still a topic that needs to be thoroughly 
discussed.  We overflow the TYPE_MAX_VALUE, but do not
overflow its TYPE_PRECISION.  ie, TYPE_MIN_VALUE/TYPE_MAX_VALUE
do not cover the set of values allowed by TYPE_PRECISION.

I claim that is a bug in the Ada front-end.  Others might
disagree.

jeff

GCC 4.1 RC2 available

[Mark Mitchell]

GCC 4.1 RC2 is now available from:

ftp://gcc.gnu.org/pub/gcc/prerelease-4.1.0-20060223

As usual, please report any problems by filing bugs in bugzilla, Cc'd to
me.  I fully expect these bits to be the final bits, modulo the items on
the release checklist, such as changes to version strings.  Assuming
that no disasters are reported, I will make the final release early next
week.

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

Re: Ada subtypes and base types

[Jeffrey A Law]

On Fri, 2006-02-24 at 18:42 +0100, Sebastian Pop wrote:
> Richard Kenner wrote:
> > Just to make sure I've dotted the i's and crossed the t's, this is not
> > what's happening when we hang in VRP when compiling a-textio.
> > 
> > We convert the incoming object from natural___XDLU_0___2147483647
> > into its base type, perform the addition in the base type, then
> > convert back to XDLU_0_2147483647.
> > 
> > The above is exactly what I thought everybody agrees is and should be
> > happening, so I'm confused by your "this is not what's happening"
> > comment above.
> 
> So if I understand correctly, if we can prove that the operation does
> not overflow in natural___XDLU_0___2147483647, then there is no need
> of a cast to the base type and back.
> 
> chrec_convert is checking for non overflowing sequences before
> removing a cast, and that is missing from the aggressive convert.
> Aggressive convert has been intentionally implemented this way because
> the conservative chrec_convert has caused performance regressions (see
> sixtrack slowdowns from last August).
> 
> A patch like the following would solve the problem too, but will
> introduce performance regressions... so I'm not sure that it is a good
> solution.
One possibility that isn't as drastic would be to add one to the
TYPE_MAX_VALUE of the inner type, then see if the result fits in
the outer type.  Perhaps also limiting that test to unsigned types.

Then again, that could just be papering over the problem; I
really don't know this code anywhere near enough to know what
a good solution will be.

jeff

Re: confused by mips target

[David Daney]

Eric Christopher wrote:


On Feb 23, 2006, at 5:27 PM, Eric Fisher wrote:


Hi,
I'm really confused by mips targets, such as mips-elf, mips-linux,
mips-elf-linux, mips-elf-linux-gnu. I will appreciate if anyone can
tell me the difference between them.



The last two don't exist.


Except I think they may be accepted as synonyms for mips-linux and 
mips-linux-gnu, as the second part of the 'triplet' is often either 
omitted or ignored.  I, of course, have verified none of this.


David Daney



The first one is to target an elf-based embedded system. The second  is 
for a mips-linux (mips-linux-gnu) box.


-eric

Re: Ada subtypes and base types

[Jeffrey A Law]

On Fri, 2006-02-24 at 18:42 +0100, Sebastian Pop wrote:
> Richard Kenner wrote:
> > Just to make sure I've dotted the i's and crossed the t's, this is not
> > what's happening when we hang in VRP when compiling a-textio.
> > 
> > We convert the incoming object from natural___XDLU_0___2147483647
> > into its base type, perform the addition in the base type, then
> > convert back to XDLU_0_2147483647.
> > 
> > The above is exactly what I thought everybody agrees is and should be
> > happening, so I'm confused by your "this is not what's happening"
> > comment above.
> 
> So if I understand correctly, if we can prove that the operation does
> not overflow in natural___XDLU_0___2147483647, then there is no need
> of a cast to the base type and back.
> 
> chrec_convert is checking for non overflowing sequences before
> removing a cast, and that is missing from the aggressive convert.
> Aggressive convert has been intentionally implemented this way because
> the conservative chrec_convert has caused performance regressions (see
> sixtrack slowdowns from last August).
> 
> A patch like the following would solve the problem too, but will
> introduce performance regressions... so I'm not sure that it is a good
> solution.
Another possibility is to simply not allow conversions between a
subtype and basetype.  Again, that might not be as drastic as
your change.

jeff

Re: Ada subtypes and base types

[Sebastian Pop]

Jeffrey A Law wrote:
> One possibility that isn't as drastic would be to add one to the
> TYPE_MAX_VALUE of the inner type, then see if the result fits in
> the outer type.  

Yes, that's basically the idea that is implemented in chrec_convert.

Because we're in a loop and we keep adding "one"s to the base, we have
to know how many times we are going to add the step to the base.  Thus
there are three restrictions for a static analyzer: when the base is a
name, when the step is a name and when the number of iterations isn't
known.

If the base is a name and it is not possible to have a bound on its
value, then even if we know that the loop runs a constant number of
times, we cannot infer that the sequence will not overflow.  The same
is true for an unknown step and for an unknown number of iterations.

We can also have some more information on the base and step from the
range of their type.  This is not yet implemented in chrec_convert,
but it will not catch enough cases if we'll have to stop using the
aggressive convert.

> Perhaps also limiting that test to unsigned types.
> 

yes, there is a test for flag_wrapv in chrec_convert: it calls
scev_probably_wraps_p.

Re: Ada subtypes and base types

[Sebastian Pop]

Jeffrey A Law wrote:
> Another possibility is to simply not allow conversions between a
> subtype and basetype. 

Such a patch also solves the problem.  But I'm not sure to understand
the impact on other codes.  Is this kind of conversion between a type
and its basetype specific to Ada?

Index: tree-chrec.c
===
--- tree-chrec.c(revision 111416)
+++ tree-chrec.c(working copy)
@@ -1207,7 +1207,9 @@ chrec_convert_aggressive (tree type, tre
 return NULL_TREE;
 
   inner_type = TREE_TYPE (chrec);
-  if (TYPE_PRECISION (type) > TYPE_PRECISION (inner_type))
+  if (TYPE_PRECISION (type) > TYPE_PRECISION (inner_type)
+  /* Conversions between a subtype and its basetype are not allowed.  */
+  || TREE_TYPE (type) == TREE_TYPE (chrec))
 return NULL_TREE;
 
   left = CHREC_LEFT (chrec);

4.1.0rc2 *rtems report (preliminary)

[Joel Sherrill]

Hi,


I have just finished building gcc 4.1.0-20060223 for
the RTEMS targets using newlib 1.14 and binutils 2.16.1.
I called this a preliminary report because I have not
built RTEMS itself yet so there may be issues.  I did
not notice any build issues with rc1 so my fingers
are crossed.  I have not executed any code yet with rc1
or rc2 on target hardware.

Fix from rc1: Ada builds without installing C first. :)

arm-rtems4.7: C C++ Ada
avr-rtems4.7: FAILED
h8300-rtems4.7: C C++
i386-rtems4.7: C C++ Ada
i686-pc-linux-gnu: C C++
m68k-rtems4.7: C C++ Ada
mips64-rtems4.7: C C++ Ada
mips-rtems4.7: C C++ Ada
powerpc-rtems4.7: C C++ Ada
sh-rtems4.7: C C++ Ada
sparc-rtems4.7: C C++ Ada

AVR failed with what I think is a known problem.  If it isn't, I need
to report it.

../../../../../../gcc-4.1.0-20060223/newlib/libc/misc/init.c: In 
function '__libc_fini_array':
../../../../../../gcc-4.1.0-20060223/newlib/libc/misc/init.c:59: error: 
unable to find a register to spill in class 'BASE_POINTER_REGS'
../../../../../../gcc-4.1.0-20060223/newlib/libc/misc/init.c:59: error: 
this is the insn:
(insn 64 31 32 2 
../../../../../../gcc-4.1.0-20060223/newlib/libc/misc/init.c:56 (set 
(mem/c:HI (plus:HI (reg/f:HI 28 r28)

   (const_int 1 [0x1])) [5 S2 A8])
   (reg:HI 24 r24)) 12 {*movhi} (nil)
   (nil))
../../../../../../gcc-4.1.0-20060223/newlib/libc/misc/init.c:59: 
confused by earlier errors, bailing out


More to follow early next week I hope.

--joel

Re: Ada subtypes and base types

[Richard Kenner]

So if I understand correctly, if we can prove that the operation does
not overflow in natural___XDLU_0___2147483647, then there is no need
of a cast to the base type and back.

This stuff is complex, but I'm fairly sure that's correct.

RFC: Memory SSA. A redesign of the virtual operand scheme.

[Diego Novillo]

Our current representation of memory operations in the IL is fairly
heavy and source of lots of painful memory and compile time problems.  I
have been thinking on and off about the problem for a few months and
recently I found a few days to really sit down and look at the problem.

I think I may have a new scheme that has the potential of being a lot
lighter both in terms of memory utilization and compile time.  I wrote
up my initial thoughts on this and will be using the IAB branch to test
the implementation.

http://people.redhat.com/dnovillo/pub/mem-ssa.pdf

The document is in its very early stages, it's mostly a brain dump over
the last few days, so it will likely be hard to read and it has glaring
holes and incomplete sections.  It assumes some familiarity with GCC but
it tries to explain how the current system works, what's wrong with it
and how the new approach would look like.

In terms of implementation, I do not think they will be too painful, but
I will likely need to make changes in basic parts of our infrastructure.
 For instance, V_MAY_DEF and VUSE operators will now need to support
multiple input operands.  The operand scanner will no longer be
responsible for adding virtual operands, only the SSA renamer will.
Alias set pruning will also be done during SSA renaming.

So, if I get good results with the new scheme, I will target the changes
for the 4.3 release.  The changes will be too risky for 4.2.

Comments and feedback on the document and the new scheme are greatly
appreciated.


Thanks.

Re: Ada subtypes and base types

[Jeffrey A Law]

On Fri, 2006-02-24 at 19:47 +0100, Sebastian Pop wrote:
> Jeffrey A Law wrote:
> > Another possibility is to simply not allow conversions between a
> > subtype and basetype. 
> 
> Such a patch also solves the problem.  But I'm not sure to understand
> the impact on other codes.  Is this kind of conversion between a type
> and its basetype specific to Ada?
I suspect, but certainly have not confirmed that these conversions
are very common in Ada, but relatively rare elsewhere.  Confirming
that suspicion one way or the other is on my TODO list for the weekend.

jeff

Tuples for GIMPLE

[Diego Novillo]

A few days ago we had chatted with Ian on IRC about the general idea of
using some tuple-like structure for GIMPLE instead of the current notion
of treating everything as a 'tree'.  We also chatted briefly with Zdenek
about this when he proposed turning compiler temporaries into non-decls.
 I think all these threads are converging and we should probably start
doing something about it.

Although I haven't thought too much about it, I know this has been on
people's minds for a long time.  I gathered some stats, which look
interesting.  At least they're skewed in the right direction.

I got these stats over a collection of C/C++ code from cc1-i-files,
SPEC2000, DLV, MICO, TRAMP3D and a couple of C++ bugzilla testcases.
The instrumentation is right after we go into SSA form, so no code has
been cleaned up yet (I wanted to maximize the variety of expressions).
This works to about 6.3M IL statements and 12.3M operands):


GIMPLE statement codes (6295370 statements)

modify_expr =   4770176 ( 75%)
label_expr  =860960 ( 13%)
cond_expr   =393865 (  6%)
call_expr   =210765 (  3%)
return_expr = 31029 (  0%)
resx_expr   = 24399 (  0%)
switch_expr =  3960 (  0%)
asm_expr=   215 (  0%)
goto_expr   = 1 (  0%)


Number of operands per statement

2 operand(s):   4770176 ( 75%)
1 operand(s):916389 ( 14%)
3 operand(s):608590 (  9%)
4 operand(s):   215 (  0%)
5 operand(s): 0 (  0%)


Operands used (12283371 operands)

ssa_name=   5520669 ( 44%)
label_decl  =860960 (  7%)
nop_expr=808041 (  6%)
component_ref   =787782 (  6%)
goto_expr   =787730 (  6%)
addr_expr   =525451 (  4%)
var_decl=478025 (  3%)
integer_cst =282051 (  2%)
plus_expr   =08 (  1%)
tree_list   =202241 (  1%)
indirect_ref=201901 (  1%)
ne_expr =176549 (  1%)
call_expr   =152942 (  1%)
array_ref   =148189 (  1%)
eq_expr =126723 (  1%)
mult_expr   =125067 (  1%)
convert_expr=114905 (  0%)
minus_expr  =108870 (  0%)
filter_expr = 48798 (  0%)
exc_ptr_expr= 48798 (  0%)
bit_and_expr= 42959 (  0%)
gt_expr = 32576 (  0%)
le_expr = 31018 (  0%)
lt_expr = 22302 (  0%)
real_cst= 18568 (  0%)
modify_expr = 16644 (  0%)
rshift_expr = 13704 (  0%)
lshift_expr = 13583 (  0%)
trunc_div_expr  = 11816 (  0%)
truth_not_expr  = 11152 (  0%)
ge_expr = 10991 (  0%)
constructor =  9405 (  0%)
bit_field_ref   =  8874 (  0%)
float_expr  =  8584 (  0%)
rdiv_expr   =  8428 (  0%)
truth_and_expr  =  7400 (  0%)
exact_div_expr  =  7315 (  0%)
bit_ior_expr=  7216 (  0%)
trunc_mod_expr  =  5408 (  0%)
negate_expr =  4875 (  0%)
truth_or_expr   =  4855 (  0%)
bit_xor_expr=  4050 (  0%)
tree_vec=  3960 (  0%)
parm_decl   =  3260 (  0%)
result_decl =  2015 (  0%)
abs_expr=  1896 (  0%)
bit_not_expr=  1530 (  0%)
obj_type_ref=  1276 (  0%)
fix_trunc_expr  =   660 (  0%)
min_expr=   454 (  0%)
rrotate_expr=   439 (  0%)
max_expr=   438 (  0%)
string_cst  =   220 (  0%)
truth_xor_expr  =76 (  0%)
complex_cst =24 (  0%)
realpart_expr   =22 (  0%)
imagpart_expr   =22 (  0%)
unordered_expr  = 4 (  0%)
complex_expr= 4 (  0%)


Not really surprising, but it is nice that the numbers are so skewed.
MODIFY_EXPR and SSA_NAMES should be "easy" to shrink.

If these codes were a simple struct that does not inherit from
'tree_common', perhaps we could save some memory.  So we could have
something like

struct gimple_stmt
{
  struct tree_common common;
  char subcode;
  gimple_op_t ops[1];
};

I'd keep gimple_stmt as a 'tree' because we'll need the usual debugging
information in tree_common and whatnot.

By far the most common operand is an SSA name.  Those need not be trees
either, they could even be an int field, as we keep them in a separate
table.  Zdenek and I have been talking about something related in the
'Not using VAR_DECLs for temporary variables' thread.  Perhaps we could
join these ideas.

The gimple_op_t structure would then be these handful of expressions.
This is roughly what I had in mind, but I have not put a lot of thought
on this.

The ugly part of the work will be fighting against the pervasive notion
that everything in the IL is a 'tree'.  Perhaps we will need to start
with unwrapping routines to interface with the tree helpers.  That
worries me a bit, as it could add unnecessary slowness.  I had a taste
of this when I converted the OMP_CLAUSE_* codes 

Re: Disabling pch checking?

[Mike Stump]

On Feb 23, 2006, at 9:05 PM, Dan Kegel wrote:

it seems to be slow at preprocessing C++ source.
This matters quite a bit when running distcc.


One way to mitigate this would be to use a precompiled header, and  
use -fpch-preprocess with distcc and ship the .gch across instead.   
This saves the far side from having to read lots of source code,  
saves the server from having to write out lots of source code, saves  
having to move it across the network, saves having to open/stat or do  
anything with a large fraction of the headers.


We do this out of the box on darwin.  Scaling still isn't what we'd  
like though.



Is there an option to do that?


Nope.  You're not building on an nfs mount are you?  If so, the first  
order of business it to not do that.

Re: Tuples for GIMPLE

[Andrew Pinski]

> goto_expr   = 1 (  0%)

This really should not be showing up at all since the CFG should
have all the information that is needed.  Did you look into
where this was showing up?

Thanks,
Andrew Pinski

Re: Tuples for GIMPLE

[Andrew Pinski]

> complex_cst =24 (  0%)
> realpart_expr   =22 (  0%)
> imagpart_expr   =22 (  0%)
> complex_expr= 4 (  0%)

For C++ code these seems low except maybe for the fact
they don't really use complex that much, maybe running these
stats over some Fortran code will get a different picture.

-- Pinski

Re: Disabling pch checking?

[Dan Kegel]

On 2/24/06, Mike Stump <[EMAIL PROTECTED]> wrote:
> On Feb 23, 2006, at 9:05 PM, Dan Kegel wrote:
> > it seems to be slow at preprocessing C++ source.
> > This matters quite a bit when running distcc.
>
> One way to mitigate this would be to use a precompiled header, and
> use -fpch-preprocess with distcc and ship the .gch across instead.

That's painful to set up, though (it requires changing the application's
source to be effective, doesn't it?)

> You're not building on an nfs mount are you?  If so, the first
> order of business it to not do that.

No nfs anywhere near this, and $DISTCC_DIR is pointing to
a non-nfs directory.

I guess I'll stop whining and measure whether comment out the stat that looks
for .gch files provides any speedup.
- Dan

--
Wine for Windows ISVs: http://kegel.com/wine/isv

Re: static inline function body is missing

[Mike Stump]

On Feb 24, 2006, at 2:08 AM, Nemanja Popov wrote:

Is it possible to workaround this problem in my port files.


Sounds like a bug, I'd recommend just finding and fixing the bug.   
Can't imagine it is more than a line to fix.


Watch for TREE_USED, SYMBOL_REF_USED, mark_referenced,  
mark_decl_referenced


I'd compile up a port that works (x86-linux maybe), and see where you  
go wrong compared to it.  A watch point on that bit in the DECL will  
stop as it changes on linux, you can then go up and set breakpoints  
and compare.


I'll give you an example of a bit from ppc darwin.  In print_operand,  
we do:


  /* Mark the decl as referenced so that cgraph will output the
 function.  */
  if (SYMBOL_REF_DECL (x))
mark_decl_referenced (SYMBOL_REF_DECL (x));

during printing to ensure that the thing we reference will come out.   
I suspect, if we left that out, some things we'd want would not come  
out.

Re: Tuples for GIMPLE

[Diego Novillo]

Andrew Pinski wrote:

> Did you look into where this was showing up?
> 
No.  Happens on libjava/interpret.cc.  Here's the patch I used and the
stats collecting script, if you're interested in gathering more info.
Index: tree-into-ssa.c
===
--- tree-into-ssa.c	(revision 36)
+++ tree-into-ssa.c	(working copy)
@@ -1773,6 +1773,29 @@ rewrite_into_ssa (void)
   free (dfs);
   sbitmap_free (interesting_blocks);
 
+  FOR_EACH_BB (bb)
+{
+  block_stmt_iterator si;
+
+  for (si = bsi_start (bb); !bsi_end_p (si); bsi_next (&si))
+	{
+	  enum tree_code code;
+	  int i;
+	  tree stmt = bsi_stmt (si);
+
+	  code = TREE_CODE (stmt);
+	  fprintf (stderr, "STMT: %-12s", tree_code_name[code]);
+	  for (i = 0; i < TREE_CODE_LENGTH (code); i++)
+	{
+	  tree op = TREE_OPERAND (stmt, i);
+	  if (op)
+		fprintf (stderr, " OP%d: %-12s", i,
+		 tree_code_name[TREE_CODE (op)]);
+	}
+	  fprintf (stderr, " (%d OPS)\n", i - 1);
+	}
+}
+
   timevar_pop (TV_TREE_SSA_OTHER);
   in_ssa_p = true;
 }
#!/bin/sh
data=00all-gimple-stmts
stmts=00stmt-codes
ops=00op-codes
total_stmts=`cat $data | wc -l`

echo "GIMPLE statement codes ($total_stmts statements)"
echo
for f in `cat $stmts` ; do
cnt=`grep "STMT: $f" $data | wc -l`
printf "%-15s = %9d (%3d%%)\n" $f $cnt $[ $cnt * 100 / $total_stmts ]
done

echo
echo
echo "Number of operands per statement"
echo
total_ops=0
for f in 0 1 2 3 4 ; do
cnt=`grep "$f OPS" $data | wc -l`
printf "%d operand(s): %9d (%3d%%)\n" $[ $f + 1 ] $cnt $[ $cnt * 100 / 
$total_stmts ]
total_ops=$[ $total_ops + ($f + 1) * $cnt ]
done

echo
echo
echo "Operands used ($total_ops operands)"
echo
for f in `cat $ops` ; do
cnt=`grep -o "OP.: $f" $data | wc -l`
printf "%-15s = %9d (%3d%%)\n" $f $cnt $[ $cnt * 100 / $total_ops ]
done

Re: Disabling pch checking?

[Mike Stump]

On Feb 24, 2006, at 1:25 PM, Dan Kegel wrote:
That's painful to set up, though (it requires changing the  
application's

source to be effective, doesn't it?)


No.  On darwin, it is a checkbox to turn distributed builds on, no  
other change necessary.


distcc already adds -E as I recall, you just add one more option as  
well.  And then, when farming it out, you need to see if the  
preprocessed file mentions a .gch file and ship it as well so it can  
be found.


I guess I'll stop whining and measure whether comment out the stat  
that looks

for .gch files provides any speedup.


I hope not, though, with tiny files and no pch... maybe it does help.

Re: [RFC] libffi testsuite gcc flags?

[David Daney]

Andreas Tobler wrote:

Hello all,

I recently recognized that we run the libffi testsuite without any gcc 
flags like -Ox or so. This had the effect that a test case was failing 
since it fell in the area of PR 323. return_fl2.c was compiled with -O0.


Now my question, would it make sense to run the testsuite with different 
opt flags like -O0, -O2 ...?
The ABI should stay the same over all opt flags, yes, but real life apps 
usually use -O2 right?


It could be done easily by just running the suite again with a different 
set.
(I used -W -Wall to clean up the test cases from warnings, a patch which 
will follow soon)


Comments?


I think it is an excellent idea.  I for one normally use -O3 (not -O2). 
 But testing with both -O0 and -O[s23] makes a lot of sense to me.


David Daney

Re: Disabling pch checking?

[Dan Kegel]

On 2/24/06, Mike Stump <[EMAIL PROTECTED]> wrote:
> On Feb 24, 2006, at 1:25 PM, Dan Kegel wrote:
> > That's painful to set up, though (it requires changing the
> > application's source to be effective, doesn't it?)
>
> No.

After reading
http://gcc.gnu.org/onlinedocs/gcc-4.0.2/gcc/Precompiled-Headers.html
I get the impression that, to start using precompiled headers, the procedure is:
1) create a single all.h that includes all the needed .h's
2) precompile all.h
3) edit all your app's sources to include all instead of the individual .h's
That sounds like a source change to me.  Or am I misunderstanding
how precompiled headers are usually used?
- Dan

--
Wine for Windows ISVs: http://kegel.com/wine/isv

Re: Ada subtypes and base types

[Sebastian Pop]

Jeffrey A Law wrote:
> I suspect, but certainly have not confirmed that these conversions
> are very common in Ada, but relatively rare elsewhere.  Confirming
> that suspicion one way or the other is on my TODO list for the weekend.
> 

okay, thanks for your investigation.  I won't be able to read my email
until Monday as I'm going to the FOSDEM in Bruxelles during the weekend.

Sebastian

Re: Disabling pch checking?

[Benjamin Kosnik]

> After reading
> http://gcc.gnu.org/onlinedocs/gcc-4.0.2/gcc/Precompiled-Headers.html
> I get the impression that, to start using precompiled headers, the procedure 
> is:
>1) create a single all.h that includes all the needed .h's
>2) precompile all.h

Correct.

> 3) edit all your app's sources to include all instead of the individual .h's

No.

Use "-include all.h" on the compile line. 

>That sounds like a source change to me.  Or am I misunderstanding
>how precompiled headers are usually used?

Using PCH is not as difficult as you are making it out to be. See the
libstdc++ build process, and the way --cxxpchflags are used in the
libstdc++ testsuite (from scripts/testsuite_flags).

>From that:

/mnt/hd/bld/gcc/./gcc/g++ -shared-libgcc -B/mnt/hd/bld/gcc/./gcc -nostdinc++ 
-L/mnt/hd/bld/gcc/i686-pc-linux-gnu/libstdc++-v3/src 
-L/mnt/hd/bld/gcc/i686-pc-linux-gnu/libstdc++-v3/src/.libs 
-B/mnt/hd/bld/H-x86-gcc/i686-pc-linux-gnu/bin/ 
-B/mnt/hd/bld/H-x86-gcc/i686-pc-linux-gnu/lib/ -isystem 
/mnt/hd/bld/H-x86-gcc/i686-pc-linux-gnu/include -isystem 
/mnt/hd/bld/H-x86-gcc/i686-pc-linux-gnu/sys-include -g -O2 -D_GLIBCXX_ASSERT 
-ffunction-sections -fdata-sections -fmessage-length=0 
-DLOCALEDIR="/mnt/hd/bld/gcc/i686-pc-linux-gnu/libstdc++-v3/po/share/locale" 
-nostdinc++ 
-I/mnt/hd/bld/gcc/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu 
-I/mnt/hd/bld/gcc/i686-pc-linux-gnu/libstdc++-v3/include 
-I/mnt/hd/src/gcc/libstdc++-v3/libsupc++ 
-I/mnt/hd/src/gcc/libstdc++-v3/include/backward 
-I/mnt/hd/src/gcc/libstdc++-v3/testsuite testsuite_abi.o testsuite_allocator.o 
testsuite_character.o testsuite_hooks.o 
/mnt/hd/src/gcc/libstdc++-v3/testsuite/18_support/numeric_limits/epsilon.cc!
-include bits/stdc++.h  -lm   -o ./epsilon.exe

-benjamin

Re: GCC 4.1 RC1

[Andreas Conz]

Hello to all and thank you for the good work,

I was trying to build GCC 4.1 RC1 on AIX 5.1 _32bit_.
The machine is not very fast and I made some mistakes in the beginning.

Now my build stops while configuring libstdc++-v3 :

-->8-
checking for a BSD-compatible install...
/scratch/build/gcc-4.1.0-20060219/install-sh -c
checking whether build environment is sane... yes
checking for gawk... no
checking for mawk... no
checking for nawk... nawk
checking whether gmake sets $(MAKE)... yes
checking for powerpc-ibm-aix5.1.0.0-gcc...
/scratch/build/gcc-4.1.0-20060219/objdir/./gcc/xgcc
-B/scratch/build/gcc-4.1.0-20060219/objdir/./gcc/
-B/opt/oss/apps/gcc-4.1.0-20060219/powerpc-ibm-aix5.1.0.0/bin/
-B/opt/oss/apps/gcc-4.1.0-20060219/powerpc-ibm-aix5.1.0.0/lib/ -isystem
/opt/oss/apps/gcc-4.1.0-20060219/powerpc-ibm-aix5.1.0.0/include -isystem
/opt/oss/apps/gcc-4.1.0-20060219/powerpc-ibm-aix5.1.0.0/sys-include
-maix64
checking for C compiler default output file name... a.out
checking whether the C compiler works... configure: error: cannot run C
compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.
gmake[2]: *** [configure-target-libstdc++-v3] Error 1
gmake[2]: Leaving directory `/scratch/build/gcc-4.1.0-20060219/objdir'
gmake[1]: *** [all] Error 2
gmake[1]: Leaving directory `/scratch/build/gcc-4.1.0-20060219/objdir'
gmake: *** [bootstrap] Error 2
8<--

I configured with
../configure --enable-prefix=XXX --enable-threads

is the problem described at the end of the build log supposed to happen?

In earlier versions I was able to work around this build problem with
the help of the --disable-multilib configure switch.

Have I misread the target specific build instructions or is this a build
problem?


mit freundliche Gruessen / kind regards
Andreas Conz
--
WWWhttp://www.neuro.informatik.uni-kassel.de/~andreasc
e-mail [EMAIL PROTECTED]

"Science is what we understand well enough to explain to a computer.
 Art is everything else we do." - Donald E. Knuth

[gnu.org #225214] apparent mistake in html attribute

[John Sullivan via RT]

Hello GCC Team,

I'm doing some housecleaning, and thought I should pass on this rather
old message to you that we received in the GNU Webmasters queue about
the sidebar on your web pages.

Can someone acknowledge this? Thanks!

--
John Sullivan
GNU Chief Webmaster


> [EMAIL PROTECTED] - Mon Mar 07 09:15:53 2005]:
> 
> The sidebar menu on gcc.gnu.org and gcj.gnu.org  has a width
> setting of 1% on many pages (at approx line 58).  This is 
> commonly overridden in most browsers but the W3.org amaya
> browser is strict in its interpretation...
> By either removing the width attribute altogether as in 5 lines
> previous, or setting it to 100% as in 5 lines later, the display
> of the menu becomes readable in amaya  without affecting the
> other browsers which were already overridding the 1%.
> I suspect it was just a typo but it does make the menu unusable
> in Amaya.  Please see if it can be repaired... and it does occur
> on many pages...john in niagara 
> --
> john russell [EMAIL PROTECTED] [those are L's as in LLAMA]
> http://home.cogeco.ca/~ve3ll
> http://home.cogeco.ca/~trains
> http://home.cogeco.ca/~cipher
> 
> 
> 
> 

Re: GCC 4.1 RC1

[David Edelsohn]

> Andreas Conz writes:

Andreas> Hello to all and thank you for the good work,
Andreas> I was trying to build GCC 4.1 RC1 on AIX 5.1 _32bit_.
Andreas> The machine is not very fast and I made some mistakes in the beginning.

Andreas> Now my build stops while configuring libstdc++-v3 :

Andreas> checking whether the C compiler works... configure: error: cannot run C
Andreas> compiled programs.

Andreas> In earlier versions I was able to work around this build problem with
Andreas> the help of the --disable-multilib configure switch.

If you are building on a 32-bit only system, you need to configure
with --disable-aix64 so that it does not try to build 64-bit libraries.
GCC currently expects to be able to run executables in all multilib modes
when building natively.

David

gcc-4.1-20060224 is now available

[gccadmin]

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

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

You'll find:

gcc-4.1-20060224.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.1-20060224.tar.bz2 C front end and core compiler

gcc-ada-4.1-20060224.tar.bz2  Ada front end and runtime

gcc-fortran-4.1-20060224.tar.bz2  Fortran front end and runtime

gcc-g++-4.1-20060224.tar.bz2  C++ front end and runtime

gcc-java-4.1-20060224.tar.bz2 Java front end and runtime

gcc-objc-4.1-20060224.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.1-20060224.tar.bz2The GCC testsuite

Diffs from 4.1-20060217 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.1
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.

Re: IVOPTS vs Ada subtypes and base types

[Daniel Berlin]

On Fri, 2006-02-24 at 15:48 +0100, Sebastian Pop wrote:
> Jeffrey A Law wrote:
> > 
> > Note how the conversions have been lost.
> > 
> 
> This is a bug in chrec_convert_aggressive.
> 
> The following patch fixes the problem in a quite drastic way,
> disabling the analysis of ivs that contain casts in their induction.

Uh, don't do that :)

There must be a better way.

Re: pointer member constant expression

[Perry Smith]

On Feb 24, 2006, at 8:55 AM, Richard Guenther wrote:


On 2/24/06, Perry Smith <[EMAIL PROTECTED]> wrote:

I have asked this question before -- maybe to the gcc-help list but
I'm still unclear.

The problem is this:

struct foo {
 int a;
 int b;
 int c;
};

static const int foo::*j = &foo::c; // accepted

class dog {
 static const int foo::*k = &foo::c;// error
};

5.19 (constant expressions) paragraph 2, the last item in the 1998 C+
+ spec says " -- a pointer to member constant expression."  That
appears to be defined as: '&' qualified-id (5.19 paragraph 6).

So is the line in error legal C++ or not?


No.

t.C:10: error: 'foo::c' cannot appear in a constant-expression
t.C:10: error: `&' cannot appear in a constant-expression
t.C:10: error: invalid in-class initialization of static data member
of non-integral type 'const int foo::*'


But '&' can occur in a constant-expression and 'foo::c' is a unique-id
which can also appear in a constant expression (see 5.19).  And as
far as the static const data member, 9.4.2 paragraph 4 says:

If a static data member is of const integral or const enumeration
type, its declaration in the class definition can specify a
constant-initializer which shall be an integral constant expression
(5.19). In that case, the member can appear in integral constant
expressions within its scope. The member shall still be defined in
a namespace scope if it is used in the program and the namespace
scope definition shall not con- tain an initializer.

Note that 5.19 states that '&foo::c' is an integral constant
expression.  So I draw the conclusion that k is a const integral
type (but I have not seen a place in the spec that actually says
that a pointer to member is an integral expression but what else
could it be?

Sorry to be a pest but I just don't see why my construct is excluded.

Thank you for your time and patience,
Perry

Re: Disabling pch checking?

[Mike Stump]

On Feb 24, 2006, at 1:57 PM, Dan Kegel wrote:

On 2/24/06, Mike Stump <[EMAIL PROTECTED]> wrote:

On Feb 24, 2006, at 1:25 PM, Dan Kegel wrote:

That's painful to set up, though (it requires changing the
application's source to be effective, doesn't it?)


No.


:-)  On darwin, we just have a UI element that adds a prefix.h to the  
project, and in it you put all the headers you want, and then the UI  
adds -include prefix.h to all the compiles.  No other changes to the  
project are otherwise necessary.


In the world of make, you can add -include prefix.h to the CFLAGS,  
and then create prefix.h as you'd like, and add it into the  
dependency graph for make, and add a rule to compile the header.   
When you said source I discounted the makefile type changes, though,  
I guess that does qualify as source, sorry if I misled you.


3) edit all your app's sources to include all instead of the  
individual .h's


Nope, don't have to do this as most headers will disappear through  
the use of #ifndef FOO; #define FOO  #endif.

RE: GCC 3.4.5 has been released

[nainjeet]

Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:

>
>I'm pleased to announce that GCC 3.4.5 has been released.
>
>   This version is a minor release, from the 3.4.x series, fixing
>regressions with respect to previous versions of GCC.  It can be
>downloaded from the FTP servers listed here
>
> http://www.gnu.org/order/ftp.html
>
>A list of known fixed bugs is available from here
>
>
>http://gcc.gnu.org/gcc-3.4/changes.html
>
>
>   Many thanks to GCC contributors who made this release possible.
>
>-- 
>   Gabriel Dos Reis 
>   [EMAIL PROTECTED]
>

__
Switch to Netscape Internet Service.
As low as $9.95 a month -- Sign up today at http://isp.netscape.com/register

Netscape. Just the Net You Need.

New! Netscape Toolbar for Internet Explorer
Search from anywhere on the Web and block those annoying pop-ups.
Download now at http://channels.netscape.com/ns/search/install.jsp

Re: GCC 4.1 RC1

[Perry Smith]

On Feb 24, 2006, at 4:34 PM, David Edelsohn wrote:


Andreas Conz writes:


Andreas> Hello to all and thank you for the good work,
Andreas> I was trying to build GCC 4.1 RC1 on AIX 5.1 _32bit_.
Andreas> The machine is not very fast and I made some mistakes in  
the beginning.


Andreas> Now my build stops while configuring libstdc++-v3 :

Andreas> checking whether the C compiler works... configure: error:  
cannot run C

Andreas> compiled programs.

Andreas> In earlier versions I was able to work around this build  
problem with

Andreas> the help of the --disable-multilib configure switch.

If you are building on a 32-bit only system, you need to configure
with --disable-aix64 so that it does not try to build 64-bit  
libraries.
GCC currently expects to be able to run executables in all multilib  
modes

when building natively.


(Someone please let me know if this is not correct)

I *think* you can go into kdb as root and type "stat" and the second  
line will tell you if you have a cpu capable of 64 bit operations.


You can build 64 bit libraries in 32 bit mode -- it depends upon your  
processor type.  kdb will tell you that.  Its probably somewhere in  
ODM as well.


HTH,
Perry

Re: GCC 4.1 RC1

[David Edelsohn]

> Perry Smith writes:

Perry> You can build 64 bit libraries in 32 bit mode.

You are answering a different question.  AIX supports building
64-bit executables on 32-bit systems.  It does not depend on the
processor. 

The question is about bootstrapping GCC.  GCC bootstrap wants to
run 64-bit executables during its configuration process.  This is
orthogonal to whether GCC or AIX can compile 64-bit executables on a
32-bit system.

   The bootstrap wants to run executables corresponding to each
multilib, so one currently needs to perform the bootstrap on a system
capable of running in all modes or restrict some of the multilib modes.

David

Re: GCC 4.1 RC1

[Perry Smith]

Thanks

I was mostly trying to give Andreas a way to determine what type of  
system he has (via kdb).



On Feb 24, 2006, at 6:07 PM, David Edelsohn wrote:


Perry Smith writes:


Perry> You can build 64 bit libraries in 32 bit mode.

You are answering a different question.  AIX supports building
64-bit executables on 32-bit systems.  It does not depend on the
processor.

The question is about bootstrapping GCC.  GCC bootstrap wants to
run 64-bit executables during its configuration process.  This is
orthogonal to whether GCC or AIX can compile 64-bit executables on a
32-bit system.

   The bootstrap wants to run executables corresponding to each
multilib, so one currently needs to perform the bootstrap on a system
capable of running in all modes or restrict some of the multilib  
modes.


David